SIP Codec Negotiation

Home » Asterisk Users » SIP Codec Negotiation
Asterisk Users 7 Comments

I receive an INVITE/SDP containing:

m=audio 11310 RTP/AVP 3 0 101

which I interpret as gsm, ulaw, rfc2833.

and I reply with an OK/SDP containing:

m=audio 15884 RTP/AVP 0 3 101

which I interpret as ulaw, gsm, rfc2833.

How can I tell which codec was actually used for the call?

7 thoughts on - SIP Codec Negotiation

  • AFAIK this is undetermined. The callee can send either ulaw or gsm, unless the caller wants to narrow it down to 1 codec, see https://tools.ietf.org/html/rfc4317#section-2.2

    Most of the time the callee will pick the first (so in this case ulaw). But there are media gateways out there that choose g711[au] above “more complex” codecs regardless order in SDP. My prefer PSTN provider will always prefer alaw if offered since that will prevent transcoding on their side if the call goes to ISDN/POTS, but AMR if the call goes to VoLTE.

  • So, without examining the RTP, you cannot tell which codec was actually used?

    In the above example, even though the INVITE/SDP says they prefer gsm over ulaw and the OK/SDP says I prefer ulaw over gsm, they can choose to use gsm or ulaw?

    Can it be asymmetrical? They send gsm and I send ulaw?

  • From an Asterisk perspective “core show channel” will also show you what is currently flowing.

    Yes.

    Technically, yes. In practice it’s a bit iffy – specifically because some DSPs in devices won’t allow it – they require a single codec be in use for each direction.

  • So, Asterisk will defer it’s choice of codec to match the codec it detects in the incoming stream?

  • It depends on the channel driver and configuration. The chan_sip module always matching outgoing codec to the incoming codec. The chan_pjsip module has an option to do that (which is on by default).

  • The unwritten rule of SDP is that if possible you use the first codec of a type listed, but you don’t have to. If the sender says he can do something, he had better be prepared to handle media of that type no matter in what order it was listed.

    So when you send OK with ulaw as first priority and get ACK most probably it will be ulaw

    בתאריך יום ו׳, 11 במאי 2018, 16:08, מאת Steve Edwards ‏< asterisk.org@sedwards.com>:

  • Is this why I see occasional notices in my log file like:

    Dropping incompatible voice frame on SIP/xxx of format ulaw since our native format has changed to (gsm)