Re: [asterisk-dev] Configuring multistream in chan_pjsip

2017-06-06 Thread Dan Jenkins 
On Tue, Jun 6, 2017 at 6:28 PM, Mark Michelson 
wrote:

> On 06/05/2017 03:17 PM, Matt Fredrickson wrote:
>
>> On Mon, Jun 5, 2017 at 2:31 PM, Joshua Colp  wrote:
>>
>>> On Mon, Jun 5, 2017, at 04:21 PM, Mark Michelson wrote:
>>>
 Hi folks,

 For those of you following along at home, I recently published review
 https://gerrit.asterisk.org/#/c/5760/ , which is step one towards
 making
 chan_pjsip multistream, i.e. supporting more than one stream of a given
 media type. This initial review does not actually introduce multistream
 support so much as it just makes use of multistream structures under the
 hood to ease the transition.

 Continuing on, one of the next steps we need to determine is how a user
 of chan_pjsip should configure a channel that supports multiple streams
 of a particular type.

 To refresh everyone on how things currently work in pjsip.conf, you set
 an "allow" option in order to determine what codecs a particular
 endpoint supports.

 [Alice]
 type = endpoint
 allow = ulaw,opus,h264

 
>>>
>>> I propose the following configuration options to move forward.

 offered_audio_streams = 1
 offered_video_streams = 2

>>> 
>>>
>>> My only question is why, in a scenario where we don't have a hint, would
>>> we want to make the number of offered streams configurable by the user?
>>> Ultimately it's up to the application that is handling the channel to
>>> decide what it wants and that is decided in the moment, not ahead of
>>> time based on configuration.
>>>
>>> I think maximum and minimum are useful for enforcing some constraints
>>> though.
>>>
>> That echoes my thoughts as well.  +1 to not having the
>> "offered_audio/video_streams" options, but I'm ok with the limiting of
>> maximum stream count for now.
>>
>> Cool. I'm all for having fewer options. Sounds like if a user wants a
> certain number of streams to be offered during origination, that should be
> a parameter for the origination, then.
>
>
>
> --
> _
> -- 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
>


Agree with the above :)
-- 
_
-- 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] Configuring multistream in chan_pjsip

2017-06-06 Thread Mark Michelson 

On 06/05/2017 03:17 PM, Matt Fredrickson wrote:

On Mon, Jun 5, 2017 at 2:31 PM, Joshua Colp  wrote:

On Mon, Jun 5, 2017, at 04:21 PM, Mark Michelson wrote:

Hi folks,

For those of you following along at home, I recently published review
https://gerrit.asterisk.org/#/c/5760/ , which is step one towards making
chan_pjsip multistream, i.e. supporting more than one stream of a given
media type. This initial review does not actually introduce multistream
support so much as it just makes use of multistream structures under the
hood to ease the transition.

Continuing on, one of the next steps we need to determine is how a user
of chan_pjsip should configure a channel that supports multiple streams
of a particular type.

To refresh everyone on how things currently work in pjsip.conf, you set
an "allow" option in order to determine what codecs a particular
endpoint supports.

[Alice]
type = endpoint
allow = ulaw,opus,h264





I propose the following configuration options to move forward.

offered_audio_streams = 1
offered_video_streams = 2



My only question is why, in a scenario where we don't have a hint, would
we want to make the number of offered streams configurable by the user?
Ultimately it's up to the application that is handling the channel to
decide what it wants and that is decided in the moment, not ahead of
time based on configuration.

I think maximum and minimum are useful for enforcing some constraints
though.

That echoes my thoughts as well.  +1 to not having the
"offered_audio/video_streams" options, but I'm ok with the limiting of
maximum stream count for now.

Cool. I'm all for having fewer options. Sounds like if a user wants a 
certain number of streams to be offered during origination, that should 
be a parameter for the origination, then.



--
_
-- 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] Configuring multistream in chan_pjsip

2017-06-05 Thread Matt Fredrickson 
On Mon, Jun 5, 2017 at 2:31 PM, Joshua Colp  wrote:
> On Mon, Jun 5, 2017, at 04:21 PM, Mark Michelson wrote:
>> Hi folks,
>>
>> For those of you following along at home, I recently published review
>> https://gerrit.asterisk.org/#/c/5760/ , which is step one towards making
>> chan_pjsip multistream, i.e. supporting more than one stream of a given
>> media type. This initial review does not actually introduce multistream
>> support so much as it just makes use of multistream structures under the
>> hood to ease the transition.
>>
>> Continuing on, one of the next steps we need to determine is how a user
>> of chan_pjsip should configure a channel that supports multiple streams
>> of a particular type.
>>
>> To refresh everyone on how things currently work in pjsip.conf, you set
>> an "allow" option in order to determine what codecs a particular
>> endpoint supports.
>>
>> [Alice]
>> type = endpoint
>> allow = ulaw,opus,h264
>>
>
> 
>
>>
>> I propose the following configuration options to move forward.
>>
>> offered_audio_streams = 1
>> offered_video_streams = 2
>
> 
>
> My only question is why, in a scenario where we don't have a hint, would
> we want to make the number of offered streams configurable by the user?
> Ultimately it's up to the application that is handling the channel to
> decide what it wants and that is decided in the moment, not ahead of
> time based on configuration.
>
> I think maximum and minimum are useful for enforcing some constraints
> though.

That echoes my thoughts as well.  +1 to not having the
"offered_audio/video_streams" options, but I'm ok with the limiting of
maximum stream count for now.

-- 
Matthew Fredrickson
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA

-- 
_
-- 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] Configuring multistream in chan_pjsip

