Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 3 Oct 2011 23:54:02 +0530

Hadriel,

Sorry for the delay response. I have mentioned the reason for "standard signaling protocol" as a separate draft and the related thread is http://www.ietf.org/mail-archive/web/rtcweb/current/msg01733.html. 

I agree to the fact that SCCP protocol is decided by Cisco folks but it does not mean that every company in the world has to create their own version of SCCP protocol and IETF should not force every company to re-invent the wheel.

The intention of standard signaling protocol is not against those who have the interest in creating their own proprietary signaling protocol. The main purpose is for the welfare of those whose focus is not signaling but interested in Real-time communication. JavaScript library by third party is worst case in case there is no native standard signaling protocol exists for RTCWeb.

Let us discuss how much services has to be provided by standard signaling protocol.

Thanks
Partha

>-----Original Message-----
>From: Hadriel Kaplan [mailto:[email-masked]]
>Sent: Friday, September 16, 2011 7:55 AM
>To: Ravindran Parthasarathi
>Cc: Saúl Ibarra Corretgé; <[email-masked]>
>Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About
>defining a signaling protocol for WebRTC (or not)]
>
>
>There is no need for a "default signaling protocol", because the
>"signaling" is between the browser's Javascript and its web server.  And
>as for the signaling protocol the web server has to support in order to
>speak to other servers or non-RTCweb endpoints, even if we specified to
>use SIP we'd just be summarily ignored by those who don't want to,
>because they actually don't *need* to.  It doesn't hurt interoperability
>of rtcweb if they don't implement SIP - it just means they can't talk to
>other SIP devices/servers.  But it's not like we need an RFC to say "if
>you don't implement X then you can't talk to people who do X".
>
>Think of this RTCWEB concept as Skinny/SCCP.  The Web Server is Call
>Manager, and the browser is the Skinny phone, but in this case instead
>of needing a 7960 phone, the Skinny protocol was written in javascript
>and uses a browser's user interface for its GUI and the built-in RTP
>library for media. (in fact one could probably write a javascript to do
>just that, if Call Manager handled SCCP over websocket)
>
>Clearly the IETF does not need to define for Cisco a standardized
>replacement for the SCCP protocol for this to work, because one isn't
>needed since the client javascript and server are built by the same
>developers and they know how their proprietary signaling works.  So how
>about for the signaling Call Manager would use to other VoIP devices,
>like gateways or VoIP service providers?  Does the IETF need to tell
>Cisco what peer-to-peer protocol(s) to implement on Call Manager?  No,
>and we never have.  Cisco's product managers decide that.  They decide
>if Call Manager needs to be able to communicate a standard protocol at
>all, such as SIP or H.323, and which one/any of those.  They decide
>based on their use-cases/need.
>
>Some rtcweb developers may not do any standard signaling protocol, ever.
>For example many Instant Messaging providers still have closed
>environments to this day. (e.g., AIM, YIM, MSN, etc.)  Some may choose
>to only use H.323, or XMPP, or IAX, or even BICC.  Some may choose to
>only support SIP with 3GPP extensions.  Obviously most of us think/hope
>people do SIP, but really the market makes those types of decisions, not
>the IETF.  Just like the IETF standardized MGCP but didn't specify what
>the MGCP Call Agent had to support to speak to other Call Agents.  SIP
>was given as an example in MGCP, but not mandated.
>
>The only thing we need to do for rtcweb is make sure the RTP library
>built into the browser supports media in such a way that it can
>communicate with other RTP peers at a media plane, regardless of what
>signaling protocol those peers might be using, preferably without going
>through media gateways.  And obviously since SIP is a very common
>protocol and defined by the IETF we need to make sure it's possible to
>use SIP on the rtcweb server, but we can't *mandate* that it be used or
>supported, and if we did it wouldn't change anything.
>
>-hadriel
>
>
>On Sep 15, 2011, at 7:56 PM, Ravindran Parthasarathi wrote:
>
>> I really didn't get your argument fully because in case there is no
>default signaling protocol, it is unavoidable to have island of devices
>without gateways but you argue other way around.
>>
>> I specifically asked for the scope of your opinion on RTCWeb work is
>between browser-to-browser or browser-to-other end-point to know whether
>parallel universe has to be build or not. In case there is no default
>signaling protocol, it is impossible to communicate between browser-to-
>endpoint without gateways. Let us assume that the intention of RTCWeb is
>to create island of browser devices even then the native signaling
>protocol for RTCWeb has advantage over Jquery library and plugin is not
>the solution.
>>
>> Having said that, I agree that it is possible to implement RTP or STUN
>or SIP stack or codec using Javascript or plugins but interop and better
>performance is not guaranteed.
>>
>> Thanks
>> Partha

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 3 Oct 2011 22:32:26 +0200

