That's exactly part of the trouble. People thinking we need a 
signaling/negotiation framework at all for media. We don't. We don't 
need to replace SDP with anything. It's just not necessary at all. Yes, 
SIP guys will need to create and parse SDP compatible with their 
networks, but it's still better to do that from a dynamic updatable 
language like JavaScript than hard coding all that inside the browser. 
They don't need the browser to generate something as pre-built into the 
hardcoded binary that generates serialized formats for the interface to 
the mechanics underneath. Likewise, we don't need a JSON version nor an 
XML version of SDP.

Start treating the media and RTC like an OS API and not like a signaling 
layer. Sure, restrictions for security reasons must exist (like 
requiring ICE agreement on the wire) but beyond that the sky should be 
the limit. If we have a programmatic interface to the lower layer 
components, we can wrap it up with our own JavaScript in any method at a 
higher level someone might want. JavaScript is a powerful language, so 
there's no reason we couldn't do some really cool stuff. JSEP? No 
problem. Traditional SIP/SDP? Check. XMPP? Yup. However Skype 
negotiates? Yup. Open Peer (and other future protocols) with stateless 
negotiation? Check. Custom silo protocol? Yup.

You have sources, like camera's / microphones. You need to be able to to 
get information about the formats available to be opened.

You have outputs like screens and speakers.

You have a mixer where you can pin in/out the various sources.

You have codecs.

You have media streams going in and coming out from a mixer where you 
can map media to RTP streams.

You have DTLS connections for arbitrary data.

I'm sure I'm missing something in the 5 minutes it took to write that 
but the point is that this isn't rocket science and it's not difficult 
to wrap the basic constructs like those with a decent API (even if the 
details can, should and will be argued but have little impact on the 
global scheme of things [unlike SDP]) and much easier to come to 
decisions because they are well known constructs with limited scopes. 
With JavaScript shims as needed, we can build out anything out of those 
building blocks we might dream up. Stick to the core of what each part 
is supposed to do and leave the rest to the higher level. Let's define 
those APIs and let's stick to the RTC layer consisting of only: 
STUN/ICE/TURN, DTLS, RTP/RTCP and security/encryption requirements (and 
any other low-level data/media level requirements). Get rid of this 
inane requirement for SDP and offer/answer negotiation which is just a 
road block and hinderance and doesn't add much value but whose long term 
costs/consequences are huge!

Those are all lower level APIs that can entirely be done without a 
signaling protocol like SDP with offer/answer at all. Not everyone does 
SDP. Nor does everyone want to SDP, and future signaling protocols 
likely won't want to do SDP.

The trouble currently with WebRTC is we have virtual no low level API 
control and only way to interface to those components is frequently 
exclusively via SDP and it forces everyone to use this horrifically 
monolithic do-everything serialized format and offer/answer round trip 
to boot to affect change instead of allowing lower level control over 
what's going on in each component; and control over the media mapping 
without requiring a round trip like offer/answer requires...

This decision was made primarily by the industry SIP folks (some of 
which have changed their minds since), many of whom still mistakenly 
believe that without SDP there is no compatibility with WebRTC, or 
believe that it produces greater compatibility, or believe we must have 
"something" common to signal media information; all of which is 
completely untrue. I really do want to hear the rational in requiring 
SDP and offer/answer. I don't see it as another other than a major 
hinderance towards compatibility and innovation rather than in favour of 
it (including for the SIP guys).

As I understand it, the resistance to opening the discussion again comes 
down to fear. Because we are afraid that if we decide to reopen this can 
o' worms that we won't be able to have consensus again and WebRTC will 
never happen. The fear comes from knowing people would never agree to 
another media related signaling format (correctly, as it's not even 
needed and counter productive to have one). I mean no disrespect when I 
ask this but is the argument against talking about it: "Let's all stick 
to something really bad because it's better than nothing at all, since 
we won't be able to come to a new agreement on a replacement to SDP 
(when we don't really need a replacement)?"

I'm really trying (hard) to understand the resistance to removing SDP or 
even discussing about something so fundamentally bad and flawed as SDP 
with offer/answer! What are the vested interests and rational in keeping 
something this bad as this intact?

I want WebRTC to succeed, but, sorry, SDP (in my opinion) has got to go.

-Robin


> Adam Roach <mailto:adam@nostrum.com>
> 18 June, 2013 4:22 PM
>
>
> Many men have died on that hill. I'm still sad about the colossal time 
> and talent sink represented by these 61 pages:
>
> http://tools.ietf.org/id/draft-ietf-mmusic-sdpng-08.txt
>
> I have no reason to think that burning WebRTC down the the ground and 
> starting over would produce a different result. If anything, the 
> issues are more contentious now than they were in 2005.
>
> /a