Subject: Re: [MMUSIC] SDP for conferencing scenario?

From: Bernard Aboba <[email-masked]>
Date: Mon, 29 Jul 2013 22:53:46 -0700

> - Web application with a SIP over WebSocket client running in the web.
> 
> - The web user is provided with a conference SIP URI in which there
> are *already* 8 participants (5 of them emitting audio and video and 3
> just emitting audio).
> 
> - The user calls, from his webphone, to the given URI to join the conference.
> 
> Let's imagine that the JS app knows the number of participant in the conference.
> Let's imagine my browser have mic and webcam.
> 
> QUESTION:
> 
> How can my browser join the conference without requiring SDP
> renegotiation from the server and, at the same time, being able to
> send audio/video and receive audio/video from others (different tracks
> / m=lines)?

Iñaki --
 
Is the term "conference" used here in the same way as in RFC 4353/4575/5239?  Or are you envisaging a set of peer-to-peer conversations?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 30 Jul 2013 09:40:24 +0200

> Iñaki
>
> Is the term "conference" used here in the same way as in RFC 4353/4575/5239?
> Or are you envisaging a set of peer-to-peer conversations?

Not exaclty. It may be but it is not required. Let's imagine I don't
use SIP but any other sig protocol (but still can be SIP). I just want
to call from my browser to a conference server in which there is
already an active conference with N participants. I want to be able to
offer my audio/video tracks and the server to accept them by also
telling me its N audio/video tracks. Without SDP renegotiation.

Is it possible? No, it is not, due to SDP semantics.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 30 Jul 2013 01:33:13 -0700

> I just want to call from my browser to a conference server in which there is

[BA]  Putting the SDP API issues aside for the moment,  I can imagine an on-the-wire SDP offer/answer exchange which could address your scenario.  For example, one could envisage a "Plan B"-ish approach where we have an SDP offer with two m lines (one for audio, one for video) and a max-recv-source attribute, and an answer also with two m-lines.  In a "mixer" topology where the SSRCs are known, a=ssrc attributes could be included.  For an "RTP translator" topology as described in "No Plan" the SSRCs might not be known, so they couldn't be included. 
 
Note that even if you don't want SDP in-the-API, you'd still need to address the RTP issues, such as which RTP topologies are to be supported.   Since interoperability among video conferencing systems is less than universal, these issues are non-trivial.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 30 Jul 2013 11:27:19 +0200

2013/7/30 Bernard Aboba <[email-masked]>:
> Putting the SDP API issues aside for the moment,  I can imagine an on-the-wire SDP offer/answer exchange which could address your scenario.

Of course, this is a SDP problem/limitation, a SDP problem which
constrains the design of WebRTC applications.

-- 
Iñaki Baz Castillo
<[email-masked]>