> I agree to the fact that SCCP protocol is decided by Cisco folks but it does not mean that every company in the world has to create their own version of SCCP protocol and IETF should not force ever…

I agree, but that's not mean that a default signaling protocol
built-in the browser is required. Lot of people uses jQuery and nobody
asks for it to be included in browsers JS stack natively.

What you suggest can easily achieved with a JS library implementing
your so much desired default signaling protocol.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 4 Oct 2011 11:04:34 +0530

Hi Inaki,

Hope you agree that Real-time communication in web is possible without RTCWeb standard and it is clearly stated in RTCWeb charter first line as well "There are a number of proprietary implementations that provide direct
  interactive rich communication using audio, video, collaboration,
  games, etc. between two peers' web-browsers.". I understand that jquery or libjingle library may act as an alternative but it is far better in case signaling protocol is provided in the browser platform itself. 

As a RTCweb developer, the standard signaling protocol helps as follows:

1) there is no need to peek into each license of jquery library and understand the terms and conditions for developing the real-time application.
2) No need of every browser user to download jquery library from each website. Unlike few number of E-mail provider (gmail, yahoo, hotmail), the real-time application provider will be huge. But number of browser is going to be countable and not as much as real-time websites are.
3) I heard from web developer about browser compatible jquery development story which is same as SIP interop issues. 
4) Perform of the native signaling protocol will be better than jquery library. Please note that plugin is forbidden in RTCWeb client (browser).

IMO, Jquery will not solve the indented problem.  

The main motive for RTCWeb standard signaling is rapid real-time application in browser platform by any web developer and there should be no need of signaling expert in each website development team. 

Thanks
Partha

>From: Iñaki Baz Castillo [mailto:[email-masked]]
>Sent: Tuesday, October 04, 2011 2:02 AM
>Cc: Hadriel Kaplan; [email-masked]
>> I agree to the fact that SCCP protocol is decided by Cisco folks but
>it does not mean that every company in the world has to create their own
>version of SCCP protocol and IETF should not force every company to re-
>invent the wheel.
>

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 4 Oct 2011 09:01:34 +0200

Hi,

> 1) there is no need to peek into each license of jquery library and understand the terms and conditions for developing the real-time application.

This is something you always need to do regardless of the project IMHO, you need to check that all libraries you use are fine with your license ASO, I don't see how RTCWeb is different here.

> 2) No need of every browser user to download jquery library from each website. Unlike few number of E-mail provider (gmail, yahoo, hotmail), the real-time application provider will be huge. But num…

What is "huge" for you these days? Assuming it's a JS library, it can be compressed.

> 3) I heard from web developer about browser compatible jquery development story which is same as SIP interop issues. 

Yet you are bringing a new iterop issue to the table: SIP or XMPP <-> the protocol in the browsers.

> 4) Perform of the native signaling protocol will be better than jquery library. Please note that plugin is forbidden in RTCWeb client (browser).

Well, it's a client, not a server, so performance will definitely not be an issue.

I didn't get that last part, do you mean that plugins are forbidden in RTCWeb client? Anyway, JS is enough. I'm not sure about Googles' plans with regards to NaCl, but if they plan to push that technology forward so that other browsers implement it, the signaling could even be done in C, in case you are worried about performance, though I know it's not an issue.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Tim Panton <[email-masked]>
Date: Tue, 4 Oct 2011 10:16:26 +0100

> Let us discuss how much services has to be provided by standard signaling protocol.

Partha - here's a quick review of http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00

I'm not going to go through it line by line as I disagree with almost all of it, so I
focus on 2 key assumptions:

Firstly -> 

Fig 1 is wrong  - in the _huge_ majority of instances there will be
only one web server in such a diagram. Federated services will only be the minority case.

Where services do interconnect, they will (As in the SIP and PSTN world today) go through 
policy gateways which will manage tariffs and dataflow into and out of the service.

So there should be either 1 web server or 2 webservers and 2 policy gateways.

If you correct this diagram  the rest of the document is invalidated.

