Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

[Bossiel thioriguel <[e-mail]>]

@Robin
Yes we'll use such API (already said it on another thread). What I'm not supporting is "remove SDP and start from zero".
What you're proposing here represent huge amount of work. I guess you already know it :)


________________________________
 De : Robin Raymond <[e-mail]>
À : Bossiel thioriguel <[e-mail]> 
Cc : "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]> 
Envoyé le : Vendredi 21 juin 2013 14h18
Objet : Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
 



Your point about it being easy to get a demo running I agree, or even 
interfacing with a SIP network.

I can't comment on the difficulty or not of CU-RTCWeb's implementation. 
It does look like CU-RTCWeb has a lot of features/complexity out of the 
gate which is necessary to do a lot of alternative scenarios but might 
cause someone to through up their hands in frustration trying to figure 
out how it all works, especially if you are an integrator of SIP and not
 an implementer.

I conquer whatever solution adopted must be equally as easy for SIP 
developers (even though that is not part of the mandate as I understand 
it). That's why I proposed that I would take it upon myself to lead an 
API proposal that could work for both. The simple "SIP/SDP" case being 
provided as a shim that you could write against if you are a SIP 
integrator (close to the current webrtc as reasonable) but something 
that doesn't break other non-SIP models.

Let me explain why offer/answer breaks other models. Offer/answer 
negotiates akin to "I send out an offer, but whatever you agree on from 
my offer we will use together". Further "if you disagree with my offer, 
we'll roll back to the existing offer". Finally "if we both make an 
offer at the same time, we'll conflict and we'll have to use conflict 
resolution to change our offers". That was true of when I last authored 
X-Lite/X-PRO SIP softphone client so perhaps something has changed since
 then to which I'm not aware, but that's my gross simplification of 
offer/answer.

However, that is absolutely _not_ the only way to negotiate. For 
example, Open Peer for example uses constraints based negotiation. This 
is akin to "if you send me anything, please send me this". The 
difference is that each side is allowed to change what it expects to 
receive without a round trip to the remote party agreeing and without 
risk of rollback. That makes it really easy to update and change what 
you expect without needing the complexities of an offer/answer state 
machine. If one is forced upon us, we'll have to find away around this 
offer/answer mechanism because negotiating is not an option for us - we 
simply don't do it at all. Whatever we do to hack around it will likely 
violate the offer/answer rules.

Offer/answer is wholly not necessary to be mandated as part of WebRTC to
 fulfill the charter but it currently is mandated. I don't want 
something just for "me", but we are forcing an unneeded model of 
negotiation upon JavaScript developers that may not want to adhere to 
that model either (and likely will violate it too, albeit 
unintentionally). Skype has similar objections to offer/answer but I 
can't speak to their negotiation strategy or presume to speak on their 
behalf. If offer/answer were removed as a mandate, you can do so 
yourself in your JavaScript without browser enforcement.

My other issue is that SDP has become an API surface for control, 
properties and extensions. We must remember that the consumer of what we
 produce must be acceptable to the W3C and their members (browser and 
JavaScript implementers) and not SIP integrators. If we are asking 
JavaScript developers to hack/mangle the SDP to do anything beyond 
"place/answer" a call, we are forcing them to learn an entirely new 
ill-defined language called SDP rather than just using a JavaScript API 
which is native to their language constructs.

If we are saying "people shouldn't touch the SDP nor need to" then why 
not have a binary format for the blob exchange that is untouchable? The 
reason we don't encode to binary is because we _expect_ people to have 
to mangle the SDP. That's simply not acceptable in my mind to require 
JavaScript developers to learn SDP. Perhaps this is outside the charter,
 but I don't think it's inside the charter either to mandate learning 
SDP to perform common edge case actions either (e.g. putting media on 
hold). There's a huge gray area here and effectively we are coming up 
with their API for the W3C called "SDP". Should we fail to provide a 
respectable API, they will reject what we have anyway and likely they 
will not come up with SDP as their solution (plus WebRTC will take 
another delay and blow).

The next issue is that SDP is not a well defined format. There is no 
100% sure way to write SDP to be compatible. This means that if we do 
have to mangle SDP, we'll have to do browser, version and platform 
detection to pre-determine what exact formats the SDP will 
generate/parses and have compatibilities for each. We must or we will 
break. This goes against browser philosophy entirely. The IETF might not
 care about that but the W3C will care. But we should care too because 
we cannot be sure that the next browser version update on some random 
platform won't just suddenly break any implementation. What we write 
will expect a certain syntax, and will break and there's no mandate that
 browser vendors come back to us for approval of their extensions they 
want/need. This will make implementations brittle.

