12-10-2012 10:33 AM - edited 03-16-2019 02:38 PM
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.
Solved! Go to Solution.
12-10-2012 12:11 PM
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.
12-10-2012 11:30 AM
ysanadiga01,
Can you please upload your CUBE configuration as well?
Thanks,
Brian
12-10-2012 11:39 AM
12-10-2012 11:51 AM
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
12-10-2012 11:56 AM
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.
12-10-2012 12:11 PM
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.
12-10-2012 12:14 PM
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.
12-10-2012 12:16 PM
You will want to do a similar configuration with your dial-peers on your CUBE.
12-10-2012 12:20 PM
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
!
12-10-2012 01:10 PM
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?
07-11-2014 07:19 AM
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
07-11-2014 07:43 AM
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?
07-11-2014 08:16 AM
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.
07-16-2014 03:14 AM
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
07-16-2014 04:53 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide