11-14-2013 11:32 AM - edited 03-16-2019 08:25 PM
Hello,
I am trying to figure out why we cannot forward calls on a SIP trunk. Inbound and Outbound calls work fine, it is only when we try to forward a call (i.e. CfwdAll from a phone attached to CUCM) that it fails...
Current setup includes a CUCM 9, Cisco 2951 voice gateway and a SIP trunk to a UK provider (Gradwell).
Some settings from the CUCM Gateway configuration:
- Media Termination Point Required
- Enable Inbound FastStart
- Redirecting Number IE Delivery - Outbound
- Enable Outbound FastStart (G711alaw)
I have included a sanitized copy of my gateway configuration as well as an output of a 'debug ccsip messages'.
For some reason, our gateway sends a CANCEL immediately after the RINGING state on the forwarded call. The call-forwarded destination (my mobile) only rings once and the call disconnects...
Please, help I am completely lost with this....
David
Solved! Go to Solution.
11-15-2013 01:26 AM
David,
From your traces, we can see that the call is disconnected due to Capabilites issues, codec etc..The disconnect cause is 47.
The trace only showed the sipo leg of the call. From your config we can see that the leg to cucm uses H323. Hence to get an accurate picture you will need to send the ff:
debug voip ccapi inout
debug ccsip messages
debug h225 asn1
debug h245 asn1
However looking at the siup trace and your config, it looks like the issue is pretty obvious..
The dial-peer to cucm is configured to use G729..
dial-peer voice 4001 voip
destination-pattern 44141.......
session target ipv4:172.16.200.100
dtmf-relay h245-alphanumeric
acc-qos controlled-load audio
no vad
On the other hand, because this call is hairpinned back to the gateway...The intra region setting is set to use G711..Hence CUCM sends G711 as the codec to use..and we can see that in the INVITE the gateway attempt to send out...
To resolve this..configure voice-class codec 1 on your dial-peer 4001...
If this doesnt resolve please send the logs I requested
Please rate all useful posts
"opportunity is a haughty goddess who waste no time with those who are unprepared"
11-15-2013 01:26 AM
David,
From your traces, we can see that the call is disconnected due to Capabilites issues, codec etc..The disconnect cause is 47.
The trace only showed the sipo leg of the call. From your config we can see that the leg to cucm uses H323. Hence to get an accurate picture you will need to send the ff:
debug voip ccapi inout
debug ccsip messages
debug h225 asn1
debug h245 asn1
However looking at the siup trace and your config, it looks like the issue is pretty obvious..
The dial-peer to cucm is configured to use G729..
dial-peer voice 4001 voip
destination-pattern 44141.......
session target ipv4:172.16.200.100
dtmf-relay h245-alphanumeric
acc-qos controlled-load audio
no vad
On the other hand, because this call is hairpinned back to the gateway...The intra region setting is set to use G711..Hence CUCM sends G711 as the codec to use..and we can see that in the INVITE the gateway attempt to send out...
To resolve this..configure voice-class codec 1 on your dial-peer 4001...
If this doesnt resolve please send the logs I requested
Please rate all useful posts
"opportunity is a haughty goddess who waste no time with those who are unprepared"
11-15-2013 05:38 AM
Hello and thanks for helping us out! As you suggested the codec specification was missing under the dial-peer. Although calls are getting established now, I am stumbled upon another issue which I suspect is from the same (codec mismatch) nature...
Now that I can forward calls out, they seem to be failing when establishing the media with the SIP provider. My scenario is: Call coming in from SIP -> Gateway -> CUCM -> UCCX Script forwards call back out to SIP -> Gateway -> SIP. I think it is the call from UCCX to the SIP provider which is failing, because the same happens if I dial the trigger of my script (4004) from an internal extension on cucm...
I have attached the debugs that you specified above. The first one is when the call is initiated from ext.1237 and the second one is an incoming call from SIP that should be call-forwarded back out to SIP through UCCX.
Thanks,
David
11-16-2013 12:38 AM
David,
I have looked at the traces and I can see CUCM sending a close logical channel to the CUBE. And yes the cause is down to media negotiation failure. I will need to see the detailed CUCM traces to determing why. The call didnt even make it to the transfer stage...I suspect this might be an MTP issue, but I need cucm traces to verify that..Please send over
Please rate all useful posts
"opportunity is a haughty goddess who waste no time with those who are unprepared"
11-16-2013 02:20 PM
Hi mate,
I managed to get it working. What I did was I stopped the transcoder on the gateway (did 'no sccp' and 'no telephony-service') and calls were fine after that. Although this gets it working I still cannot understand why it was failing with the local transcoder? This is what I had used:
sccp local GigabitEthernet0/1
sccp ccm 172.16.200.100 identifier 2 version 7.0
sccp ccm 172.16.200.90 identifier 1 version 7.0
sccp ccm group 2
associate ccm 2 priority 1
associate profile 2 register TBR-HQ-XCODE
keepalive retries 1
keepalive timeout 10
switchover method immediate
switchback method immediate
sccp ccm group 1
associate ccm 1 priority 1
associate profile 1 register XCODER
keepalive retries 1
keepalive timeout 10
switchover method immediate
switchback method immediate
dspfarm profile 1 transcode
codec g729r8
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
maximum sessions 10
associate application SCCP
dspfarm profile 2 transcode
codec g729r8
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
maximum sessions 4
associate application SCCP
------------------------------------------------------------
I must have misconfigured the transcoder, but I cannot see where the problem is.
Thanks,
David
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