Re: [rtcweb] codec and connection negotiation

"Parthasarathi R (partr)" <partr@cisco.com> Mon, 08 August 2011 11:47 UTC

Return-Path: <partr@cisco.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 B104421F8736 for <rtcweb@ietfa.amsl.com>; Mon, 8 Aug 2011 04:47:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.198
X-Spam-Level:
X-Spam-Status: No, score=-10.198 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 Aryf1J6oUWiI for <rtcweb@ietfa.amsl.com>; Mon, 8 Aug 2011 04:47:18 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 31ADE21F867A for <rtcweb@ietf.org>; Mon, 8 Aug 2011 04:47:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=partr@cisco.com; l=5461; q=dns/txt; s=iport; t=1312804064; x=1314013664; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ckcwlczTc0DVOTMPEIWwvpXJ+bi/NorEB7UAcTEmJPg=; b=VIxZN/0JYPvciZESF+N1GAsP9GDVsW7MWJnYrGhw710/syVRLOeNOeBl G5Pcki0Sg/VTIO8CzWKejfX0rt0jT66S32WpgcXZSxWuGuiv5WP1DOb5F 5YAblCKvmj5X853npkxacY5jxAcpdzB6DpG6jpu2tbVDVXGD8uwKttLm5 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Au0AANfLP05Io8UQ/2dsb2JhbAA5CZduj013gUABAQEBAwEBAQ8BHQo0CwwEAgEIEQQBAQEKBhcBBgEmHwkIAQEECwgIGodPnz0Bnh6DJ4JAXwSHWpA5i18
X-IronPort-AV: E=Sophos;i="4.67,336,1309737600"; d="scan'208";a="47540872"
Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-2.cisco.com with ESMTP; 08 Aug 2011 11:47:41 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p78BlfI7031704; Mon, 8 Aug 2011 11:47:41 GMT
Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Aug 2011 17:17:41 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 08 Aug 2011 17:17:40 +0530
Message-ID: <A11921905DA1564D9BCF64A6430A6239061A657A@XMB-BGL-411.cisco.com>
In-Reply-To: <4E3FA538.3000301@alvestrand.no>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] codec and connection negotiation
Thread-Index: AcxVqV6IBcjKkBrVQGOtXOOQilgIgAAE+9iQ
References: <4E3C377A.5090105@skype.net> <4E3C3C2C.4020808@skype.net> <A11921905DA1564D9BCF64A6430A62390608EBEC@XMB-BGL-411.cisco.com> <4E3FA538.3000301@alvestrand.no>
From: "Parthasarathi R (partr)" <partr@cisco.com>
To: Harald Alvestrand <harald@alvestrand.no>
X-OriginalArrivalTime: 08 Aug 2011 11:47:41.0619 (UTC) FILETIME=[FAC4E030:01CC55C0]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] codec and connection negotiation
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: Mon, 08 Aug 2011 11:47:19 -0000

Harald,

<snip>
> two comments:
> - I do not see a requirement that all scenarios use usernames.
> - in "xyz@abc.com", "xyz" is not necessarily an username, and 
> "abc.com" 
> is not necessarily a hostname.
> Even when identity is mediated via the Domain Name System, 
> there may be no host with that name.
</snip>

I provided username just as an example and the identity discussion is
not related to this mail thread. Intention of my example in the mail
thread is to highlight high level API possible from Javascript. 

I'm fine with any identity mechanism as long as multiple RTCWeb servers
are able to interop with the given identity.

Thanks
Partha

> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no] 
> Sent: Monday, August 08, 2011 2:29 PM
> To: Parthasarathi R (partr)
> Cc: Matthew Kaufman; rtcweb@ietf.org
> Subject: Re: [rtcweb] codec and connection negotiation
> 
> On 08/06/11 11:43, Parthasarathi R (partr) wrote:
> > Matthew,
> >
> > I'm seeing two aspects here
> >
> > 1) API: Level of control has to be given to the Javascript 
> programmer.
> > Here, the discussion has to focus on the abstraction by which 
> > application shall be developed easily without much 
> understanding the 
> > protocol intricacies. Even API shall be provided to the extent that 
> > username&  destination host (xyz@abc.com) as a input shall 
> trigger the 
> > session creation with default codec.
> Partha,
> 
> two comments:
> - I do not see a requirement that all scenarios use usernames.
> - in "xyz@abc.com", "xyz" is not necessarily an username, and 
> "abc.com" 
> is not necessarily a hostname.
> Even when identity is mediated via the Domain Name System, 
> there may be no host with that name.
> 
> > 2) Protocol: The protocol selection has to be based on 
> better interop 
> > with other browsers and other VoIP entity also. I'm not 
> favoring for 
> > creating different island of realtime protocol which has to interop 
> > with "n" of gateways.
> >
> > Please read inline for more comments.
> >
> > Thanks
> > Partha
> >
> >
> > -----Original Message-----
> > From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On 
> > Behalf Of Matthew Kaufman
> > Sent: Saturday, August 06, 2011 12:24 AM
> > To: rtcweb@ietf.org
> > Subject: Re: [rtcweb] codec and connection negotiation
> >
> > Now, to follow up on my previous message with a bit of opinion...
> >
> > I think we should not use SDP as the API,
> >
> > <partha>  It is fine to discuss which level of control has to be 
> > provided.</partha>
> >
> >   and we should not have the browser implementing SDP offer-answer.
> > <partha>  I could not see the strong reason for not doing 
> so.</partha>
> >
> > 1. If SDP offer-answer is all that is available to the Javascript 
> > programmer (and server programmer), it becomes very 
> difficult to know 
> > what the full capability set is without complex probing. This 
> > significantly complicates the building of future innovative 
> > applications on top of the browser as platform. Many of the current 
> > applications that show off browser capabilities do so by using 
> > capabilities that were already present for other reasons, 
> and we can 
> > expect the same innovation to occur here, if we provide the tools.
> >
> > 2. Using SDP offer-answer has the advantage of reusing all the IETF 
> > standards work that occurs to define SDP when a new codec 
> comes along.
> > But it also has the *disadvantage* of having to wait for 
> the IETF to 
> > produce these standards, which may be incomplete, or unable 
> to control 
> > parameters which are necessary for web applications.
> > <partha>  I prefer standard over proprietary mechanism because 
> > standard may delay but proprietary is normal uncontrolled and 
> > impossible to interop with other webservers</partha>
> >
> > 3. Anything that is missing in SDP (example: forcing the 
> Opus codec to 
> > "music" mode for encoding) will still need to be exposed as a 
> > Javascript API on the encoder. Thus we end up with a mix of 
> > possibly-conflicting settings that are adjusted via the 
> explicit API and the opaque SDP API.
> > <partha>  It is possible to integrate unknown SDP attribute&  known 
> > SDP attribute using the proper API design. It is the basic 
> requirement 
> > in any SDP stack API today.</partha>
> >
> > 4. Other work in browsers (like recording camera and microphone to 
> > disk) will require the ability to directly control the encoders. If 
> > these APIs exist then there will definitely be conflicting 
> settings. 
> > What happens if you feed in an SDP answer that requires VP8 
> encoding 
> > and then set the encoder to H.264 mode via the Javascript?
> > <partha>  I'm reading your query as how to priortize the 
> value in case 
> > extra environment change the value. It has to be worked out</partha>
> >
> >
> > Matthew Kaufman
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> 
>