Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
Bossiel thioriguel <bossiel@yahoo.fr> Fri, 21 June 2013 14:58 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 8FEA611E8199 for <rtcweb@ietfa.amsl.com>; Fri, 21 Jun 2013 07:58:58 -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 vNFyB-OxKzmL for <rtcweb@ietfa.amsl.com>; Fri, 21 Jun 2013 07:58:53 -0700 (PDT)
Received: from nm14-vm1.bullet.mail.ird.yahoo.com (nm14-vm1.bullet.mail.ird.yahoo.com [77.238.189.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7861111E8198 for <rtcweb@ietf.org>; Fri, 21 Jun 2013 07:58:52 -0700 (PDT)
Received: from [77.238.189.233] by nm14.bullet.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 14:58:49 -0000
Received: from [212.82.108.112] by tm14.bullet.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 14:58:49 -0000
Received: from [127.0.0.1] by omp1021.mail.ird.yahoo.com with NNFMP; 21 Jun 2013 14:58:49 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 158072.91868.bm@omp1021.mail.ird.yahoo.com
Received: (qmail 60700 invoked by uid 60001); 21 Jun 2013 14:58:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1371826728; bh=0cl65c/AKH+wLz64xqVgWbub1kkdgDND1XKjIQ+PSZ0=; 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=G+cqUqK6er/y++jPnGIJfZTJC91j5/WYnqtVlxFJ/TXute/ZQql3/Ic7Y2ht4haUfsVjkcyRZhJz4gxmYwPcbrcNRDuTmTfLiqQzNhZ7RajXcGcxZX+voVpKa4e0I6Uz/GNFyNXodl5wqfODyPsBzlSyKG7xb5cIyib9HLoWe0c=
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=GkQfqddMhoSWI/IXdhUJCUAvhCHtxAQ0byG/olP1e3JnlGSVH3yBQM7S6stWzyDRq2Lkh01OtBw6sWybyOOqEPGsdtuoVfNapPAP4FyAsGoSvmMb9YbI4yC1w2JfgBwDEP0dxjcKJ1/JkVltixFe1jjhiPRntBoE1g0+0VKYcKQ=;
X-YMail-OSG: Unzq3FUVM1lChGYoamD8KJR.1OcwJio062oRgvfIBxDrn6f lMBW8NPvsSaqHA86WVytmYT6WXIU0qavZIBVD1mOyHsJecEXy3LHPuX2g15O qjrDE7eS29a6q__rDRsBB8.nIn6Zcz4kV.rY81YKSbvcfORSrYTj9XjfCQ_K 5GfRJ8I53bk1_78loEz5sAFGTlT62anyzWWwixwlhpS97vwB0LzswiHB9Iki wysVdSfj3mphC6inOImgTt5BkcBPmIAQ_ifjonl4gQ5ncwCZkAjwKrYoagTt AEI5UKkLLbq9XUsyucKdH66b3Frl1aC1d9uTNN7TaKwZh.44sbZcuOwU5xIn aD51FcHrZE1_gFqVpuWztOQo6Tkr3sYTw1GFUhDOKj0nJ4iIrm5wqBMSRP97 IFie7dfNm9J2fZum7WyjW0axDYNvhIkSBSdAWprbMVS754ZblKQVTBaWpDHb XRkYuNKtZ2RvjY7Qxj.AUN1keLqFYM71nKyGmYhjO8GN47i5_ApbE1MKdgYU l3r4tII38LBrr_9qTamsfkXotHopxnSISOnswaTNGEC.GRcU4h7QWzh.ZfR_ 82lZ_XKHwOSGRHzNEX5vovw9HzfagV2rQCWIjiAO5zwKZ5lJ36J2Y5tGCtOt i48K8QNpOiKtcaFvqXgQe7ZetqWTQP.zDaxDblK9pNOadhG.F1GhihjYNr0s 7mF3NQgAu3uoPvr4d3YJoE0VYfOw-
Received: from [88.179.39.5] by web171304.mail.ir2.yahoo.com via HTTP; Fri, 21 Jun 2013 15:58:48 BST
X-Rocket-MIMEInfo: 002.001, QFJvYmluClllcyB3ZSdsbCB1c2Ugc3VjaCBBUEkgKGFscmVhZHkgc2FpZCBpdCBvbiBhbm90aGVyIHRocmVhZCkuIFdoYXQgSSdtIG5vdCBzdXBwb3J0aW5nIGlzICJyZW1vdmUgU0RQIGFuZCBzdGFydCBmcm9tIHplcm8iLgpXaGF0IHlvdSdyZSBwcm9wb3NpbmcgaGVyZSByZXByZXNlbnTCoGh1Z2UgYW1vdW50IG9mIHdvcmsuIEkgZ3Vlc3MgeW91IGFscmVhZHkga25vdyBpdCA6KQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBEZcKgOiBSb2JpbiBSYXltb25kIDxyb2JpbkBob29rZmxhc2gBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.148.554
References: <CALiegfkajJPxWZTzjYssP91VW+StStLpxoxGCkjOLKDMUWc0rA@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> <51C4447B.6020709@hookflash .com>
Message-ID: <1371826728.58934.YahooMailNeo@web171304.mail.ir2.yahoo.com>
Date: Fri, 21 Jun 2013 15:58:48 +0100
From: Bossiel thioriguel <bossiel@yahoo.fr>
To: Robin Raymond <robin@hookflash.com>
In-Reply-To: <51C4447B.6020709@hookflash.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1470824145-821007945-1371826728=:58934"
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 14:58:58 -0000
@Robin Yes we'll use such API (already said it on another thread). What I'm not supporting is "remove SDP and start from zero". What you're proposing here represent huge amount of work. I guess you already know it :) ________________________________ De : Robin Raymond <robin@hookflash.com> À : Bossiel thioriguel <bossiel@yahoo.fr> Cc : "diopmamadou@doubango.org" <diopmamadou@doubango.org>; "rtcweb@ietf.org" <rtcweb@ietf.org> Envoyé le : Vendredi 21 juin 2013 14h18 Objet : Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened Your point about it being easy to get a demo running I agree, or even interfacing with a SIP network. I can't comment on the difficulty or not of CU-RTCWeb's implementation. It does look like CU-RTCWeb has a lot of features/complexity out of the gate which is necessary to do a lot of alternative scenarios but might cause someone to through up their hands in frustration trying to figure out how it all works, especially if you are an integrator of SIP and not an implementer. I conquer whatever solution adopted must be equally as easy for SIP developers (even though that is not part of the mandate as I understand it). That's why I proposed that I would take it upon myself to lead an API proposal that could work for both. The simple "SIP/SDP" case being provided as a shim that you could write against if you are a SIP integrator (close to the current webrtc as reasonable) but something that doesn't break other non-SIP models. Let me explain why offer/answer breaks other models. Offer/answer negotiates akin to "I send out an offer, but whatever you agree on from my offer we will use together". Further "if you disagree with my offer, we'll roll back to the existing offer". Finally "if we both make an offer at the same time, we'll conflict and we'll have to use conflict resolution to change our offers". That was true of when I last authored X-Lite/X-PRO SIP softphone client so perhaps something has changed since then to which I'm not aware, but that's my gross simplification of offer/answer. However, that is absolutely _not_ the only way to negotiate. For example, Open Peer for example uses constraints based negotiation. This is akin to "if you send me anything, please send me this". The difference is that each side is allowed to change what it expects to receive without a round trip to the remote party agreeing and without risk of rollback. That makes it really easy to update and change what you expect without needing the complexities of an offer/answer state machine. If one is forced upon us, we'll have to find away around this offer/answer mechanism because negotiating is not an option for us - we simply don't do it at all. Whatever we do to hack around it will likely violate the offer/answer rules. Offer/answer is wholly not necessary to be mandated as part of WebRTC to fulfill the charter but it currently is mandated. I don't want something just for "me", but we are forcing an unneeded model of negotiation upon JavaScript developers that may not want to adhere to that model either (and likely will violate it too, albeit unintentionally). Skype has similar objections to offer/answer but I can't speak to their negotiation strategy or presume to speak on their behalf. If offer/answer were removed as a mandate, you can do so yourself in your JavaScript without browser enforcement. My other issue is that SDP has become an API surface for control, properties and extensions. We must remember that the consumer of what we produce must be acceptable to the W3C and their members (browser and JavaScript implementers) and not SIP integrators. If we are asking JavaScript developers to hack/mangle the SDP to do anything beyond "place/answer" a call, we are forcing them to learn an entirely new ill-defined language called SDP rather than just using a JavaScript API which is native to their language constructs. If we are saying "people shouldn't touch the SDP nor need to" then why not have a binary format for the blob exchange that is untouchable? The reason we don't encode to binary is because we _expect_ people to have to mangle the SDP. That's simply not acceptable in my mind to require JavaScript developers to learn SDP. Perhaps this is outside the charter, but I don't think it's inside the charter either to mandate learning SDP to perform common edge case actions either (e.g. putting media on hold). There's a huge gray area here and effectively we are coming up with their API for the W3C called "SDP". Should we fail to provide a respectable API, they will reject what we have anyway and likely they will not come up with SDP as their solution (plus WebRTC will take another delay and blow). The next issue is that SDP is not a well defined format. There is no 100% sure way to write SDP to be compatible. This means that if we do have to mangle SDP, we'll have to do browser, version and platform detection to pre-determine what exact formats the SDP will generate/parses and have compatibilities for each. We must or we will break. This goes against browser philosophy entirely. The IETF might not care about that but the W3C will care. But we should care too because we cannot be sure that the next browser version update on some random platform won't just suddenly break any implementation. What we write will expect a certain syntax, and will break and there's no mandate that browser vendors come back to us for approval of their extensions they want/need. This will make implementations brittle. The final thing that scares me is all the extensions being proposed to make this SDP, for example, BUNDLE. Nothing wrong with the concepts at all! But should some vendors start adopting some of these extensions (or fork the browser code base to support these extensions), we'll see environments where the SDP produced is massively complex, unknown and "special". This will be entirely legal since anything goes with SDP but will wholly break likely everything that doesn't know about those extensions, except those involved in producing those extensions. No longer will this be the open web, but a closed web tied to certain vendors via extensions. This isn't just some theoretical issue. This is already underway with an avalanche with many requests / demands being put upon the various browser vendors all with their own competing interests / alliances. With an API model, extensions can be added as additional API, without breaking anyone. If you use the "basic" API, you get the same behaviours you expect as always even if new features are added later. If you use additional APIs, only then do you get the advanced features for the API you know about. With SDP, you don't know because their's nothing restricting exactly what the SDP expresses locally in advance nor what you will receive from a remote party. Finally, by baking the SDP into the browser, you make it unchangeable. If there was issues with the SDP generated/parsing, you'll have to mangle the SDP from JavaScript (or from an SBC) to make it work (and you will need browser version detection to do that which is something the browser vendors are fighting hard to prevent). Were it instead written as a JavaScript shim, you could tweak the shim code yourself for whatever compatibility you need without waiting for the next browser update to fix the issue. Baked in the browser, you are out of luck. This is why I'm proposing we have a reasonable API for JavaScript using their language constructs they already know and are familiar that is extensible for the future without more SDP mangling/extensions. Those who want to do SDP extensions can do it inside an updatable shim, which can be tailored to your specific SIP environment to be 100% compatible with little to no risk the browser vendors will break you. I fully appreciate the need that whatever API is produced is not needlessly complex and to ensure the absolutely dead-easy implementation exist. I plan to satisfy the dead-easy situation by providing a shim written entirely in JavaScript that provides that "80%" of what people want, i.e. the current WebRTC API which is easy starting point for many SIP integrators. Those of us who in the 20% who don't use SIP can bypass (or modify) the shim to do what they want/need. So I ask you, if I were to propose such a solution (and provide examples), would you be open minded to using a shim that provides your easy use case rather than forcing SDP inside of SDP being baked into browser binary? Do you also understand my objections to using SDP with offer/answer? -Robin Bossiel thioriguel >21 June, 2013 5:40 AM >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 >
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Robin Raymond
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Roman Shpount
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Alexandre GOUAILLARD
- [rtcweb] Requesting "SDP or not SDP" debate to be… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Erik Lagerway
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Ted Hardie
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Adam Roach
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Matthew Kaufman (SKYPE)
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Robin Raymond
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Martin Thomson
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Roman Shpount
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Robin Raymond
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Christer Holmberg
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Christer Holmberg
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Christer Holmberg
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Robin Raymond
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Matthew Kaufman
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Priorities - Was: Requesting "SDP or… Hutton, Andrew
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Matthew Kaufman
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Matthew Kaufman (SKYPE)
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Robin Raymond
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Matthew Kaufman (SKYPE)
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Matthew Kaufman
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Christer Holmberg
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Robin Raymond
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Martin Thomson
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Christer Holmberg
- [rtcweb] Priorities - Was: Requesting "SDP or not… Hutton, Andrew
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Harald Alvestrand
- Re: [rtcweb] Priorities - Was: Requesting "SDP or… Roman Shpount
- Re: [rtcweb] Priorities - Was: Requesting "SDP or… Matthew Kaufman (SKYPE)
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Priorities - Was: Requesting "SDP or… Hutton, Andrew
- Re: [rtcweb] Priorities - Was: Requesting "SDP or… Iñaki Baz Castillo
- Re: [rtcweb] Priorities - Was: Requesting "SDP or… Peter Thatcher
- Re: [rtcweb] Priorities - Was: Requesting "SDP or… Hutton, Andrew
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Harald Alvestrand
- Re: [rtcweb] Priorities - Was: Requesting "SDP or… Bernard Aboba
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Matthew Kaufman
- Re: [rtcweb] Priorities - Was: Requesting "SDP or… Bernard Aboba
- Re: [rtcweb] Priorities - Was: Requesting "SDP or… Richard Barnes
- Re: [rtcweb] Priorities - Was: Requesting "SDP or… Robin Raymond
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Matthew Kaufman
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Priorities - Was: Requesting "SDP or… Hutton, Andrew
- Re: [rtcweb] Priorities - Was: Requesting "SDP or… Parthasarathi R
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Emil Ivov
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Bossiel thioriguel
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Bossiel thioriguel
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Hutton, Andrew
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Hutton, Andrew
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Robin Raymond
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Robin Raymond
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Bossiel thioriguel
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Bossiel thioriguel
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Iñaki Baz Castillo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Roman Shpount
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Roman Shpount
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Hutton, Andrew
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Matthew Kaufman (SKYPE)
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Silvia Pfeiffer
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Bossiel thioriguel
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Silvia Pfeiffer
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Roman Shpount
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Roman Shpount
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Martin Thomson