Secondly ->

You assume that being compatible with a legacy protocol would be a good thing, 
but don't examine why. 
I contend that there is no suitable legacy protocol and no advantage would be conveyed by 
implementing one directly in a browser. I'll use SIP to illustrate my point:

The illusion is that there are lots of SIP devices that users are itching to call from their
browsers. There aren't. Almost all the SIP devices in the world are behind policy firewalls
and are not directly accessible from a browser based SIP implementation.

Even if they were reachable, our experience of browser based realtime audio
(at phonefromhere.com) shows that people don't use the browser to call PSTN-like
endpoints. If they want a PSTN experience, they pick up one of the 3+ phones available to
them. 
(What they do use browser based realtime audio for is dating, conference calls, collaboration etc)

Even if all the SIP devices were reachable and people wanted to reach them, 
we still should not be using that as the core case to base the webRTC spec upon.
There are (I guess) already more users of the facebook site than there are SIP devices.

Conclusion -> 

So we should focus upon the most common use-case and not get distracted into discussing 
what is at best an edge case.

The risk of such a discussion (of a standard signalling protocol) is that we will still be discussing it in 3 
years time and each of the browser makers will have implemented their own subtly different
webRTC solutions.

Tim, speaking for himself, but based on bitter experience at phonefromhere.com

---

From: Randell Jesup <[email-masked]>
Date: Tue, 04 Oct 2011 10:43:18 -0400

> only one web server in such a diagram. Federated services will only be the minority case.

Agreed.

> The illusion is that there are lots of SIP devices that users are itching to call from their browsers. There aren't.

I agree, that is not a reason for any standard on signalling (though as 
you say Partha didn't actually give a reason).  If someone is building 
an access-the-PSTN app (and they will), they can use or build a lib to 
do so - though I'll also mention these fully-functional JS SIP/etc 
libraries we presume don't exist yet and are a lot of work to write and 
debug.  A Skype can do so easily; a small PBX add-on company using 
Asterisk not so much.

I have a different argument: I want it to be *easy* for a website 
author/app developer to add audio or video for their users.   The 
developers aren't experts on glare, forking, the intricacies of getting 
offer-answer (or whatever) right, ad nauseum.  If you ask them to 
*design* their own protocol, they'll make a ton of 'rookie' mistakes.  
And for added fun, they'll likely never correct them and in many cases 
never understand why the bug is occasionally reported by their users.

A random example is forking - forking will happen (forward call to all 
the devices the person logged in under) , and handling forking well 
requires some thought and experience.

The obvious answer is "those people shouldn't design a protocol (leave 
that to the big guys), they should use a standard library."  Ok, great, but:

1) These don't exist yet (minor issue; one presumes they'll exist "soon")
2) The quality and testing of these libraries is unlikely to equal that 
of existing signalling stacks available freely for quite a while
3) Inaki's (sorry about the cedilla) point about "website-based 
libraries can be updated more often than ones baked into a browser" is 
valid, but it has a flip-side - the swarm of smaller users of webrtc are 
likely to download a version of jSIP.js (or whatever) and are not likely 
to actively track updates.  My understanding is that this is rife in the 
use of things like jquery - upgrading is time-consuming and risks 
breakage, and requires QA.  People grab one version and never change it 
- while Firefox for example updates every 6 weeks.  (He may have a 
better argument with IE users, especially in business, but my point 
still holds.)  The larger, sophisticated users are more likely to 
update, or debug problems when they occur, so I'm not worried about them 
- and they can use jSIP.js regardless if there's a signalling protocol 
in the browser.

Point 3 is in ways the strongest point here, since I assume these 
libraries will exist at some point.

You'll note I'm not arguing for SIP here - I'm arguing that there are 
valid reasons for easy default signalling *as and option*, especially 
for the health of the "little guy" app/service developer who wants to 
add RT media.  If we had a functional, debugged, standard JS protocol 
that was free and we could figure a way for app developers to ease the 
update process, it would undercut my argument - but we don't have that, 
and we can't count on that, at least not for a while.  It does not 
*have* to be any existing signalling standard - though using one of 
those is probably easiest, quickest (if the wars over whether/what 
subside) and least error-prone.

> The risk of such a discussion (of a standard signalling protocol) is that we will still be discussing it in 3 years time and each of the browser makers will have implemented their own subtly different webRTC solutions.

