Re: [asterisk-dev] Asterisk 18 Planning: Codec Negotiation
On Fri, Jan 31, 2020 at 1:06 AM Michael Maier wrote:
> On 30.01.20 at 23:20 Kevin Harwell wrote:
> ...
> > No worries it's my bad. I can see how what I wrote was ambiguous. What I
> > meant was "if *either* remote *or* local is chosen". As in it doesn't
> > matter which option value you choose. Either one would result (in this
> > example) in opus not being included in list 2.
>
> Hmm, that's how I understood it - but I still can't see any possibility
> to not provide either remote or local value. Therefore I can't see any
> possibility to ever get opus in your given example above to the
> resulting list 2. But that would be ok anyway, because I don't ever want
> to have opus in the list in this specific case.
>
That's correct. A local or remote value, or some derivative of them
(_single/_limit), will always be specified. And opus will never be included
in list 2.
>
> Could you please tell me, how outgoing_sdp_send_prefs can be used
> *without* any active "value" (like local, local_limit, local_single,
> remote, remote_limit, remote_single) as long as *remote* is
> automatically used ("default") according documentation if no other value
> is provided? This would be the same for all other lists, too.
>
>
> From documentation:
> --
> remote - Order by what is optionally given by a "caller". Note, the
> resulting list will contain those codecs specified by Bob's
> configuration, which are not found also in the given remote list, as
> least preferred. Meaning they will be at the end, or bottom of the list
> (*default*)
> --
>
>
For any of the options a value can be specified by the user (e.g. local,
remote, local_single, etc...). If no value is specified then the default
value for that option is used. From the code's perspective there will never
be a case for outgoing_sdp_send_prefs, or any of the other options, where
one of its legal values is not always set for it. Either specified by the
user in the configuration, or using it uses the default.
So for example in the case of outgoing_sdp_send_prefs there is no way it
can be used *without* any active "value". It's impossible. Within the
code outgoing_sdp_send_prefs will always be set to one of its values.
--
Kevin Harwell
Senior Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://asterisk.org
--
_
-- 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
Re: [asterisk-dev] Asterisk 18 Planning: Codec Negotiation
On 30.01.20 at 23:20 Kevin Harwell wrote:
> On Thu, Jan 30, 2020 at 3:01 PM Michael Maier wrote:
>
>> .
2. outgoing_sdp_send_prefs
The list can be created on base of the callees
allow line and list 1 (option local ...).
Or:
The list can be created on base of list 1
(option remote ...) and the callees allow line.
Both lists may have a different codec order or
different codecs (if *_single is provided).
Codecs not given in the callees allow line or
list 1 are dropped (*_limit).
>>> This is mostly correct, but for clarification selecting the "remote" or
>>> "local" value will always only contain those codecs from the endpoint
>>> configuration allow line. Or another way to say it is the resulting list
>> is
>>> the intersection of the two lists (list 1 and allow=) plus the codecs in
>>> the allow line that are not in list 1. The order will change depending on
>>> which value is used.
>>>
>>> This means that if list 1 contains a codec not found in the endpoints
>>> allow= line then that codec will not be included in the resulting list.
>> For
>>> example;
>>>
>>> list 1 = opus,ulaw,alaw
>>> allow= ulaw, alaw, g722
>>>
>>> Then if "remote" or "local" is chosen then the resulting list will never
>>> have opus in it.
>>
>> Sorry, I don't understand at the moment, how it is possible to *not*
>> choose "remote" or "local". According to your documentation, "remote" is
>> the default if you don't provide any option to outgoing_sdp_send_prefs.
>> Maybe I missunderstood some more ... .
>>
>
> No worries it's my bad. I can see how what I wrote was ambiguous. What I
> meant was "if *either* remote *or* local is chosen". As in it doesn't
> matter which option value you choose. Either one would result (in this
> example) in opus not being included in list 2.
Hmm, that's how I understood it - but I still can't see any possibility
to not provide either remote or local value. Therefore I can't see any
possibility to ever get opus in your given example above to the
resulting list 2. But that would be ok anyway, because I don't ever want
to have opus in the list in this specific case.
Could you please tell me, how outgoing_sdp_send_prefs can be used
*without* any active "value" (like local, local_limit, local_single,
remote, remote_limit, remote_single) as long as *remote* is
automatically used ("default") according documentation if no other value
is provided? This would be the same for all other lists, too.
From documentation:
--
remote - Order by what is optionally given by a "caller". Note, the
resulting list will contain those codecs specified by Bob's
configuration, which are not found also in the given remote list, as
least preferred. Meaning they will be at the end, or bottom of the list
(*default*)
--
Thanks
Michael
--
_
-- 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
Re: [asterisk-dev] Asterisk 18 Planning: Codec Negotiation
On Thu, Jan 30, 2020 at 3:01 PM Michael Maier wrote: > . > >> 2. outgoing_sdp_send_prefs > >>The list can be created on base of the callees > >>allow line and list 1 (option local ...). > >> > >>Or: > >> > >>The list can be created on base of list 1 > >>(option remote ...) and the callees allow line. > >> > >>Both lists may have a different codec order or > >>different codecs (if *_single is provided). > >> > >>Codecs not given in the callees allow line or > >>list 1 are dropped (*_limit). > >> > >> > > This is mostly correct, but for clarification selecting the "remote" or > > "local" value will always only contain those codecs from the endpoint > > configuration allow line. Or another way to say it is the resulting list > is > > the intersection of the two lists (list 1 and allow=) plus the codecs in > > the allow line that are not in list 1. The order will change depending on > > which value is used. > > > > This means that if list 1 contains a codec not found in the endpoints > > allow= line then that codec will not be included in the resulting list. > For > > example; > > > > list 1 = opus,ulaw,alaw > > allow= ulaw, alaw, g722 > > > > Then if "remote" or "local" is chosen then the resulting list will never > > have opus in it. > > Sorry, I don't understand at the moment, how it is possible to *not* > choose "remote" or "local". According to your documentation, "remote" is > the default if you don't provide any option to outgoing_sdp_send_prefs. > Maybe I missunderstood some more ... . > No worries it's my bad. I can see how what I wrote was ambiguous. What I meant was "if *either* remote *or* local is chosen". As in it doesn't matter which option value you choose. Either one would result (in this example) in opus not being included in list 2. -- Kevin Harwell Senior Software Developer Sangoma Technologies Check us out at: https://sangoma.com & https://asterisk.org -- _ -- 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
Re: [asterisk-dev] Asterisk 18 Planning: Codec Negotiation
Hello Kevin, thanks for your clarification. Anyway, I think I don't understand it completely right now. Please see question below. Thanks Michael On 30.01.20 at 16:49 Kevin Harwell wrote: > On Thu, Jan 30, 2020 at 4:55 AM Michael Maier wrote: > >> >> >> Could the planned codec handling globally described like this: >> >> > Overall I think you have the gist of it. See below, though, for a couple of > clarifications. > > >> >> The codec handling is based on 4 lists. >> >> 1. incoming_sdp_receive_prefs >>This list is created based on the allow line >>of the callers extension and the SDP offer of >>the phone (local ...). >> >>Or: >> >>This list is created based on the SDP offer of >>the caller and the allow line of the extension >>(remote). >> >>Codecs not given in the callers allow line are >>dropped. Both list variants may have a >>different codec order. >> >> >> 2. outgoing_sdp_send_prefs >>The list can be created on base of the callees >>allow line and list 1 (option local ...). >> >>Or: >> >>The list can be created on base of list 1 >>(option remote ...) and the callees allow line. >> >>Both lists may have a different codec order or >>different codecs (if *_single is provided). >> >>Codecs not given in the callees allow line or >>list 1 are dropped (*_limit). >> >> > This is mostly correct, but for clarification selecting the "remote" or > "local" value will always only contain those codecs from the endpoint > configuration allow line. Or another way to say it is the resulting list is > the intersection of the two lists (list 1 and allow=) plus the codecs in > the allow line that are not in list 1. The order will change depending on > which value is used. > > This means that if list 1 contains a codec not found in the endpoints > allow= line then that codec will not be included in the resulting list. For > example; > > list 1 = opus,ulaw,alaw > allow= ulaw, alaw, g722 > > Then if "remote" or "local" is chosen then the resulting list will never > have opus in it. Sorry, I don't understand at the moment, how it is possible to *not* choose "remote" or "local". According to your documentation, "remote" is the default if you don't provide any option to outgoing_sdp_send_prefs. Maybe I missunderstood some more ... . > Unless for some reason folks think it would make sense to > make an offer to a device containing codec(s) that were not part of its > Asterisk endpoint configuration definition. > > >> >> 3. outgoing_sdp_receive_prefs >>The list is created based on the received SDP >>and list 2 (remote ...). >> >>Or: >> >>The list is based on list 2 and the received >>SDP. >> >>These list variants may provide different codec >>orders or different codecs (if *_single is >>provided). >> >>This list only contains codecs which can be >>found in the received SDP and in list 2 at the >>same time. >> >> >> 4. incoming_sdp_send_prefs >>This list is created based on list 3 and 1 >>(remote ...) >> >>Or >> >>the list is based on 1 and 3 (local ...). >> >>The Codec order may differ between those >>variants. >> >>This list only contains codecs which can be >>found in list 3 and 1 at the same time >>(*_limit). >> >> > Again this is mostly the case, but pretty much the same description from > above applies here too, i.e. the resulting list will never have codecs in > it that were not part of list 1. -- _ -- 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
Re: [asterisk-dev] Asterisk 18 Planning: Codec Negotiation
On Thu, Jan 30, 2020 at 4:55 AM Michael Maier wrote: > > > Could the planned codec handling globally described like this: > > Overall I think you have the gist of it. See below, though, for a couple of clarifications. > > The codec handling is based on 4 lists. > > 1. incoming_sdp_receive_prefs >This list is created based on the allow line >of the callers extension and the SDP offer of >the phone (local ...). > >Or: > >This list is created based on the SDP offer of >the caller and the allow line of the extension >(remote). > >Codecs not given in the callers allow line are >dropped. Both list variants may have a >different codec order. > > > 2. outgoing_sdp_send_prefs >The list can be created on base of the callees >allow line and list 1 (option local ...). > >Or: > >The list can be created on base of list 1 >(option remote ...) and the callees allow line. > >Both lists may have a different codec order or >different codecs (if *_single is provided). > >Codecs not given in the callees allow line or >list 1 are dropped (*_limit). > > This is mostly correct, but for clarification selecting the "remote" or "local" value will always only contain those codecs from the endpoint configuration allow line. Or another way to say it is the resulting list is the intersection of the two lists (list 1 and allow=) plus the codecs in the allow line that are not in list 1. The order will change depending on which value is used. This means that if list 1 contains a codec not found in the endpoints allow= line then that codec will not be included in the resulting list. For example; list 1 = opus,ulaw,alaw allow= ulaw, alaw, g722 Then if "remote" or "local" is chosen then the resulting list will never have opus in it. Unless for some reason folks think it would make sense to make an offer to a device containing codec(s) that were not part of its Asterisk endpoint configuration definition. > > 3. outgoing_sdp_receive_prefs >The list is created based on the received SDP >and list 2 (remote ...). > >Or: > >The list is based on list 2 and the received >SDP. > >These list variants may provide different codec >orders or different codecs (if *_single is >provided). > >This list only contains codecs which can be >found in the received SDP and in list 2 at the >same time. > > > 4. incoming_sdp_send_prefs >This list is created based on list 3 and 1 >(remote ...) > >Or > >the list is based on 1 and 3 (local ...). > >The Codec order may differ between those >variants. > >This list only contains codecs which can be >found in list 3 and 1 at the same time >(*_limit). > > Again this is mostly the case, but pretty much the same description from above applies here too, i.e. the resulting list will never have codecs in it that were not part of list 1. -- Kevin Harwell Senior Software Developer Sangoma Technologies Check us out at: https://sangoma.com & https://asterisk.org -- _ -- 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
Re: [asterisk-dev] Asterisk 18 Planning: Codec Negotiation
On 29.01.20 at 22:44 Kevin Harwell wrote: > Ugh I used the wrong keyboard shortcuts and the message sent before I was > done. Below is the rest :-) > > On Wed, Jan 29, 2020 at 3:42 PM Kevin Harwell wrote: > >> On Wed, Jan 29, 2020 at 3:12 PM Michael Maier >> wrote: >> >>> >>> >> >>> >>> >>> From my point of view, it should always be possible to prevent >>> transcoding as long as there is one codec which can be used on both >>> sides. If there is more than one codec equal on both sides, it's good to >>> have the possibility by your planned options if the local or the remote >>> most preferred codec should be used. >>> >>> Default configuration for me would be like that: >>> incoming_sdp_receive_prefs=local >>> outgoing_sdp_send_prefs=remote >>> outgoing_sdp_receive_prefs=local >>> incoming_sdp_send_prefs=local >>> transcode=avoid >>> >>> From my understanding, this should avoid any unnecessary transcoding as >>> long as there's just one common codec on both sides and should always >>> prefer the codecs desired by the caller. >>> >>> Did I got this correctly? >>> >> >> We're still working through the idea of the "transcode" option, and how it >> might work in practice. But what you have is the general idea. To better >> avoid it, in the setup you have above I'd probably modify the following: >> > > incoming_sdp_send_prefs=remote > > This would send in the answer to Alice the exact order preferred by Bob. If > Alice accepts then Asterisk should never transcode. Thanks! That's true. Probably even better remote_limit (even for outgoing_sdp_send_prefs). Could the planned codec handling globally described like this: The codec handling is based on 4 lists. 1. incoming_sdp_receive_prefs This list is created based on the allow line of the callers extension and the SDP offer of the phone (local ...). Or: This list is created based on the SDP offer of the caller and the allow line of the extension (remote). Codecs not given in the callers allow line are dropped. Both list variants may have a different codec order. 2. outgoing_sdp_send_prefs The list can be created on base of the callees allow line and list 1 (option local ...). Or: The list can be created on base of list 1 (option remote ...) and the callees allow line. Both lists may have a different codec order or different codecs (if *_single is provided). Codecs not given in the callees allow line or list 1 are dropped (*_limit). 3. outgoing_sdp_receive_prefs The list is created based on the received SDP and list 2 (remote ...). Or: The list is based on list 2 and the received SDP. These list variants may provide different codec orders or different codecs (if *_single is provided). This list only contains codecs which can be found in the received SDP and in list 2 at the same time. 4. incoming_sdp_send_prefs This list is created based on list 3 and 1 (remote ...) Or the list is based on 1 and 3 (local ...). The Codec order may differ between those variants. This list only contains codecs which can be found in list 3 and 1 at the same time (*_limit). Thanks Michael -- _ -- 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
Re: [asterisk-dev] Asterisk 18 Planning: Codec Negotiation
Ugh I used the wrong keyboard shortcuts and the message sent before I was done. Below is the rest :-) On Wed, Jan 29, 2020 at 3:42 PM Kevin Harwell wrote: > On Wed, Jan 29, 2020 at 3:12 PM Michael Maier > wrote: > >> >> > >> >> >> From my point of view, it should always be possible to prevent >> transcoding as long as there is one codec which can be used on both >> sides. If there is more than one codec equal on both sides, it's good to >> have the possibility by your planned options if the local or the remote >> most preferred codec should be used. >> >> Default configuration for me would be like that: >> incoming_sdp_receive_prefs=local >> outgoing_sdp_send_prefs=remote >> outgoing_sdp_receive_prefs=local >> incoming_sdp_send_prefs=local >> transcode=avoid >> >> From my understanding, this should avoid any unnecessary transcoding as >> long as there's just one common codec on both sides and should always >> prefer the codecs desired by the caller. >> >> Did I got this correctly? >> > > We're still working through the idea of the "transcode" option, and how it > might work in practice. But what you have is the general idea. To better > avoid it, in the setup you have above I'd probably modify the following: > incoming_sdp_send_prefs=remote This would send in the answer to Alice the exact order preferred by Bob. If Alice accepts then Asterisk should never transcode. -- Kevin Harwell Senior Software Developer Sangoma Technologies Check us out at: https://sangoma.com & https://asterisk.org -- _ -- 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
Re: [asterisk-dev] Asterisk 18 Planning: Codec Negotiation
On Wed, Jan 29, 2020 at 5:12 PM Michael Maier wrote: > Hello Kevin, > > On 29.01.20 at 20:22 Kevin Harwell wrote: > > Greetings! > > > > Over the years there have been numerous requests to improve the codec > > negotiation process in Asterisk. Specifically, regarding what codecs are > > offered, in what order, how Asterisk chooses which codec(s) to use, and > of > > course how transcoding is affected by that. > > I'm really happy to hear that you are going to improve the codec > handling! Thanks for that! > > > Well hopefully that wait will soon be over. Currently we have plans to > work > > on this for Asterisk 18. > > Will Asterisk 18 be a LTS version? 18 will be an LTS, and thanks to previous work done such as for streams some of the groundwork for this functionality already exists. I personally expect much of the work to be done within the PJSIP modules leveraging what we already have. -- Joshua C. Colp Asterisk Technical Lead Sangoma Technologies Check us out at www.sangoma.com and www.asterisk.org -- _ -- 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
Re: [asterisk-dev] Asterisk 18 Planning: Codec Negotiation
On Wed, Jan 29, 2020 at 3:12 PM Michael Maier wrote: > > > Will Asterisk 18 be a LTS version? > I'll defer the answer to that question to others :-) > > > From my point of view, it should always be possible to prevent > transcoding as long as there is one codec which can be used on both > sides. If there is more than one codec equal on both sides, it's good to > have the possibility by your planned options if the local or the remote > most preferred codec should be used. > > Default configuration for me would be like that: > incoming_sdp_receive_prefs=local > outgoing_sdp_send_prefs=remote > outgoing_sdp_receive_prefs=local > incoming_sdp_send_prefs=local > transcode=avoid > > From my understanding, this should avoid any unnecessary transcoding as > long as there's just one common codec on both sides and should always > prefer the codecs desired by the caller. > > Did I got this correctly? > We're still working through the idea of the "transcode" option, and how it might work in practice. But what you have is the general idea. To better avoid it in the setup you have above I'd probably modify the following: -- Kevin Harwell Senior Software Developer Sangoma Technologies Check us out at: https://sangoma.com & https://asterisk.org -- _ -- 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
Re: [asterisk-dev] Asterisk 18 Planning: Codec Negotiation
Hello Kevin, On 29.01.20 at 20:22 Kevin Harwell wrote: > Greetings! > > Over the years there have been numerous requests to improve the codec > negotiation process in Asterisk. Specifically, regarding what codecs are > offered, in what order, how Asterisk chooses which codec(s) to use, and of > course how transcoding is affected by that. I'm really happy to hear that you are going to improve the codec handling! Thanks for that! > Well hopefully that wait will soon be over. Currently we have plans to work > on this for Asterisk 18. Will Asterisk 18 be a LTS version? > The bulk of that work will be around the addition > of new chan_pjsip options that will allow a user to better control codec > offerings, and order. > > I've added a page to the wiki [1] beneath the Asterisk 18 roadmap page that > explains what those options are (along with a couple current codec related > ones), and how they will work. Please, if you have any interest in this > topic read through that page and let us know what you think, or how things > can be improved. > > [1] https://wiki.asterisk.org/wiki/display/AST/Codec+Negotiation From my point of view, it should always be possible to prevent transcoding as long as there is one codec which can be used on both sides. If there is more than one codec equal on both sides, it's good to have the possibility by your planned options if the local or the remote most preferred codec should be used. Default configuration for me would be like that: incoming_sdp_receive_prefs=local outgoing_sdp_send_prefs=remote outgoing_sdp_receive_prefs=local incoming_sdp_send_prefs=local transcode=avoid From my understanding, this should avoid any unnecessary transcoding as long as there's just one common codec on both sides and should always prefer the codecs desired by the caller. Did I got this correctly? Thanks Michael -- _ -- 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
[asterisk-dev] Asterisk 18 Planning: Codec Negotiation
Greetings! Over the years there have been numerous requests to improve the codec negotiation process in Asterisk. Specifically, regarding what codecs are offered, in what order, how Asterisk chooses which codec(s) to use, and of course how transcoding is affected by that. Well hopefully that wait will soon be over. Currently we have plans to work on this for Asterisk 18. The bulk of that work will be around the addition of new chan_pjsip options that will allow a user to better control codec offerings, and order. I've added a page to the wiki [1] beneath the Asterisk 18 roadmap page that explains what those options are (along with a couple current codec related ones), and how they will work. Please, if you have any interest in this topic read through that page and let us know what you think, or how things can be improved. [1] https://wiki.asterisk.org/wiki/display/AST/Codec+Negotiation Thanks! -- Kevin Harwell Senior Software Developer Sangoma Technologies Check us out at: https://sangoma.com & https://asterisk.org -- _ -- 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
