cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4616
Views
6
Helpful
5
Replies

SIP/SDP - no codec specifed

TONY SMITH
Spotlight
Spotlight

Hi,

Where an incoming call does not specify an attribute for codec within it's SDP headers, my understanding is that this is equivalent to specifying G711u.   Is that correct, or is there some wider meaning.  For example does it indicate G711u only, or does it leave the choice of codec open?   My reason for asking is that in an installation I'm looking at just now the ITSP does not specify for incoming calls, but apparently is happy to accept G729 if that's what we respond with.

1 Accepted Solution

Accepted Solutions

The numbers at the end of this m line:

m=audio 23610 RTP/AVP 8 0 18 97

Those are the codecs.

They are RTP payload types, and in preference order.

Eg 8=g711alaw, 0=g711ulaw, 18=g729, 97=this one is special, it's actually what they want to Mark RTP-NTP (RFC2833) DTMF relay as.

The audio descriptions are optional, which is what you were referring to, but the offer would still contain the codecs on the m line.

https://en.m.wikipedia.org/wiki/RTP_audio_video_profile

View solution in original post

5 Replies 5

Mike_Brezicky
Cisco Employee
Cisco Employee

Do you have the SIP traces showing no audio codec?  I am surprised a carrier would not include any m=audio or  a=rtpmap if they are sending the invite with SDP.

 

I believe the default codec for a voip dial peer is g.729, but as long as you have a voice class codec assigned to the dial peer with the other codecs, that should be fine.  You might need a transcoder in some cases.

 

As for what they accept back, some carriers will take whatever is sent, some are hard coded to only allow one.

 

 

Yes that's correct, "m" and "a" attributes in the incoming Invite are ..

   m=audio 23610 RTP/AVP 8 0 18 97
   a=rtpmap:97 telephone-event/8000
   a=fmtp:97 0-15
   a=ptime:20

As for transcoding I was expecting it to use the CUBE's DSPs as it does for outbound calls  Instead the CUBE passes CUCM's requested G729 straight through to the ITSP.  In summary ..

    Incoming Invite - unspecific codec
   Invite to CUCM - offers G711u and G729
   OK from CUCM - G729
   OK to ITSP - G729

That last stage wasn't what I was expecting, I expected it to honour the G711 from the initial Invite, and transcode.

By the way all references to G729 here are to do with calls answered or originated away from the site of the gateway, normal calls within the site use G711.  That's all controlled by CUCM regions.

The numbers at the end of this m line:

m=audio 23610 RTP/AVP 8 0 18 97

Those are the codecs.

They are RTP payload types, and in preference order.

Eg 8=g711alaw, 0=g711ulaw, 18=g729, 97=this one is special, it's actually what they want to Mark RTP-NTP (RFC2833) DTMF relay as.

The audio descriptions are optional, which is what you were referring to, but the offer would still contain the codecs on the m line.

https://en.m.wikipedia.org/wiki/RTP_audio_video_profile

That's great thanks.  I must admit that since I've never before seen signalling that didn't contain the audio headers I didn't look elsewhere for codec information, even when looking through the RFCs.  

We're never done learning. Cheers!