MIME-Version: 1.0
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Mon, 29 Jul 2013 19:31:55 +0200
Message-ID: <CALiegfnU0U0juKu8y68K-pfkdf9NwQPxH=yM7vt=1EZEg=fxtA@mail.gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>,
 "public-webrtc@w3.org" <public-webrtc@w3.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [rtcweb] SDP is not suitable for WebRTC
Precedence: list

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.



So my concern is:


- 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 conferenc=
e.



Let's imagine that the JS app knows the number of participant in the confer=
ence.
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=3Dlines)?




"SOLUTIONS":



1)

I tell my browser to generate a SDP offer with:

  - 1 send/receive m=3Daudio line.
  - 7 recvonly m=3Daudio line.
  - 1 send/only m=3Dvideo line.
  - 4 recvonly m=3Dvideo line.

(Obviously this is 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"). So my browser generates a SDP offer with 1 m=3Daudio line
and 1 m=3Dvideo line, and the server replies with 8 m=3Daudio lines and 4
m=3Dvideo lines.

Will my browser understand such a SDP answer with more m lines than
its generated offer? I assume NOT.



3)

My browser generates a SDP offer with 1 m=3Daudio line and 1 m=3Dvideo
line and the server too. And later the server sends re-INVITE with all
the m lines.

Oppss, SDP renegotiation...




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 ?


--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>