Re: [rtcweb] codec and connection negotiation

Sohel Khan <sohel_khan777@yahoo.com> Sat, 06 August 2011 16:58 UTC

Return-Path: <sohel_khan777@yahoo.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 0794821F8548 for <rtcweb@ietfa.amsl.com>; Sat, 6 Aug 2011 09:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.669
X-Spam-Level:
X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76K727Qtdhtb for <rtcweb@ietfa.amsl.com>; Sat, 6 Aug 2011 09:58:02 -0700 (PDT)
Received: from nm20-vm0.bullet.mail.bf1.yahoo.com (nm20-vm0.bullet.mail.bf1.yahoo.com [98.139.213.165]) by ietfa.amsl.com (Postfix) with SMTP id C895021F8545 for <rtcweb@ietf.org>; Sat, 6 Aug 2011 09:58:01 -0700 (PDT)
Received: from [98.139.212.151] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 06 Aug 2011 16:58:22 -0000
Received: from [98.139.212.215] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 06 Aug 2011 16:58:22 -0000
Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 06 Aug 2011 16:58:22 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 401749.1116.bm@omp1024.mail.bf1.yahoo.com
Received: (qmail 17009 invoked by uid 60001); 6 Aug 2011 16:58:22 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312649902; bh=vOSGHEvHUViIa4VilD/YvLtKAd3ePaSv73zuJbyY0CA=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=eOUBBCKymR/E3Hr7CzWi9afQEGDLMJBuY3Dt6sAUBsaLl9vQe+K/y93/Dlyx50lmvOM1/85arBIDYSt4g5YjsCX1SkKKueLRG6lwxFnD1xtjEF2Ga6po9+fsrYpxilGBqr7vJPCL5hvQ7Wmg/l9yH3PsXE+oCS6K1FQSVyFbh40=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=elkvAuJHYGmSSGJ/LSUbTSib3R7ybCDkUV3yq8Jg2E0wNS9UIC/zl6w0/xb0vS8wTy2fcdQ2canwyfRvx/v1ra4tq/KfhSYmSBgIkNoEnUCXv/6lmyy47RJH6MgoM7MhPiJN8JRFCUyCGQvEFgGqYE4m00kJZrCKNqycbIZdEGk=;
X-YMail-OSG: EAMIvRUVM1krSv5HMtiMzUS_LvKOjPNWZHkLvoytNpsdet7 fvuT9FH6LxKhlNIGLR6xd6LvzU9ue3mg80oSC99q4R99KMtndCkygRNGQE0H cFJ.UHv08_8e8mojSspgaIW7c6bf5eK8VJXlarRH8SZ.Mss0WJKns5ZfM0_n SP0sY1LkmhrS_g4V25y08TaH9kpkcd_QI9qtTSOhzoGeKflfuNSq53vtfvej QD6wFnOWxjgyu_d82.ltLMwpnvEV1am9letZzq5IvmN9pqG2aJ8oSqBPpHSF 59cY9Zn5z6sVBX3w9vcN9njqxFdZnCieuqsrcnpLStRfLxCEIvKmUT1rPBv9 dWYvdfU6f5RMW.tCtv30jamjdnZLAZ0pFGw_0IoUbIDjpzQwoIhey8TO2EUV nsje91.irzKo_KHZaJmrv0wWWYd.b08fGn23pt2wn6nut.5w-
Received: from [216.127.113.30] by web162011.mail.bf1.yahoo.com via HTTP; Sat, 06 Aug 2011 09:58:22 PDT
X-Mailer: YahooMailWebService/0.8.113.313619
References: <4E3C377A.5090105@skype.net> <4E3C3C2C.4020808@skype.net> <A11921905DA1564D9BCF64A6430A62390608EBEC@XMB-BGL-411.cisco.com>
Message-ID: <1312649902.16121.YahooMailNeo@web162011.mail.bf1.yahoo.com>
Date: Sat, 06 Aug 2011 09:58:22 -0700
From: Sohel Khan <sohel_khan777@yahoo.com>
To: "Parthasarathi R (partr)" <partr@cisco.com>, Matthew Kaufman <matthew.kaufman@skype.net>, "rtcweb@ietf.org" <rtcweb@ietf.org>
In-Reply-To: <A11921905DA1564D9BCF64A6430A62390608EBEC@XMB-BGL-411.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-370549104-1312649902=:16121"
Subject: Re: [rtcweb] codec and connection negotiation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Sohel Khan <sohel_khan777@yahoo.com>
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: Sat, 06 Aug 2011 16:58:03 -0000

Thanks Matt and Partha for valuable comments and proposals.
The main point here is to create standards specifying methods to exchange desired session capabilities. From various discussions, it appears to me that there are two key options:
1. No SDP in browser. Object oriented and popular script language (e.g., JavaScript) implementation transfers desired session capabilities in between browser and server. The server performs SDP offer/answer in the VoIP core network.
2. SDP in browser. Use IETF SDP offer/answer standards to transfer desired session capabilities from browser to browser with/without core VoIP network.

In my opinion, we will need to create RTCWeb standards for both the options. We can either create one document containing both standards or two separate documents each containing an option. The architecture and use case documents should include both options.

 
Regards,
Sohel Khan


________________________________
From: Parthasarathi R (partr) <partr@cisco.com>
To: Matthew Kaufman <matthew.kaufman@skype.net>; rtcweb@ietf.org
Sent: Saturday, August 6, 2011 5:43 AM
Subject: Re: [rtcweb] codec and connection negotiation

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.

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