Re: Why people munge SDP

On 24/07/2013 12:01 AM, Cullen Jennings (fluffy) wrote:
> At the WebRTC expo I got a chance to ask people if they needed to munge SDP in the JS API
>
> The most common answer I got was there were not munging it.
>
> A few people were doing it because at one point they needed to to work around bugs that have been fixed in current Firefox and Chrome. (need of a=crypto line being the main one). I'm not going to bother to mention ones that are already fixed.
>
>
> The most common reason was the echo cancelation problem in Chrome. I have not looked into this personally but evidently it is https://code.google.com/p/webrtc/issues/detail?id=827 ). As people explained it to me, when using OPUS in chrome, the echo cancelation does not really work. The solution to this is take the offer, which does not include isac, and add isac to it because the echo cancelation does work with isac.
>
> So lets think about this a bit
>
> 1) I'm sure that Chrome will fix the echo cancelation problem (it may already be fixed). This code is being sent out to folks early as it is in development. I think it is good Google is releasing it early instead of waiting to have it all polished and fully tested before releasing it.
>
> 2) applications going and adding a codec that the browser has not said it will support in the offer is, well, pretty nuts. I can imagine people doing it as an evil hack to get around using version of browsers that are still under development for specs that are not done.
>
> I do not think the above is problem standards need to fix. It does illustrate they types of hacks an advanced API usage can do but it's clearly not something we expect any developer to have to do in the future.
>
>
> The next issues that got mentioned was setting bandwidth. I think we should add a constraint, or some API, to be able to do this. It is a bit more complex to add because we likely need to set it on a track not a stream.
>
>
> The other issue I have heard is changing the prefer end order of codecs. I think the current JSEP draft explicitly supports this but if people feel they want to do that without parsing SDP, there would be designs that could do that. I'm not arguing for or against any of them, I'm just trying to move the conversation from gauge generalities of "nothing works" to specific items that we, as a WG, can decide if we want to fix in 1.0 or not.
>
>
> I'm happy to hear about other case (and I know some others have been sent to this list)

     I've got a (potentially evil) idea for speeding this up.

     Add an experimental flag in Chrome that SDP mutability. Set SDP as 
immutable by default in Canary, and as mutable in Stable. In theory, 
developers will run into problems with Canary and let you know their 
legitimate use-cases, but production deployments will not be affected 
since they use Stable.

Gili

Received on Wednesday, 24 July 2013 05:07:12 UTC