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

[Emil Ivov <[e-mail]>]

Hey Iñaki,

On 20.06.13, 23:49, Iñaki Baz Castillo wrote:
> 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.

I am having a problem following what you are trying to achieve here. In 
JsSIP you seem to be going for a full SIP implementation in the browser. 
If this is true and if this WG decides to remove SDP from the API 
surface, then you would need to completely parse SDP in the JS and then 
convert it into API calls. Similarly, when creating offers and answers 
you would need to construct SDP all by yourself.

So I am not sure why the SDP parsing in the current situation is so much 
of a blocker for your use case.

> 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.

Yup, sorry for being silent on that one. Busy days.

My personal take on No Plan SIP interop is that the JS app would take 
the initial SDP out of the browser, send it to a signalling gateway and 
leave that gateway do whatever it wants with it.

Some gateways will resend it with no changes (it is likely that an 
increasing number of endpoints will come to support the kind of SDP that 
comes from browsers). Most GWs will probably handle it as any B2BUA 
handles a call leg. They'd keep a state and possibly convert some of the 
SDP to match what various endpoints expect.

The other option would be indeed to do the same thing in JS. I believe 
this is JsSIP's use case. In that case however, regardless of whether 
you choose Plan A, Plan B, No Plan or CU-RTC-Web, you will inevitably be 
exposed to a fair amount of complexity, parsing and JS magic.

You are, after all, building a SIP stack.

In the above mail you also say:

> 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?

No, with No Plan there are no SSRCs and MSIDs in the SDP that comes from 
the browser.

> * 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).

That's the thing. You don't need that. In Jitsi we do exactly this 
operation with no Offer/Answer signalling. RTP carries enough 
information to process streams and we use upper layer signalling (4575) 
for things such as mapping SSRCs to users and announcing current 
participant list.

Cheers,

Emil




-- 
https://jitsi.org