Re: SDP is not suitable for WebRTC

On 07/29/2013 07:31 PM, Iñaki Baz Castillo wrote:
> Hi, I initiated a thread [*] about Plan-Unified and multiple m lines,
> but it was moved to MMUSIC maillist (don't know why since it is about
> WebRTC applications design):
>
> http://www.ietf.org/mail-archive/web/mmusic/current/msg11966.html
>
> Sorry for the cross-posting but at this point I'm a bit lost and do
> not know which is the appropriate group for my concern.

For API issues, it's WebRTC.

For SDP issues, it's MMUSIC.

RTCWEB doesn't want this discussion at the moment.

Since what you describe doesn't seem to
>
>
>
> So my concern is:
>
>
> - Web application with a SIP over WebSocket client running in the web.

Do you really mean SIP here (which means that you've already bought into
using SDP and only SDP for your session descriptions), or do you mean "a
signalling protocol"?

I'm assuming you means SIP below.

>
> - 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)?
>
>
>
>
> "SOLUTIONS":
>
>
>
> 1)
>
> 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 a joke)

Given your constraints above (SIP, previous knowledge of the number of
active participants), what's obvious about this being a joke?
>
>
>
> 2)
>
> SDP seems to allow that the offer and the answer have different number
> of m lines (I'm not aware of that but I believe that SDP can do
> "everything").
If you believe that, you'll have a hard time dealing with the real world.

As far as I understand it:
- An answer always has the same number of M-lines as the offer
- A renegotiating offer always has at least as many M-lines as the last
offer/answer

So the number of M-lines always increases, never decreases.
>  So my browser generates a SDP offer with 1 m=audio line
> and 1 m=video line, and the server replies with 8 m=audio lines and 4
> m=video lines.
>
> Will my browser understand such a SDP answer with more m lines than
> its generated offer? I assume NOT.

I think you're right. The server has broken the rules.
>
>
>
> 3)
>
> My browser generates a SDP offer with 1 m=audio line and 1 m=video
> line and the server too. And later the server sends re-INVITE with all
> the m lines.
>
> Oppss, SDP renegotiation...

And why is that a problem, exactly?
And you did not include the scenario I'd prefer if I was operating
within the limitations you mention (SIP over WebSockets):

4)

The *server* generates an SDP offer with 8 m=audio lines and 4 m=video
lines.
One of each is sendrecv. The browser answers. End of story.

I don't know how people get so hung up on the entity joining the call
being the one to send the SDP offer; there's nothing in the protocol
requiring that, and just the loading of the Web page and opening of the
WS connection has already caused multiple round trips between the
browser and the server.




>
>
>
>
> SDP is bad for WebRTC. SDP is good for legacy symmetric communications
> in which there is a single-track audio communication and, of course,
> both endpoints emit audio. But SDP is bad for modern RTC protocols in
> which an endpoint can emit tons of tracks to a single endpoint.
>
>
> Do we really want this for WebRTC 1.0 ?

I see many issues with the use of SDP.

But when one of the requirements is "we have to be able to produce and
consume SDP from the data available on the API", actually producing and
consuming that SDP makes the requirement trivial to test.

That is not a small thing.

Received on Tuesday, 30 July 2013 08:31:56 UTC