[asterisk-dev] Configuring multistream in chan_pjsip

Mark Michelson mmichelson at digium.com
Tue Jun 6 12:28:47 CDT 2017


On 06/05/2017 03:17 PM, Matt Fredrickson wrote:
> On Mon, Jun 5, 2017 at 2:31 PM, Joshua Colp <jcolp at digium.com> 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
>>>
>> <snip>
>>
>>> I propose the following configuration options to move forward.
>>>
>>> offered_audio_streams = 1
>>> offered_video_streams = 2
>> <snip>
>>
>> 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.




More information about the asterisk-dev mailing list