Yes, this is critical.  We need to finish it.  I'd rather have it 
finished and a strong project to build a "standard" external JS library 
under way than to have the whole thing wait.  But if I had my druthers 
(what the bleep are those, anyways?) I'd have an optional signalling 
protocol available.

-- 
Randell Jesup
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 4 Oct 2011 08:32:34 -0700

On Tue, Oct 4, 2011 at 7:43 AM, Randell Jesup <[email-masked]>wrote:
>
> 3) Inaki's (sorry about the cedilla) point about "website-based libraries
> can be updated more often than ones baked into a browser" is valid, but it
> has a flip-side - the swarm of smaller users of webrtc are likely to
> download a version of jSIP.js (or whatever) and are not likely to actively
> track updates.  My understanding is that this is rife in the use of things
> like jquery - upgrading is time-consuming and risks breakage, and requires
> QA.  People grab one version and never change it - while Firefox for example
> updates every 6 weeks.  (He may have a better argument with IE users,
> especially in business, but my point still holds.)

This is my understanding as well, and it's something that is encouraged by
the way that these
libraries are distributed, namely that the obvious behavior if you go to the
JQuery site is to
just download one of the canned versions, which of course is specific. Even
if you use one
of the CDN versions (see:
http://docs.jquery.com/Downloading_jQuery#CDN_Hosted_jQuery),
the links are all to specific versions. So, the consequence is that people
en up nailed to
one version.

This doesn't necessarily mean that client libraries will upgrade more slowly
than the browsers,
but as far as I know it's not a decided question either way.

Best,
-Ekr

---

From: Jim McEachern <[email-masked]>
Date: Tue, 4 Oct 2011 15:59:14 +0000

On Tue, Oct 4, 2011 at 10:43 AM, Randell Jesup <[email-masked]> wrote:

> developers aren't experts on glare, forking, the intricacies of getting offer-
> answer (or whatever) right, ad nauseum.  If you ask them to
> And for added fun, they'll likely never correct them and in many cases never
> understand why the bug is occasionally reported by their users.
> 
> A random example is forking - forking will happen (forward call to all the
> devices the person logged in under) , and handling forking well requires
> some thought and experience.
> 

The problem with this argument is that it involves complex functionality that would not be covered by basic SIP in the browser. 
Are you proposing that the full SIP stack, with support for forking, early media, etc. be built into all browsers?  If yes, then we are already at the bottom of the "slippery slope" that people fear. 
 If no, then the app developer will still need to deal with this complexity.

Am I missing something?

Jim

---

From: Tim Panton <[email-masked]>
Date: Tue, 4 Oct 2011 17:00:36 +0100

On 4 Oct 2011, at 15:43, Randell Jesup wrote:

> I agree, that is not a reason for any standard on signalling (though as you say Partha didn't actually give a reason).  If someone is building an access-the-PSTN app (and they will), they can use or build a lib to do so - though I'll also mention these fully-functional JS SIP/etc libraries we presume don't exist yet and are a lot of work to write and debug.  A Skype can do so easily; a small PBX add-on company using Asterisk not so much.

Here we disagree on 3 fronts :
1) whilst people will do access-the-PSTN apps they will be wasting their time (IMHO) The growth/interesting area in RTC is not PSTN interconnect.
I made the mistake of betting the farm on PSTN interconnect being the dominant use of an in browser audio component. I was wrong - people used 
the component for  collaboration, dating, games etc - but hardly at all for PSTN. Look at vivox, skype and the rest - PSTN access is a small and shrinking use case. We should not let it sway us unduly.

2) Phono's javascript exists and is open source - it  works and is based on xmpp. 
https://github.com/phono/PhonoSDK/tree/master/modules/phono-js/src/main
I'm not claiming that it solves _every_ problem, that it has the ideal abstraction,  
or that it is compatible with the yet unwritten RTCweb spec, but it does serve 
as a proof by example.

3) the moment RTCweb settles, the asterisk, freeswitch, YATE etc communities will write a native channel drivers for it. Those platforms
have built in http servers, channel independent RTP modules and protocol independent frameworks that can be leveraged to
ease the pain of supporting a new protocol.
I've investigated doing one for Asterisk SCF - it looks like a couple of weeks work. Minimal JS needed and certainly no sip.js 

