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 88D5121F9C8B for ; Mon, 29 Jul 2013 10:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 RdNQAipvb+Qz for ; Mon, 29 Jul 2013 10:50:07 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3681D21F9A50 for ; Mon, 29 Jul 2013 10:50:04 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id c11so2033227qcv.27 for ; Mon, 29 Jul 2013 10:49:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=L8dj04nslYZjOsGkfZjGru0i+IGa4CO/I7t4XA0AUdc=; b=axhq3Y+e9/x8LIeWjFvfQmp5f2rJQPhfzZxnnkCZtzIDUJdkV+/lY/pmACnRd5dMqk gN+gtD3GKlChAdAoIQy7tFR8YD0p8mYDm4i/ht7avRMJqRwE6T3jaYwHDaGr1a8GTqbW Kj8ZWGKSBls3YJWy+zeFk7rTH2ntjQak/sF5/wazfrMsVwFDmaRgTejAesaKsyx3Z3lu sfYYKVZ3wmsKpiOH6eQ3fEvV35Nq2JV+GzdwKbKzk90XD+NqZWUGbGIoXDJv/3Ps8PS+ TPuld7dx9DM97dQu5/jjN2LXvpWPnCMfC21dxftY6MjhQbAVXhniFq96pKQkAsXGs2rw YOFA== MIME-Version: 1.0 X-Received: by 10.229.16.207 with SMTP id p15mr5890154qca.47.1375120198810; Mon, 29 Jul 2013 10:49:58 -0700 (PDT) Received: by 10.49.72.132 with HTTP; Mon, 29 Jul 2013 10:49:58 -0700 (PDT) Received: by 10.49.72.132 with HTTP; Mon, 29 Jul 2013 10:49:58 -0700 (PDT) In-Reply-To: <1375119910.76535.YahooMailNeo@web171302.mail.ir2.yahoo.com> References: <1375119910.76535.YahooMailNeo@web171302.mail.ir2.yahoo.com> Date: Mon, 29 Jul 2013 19:49:58 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bossiel thioriguel Content-Type: multipart/alternative; boundary=0015175df19ef975ed04e2aa1e7a X-Gm-Message-State: ALoCoQnSziW3HCKoslyH8SZ9cMzBTUNl/Xj66z20j4PYwehHVGjQPGp21P59BWjn0j2xSPvZrtfH Cc: rtcweb@ietf.org, public-webrtc@w3.org Subject: Re: [rtcweb] SDP is not suitable for WebRTC X-BeenThere: rtcweb@ietf.org 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: Mon, 29 Jul 2013 17:50:40 -0000 --0015175df19ef975ed04e2aa1e7a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=C3=B1aki Baz Castillo El 29/07/2013 19:45, "Bossiel thioriguel" escribi=C3=B3: > 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=3D" line in the offer, there MUST be a corresponding "m=3D" > > line 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 u= p > based on their order. This implies that if the offer contained zero > "m=3D" lines, the answer MUST contain zero "m=3D" lines. > > Mamadou. > > ------------------------------ > *De :* I=C3=B1aki Baz Castillo > *=C3=80 :* "rtcweb@ietf.org" ; "public-webrtc@w3.org" < > public-webrtc@w3.org> > *Envoy=C3=A9 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): > > 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 > 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=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 ? > > > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --0015175df19ef975ed04e2aa1e7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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=C3=B1aki Baz Castillo
<ibc@aliax.net>

El 29/07/2013 19:45, "Bossiel thioriguel&qu= ot; <bossiel@yahoo.fr> escrib= i=C3=B3:
You said: "2= )

SDP seems to allow that the offer and the answer have dif= ferent number
of m lines=C2=A0"

No at all:
RFC 3264:
For = each "m=3D" line in the offer, there MUST be a corresponding &quo= t;m=3D"
   line in th=
e answer.  The answer MUST contain exactly the same number
   of "m=3D" lines as the offer.  This allows for streams to be m=
atched up
   based on their order.  This implies that if the offer contained zero
   "m=3D" lines, the answer MUST contain zero "m=3D" li=
nes.
Mamadou.=
De=C2=A0: I=C3=B1aki= Baz Castillo <ibc@al= iax.net>
=C3=80=C2=A0: "rtcweb@ietf.org" <= ;rtcweb@ietf.org&g= t;; "public-= webrtc@w3.org" <public-webrtc@w3.org>
Envoy=C3=A9 le : Lundi 29 j= uillet 2013 19h31
Objet=C2=A0: [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 applica= tions 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 cl= ient 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
j= ust emitting audio).

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



Let's imagine that the JS app knows the number of participa= nt in the conference.
Let's imagine my browser have mic and webcam.<= br>


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




"SOLUT= IONS":



1)

I tell my browser to generate a SDP offer with:
=C2=A0 - 1 send/receive m=3Daudio line.
=C2=A0 - 7 recvonly m=3Daudio = line.
=C2=A0 - 1 send/only m=3Dvideo line.
=C2=A0 - 4 recvonly m=3Dvi= deo 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 th= at SDP can do
"everything"). So my browser generates a SDP off= er with 1 m=3Daudio line
and 1 m=3Dvideo line, and the server replies with 8 m=3Daudio lines and 4m=3Dvideo lines.

Will my browser understand such a SDP answer with= more m lines than
its generated offer? I assume NOT.



3)<= br>
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 single-track audio communication and, of course,
bot= h 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=C3=B1aki Baz Castillo
<ibc@aliax.net>
____________________________= ___________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--0015175df19ef975ed04e2aa1e7a--