Re: SDP is not suitable for WebRTC

2013/7/30 Silvia Pfeiffer <silviapfeiffer1@gmail.com>:
> Since you seem to be doing a full mesh and you seem to be wanting to
> receive from everyone and be able to talk back to everyone, wouldn't
> this need to be 8 different SDP offers in a full mesh network rather
> than one SDP offer with 13 different m-lines? I don't follow how each
> of the recipients would pick the right m-line for themselves...


Silvia, I don't feel I am doing a full mesh, but something really
common, which is:

- I contact, from my browser, to a conference server in which there is
an active conference with N participants.

- I provide my audio and video tracks to the conference server.

- The server provides me with N audio/video tracks belonging to N participants.

- I don't want to do a second SDP O/A round trip.

Please, note that my browser has a signaling and a media session with
the conference server. This is, the endpoints are my browser and the
conference server. The fact that the conference server acts as a mixer
by joining all the participants changes nothing. The browser
establishes a single RTC session with the server. This is not an
exotic scenario at all.

And no, I do not want to send 8 different SDP offers since I will
mantain just a single RTC session (with the conference server). All
the participants do the same, and the conference server is responsible
of taking all the tracks from participants and send them to all the
participants (via separate tracks).


I would like to hear the opinion of those in favour of SDP for WebRTC,
since what I am clearly stating is that SDP and Plan-Unified is *bad*
for this common scenario.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Tuesday, 30 July 2013 07:46:46 UTC