Re: [rtcweb] codec and connection negotiation

[Henry Sinnreich <[e-mail]>]

+1

Thanks, Henry


On 8/6/11 11:58 AM, "Sohel Khan" <[e-mail]> wrote:

> 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) <[e-mail]>
> To: Matthew Kaufman <[e-mail]>; [e-mail]
> 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 ([e-mail]) 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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Matthew Kaufman
> Sent: Saturday, August 06, 2011 12:24 AM
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb