SIP trunk codec problem

[vjemin]

Hi,

I have CUCM 7.1 server and it has SIP trunk configured. I don't have voice gateway or CUBE, provider's CPE is on my network and comunication goes through that CPE (please, don't ask why is that so).

SIP trunk is configured with MTP enabled and we use g711a codec for outside calls.The idea is that CUCM and provider speak SIP and IP phone and CUCM speak SCCP and RTP goes between IP phone and CUCM and CUCM and provider.

So, IP phone see CUCM ip address in RTP stream.

So, when I call from IP phone, everything works well.

But, when someone calls from outside, my CUCM and provider can not agree about codec!

How that looks like: outside phone calling, my IP phone ringing, I hang up my IP phone, but it still ringing on outside phone. After a few seconds call is droped.

In SIP messages my CUCM send g711u codec, and provider does not accept it.

How can I configure that I use g711a codec for call coming from provider? Is it possible and where.

Thanks,

Vlaho

[vasank]

in sip trunk configuration page u first have to enable MTP require check and then in SIP Information section select MTP Preferred Originating Codec to g711alaw

HTH

[srsivara]

If the SIP trunk config for MTP is already set to g711a, then reset the trunk and make a test call. If the call fails, get the detailed 'Cisco CallManager' traces (SIP call processing and SIP stack traces too) for the time period of the call, and attach it to the thread. Let us know

- Calling party

- Called party

- Time stamp of call

- Exact user experience

- Sriram

Please rate helpful posts !

[vjemin]

Hi,

this is what I have at the moment. Debug from CallManager when I call in (mobile to ip) and when I call out (ip to mobile). Call out works fine.

Mobile number (in both cases) is 0098463786 and local nuber is 8999 (provider sends 1047908999). Providers SIP trunk is 10.56.0.13.

The problem is in this part where CallManager ofers only g711ulaw (from mobile to ip debug):

SIP/2.0 200 OK
Date: Fri, 04 Feb 2011 15:02:02 GMT
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
From: <0098463786>;tag=0065d32f000036b0
Allow-Events: presence, kpml
P-Asserted-Identity: <8999>
Supported: replaces
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Remote-Party-ID: <8999>;party=called;screen=yes;privacy=off
Content-Length: 212
To: <1047908999>;tag=523d0b10-6686-4eeb-9000-35fa7ce40008-19860576
Contact: <1047908999>
Content-Type: application/sdp
Call-ID: 7f00000113ce0065d32f000036b0@127.0.0.1
Via: SIP/2.0/UDP 10.56.0.13:5060;branch=z9hG4bK1dop01000gggmcsst5o1.1
CSeq: 2 INVITE

v=0

o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.17.254.33

s=SIP Call

c=IN IP4 10.17.254.33

t=0 0

m=audio 24748 RTP/AVP 0 101

a=rtpmap:0 PCMU/8000

a=ptime:20

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

Regards,

Vlaho

[srsivara · Accepted solution]

The issue stems from the fact the Telco advertises g711u as a codec that they can support - comes in the incoming SIP INVITE :

02/04/2011 16:02:02.905 CCM|//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP message size 756 from 10.56.0.13:[5060]:
INVITE sip:1047908999@10.17.254.33:5060 SIP/2.0
Via: SIP/2.0/UDP 10.56.0.13:5060;branch=z9hG4bK1dop01000gggmcsst5o1.1
Contact: <0098463786>
GenericID: 129683172264184@000825a07210
Supported: 100rel
From: <0098463786>;tag=0065d32f000036b0
To: <1047908999>
Call-ID: 7f00000113ce0065d32f000036b0@127.0.0.1
CSeq: 2 INVITE
P-Asserted-Identity: <0098463786>
Content-Length: 216
Content-Type: application/sdp
Max-Forwards: 70

v=0
o=IWF 1102140 1249019 IN IP4 10.56.0.13
s=H323 Call
c=IN IP4 10.56.0.13
t=0 0
m=audio 39388 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

CallManager allocates MTP for call flow, and selects g711u codec, as the SIP provider claims to support that codec.

Please work with your Telco to not send g711u as a supported codec to CallManager, so that this issue doesn't occur.

- Sriram

Please rate helpful posts !

[vjemin]

Sriram,

thanks a lot.

Problem is solved on providers side.

They have moved the ulaw codec and now works well.

I don't know why are they giving the second codec when they can not handle it

Kind regards,

Vlaho