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

Silvia Pfeiffer <silviapfeiffer1@gmail.com> Fri, 21 June 2013 23:40 UTC

Return-Path: <silviapfeiffer1@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B304221F9E99 for <rtcweb@ietfa.amsl.com>; Fri, 21 Jun 2013 16:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iso4GD-tEuge for <rtcweb@ietfa.amsl.com>; Fri, 21 Jun 2013 16:40:37 -0700 (PDT)
Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 023BE21F9ED4 for <rtcweb@ietf.org>; Fri, 21 Jun 2013 16:40:36 -0700 (PDT)
Received: by mail-oa0-f43.google.com with SMTP id i7so10051082oag.16 for <rtcweb@ietf.org>; Fri, 21 Jun 2013 16:40:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HbCspx7cOmed6hCUcqv/sLCUwS2GhUTWAKmBs9/Jnkw=; b=yTi38MEA/27/kVJy6Zma4o2Z7XDFgIo7KDfx0fOEoCleu/5/44S7iMRUqSfUsG63VO 1dtVpOmXgZKu9s7nO/oE/4f6qlcjlNF+qqK+rGUIWsJ4q/Vgxyjp6kyMLj7oBmW7Uk/z kJNmISiOIC4iwRcihByGG+gyojxXdVIMNh+moTMrpKhNJR9LbZJrJYs7ebyyYZ+B5jW9 sYLIngijMBAErgbOrL3cIce4052i8npTA2U6pb9PQWRiWxY+jMdq2gzX6CG8FoQvYrud z0wisbuk6JgIT3rUhFsHZPCFr6PPaSzn4PT2YFmSLK2eCShfHznQfrg8dM1NOPQwsbx6 hwwQ==
MIME-Version: 1.0
X-Received: by 10.182.72.170 with SMTP id e10mr4454295obv.62.1371858036217; Fri, 21 Jun 2013 16:40:36 -0700 (PDT)
Received: by 10.76.116.71 with HTTP; Fri, 21 Jun 2013 16:40:35 -0700 (PDT)
Received: by 10.76.116.71 with HTTP; Fri, 21 Jun 2013 16:40:35 -0700 (PDT)
In-Reply-To: <1371826199.49975.YahooMailNeo@web171304.mail.ir2.yahoo.com>
References: <CALiegfkajJPxWZTzjYssP91VW+StStLpxoxGCkjOLKDMUWc0rA@mail.gmail.com> <CABkgnnWfV=5xBaRqAddqUURThs9J4T4+0HK4Ux07VA51r5oC3Q@mail.gmail.com> <CAJrXDUFNGKvWHw-yqeApEdTeuqMNPTDxvdKZ2DuzANmcR2y2CQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <CAJrXDUHCkQSLab2UuY_vWP3Gr8uh+++c9mDq5f4sCpuaK5aeLQ@mail.gmail.com> <51C1B907.8060508@hookflash.com> <CAJrXDUG06jvPvhfNwZ6Puzxj7E4XxELG_fU=S7B_c=tnC9eoNQ@mail.gmail.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <CAJrXDUGOYc_Z_qWD7J0ZzVdfwYOacH_p5PjZEg5aP1LUetffMA@mail.gmail.com> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <CABkgnnWw9anT+h_hnF14nBChS73qpTb31hSM=p2KnGrcRPGRJA@mail.gmail.com> <51C3209B.1030501@alvestrand.no> <CALiegfkEpwxNZL8TU0ofCzRB_Gza+NoSnZpGcM=tuYBOXmHsZQ@mail.gmail.com> <51C335F9.4000900@alvestrand.no> <CALiegfk_wwvdSixFYWpBBdUNfXxmcOwCnRsjyS6J3M9WG_dJCg@mail.gmail.com> <51C38356.3020402@jitsi.org> <CALiegfm1xYpAnmrg=4vx_06RZQTo_RS2nFJoidpoQtjg2kn=Vw@mail.gmail.com> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> <CAJrXDUFFzAdBtQp5mS9Kfgs-N11D7SL22ms=uBg8EcHhaiB_+g@mail.gmail.com> <1371826199.49975.YahooMailNeo@web171304.mail.ir2.yahoo.com>
Date: Sat, 22 Jun 2013 09:40:35 +1000
Message-ID: <CAHp8n2m_ZZy5X1q1emAh2gSQgBQbsPy7TrefRPAZ1NEJa6tB7Q@mail.gmail.com>
From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
To: Bossiel thioriguel <bossiel@yahoo.fr>
Content-Type: multipart/alternative; boundary=001a11c2f3d8ee60f204dfb296b8
Cc: diopmamadou@doubango.org, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jun 2013 23:40:38 -0000

Did you develop a SDP manipulation library that you could share/point us to?
Silvia.
 On 22 Jun 2013 00:50, "Bossiel thioriguel" <bossiel@yahoo.fr> wrote:

> @Peter
> Both audio and video.
> Yes we're doing all you're listing here and even more.
>
>   ------------------------------
>  *De :* Peter Thatcher <pthatcher@google.com>
> *À :* Bossiel thioriguel <bossiel@yahoo.fr>
> *Cc :* diopmamadou@doubango.org; rtcweb@ietf.org
> *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" <bossiel@yahoo.fr> 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 <ibc@aliax.net>
> *À :* Emil Ivov <emcho@jitsi.org>
> *Cc :* "rtcweb@ietf.org" <rtcweb@ietf.org>
> *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 <emcho@jitsi.org>rg>:
> >
> > 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
> <ibc@aliax.net>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>