On Tue, Jun 6, 2017 at 6:28 PM, Mark Michelson <mmichel...@digium.com> wrote:
> On 06/05/2017 03:17 PM, Matt Fredrickson wrote: > >> On Mon, Jun 5, 2017 at 2:31 PM, Joshua Colp <jc...@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. > > > > -- > _____________________________________________________________________ > -- 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
