Does RTC-WEB need to pick a signaling protocol?
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, and here are my thoughts on it. If one asks the question on whether it is actually NECESSARY to require that a browser implement something like SIP in order to enable voip natively, the answer is definitively NO. The browser already provides a tool for exchanging messaging of arbitrary content between the browser and a server - its called HTTP (and websockets). Through client-side Javascript that comes from the server, an application can craft arbitrary protocol messaging of its own design between the client and the server. As an obvious example, in order to read mail on Gmail, the browser doesn't need to have an implementation of IMAP or POP; Gmail's Javascript implements the client side of a protocol of Google's design, and it talks to a web server which implements the server side of that protocol. The protocol is then then carried over HTTP. As such, if we take our charter here to define only what is truly REQUIRED of a browser, in order to enable voip without a plugin, then we do NOT need to pick a signaling protocol. All we need are the things which are truly impossible or grossly unsuitable for HTTP, and that is the real-time media path only. There need only be APIs for pushing in, and extracting out, the data that must be exchanged through HTTP-based signaling - and those are things like IP addresses and codec selections. That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived. This is something which, despite our best efforts here at IETF over the years, we have failed to achieve. I think it is critical that we allow web-based voip to innovate with the same kind of pace we've seen in the web overall. One of the arguments made on the list about why we should pick something, is that building their own signaling protocols and messaging is "hard" for a tiny web developer that just wants to add a bit of voice to their app. In such a case, I fully expect that within weeks or months of specification and implementation of RTC-WEB stuff in browsers, smart people will develop Javascript libraries which do all of this "hard work", along with PHP and many other server-side libraries with sit on the other side. None of it requires standardization, and we can let the open source community and the marketplace innovate on whatever solutions are needed. Thanks, 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
I understand your position Jonathan and agree that it might be the right course at some point in the future but the fact remains, SIP rules in communications "today", it will do so for years to come. It might be wise for us to move forward on a standard that is understood and appreciated by not only the developer community but also the business community paying the bills. I think they, as will everyone else that owns a SIP endpoint, will appreciate that sentiment. Yes, we can build anew atop http, all it takes is time and money, money is running in shirt supply. It would be nice if we could get it working for those who spent hard earned dollars on SIP, sooner rather than later. An http effort will take a while, we have a standard, one that you are very familiar with, let's use that. -Erik On 2011-01-29, at 6:35 AM, Jonathan Rosenberg <jdrosen@jdrosen.net> 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, and here are my thoughts on it.
If one asks the question on whether it is actually NECESSARY to require that a browser implement something like SIP in order to enable voip natively, the answer is definitively NO. The browser already provides a tool for exchanging messaging of arbitrary content between the browser and a server - its called HTTP (and websockets). Through client-side Javascript that comes from the server, an application can craft arbitrary protocol messaging of its own design between the client and the server. As an obvious example, in order to read mail on Gmail, the browser doesn't need to have an implementation of IMAP or POP; Gmail's Javascript implements the client side of a protocol of Google's design, and it talks to a web server which implements the server side of that protocol. The protocol is then then carried over HTTP.
As such, if we take our charter here to define only what is truly REQUIRED of a browser, in order to enable voip without a plugin, then we do NOT need to pick a signaling protocol. All we need are the things which are truly impossible or grossly unsuitable for HTTP, and that is the real-time media path only. There need only be APIs for pushing in, and extracting out, the data that must be exchanged through HTTP-based signaling - and those are things like IP addresses and codec selections.
That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived. This is something which, despite our best efforts here at IETF over the years, we have failed to achieve. I think it is critical that we allow web-based voip to innovate with the same kind of pace we've seen in the web overall.
One of the arguments made on the list about why we should pick something, is that building their own signaling protocols and messaging is "hard" for a tiny web developer that just wants to add a bit of voice to their app. In such a case, I fully expect that within weeks or months of specification and implementation of RTC- WEB stuff in browsers, smart people will develop Javascript libraries which do all of this "hard work", along with PHP and many other server-side libraries with sit on the other side. None of it requires standardization, and we can let the open source community and the marketplace innovate on whatever solutions are needed.
Thanks, 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
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
I understand the argument and agree that pure http might be the right course at some point in the future but the fact remains, SIP rules in communications "today", it will do so for years to come. It might be wise for us to move forward on a standard that is understood and appreciated by not only the developer community but also the business community paying the bills. Yes, we can build anew atop http, all it takes is time and money. An http effort will take a while, I think we all know that. How long did it take for SIP to displace H.323? I think the unanimous answer is "too long". We have a standard that exists today, one that we are all very familiar with, one that works! It would seem a shame not to leverage all we (and our employers) have invested, which is considerable. This is a major event in communications, we need to consider this carefully but we also owe it to "standards" to do it quickly, which has not been the norm it seems. *Erik Lagerway | hookflash | m. 604.562.8647* On Sat, Jan 29, 2011 at 6:35 AM, Jonathan Rosenberg <jdrosen@jdrosen.net>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, and here are my thoughts on it.
If one asks the question on whether it is actually NECESSARY to require that a browser implement something like SIP in order to enable voip natively, the answer is definitively NO. The browser already provides a tool for exchanging messaging of arbitrary content between the browser and a server - its called HTTP (and websockets). Through client-side Javascript that comes from the server, an application can craft arbitrary protocol messaging of its own design between the client and the server. As an obvious example, in order to read mail on Gmail, the browser doesn't need to have an implementation of IMAP or POP; Gmail's Javascript implements the client side of a protocol of Google's design, and it talks to a web server which implements the server side of that protocol. The protocol is then then carried over HTTP.
As such, if we take our charter here to define only what is truly REQUIRED of a browser, in order to enable voip without a plugin, then we do NOT need to pick a signaling protocol. All we need are the things which are truly impossible or grossly unsuitable for HTTP, and that is the real-time media path only. There need only be APIs for pushing in, and extracting out, the data that must be exchanged through HTTP-based signaling - and those are things like IP addresses and codec selections.
That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived. This is something which, despite our best efforts here at IETF over the years, we have failed to achieve. I think it is critical that we allow web-based voip to innovate with the same kind of pace we've seen in the web overall.
One of the arguments made on the list about why we should pick something, is that building their own signaling protocols and messaging is "hard" for a tiny web developer that just wants to add a bit of voice to their app. In such a case, I fully expect that within weeks or months of specification and implementation of RTC-WEB stuff in browsers, smart people will develop Javascript libraries which do all of this "hard work", along with PHP and many other server-side libraries with sit on the other side. None of it requires standardization, and we can let the open source community and the marketplace innovate on whatever solutions are needed.
Thanks, 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
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote:
That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived.
Agreed. Consider the case of Gmail (or any other web-based email) Did every web browser on the planet need to be upgraded to speak IMAP or SMTP in order for Gmail to be implemented? No. Does the JavaScript that Gmail sends down to your browser in order to implement its UI need to be standardized among web email platforms? No. Does Google need to use the same JavaScript libraries and PHP back-end that SquirrelMail uses in order to implement a web email application? No. Can Google change that JavaScript tomorrow without breaking interoperability? Yes, and they probably will. But could Gmail be as successful without the worldwide SMTP infrastructure it ties in to? Probably not. I see the same situation here. A web browser with real-time communication capabilities will work in conjunction with a web site that serves up the HTML and JavaScript that makes up the calling application. For some applications, this will be sufficient. For others, one will want to implement SIP or XMPP/Jingle or something else in order to gateway these calls to other networks. The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof. Matthew Kaufman
+1
The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof.
Or even in a browser add-in, perish the thought :-) The main point here is to avoid the Chronos effect from SIP and XMPP (has to do with avoiding competition from the children by eating them, as described in the book "The Master Switch" by Tim Wu). Thanks, Henry On 1/31/11 10:12 AM, "Matthew Kaufman" <matthew.kaufman@skype.net> wrote:
On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote:
That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived.
Agreed. Consider the case of Gmail (or any other web-based email)
Did every web browser on the planet need to be upgraded to speak IMAP or SMTP in order for Gmail to be implemented? No.
Does the JavaScript that Gmail sends down to your browser in order to implement its UI need to be standardized among web email platforms? No.
Does Google need to use the same JavaScript libraries and PHP back-end that SquirrelMail uses in order to implement a web email application? No.
Can Google change that JavaScript tomorrow without breaking interoperability? Yes, and they probably will.
But could Gmail be as successful without the worldwide SMTP infrastructure it ties in to? Probably not.
I see the same situation here. A web browser with real-time communication capabilities will work in conjunction with a web site that serves up the HTML and JavaScript that makes up the calling application. For some applications, this will be sufficient. For others, one will want to implement SIP or XMPP/Jingle or something else in order to gateway these calls to other networks. The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof.
Matthew Kaufman _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
Hmm, not convinced that SIP via JS or remote would perform adequately but certainly agree that we need to get on with it. -Erik On Mon, Jan 31, 2011 at 8:34 AM, Henry Sinnreich <henry.sinnreich@gmail.com>wrote:
+1
The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof.
Or even in a browser add-in, perish the thought :-)
The main point here is to avoid the Chronos effect from SIP and XMPP (has to do with avoiding competition from the children by eating them, as described in the book "The Master Switch" by Tim Wu).
Thanks, Henry
On 1/31/11 10:12 AM, "Matthew Kaufman" <matthew.kaufman@skype.net> wrote:
On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote:
That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived.
Agreed. Consider the case of Gmail (or any other web-based email)
Did every web browser on the planet need to be upgraded to speak IMAP or SMTP in order for Gmail to be implemented? No.
Does the JavaScript that Gmail sends down to your browser in order to implement its UI need to be standardized among web email platforms? No.
Does Google need to use the same JavaScript libraries and PHP back-end that SquirrelMail uses in order to implement a web email application? No.
Can Google change that JavaScript tomorrow without breaking interoperability? Yes, and they probably will.
But could Gmail be as successful without the worldwide SMTP infrastructure it ties in to? Probably not.
I see the same situation here. A web browser with real-time communication capabilities will work in conjunction with a web site that serves up the HTML and JavaScript that makes up the calling application. For some applications, this will be sufficient. For others, one will want to implement SIP or XMPP/Jingle or something else in order to gateway these calls to other networks. The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof.
Matthew Kaufman _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Hmm, not convinced that SIP via JS or remote would perform adequately but certainly agree that we need to get on with it.
Could not agree with you more Erik on the need for SIP signaling compatibility, was just trying to avoid the ³Flash² word :-) Which I believe would work not just fine, but also be the best of the breed. I hope we don¹t discuss this here any more however since this list is about de jure standards. The main issue is to avoid the Chronos effect by constraining the API standard with the 1990s limitations of SIP and XMPP. And also avoid the rat hole of discussing SIP vs. XMPP. Henry On 1/31/11 12:32 PM, "Erik Lagerway" <erik@hookflash.com> wrote:
Hmm, not convinced that SIP via JS or remote would perform adequately but certainly agree that we need to get on with it.
-Erik
On Mon, Jan 31, 2011 at 8:34 AM, Henry Sinnreich <henry.sinnreich@gmail.com> wrote:
+1
The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof.
Or even in a browser add-in, perish the thought :-)
The main point here is to avoid the Chronos effect from SIP and XMPP (has to do with avoiding competition from the children by eating them, as described in the book "The Master Switch" by Tim Wu).
Thanks, Henry
On 1/31/11 10:12 AM, "Matthew Kaufman" <matthew.kaufman@skype.net> wrote:
On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote:
That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived.
Agreed. Consider the case of Gmail (or any other web-based email)
Did every web browser on the planet need to be upgraded to speak IMAP or SMTP in order for Gmail to be implemented? No.
Does the JavaScript that Gmail sends down to your browser in order to implement its UI need to be standardized among web email platforms? No.
Does Google need to use the same JavaScript libraries and PHP back-end that SquirrelMail uses in order to implement a web email application? No.
Can Google change that JavaScript tomorrow without breaking interoperability? Yes, and they probably will.
But could Gmail be as successful without the worldwide SMTP infrastructure it ties in to? Probably not.
I see the same situation here. A web browser with real-time communication capabilities will work in conjunction with a web site that serves up the HTML and JavaScript that makes up the calling application. For some applications, this will be sufficient. For others, one will want to implement SIP or XMPP/Jingle or something else in order to gateway these calls to other networks. The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof.
Matthew Kaufman _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Agreed. *Erik Lagerway | hookflash | m. 604.562.8647 | www.hookflash.com* On Mon, Jan 31, 2011 at 1:04 PM, Henry Sinnreich <henry.sinnreich@gmail.com>wrote:
Hmm, not convinced that SIP via JS or remote would perform adequately but certainly agree that we need to get on with it.
Could not agree with you more Erik on the need for SIP signaling compatibility, was just trying to avoid the “Flash” word :-) Which I believe would work not just fine, but also be the best of the breed. I hope we don’t discuss this here any more however since this list is about de jure standards.
The main issue is to avoid the Chronos effect by constraining the API standard with the 1990s limitations of SIP and XMPP. And also avoid the rat hole of discussing SIP vs. XMPP.
Henry
On 1/31/11 12:32 PM, "Erik Lagerway" <erik@hookflash.com> wrote:
Hmm, not convinced that SIP via JS or remote would perform adequately but certainly agree that we need to get on with it.
-Erik
On Mon, Jan 31, 2011 at 8:34 AM, Henry Sinnreich < henry.sinnreich@gmail.com> wrote:
+1
The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof.
Or even in a browser add-in, perish the thought :-)
The main point here is to avoid the Chronos effect from SIP and XMPP (has to do with avoiding competition from the children by eating them, as described in the book "The Master Switch" by Tim Wu).
Thanks, Henry
On 1/31/11 10:12 AM, "Matthew Kaufman" <matthew.kaufman@skype.net> wrote:
On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote:
That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived.
Agreed. Consider the case of Gmail (or any other web-based email)
Did every web browser on the planet need to be upgraded to speak IMAP or SMTP in order for Gmail to be implemented? No.
Does the JavaScript that Gmail sends down to your browser in order to implement its UI need to be standardized among web email platforms? No.
Does Google need to use the same JavaScript libraries and PHP back-end that SquirrelMail uses in order to implement a web email application? No.
Can Google change that JavaScript tomorrow without breaking interoperability? Yes, and they probably will.
But could Gmail be as successful without the worldwide SMTP infrastructure it ties in to? Probably not.
I see the same situation here. A web browser with real-time communication capabilities will work in conjunction with a web site that serves up the HTML and JavaScript that makes up the calling application. For some applications, this will be sufficient. For others, one will want to implement SIP or XMPP/Jingle or something else in order to gateway these calls to other networks. The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof.
Matthew Kaufman _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
+1 Peter Musgrave On 2011-01-31, at 10:20 PM, Erik Lagerway wrote:
Agreed.
Erik Lagerway | hookflash | m. 604.562.8647 | www.hookflash.com
On Mon, Jan 31, 2011 at 1:04 PM, Henry Sinnreich <henry.sinnreich@gmail.com> wrote:
Hmm, not convinced that SIP via JS or remote would perform adequately but certainly agree that we need to get on with it.
Could not agree with you more Erik on the need for SIP signaling compatibility, was just trying to avoid the “Flash” word :-) Which I believe would work not just fine, but also be the best of the breed. I hope we don’t discuss this here any more however since this list is about de jure standards.
The main issue is to avoid the Chronos effect by constraining the API standard with the 1990s limitations of SIP and XMPP. And also avoid the rat hole of discussing SIP vs. XMPP.
Henry
On 1/31/11 12:32 PM, "Erik Lagerway" <erik@hookflash.com> wrote:
Hmm, not convinced that SIP via JS or remote would perform adequately but certainly agree that we need to get on with it.
-Erik
On Mon, Jan 31, 2011 at 8:34 AM, Henry Sinnreich <henry.sinnreich@gmail.com> wrote: +1
The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof.
Or even in a browser add-in, perish the thought :-)
The main point here is to avoid the Chronos effect from SIP and XMPP (has to do with avoiding competition from the children by eating them, as described in the book "The Master Switch" by Tim Wu).
Thanks, Henry
On 1/31/11 10:12 AM, "Matthew Kaufman" <matthew.kaufman@skype.net> wrote:
On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote:
That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived.
Agreed. Consider the case of Gmail (or any other web-based email)
Did every web browser on the planet need to be upgraded to speak IMAP or SMTP in order for Gmail to be implemented? No.
Does the JavaScript that Gmail sends down to your browser in order to implement its UI need to be standardized among web email platforms? No.
Does Google need to use the same JavaScript libraries and PHP back-end that SquirrelMail uses in order to implement a web email application? No.
Can Google change that JavaScript tomorrow without breaking interoperability? Yes, and they probably will.
But could Gmail be as successful without the worldwide SMTP infrastructure it ties in to? Probably not.
I see the same situation here. A web browser with real-time communication capabilities will work in conjunction with a web site that serves up the HTML and JavaScript that makes up the calling application. For some applications, this will be sufficient. For others, one will want to implement SIP or XMPP/Jingle or something else in order to gateway these calls to other networks. The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof.
Matthew Kaufman _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________ 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
Great example. And just like Gmail uses an SMTP gateway to connect its own HTTP-based protocol to the rest of the world, Gmail voice and video uses a XMPP gateway to connect its HTTP-based signaling to other XMPP clients. Others in this space have done similar things by implementing XMPP clients in Javascript. So I think we have existence proofs that this approach, in addition to being extremely flexible, is entirely workable today. The two things that we need to specify are a) the semantics of the signaling (i.e. the offer-answer mechanism that both SIP and XMPP are patterned around) b) the mechanism through which session offers and answers will be described (e.g. some SDP-ish thing that is suitable for the web). a) seems rather straightforward. b) will likely be trickier - we need something that can be mapped to SDP, for SIP gateways, but we probably want it to be represented as JSON for benefit of web developers. So the challenge becomes, what format can we define that can be unambiguously mapped to/from SDP, but doesn't bring with it all of the baggage of SDP? --justin On Mon, Jan 31, 2011 at 8:12 AM, Matthew Kaufman <matthew.kaufman@skype.net>wrote:
On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote:
That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived.
Agreed. Consider the case of Gmail (or any other web-based email)
Did every web browser on the planet need to be upgraded to speak IMAP or SMTP in order for Gmail to be implemented? No.
Does the JavaScript that Gmail sends down to your browser in order to implement its UI need to be standardized among web email platforms? No.
Does Google need to use the same JavaScript libraries and PHP back-end that SquirrelMail uses in order to implement a web email application? No.
Can Google change that JavaScript tomorrow without breaking interoperability? Yes, and they probably will.
But could Gmail be as successful without the worldwide SMTP infrastructure it ties in to? Probably not.
I see the same situation here. A web browser with real-time communication capabilities will work in conjunction with a web site that serves up the HTML and JavaScript that makes up the calling application. For some applications, this will be sufficient. For others, one will want to implement SIP or XMPP/Jingle or something else in order to gateway these calls to other networks. The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof.
Matthew Kaufman
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Hi Justin, I’m not sure I fully understand the task b) that you describe below. You are not talking about a representation/mechanism for a wire protocol, but something related to the API? I mean, if everyone is going to define and implement their own “signaling” protocol on HTTP or websockets, what is it exactly that would need to be standardized? If we use webmail as an example, there has been no need to define any mapping/format related to SMTP. So if that case is analogous to this one, why we need to do something different here? I know that the difference is that in RTC-Web we want to establish media streams end-to-end between the browsers, unlike in e-mail. So, the cases are not fully analogous after all. Some elaboration on that point would help many people to understand the RTC-Web need better, I think. Thanks, Markus From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Justin Uberti Sent: 02 February, 2011 08:47 To: Matthew Kaufman Cc: rtc-web@alvestrand.no; DISPATCH list Subject: Re: [dispatch] [RTW] Does RTC-WEB need to pick a signaling protocol? Great example. And just like Gmail uses an SMTP gateway to connect its own HTTP-based protocol to the rest of the world, Gmail voice and video uses a XMPP gateway to connect its HTTP-based signaling to other XMPP clients. Others in this space have done similar things by implementing XMPP clients in Javascript. So I think we have existence proofs that this approach, in addition to being extremely flexible, is entirely workable today. The two things that we need to specify are a) the semantics of the signaling (i.e. the offer-answer mechanism that both SIP and XMPP are patterned around) b) the mechanism through which session offers and answers will be described (e.g. some SDP-ish thing that is suitable for the web). a) seems rather straightforward. b) will likely be trickier - we need something that can be mapped to SDP, for SIP gateways, but we probably want it to be represented as JSON for benefit of web developers. So the challenge becomes, what format can we define that can be unambiguously mapped to/from SDP, but doesn't bring with it all of the baggage of SDP? --justin On Mon, Jan 31, 2011 at 8:12 AM, Matthew Kaufman <matthew.kaufman@skype.net<mailto:matthew.kaufman@skype.net>> wrote: On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote: That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived. Agreed. Consider the case of Gmail (or any other web-based email) Did every web browser on the planet need to be upgraded to speak IMAP or SMTP in order for Gmail to be implemented? No. Does the JavaScript that Gmail sends down to your browser in order to implement its UI need to be standardized among web email platforms? No. Does Google need to use the same JavaScript libraries and PHP back-end that SquirrelMail uses in order to implement a web email application? No. Can Google change that JavaScript tomorrow without breaking interoperability? Yes, and they probably will. But could Gmail be as successful without the worldwide SMTP infrastructure it ties in to? Probably not. I see the same situation here. A web browser with real-time communication capabilities will work in conjunction with a web site that serves up the HTML and JavaScript that makes up the calling application. For some applications, this will be sufficient. For others, one will want to implement SIP or XMPP/Jingle or something else in order to gateway these calls to other networks. The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof. Matthew Kaufman _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no<mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web
I agree that it is important to have rtcweb interoperable with the rest of the world (i.e. millions of existing end-points that use SIP or XMPP). I think that interoperability with such protocols - which are IETF protocols by the way - should really be in the scope of the charter. On Wed, Feb 2, 2011 at 7:47 AM, Justin Uberti <juberti@google.com> wrote:
Great example.
And just like Gmail uses an SMTP gateway to connect its own HTTP-based protocol to the rest of the world, Gmail voice and video uses a XMPP gateway to connect its HTTP-based signaling to other XMPP clients. Others in this space have done similar things by implementing XMPP clients in Javascript.
So I think we have existence proofs that this approach, in addition to being extremely flexible, is entirely workable today.
The two things that we need to specify are a) the semantics of the signaling (i.e. the offer-answer mechanism that both SIP and XMPP are patterned around) b) the mechanism through which session offers and answers will be described (e.g. some SDP-ish thing that is suitable for the web).
a) seems rather straightforward. b) will likely be trickier - we need something that can be mapped to SDP, for SIP gateways, but we probably want it to be represented as JSON for benefit of web developers. So the challenge becomes, what format can we define that can be unambiguously mapped to/from SDP, but doesn't bring with it all of the baggage of SDP?
--justin
On Mon, Jan 31, 2011 at 8:12 AM, Matthew Kaufman < matthew.kaufman@skype.net> wrote:
On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote:
That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived.
Agreed. Consider the case of Gmail (or any other web-based email)
Did every web browser on the planet need to be upgraded to speak IMAP or SMTP in order for Gmail to be implemented? No.
Does the JavaScript that Gmail sends down to your browser in order to implement its UI need to be standardized among web email platforms? No.
Does Google need to use the same JavaScript libraries and PHP back-end that SquirrelMail uses in order to implement a web email application? No.
Can Google change that JavaScript tomorrow without breaking interoperability? Yes, and they probably will.
But could Gmail be as successful without the worldwide SMTP infrastructure it ties in to? Probably not.
I see the same situation here. A web browser with real-time communication capabilities will work in conjunction with a web site that serves up the HTML and JavaScript that makes up the calling application. For some applications, this will be sufficient. For others, one will want to implement SIP or XMPP/Jingle or something else in order to gateway these calls to other networks. The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof.
Matthew Kaufman
_______________________________________________ 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
With respect to b) one challenge is obtaining the IP addresses necessary to create the SDP offer. (see http://javascript.about.com/library/blip.htm). On Tue, Feb 1, 2011 at 10:47 PM, Justin Uberti <juberti@google.com> wrote:
Great example.
And just like Gmail uses an SMTP gateway to connect its own HTTP-based protocol to the rest of the world, Gmail voice and video uses a XMPP gateway to connect its HTTP-based signaling to other XMPP clients. Others in this space have done similar things by implementing XMPP clients in Javascript.
So I think we have existence proofs that this approach, in addition to being extremely flexible, is entirely workable today.
The two things that we need to specify are a) the semantics of the signaling (i.e. the offer-answer mechanism that both SIP and XMPP are patterned around) b) the mechanism through which session offers and answers will be described (e.g. some SDP-ish thing that is suitable for the web).
a) seems rather straightforward. b) will likely be trickier - we need something that can be mapped to SDP, for SIP gateways, but we probably want it to be represented as JSON for benefit of web developers. So the challenge becomes, what format can we define that can be unambiguously mapped to/from SDP, but doesn't bring with it all of the baggage of SDP?
--justin
On Mon, Jan 31, 2011 at 8:12 AM, Matthew Kaufman < matthew.kaufman@skype.net> wrote:
On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote:
That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived.
Agreed. Consider the case of Gmail (or any other web-based email)
Did every web browser on the planet need to be upgraded to speak IMAP or SMTP in order for Gmail to be implemented? No.
Does the JavaScript that Gmail sends down to your browser in order to implement its UI need to be standardized among web email platforms? No.
Does Google need to use the same JavaScript libraries and PHP back-end that SquirrelMail uses in order to implement a web email application? No.
Can Google change that JavaScript tomorrow without breaking interoperability? Yes, and they probably will.
But could Gmail be as successful without the worldwide SMTP infrastructure it ties in to? Probably not.
I see the same situation here. A web browser with real-time communication capabilities will work in conjunction with a web site that serves up the HTML and JavaScript that makes up the calling application. For some applications, this will be sufficient. For others, one will want to implement SIP or XMPP/Jingle or something else in order to gateway these calls to other networks. The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof.
Matthew Kaufman
_______________________________________________ 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
Is there some understanding on the list on how the IP addresses in SDP can be reconciled with the USAF RFC 3424? http://www.rfc-editor.org/rfc/rfc3424.txt ³...a process whereby some originating process attempts to determine or fix the address (and port) by which it is known - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. There are only heuristics and workarounds to attempt to achieve this effect; there is no 100% solution. Since NATs may also dynamically reclaim or readjust translations, "keep-alive" and periodic re- polling may be required. Use of these workarounds MUST be considered transitional in IETF protocols, and a better architectural solution is being sought. The explicit intention is to deprecate any such workarounds when sound technical approaches are available.² Obviously there is much more dead stuff in SDP besides using the misleading IP addresses, but this seems to be a deep architectural flaw. There were some early attempts to do SDPng and we know today much more: http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07 Why not replace SDP, since it deals only with a/v codec negotiation with a more general, standards based metadata approach? For example including Web conferencing displays and UI control capabilities. Of course such a new approach must be easily mapped to the existing global SIP VoIP infrastructure. Or are the no ³sound technical approaches² available at all? Thanks, Henry On 2/2/11 11:55 AM, "Bernard Aboba" <bernard.aboba@gmail.com> wrote:
With respect to b) one challenge is obtaining the IP addresses necessary to create the SDP offer. (see http://javascript.about.com/library/blip.htm ).
On Tue, Feb 1, 2011 at 10:47 PM, Justin Uberti <juberti@google.com> wrote:
Great example.
And just like Gmail uses an SMTP gateway to connect its own HTTP-based protocol to the rest of the world, Gmail voice and video uses a XMPP gateway to connect its HTTP-based signaling to other XMPP clients. Others in this space have done similar things by implementing XMPP clients in Javascript.
So I think we have existence proofs that this approach, in addition to being extremely flexible, is entirely workable today.
The two things that we need to specify are a) the semantics of the signaling (i.e. the offer-answer mechanism that both SIP and XMPP are patterned around) b) the mechanism through which session offers and answers will be described (e.g. some SDP-ish thing that is suitable for the web).
a) seems rather straightforward. b) will likely be trickier - we need something that can be mapped to SDP, for SIP gateways, but we probably want it to be represented as JSON for benefit of web developers. So the challenge becomes, what format can we define that can be unambiguously mapped to/from SDP, but doesn't bring with it all of the baggage of SDP?
--justin
On Mon, Jan 31, 2011 at 8:12 AM, Matthew Kaufman <matthew.kaufman@skype.net> wrote:
On 1/29/2011 6:35 AM, Jonathan Rosenberg wrote:
That said, even if one asks the question of whether it is a good idea for us to pick something, I think the answer is no. The enormous benefit of the web model is its ability for innovation and velocity. Standardization is not needed for communications within the domain of the provider; new features can be developed and deployed as quickly as they can be conceived.
Agreed. Consider the case of Gmail (or any other web-based email)
Did every web browser on the planet need to be upgraded to speak IMAP or SMTP in order for Gmail to be implemented? No.
Does the JavaScript that Gmail sends down to your browser in order to implement its UI need to be standardized among web email platforms? No.
Does Google need to use the same JavaScript libraries and PHP back-end that SquirrelMail uses in order to implement a web email application? No.
Can Google change that JavaScript tomorrow without breaking interoperability? Yes, and they probably will.
But could Gmail be as successful without the worldwide SMTP infrastructure it ties in to? Probably not.
I see the same situation here. A web browser with real-time communication capabilities will work in conjunction with a web site that serves up the HTML and JavaScript that makes up the calling application. For some applications, this will be sufficient. For others, one will want to implement SIP or XMPP/Jingle or something else in order to gateway these calls to other networks. The SIP implementation can live in the JavaScript, up in the web server, in a separate gateway, or any combination thereof.
Matthew Kaufman
_______________________________________________ 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
On 02/02/11 11:19, Henry Sinnreich wrote:
Is there some understanding on the list on how the IP addresses in SDP can be reconciled with the USAF RFC 3424? Nit: UNSAF, not USAF. http://www.rfc-editor.org/rfc/rfc3424.txt
"...a process whereby some originating process attempts to determine or fix the address (and port) by which it is known - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. There are only heuristics and workarounds to attempt to achieve this effect; there is no 100% solution. Since NATs may also dynamically reclaim or readjust translations, "keep-alive" and periodic re- polling may be required. Use of these workarounds MUST be considered transitional in IETF protocols, and a better architectural solution is being sought. The explicit intention is to deprecate any such workarounds when sound technical approaches are available." In our case, the answer that has proved workable is called STUN.
Obviously there is much more dead stuff in SDP besides using the misleading IP addresses, but this seems to be a deep architectural flaw. There were some early attempts to do SDPng and we know today much more: http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07
Why not replace SDP, since it deals only with a/v codec negotiation with a more general, standards based metadata approach? For example including Web conferencing displays and UI control capabilities. Of course such a new approach must be easily mapped to the existing global SIP VoIP infrastructure.
Or are the no "sound technical approaches" available at all? I'm all in favour of replacing SDP, but would not like to require that before we can produce any output from this group.
Justin's idea of sorting out what information we need and specifying how that maps into SDP (just like is currently done by Jingle) might be a reasonable approach that can allow us to not fossilize SDP's misfeatures forever. Harald
Alternatives can be explored for how to represent the information provided by SDP, but the enumeration and testing of potential endpoints within an offer-answer exchange is at the core of ICE (RFC 5245), and is also a potential means for demonstrating media authorization. If the Javascript limitations on enumeration of physical or logical addresses can't be overcome, we might have to live with server reflexive and relayed endpoint identifiers (assuming that server reflexive and relayed endpoint identifiers don't trigger similar concerns). Replacing addresses with names could be done prior to the offer/answer exchange but this might introduce vulnerabilities (e.g. voice hammer attacks based on DNS cache poisoning). Date: Wed, 2 Feb 2011 16:09:48 -0800 From: harald@alvestrand.no To: rtc-web@alvestrand.no Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol? On 02/02/11 11:19, Henry Sinnreich wrote: Message body Is there some understanding on the list on how the IP addresses in SDP can be reconciled with the USAF RFC 3424? Nit: UNSAF, not USAF. http://www.rfc-editor.org/rfc/rfc3424.txt “...a process whereby some originating process attempts to determine or fix the address (and port) by which it is known - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. There are only heuristics and workarounds to attempt to achieve this effect; there is no 100% solution. Since NATs may also dynamically reclaim or readjust translations, "keep-alive" and periodic re- polling may be required. Use of these workarounds MUST be considered transitional in IETF protocols, and a better architectural solution is being sought. The explicit intention is to deprecate any such workarounds when sound technical approaches are available.” In our case, the answer that has proved workable is called STUN. Obviously there is much more dead stuff in SDP besides using the misleading IP addresses, but this seems to be a deep architectural flaw. There were some early attempts to do SDPng and we know today much more: http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07 Why not replace SDP, since it deals only with a/v codec negotiation with a more general, standards based metadata approach? For example including Web conferencing displays and UI control capabilities. Of course such a new approach must be easily mapped to the existing global SIP VoIP infrastructure. Or are the no “sound technical approaches” available at all? I'm all in favour of replacing SDP, but would not like to require that before we can produce any output from this group. Justin's idea of sorting out what information we need and specifying how that maps into SDP (just like is currently done by Jingle) might be a reasonable approach that can allow us to not fossilize SDP's misfeatures forever. Harald _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
I would expect that the APIs that this group creates would handle the details of obtaining any needed addresses (whether they be local, server reflexive, or relayed endpoints). Do we think there is a significant security concern here (above and beyond exposing the ability to send audio and video from your computer)? On Wed, Feb 2, 2011 at 7:49 PM, Bernard Aboba <bernard_aboba@hotmail.com>wrote:
Alternatives can be explored for how to represent the information provided by SDP, but the enumeration and testing of potential endpoints within an offer-answer exchange is at the core of ICE (RFC 5245), and is also a potential means for demonstrating media authorization. If the Javascript limitations on enumeration of physical or logical addresses can't be overcome, we might have to live with server reflexive and relayed endpoint identifiers (assuming that server reflexive and relayed endpoint identifiers don't trigger similar concerns). Replacing addresses with names could be done prior to the offer/answer exchange but this might introduce vulnerabilities (e.g. voice hammer attacks based on DNS cache poisoning). ------------------------------ Date: Wed, 2 Feb 2011 16:09:48 -0800 From: harald@alvestrand.no To: rtc-web@alvestrand.no Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?
On 02/02/11 11:19, Henry Sinnreich wrote:
Is there some understanding on the list on how the IP addresses in SDP can be reconciled with the USAF RFC 3424?
Nit: UNSAF, not USAF.
http://www.rfc-editor.org/rfc/rfc3424.txt
“...a process whereby some originating process attempts to determine or fix the address (and port) by which it is known - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. There are only heuristics and workarounds to attempt to achieve this effect; there is no 100% solution. Since NATs may also dynamically reclaim or readjust translations, "keep-alive" and periodic re- polling may be required. Use of these workarounds MUST be considered transitional in IETF protocols, and a better architectural solution is being sought. The explicit intention is to deprecate any such workarounds when sound technical approaches are available.”
In our case, the answer that has proved workable is called STUN.
Obviously there is much more dead stuff in SDP besides using the misleading IP addresses, but this seems to be a deep architectural flaw. There were some early attempts to do SDPng and we know today much more: http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07
Why not replace SDP, since it deals only with a/v codec negotiation with a more general, standards based metadata approach? For example including Web conferencing displays and UI control capabilities. Of course such a new approach must be easily mapped to the existing global SIP VoIP infrastructure.
Or are the no “sound technical approaches” available at all?
I'm all in favour of replacing SDP, but would not like to require that before we can produce any output from this group.
Justin's idea of sorting out what information we need and specifying how that maps into SDP (just like is currently done by Jingle) might be a reasonable approach that can allow us to not fossilize SDP's misfeatures forever.
Harald
_______________________________________________ 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
On 02/03/11 01:32, Justin Uberti wrote:
I would expect that the APIs that this group creates would handle the details of obtaining any needed addresses (whether they be local, server reflexive, or relayed endpoints). Do we think there is a significant security concern here (above and beyond exposing the ability to send audio and video from your computer)? Apart from the known security concerns that come automatically from sharing IP addresses (such as revealing your network attachment location to whoever gets the IP address), I don't see any huge ones.
On Wed, Feb 2, 2011 at 7:49 PM, Bernard Aboba <bernard_aboba@hotmail.com <mailto:bernard_aboba@hotmail.com>> wrote:
Alternatives can be explored for how to represent the information provided by SDP, but the enumeration and testing of potential endpoints within an offer-answer exchange is at the core of ICE (RFC 5245), and is also a potential means for demonstrating media authorization. If the Javascript limitations on enumeration of physical or logical addresses can't be overcome, we might have to live with server reflexive and relayed endpoint identifiers (assuming that server reflexive and relayed endpoint identifiers don't trigger similar concerns). Replacing addresses with names could be done prior to the offer/answer exchange but this might introduce vulnerabilities (e.g. voice hammer attacks based on DNS cache poisoning). ------------------------------------------------------------------------ Date: Wed, 2 Feb 2011 16:09:48 -0800 From: harald@alvestrand.no <mailto:harald@alvestrand.no> To: rtc-web@alvestrand.no <mailto:rtc-web@alvestrand.no> Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol?
On 02/02/11 11:19, Henry Sinnreich wrote:
Is there some understanding on the list on how the IP addresses in SDP can be reconciled with the USAF RFC 3424?
Nit: UNSAF, not USAF.
http://www.rfc-editor.org/rfc/rfc3424.txt
“...a process whereby some originating process attempts to determine or fix the address (and port) by which it is known - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. There are only heuristics and workarounds to attempt to achieve this effect; there is no 100% solution. Since NATs may also dynamically reclaim or readjust translations, "keep-alive" and periodic re- polling may be required. Use of these workarounds MUST be considered transitional in IETF protocols, and a better architectural solution is being sought. The explicit intention is to deprecate any such workarounds when sound technical approaches are available.”
In our case, the answer that has proved workable is called STUN.
Obviously there is much more dead stuff in SDP besides using the misleading IP addresses, but this seems to be a deep architectural flaw. There were some early attempts to do SDPng and we know today much more: http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07
Why not replace SDP, since it deals only with a/v codec negotiation with a more general, standards based metadata approach? For example including Web conferencing displays and UI control capabilities. Of course such a new approach must be easily mapped to the existing global SIP VoIP infrastructure.
Or are the no “sound technical approaches” available at all?
I'm all in favour of replacing SDP, but would not like to require that before we can produce any output from this group.
Justin's idea of sorting out what information we need and specifying how that maps into SDP (just like is currently done by Jingle) might be a reasonable approach that can allow us to not fossilize SDP's misfeatures forever.
Harald
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no <mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no <mailto:RTC-Web@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/rtc-web
Given that people have been using workarounds to obtain IP addresses, the value of keeping this out of Javascript seems marginal. However, since the W3C will be handling APIs, not the IETF, this does raise the question of how issues like this will be coordinated. Date: Thu, 3 Feb 2011 08:50:27 -0800 From: harald@alvestrand.no To: juberti@google.com CC: bernard_aboba@hotmail.com; rtc-web@alvestrand.no Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol? On 02/03/11 01:32, Justin Uberti wrote: I would expect that the APIs that this group creates would handle the details of obtaining any needed addresses (whether they be local, server reflexive, or relayed endpoints). Do we think there is a significant security concern here (above and beyond exposing the ability to send audio and video from your computer)? Apart from the known security concerns that come automatically from sharing IP addresses (such as revealing your network attachment location to whoever gets the IP address), I don't see any huge ones. On Wed, Feb 2, 2011 at 7:49 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote: Alternatives can be explored for how to represent the information provided by SDP, but the enumeration and testing of potential endpoints within an offer-answer exchange is at the core of ICE (RFC 5245), and is also a potential means for demonstrating media authorization. If the Javascript limitations on enumeration of physical or logical addresses can't be overcome, we might have to live with server reflexive and relayed endpoint identifiers (assuming that server reflexive and relayed endpoint identifiers don't trigger similar concerns). Replacing addresses with names could be done prior to the offer/answer exchange but this might introduce vulnerabilities (e.g. voice hammer attacks based on DNS cache poisoning). Date: Wed, 2 Feb 2011 16:09:48 -0800 From: harald@alvestrand.no To: rtc-web@alvestrand.no Subject: Re: [RTW] [dispatch] Does RTC-WEB need to pick a signaling protocol? On 02/02/11 11:19, Henry Sinnreich wrote: Is there some understanding on the list on how the IP addresses in SDP can be reconciled with the USAF RFC 3424? Nit: UNSAF, not USAF. http://www.rfc-editor.org/rfc/rfc3424.txt “...a process whereby some originating process attempts to determine or fix the address (and port) by which it is known - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections. There are only heuristics and workarounds to attempt to achieve this effect; there is no 100% solution. Since NATs may also dynamically reclaim or readjust translations, "keep-alive" and periodic re- polling may be required. Use of these workarounds MUST be considered transitional in IETF protocols, and a better architectural solution is being sought. The explicit intention is to deprecate any such workarounds when sound technical approaches are available.” In our case, the answer that has proved workable is called STUN. Obviously there is much more dead stuff in SDP besides using the misleading IP addresses, but this seems to be a deep architectural flaw. There were some early attempts to do SDPng and we know today much more: http://tools.ietf.org/html/draft-ietf-mmusic-sdpng-07 Why not replace SDP, since it deals only with a/v codec negotiation with a more general, standards based metadata approach? For example including Web conferencing displays and UI control capabilities. Of course such a new approach must be easily mapped to the existing global SIP VoIP infrastructure. Or are the no “sound technical approaches” available at all? I'm all in favour of replacing SDP, but would not like to require that before we can produce any output from this group. Justin's idea of sorting out what information we need and specifying how that maps into SDP (just like is currently done by Jingle) might be a reasonable approach that can allow us to not fossilize SDP's misfeatures forever. Harald _______________________________________________ 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 _______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Oh hell no.... Really, what we need are the primitives that make a web app able to do things like slurp data from a microphone and send it someplace useful. We might also need interfaces to A/V streams (maybe even RTP), and mixers. We need those primitives exposed to things like Javascript. What we don't need is an API that turns every browser into a generic SIP UA capable of being reused in haphazard fashion, such that everybody and his chihuahua reskins their "SIP browser phone" with CSS, and every browser swells to the size of the Hindenberg just before the fatal spark. -- Dean
participants (13)
-
Bernard Aboba -
Bernard Aboba -
Dean Willis -
Erik Lagerway -
Erik Lagerway -
Harald Alvestrand -
Henry Sinnreich -
Jonathan Rosenberg -
Justin Uberti -
Markus.Isomaki＠nokia.com -
Matthew Kaufman -
Peter Musgrave -
Xavier Marjou