Codec negotiation and the impact of dial-peers, SIP configuration.

[_|brt.drml|_]

Dear members

I'm searching the to large and world wide web for following information.

- When and how are codecs negotiated?

- what has the priority? Diel-peer or the endpoint? (e.g. codec transparten vs codec list vs fixed codec)

- what is the impact of configurations like early offer etc..

- how does the voice class codec list work? Is it top to bottom offer?

Simply said - if someone has/knows where to find good information on this forum. Please share.

And I thank you in advance.

[Anthony Holloway]

Codecs are negotiated anytime between call setup and call answer.

Codecs are negotiated in the "offer/answer" model. An analogy would be: I tell you a few options for lunch, and you pick one of them.

Priority is always given to the side which sends the offer. For example, if I only want to eat at McDonalds for lunch, and I don't want you picking Burger King, then when I give you my offer, I just omit Burger King; therefore I ultimately get to choose. However, if I give you a bunch of choices, technically, I am giving you ultimate control over where lunch is, because you get to pick anyone from my list.

Codec transparent simple tells the DP to passthru the codec offer from the UAC.

The impact of early offer is that you get to have a little more control over the codec selection, as I mention earlier in the lunch example. There generally is no reason to NOT use early offer, and there is no negative effect to using it. Same with early media using PRACK on 1XX messages which contain SDP. Though, a little less so with early media, because this could mess up your ringback tone, if your not sure of who and where the ringback comes from.

The voice class codec list should be in preference order, like this:

voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8
!

Keep in mind that this order cannot be enforced.

See this from the RFC on SDP offer/answer:

"For streams marked as sendrecv in the answer,
the "m=" line MUST contain at least one codec the answerer is willing
to both send and receive, from amongst those listed in the offer."

and

"The
media 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 offerer SHOULD use the format with the
highest preference from the answer."

and

"Although the answerer MAY list the formats in their desired order of
preference, it is RECOMMENDED that unless there is a specific reason,
the answerer list formats in the same relative order they were
present in the offer. In other words, if a stream in the offer lists
audio codecs 8, 22 and 48, in that order, and the answerer only
supports codecs 8 and 48, it is RECOMMENDED that, if the answerer has
no reason to change it, the ordering of codecs in the answer be 8,
48, and not 48, 8. This helps assure that the same codec is used in
both directions."

Link: https://tools.ietf.org/html/rfc3264

[_|brt.drml|_]

Dear Anthony,

Excuses me for the late answer!

I do want to thank you for that simple and clear reply. It will and is helping me in the investigation of how the Codec Offering works.

The base of the problem is that I want to avoid codec problems due to hardware issues. I noticed that some devices offer build in codecs or do not even speak some codecs (presumably with the reason of old hardware).

Taken that fact, I want to have a correct configuration of the Routers in order to avoid codec issues along the communication line. (different private end points not in my control)

Sincere,

Bart