There are always two participants in the SDP negotiation , both will publish/offer a prioritized by preference list, the one codec that is mutually accept by both parties with the highest priority will be used first (it might fail, then the list goes down) both parties can have ‘areallyneatcodec’ as a priority, but until both parties have a ‘reallyneatcodec’ that works then we proceed ‘down the list’ until we get an agreement.
For calls that might include local and PSTN connections then areallyneatcodec,opus,g722,ulaw,alaw,gsm,g729 would be a good order for your ‘A-leg’ to offer ordered by your personally perceived ‘MOS’ (MeanOpinionScore) , SDP will settle on the highest priority that the ‘B-leg’ supports
Yet even the greatest will have to bow down to the Greatest Common Factor that SDP negotiated (that’s not for Cisco to decide) Every circuit between A-leg and B-leg can contribute to the negotiated codec, PSTN as stated will likely peg out at g711. but you can try and negotiate ‘directmedia’ for a pure network connection over and above the limitations of your PBX, you might then get areallyneatcodec (but no voicemail )
Although people talk about negotiating codecs, SIP is not even specified to require the same codec in each direction, and there is no negotiation phase.
Asterisk will (I’m not sure if an override has been added for this) only offer codecs that are configured, within it, for the endpoint, and, if making the second SDP offer, will only offer codecs that were in the first offer. If the peer tries to only offer codecs not configured at the Asterisk end in the INVITE, it will reject the call with Not Acceptable Here. If this happens on a response, or an ACK, it will accept the call and immediately hang it up.
The only cases where it can subsequently discover a codec is unusable is if the peer sends a codec that wasn’t in Asterisk’s offer, or transcoding proves necessary and Asterisk has no suitable codec modules to perform the translation. In that case the media is dropped, with no attempt to renegotiate.
One further subtlety is that the chosen working codec for the A side is moved to the top of the list on the B side, assuming that it is an available choice.
Also, as I remember it, Asterisk uses a bitmap of the allowed codecs, so the order of them in the configuration file is ignored. Certainly the list given to the peer is always in ascending order of codec number, not priority order.
It looks like things may have changed since I looked at this in any detail. Asterisk does preserve information about preference order (which is modified by the result of the A side exchange when setting up the B side). Also, although I’m used to seeing codecs in numerical order, SDP does make the order correspond to the order of preference.
That was what I thought for the original post, but on further fact checking, RFC 3264 says:
In all cases, the formats in the “m=” line MUST be listed in order of
preference, with the first format listed being preferred. In this
case, preferred means that the recipient of the offer SHOULD use the
format with the highest preference that is acceptable to it.
Asterisk allocates a small, natural, number to each possible codec. The bitmap would have been a bit array, indexed by those numbers
)