Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]
Roman Shpount <roman@telurix.com> Thu, 08 September 2011 15:33 UTC
Return-Path: <roman@telurix.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 B7DF121F8B92 for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 08:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 kl5V-NktHaAl for <rtcweb@ietfa.amsl.com>; Thu, 8 Sep 2011 08:33:53 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D954D21F8B91 for <rtcweb@ietf.org>; Thu, 8 Sep 2011 08:33:52 -0700 (PDT)
Received: by yxj20 with SMTP id 20so848405yxj.31 for <rtcweb@ietf.org>; Thu, 08 Sep 2011 08:35:45 -0700 (PDT)
Received: by 10.151.5.21 with SMTP id h21mr1038426ybi.438.1315496145117; Thu, 08 Sep 2011 08:35:45 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id u19sm414349ybm.4.2011.09.08.08.35.44 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Sep 2011 08:35:44 -0700 (PDT)
Received: by yxj20 with SMTP id 20so848374yxj.31 for <rtcweb@ietf.org>; Thu, 08 Sep 2011 08:35:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.62.232 with SMTP id b8mr1300015pbs.523.1315496143245; Thu, 08 Sep 2011 08:35:43 -0700 (PDT)
Received: by 10.68.43.136 with HTTP; Thu, 8 Sep 2011 08:35:43 -0700 (PDT)
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0989@sonusinmail02.sonusnet.com>
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <A444A0F8084434499206E78C106220CA0B00FDB34D@MCHP058A.global-ad.net> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com> <101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <4E668FB3.9020601@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F08FE@sonusinmail02.sonusnet.com> <4E67AD3D.9000005@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F090F@sonusinmail02.sonusnet.com> <4E686663.1050900@alvestrand.no> <2E239D6FCD033C4BAF15F386A979BF510F0989@sonusinmail02.sonusnet.com>
Date: Thu, 08 Sep 2011 11:35:43 -0400
Message-ID: <CAD5OKxtaGMuzTsRV2YJ6-UDRM4zGUK6F1h5cpp6XNKc-eR=-3w@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
Content-Type: multipart/alternative; boundary="bcaec539618052505004ac6fd09b"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote recording - RTC-Web client acting as SIPREC session recording client]
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: Thu, 08 Sep 2011 15:33:54 -0000
Partha, What I am failing to understand is what you plan to use SIP for. SIP would be useful to call a SIP end point on the public IP or behind the same NAT. If you want to call another SIP end point behind NAT, especially if you need to use TCP to send ICE offers or security with TLS, you will need an assistance of some type of server on the public IP. In order for this to work both server and the client will need to implement something like RFC 5626. This will require building something fairly tricky to essentially proxy all the SIP requests from the client to all the other SIP points. Building this is no easier then implementing the same thing using an HTTP server application which works with a client JavaScript library. If our primary goal were implementation of Intranet SIP phones, that would be an acceptable solution. For consumer oriented RTC service this is completely useless. On the other hand extending SIP based infrastructure to implement new functionality is a lot more complex. Adding new features will require standardization or navigating a large number of conflicting SIP related specifications which are currently in force. Also, keep in mind that compliance to a lot of more advanced SIP specifications does not necessarily imply easy interoperability with existing devices. Compliance to a lot of those standards require a custom SIP server or SBC which implements them using a much smaller subset supported by each different SIP device. Bottom line, adding new features in SIP based environment typically requires a lot of server development, which is pretty much what will be required for doing signaling via an HTTP connection. I will concur that using HTTP with JavaScript is a lot less efficient then using SIP for both the client and the server, since client will need to implement more functionality using JavaScript and the server will need to maintain large number of connections and proxy all the requests, but this is a drawback of any AJAX based solution. This is something that seems to be acceptable to the industry and should not be a decisive factor. _____________ Roman Shpount On Thu, Sep 8, 2011 at 11:13 AM, Ravindran Parthasarathi < pravindran@sonusnet.com> wrote: > Harald,**** > > ** ** > > I’m proposing for “SIP UA framework for RTCWeb browser”, the framework > provides Javascript API. In case you mean the same as “SIP lite”. I’m fine > with it. SIP UA framework helps to support two-party communication from > RTCWeb browser and uses HTTP as presence or configuration interface. **** > > ** ** > > As I mentioned in the another mail, I’m talking about INVITE subset of RFC > 3261 in browser. **** > > ** ** > > Thanks**** > > Partha**** > > ** ** > > *From:* Harald Alvestrand [mailto:harald@alvestrand.no] > *Sent:* Thursday, September 08, 2011 12:23 PM > > *To:* Ravindran Parthasarathi > *Cc:* Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org > *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote > recording - RTC-Web client acting as SIPREC session recording client]**** > > ** ** > > On 09/08/2011 07:09 AM, Ravindran Parthasarathi wrote: **** > > Harald,**** > > **** > > For browser as a SIP UA application, browser has to no need to compliant > with 269 pages of RFC 3261 as proxy core is irrelevant to it. I also agree > with you that browser-to-browser communication, I could not see the strong > reason for supporting S/MIME. As part of the RTCWeb architecture & solution, > we will able to explore the SIP UA requirement for making browser SIP > compliant.**** > > So you're advocating for creating a "SIP lite" subset that RTCWEB browsers > implement. > I think we have been down this road before, and it's not a happy one. > But sure - if you want us to implement some part of SIP, *please start > stating what part* rather than making wooly statements. > > Subsets are Real Hard Work. > > **** > > Say for example, forking does not make sense in case of browser as SIP UA > application, forked response will be rejected with CANCEL in browser without > Javascript intervention. The main requirement is to build the right SIP UA > framework in browser by which Javascript developer will be able to use to > the maximum extent without impacting the basic 2 two party communication in > the internet. **** > > **** > > As mailed in another thread, RTCWEB client + RTCWeb server makes to feel a > modern exchange in web world (Plain Old Telephony System phone with exchange > architecture). I think so because POTS phones are dumb which does not know > its identity and every event like offhook, onhook has to passed to exchange > (webserver) whereas RTCWeb client (browser) has to pass every event to > webserver and webserver has whole intelligence to make it work.**** > > Don't forget that the RTCWEB client (the browser) contains an open, fully > programmable application platform - the Javascript engine. That's a HUGE > difference to the POTS phone. > > **** > > I got this feel more when someone is talking about MEGACO or MGCP between > RTCWEB client & webserver. My understanding is that SIP does not fit well to > legacy telephone-based paradigm by any means but MEGACO or MGCP are the > better choice which maps to SS7 architecture well. I’m interested in seeing > RTCWeb client perform the basic routing rather than webserver does the > routing on behalf of RTCWEb client.**** > > **** > > I agree with you that in case it is local exchange (same site like skype or > Google hangout) communication, there will be no need of signaling but I’m > interested in communication with one of the Google real-time user in > internet without having any Google id. I believe that SIP will make it > work.**** > > If by saying "the Google real time user in Internet", you mean a Google > Talk user, you have that already. It's called Google Voice. It uses SIP, but > not in the browser. > > Talking to someone who doesn't want to talk to you is an use case we don't > intend to support. > > **** > > **** > > Thanks**** > > Partha**** > > **** > > *From:* Harald Alvestrand [mailto:harald@alvestrand.no<harald@alvestrand.no>] > > *Sent:* Wednesday, September 07, 2011 11:13 PM > *To:* Ravindran Parthasarathi > *Cc:* Matthew Kaufman; igor.faynberg@alcatel-lucent.com; rtcweb@ietf.org > *Subject:* Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remote > recording - RTC-Web client acting as SIPREC session recording client]**** > > **** > > On 09/07/11 19:29, Ravindran Parthasarathi wrote: **** > > Matthew,**** > > **** > > When I asked for SIP, I have meant RFC 3261 only.**** > > This is 269 pages, and has 26 normative dependencies including S/MIME. It's > not a small dependency.**** > > > > > **** > > The basic reason for asking SIP is to make the basic call works between > browser to browser across web servers. Without SIP in browser, it is not > going happen. Innovative application is going to be proprietary whether it > is HTTP or SIP or any other protocol for that matter.**** > > **** > > My reasoning are as follows:**** > > SIP makes browser more intelligence compare to dump signaling mechanism > like MEGACO and browser acts as MG. **** > > Why does that "intelligence" need to be in the browser, rather than in the > Javascript? > > > **** > > The importance of basic call interop is that there is no need of many > individual id like skype id, Google id and yahoo id by everyone in the > world to communicate others. I wish to have single id like e-mail id to be > maintained by browser-to-browser users to communicate with others. **** > > This only makes sense for applications that fit the "call an identified > party" paradigm. > > > **** > > SIP helps to interop for basic call with other existing realtime > application in Enterprise & Telecom provider.**** > > There is no need to build two different signaling logic in VoIP servers for > each service. Your own example of Bridge line appearance will need two > implementation by the single vendor because desktop application or hardphone > implementation based on SIP and browser based implementation is depend on > HTTP metadata. It is possible to avoided by having one signaling protocol. > **** > > One protocol can be achieved by multiple applications choosing to implement > one protocol. > It doesn't have to be enforced by the prtoocol being embedded in the > browser. > > > **** > > **** > > In RTCWEB does not standardize the signaling protocol interface between > browsers, the interop across webservers is next to impossible and it will be > restricted to single webserver (company) only. Please let me know in case > I’m missing something here.**** > > > I think the main thing you are missing is that there are many applications > that people want to build on top of RTCWEB that are not telephones, and will > not fit with telephone-based paradigms.**** > > ** ** > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > >
- [rtcweb] Remote recording - RTC-Web client acting… Elwell, John
- Re: [rtcweb] Remote recording - RTC-Web client ac… Stefan Håkansson LK
- Re: [rtcweb] Remote recording - RTC-Web client ac… Ravindran Parthasarathi
- Re: [rtcweb] Remote recording - RTC-Web client ac… Paul Kyzivat
- Re: [rtcweb] Remote recording - RTC-Web client ac… Dan York
- Re: [rtcweb] Remote recording - RTC-Web client ac… Elwell, John
- Re: [rtcweb] Remote recording - RTC-Web client ac… Olle E Johansson
- Re: [rtcweb] Remote recording - RTC-Web client ac… Dan York
- Re: [rtcweb] Remote recording - RTC-Web client ac… Hutton, Andrew
- Re: [rtcweb] Remote recording - RTC-Web client ac… Igor Faynberg
- [rtcweb] SIP MUST NOT be used in browser?[was RE:… Ravindran Parthasarathi
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Igor Faynberg
- Re: [rtcweb] Remote recording - RTC-Web client ac… Randell Jesup
- Re: [rtcweb] Remote recording - RTC-Web client ac… Elwell, John
- Re: [rtcweb] Remote recording - RTC-Web client ac… Hutton, Andrew
- Re: [rtcweb] Remote recording - RTC-Web client ac… Harald Alvestrand
- Re: [rtcweb] Remote recording - RTC-Web client ac… Dzonatas Sol
- Re: [rtcweb] Remote recording - RTC-Web client ac… Igor Faynberg
- Re: [rtcweb] Remote recording - RTC-Web client ac… Paul Kyzivat
- Re: [rtcweb] Remote recording - RTC-Web client ac… Harald Alvestrand
- Re: [rtcweb] Remote recording - RTC-Web client ac… Elwell, John
- Re: [rtcweb] Remote recording - RTC-Web client ac… Matthew Kaufman
- Re: [rtcweb] Remote recording - RTC-Web client ac… Dzonatas Sol
- Re: [rtcweb] Remote recording - RTC-Web client ac… Ravindran Parthasarathi
- Re: [rtcweb] Remote recording - RTC-Web client ac… Timothy B. Terriberry
- Re: [rtcweb] Remote recording - RTC-Web client ac… Ravindran Parthasarathi
- Re: [rtcweb] Remote recording - RTC-Web client ac… Ravindran Parthasarathi
- Re: [rtcweb] Remote recording - RTC-Web client ac… Matthew Kaufman
- Re: [rtcweb] Remote recording - RTC-Web client ac… Matthew Kaufman
- Re: [rtcweb] Remote recording - RTC-Web client ac… Bernard Aboba
- Re: [rtcweb] Remote recording - RTC-Web client ac… Robert O'Callahan
- Re: [rtcweb] Remote recording - RTC-Web client ac… Robert O'Callahan
- Re: [rtcweb] Remote recording - RTC-Web client ac… Elwell, John
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Matthew Kaufman
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Igor Faynberg
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Ravindran Parthasarathi
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Matthew Kaufman
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Olle E. Johansson
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Ravindran Parthasarathi
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Asveren, Tolga
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Igor Faynberg
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Justin Uberti
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Matthew Kaufman
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Matthew Kaufman
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Matthew Kaufman
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Matthew Kaufman
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Paul Kyzivat
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Olle E. Johansson
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Roman Shpount
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Igor Faynberg
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Igor Faynberg
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Ravindran Parthasarathi
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Harald Alvestrand
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Markus.Isomaki
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Randell Jesup
- [rtcweb] Encryption mandate Randell Jesup
- Re: [rtcweb] Encryption mandate Olle E. Johansson
- Re: [rtcweb] Encryption mandate Dzonatas Sol
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Olle E. Johansson
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Olle E. Johansson
- Re: [rtcweb] Encryption mandate Dzonatas Sol
- Re: [rtcweb] Encryption mandate (and offer/answer) Jonathan Lennox
- Re: [rtcweb] Encryption mandate Christopher Blizzard
- Re: [rtcweb] Encryption mandate Igor Faynberg
- Re: [rtcweb] Encryption mandate Dzonatas Sol
- Re: [rtcweb] Encryption mandate Paul Kyzivat
- Re: [rtcweb] Encryption mandate Igor Faynberg
- Re: [rtcweb] Encryption mandate Randell Jesup
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Matthew Kaufman
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Matthew Kaufman
- Re: [rtcweb] Encryption mandate (and offer/answer) Randell Jesup
- Re: [rtcweb] Encryption mandate Matthew Kaufman
- Re: [rtcweb] Encryption mandate Randell Jesup
- Re: [rtcweb] Encryption mandate Dzonatas Sol
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Silvia Pfeiffer
- Re: [rtcweb] Encryption mandate Christopher Blizzard
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Ravindran Parthasarathi
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Ravindran Parthasarathi
- Re: [rtcweb] Encryption mandate Olle E. Johansson
- Re: [rtcweb] Encryption mandate Olle E. Johansson
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Olle E. Johansson
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Silvia Pfeiffer
- Re: [rtcweb] Encryption mandate Randell Jesup
- [rtcweb] AVPF [was: Encryption mandate (and offer… Christer Holmberg
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Harald Alvestrand
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Olle E. Johansson
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Silvia Pfeiffer
- Re: [rtcweb] Encryption mandate Michael Procter
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Tim Panton
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Olle E. Johansson
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Jonathan Lennox
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Igor Faynberg
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Tim Panton
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Igor Faynberg
- [rtcweb] Meeting Bridge and Webex link for Sept 8… Sohel Khan
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Harald Alvestrand
- Re: [rtcweb] Encryption mandate Paul Kyzivat
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Bernard Aboba
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Igor Faynberg
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Igor Faynberg
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Ravindran Parthasarathi
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Harald Alvestrand
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Ravindran Parthasarathi
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Roman Shpount
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Roman Shpount
- Re: [rtcweb] Encryption mandate Paul Kyzivat
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Paul Kyzivat
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Ravindran Parthasarathi
- Re: [rtcweb] Encryption mandate Christopher Blizzard
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Igor Faynberg
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Justin Uberti
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Peter Saint-Andre
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Igor Faynberg
- Re: [rtcweb] SIP MUST NOT be used in browser? Aaron Clauson
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Justin Uberti
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Alan Johnston
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Justin Uberti
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Matthew Kaufman
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Dzonatas Sol
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Eric Rescorla
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Justin Uberti
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Dzonatas Sol
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Alan Johnston
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Roman Shpount
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Dzonatas Sol
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Dzonatas Sol
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Christer Holmberg
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Dzonatas Sol
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Christer Holmberg
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Randell Jesup
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Justin Uberti
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Dzonatas Sol
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Dzonatas Sol
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Paul Kyzivat
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Olle E. Johansson
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Olle E. Johansson
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Olle E. Johansson
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Roman Shpount
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Matthew Kaufman
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Dzonatas Sol
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Dzonatas Sol
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Dzonatas Sol
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Dzonatas Sol
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Roman Shpount
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Matthew Kaufman
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Bernard Aboba
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Christer Holmberg
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Paul Kyzivat
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Randell Jesup
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Stefan Håkansson LK
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Hadriel Kaplan
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Timothy B. Terriberry
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Dzonatas Sol
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Ravindran Parthasarathi
- Re: [rtcweb] SIP MUST NOT be used in browser? Ravindran Parthasarathi
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Ravindran Parthasarathi
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Roman Shpount
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Roman Shpount
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Roman Shpount
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Stefan Håkansson LK
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Stefan Håkansson LK
- [rtcweb] SIP vs Websocket in RTCWeb [was RE: SIP … Ravindran Parthasarathi
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Matthew Kaufman
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Matthew Kaufman
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… DRAGE, Keith (Keith)
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] SIP vs Websocket in RTCWeb [was RE: … Peter Saint-Andre
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Paul Kyzivat
- Re: [rtcweb] SIP vs Websocket in RTCWeb [was RE: … Dzonatas Sol
- Re: [rtcweb] SIP vs Websocket in RTCWeb [was RE: … Ravindran Parthasarathi
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Ravindran Parthasarathi
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Jozsef Vass
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Roman Shpount
- Re: [rtcweb] SIP vs Websocket in RTCWeb [was RE: … Peter Saint-Andre
- [rtcweb] signaling protocol SHANMUGALINGAM SIVASOTHY
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Hadriel Kaplan
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Hadriel Kaplan
- Re: [rtcweb] SIP MUST NOT be used in browser? Tim Panton
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Tim Panton
- Re: [rtcweb] SIP MUST NOT be used in browser? Olle E. Johansson
- Re: [rtcweb] SIP MUST NOT be used in browser? Ravindran Parthasarathi
- Re: [rtcweb] SIP MUST NOT be used in browser?[was… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Dan Wing
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Tim Panton
- Re: [rtcweb] AVPF [was: Encryption mandate (and o… Dan Wing