<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 6, 2017 at 6:28 PM, Mark Michelson <span dir="ltr"><<a href="mailto:mmichelson@digium.com" target="_blank">mmichelson@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 06/05/2017 03:17 PM, Matt Fredrickson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Jun 5, 2017 at 2:31 PM, Joshua Colp <<a href="mailto:jcolp@digium.com" target="_blank">jcolp@digium.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Jun 5, 2017, at 04:21 PM, Mark Michelson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi folks,<br>
<br>
For those of you following along at home, I recently published review<br>
<a href="https://gerrit.asterisk.org/#/c/5760/" rel="noreferrer" target="_blank">https://gerrit.asterisk.org/#/<wbr>c/5760/</a> , which is step one towards making<br>
chan_pjsip multistream, i.e. supporting more than one stream of a given<br>
media type. This initial review does not actually introduce multistream<br>
support so much as it just makes use of multistream structures under the<br>
hood to ease the transition.<br>
<br>
Continuing on, one of the next steps we need to determine is how a user<br>
of chan_pjsip should configure a channel that supports multiple streams<br>
of a particular type.<br>
<br>
To refresh everyone on how things currently work in pjsip.conf, you set<br>
an "allow" option in order to determine what codecs a particular<br>
endpoint supports.<br>
<br>
[Alice]<br>
type = endpoint<br>
allow = ulaw,opus,h264<br>
<br>
</blockquote>
<snip><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I propose the following configuration options to move forward.<br>
<br>
offered_audio_streams = 1<br>
offered_video_streams = 2<br>
</blockquote>
<snip><br>
<br>
My only question is why, in a scenario where we don't have a hint, would<br>
we want to make the number of offered streams configurable by the user?<br>
Ultimately it's up to the application that is handling the channel to<br>
decide what it wants and that is decided in the moment, not ahead of<br>
time based on configuration.<br>
<br>
I think maximum and minimum are useful for enforcing some constraints<br>
though.<br>
</blockquote>
That echoes my thoughts as well.  +1 to not having the<br>
"offered_audio/video_streams" options, but I'm ok with the limiting of<br>
maximum stream count for now.<br>
<br>
</blockquote></div></div>
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.<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
-- <br>
______________________________<wbr>______________________________<wbr>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
  <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" rel="noreferrer" target="_blank">http://lists.digium.com/mailma<wbr>n/listinfo/asterisk-dev</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Agree with the above :)</div></div>