2013/6/18 Emil Ivov <emcho@jitsi.org>:
> This is exactly what No Plan tries to avoid. It gets you
> interoperability for widely deployed legacy (as in SIP phones, popular
> free SBCs and PSTN) and then it lets you do what you want for all the
> fancy use cases that you are going to come up with. You are in no way
> hampered by SDP this way.

Hi Emil,

I understand your aim and really appreciate your effort (as I said
before, it is much better than fully depending on SDP for any media
operation). However let me expose the following questions, and I would
be very grateful if you answer inline:



* SIP over WebSocket JS app running in the browser (so SIP signaling
is used in the wire).

* I send the initial INVITE with the SDP I retrieve from the local PC
(I am the JS app).

* Later I want to put the remote peer on hold, so I need to send a
re-INVITE with same SDP but some differences:

- Increased SDP version number.
- a=inactive in every m= sections.

* How to do that? As far as I can imagine:

- I need to keep the initial SDP or retrieve it again from the PC, so
I get a string blob. I can "expect" how such a string blob looks, but
I cannot be sure since the same SDP can be represented in multiple
ways.

- So I need to *parse* the SDP at JS level, right? and then I need to
mangle it (for increasing version number and adding a=inactive),
right?.

- And then I must pause/stop my local streams (via PC API call),
generate the re-INVITE with the mangled SDP, and send it to the
remote, right?

- Then the remote peer receives it. Since it is also a SIP JS app, it
must *parse* the SDP at JS level and realize that there are a=inactive
lines in every m= sections, right? Then it could notify the human user
that "the remote has put the call on hold".

- Then, should the remote JS app pass the SDP to its PC? I expect not
(just wondering).

- And finally, the remote peer (its JS SIP app) should also mangle its
initial SDP for increasing the version number and adding a=inactive or
a=recvonly in every m= sections, right? and then send it into a SIP
200 OK.


So, unless I'm fully wrong, a simple use case (hold/unhold application
so widely extended in SIP) requires:

* SDP parsing at JS.
* SDP mangling at JS.

And such a parsing and mangling must be done over a string blob that
can have multiple representations (which depends on each WebRTC
implementation). Even worse, some non-browser-WebRTC-devices may add
a=inactive/sendonly before the m= sections (global SDP attribute), so
my JS app must be ready to detect it, right?


Does it really look nice? IMHO the mechanism you propose makes WebRTC
easy for very-very-very-ultra-basic use cases (basically an
audio/video call with no media changes) and makes it really complex
for implementing any kind of media modification or media application
(i.e. "hold" / "unhold").



Another example:

* I am a powerful SIP conference server which properly implements
WebRTC. I initiate a call to 5 users (running JS SIP app in their
browsers). The initial INVITE has SSRC/MSID fields in the SDP
identifying all the participants, am I right?

* Later, during the conference, I call to another 6th participant and
enter him into the conference, so I need to send a re-INVITE to every
participant with a modified version of the SDP (note that this is SIP
protocol, so I need to use SIP messages to carry the new info about
SSRC/MSID and so on).

* Magically I (the server) create the new SDP with the SSRC/MSID of
the new stream associated to the new participant, and send it into a
re-INVITE to every participant.

* Now a participant receives it and must be able to know what has been
modified (in order to render it in the HTML, i.e. by drawing a new
<video> element). Your draft states that those media modifications
(track additions) don't require re-sending a SDP, but in a SIP context
this must be done with a new SDP, so:

- The JS SIP app needs to *parse* the SDP at JS level, which is a
complex task. It must realize of the new SSRC/MSID (but it should also
detect whether an existing participant has leave the conference).

- Then it draws the new <video> element for showing the video of the
new participant.

- And some WebRTC events would be automatically fired in the remote JS
app due to the Track modifications, which is detected by the WebRTC
stack due to the presence of new SSRC/MSID in the RTP, right?

- And then the remote JS app must create a new SDP (a modified/mangled
version of the SDP in the initial SIP 200 OK response) with these
changes:

  - New version value.
  - Probably new lines/attributes due to the new SSRC/MSID (not sure about it).
  - And all of this at JS level by mangling the string blob.

- And send it back to the conference server in a SIP 200 response.



Well, IMHO this is the most tedious and error prune mechanism I've
ever seen. How to make it simpler?:

- WebRTC PC should not return a SDP (nor expect a SDP string), but
just a JS object with the required attributes.

- The JS app then builds a SDP (if it needs it due to the signaling
protocol as in the examples above).

- In this way the JS app has full control over the SDP associated to
the session and can safely modify it.

- And in 99% of WebRTC use cases (where no SIP is involved) the JS app
does not need to deal with a string blob retrieved from the
PeerConnection.


So, why not let the SDP-game for JS libraries? In this way, a
telco/provider/vendor could offer a JS app that does the required
magic to interop with its media gateways rather than leaving that
responsibility to browsers.


Please take a look to this article which claims more or less the same:

  http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/



Regards.



--
Iñaki Baz Castillo
<ibc@aliax.net>