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 <m1278...@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]
-- _____________________________________________________________________ -- 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