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

Tue Jun 9 09:51:35 CDT 2020

Thanks for your response Michael!

I'm going to top-post because this is a long thread and I just wanted to
say that we pretty much agree with the behaviors you've outlined and, in
fact, those will probably be the default behaviors.  I also like the
"principles"  you noted and will expand on those in a future email.

On Sat, Jun 6, 2020 at 12:21 AM Michael Maier <m1278468 at mailbox.org> wrote:

> 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
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev

-- 
George Joseph
Asterisk Software Developer
direct/fax +1 256 428 6012
Check us out at www.sangoma.com and www.asterisk.org
[image: image.png]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20200609/049b2035/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5142 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20200609/049b2035/attachment-0001.png>