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