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

[Iñaki Baz Castillo <[e-mail]>]

2013/6/20 Harald Alvestrand <[e-mail]>:

>> IMHO it would be much more interesting a JS demo that takes the SDP
>> generated by Chrome and "converts" it into a Jingle XML session
>> description (I mean XEP-0167), and that can interoperate (via XMPP
>> over WebSocket or whatever) with a XMPP/Jingle endpoint by
>> incrementally sending/receiving transport (ICE stuff) and media
>> capabilities (as XEP-0167 allows) in different XMPP messages.
>
> You find it interesting. I'm sure you have a particular XMPP/Jingle
> endpoint in mind that you want to connect to.
>
> Create one. Or try, and share with us why it did not work.

It will not work (with the current SDP-based model) because it will
require that my JS code parses the SDP blob retrieved from the
browser, extracts all the fields/attributes and "exports" them into
some XML bodies.

What is the problem here? SDP itself because there are tons of
possible valid representations for the *same* session description
information into SDP blobs that look different (but mean the same).
And the problem is that we don't know how the SDP blob retrieved from
current browser model and version will look. My JS code could properly
parse a SDP blob generated by Chrome 35 but may fail in Chrome 36 or
Firefox 29 due to "cosmethic" changes in the SDP.

If this statement is not true (I hope I don't need to code a
XMPP/Jingle endpoint to prove it...), why are there so many SDP
compatibility issues in widely deployed SDP-based protocolos (i.e.
SIP)? Why do SBCs exist? (I know "fixing-SDP-compatibility-issues" is
not their only feature, but it is one of them).




>> And it would also be interesting a JS demo that interoperates with a
>> SIP gateway and is able to perform the "hold" / "unhold" feature so
>> widely extended in SIP world (via reINVITE with a=inactive/sendonly
>> and 200 "OK" with a=inactive/recvonly).
>
> We have people who have demonstrated interoperability with SIP softphones.
> Some of them are on this list.
> Can they tell us what happened when they tried?

Which kind of interoperability? Let me guess it:

- Initial INVITE with SDP.
- 200 OK response with SDP.
- Lot of applause when the browser produces audio.
- BYE.

In JsSIP we are getting frustrated trying to implement the "hold" /
"unhold" feature because it requires SDP parsing and mangling. Sending
a re-INVITE with a modified SDP (now with a video track enabled) seems
to work (after lot of pain) but we still miss a reliable API to know
what the new SDP means. Instead we need to parse the SDP to detect
global (or per m=) line attributes like "a=inactive" or "a=sendonly"
etc etc. It's really painful.


BTW I don't know wheter you support PlanA, PlanB or NoPlan, but I did
a question (in this case about NoPlan) for which I got no response,
and honestly I would like to see it replied regardless the solution
uses PlanA, PlanB or NoPlan model:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg07871.html

I would *really* appreciate a response to that mail (with any Plan as
solution), really.



Best regards.



--
Iñaki Baz Castillo
<[e-mail]>