Re: [rtcweb] SDP is not suitable for WebRTC

Bossiel thioriguel <> Mon, 29 July 2013 17:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A40FB21F9A35 for <>; Mon, 29 Jul 2013 10:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wepGUClonYvq for <>; Mon, 29 Jul 2013 10:45:26 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 6FD0621F8427 for <>; Mon, 29 Jul 2013 10:45:13 -0700 (PDT)
Received: from [] by with NNFMP; 29 Jul 2013 17:45:11 -0000
Received: from [] by with NNFMP; 29 Jul 2013 17:45:10 -0000
Received: from [] by with NNFMP; 29 Jul 2013 17:45:10 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 76922 invoked by uid 60001); 29 Jul 2013 17:45:10 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1375119910; bh=EOkC1I2GcnRR6nzD2Jt+OEpcP4gpHiUkNMk67hZgyjo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=GfoLOU3BxlWzveiJYb8Pm1sgSq/v80V+/u6IQTtD1yJQO9LzhezKdZI3e7mkTOThAmXhkbHIbz1qKH9+PBWU8ENiJKkp3O7qqt4GCCoJo5EuyHiJzYQJyBR0Fk9HAQ5ROEJxhxRrUC42ciuj0VGMqiL0O8gTY4WXTO/ynNlOkv4=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=2tpivj/JLPUM6hV2tRt/XmFigB0CvM7JMSh/1l9TYhFp8qhsLBe1o18jFnDDskF1d7IPQAxbk02yk3aC4ZqhUxW5r9dYKHz7/keWMqQeGgKhoXI4DGQNJ3oSLmbJuFDVWJJXYgDrlzkYtZRN5iV6szYAseh3wjgg7QDdecdSL3I=;
X-YMail-OSG: Q4oT19IVM1ncXoquQiAsRJIBvfctuuwa76deUzp42_gUSqd yl4biOFRIJHqoCZC1pBWIr0VVgclcTGQedz0_5HIqeaG7TvijozS.PXdjRVO zGR_ceg_Vzo2lSm_PsSIW7fKdXYp_frTHRWr9QBrD4jzPx1fcaClJL6zLy5g MYCkHWFZh0ZdwcdU5WEn5iz.eKNvaTKvD4kuzDBXboOdq72bWiAyg87R7DGK Whc9ZPRoX396vbss4WgM6s2P4aH7sEHBUdqbN7iueRkIuLft_Xn0fqEMWzHI 9apwoR8MUyy3hmAuXEzHz5e4CSYDB_lcuhTsfv5epWvjHncq1uxWS1C0ewaa 6_86v5yopsrNFT5rTN13HQwcwUAdpTFmlxiQtvOslpBmlvIK.ZFd1032AMds AFk7hH5lNbKbVMPhnTjfyYxjXbgE_JGzv6.9xIGmpWhb97Xl6bf1JJCndWPS 5idLthcUcAdwc2gNCB1unxQgvimY9d3ih98htNDSTSQk7NcENdOltaEF_3OB 2ny26Cas8jgXO2P3EZwprO0znQKbnY4qy1RVX
Received: from [] by via HTTP; Mon, 29 Jul 2013 18:45:10 BST
X-Rocket-MIMEInfo: 002.001, WW91IHNhaWQ6ICIyKQpTRFAgc2VlbXMgdG8gYWxsb3cgdGhhdCB0aGUgb2ZmZXIgYW5kIHRoZSBhbnN3ZXIgaGF2ZSBkaWZmZXJlbnQgbnVtYmVyCm9mIG0gbGluZXPCoCIKCgpObyBhdCBhbGw6ClJGQyAzMjY0OgpGb3IgZWFjaCAibT0iIGxpbmUgaW4gdGhlIG9mZmVyLCB0aGVyZSBNVVNUIGJlIGEgY29ycmVzcG9uZGluZyAibT0iCmxpbmUgaW4gdGhlIGFuc3dlci4gIFRoZSBhbnN3ZXIgTVVTVCBjb250YWluIGV4YWN0bHkgdGhlIHNhbWUgbnVtYmVyIG9mICJtPSIgbGluZXMgYXMgdGhlIG9mZmVyLiAgVGgBMAEBAQE-
X-Mailer: YahooMailWebService/
References: <>
Message-ID: <>
Date: Mon, 29 Jul 2013 18:45:10 +0100
From: Bossiel thioriguel <>
To: Iñaki Baz Castillo <>, "" <>, "" <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1670751155-1967887231-1375119910=:76535"
Subject: Re: [rtcweb] SDP is not suitable for WebRTC
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Bossiel thioriguel <>
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: Mon, 29 Jul 2013 17:45:32 -0000

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