asterisk users - Jun 2020 - Advanced Codec Negotiation: Need info and uses cases

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
allowparameter.  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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20200605/6e76b50b/attachment.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-users/attachments/20200605/6e76b50b/attachment.png>

El Fri, 5 Jun 2020 09:42:33 -0600
George Joseph <gjoseph at digium.com> escribió:
> 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.
Hi Joseph


Thanks for such a detailed mail and involving the community. 


First of all, I'd have a transcoding=yes/no option to disable entirely
transcoding scenarios. That would make things easier for the scenarios you
describe. 

> 
> 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.
> 
In this case, I would only follow to Bob those codecs that Alice sends AND are
in the allow parameter. It's the most intuitive scenario. If after that
there
are no formats in common I'd transcode or not depending if the option is
enabled or not. If not just send a 488 back. 

> 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.

In this case I would do the following:

If transcoding is disabled I'd send Alice's list filtered by Alice's
allow,
filtered by Bob's allow. 

If transcoding is enabled Would it be possible to do the same but handle a 488
back from Bob and failover to another INVITE with Bob's allow list to handle
transcoding? That way we would always try no-transcoding before offering a
transcoding codec. 

Anyway, I'd never send an offer to Bob which is not in Bob's allow list.
That's
what allow is for.
> 
> 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 wouldn't accept a codec that wasn't offered and wasn't in the
allow param.
Agree with that. 
> 
> 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".
I wouldn't send a format not in her offer and in her allow.
> 
> 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?

I'd use the first codec sent by Bob. UAC offers in one order and UAS agrees
based on the offer, so we should trust Bob took into consideration Alice's
preferences. I'd try send to Alice the first codec received in Bob's
response
(case both can use it based on their capabilities and allow params).

> 
> 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.
To make it simple why not use the old format in case any of the channels is not
pjsip?


Alice not pjsip, no matter what Bob is --> don't do the advanced stuff.

Alice PJSIP and Bob is not: Construct Alice's response based on Bob's
answer as
talked above. I think if you send to the core Alice's list filtered by the
allow param shouldn't matter what kind of channel Bob will be until we
create
Bob's channel, right?

Alice and Bob are Pjsip both: No problem here. 


> 
> 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.
> 
Try to keep it simple. I'd have transcoding global enable/disable. Try to be
transparent with the codecs list and order and only filter by the allow
param IMHO.




-- 
PekePBX, the multitenant PBX solution
https://pekepbx.com

El Tue, 9 Jun 2020 09:46:32 -0600
George Joseph <gjoseph at digium.com> escribió:


Hi George
> 
> 
> >
> > If transcoding is enabled Would it be possible to do the same but
handle a
> > 488
> > back from Bob and failover to another INVITE with Bob's allow list
to
> > handle
> > transcoding? That way we would always try no-transcoding before
offering a
> > transcoding codec.
> >  
> 
> I think this is a good idea but might not be possible in the first release
> of Advanced Codecs.
> We'd also probably need an option to enable/disable retrying.
> 
> We might also be able to just handle this by taking Bob's allowed
codecs
> but sorting
> them so that any codecs that Bob and Alice share come at the front of the
> list
> in the offer to Bob.
> 
> 
In this scenario. For example if we have

[alice]
disallow=all
allow=alaw
allow=opus

[bob]
disallow=all
allow=opus
allow=alaw
allow=gsm


In case Alice sends an INVITE with opus and g723 in the sdp.

1: We remove g723 as it's not in Alice's allow

2: When we send the INVITE to Bob either we:

  2a: Send the invite only with opus to avoid transcoding. If Bob's phone
  doesn't support opus and sends 488 back I'd send another INVITE with
alaw and
  gsm to handle the call with transcoding.

  2b: We send the invite with opus, alaw and gsm and let Bob choose. In this
  case we don't try to avoid transcoding. 

  2c: We send invite with opus only and don't retry. I would do this only if
  transcoding is disabled by configuration. 

My preferred solution would be 2a/c based on a transcoding on/off configuration
option.

In your explanation transcoding is not done if you filter by the allowed codecs
of both + alice's INVITE. It could be possible to receive a 488 and without
retry we lose any transcoding capability.


right?


cheers,

Jon


-- 
PekePBX, the multitenant PBX solution
https://pekepbx.com