The final thing that scares me is all the extensions being proposed to 
make this SDP, for example, BUNDLE. Nothing wrong with the concepts at 
all! But should some vendors start adopting some of these extensions (or
 fork the browser code base to support these extensions), we'll see 
environments where the SDP produced is massively complex, unknown and 
"special". This will be entirely legal since anything goes with SDP but 
will wholly break likely everything that doesn't know about those 
extensions, except those involved in producing those extensions. No 
longer will this be the open web, but a closed web tied to certain 
vendors via extensions. This isn't just some theoretical issue. This is 
already underway with an avalanche with many requests / demands being 
put upon the various browser vendors all with their own competing 
interests / alliances.

With an API model, extensions can be added as additional API, without 
breaking anyone. If you use the "basic" API, you get the same behaviours
 you expect as always even if new features are added later. If you use 
additional APIs, only then do you get the advanced features for the API 
you know about. With SDP, you don't know because their's nothing 
restricting exactly what the SDP expresses locally in advance nor what 
you will receive from a remote party.

Finally, by baking the SDP into the browser, you make it unchangeable. 
If there was issues with the SDP generated/parsing, you'll have to 
mangle the SDP from JavaScript (or from an SBC) to make it work (and you
 will need browser version detection to do that which is something the 
browser vendors are fighting hard to prevent). Were it instead written 
as a JavaScript shim, you could tweak the shim code yourself for 
whatever compatibility you need without waiting for the next browser 
update to fix the issue. Baked in the browser, you are out of luck.

This is why I'm proposing we have a reasonable API for JavaScript using 
their language constructs they already know and are familiar that is 
extensible for the future without more SDP mangling/extensions. Those 
who want to do SDP extensions can do it inside an updatable shim, which 
can be tailored to your specific SIP environment to be 100% compatible 
with little to no risk the browser vendors will break you.

I fully appreciate the need that whatever API is produced is not 
needlessly complex and to ensure the absolutely dead-easy implementation
 exist. I plan to satisfy the dead-easy situation by providing a shim 
written entirely in JavaScript that provides that "80%" of what people 
want, i.e. the current WebRTC API which is easy starting point for many 
SIP integrators. Those of us who in the 20% who don't use SIP can bypass
 (or modify) the shim to do what they want/need.

So I ask you, if I were to propose such a solution (and provide 
examples), would you be open minded to using a shim that provides your 
easy use case rather than forcing SDP inside of SDP being baked into 
browser binary? Do you also understand my objections to using SDP with 
offer/answer?

-Robin


Bossiel thioriguel
>21 June, 2013 
5:40 AM
>Hello,
>
>
>I'm registered on this group since the beginning but this is my first post 
on this thread. So, I presente myself: Mamadou DIOP and I'm working for 
Doubango Telecom where we're building SIP endpoints, gateways, 
TelePresence/Telemedicine systems... all focused on SIP/IMS/LTE/RCS-e 
and open source.
>
>
>What I'm talking about is not just feeling but something I've experienced.
>
>
>Using the current WebRTC we have managed to *easily* build almost all kind of applications: click-to-call, SIP/IMS clients, gateways to PSTN, MCUs, 
Telemedicine systems...and haven't seen any major issue. It's true that 
it's not natural to "hack" a blob SDP to implement features like hold/resume, media update, early 
media ... but it works and there are demo applications showing it. If 
there is something more beautiful we just want to see it in action and 
test it.
>
>
>Many participants here have said that what 
they want is something close to CU-RTC-WEB. Don't really know if they 
tried to build applications using it or not but in my case I have.
>My reference: http://html5labs.interoperabilitybridges.com/prototypes/cu-rtc-web-roaming/cu-rtc-web-roaming/info
>First on Windows 8 but 
haven't gone far as there is no documentation to get started. Then, OSX 
and luckily there was a readme with two links for testing (only one 
work). You need to open 3 pages (1 master, 2 slaves) and check "send 
audio" on both slaves to header sound. Many javascript files and no 
documentation. It's said on these blogs that interop with SIP networks 
is easy but it's not my feeling ...I just want to see one :)
>
>
>I don't really understand the issue with the O/A model. 
SDP or not SDP you'll always offer something and answer something. I'm I missing?
>
>
>For the current WebRTC, 
Google open sourced their engine, produced drafts, a working 
implementation in chrome, a mailing-list to help developers, demo 
applications, documentation... we just want to see the same from any 
company asking to rewrite everything.
>
>
>I'm not 
saying the current WebRTC implementation is perfect but I have seen my 
14 year old nephew developing an audio/video chat for his homework :)
>
>
>Regards
>