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

[Silvia Pfeiffer <[e-mail]>]

Did you develop a SDP manipulation library that you could share/point us to?
Silvia.
 On 22 Jun 2013 00:50, "Bossiel thioriguel" <[e-mail]> wrote:

> @Peter
> Both audio and video.
> Yes we're doing all you're listing here and even more.
>
>   ------------------------------
>  *De :* Peter Thatcher <[e-mail]>
> *À :* Bossiel thioriguel <[e-mail]>
> *Cc :* [e-mail]; [e-mail]
> *Envoyé le :* Vendredi 21 juin 2013 16h42
> *Objet :* Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
>
> Do you work with video or just audio?
> Do you work with multiple streams/tracks, both send and receive?
> Do you use features such as rtx, fec, and simulcast?
> Simple, single-track, audio-only clients that use SDP for signalling over
> the wire are fairly well served by the current API, as are clients only
> using the data channel.  But doing more advanced things, such as those I
> mention, require significant SDP munging which can be a very slow and
> error-prone experience.
> Your experience may differ from others because they are trying to do
> things that require a lot more SDP munging, which can be quite painful.
> On Jun 21, 2013 2:40 AM, "Bossiel thioriguel" <[e-mail]> wrote:
>
> 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
>
>   ------------------------------
>  *De :* Iñaki Baz Castillo <[e-mail]>
> *À :* Emil Ivov <[e-mail]>
> *Cc :* "[e-mail]" <[e-mail]>
> *Envoyé le :* Vendredi 21 juin 2013 1h24
> *Objet :* Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
>
> 2013/6/21 Emil Ivov <[e-mail]>:
> >
> > 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.
>
> And we will do it very happily because then we will know what
> *exactly* we are sending on-the-wire.
>
>
>
>
> > So I am not sure why the SDP parsing in the current situation is so much
> of
> > a blocker for your use case.
>
> Because regardless I am a SIP-guy, I understand that the main mission
> of WebRTC is to provide realtime communications *for* the WWW, and not
> to enable a new interface for like-telephony-bussines.
>
> Today I'm doing SIP. Tomorrow I may be doing
> [[put_here_a_future_RTC_protocol_not_based_on_SDP]] and then I don't
> want to be constrained by decisions made today that force any future
> RTC protocol to deal with SDP O/A model.
>
> :)
>
>
>
> >> 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
> >>
> > 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.
>
> Yes, but JsSIP creates its own SIP messages to be sent in the wire, so
> we have full control over *what* we create and send. Those SIP
> messages are not provided by the WebRTC API. But for the SDP
> component, JsSIP retreives a SDP blob string from the PC.
>
>
>
>
>
>
>
> >
> > 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.
>
> OK
>
>
> >> * 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.
>
> That is much better than Plan A and Plan B.
>
>
>
> BTW: What would happen in NoPlan if the remote (i.e. a SIP
> gateway/endpoing) sends you a re-INVITE for "hold" purposes and you
> pass the SDP to your PC? or you should not pass the SDP to your PC?
> and if so, what about if the SDP contains updated ICE candidates due
> to remote peer network mobility?
>
>
>
> Thanks a lot for your response.
>
> --
> Iñaki Baz Castillo
> <[e-mail]>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>