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

Tue Jun 9 10:32:30 CDT 2020

Thanks for your response Torrey!

I do have a few comments below...

On Tue, Jun 9, 2020 at 2:08 AM Torrey Searle <tsearle at gmail.com> wrote:

> 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.   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.
>
> I think there are use cases in the HD Voice domain.  If Alice has HD voice
> in her offer, add HD Voice codecs to the offer sent to BOB.  Otherwise only
> send the narrow band codecs.  This is to avoid transcoding narrow band into
> wide band pointlessly. (The same would hold true for Video codecs)
>

I think narrow vs wideband is going to have to be an admin decision.  If he
or she wants to enable sending wideband codecs to Bob, then they should
include them in Bob's allow line.

>
> 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.  We'd just drop the frames.   If Bob wants to use a format
> not in the offer, he should RE-INVITE.
>
> I agree, I think this should be considered invalid and the frames dropped.
>
> 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.
>
> The deciding to use our order vis his order should be covered by the
> existing asymmetric_codecs flag shouldn't it?
>

Asymmetric codecs will be the subject of a forthcoming email :)

>
> 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?
> In the case of Video the answer to Alice needs to be filtered to only
> include the Video Codecs Bob as negotiated, otherwise the call will fail as
> asterisk cannot provide video transcoding.  Also more generally, if Alice's
> endpoint has video enabled, but Bob rejected video.  The answer to Alice
> should also reject video.
>

Agreed.

>
>
> On Wed, Jun 3, 2020 at 10:18 PM George Joseph <gjoseph at digium.com> 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.
>>
>> To give you some idea of just how difficult a job this is, a simple call
>> from Alice to Bob currently causes 8 attempts to reconcile codecs between
>> them in app_dial, chan_pjsip, res_pjsip_session and res_pjsip_sdp_rtp.  If
>> you've noticed a recent addition of a SCOPE_TRACE facility for Asterisk
>> being committed, this was the driver.  It was also very enlightening.  So
>> we're trying to simplify things a little.  Well, a lot.  We've got some
>> questions that we'd like answered with *real* use cases.
>>
>> 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?   Does whether we accept formats not on the endpoint need to be
>> configurable?   Don't just say "yes". :)   We need use cases.   We could
>> use the offer's list exclusively, use the endpoint's list exclusively,
>> merge the two together, or use only those in common.  What happens if after
>> applying that operation, there are no formats in common?  Drop the call?
>> Transocde? 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.   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.
>>
>> 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.  We'd just drop the frames.   If Bob wants to use a format
>> not in the offer, he should RE-INVITE.
>>
>> 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.  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.  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".
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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?
>>
>> 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 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.
>>
>> THANKS!
>>
>>
>> --
>> 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
>
> --
> _____________________________________________________________________
> -- 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/83c93582/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 4936 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20200609/83c93582/attachment-0002.png>
-------------- 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/83c93582/attachment-0003.png>