Re: Cross posting: Re: [rtcweb] SDP is not suitable for WebRTC

2013/7/30 Ted Hardie <ted.ietf@gmail.com>:
> We have asked that folks avoid cross-posting, in order to keep it easier for
> folks to follow a thread.  Please keep this discussion on public-webrtc.


Thanks Ted.

I will summarize my SDP/Plan-Unified concern here. I hope that those
who are fine with SDP and Plan-Unified (i.e. Google and Cisco) will
express their opinion:




- 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.

- A signaling and media session would then be established between the
browser and the conference server.



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 its audio/video tracks and receive audio/video from all the participants?




"SOLUTION":

I tell my browser to generate a SDP offer with:

  - 1 send/receive m=audio line.
  - 7 recvonly m=audio line.
  - 1 send/only m=video line.
  - 4 recvonly m=video line.

Obviously this is not possible with current SDP-blob based API, and I
hope the API will never allow such an aberration. And, regardless it
would be possible, why should my browser know (before calling) the
number of participants in the conference?

My browser should be able to tell the conference server:

- These are my audio and video tracks (2 tracks).

And the server should be able to accept the "call" and reply:

- OK, and these are my multiple audio and video tracks (13 tracks).

And that's all. But since we are mandated and limitated by the
old-fashion-style SDP protocol, we cannot do that, and instead must
play with media renegotiation via new SDP O/A round trips, and this is
because, according to RFC 3264:

     The answer MUST contain exactly the same number
     of "m=" lines as the offer.  This allows for streams to be
     matched up based on their order.

So "cool and modern", really.
SDP: don't you know about "id-based matching" instead of "line number matching"?


Nobody considered how bad SDP and Plan-Unified are for the above so
common scenario?


Regards.



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

Received on Tuesday, 30 July 2013 08:53:26 UTC