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
>