Re: Why people munge SDP

Nice and evil, +1 ;-)
El 24/07/2013 07:08, "cowwoc" <cowwoc@bbs.darktech.org> escribió:

> 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<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
>
>