Re: [rtcweb] Review request for RTCWeb standard signaling protocol

"Asveren, Tolga" <tasveren@sonusnet.com> Tue, 18 October 2011 18:18 UTC

Return-Path: <tasveren@sonusnet.com>
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 C9ADC21F8AC9 for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 11:18:40 -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 oDJs-iStOZgA for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 11:18:40 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id C73A421F8AC3 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 11:18:39 -0700 (PDT)
Received: from sonusmail04.sonusnet.com (sonusmail04.sonusnet.com [10.128.32.98]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9IIJBMr028296; Tue, 18 Oct 2011 14:19:11 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 18 Oct 2011 14:18:34 -0400
Message-ID: <033458F56EC2A64E8D2D7B759FA3E7E703DBF698@sonusmail04.sonusnet.com>
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol
Thread-Index: AQHMjWPJQsg22CmbRQ+ec/AyTlzr85WCFU0AgAAGWYCAAE3QgP//tE4QgABB3qCAAAffsA==
References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><CALiegf=ejF2kUC1m=74o9eprF1M8wYtgE-Crwa1x14rzDOf+gQ@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><CAOg=WDcC9t2KhQUg0gDJ60gO_2mNyMv9HKt=otCdPDfj4TnoTg@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><CABRok6mM7TfbLgGhoQvdRh1Kwoi5BhRweLcqWg7VZOFnaa8VOw@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><CABRok6n33QK0Si1Y0kT7+U0zgAWsJ4d5GENK_KL-JPx5a4erYg@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com><CALiegfmrncjsLVSiWk0tEgzwB00YaBGiqj0SDf9JTm9p1ZNoVA@mail.gmail.com><2E239D6FCD033C4BAF15F38 6A979B F 51159950@so nusinmail02.sonusnet.com><0950F0E1-6E4B-407F-9563-654AFE79F64B@ag-projects.com><2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com><1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com> <033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com> <8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil> <2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com>
From: "Asveren, Tolga" <tasveren@sonusnet.com>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>, "Roy, Radhika R USA CIV (US)" <radhika.r.roy.civ@mail.mil>, "Avasarala, Ranjit" <Ranjit.Avasarala@Polycom.com>, Saúl Ibarra Corretgé <saul@ag-projects.com>
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol
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, 18 Oct 2011 18:18:40 -0000

Just for clarity, my use of the term "simple" in this thread was a bit rhetorical to indicate that I do not agree with Ranjit's view that a "simple standard protocol" is needed between browser and webserver.

I am even not sure whether full offer/answer semantics need to be supported between webserver and JS (or better said, whether that needs to be the only way of doing things). I would think that supporting what Tim Panton describes in another thread (codec selection done in webserver) could be nice to achieve -among other models- if possible. 

Thanks,
Tolga

> -----Original Message-----
> From: Ravindran Parthasarathi
> Sent: Tuesday, October 18, 2011 2:05 PM
> To: Roy, Radhika R USA CIV (US); Asveren, Tolga; Avasarala, Ranjit; Saúl
> Ibarra Corretgé
> Cc: rtcweb@ietf.org
> Subject: RE: [rtcweb] Review request for RTCWeb standard signaling
> protocol
> 
> Tolga/Radhika,
> 
> In case I read Ranjit mail correctly, the "simpler" protocol than "SIP
> over websocket" is required which does not require to perform signaling
> routing functionality like via header, route header handling as two-way
> communication between browser to RTCWeb server is established using
> websocket. But, It does not mean that media negotiation ("offer/answer")
> is not required. I have mentioned this media negotiation requirement for
> signaling in Bullet 2 of Sec 5 in draft-partha-rtcweb-signaling-00 draft
> as
> 
>     " The mechanism has to provide the way to pass description about the
>       media transmission between two RTCweb clients"
> 
> Also, the attempt for "standard" signaling protocol is not an attempt to
> stop custom-build signaling protocol and Sec 4 of draft-partha-rtcweb-
> signaling-00 draft explains this as
> 
> "The defining signaling protocol is not a hindrance for any innovative
>    RTCWeb signaling protocol development as it is complementary
>    solution."
> 
> but standard signaling protocol facilities for the quick development of
> the generic RTCWeb usecase without the need of developing of new signaling
> protocol per website. In case you still feel that my draft does not
> reflect this notion, Please let me know.
> 
> 
> Thanks
> Partha
> 
> >-----Original Message-----
> >From: Roy, Radhika R USA CIV (US) [mailto:radhika.r.roy.civ@mail.mil]
> >Sent: Tuesday, October 18, 2011 7:19 PM
> >To: Asveren, Tolga; Avasarala, Ranjit; Ravindran Parthasarathi; Saúl
> >Ibarra Corretgé
> >Cc: rtcweb@ietf.org
> >Subject: RE: [rtcweb] Review request for RTCWeb standard signaling
> >protocol
> >
> >Folks:
> >
> >Tolga is right.
> >
> >We have a very complex problem to solve. It is called negotiations
> >between different types of codecs and between different features of each
> >codec type.
> >
> >Let us see how simple a protocol can be based on these simple
> >requirements.
> >
> >BR/Radhika
> >
> >-----Original Message-----
> >From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
> >Of Asveren, Tolga
> >Sent: Tuesday, October 18, 2011 9:17 AM
> >To: Avasarala, Ranjit; Ravindran Parthasarathi; Saúl Ibarra Corretgé
> >Cc: rtcweb@ietf.org
> >Subject: Re: [rtcweb] Review request for RTCWeb standard signaling
> >protocol
> >
> >Yes, something "simple" would be nice but the definition of "simple
> >enough but still allowing me to do what I want to achieve" is very much
> >dependent on the needs of each specific use case/service. There is no
> >universal definition of "simple" here. So, I guess this is yet another
> >argument in favor of not standardizing the protocol between browser and
> >webserver so that everybody can design/use whatever is "simple but good
> >enough" from their perspective.
> >
> >Thanks,
> >Tolga
> >