> 
> I have a different argument: I want it to be *easy* for a website author/app developer to add audio or video for their users.   The developers aren't experts on glare, forking, the intricacies of getting offer-answer (or whatever) right, ad nauseum.  If you ask them to *design* their own protocol, they'll make a ton of 'rookie' mistakes.  And for added fun, they'll likely never correct them and in many cases never understand why the bug is occasionally reported by their users.
> 
> A random example is forking - forking will happen (forward call to all the devices the person logged in under) , and handling forking well requires some thought and experience.

But that thought and experience are (I'd argue) irrelevant, or at least need a deep review because it isn't the same problem as we
solved last time. Worse, we are only guessing what the problem is. Who says that the forking problem even exists if you let go of the 
device/call/line centric PSTN model - I'm not convinced.

> 
> The obvious answer is "those people shouldn't design a protocol (leave that to the big guys), they should use a standard library."  Ok, great, but:
> 

(see phono)

> 2) The quality and testing of these libraries is unlikely to equal that of existing signalling stacks available freely for quite a while

True, but you may be underestimating the difficulty of taking an existing native SIP/IAX/XXX stack and adding it safely to a browser framework.
 Browsers have strict threading and memory requirements (especially when it comes to access to the DOM/JS) 
- and that's without event starting on the security issues. 
By minimizing the native code and maximizing the javascript  we put more of the code on the 'already sandboxed' side of the fence.
Also I doubt that the browser makers will all go for the same pre-existing-native stack, for license reasons if no other. Then you are faced
with the usual interop problems between 4 different  stacks implementing different subsets of a standard.

> 3) Inaki's (sorry about the cedilla) point about "website-based libraries can be updated more often than ones baked into a browser" is valid, but it has a flip-side - the swarm of smaller users of webrtc are likely to download a version of jSIP.js (or whatever) and are not likely to actively track updates.  My understanding is that this is rife in the use of things like jquery - upgrading is time-consuming and risks breakage, and requires QA.  People grab one version and never change it - while Firefox for example updates every 6 weeks.  (He may have a better argument with IE users, especially in business, but my point still holds.)  The larger, sophisticated users are more likely to update, or debug problems when they occur, so I'm not worried about them - and they can use jSIP.js regardless if there's a signalling protocol in the browser.