2017-06-05 Thread Joshua Colp 
On Mon, Jun 5, 2017, at 04:21 PM, Mark Michelson wrote:
> Hi folks,
> 
> For those of you following along at home, I recently published review 
> https://gerrit.asterisk.org/#/c/5760/ , which is step one towards making 
> chan_pjsip multistream, i.e. supporting more than one stream of a given 
> media type. This initial review does not actually introduce multistream 
> support so much as it just makes use of multistream structures under the 
> hood to ease the transition.
> 
> Continuing on, one of the next steps we need to determine is how a user 
> of chan_pjsip should configure a channel that supports multiple streams 
> of a particular type.
> 
> To refresh everyone on how things currently work in pjsip.conf, you set 
> an "allow" option in order to determine what codecs a particular 
> endpoint supports.
> 
> [Alice]
> type = endpoint
> allow = ulaw,opus,h264
> 



> 
> I propose the following configuration options to move forward.
> 
> offered_audio_streams = 1
> offered_video_streams = 2



My only question is why, in a scenario where we don't have a hint, would
we want to make the number of offered streams configurable by the user?
Ultimately it's up to the application that is handling the channel to
decide what it wants and that is decided in the moment, not ahead of
time based on configuration.

I think maximum and minimum are useful for enforcing some constraints
though.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & 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

[asterisk-dev] Configuring multistream in chan_pjsip

2017-06-05 Thread Mark Michelson 

Hi folks,

For those of you following along at home, I recently published review 
https://gerrit.asterisk.org/#/c/5760/ , which is step one towards making 
chan_pjsip multistream, i.e. supporting more than one stream of a given 
media type. This initial review does not actually introduce multistream 
support so much as it just makes use of multistream structures under the 
hood to ease the transition.


Continuing on, one of the next steps we need to determine is how a user 
of chan_pjsip should configure a channel that supports multiple streams 
of a particular type.


To refresh everyone on how things currently work in pjsip.conf, you set 
an "allow" option in order to determine what codecs a particular 
endpoint supports.


[Alice]
type = endpoint
allow = ulaw,opus,h264

In the above example, the endpoint "Alice" supports the ulaw and opus 
audio codecs and the H.264 video codec. Given that information, when 
Asterisk creates an offer to Alice, Asterisk may offer at most one audio 
stream and one video stream. Most commonly, the determination of what to 
offer is based on whatever incoming call results in the call to Alice. 
So if Bob called in and only offered audio, then Asterisk would offer 
one audio stream to Alice and no video (even though Alice is configured 
to allow video). If Carol called in and offered both audio and video, 
then Asterisk would offer one audio stream and one video stream on the 
resulting outgoing call to Alice.


Consider now that Alice is an endpoint that is capable of supporting 
more than one audio or video stream. For instance, Alice may be a 
browser that can support multiple video streams being displayed at once. 
The above configuration does not convey Alice's capabilities clearly. 
Asterisk has no way of knowing how many streams Alice would prefer to 
have offered to her, and Asterisk has no idea what Alice's limitations 
are with regards to number of streams.



I propose the following configuration options to move forward.

offered_audio_streams = 1
offered_video_streams = 2

The offered_audio_streams and offered_video_streams options will 
determine how many streams Asterisk will offer to Alice when no other 
hints are available to dictate how many streams to offer. This would be 
used most commonly when originating a call to Alice from Asterisk. With 
the options specified above, Asterisk would offer one audio stream and 
two video streams when originating a call to Alice. This option would 
not be consulted if the outgoing call to Alice were the result of an 
incoming call from someone else. For instance, an incoming call from 
Carol might offer only one audio and one video stream. In that case, 
Asterisk would mirror Carol's capabilities by only offering one audio 
and one video stream in the outgoing call to Alice. To maintain behavior 
of previous versions of Asterisk, the default value for both options 
would be 1.



max_audio_streams = 1
max_video_streams = 5

The max_audio_streams and max_video_streams options will determine the 
maximum number of streams Asterisk may offer to Alice. This option would 
come into play most commonly because an application (such as ConfBridge) 
may wish to expand the number of video streams configured on an endpoint 
further and further. The option would also come into play on basic 
one-to-one calls. These options would make it so that Asterisk would not 
attempt to offer an "unreasonable" number of streams to a particular 
endpoint. Say that Bob calls into Asterisk on some crazy device that 
offers three audio streams and six video streams. Given the options 
specified above, Asterisk would only offer one audio stream and five 
video streams to Alice. The rest of Bob's offered streams would be 
rejected. To maintain behavior of previous Asterisk versions, the 
default value for both options would be 1.



minimum_audio_streams = 1
minimum_video_streams = 0

This determines the minimum number of audio and video streams that must 
be present before Asterisk will attempt a call to Alice. Let's say that 
Bob calls Alice and offers one audio and one video stream. The audio 
stream is compatible with Alice's audio codecs, but the video codecs 
offered are not compatible with Alice's video. The result is that 
Asterisk is only capable of offering one audio stream to Alice and no 
video. Should Asterisk attempt to call Alice? According to the 
configuration above, yes. If Alice had configured the 
minimum_video_streams to be 1 instead of 0, though, Asterisk would have 
rejected the incoming call from Bob instead. To maintain compatibility 
with previous versions of Asterisk, the default values for these options 
would be 1 for minimum_audio_streams and 0 for minimum_video_streams.



With these options, Asterisk can reasonably have multistream support for 
PJSIP channels. Configuration from previous Asterisk versions would 
continue to work and behave the same after an upgrade. The only 
potential downside I see is that if you