Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40FB21F9A35 for ; Mon, 29 Jul 2013 10:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wepGUClonYvq for ; Mon, 29 Jul 2013 10:45:26 -0700 (PDT) Received: from nm13-vm0.bullet.mail.ird.yahoo.com (nm13-vm0.bullet.mail.ird.yahoo.com [77.238.189.195]) by ietfa.amsl.com (Postfix) with SMTP id 6FD0621F8427 for ; Mon, 29 Jul 2013 10:45:13 -0700 (PDT) Received: from [77.238.189.50] by nm13.bullet.mail.ird.yahoo.com with NNFMP; 29 Jul 2013 17:45:11 -0000 Received: from [212.82.108.243] by tm3.bullet.mail.ird.yahoo.com with NNFMP; 29 Jul 2013 17:45:10 -0000 Received: from [127.0.0.1] by omp1008.mail.ird.yahoo.com with NNFMP; 29 Jul 2013 17:45:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 974894.2338.bm@omp1008.mail.ird.yahoo.com Received: (qmail 76922 invoked by uid 60001); 29 Jul 2013 17:45:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; 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; d=yahoo.fr; 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 [88.179.39.5] by web171302.mail.ir2.yahoo.com via HTTP; Mon, 29 Jul 2013 18:45:10 BST X-Rocket-MIMEInfo: 002.001, WW91IHNhaWQ6ICIyKQpTRFAgc2VlbXMgdG8gYWxsb3cgdGhhdCB0aGUgb2ZmZXIgYW5kIHRoZSBhbnN3ZXIgaGF2ZSBkaWZmZXJlbnQgbnVtYmVyCm9mIG0gbGluZXPCoCIKCgpObyBhdCBhbGw6ClJGQyAzMjY0OgpGb3IgZWFjaCAibT0iIGxpbmUgaW4gdGhlIG9mZmVyLCB0aGVyZSBNVVNUIGJlIGEgY29ycmVzcG9uZGluZyAibT0iCmxpbmUgaW4gdGhlIGFuc3dlci4gIFRoZSBhbnN3ZXIgTVVTVCBjb250YWluIGV4YWN0bHkgdGhlIHNhbWUgbnVtYmVyIG9mICJtPSIgbGluZXMgYXMgdGhlIG9mZmVyLiAgVGgBMAEBAQE- X-Mailer: YahooMailWebService/0.8.150.561 References: Message-ID: <1375119910.76535.YahooMailNeo@web171302.mail.ir2.yahoo.com> Date: Mon, 29 Jul 2013 18:45:10 +0100 (BST) From: Bossiel thioriguel To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "rtcweb@ietf.org" , "public-webrtc@w3.org" 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-BeenThere: rtcweb@ietf.org 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 --1670751155-1967887231-1375119910=:76535 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable You said: "2)=0ASDP seems to allow that the offer and the answer have diffe= rent number=0Aof m lines=A0"=0A=0A=0ANo at all:=0ARFC 3264:=0AFor each "m= =3D" line in the offer, there MUST be a corresponding "m=3D"=0Aline in the = answer. The answer MUST contain exactly the same number of "m=3D" 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=3D" lines, the answer MU= ST contain zero "m=3D" lines.=0AMamadou.=0A=0A_____________________________= ___=0A De=A0: I=F1aki Baz Castillo =0A=C0=A0: "rtcweb@ietf.o= rg" ; "public-webrtc@w3.org" =0AEnv= oy=E9 le : Lundi 29 juillet 2013 19h31=0AObjet=A0: [rtcweb] SDP is not suit= able for WebRTC=0A =0A=0AHi, I initiated a thread [*] about Plan-Unified an= d multiple m lines,=0Abut it was moved to MMUSIC maillist (don't know why s= ince it is about=0AWebRTC applications design):=0A=0Ahttp://www.ietf.org/ma= il-archive/web/mmusic/current/msg11966.html=0A=0ASorry for the cross-postin= g but at this point I'm a bit lost and do=0Anot know which is the appropria= te group for my concern.=0A=0A=0A=0ASo my concern is:=0A=0A=0A- Web applica= tion with a SIP over WebSocket client running in the web.=0A=0A- The web us= er is provided with a conference SIP URI in which there=0Aare *already* 8 p= articipants (5 of them emitting audio and video and 3=0Ajust emitting audio= ).=0A=0A- The user calls, from his webphone, to the given URI to join the c= onference.=0A=0A=0A=0ALet's imagine that the JS app knows the number of par= ticipant in the conference.=0ALet's imagine my browser have mic and webcam.= =0A=0A=0A=0AQUESTION:=0A=0AHow can my browser join the conference without r= equiring SDP=0Arenegotiation from the server and, at the same time, being a= ble to=0Asend audio/video and receive audio/video from others (different tr= acks=0A/ m=3Dlines)?=0A=0A=0A=0A=0A"SOLUTIONS":=0A=0A=0A=0A1)=0A=0AI tell m= y browser to generate a SDP offer with:=0A=0A=A0 - 1 send/receive m=3Daudio= line.=0A=A0 - 7 recvonly m=3Daudio line.=0A=A0 - 1 send/only m=3Dvideo lin= e.=0A=A0 - 4 recvonly m=3Dvideo line.=0A=0A(Obviously this is a joke)=0A=0A= =0A=0A2)=0A=0ASDP seems to allow that the offer and the answer have differe= nt number=0Aof m lines (I'm not aware of that but I believe that SDP can do= =0A"everything"). So my browser generates a SDP offer with 1 m=3Daudio line= =0Aand 1 m=3Dvideo line, and the server replies with 8 m=3Daudio lines and = 4=0Am=3Dvideo lines.=0A=0AWill my browser understand such a SDP answer with= more m lines than=0Aits generated offer? I assume NOT.=0A=0A=0A=0A3)=0A=0A= My browser generates a SDP offer with 1 m=3Daudio line and 1 m=3Dvideo=0Ali= ne and the server too. And later the server sends re-INVITE with all=0Athe = m lines.=0A=0AOppss, SDP renegotiation...=0A=0A=0A=0A=0ASDP is bad for WebR= TC. SDP is good for legacy symmetric communications=0Ain which there is a s= ingle-track audio communication and, of course,=0Aboth endpoints emit audio= . But SDP is bad for modern RTC protocols in=0Awhich an endpoint can emit t= ons of tracks to a single endpoint.=0A=0A=0ADo we really want this for WebR= TC 1.0 ?=0A=0A=0A-- =0AI=F1aki Baz Castillo=0A=0A___________= ____________________________________=0Artcweb mailing list=0Artcweb@ietf.or= g=0Ahttps://www.ietf.org/mailman/listinfo/rtcweb --1670751155-1967887231-1375119910=:76535 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
You said: = "2)

