Dialing delay between CME routers

Hi all..

I have been toying around with implementations of multiple CME deployments and I have noticed that when calling between CME routers there is a delay of upto 25 seconds before the endpoint will call. Debug shows me that I am matching the right dial-peers and that it takes less than 1 second to find the match (debug voip ccapi inout).

Routing between the networks is low latency through GRE. QoS is also configured against ef and cs5 packets.. with a policy-map setting the dscp to af41 (that is what is needed to match the telco).

I have also found that for a CME that is the single exit point to the PSTN, the delay is aggregated as the channel is set up between all CMEs.

Calls internal to the CME node have zero delay...

Any ideas from the Voice gurus?

Cheers.

Find more posts tagged with

Comments

shodown

I would need too see the configurations and where the CME's go to the PSTN to have an idea.

cisco_nerd

Shodown,

The PSTN connection is through a locally owned PBX and then through a satellite bearer which only induces a few seconds of latency for outgoing calls. However between the CMEs it is a full IP network, and this is where the delay occurs. The networks between sites are meshed together through GRE VPN. All GRE have qos enabled (qos pre-classify) and QoS applied to the physical interface for the tunnel (output policy).

I have built a replica network in a test bed that has next to no data traversing the network except for all the normal keepalives etc.

Calls that originate from the router connected to the PBX have minimal delay out the E1 card, calls that are made through another CME to the PSTN is delayed, and any external VOIP call between the CMEs is delayed up to 15 seconds.

Traceroutes and pings between the loopbacks of the CMEs shows very low latency (ping avg - 1-5ms, trace avg 4ms).

Debug voip ccapi inout shows a dial-peer match in less than 1 second, and as stated QoS is implemented within the network for voice packets

This is a portion of the config with the relevant bits of info shown. The other side is mostly the same except has the E1 card for off-net calls. There is nothing fancy about the config or the dial-peers. I am running CME 8.5 on 2851 and 2951 ISRs.

voice service voip
allow-connections h323 to h323
supplementary-service h450.12
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
h323
no h225 timeout keepalive
call preserve
!
!
interface Loopback100
ip address 1.1.1.1 255.255.255.255
h323-gateway voip interface
h323-gateway voip bind srcaddr 1.1.1.1
ip ospf 1 area 1
!
!
interface GigabitEthernet0/0.100
description VOICE VLAN
encapsulation dot1Q 100
ip address 192.168.1.1 255.255.255.0
!
!
interface GigabitEthernet0/0.200
description DATA VLAN
encapsulation dot1Q 200
ip address 192.168.2.1 255.255.255.0
ip ospf 1 area 1
!
!
router ospf 1
area 1 stub
passive-interface GigabitEthernet0/0.100
!
!
!
dial-peer voice 1 voip
description OUTGOING DIAL-PEER
destination-pattern 0T
session target ipv4:2.2.2.2
dtmf-relay rtp-nte h245-alphanumeric
req-qos guaranteed-delay audio
codec g711ulaw
no vad
!
dial-peer voice 2 ports
description FAX LINE
destination-pattern 55423
voice-port 0/1/0
!
dial-peer voice 10 voip
description CME#2 DIAL-PEER
destination-pattern 555..
session target ipv4:2.2.2.2
dtmf-relay rtp-nte h245-alphanumeric
req-qos guaranteed-delay audio
codec g711ulaw
no vad
!
telephony-service
no auto-reg-ephone
ip source-address 1.1.1.1 port 2000
timeouts interdigit 4
dialplan-pattern 1 02123554.. extension-length 5 extension-pattern 554..
!

shodown

you have the dial peer 0T. What I"m thinking is that you have a inter digit time out issue.

cisco_nerd

Interdigit timeout is only set at 4 seconds. 0T dial-peer captures all PSTN bound phone numbers for the router that has the E1 connection to the PABX.

Even by using the digit terminator (#) after the dialed string to force the call-channel to begin setting up instead of waiting for the timeout for the dial-peer, the delay was not reduced.

I have however rectified the issues, as it was an issue caused by a previous engineer using "num-exp" to change a full E.164 number to a 5 digit extension and conflicting with the dialplan-pattern telephony service config:

e.g. num-exp 02612345.. 45..

Removed this and added a dial-peer to capture the full E.164 number to compliment the extension so that either number can be dialed internally and delay was completely removed. Calls now between CME routers are virtually instantaneous.

JeanM

Very nice!

cisco_nerd

JeanM wrote: »

Very nice!

Cheers!