[asterisk-dev] Issues with WebRTC going forward - rtcp-mux now required

[Dan Jenkins]

Hi Sebastian,

I haven't opened an issue in Asterisk yet - ran out of time yesterday -
first thing on my list to do today.

I have now tested the flag in jssip (jssip makes it extremely easy to test
as it gives you direct access to the parameters you pass into
RTCPeerConnection) and it does in fact work. Once I've made the issue -
I'll be writing a blog post about the issue to further warn others about it.

Dan

On Thu, Jan 19, 2017 at 12:33 AM, Sebastian Gutierrez <scgm11 at gmail.com>
wrote:

> Dan,
>
> have you open an issue on asterisk jira?
> did you test the flag in jssip?
>
> thanks
>
> best regards
>
>
> On Jan 18, 2017, 10:52 -0600, Dan Jenkins <dan.jenkins88 at gmail.com>,
> wrote:
>
> Hi All,
>
> I've been working with a company who utilise WebRTC using Asterisk behind
> Kamailio to connect browser users and their SIP infrastructure and just
> came across an issue making/receiving calls in Chrome Canary and Chrome Dev.
>
> Long story short; the issue is that rtcp-mux has now been set as required
> in Chrome's WebRTC stack - https://groups.google.com/
> forum/#!topic/discuss-webrtc/eM57DEy89MY
>
> For now; there is a workaround of being able to pass in a flag to the
> RTCPeerConnection call to get the old "negotiate" behaviour and I'm talking
> to the Chrome team to find out how long this flag will be around for.
>
> I've been told that Asterisk doesn't support rtcp-mux as of today and so
> I'm raising the issue here. It seems - if Asterisk wants to support WebRTC
> long term; it will need to support rtcp-mux - I quote Sean Bright from a
> conversation we had in IRC where he said it was "non-trivial" to support.
>
> I don't know more than this and I don't mean to say something is difficult
> to fix when I honestly don't know the effort levels in order to fix this.
> So I'm raising this here for a conversation.
>
> I will be testing the client side flag fix in jssip in a moment and then
> writing up a blog post about it if it does indeed fix the issue, at least
> temporarily while the flag is available.
>
> Dan
> --
> _____________________________________________________________________
> -- 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
>
>
> --
> _____________________________________________________________________
> -- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170119/3308e83d/attachment.html>