SDP seems to al= low that the offer and the answer have different number
of m lines = "

No at all:
RFC 32= 64:
For each "m=3D" line = in the offer, there MUST be a corresponding "m=3D"
   line in the answer=
.  The answer MUST contain exactly the same number=0A   of "m=3D" lines as =
the offer.  This allows for streams to be matched up=0A   based on their or=
der.  This implies that if the offer contained zero=0A   "m=3D" lines, the =
answer MUST contain zero "m=3D" lines.
Mamadou.
<= span style=3D"font-weight:bold;">De : I=F1aki Baz Castillo = <ibc@aliax.net>
=C0 :<= /span> "rtcweb@ietf.org" <rtcweb@ietf.org>; "public-webrtc@w3.org= " <public-webrtc@w3.org>
E= nvoy=E9 le : Lundi 29 juillet 2013 19h31
Objet : [rtcweb] SDP is not suitable for= WebRTC

Hi, I initiat= ed a thread [*] about Plan-Unified and multiple m lines,
but it was move= d to MMUSIC maillist (don't know why since it is about
WebRTC application= s 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 grou= p for my concern.



So my concern is:


- Web applica= tion 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 a= udio).

- The user calls, from his webphone, to the given URI to join= the conference.



Let's imagine that the JS app knows the num= ber 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 fr= om others (different tracks
/ m=3Dlines)?




"SOLUTIONS"= :



1)

I tell my browser to generate a SDP offer with:<= br>
  - 1 send/receive m=3Daudio line.
  - 7 recvonly m=3Da= udio line.
  - 1 send/only m=3Dvideo line.
  - 4 recvonly m= =3Dvideo line.

(Obviously this is a joke)



2)

S= DP 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
"everythin= g"). 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=3Dv= ideo 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 th= e server too. And later the server sends re-INVITE with all
the m lines.=

Oppss, SDP renegotiation...




SDP is bad for WebRT= C. SDP is good for legacy symmetric communications
in which there is a s= ingle-track audio communication and, of course,
both endpoints emit audi= o. 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=F1aki Baz Castillo
<ibc@aliax.net>_______________________________________________
rtcweb mailing list
= rtcwe= b@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

<= br>
--1670751155-1967887231-1375119910=:76535--