Introduction
This document describes some of the issues when calling accross SIP Trunk and how to to troubleshoot the same.
Troubleshooting
Problem: You are currently implementing a SIP trunk from a UC Cluster to an external SIP provider via a CUBE.
Issue in getting basic incoming/outgoing calls. No voice is heard when calling accross SIP Trunk.
A Trace of the problem and the config for the CUBE needs to be taken.
The CUBE is running 15.1.3T code, and the CallManager is on 8.0.3 code.
Refer :https://supportforums.cisco.com/message/3668056
for the detailed trace and configuration file.
Solution
This could happen if You have not configured the dial-peer to CUCM to use SIP.
The trace file gives the following details.
Sent:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 146.191.243.4:6280;branch=z9hG4bK7kljtp2088b0cmgv34l0.1
From: <sip:anonymous@10.0.0.73>;tag=536c8c54
To: <sip:5811@10.0.48.98:6280>;tag=44F7878-C23
Date: Wed, 27 Jun 2012 09:38:06 GMT
Call-ID: ODE1Y2E4ZTlhZDg1NjM0MmRhZDE4YmNhNTRiMjhkN2M.
CSeq: 1 INVITE
Require: 100rel
RSeq: 650
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: "Michelle Walters" <sip:5811@146.191.201.41>;party=called;screen=no;privacy=off
Contact: <sip:5811@146.191.201.41:5060>
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 262
v=0
o=CiscoSystemsSIP-GW-UserAgent 5886 9981 IN IP4 146.191.201.41
s=SIP Call
c=IN IP4 146.191.201.41
t=0 0
m=audio 20748 RTP/AVP 18 96
c=IN IP4 146.191.201.41
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
This means here you are sending G729br8 to your SIP provider but they do not support annexb because in their invite you were unable to find annexb.
INVITE sip:5811@UniWestScot:5060 SIP/2.0
Via: SIP/2.0/UDP 146.191.243.4:6280;branch=z9hG4bK7kljtp2088b0cmgv34l0.1
Max-Forwards: 68
Contact: <sip:anonymous@146.191.243.4:6280;transport=udp>
To: <sip:5811@10.0.48.98:6280>
From: <sip:anonymous@10.0.0.73>;tag=536c8c54
Call-ID: ODE1Y2E4ZTlhZDg1NjM0MmRhZDE4YmNhNTRiMjhkN2M.
CSeq: 1 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER, PRACK
Content-Type: application/sdp
Supported: 100rel
P-Asserted-Identity: <sip:anonymous@10.0.0.73>
Content-Length: 278
v=0
o=Redwood_INX 347015 347015 IN IP4 146.191.243.4
s=Redwood Media Server
c=IN IP4 146.191.243.4
t=0 0
m=audio 50002 RTP/AVP 8 18 96
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=silenceSupp:off
a=ecan:on
a=fmtp:96 0-15
So in this case you need to either configure your cube to transcode from g729br8 to g729r8 or send your provider g729r8
Ensure you add g729br8 in your list of codecs
If the issue still persist do another test call and run the debug ccsip messages.
After looking at the trace in detail it was found that the called number was not from the sip provider.
Your dial-peer 1 shows like this.
dial-peer voice 1 voip
incoming called-number 5[8-9].. (this is not the incoming called number)
it should be this..
dial-peer voice 1 voip
incoming called-number 01387345[8-9]..
Then when this dial-peer is matched, the xlation will be applied.
Also you need to remove the following lines from the dial-peers to cucm. you need to ensure that you have removed all dial-peers to cucm and sip provider.
progress_ind setup enable 3
progress_ind alert enable 8
Call Forward over SIP trunk fails
Problem Details: You have a SIP trunk connecting to provider called centurylink. For sites that you have provisioned on this SIP trunk,
call forwarding to a PSTN number is not working. This issue is related to the originating number not being associated with the provicer
century link account, and so century link is probably dropping the call.
How to configure the call forward on a line to transform the ANI which is sent out on the SIP turnk to be a predetermined number (like the DID of the line).
The call flow is
PSTN--SIP(CUBE)--CUCM--IP PHONE(CFA)---SIP(CUBE)---PSTN
The call coming through same sip trunk and going through same .
Solution:
Here the issue is in selecting redirecting calling rather than original calling party when doing a CFA to PSTN number. This happens because the
s the originating number is of the PSTN party and the number is not registered with provider so they are dropping it. To resolve this issue you need to change the calling party selection from original calling party to last redirecting party (External).
Calls failing accross SIP trunk to display caller ID
Problem Description: When users homed at Head Quarters CUBE makes an outbound call,
the Local Route Group is failing to send the call out the gateway, calls are defaulting to the trunk causing the caller ID to represent the trunk's mask.
Follow the steps below to resolve the issue:
- Incoming/Outgoing dial-peers on CUBE were configured with g729
- Call from CUCM came with EarlyOffer g711u codec.
- CUBE rejected call with codec mismatch between incoming dial-peer and codec in INVITE message.
- After checking configuration parameters on SIP trunk it was found that MTP required is checked and g711u used as codec for EarlyOffer Configuring g729 caused disconnect from CUCM side.
- Disabling MTP on trunk made call possible to go through CUBE successfully.
Actually, outgoing dial-peer on CUBE is configured for EarlyOffer so there's no need to configure MTP on SIP trunk to avoid double xcoding. In version 8.0.3+ EarlyOffer sent from SIP trunk without using MTP. MTP required was checked on SIP trunk which caused CUCM to send call with G711u towards CUBE. Dial-peer towards SIP provider on CUBE was configured with g729 and no local xcoder configured. After disabling MTP required on SIP trunk everything works as expected.
Incorrectly configured trunk with MTP enabled caused CUBE to reject call with codec mismatch reason. Call went out through different GW in RGL. After disabling MTP call went through correct GW.
Related Links