(following your example, which I don't wholly subscribe to for reasons mentioned above)

The users won't exactly 'download' jSIP.js - the web services they use will include it. 
The site's web developers will reference a version that works with the version of asterisk (say) that they have 
installed on their server. The last thing they want is the browser to go spontaneously fixing protocol implementation bugs when
they have carefully patched the asterisk to cover up the problem.

> 
> Point 3 is in ways the strongest point here, since I assume these libraries will exist at some point.
> 
> You'll note I'm not arguing for SIP here - I'm arguing that there are valid reasons for easy default signalling *as and option*, especially for the health of the "little guy" app/service developer who wants to add RT media.  If we had a functional, debugged, standard JS protocol that was free and we could figure a way for app developers to ease the update process, it would undercut my argument - but we don't have that, and we can't count on that, at least not for a while.  It does not *have* to be any existing signalling standard - though using one of those is probably easiest, quickest (if the wars over whether/what subside) and least error-prone.

And I fear that it opens a different, more opaque, can of worms by encouraging these little-guys to adopt SIP/SER/asterisk just 
to get in-game push-to-talk.

> Yes, this is critical.  We need to finish it.  I'd rather have it finished and a strong project to build a "standard" external JS library under way than to have the whole thing wait.  But if I had my druthers (what the bleep are those, anyways?) I'd have an optional signalling protocol available.

I have no problem with an optional signalling library, I just rather it to be a javascript example not a baked in native default.

Tim.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Oct 2011 11:19:22 -0700

[BA]  I think this is the main point.   If we finish RTCWEB 1.0 expeditiously, this will in all likelihood
spawn a number of browser-independent signaling libraries, as well as developing a wealth of experience
with the limitations of RFCWEB 1.0, to inform future efforts. 

The alternative is to "load up the camel" until it collapses under the weight of (largely irrelevant) use
cases.  Since the realtime web has been around for over a decade, we have a pretty good idea of what
native realtime capabilities would be used for -- and PSTN connectivity has never been high on the list.

> (what the bleep are those, anyways?) I'd have an optional signaling 
> protocol available.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 4 Oct 2011 16:56:18 -0600

> native realtime capabilities would be used for -- and PSTN connectivity has never been high on the list.

So uh, you are right we have a lot of experience with real time communications on the internet. Things that come to mind over the last ten years include Microsoft Voice.NET, Vonage, Dialpad, Telio, CBeyond, Skype, Yahoo Messenger, Fring, Google Voice, Webex. That's not a systematic sample but just some random things that came to my mind. Oddly, they all seem to connect with the PSTN. What are the things you are thinking of that decided that PSTN connectivity was not high on the list? Perhaps we can look at which ones ended up being successful.

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 04 Oct 2011 19:45:03 -0700

On 10/4/2011 3:56 PM, Cullen Jennings wrote:
> What are the things you are thinking of that decided that PSTN 
> connectivity was not high on the list? Perhaps we can look at which 
> ones ended up being successful.

The first one that comes to mind is TeamSpeak.

Oh, and Xbox Live VoIP.

Neither has PSTN connectivity and I think both fall into the "ended up 
being successful" camp.

Matthew Kaufman

---

From: Randell Jesup <[email-masked]>
Date: Wed, 05 Oct 2011 00:06:16 -0400

On 10/4/2011 2:19 PM, Bernard Aboba wrote:
> [BA] I think this is the main point. If we finish RTCWEB 1.0
> expeditiously, this will in all likelihood

Well, I'd say that's mildly debatable - VoIP companies chew a lot of 
bandwidth on the net, and it's almost all going to the PSTN - though 
it's not in browsers generally.  Skype completes a lot of on-net calls - 
but they make a lot of money (almost all?) from PSTN calls.

That said, I don't consider the Skypes of the world a problem here - 
they can and will roll their own.  Same for PBX vendors I suppose, 
though they'll try to leverage more existing examples.

I think there will be a lot of small-to-medium users adding chat, 
building games, etc, who care little or not at all about the PSTN. 
Those are the ones who I worry about; they wouldn't realize there are 
issues with glare (totally ignoring PSTN) or that forking can be 
complex.  They want a simple, one-stop-shopping solution for adding 
voice/video/data to their sites and games, etc.

Yes, people will build JS apps to provide that.  I'm worried about the 
quality of those apps, and that the likely model will be the author 
downloads a random version when they develop their service, and they 
never update it.  This is a real problem; it is a real problem today 
with other JS modules.

Does this mean we *have* to bake in some sort of signalling?  No, it 
doesn't.  It is an _argument_ for providing some type of signalling as a 
baseline default; or if not, then for starting a project to provide that.

Note that I said "baseline".  I did *not* say "can handle all the 
intricacies of the PSTN well".  It could be something far simpler than
SIP or XMPP, etc, or it could be a very dumbed-down version of one. 
These small users (as noted) need something to provide the basics, and 
to handle certain complexities that simply arise from normal usage 
patterns and features (like forking).  Being able to access the PSTN at 
all using this would be a plus - but it would not be critical in my mind.

And, as I mentioned, it could be external JS - but then it has be more 
solid to start with.  For these simple uses - say chat with other users 
on someones special-interest website, 2 and multiplayer gaming, etc - we 
should try to pull together the minimum things any app/service developer 
would need to be prepared for.  I think any service that allows someone 
to log in from multiple devices has to handle forking in some manner. 
Glare is always possible.  What else?  I'd like to see simple 
conferencing.  Perhaps the minimum is simple enough that it makes more 
sense to develop a new, very simple signalling JS module, and use it in 
examples. This would limit the downside from not updating.

The advantage of basing it on something known is that the basics of all 
these protocols are well-understood.

I'll paraphrase Harald (and many others in other contexts): make simple 
things simple, make complex things possible.

-- 
Randell Jesup
[email-masked]

---

From: Matthew Kaufman <[email-masked]>
Date: Tue, 04 Oct 2011 21:30:37 -0700

On 10/4/2011 9:06 PM, Randell Jesup wrote:
> it's not in browsers generally.  Skype completes a lot of on-net calls 
> - but they make a lot of money (almost all?) from PSTN calls.
>

Ok, so they don't know there's issues with glare or that forking is 
hard. Does that mean that we solve forking in the browser?

> never update it.  This is a real problem; it is a real problem today 

It can also be really simple JS modules and most of the complexity up at 
the server.

Or even more likely (see all the various mashups of the world already), 
simple JS modules and most of the complexity at a third party server 
that you use via its REST APIs.

> doesn't.  It is an _argument_ for providing some type of signalling as 
> a baseline default; or if not, then for starting a project to provide 
> that.
>
> intricacies of the PSTN well".

So does "baseline" include handling the fact that "forking is hard", or 
does baseline not address forking either?

> It could be something far simpler than
> patterns and features (like forking).  Being able to access the PSTN 
> at all using this would be a plus - but it would not be critical in my 
> mind.

This still doesn't mean that the browser needs to become a SIP phone, 
any more than it needed a map rendering engine for Google Maps to exist 
or an IMAP client for Gmail to exist.

> solid to start with.  For these simple uses - say chat with other 
> users on someones special-interest website, 2 and multiplayer gaming, 
> etc - we should try to pull together the minimum things any 
> app/service developer would need to be prepared for.  I think any 
> service that allows someone to log in from multiple devices has to 
> handle forking in some manner. Glare is always possible.  What else?  
> I'd like to see simple conferencing.  Perhaps the minimum is simple 
> enough that it makes more sense to develop a new, very simple 
> signalling JS module, and use it in examples. This would limit the 
> downside from not updating.

Or create a good *platform* for building RTC apps and let the developers 
build things you've never imagined. I think that's a far better outcome 
than building a SIP phone into the browser and then discovering that 
most people don't want to just make phone calls.

>
> The advantage of basing it on something known is that the basics of 
> all these protocols are well-understood.
>
> I'll paraphrase Harald (and many others in other contexts): make 
> simple things simple, make complex things possible.

The latter is far more important than the former. If making simple 
things simple makes complex things significantly harder or impossible, 
you're not building a platform for innovation.

Matthew Kaufman

---

From: Randell Jesup <[email-masked]>
Date: Wed, 05 Oct 2011 01:01:15 -0400

> does baseline not address forking either?

If you want me to answer that question: yes, I'd include support for 
some sort of resolution of forking.  Enough to avoid getting into 
trouble, only.

> or an IMAP client for Gmail to exist.

I am in *no way* saying it needs to be a SIP phone.  I'm saying "provide 
a simple-to-use basic signalling method which it totally optional to 
use, and which handles the basics needed of almost any signalling method 
(forking, glare, etc)".  Nothing about phones, nothing about PSTN.

We also don't ship browsers that consist of a canvas element and a JS 
interpreter, though you *could* build all websites that way (more or 
less), and some do (GMail and the like aren't far from it).  But most 
site authors are glad they don't have to start with a bucket of rocks to 
build a castle *as their only option*.

>> on someones special-interest website, 2 and multiplayer gaming, etc -
>> we should try to pull together the minimum things any app/service
>> developer would need to be prepared for. I think any service that
>> allows someone to log in from multiple devices has to handle forking
>> in some manner. Glare is always possible. What else? I'd like to see
>> simple conferencing. Perhaps the minimum is simple enough that it
>> makes more sense to develop a new, very simple signalling JS module,
>> and use it in examples. This would limit the downside from not updating.
>

Again: I'm not suggesting "build in a SIP phone", and how does my 
proposal in any way tie the hands of someone who wants to build it 
themselves?

> you're not building a platform for innovation.

Ok, but in this case I don't want to complicate the later - so you're 
addressing a point I'm not making.  Please consider re-reading my 
posting with that in mind.

-- 
Randell Jesup
[email-masked]

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 5 Oct 2011 08:26:12 -0700

On Oct 4, 2011 10:05 PM, "Randell Jesup" <[email-masked]> wrote:
> If you want me to answer that question: yes, I'd include support for some
sort of resolution of forking.  Enough to avoid getting into trouble, only.
> I am in *no way* saying it needs to be a SIP phone.  I'm saying "provide a
simple-to-use basic signalling method which it totally optional to use, and
which handles the basics needed of almost any signalling method (forking,
glare, etc)".  Nothing about phones, nothing about PSTN.
> We also don't ship browsers that consist of a canvas element and a JS
interpreter, though you *could* build all websites that way (more or less),
and some do (GMail and the like aren't far from it).  But most site authors
are glad they don't have to start with a bucket of rocks to build a castle
*as their only option*.

I agree with Randal here. Let's make simple things simple, which does not
preclude making advanced and novel things possible.

Cb
> Again: I'm not suggesting "build in a SIP phone", and how does my proposal
in any way tie the hands of someone who wants to build it themselves?
> Ok, but in this case I don't want to complicate the later - so you're
addressing a point I'm not making.  Please consider re-reading my posting
with that in mind.
>
>
> --
> Randell Jesup
> [email-masked]
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 5 Oct 2011 23:16:28 +0530

Hi Randell/Tim,

Please read inline.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Randell Jesup
>Sent: Tuesday, October 04, 2011 8:13 PM
>To: [email-masked]
>> only one web server in such a diagram. Federated services will only
be
>the minority case.
<partha> Agreed for the federated services. I will add another diagram
with single server in the next revision </partha>

>> The illusion is that there are lots of SIP devices that users are
>itching to call from their browsers. There aren't.
>

<partha> It is not my argument. In case some of the draft sounds so,
Please point it out and I will change </partha>

>debug.  A Skype can do so easily; a small PBX add-on company using

<partha> Agreed </partha>

>never understand why the bug is occasionally reported by their users.

<partha> Under Sec 4, first bullet convey the same above point. In case
the bullet text is not clear, Please let me know. </partha>

>that to the big guys), they should use a standard library." 

<partha> It is the important point. </partha>

 Ok, great,
>but:
>add RT media.

<partha> My argument is also not for SIP. </partha>

  If we had a functional, debugged, standard JS protocol
>> The risk of such a discussion (of a standard signalling protocol) is
>that we will still be discussing it in 3 years time and each of the
>browser makers will have implemented their own subtly different webRTC
>solutions.
>

<partha> I agree with you. I listed some of the existing signaling
protocol for the same reason which shall be integrated quickly. Most of
the existing signaling protocol is stable by now because of the usage in
other applications. </partha>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 5 Oct 2011 23:19:19 +0530

Hi Jim,

For the given RTCWeb basic communication, if some other better signaling
protocol exists, we will adopt for it. 

Thanks
Partha

Behalf
>Of Jim McEachern
>Sent: Tuesday, October 04, 2011 9:29 PM
>To: Randell Jesup; [email-masked]
>Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE:About
>> developers aren't experts on glare, forking, the intricacies of
>> getting offer- answer (or whatever) right, ad nauseum.  If you ask
>> them to
>The problem with this argument is that it involves complex
functionality
>that would not be covered by basic SIP in the browser.
>Are you proposing that the full SIP stack, with support for forking,
>early media, etc. be built into all browsers?  If yes, then we are
>already at the bottom of the "slippery slope" that people fear.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 5 Oct 2011 14:27:37 -0400

Making things simple/accessible to a wide range of programmers is a good
idea but then does this mean that a signaling protocol (even a simple
one) should be baked in the browser? For example, if I have a webserver
allowing people to play Battleships and want to add voice support for
players, why do I need to use SIP (or something as complex as it)? What
I am interested in would be limited to two-party simple voice
communication (no forking, no renegotiation, no early media, no reliable
responses etc....). A simple signaling protocol between JS and WebServer
should be good enough AFAICS. There could be some JS libraries built for
this purpose and one can use whichever one prefers (or develop its own).
Arguing about potential issues with a JS SIP library in the context of
simple use cases does not sound fair to me for this reason. The
requirement of simplicity for the no-signaling-protocol-in the-browser
approach would be: Keep the API exposing media related
information/attributes as simple as possible (but no simpler).

One could argue that the definition of "simple" includes things I
excluded above, e.g. forking. To me, simple means things similar to the
use case above but I doubt there is consensus on that.

Thanks,

Tolga

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Cameron Byrne
Sent: Wednesday, October 05, 2011 11:26 AM
To: Randell Jesup
Cc: [email-masked]
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About
defining a signaling protocol for WebRTC (or not)]

>>> patterns and features (like forking). Being able to access the PSTN
at
> I am in *no way* saying it needs to be a SIP phone.  I'm saying
"provide a simple-to-use basic signalling method which it totally
optional to use, and which handles the basics needed of almost any
signalling method (forking, glare, etc)".  Nothing about phones, nothing
about PSTN.

I agree with Randal here. Let's make simple things simple, which does
not preclude making advanced and novel things possible.

Cb
>>> solid to start with. For these simple uses - say chat with other
users

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Sat, 8 Oct 2011 11:09:03 +0200

> protocol exists, we will adopt for it. 

And who will judge if protocol X is "better" than protocol Y? In what context? Under what assumptions? I don't this this is the right direction.

-- 
Saúl Ibarra Corretgé
AG Projects