Re: [rtcweb] SDP is not suitable for WebRTC

Christer Holmberg <> Tue, 30 July 2013 03:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 670F311E81B4 for <>; Mon, 29 Jul 2013 20:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.46
X-Spam-Status: No, score=-5.46 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zQLx2TzTp2Fr for <>; Mon, 29 Jul 2013 20:52:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7219511E81B3 for <>; Mon, 29 Jul 2013 20:52:48 -0700 (PDT)
X-AuditID: c1b4fb25-b7f826d000001766-97-51f7388d5b6f
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id E6.5F.05990.D8837F15; Tue, 30 Jul 2013 05:52:46 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Tue, 30 Jul 2013 05:52:45 +0200
From: Christer Holmberg <>
To: Iñaki Baz Castillo <>, Bossiel thioriguel <>
Thread-Topic: [rtcweb] SDP is not suitable for WebRTC
Thread-Index: AQHOjIHcZ/1hbOJS5UyRjSuEQ/tcvJl7zDIAgAABWACAAMllYA==
Date: Tue, 30 Jul 2013 03:52:45 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: fi-FI
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4132BFESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+JvrW6fxfdAgze/+Sym/jjOYjF9n41F 78cljBZr/7WzO7B4nGt4z+6xZMlPJo+j8/azerya/pA9gCWKyyYlNSezLLVI3y6BK6N1bgNr wYOFjBWTn01na2DcMZexi5GTQ0LAROLMvO9QtpjEhXvr2boYuTiEBA4zSsw4eZ0ZwlnCKDG7 Zx5QhoODTcBCovufNkiDiEC6xKSNH5hAbGaBCImLR16yg9jCQEO7F6xmhqgxldjw4TgThO0k cWdrLyuIzSKgKvFo3WKwel4BX4lvO35CLb7GKLHh5hWwizgFAiXO/jjMBmIzAl33/dQaqGXi Eh8OXmeGuFpAYsme81C2qMTLx/9YIWwlicYlT1gh6vMlXl7vYoZYJihxcuYTlgmMorOQjJqF pGwWkrJZQC8zC2hKrN+lD1GiKDGl+yE7hK0h0TpnLjuy+AJG9lWM7LmJmTnp5UabGIHRd3DL b9UdjHfOiRxilOZgURLn3ax3JlBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo07Zzmkv9nJx B7Ac9tczYXup9Uf727UMm+1tcQGWl8v32zu9t1sVJ/flSEPoqjDP4zqTpzd2ZzrEBMS33Hxf lhDYIXV7qR2D0Fb3LiGjkG/Fs+/M5km+vMvszsWuL7WyX7KLls2Urm96xGB1I9FU6Yncwmru CzN0r0ZNnyYWIa/J1N/z8V+QEktxRqKhFnNRcSIAAq6Hk4wCAAA=
Cc: "" <>, "" <>
Subject: Re: [rtcweb] SDP is not suitable for WebRTC
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Jul 2013 03:52:54 -0000


I was not wrong, but I was maybe unclear. I meant that each entity would offer it’s m- lines as part of separate Offer/Answer transactions. It IS allowed to add m- lines in a subsequent Offer.



Lähettäjä: Iñaki Baz Castillo []
Lähetetty: 29. heinäkuuta 2013 20:50
Vastaanottaja: Bossiel thioriguel
Aihe: Re: [rtcweb] SDP is not suitable for WebRTC

Thanks a lot for clarifying it. So Christer was wrong ;)

And it makes my scenario even worse. I really hope something will happen and WebRTC will get rid of SDP...

Iñaki Baz Castillo
El 29/07/2013 19:45, "Bossiel thioriguel" <<>> escribió:
You said: "2)

SDP seems to allow that the offer and the answer have different number
of m lines "

No at all:
RFC 3264:
For each "m=" line in the offer, there MUST be a corresponding "m="

   line in the answer.  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.  This implies that if the offer contained zero

   "m=" lines, the answer MUST contain zero "m=" lines.


De : Iñaki Baz Castillo <<>>
À : "<>" <<>>; "<>" <<>>
Envoyé le : Lundi 29 juillet 2013 19h31
Objet : [rtcweb] SDP is not suitable for WebRTC

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):

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


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


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


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

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ñaki Baz Castillo
rtcweb mailing list<>