[asterisk-dev] Advanced Codec Negotiation: Need info and uses cases

Michael Maier m1278468 at mailbox.org
Sat Jun 6 01:20:47 CDT 2020


On June 03, 2020 at 22:17 George Joseph wrote:
> Greetings All,
> 
> We've been working hard on new codec negotiation stuff for Asterisk 18 and
> we've got some stuff to run by you.  It's a lot so please read carefully.

Thank you very much for your ongoing effort! I really appreciate it!
I additionally read this documentation here [1].
During writing down those lines I got the feeling how complicated could be ... .


Therefore there must be some basic principals on how to handle things. I tried to write them down as follows:

0. Asterisk is the only one which decides the codecs to be used on base of the allow list on each leg phone <-> Asterisk because I want to be sure about the codecs used on each leg
(because of existing network bandwidth restrictions e.g.)
1. The phone must support at least one of the codecs of the allow list. If not: drop the call
2. Bringing together the legs: the actually used codec list on each leg only contains the codecs supported by the respective device and which are allowed on the allow list on the
other hand.
3. At this point Asterisk decides: if there are common codecs on both legs -> use these / this. If there are no common codecs between two legs: transcode (Use case: don't prevent a
call as long as the codecs on each leg itself are allowed).
4. Each phone on each call leg may define its own codec order. But Asterisk finally has to decide, which side to prefer (-> switchable).
5. Basically, a phone mustn't advertise codecs it can't handle - if this can't be prevented, the codec has to be removed on the respective allow list of the line on Asterisk side.

[...]

> Simple use case, Alice to Bob, no direct media.
> 
> 1.  Under what conditions would we accept a format on an incoming offer
> from a UAC (Alice) that *wasn't* in the UAC's endpoint allow= parameter?

The use case of this consideration seems to me: How to handle broken configurations.

>   Does whether we accept formats not on the endpoint need to be
> configurable?   Don't just say "yes". :)

No. From my point of view it never ever is Asterisk's job to handle broken configurations. Simple example: Phone sends SDP offer codec a) and b) which are both not on the allow list
for this endpoint -> drop the call.

>   We need use cases.

Use case: It's not Asterisk's job to repair broken configurations. I must be sure that only allowed codecs are used on a defined port because of bandwidth restrictions e.g.

>   We could
> use the offer's list exclusively, use the endpoint's list exclusively,
> merge the two together, or use only those in common.

Asterisk finally defines which codec to use. Therefore all codecs of the phones offer have to be dropped which are not part of the allow list. Furthermore all codecs of the allow
list have to be dropped, which are not contained in the SDP offer of the device.

>  What happens if after
> applying that operation, there are no formats in common?  Drop the call?

Exactly. Because it's a result of misconfiguration. It's not Asterisk's job to repair broken configurations.

> Transocde? 

Transcoding only if there is an allowed and supported codec on both sides which are not common. If there is one common codec on both sides - use this codec and do not transcode.

> Using what format? It'd have to be one Alice accepts.  We'll
> save the process of transcoding for a follow-on discussion.
> 
> 2.  Under what conditions would we send a codec in an offer to a UAS (Bob)
> that *wasn't* in the UAS's endpoint allow= parameter.

Never! I must be sure about the codecs to be used on a line (bandwidth).

>   Similarly, under
> what conditions would we send a format to Bob that *was* in his endpoint
> allow= parameter but *wasn't* in the reconciled list we got from Alice via
> the core?  Same possible options and questions as above.

Asterisk just should send the codecs to Bob which are part of the allow list - nothing more. The order could be defined by the reconciled list we got from Alice. Always the same use
case: Asterisk defines which codec to use just to be sure that bandwidth requirements can be enforced (or other requirements)

> 
> 3.  OK now whatever we've decided to send to Bob, according to RFC3264 para
> 6.1, Bob MUST send back an answer that contains a common format OR reject
> the stream if there are no formats in common.  It doesn't say whether it's
> valid for Bob to send back formats we didn't request *in addition *to ones
> we did request.  It wouldn't make sense for him to do that because that
> same RFC and paragraph only says we MUST accept media in a format we sent.
> It doesn't mention what should happen if we get media in a format we
> *didn't* request.  Based on this, unless someone can give us a valid use
> case for this, and rules governing when it's acceptable and when it's not,
> we do NOT plan on supporting receiving media in a format we didn't
> request.

Yes.

>  We'd just drop the frames.

Correctly.

>   If Bob wants to use a format not in
> the offer, he should RE-INVITE.

Which would lead to a drop - remember: we don't allow any codec not on the allow list.

> 
> 4.  Now we've got Bob's answer and are passing it back to the core so we
> need to send an answer back to Alice.

All codecs not on Bob's allow list have to be removed. The order may be adopted.

>  First, unless someone can give us a
> valid use case, we will never send Alice a format she didn't request in her
> offer so those will get removed.

Correct. Furthermore, you mustn't send any format which is not part of Alice's allow list.

