Delay Outbound through SIP Trunk

[ysanadiga01]

Hi there,

When calling Outbound through a SIP trunk takes about 20 seconds. Inbound calls are going fine. I tried the following scenario's:

IP Phone > CUCM > SIP Trunk > CUBE > SIP Provider

IP Phone > CUCM > H323 Gateway > CUBE > SIP Provider

I'm attachting CCSIP logs and if you look at the timestamps, you can see there is a delay of around 10 seconds.

Any suggestions will be highly appreciated.

thanks.

[brmeade]

ysanadiga01,

Can you please upload your CUBE configuration as well?

Thanks,

Brian

[ysanadiga01]

Hi Brian,

Here is the configuration.

thanks.

[brmeade]

ysanadiga01,

It looks like this is caused by your dial-peer 1010 configuration:

dial-peer voice 1010 voip

destination-pattern T

You will want to use more specific patterns as the call will be delayed until the interdigit timeout is reached with your current configuration as it could receive more digits through SIP Options messages.

Thanks,

Brian

[ysanadiga01]

Hi Brian,

Thanks for your answer.

Dial-peer 1010 is a "general" inbound/outbound dial-peer towards the SIP provider. Do you have any suggestion how I can make is more specific?

Thanks.

[brmeade · Accepted solution]

You could create multiple dial-peers for local calls, long distance calls, and international calls to match different possible lengths.  You will ideally want these to not overlap either.  This is where design comes into play when it comes to doing IPT.

[ysanadiga01]

Hi Brian,

I think I know what you mean. In CUCM I have already configured several route patterns for local, mobile, international etc. I don't think that there is an issue with inter-digit-timeout.

Thanks.

[brmeade]

You will want to do a similar configuration with your dial-peers on your CUBE.

[ysanadiga01]

Hi Brian,

A few weeks back I did same kind of configuration with another customer (with the same SIP Provider) and I don't have this probleem there. I did the same on CUCM and also on the CUBE (same version of IOS and almost same configuration).

!

dial-peer voice 1010 voip

destination-pattern T

progress_ind alert enable 8

session protocol sipv2

session target dns:pbx.signet.nl

incoming called-number T

dtmf-relay rtp-nte cisco-rtp

codec g711ulaw

no vad

!

dial-peer voice 1000 voip

destination-pattern 717470101

session target ipv4:192.168.1.250

incoming called-number 717470101

dtmf-relay h245-alphanumeric

codec g711ulaw

no vad

!

dial-peer voice 1020 voip

destination-pattern 8886401..

progress_ind alert enable 8

session target ipv4:192.168.1.250

incoming called-number 8886401..

dtmf-relay h245-alphanumeric

codec g711ulaw

no vad

!

[brmeade]

After looking further into this, you may be having issues with the DNS lookup of pbx.signet.nl.  The CUBE will first do an SRV lookup to the configured name-server.  If your DNS server doesn't respond to SRV lookups, it will fail after 9 seconds then use a regular A-record lookup which will use your "ip host" configuration.  Do you have a name-server configured?

[lliska]

Hi,

we had similar problem, the CUBE waited 9 seconds before INVITE was forwarded on outside leg. It was caused by DNS (default DNS timeout is 3 sec, default retry is 2, what means 3x3=9 seconds). Workaroud was to set DNS timers to minimal values:

ip domain retry 0
ip domain timeout 1

But the question is, why CUBE tries to use DNS server, when we have domain lookup set to OFF, and why it does not directly use manualy configured record.

With the workaround we decreased the delay to 1 second (better than 9 :-), but if we could avoid also this unnecessary 1 second, it would be nice.

Thanks,

Lubomir

[Ayodeji Okanlawon]

Is your session target set to use DNS? If it is then CUBE will need to resolve the target name to ip before the call can be routed..Have you tried to use IP address directly?

[lliska]

Yes, our session target points to a DNS name. We need it because it uses sip-ua (registration) and authenticates with the provider with every call request; we were not able to get it working with IP address as a session target.

[Ayodeji Okanlawon]

It looks like the issue is with your DNS server. Its response back to CUBE is delayed.

You can try and configure your DNS records locally on the CUBE to ascertain where the issue lies.

dial-peer voice 1 voip
 destination-pattern 2000
 session protocol sipv2
 session target dns:cucm.company.org
!
! The SRV records for the domain name specified in the dial-peer
!
ip host _sip._udp.cucm.company.org srv 1 50 5060 cucm-subA.company.org
ip host _sip._udp.cucm.company.org srv 2 50 5060 cucm-subB.company.org
ip host _sip._udp.cucm.company.org srv 3 50 5060 cucm-pub.company.org
!
! DNS entries for the hostnames specified in the SRV records
!
ip host cucm-pub.company.org 10.0.0.1
ip host cucm-subA.company.org 10.0.0.2
ip host cucm-subB.company.org 10.0.0.3
!
! Tell IOS to use itself as a DNS server
!
ip name-server 127.0.0.1
ip domain name company.org

[lliska]

Excellent, this works!

I tried before to make router itself a DNS server, and added record:

ip host _sip._udp.cucm.company.org 10.0.0.1

(hostname is obvious from "debug domain" output), but I did not specify it in correct SRV format, so it was not working.

Thank you very much, you saved our lives (at least 1 second for every call we make :-)

Lubomir