Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?
On 1/29/11 8:35 AM, Jonathan Rosenberg wrote:
I'm starting a separate thread on this, since I don't want to confound it with the charter discussion. This is a topic that should be resolved within the group itself
I have a number of thoughts on this topic also, but I don't think this (DISPATCH) is the forum for them. I'd like for these conversations to take place, though, so I want it to be clear in the charter that we aren't precluded from choosing one path over the other. Is it fair to characterize your statement that "this is a topic that should be resolved within the group itself" to support leaving the charter open enough to support any consensus conclusion that discussion may reach? /a
Absolutely. I agree this debate should be resolved in the group, and the charter should specify that this question (whether or not we need to specify a protocol, and then if so, what it is) is in scope. I send some proposed text for charter wording along these lines. Of course, that doesn't mean we cannot start the debate early. And indeed, since we have, I chimed in ;) -Jonathan R. Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net -----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Adam Roach Sent: Saturday, January 29, 2011 10:39 AM To: Jonathan Rosenberg Cc: rtc-web@alvestrand.no; 'DISPATCH list' Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol? On 1/29/11 8:35 AM, Jonathan Rosenberg wrote:
I'm starting a separate thread on this, since I don't want to confound it with the charter discussion. This is a topic that should be resolved within the group itself
I have a number of thoughts on this topic also, but I don't think this (DISPATCH) is the forum for them. I'd like for these conversations to take place, though, so I want it to be clear in the charter that we aren't precluded from choosing one path over the other. Is it fair to characterize your statement that "this is a topic that should be resolved within the group itself" to support leaving the charter open enough to support any consensus conclusion that discussion may reach? /a _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Absolutely. I agree this debate should be resolved in the group, and the charter should specify that this question (whether or not we need to specify a protocol, and then if so, what it is) is in scope. I send some proposed text for charter wording along these lines. Of course, that doesn't mean we cannot start the debate early. And indeed, since we have, I chimed in ;) -Jonathan R. On 1/29/2011 10:38 AM, Adam Roach wrote:
On 1/29/11 8:35 AM, Jonathan Rosenberg wrote:
I'm starting a separate thread on this, since I don't want to confound it with the charter discussion. This is a topic that should be resolved within the group itself
I have a number of thoughts on this topic also, but I don't think this (DISPATCH) is the forum for them. I'd like for these conversations to take place, though, so I want it to be clear in the charter that we aren't precluded from choosing one path over the other.
Is it fair to characterize your statement that "this is a topic that should be resolved within the group itself" to support leaving the charter open enough to support any consensus conclusion that discussion may reach?
/a
-- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net
SIP, for various reasons, is the right choice IMO. My 2 bits outside of dispatch: http://www.alvestrand.no/pipermail/rtc-web/2011-January/000312.html On 2011-01-29, at 8:18 AM, "Rosenberg, Jonathan" <jonathan.rosenberg@skype.net
wrote:
Absolutely. I agree this debate should be resolved in the group, and the charter should specify that this question (whether or not we need to specify a protocol, and then if so, what it is) is in scope. I send some proposed text for charter wording along these lines.
Of course, that doesn't mean we cannot start the debate early. And indeed, since we have, I chimed in ;)
-Jonathan R.
Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web- bounces@alvestrand.no] On Behalf Of Adam Roach Sent: Saturday, January 29, 2011 10:39 AM To: Jonathan Rosenberg Cc: rtc-web@alvestrand.no; 'DISPATCH list' Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?
On 1/29/11 8:35 AM, Jonathan Rosenberg wrote:
I'm starting a separate thread on this, since I don't want to confound it with the charter discussion. This is a topic that should be resolved within the group itself
I have a number of thoughts on this topic also, but I don't think this (DISPATCH) is the forum for them. I'd like for these conversations to take place, though, so I want it to be clear in the charter that we aren't precluded from choosing one path over the other.
Is it fair to characterize your statement that "this is a topic that should be resolved within the group itself" to support leaving the charter open enough to support any consensus conclusion that discussion may reach?
/a _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Duh ... what are we abandoning 10 years of work? -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Erik Lagerway Sent: Saturday, January 29, 2011 12:35 PM To: Rosenberg, Jonathan Cc: rtc-web@alvestrand.no; DISPATCH list Subject: Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol? SIP, for various reasons, is the right choice IMO. My 2 bits outside of dispatch: http://www.alvestrand.no/pipermail/rtc-web/2011-January/000312.html On 2011-01-29, at 8:18 AM, "Rosenberg, Jonathan" <jonathan.rosenberg@skype.net
wrote:
Absolutely. I agree this debate should be resolved in the group, and the charter should specify that this question (whether or not we need to specify a protocol, and then if so, what it is) is in scope. I send some proposed text for charter wording along these lines.
Of course, that doesn't mean we cannot start the debate early. And indeed, since we have, I chimed in ;)
-Jonathan R.
Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net
-----Original Message----- From: rtc-web-bounces@alvestrand.no [mailto:rtc-web- bounces@alvestrand.no] On Behalf Of Adam Roach Sent: Saturday, January 29, 2011 10:39 AM To: Jonathan Rosenberg Cc: rtc-web@alvestrand.no; 'DISPATCH list' Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?
On 1/29/11 8:35 AM, Jonathan Rosenberg wrote:
I'm starting a separate thread on this, since I don't want to confound it with the charter discussion. This is a topic that should be resolved within the group itself
I have a number of thoughts on this topic also, but I don't think this (DISPATCH) is the forum for them. I'd like for these conversations to take place, though, so I want it to be clear in the charter that we aren't precluded from choosing one path over the other.
Is it fair to characterize your statement that "this is a topic that should be resolved within the group itself" to support leaving the charter open enough to support any consensus conclusion that discussion may reach?
/a _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
Duh ... what are we abandoning 10 years of work?
The web is a "generative" platform that supports not just protocols, but also execution of code. This enables the platform to be extended in a virtually infinite number of ways, including the development of Javascript signaling APIs, without needing to add yet more core code to the browser. This is the preferred approach unless it can be shown that something *absolutely* must be natively supported (as was discussed at the workshop, STUN/TURN authorization for peer-to-peer media is probably an example of something that *does* need to be native). As an example of what is possible, there is an excellent Javascript library for XMPP (strophe, see http://code.stanziq.com/strophe/). Poking around, it would appear that there are a number of Javascript libraries that claim to provide support for SIP (such as http://phono.com/), although I have no idea of their usefulness. Given the generality and power of the web platform and the ease with which sophisticated signaling libraries can be implemented today, the bar for getting additional code into any browser is going to be quite high. If you doubt this, ask the build-master of your favorite browser for the requirements for checkin of a complete SIP stack :)
Hi, I pretty much agree with what Bernard and Johathan Rosenberg have said. There are just a couple of issues I would like to understand better: - I suppose these Javascript libraries can be cached on the browser and need not be downloaded every time the application/site is accessed? (These are probably a common practices in Javascript and Browsers but are good to clarify in this discussion.) - It may be easy for a web developer to use the client side Javascript library, but I believe the challenge may be bigger on the server side, where scalability etc. become issues. How about the server side, is there something ready-made for that? I suppose the Javascript on the browser can't necessarily connect to vanilla SIP or XMPP servers but some HTTP/WebSocket/TLS tunneling and connection management magic is needed, especially when dealing with HTTP intermediaries. (But presumably the same issues would be faced if we "picked" SIP or XMPP.) Markus From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of ext Bernard Aboba Sent: 30 January, 2011 07:35 To: Richard Shockey; erik@hookflash.com; jonathan.rosenberg@skype.net Cc: rtc-web@alvestrand.no; dispatch@ietf.org Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?
Duh ... what are we abandoning 10 years of work?
The web is a "generative" platform that supports not just protocols, but also execution of code. This enables the platform to be extended in a virtually infinite number of ways, including the development of Javascript signaling APIs, without needing to add yet more core code to the browser. This is the preferred approach unless it can be shown that something *absolutely* must be natively supported (as was discussed at the workshop, STUN/TURN authorization for peer-to-peer media is probably an example of something that *does* need to be native). As an example of what is possible, there is an excellent Javascript library for XMPP (strophe, see http://code.stanziq.com/strophe/). Poking around, it would appear that there are a number of Javascript libraries that claim to provide support for SIP (such as http://phono.com/), although I have no idea of their usefulness. Given the generality and power of the web platform and the ease with which sophisticated signaling libraries can be implemented today, the bar for getting additional code into any browser is going to be quite high. If you doubt this, ask the build-master of your favorite browser for the requirements for checkin of a complete SIP stack :)
One approach is to tunnel the signaling protocol over HTTP. This requires support for bi-directional communications, such as can be provided by BOSH, or Websockets. In these architectures the web client communicates via HTTP with a "Connection Manager" which encapsulates/decapsulates the signaling messages and routes them appropriately on the backend. To provide interoperability, specifications for encapsulation of signaling messages within HTTP are required. Examples include: XEP-0124 <http://xmpp.org/extensions/xep-0124.html> : Bidirectional-streams Over Synchronous HTTP (BOSH) XEP-0206 <http://xmpp.org/extensions/xep-0206.html> : XMPP over BOSH An XMPP Sub-protocol for Websocket <http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket> Information on BOSH implementations can be found here: http://xmpp.org/about-xmpp/technology-overview/bosh/#impl From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of Markus.Isomaki@nokia.com Sent: Sunday, January 30, 2011 2:45 PM To: bernard_aboba@hotmail.com; richard@shockey.us; erik@hookflash.com; jonathan.rosenberg@skype.net Cc: rtc-web@alvestrand.no; dispatch@ietf.org Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol? Hi, I pretty much agree with what Bernard and Johathan Rosenberg have said. There are just a couple of issues I would like to understand better: - I suppose these Javascript libraries can be cached on the browser and need not be downloaded every time the application/site is accessed? (These are probably a common practices in Javascript and Browsers but are good to clarify in this discussion.) - It may be easy for a web developer to use the client side Javascript library, but I believe the challenge may be bigger on the server side, where scalability etc. become issues. How about the server side, is there something ready-made for that? I suppose the Javascript on the browser can't necessarily connect to vanilla SIP or XMPP servers but some HTTP/WebSocket/TLS tunneling and connection management magic is needed, especially when dealing with HTTP intermediaries. (But presumably the same issues would be faced if we "picked" SIP or XMPP.) Markus From: rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] On Behalf Of ext Bernard Aboba Sent: 30 January, 2011 07:35 To: Richard Shockey; erik@hookflash.com; jonathan.rosenberg@skype.net Cc: rtc-web@alvestrand.no; dispatch@ietf.org Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?
Duh ... what are we abandoning 10 years of work?
The web is a "generative" platform that supports not just protocols, but also execution of code. This enables the platform to be extended in a virtually infinite number of ways, including the development of Javascript signaling APIs, without needing to add yet more core code to the browser. This is the preferred approach unless it can be shown that something *absolutely* must be natively supported (as was discussed at the workshop, STUN/TURN authorization for peer-to-peer media is probably an example of something that *does* need to be native). As an example of what is possible, there is an excellent Javascript library for XMPP (strophe, see http://code.stanziq.com/strophe/). Poking around, it would appear that there are a number of Javascript libraries that claim to provide support for SIP (such as http://phono.com/), although I have no idea of their usefulness. Given the generality and power of the web platform and the ease with which sophisticated signaling libraries can be implemented today, the bar for getting additional code into any browser is going to be quite high. If you doubt this, ask the build-master of your favorite browser for the requirements for checkin of a complete SIP stack :)
On 01/30/11 22:50, Bernard Aboba wrote:
One approach is to tunnel the signaling protocol over HTTP. This requires support for bi-directional communications, such as can be provided by BOSH, or Websockets. In these architectures the web client communicates via HTTP with a "Connection Manager" which encapsulates/decapsulates the signaling messages and routes them appropriately on the backend.
I think that no matter what we define (or not) as the signalling protocol, it will be carried in a fashion that looks like HTTP or HTTPS (most probably HTTPS) to intermediaries and firewalls. Not using WebSockets (if it's done yet) seems like a strange choice; if WebSockets are usable for anything, they should be usable for this application.
To provide interoperability, specifications for encapsulation of signaling messages within HTTP are required. Examples include:
XEP-0124 <http://xmpp.org/extensions/xep-0124.html>: Bidirectional-streams Over Synchronous HTTP (BOSH)
XEP-0206 <http://xmpp.org/extensions/xep-0206.html>: XMPP over BOSH
An XMPP Sub-protocol for Websocket <http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket>
Information on BOSH implementations can be found here:
http://xmpp.org/about-xmpp/technology-overview/bosh/#impl
*From:*rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] *On Behalf Of *Markus.Isomaki@nokia.com *Sent:* Sunday, January 30, 2011 2:45 PM *To:* bernard_aboba@hotmail.com; richard@shockey.us; erik@hookflash.com; jonathan.rosenberg@skype.net *Cc:* rtc-web@alvestrand.no; dispatch@ietf.org *Subject:* Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?
Hi,
I pretty much agree with what Bernard and Johathan Rosenberg have said.
There are just a couple of issues I would like to understand better:
-I suppose these Javascript libraries can be cached on the browser and need not be downloaded every time the application/site is accessed? (These are probably a common practices in Javascript and Browsers but are good to clarify in this discussion.)
-It may be easy for a web developer to use the client side Javascript library, but I believe the challenge may be bigger on the server side, where scalability etc. become issues. How about the server side, is there something ready-made for that? I suppose the Javascript on the browser can't necessarily connect to vanilla SIP or XMPP servers but some HTTP/WebSocket/TLS tunneling and connection management magic is needed, especially when dealing with HTTP intermediaries. (But presumably the same issues would be faced if we "picked" SIP or XMPP.)
Markus
*From:*rtc-web-bounces@alvestrand.no [mailto:rtc-web-bounces@alvestrand.no] *On Behalf Of *ext Bernard Aboba *Sent:* 30 January, 2011 07:35 *To:* Richard Shockey; erik@hookflash.com; jonathan.rosenberg@skype.net *Cc:* rtc-web@alvestrand.no; dispatch@ietf.org *Subject:* Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?
Duh ... what are we abandoning 10 years of work?
The web is a "generative" platform that supports not just protocols, but also execution of code. This enables the platform to be extended in a virtually infinite number of ways, including the development of Javascript signaling APIs, without needing to add yet more core code to the browser. This is the preferred approach unless it can be shown that something *absolutely* must be natively supported (as was discussed at the workshop, STUN/TURN authorization for peer-to-peer media is probably an example of something that *does* need to be native).
As an example of what is possible, there is an excellent Javascript library for XMPP (strophe, see http://code.stanziq.com/strophe/). Poking around, it would appear that there are a number of Javascript libraries that claim to provide support for SIP (such as http://phono.com/), although I have no idea of their usefulness.
Given the generality and power of the web platform and the ease with which sophisticated signaling libraries can be implemented today, the bar for getting additional code into any browser is going to be quite high. If you doubt this, ask the build-master of your favorite browser for the requirements for checkin of a complete SIP stack :)
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
On Tue, Feb 1, 2011 at 1:28 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
On 01/30/11 22:50, Bernard Aboba wrote:
One approach is to tunnel the signaling protocol over HTTP. This requires support for bi-directional communications, such as can be provided by BOSH, or Websockets. In these architectures the web client communicates via HTTP with a “Connection Manager” which encapsulates/decapsulates the signaling messages and routes them appropriately on the backend.
I think that no matter what we define (or not) as the signalling protocol, it will be carried in a fashion that looks like HTTP or HTTPS (most probably HTTPS) to intermediaries and firewalls. Not using WebSockets (if it's done yet) seems like a strange choice; if WebSockets are usable for anything, they should be usable for this application.
It's already possible to write a "shared video viewing" application using Web sockets. There, the user just follows a URL to a Web page on which the video is being shown and by following that URL they are added to a Web socket based communication. I also believe there is a place for Web sockets somewhere in this specification. Cheers, Silvia.
participants (9)
-
Adam Roach -
Bernard Aboba -
Erik Lagerway -
Harald Alvestrand -
Jonathan Rosenberg -
Markus.Isomaki＠nokia.com -
Richard Shockey -
Rosenberg, Jonathan -
Silvia Pfeiffer