>  Based on options specified above though,
> the potential answer MAY contain formats NOT in Alice's endpoint allow=
> parameter.  Same options and questions as "1".

No - the answer mustn't contain any format not allowed in the allow list. It's the allow list which finally defines codecs to be used. I must count on the allow list!

> 
> Now let's talk about format preference order.
> 
> On the Alice to Bob side...
> 1.  On Alice's incoming leg, after reconciling Alice's offer and Alice's
> endpoint, we can sort by Alice's preferred order or Alice's endpoint's
> preferred order based on configuration and send that order to the core.

The order can be defined by the phone based on the allowed codecs. That's ok for me. It's just important to remove each codec which is not on the allow list.

> 2.  On Bob's outgoing leg, after reconciling what came from the core and
> Bob's endpoint, we can also sort based on either and send that in the offer.

Based on the fact, that only the allowed codecs are contained in the offer and furthermore based on the fact, that each phone must be able to handle the codecs it advertises /
accepts -> fine with me.

> 3.  Bob can re-order the formats in his answer so I guess we need another
> option to use the order we sent or the order we received before we send it
> back to the core.  Do we care about the order we got *from* the core or on
> Bob's endpoint any more?  Hopefully not.

No - keep the formats based on the received order - but remove the not allowed codecs.

> 4.  Now we've got a list from the core and we need to send an answer back
> to Alice...  Do we need any sort alterations at all here or can we just use
> what came from the core?

Goal is to find a codec supported by both just to prevent transcoding. Therefore use the first codec based on the order of the initial call of Alice. If there is no common codec ->
transcode between the first codec in the list on both lines.

> One more thing to consider...   Alice and Bob may *not* both be using a
> pjsip channel.  In this case, the process can only be applied on the call
> leg that *is* pjsip.  Let's say that Alice's leg is pjsip and Bob's isn't.
> We can make Alice's channel aware that Bob isn't capable of the advanced
> codec process but only after Bob's channel has been created so the process
> Alice runs when passing the list to the core won't know.  The process that
> runs when constructing Alice's answer *will* know by virtue of *not getting
> anything* from the core because today there's no feedback at all from the
> core.   On the flip side, if Alice is chan_sip and Bob is chan_pjsip, Bob
> *will* know whether what came from the core is "advanced" or not.   Now the
> question is, given all that's talked about above, do the rules change
> depending on whether both channels are pjsip or not?  Of course, if
> *neither* is pjsip, none of the above applies and the old process is used.

I would say: The new process can be used only if all call legs are ruled by pjsip. If one call leg is not ruled by pjsip -> use the traditional process.

> 
> I know this is a lot to take in but I'd implore you to read thoroughly,
> respond with real life scenarios and ask questions if something isn't
> clear.   We are NOT going to shove this into 18 without everyone
> understanding the implications, and if the process gets too complex, we'll
> NEVER put it in because it'll work no better and be no better understood
> than the current process.

Well, there must be principles as written above. If those are kept, I can't see any problem at the moment - it seems to me pretty simple.


Some examples:

1) Drop call
Alice: g722/g711

Asterisk allow: g729

=> all calls from and to Alice will be dropped. It's just a misconfiguration -> admins fault. It's not the job of asterisk to repair it.


2) Prevent transcoding
Alice: g722/g711

------------------------------------
Asterisk Alice allow: g729/g711/g722

Asterisk Bob allow: g722/g711/g726
------------------------------------

Bob: gsm/g729/g711/g722

Alice calls Bob:
- Asterisk drops g729 on the possible list of used codecs for this call leg based on the offer of Alice.
- Asterisk sends to Bob: g722/g711/g726 (it's always Bobs allow list based on the order of Alice's offer)

- Bob sends to Asterisk: gsm/g729/g711/g722 - Asterisk drops gsm and g729 (because not on the allow list). g711/g722 is given to the core to compare and find the chosen codec: Result
will be: g722 (based on the order of the incoming call leg g722/g711). If you would have preferred the outgoing call leg, the resulting common codec would have been g711.


3) Transcoding example
Alice: g729

------------------------------------
Asterisk Alice allow: g722/g711/g729

Asterisk Bob allow: g722/g711
------------------------------------

Bob: gsm/g729/g711/g722

Alice calls Bob:
- Asterisk drops g711/g729 on the possible list of used codecs for this call leg based on the offer of Alice.
- Asterisk sends to Bob: g722/g711 (it's always Bobs allow list based on the order of Alice's offer - if possible :-))
- Bob sends to Asterisk: gsm/g729/g711/g722 - Asterisk drops gsm and g729 (because not on the allow list). g711/g722 is given to the core to compare and find the chosen codec: In
this case, the call is transcoded between g729 and g711 (because there is no common codec between both call legs and transcoding usually is better than dropping - but this decision
may be switchable).


Hope this helps!


Thanks
Kind regards
Michael


[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Codec+Negotiation+Proposal



More information about the asterisk-dev mailing list