IETF Logo Mail Archive

Re: [rtcweb] SDP is not suitable for WebRTC (UNCLASSIFIED)

"Roy, Radhika R CIV USARMY (US)" <radhika.r.roy.civ@mail.mil> Tue, 30 July 2013 11:23 UTC

Return-Path: <radhika.r.roy.civ@mail.mil>
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 4483111E81C4 for <rtcweb@ietfa.amsl.com>; Tue, 30 Jul 2013 04:23:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 N-YTgMFqNZ+Q for <rtcweb@ietfa.amsl.com>; Tue, 30 Jul 2013 04:23:43 -0700 (PDT)
Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.13]) by ietfa.amsl.com (Postfix) with ESMTP id B72D511E81F3 for <rtcweb@ietf.org>; Tue, 30 Jul 2013 04:23:36 -0700 (PDT)
Received: from UCOLHP3P.easf.csd.disa.mil (131.64.100.155) by edge-cols.mail.mil (131.64.100.13) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 30 Jul 2013 11:23:35 +0000
Received: from UCOLHP9B.easf.csd.disa.mil ([169.254.10.43]) by UCOLHP3P.easf.csd.disa.mil ([131.64.100.155]) with mapi id 14.03.0123.003; Tue, 30 Jul 2013 11:23:34 +0000
From: "Roy, Radhika R CIV USARMY (US)" <radhika.r.roy.civ@mail.mil>
To: Iñaki Baz Castillo <ibc@aliax.net>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Thread-Topic: [rtcweb] SDP is not suitable for WebRTC (UNCLASSIFIED)
Thread-Index: AQHOjK50kFQA3ktZMU24WHKXTf6sAZl82EyAgAA7YjA=
Date: Tue, 30 Jul 2013 11:23:32 +0000
Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF49B37A18@ucolhp9b.easf.csd.disa.mil>
References: <CALiegfnU0U0juKu8y68K-pfkdf9NwQPxH=yM7vt=1EZEg=fxtA@mail.gmail.com> <CAHp8n2=D6jSmBGLtnhVYHj5FVKZ+X2x_KUM2ab1APVALMELQDQ@mail.gmail.com> <CALiegf=1iCqER7KqQ1kyqNDsjsY9Kdut45Qh-6n=ep8=fA-k6Q@mail.gmail.com>
In-Reply-To: <CALiegf=1iCqER7KqQ1kyqNDsjsY9Kdut45Qh-6n=ep8=fA-k6Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [131.64.62.4]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0004_01CE8CF5.B07A3C00"
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] SDP is not suitable for WebRTC (UNCLASSIFIED)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jul 2013 11:23:49 -0000

Classification: UNCLASSIFIED
Caveats: NONE

Iñaki:

Yes, the conference setup scenario is itself is restricted in a kind of start-conference-arch, as if, it is the third party call setup in the SIP-conf-scenario in your conf-flow.

So, the discussions need to be confined based on this particular conf-call-flow arch. Once we agree on this, we can then limit our discussions with thiis particular case instead of making a general case.

BR/Radhika

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Iñaki Baz Castillo
Sent: Tuesday, July 30, 2013 3:46 AM
To: Silvia Pfeiffer
Cc: rtcweb@ietf.org; public-webrtc@w3.org
Subject: Re: [rtcweb] SDP is not suitable for WebRTC

2013/7/30 Silvia Pfeiffer <silviapfeiffer1@gmail.com>:
> Since you seem to be doing a full mesh and you seem to be wanting to 
> receive from everyone and be able to talk back to everyone, wouldn't 
> this need to be 8 different SDP offers in a full mesh network rather 
> than one SDP offer with 13 different m-lines? I don't follow how each 
> of the recipients would pick the right m-line for themselves...


Silvia, I don't feel I am doing a full mesh, but something really common, which is:

- I contact, from my browser, to a conference server in which there is an active conference with N participants.

- I provide my audio and video tracks to the conference server.

- The server provides me with N audio/video tracks belonging to N participants.

- I don't want to do a second SDP O/A round trip.

Please, note that my browser has a signaling and a media session with the conference server. This is, the endpoints are my browser and the conference server. The fact that the conference server acts as a mixer by joining all the participants changes nothing. The browser establishes a single RTC session with the server. This is not an exotic scenario at all.

And no, I do not want to send 8 different SDP offers since I will mantain just a single RTC session (with the conference server). All the participants do the same, and the conference server is responsible of taking all the tracks from participants and send them to all the participants (via separate tracks).


I would like to hear the opinion of those in favour of SDP for WebRTC, since what I am clearly stating is that SDP and Plan-Unified is *bad* for this common scenario.


--
Iñaki Baz Castillo
<ibc@aliax.net>
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



Classification: UNCLASSIFIED
Caveats: NONE

v2.29.0 | Report a Bug | By Email | System Status