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

Bossiel thioriguel <bossiel@yahoo.fr> Fri, 21 June 2013 23:47 UTC

Return-Path: <bossiel@yahoo.fr>
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 E81B421F9E37 for <rtcweb@ietfa.amsl.com>; Fri, 21 Jun 2013 16:47:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 2kKQ34sFn0+v for <rtcweb@ietfa.amsl.com>; Fri, 21 Jun 2013 16:47:04 -0700 (PDT)
Received: from nm7-vm1.bullet.mail.ird.yahoo.com (nm7-vm1.bullet.mail.ird.yahoo.com [77.238.189.223]) by ietfa.amsl.com (Postfix) with SMTP id 61A5921F9D87 for <rtcweb@ietf.org>; Fri, 21 Jun 2013 16:46:58 -0700 (PDT)
Received: from [77.238.189.227] by nm7.bullet.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 23:46:57 -0000
Received: from [212.82.98.121] by tm16.bullet.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 23:46:57 -0000
Received: from [127.0.0.1] by omp1058.mail.ir2.yahoo.com with NNFMP; 21 Jun 2013 23:46:57 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 171377.58710.bm@omp1058.mail.ir2.yahoo.com
Received: (qmail 31014 invoked by uid 60001); 21 Jun 2013 23:46:57 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1371858416; bh=5SRgAb0hwgsFZFYPnq46SwitmEtCLDeV2ZMmqZcxBw8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GMfIPbRvpw7CwPTmdq7YFmZ+bhDoPC9q7Pymd6b5gmB/xoI8pnu96rxRSDwpaxC+9mT8cHsr+t0rqWfbEzENN1cORCnRpT356nUNzyUko4TxhwOst+8dquXAdVjv0sc4eWY96qkbhVG7S6GtD1Xo7DMG2matyhbTLv7hsFQ2dYo=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ReeBZ9aGYj0lEQYBmBvUbdoOkZ773mrPV2+PsQKtesWEn/Xc00l/NTxbqyLbO7P1ofj35iDF6rvKYhqGUnSQGRRICqJqBoYwmXRkg5mkZfP27DpvbakFNsf829Yd8XEkl7d8MuD/OE9rCXo59JVTqijVA7M+lxHxdwevCElDpNw=;
X-YMail-OSG: go9Tri8VM1ndQ4qxuNWwMv3q.2nj5yA2SpyHEL8ytdwBBMn SvadsjAF0yt3gn.bq9Y8OSIc52Qwa0DzyevRfj5ewNkZjqeKGcfn1lPjbl8k 84PqmHC0Gjfne9BG5G1yueM0QwVJD5ec5TOTtpe8kYD.I5WEeVyyQ.6R1urx Be87CPSAtFIY3vkaqjN3dByHAlh1fDPO1skdLQAsu3ChtMfzEBH1Jh0WdJGj Ob3Gft6qaJOBGV14SplOA6mkh9pyfQVAV4CdysZZh0YsWY2uG98Ed_Vu2aUo upcu52c7rFvLjpkvM7E_RWFgKdQKQhzRBHJtSvgi2RV2OhgzvOTTeTQbqd3I 9EaDGy4Rfccy.s99_Gk28VVnHgmM094E7gmeB05GTMhYDwLcNhySRQRcLbFr In.sypyPMmt0BFWnwGgtwSmqO0uSoJnQAdJ0QHCudHuTy2t99P16navAhnq7 AMRSbP_wvNPPVhg52_Eihsl5p6gldIf4C31Rnt8AWqkH.pNmRMEnCy5UIgGE 62UjNe8rT3.KKEFU33p78sp9wYXHPA0kegGebcCOe1QQUMC60_e9difcBp6b gEkAD5_Sj8U_nmfyEwTgAJQ0U4RItXsoCK5QnofyLzv._d3Cf9UM4j0m2vBm enZapofGb8iBmR3bHgWaEC09AZipCw8Jkrx0ugUadpb18PDrbi7WxTWw3gai sMLG_OO8CjN0vAQmeTN3IcQZtpqfI3ZMYejK88PIWGEKn7ZflIvNWEQ49C6I wLIORee3AoCw5leXuHaPLHubzlNaJPuoZqf1ZRQMbe4ZmYPNmNlbeblbVEox .kjA-
Received: from [88.179.39.5] by web171303.mail.ir2.yahoo.com via HTTP; Sat, 22 Jun 2013 00:46:56 BST
X-Rocket-MIMEInfo: 002.001, WWVzCmh0dHBzOi8vY29kZS5nb29nbGUuY29tL3Avc2lwbWw1L3NvdXJjZS9icm93c2UvI3N2biUyRnRydW5rJTJGc3JjJTJGdGlueVNEUCUyRnNyYwoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwogRGXCoDogU2lsdmlhIFBmZWlmZmVyIDxzaWx2aWFwZmVpZmZlcjFAZ21haWwuY29tPgrDgMKgOiBCb3NzaWVsIHRoaW9yaWd1ZWwgPGJvc3NpZWxAeWFob28uZnI.IApDY8KgOiBkaW9wbWFtYWRvdUBkb3ViYW5nby5vcmc7IFBldGVyIFRoYXRjaGVyIDxwdGhhdGNoZXJAZ29vZ2xlLmNvbT47ICIBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.148.554
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> <CAHp8n2m_ZZy5X1q1emAh2gSQgBQbsPy7TrefRPAZ1NEJa6tB7Q@mail.gmail.com>
Message-ID: <1371858416.26047.YahooMailNeo@web171303.mail.ir2.yahoo.com>
Date: Sat, 22 Jun 2013 00:46:56 +0100 (BST)
From: Bossiel thioriguel <bossiel@yahoo.fr>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
In-Reply-To: <CAHp8n2m_ZZy5X1q1emAh2gSQgBQbsPy7TrefRPAZ1NEJa6tB7Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1953309981-804715514-1371858416=:26047"
Cc: "diopmamadou@doubango.org" <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
Reply-To: Bossiel thioriguel <bossiel@yahoo.fr>
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:47:09 -0000

Yes
https://code.google.com/p/sipml5/source/browse/#svn%2Ftrunk%2Fsrc%2FtinySDP%2Fsrc



________________________________
 De : Silvia Pfeiffer <silviapfeiffer1@gmail.com>
À : Bossiel thioriguel <bossiel@yahoo.fr> 
Cc : diopmamadou@doubango.org; Peter Thatcher <pthatcher@google.com>om>; "rtcweb@ietf.org" <rtcweb@ietf.org> 
Envoyé le : Samedi 22 juin 2013 1h40
Objet : Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
 


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