Re: Signaling & peerconnection API questions

On Jul 19, 2011, at 4:20 , Harald Alvestrand wrote:

> On 07/18/11 23:07, Ian Hickson wrote:
>> On Mon, 18 Jul 2011, Prakash wrote:
>>> Excellent. Thanks Ian. I was most concerned about interop with non
>>> browser/existing systems. If the message is not opaque, then anyone
>>> should be able to translate it if needed.
>> Indeed. Compatibility with SIP in particular was high on my mind when
>> designing this API; the intent is that it should be almost trivial to do a
>> SIP gateway for this stuff. (I mean, as trivial as this stuff can get,
>> anyway...)
>> 
> FWIW, this is one area where Ian and I still don't agree; I think SDP is a representation format we need to avoid, and that we're better off with a JSON-based format where the relevant information can be easily transformed into SDP when needed.
> 
> This is what the current Google WebRTC implementation supports.
> 
> We fully agree that the format needs to be
> a) documented
> b) possible to map into SDP for gatewaying purposes
> 
>              Harald
> 


I'm going to argue something very counter intuitive here but I am in the Ian camp on SDP vs creating something new. I am going to argue that SDP is an awful design for negotiation of media and that is why we should use it. 

I've worked on multiple projects mapping SDP to something else. They are all frustrating. You have two choices at the hight level. 

1) make the new mapping semantically exactly the same as SDP so as new parts are added to SDP, they are automatically added to the new things. Anything that can be done in the new mapping can be done in SDP and visa versa. 

2) try and take the semantics of SDP and map the useful parts (a subset) to the new thing and have the new thing be a more rational design than SDP. 

3) try and make something that SDP can be mapped into but does more than SDP to deal with the limitations of SDP

The problem with 1 is that you get all the pain of SDP and at the same time force yourself to have yet another thing you know how to parse. None of the existing tools support it. And given all you are doing ins syntax manipulations, it ends up with no real advantage over SDP. When implementations get the mapping to and from SDP wrong, it becomes much harder to debug and track down what went wrong. The hard part of SDP is not parsing it, it is understanding what it means in a given context so there is no real gain to if the delimiters are , and space, or curly brackets, or angle brackets. 

The problem with 2 is that SDP is constantly changing it it is impossible to keep in sync. New codecs constantly add new parameters - particularly any advanced video codec. If for each new think you have to wait for the SDP to get done, then argue about if that part should be in the new protocol, then how to map it in, it just delays adding new things with very little real gain. Because of the fundamental limitations of SDP, and the fact that you have to be mappable to a subset of SDP, you can't really do anything better than what SDP does. You end up with something that by being a subset of SDP, is at best just as bad as SDP and is at worst worse than SDP. 

The problem with 3 is that it can't be mapped to SDP. At first glance this sounds OK, like sure, basic stuff will work with SDP and the advanced stuff won't and eventually we will have a transition path away from SDP. But SDP has to flow both direction in offer / answer. The problem is no one wants to be the stuff that does not work with the old SDP as there is always a use case for the advanced stuff in the old SDP only systems. So no one does the new stuff that won't work with SDP and instead just keeps extending SDP. I'm sure that many people remember the IETF trying to fix this whole problem with SDP NG (next gen) - that effort failed because it requirement too many devices to change before it was useful. It was easier to do small changes that allowed things to work with existing systems. This was just yet another example of how the internet ends up moving from where it is to some local optimum where each step of the say is better yet failed to find the global optimum.

In defense of SDP, using it for an Offer/Answer exchange was way outside what it was designed to do and it's not surprising the semantics and syntax are not ideal for this. However, with the audition of the SDP Capability Negotiation, we have figured out how to make SDP work for a very wide range of applications and media types. It's not ideal, but it better than the alternatives and if you want to be mappable both direction to SDP, Oran's Law of Gateways more or less says you can't beat SDP.

From a practical point, doing something new is going to be a huge chunk of work with no gain.

Received on Tuesday, 19 July 2011 23:30:24 UTC