Subject: [rtcweb] Review request for RTCWeb standard signaling protocol

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

Hi all,

RTCWeb standard signaling protocol (http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00) draft list the need for standard signaling protocol between RTCWeb client (browser) and RTCWeb server and the possible signaling protocol for the same. This draft is written based on http://www.ietf.org/mail-archive/web/rtcweb/current/msg01172.html mail thread discussion. Could you please provide your valuable comments.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 03, 2011 7:56 PM
To: Ravindran Parthasarathi
Cc: Ravindran Parthasarathi
Subject: New Version Notification for draft-partha-rtcweb-signaling-00.txt

A new version of I-D, draft-partha-rtcweb-signaling-00.txt has been successfully submitted by Parthasarathi Ravindran and posted to the IETF repository.

Filename:	 draft-partha-rtcweb-signaling
Revision:	 00
Title:		 RTCWeb standard signaling protocol
Creation date:	 2011-10-03
WG ID:		 Individual Submission
Number of pages: 8

Abstract:
   The standardization of Real time communication between browsers is to
   provide the infrastructure for audio, video, text communication using
   standard interface so that interoperable communication can be
   established between any compatible browsers.  RTCWeb specific
   Javascript API will be provided by browsers for developing real-time
   web application.  It is possible to develop signaling protocol like
   Session Initiation Protocol (SIP) or Jingle or websocket extension or
   custom-made signaling protocol in Javascript.  There are lots of
   issues in Javascript based signaling protocol.  This document list
   the need for standard signaling protocol between RTCWeb client
   (browser) and RTCWeb server and possible signaling protocol for the
   same.

The IETF Secretariat

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 3 Oct 2011 17:37:03 +0200

> RTCWeb standard signaling protocol (http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00) draft list the need for standard signaling protocol between RTCWeb client (browser) and RTCWeb serve…

Hi Ravindran,

The draft just talks about supposed advantages of using a
"default/standard" signaling protocol for WebRTC, and clearly ignores
all the disadvantages that people in this list has explained in
several threads. So I must repeat them:

1) If the browsers speak *native* SIP (or any other protocol) then the
web server is unaware of what is happening at media level between the
visitors (because the web server, where the application logic is, does
not see the signaling traffic). It would be possible just in case the
signaling protocol is HTTP or WebSocket.

2) By forcing a specific signaling protocol between rtcweb client and
server, you force the existence of ugly signaling gateways (rtcweb to
SIP/XMPP). Your draft shows it as an advantage:

   o  Gateway for RTCWeb server and legacy signaling protocol is easy in
      case standard RTCweb signaling protocol is used.

Easy??? that should be a joke. Doing protocol conversion/gateway
always means loss of features. If not, take any current
JSON-AJAX-based "web softphone" in which there is a conversion from
the custom (always custom!!!) JSON protocol to SIP protocol in a
"special" gateway, and let me know which one allows "exotic" features
like parallel forking or call transfer.

Please, don't mandate a gateway for signalling protocol, please. I
*do* know that SIP and XMPP can be ***fully*** implemented in
JavaScript by using websocket as transport protocol and a SIP/XMPP
proxy/server that also implements SIP/XMPP over WebSocket (this is not
protocol gateway!! this is ***pure*** SIP/XMPP).

In the other side, I think you don't fully understand how WWW world
works for years. Your draft talks about some "issues" (which IMHO are
not issues at all), comments in line:

> 3.  Issues without RTCWeb standard signaling protocol
>
>   The issues in creating non standard RTCWeb sigaling protocol are
>
>   o  Without RTCWeb standard signaling protocol, each website developer
>      has to understand the complication of signaling protocol for
>     making the real-time communication.

For sure there will appear signalling libraries, some of them GPL some
others not. WWW is a jungle, trying to mandate something never works.
And I don't want to be limited by the basic features that your "RTCWeb
standard signaling protocol" would provide.

>   o  Downloading the complete RTCWeb signaling protocol Javascript is
>      inefficient as it impact performance and setup delay of real-time
>      communication.  The caching of Javascript shall avoid downloading
>      the signaling protocol in each time RTCWeb server is accessed.
>      But the Javascript cache is possible to be removed often which
>      leads to the impact.

Ok, let me say something similar:

      Downloading the complete Gmail Javascript is
      inefficient as it impact performance and setup delay of real-time
      communication. So we need to create a "standard webmail protocol"
      so Gmail, Hotmail, Yahoo and all the webmail providers would use
      them and all the browsers would natively implement it.

>   o  Also, browser has to download each website signaling protocol
>      indepentely

Same as above. When you visit Gmail you download the complete JS code
from Gmail. If later you visit Hotmail you download the complete JS
code from Hotmail. That's how WWW works. Welcome.

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

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 4 Oct 2011 00:40:54 +0530

Inaki,

<snip>
" The draft just talks about supposed advantages of using a "default/standard" signaling protocol for WebRTC"
</snip>
I'm happy to hear from you that RTCWeb standard signaling protocol has some advantages. 

I thought that at least you will understand my point after looking at the draft but does not seems to be. Please note that RTCWeb standard signaling protocol is not against having proprietary protocol and I have explained in Sec 4 of the draft as 

"  The defining signaling protocol is not a hindrance for any innovative
   RTCWeb signaling protocol development as it is complementary
   solution."

I could not understand some of your argument, Please read inline for details.

Thanks
Partha

>From: Iñaki Baz Castillo [mailto:[email-masked]]
>Sent: Monday, October 03, 2011 9:07 PM
>Cc: [email-masked]
>Subject: Re: [rtcweb] Review request for RTCWeb standard signaling
>protocol
>
>> RTCWeb standard signaling protocol (http://tools.ietf.org/html/draft-
>partha-rtcweb-signaling-00) draft list the need for standard signaling
>protocol between RTCWeb client (browser) and RTCWeb server and the
>possible signaling protocol for the same. This draft is written based on
>http://www.ietf.org/mail-archive/web/rtcweb/current/msg01172.html mail
>thread discussion. Could you please provide your valuable comments.
>
>Hi Ravindran,
>

<partha> I guess that you propose to have websocket or HTTP based signaling protocol and not preferring SIP. I'm ok to have any one of the standard signaling protocol and not. So, we have no disagreement at this level for the draft. </partha>

>SIP/XMPP). 

<partha> In case you have any solution (other than SIP) in RTCWeb with any signaling gateway, let us discuss. Please don’t mentioned your websocket tunneling SIP as a solution. Even in your proposed mechanism, gateway (B2BUA) has to remove the websocket transport and forward SIP messages with appropriate changes. ISTM, you are simply arguing </partha>

>like parallel forking or call transfer.

<partha> I meant for "easy" in the comparative sense. Protocol conversion/gateway does not means loss of features and this is based on my experience on gateways which supports multiple protocol namely ISDN, ISUP, SIP, H.323, MGCP, SCCP simultaneously. Websocket or HTTP will be one another addition signaling protocol in those gateway for interop with existing signaling protocol. In case you think that it is cakewalk job then you are wrong. Each protocol mapping will involve some circus during conversion like extra RE-INVITE. 

My comparison is between "your proposal custom made RTCWeb signaling to federated signaling protocol" to "RTCWeb standard signaling protocol to federated signaling protocol". </partha>

>protocol gateway!! this is ***pure*** SIP/XMPP).

<partha> Please note that RTCWeb server in your implementation has to acts as gateway to remove websocket tunnel. Gateway includes B2BUA with different transport. And also, your argument is not related to my draft </partha>

>others not. 

<partha> GPL or not is one of the issue with 3rd party signaling libraries </partha>

WWW is a jungle, trying to mandate something never works.

<partha> I believe that RTCweb mandating (media, security) works for WWW jungle. </partha>

>standard signaling protocol" would provide.

<partha> Of course, the limited feature "RTCWeb standard signaling protocol" is not for power user like you and also it does not hinder any of your activity. But I'm fail to understand your argument for not having standard signaling protocol </partha>

>code from Hotmail. That's how WWW works. Welcome.

<partha> There is no comparison between non-real time protocol and real-time protocol. I agree that non-real time WWW works in this fashion which is not appropriate for real-time application. Also, please note that number of e-mail provider to real-time application will be very different. Say I'll provide RTCWeb application in my personal website for communicating with me in my mobile.  </partha>

---

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

> I'm happy to hear from you that RTCWeb standard signaling protocol has some advantages.

Hi Ravindran. I've never said that. I just said that your draft "talks
about *supposed* advantages. More inline.

>   RTCWeb signaling protocol development as it is complementary

I will comment about this at the end of this mail.

> <partha> I guess that you propose to have websocket or HTTP based signaling protocol and not preferring SIP. I'm ok to have any one of the standard signaling protocol and not. So, we have no disagr…

Not exactly. I propose nothing. I don't propose a "default signaling
protocol" at all (reasons in the rest of the mail).

> <partha> In case you have any solution (other than SIP) in RTCWeb with any signaling gateway, let us discuss. Please don’t mentioned your websocket tunneling SIP as a solution. Even in your propose…

First of all, WebSocket is a *transport* protocol, rather than an
application protocol as you suggest in different comments. The
separation between a transport protocol and an application protocol is
just logical: A transport protocol carries messages of an application
protocol.

WebSocket by itself is just nothing. The developer must use or create
a WebSocket subprotocol by defining messages to be send via the
WebSocket connection, and such protocol is coded in JavaScript!. So
WebSocket is a transport protocol as UDP or TCP. Or would you consider
UDP over TCP as an application protocol?

> <partha> I meant for "easy" in the comparative sense. Protocol conversion/gateway does not means loss of features and this is based on my experience on gateways which supports multiple protocol namely ISDN, ISUP, SIP, H.323, MGCP, SCCP simultaneously. Websocket or HTTP will be one another addition signaling protocol

Again: WebSocket is not a signaling protocol. IMHO you should take a
look to http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17.

> in those gateway for interop with existing signaling protocol. In case you think that it is cakewalk job then you are wrong. Each protocol mapping will involve some circus during conversion like extra RE-INVITE.

I just think that the best way to interoperate with protocol A is by
using protocol A, rather than using protocol B and a gateway A/B.

> <partha> Please note that RTCWeb server in your implementation has to acts as gateway to remove websocket tunnel. Gateway includes B2BUA with different transport.

I've already explained that WebSocket must be considered a transport
protocol, so a SIP proxy implementing SIP over WebSocket *transport*
is not a B2BUA. It's the same concept as a common SIP proxy
implementing UDP and TCP, and allowing a request to come via UDP and
leave the proxy via TCP. I've just added a new transport: WebSocket.
That changes nothing from the point of view of what a SIP proxy is
supposed to do. It's not a B2BUA.

> And also, your argument is not related to my draft </partha>

IMHO it's related as your draft assumes the need for a gateway
performing application gateway.

> <partha> I believe that RTCweb mandating (media, security) works for WWW jungle. </partha>

Yes, but you are trying to mandate something that is unnecessary,
since what you propose can already be done by custom JavaScript. About
your text:

 "The defining signaling protocol is not a hindrance for any innovative
  RTCWeb signaling protocol development as it is complementary
  solution."

It does not convince me since in other mails you have suggested that
WebRTC should just allow communication between browsers.

> <partha> Of course, the limited feature "RTCWeb standard signaling protocol" is not for power user like you and also it does not hinder any of your activity. But I'm fail to understand your argumen…

Having a standard signaling protocol meanst that browsers must
natively implement it, and I think that's unnecessary. In the same way
you could expect that something like jQuery should be part of the
JavaScript stack in browsers, but it is not, and *lot* of people uses
jQuery, and they can use a newer version of jQuery when it's available
without having to wait for a new version of *every* webbrowsers. The
web developer just needs to include the desired jQuery version in its
web application and it's done. If jQuery would be part of the JS
stack, then a web developer would never know wheter their clients use
a browser that implements jQuery version X or Y. That stops
innovation, and the very same for a "default rtcweb signaling
protocol".

> <partha> There is no comparison between non-real time protocol and real-time protocol. I agree that non-real time WWW works in this fashion which is not appropriate for real-time application. Also,…

Open Gmail, open ebuddy.com, open Facebook, open any web page in which
there is a *realtime* chat, and voilá, you get a realtime protocol.
Fortunately all these apps could use WebSocket soon rather than
dealing with ugly HTTP long polling or HTTP Comet. In all those cases,
the realtime protocol is implemented using a custom JavaScript code
that the browser MUST download. The same when WebSocket arrives since
WebSocket is just a transport protocol and it requires custom
JavaScript code implementing a real protocol on top of it.

Now a suggestion: instead of trying to propose a default rtcweb
signaling protocol built-in the web browser, why don't you create a
signaling protocol on top of WebSocket (for example using JSON
messages exchange) and publish it? If for example such protocol or
implementation has a bug, you can fix it by publishing a new version,
and the web developers will just need to provide the new JavaScript
file, rather than having to wait for *all* the web browsers in the
world to fix the bug and *all* the humans in the world to upgrade
their web browsers. Wouldn't that stop innovation??

Regards.

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

---

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

Hi,

Here are some comments after the first read:

"There are lots of
   issues in Javascript based signaling protocol."

What issues? Do you have an implementation to sustain that statement?

"Architecture"

I guess you noticed that  the architecture graph in your draft is exactly the SIP trapezoid. But we can't make everyone happy, XMPP guys will want to use XMPP and SIP guys will want to use SIP, there is no need to force people to use either, or any other.

"Without RTCWeb standard signaling protocol, each website developer
      has to understand the complication of signaling protocol for
      making the real-time communication."

With libraries like jQuery one doesn't need to know about xmlhttprequest anymore, so I'd say the same would be true for any signaling sibrary developed by a thirst party. It could expose a simple API for other developers to use, but of course, the one building the library itself *has* to know about the protocol.

"Also, browser has to download each website signaling protocol
      indepentely"

Of course, same as with any other JS library or plugin. Why do you see a difference between the signaling protocol for RTCweb and everything else?

Overall, I didn't see any key points for the need of a default signaling protocol. I wouldn't agree with it even if you advocated for SIP, this should be up to the developer.

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 04 Oct 2011 10:21:54 +0200

Ravindran,

the core part of your document seems to me to be this list:

    The following Signaling protocols will qualify for becoming standard
    RTCWeb signaling protocol

    1.  Jingle
    2.  Websocket with SDP offer/answer
    3.  SIP
    4.  SIPLite [I-D.cbran-rtcweb-protocols  <http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00#ref-I-D.cbran-rtcweb-protocols>]
    5.  Websocket with custom XML
    6.  Megaco [RFC5125  <http://tools.ietf.org/html/rfc5125>]
    7.  Websocket with SIP [I-D.ibc-rtcweb-sip-websocket  <http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00#ref-I-D.ibc-rtcweb-sip-websocket>]
    8.  HTTP with custom XML
    9.  ???

    TBD: Pros and cons for each of the signaling mechanism has to be
    added

My reading of your document is that you want the RTCWEB working group to 
pick exactly one of these alternatives, and insist that all conformant 
implementations of RTCWEB support this protocol.

I disagree with:

a) that this is needed
b) that this is a good idea

The reasons why it is not a good idea have been raised multiple times, 
and spending continued effort on trying to debate which of the 
alternatives you list above is "the best one" is distracting to our 
purpose of getting the RTCWEB protocol suite done.

I do not support pursuing your suggested direction of work in this 
working group.

                      Harald

On 10/03/2011 04:41 PM, Ravindran Parthasarathi wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Oct 2011 09:38:27 -0700

Agree with Harald on this.   Debating which alternative is "the best" is a distraction.  One of the major advantages of RTCWEB is the flexibility it provides with respect to signaling.  

Date: Tue, 4 Oct 2011 10:21:54 +0200
From: [email-masked]
To: [email-masked]
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol

    

    Ravindran,

   1.  Jingle
   2.  Websocket with SDP offer/answer
   3.  SIP
   4.  SIPLite [I-D.cbran-rtcweb-protocols]
   5.  Websocket with custom XML
   6.  Megaco [RFC5125]
   7.  Websocket with SIP [I-D.ibc-rtcweb-sip-websocket]
   8.  HTTP with custom XML
   9.  ???

    My reading of your document is that you want the RTCWEB working
    group to pick exactly one of these alternatives, and insist that all
    conformant implementations of RTCWEB support this protocol.

    I disagree with:

    a) that this is needed

    The reasons why it is not a good idea have been raised multiple
    times, and spending continued effort on trying to debate which of
    the alternatives you list above is "the best one" is distracting to
    our purpose of getting the RTCWEB protocol suite done.

                         Harald

    

      Hi all,

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 03, 2011 7:56 PM
To: Ravindran Parthasarathi
Cc: Ravindran Parthasarathi
Subject: New Version Notification for draft-partha-rtcweb-signaling-00.txt

Abstract:

The IETF Secretariat

---

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

Hi Harald, 

Sec 3 & 4 of the draft deals with the need and advantages for standard
signaling protocol. I understand your major concern is time. I think
through and provided some solution as part of the draft

1)      Sec 5:  (RTCWeb Protocol requirement and design consideration)
is added to come up with the thump rules for standard signaling rather
than discussion different protocol

2)      Sec 6:  The list of existing signaling protocol is shown for
eliminating the signaling protocol based on Sec 5 conclusion

In case time factor to solve this issue is the reason for rejecting this
proposal , let us work for the better way to reduce the timeframe to
achieve the result. 

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Harald Alvestrand
Sent: Tuesday, October 04, 2011 1:52 PM
To: [email-masked]
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling
protocol

Ravindran,

 
   1.  Jingle
   2.  Websocket with SDP offer/answer
   3.  SIP
   4.  SIPLite [I-D.cbran-rtcweb-protocols
<http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00#ref-I-D.cbr
an-rtcweb-protocols> ]
   5.  Websocket with custom XML
   6.  Megaco [RFC5125 <http://tools.ietf.org/html/rfc5125> ]
   7.  Websocket with SIP [I-D.ibc-rtcweb-sip-websocket
<http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00#ref-I-D.ibc
-rtcweb-sip-websocket> ]
   8.  HTTP with custom XML
   9.  ???

I disagree with:

a) that this is needed

                     Harald

Hi all,
 
RTCWeb standard signaling protocol
(http://tools.ietf.org/html/draft-partha-rtcweb-signaling-00) draft list
the need for standard signaling protocol between RTCWeb client (browser)
and RTCWeb server and the possible signaling protocol for the same. This
draft is written based on
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01172.html mail
thread discussion. Could you please provide your valuable comments.
 
Thanks
Partha
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 03, 2011 7:56 PM
To: Ravindran Parthasarathi
Cc: Ravindran Parthasarathi
Subject: New Version Notification for
draft-partha-rtcweb-signaling-00.txt
 
A new version of I-D, draft-partha-rtcweb-signaling-00.txt has been
successfully submitted by Parthasarathi Ravindran and posted to the IETF
repository.

Abstract:

 
The IETF Secretariat

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 7 Oct 2011 03:49:26 +0200

2011/10/5 Ravindran Parthasarathi <[email-masked]>:
> signaling protocol.

No

>I understand your major concern is time.

No, it's the proposal itself. Just you want it.

> I think through
> and provided some solution as part of the draft

The solution is forgetting your wrong idea and stop ignoring replyins
and rationale given to your *insistent* proposal.

> 1)      Sec 5:  (RTCWeb Protocol requirement and design consideration) is
> added to come up with the thump rules for standard signaling rather than
> discussion different protocol

And it's wrong (I will not repeat the arguments again).

> eliminating the signaling protocol based on Sec 5 conclusion

Yes, let's use MEGACO, or H323, or ISUP.

> proposal , let us work for the better way to reduce the timeframe to achieve
> the result.

That's not the point.

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

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 7 Oct 2011 11:35:53 +0530

Inaki,

I understand that you don't want any signaling protocol for RTCWeb  to be standardized. I'm strong believer of "something is better than nothing". Also, My standard signaling protocol proposal is never a hindrance to your innovative custom-build signaling protocol (SIP over websocket) development and the standard signaling protocol is not meant for you in case you are building custom-build signaling protocol. 

From the RTCweb client programmer perspective, there will be an set of API for building custom build signaling and another top level API which is based on proposed standard signaling. I could not understand why are you so against the standardization of the signaling protocol. 

Thanks
Partha  

>Sent: Friday, October 07, 2011 7:19 AM
>Cc: Harald Alvestrand; [email-masked]
>is
>achieve

---

From: Tim Panton <[email-masked]>
Date: Fri, 7 Oct 2011 11:23:41 +0100

> From the RTCweb client programmer perspective, there will be an set of API for building custom build signaling and another top level API which is based on proposed standard signaling. I could not u…

Because it is a distraction. It is unnecessary, the advantages don't outweigh the disadvantages.

It isn't essential to the success of this effort and would slow us down by _years_ debating the details.

Even if we could magically all instantly agree to use (say) RFC 5456 as the standard (*) , it would then immediately impact the 
core effort, the temptation to add features and helper methods to the core media API that suited the 'standard' signalling protocol
would be irresistible. Pretty soon we'd find we had a media layer that could _only_ work well through the standard signalling protocol.

Tim.

(*) In my view no one of the currently available signalling protocols are suitable for this effort. They were all designed with 
a totally different set of constraints to the ones faced by rtcweb. 

T.

---

From: samuel <[email-masked]>
Date: Fri, 7 Oct 2011 12:30:44 +0200

Hi all,

The point Iñaki is pushing forward is crucial, as Tim also stated, because
it will save us the burden of implementing another protocol, the marketing
fight between protocols (do you want another SIP vs. H323 "war"?) Please,
don't reinvent the wheel, keep it simple.

Best regards,

Samuel

On 7 October 2011 12:23, Tim Panton <[email-masked]> wrote:

> > I understand that you don't want any signaling protocol for RTCWeb  to be
> standardized. I'm strong believer of "something is better than nothing".
> Also, My standard signaling protocol proposal is never a hindrance to your
> innovative custom-build signaling protocol (SIP over websocket) development
> and the standard signaling protocol is not meant for you in case you are
> building custom-build signaling protocol.
> >
> > From the RTCweb client programmer perspective, there will be an set of
> API for building custom build signaling and another top level API which is
> based on proposed standard signaling. I could not understand why are you so
> against the standardization of the signaling protocol.
>
> Even if we could magically all instantly agree to use (say) RFC 5456 as the
> standard (*) , it would then immediately impact the
> core effort, the temptation to add features and helper methods to the core
> media API that suited the 'standard' signalling protocol
> would be irresistible. Pretty soon we'd find we had a media layer that
> could _only_ work well through the standard signalling protocol.
>
> Tim.
>
> (*) In my view no one of the currently available signalling protocols are
> suitable for this effort. They were all designed with

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 7 Oct 2011 16:06:22 +0530

Tim,

Your argument is "Time to market" RTCWeb compliance and few folks already mentioned about it and also proposing to develop the new protocol.

At this moment, I don't think that there is a need for developing new signaling protocol for RTCweb. IMO, The argument may be which is best suitable rather than none of the protocol is suitable. 

Sam,

In case your proposal is not to invent new protocol for RTCWeb signaling.  Please look at my draft which is in the same line.

Thanks

Partha

From: samuel [mailto:[email-masked]] 
Sent: Friday, October 07, 2011 4:01 PM
To: Tim Panton
Cc: Ravindran Parthasarathi; [email-masked]
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol

Hi all,

The point Iñaki is pushing forward is crucial, as Tim also stated, because it will save us the burden of implementing another protocol, the marketing fight between protocols (do you want another SIP vs. H323 "war"?) Please, don't reinvent the wheel, keep it simple.

Best regards,

Samuel

Tim.

T.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 7 Oct 2011 12:49:28 +0200

2011/10/7 Ravindran Parthasarathi <[email-masked]>:
> Your argument is "Time to market" RTCWeb compliance and few folks already
> mentioned about it and also proposing to develop the new protocol.

And *lot* of folks already mentioned that your proposal is bad for
WebRTC, but you don't say that. You still continue ignoring arguments
and persons you cannot reply. Tim's argument is not just about "Time
to market". Anyone reading his mail would also read the third
paragraph (which you intentionally ignore now, of course, as you
always do).

> At this moment, I don't think that there is a need for developing new
> signaling protocol for RTCweb. IMO, The argument may be which is best
> suitable rather than none of the protocol is suitable.

Please, don't try to distract this WG for achieving your goals. There
is not, and there will not be, a discussion/debate about which one is
the "best default and *mandatory* signaling protocol".

> In case your proposal is not to invent new protocol for RTCWeb signaling.
> Please look at my draft which is in the same line.

Sure, your draft is just any of your mails copy&pasted into a draft.

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

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 7 Oct 2011 16:21:36 +0530

Let us debate on the RTCWeb signaling meeting

Thanks
Partha

>Sent: Friday, October 07, 2011 4:19 PM
>Cc: samuel; Tim Panton; [email-masked]

---

From: <[email-masked]>
Date: Fri, 7 Oct 2011 11:02:17 +0000

Hi,

Ravindran Parthasarathi
>Let us debate on the RTCWeb signaling meeting

I'd rather hope we could stop spending cycles on this particular debate. My read on the list is that there is pretty strong concensus on that we will *not* pick and standardize a single complete "signaling protocol" (such as SIP or XMPP/Jingle) for RTC-Web. This is of course up to the chairs to determine.

Markus

>>and persons you cannot reply. Tim's argument is not just about "Time to
>>market". Anyone reading his mail would also read the third paragraph
>>(which you intentionally ignore now, of course, as you always do).
>>
>>
>>

---

From: Neil Stratford <[email-masked]>
Date: Fri, 7 Oct 2011 12:16:54 +0100

> suitable rather than none of the protocol is suitable.
In my view the only option for a standardised signalling protocol for RTCweb
*would* be something entirely new that met the specific needs of the
environment.

If we did go down the hypothetical new standard protocol route (which I
really think we shouldn't) my requirements would be:
- No server side infrastructure (SIP proxies etc) to maintain or configure.
- No special understanding in the server side web application beyond
discovering peer identities you might want to communicate with.

Which would lead to something looking like a browser maintained peer to peer
network, at which point we are re-inventing the web, which sounds like
something beyond this group. So I strongly support not picking a default and
instead encourage some innovation at the javascript level.

Neil

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 7 Oct 2011 17:10:33 +0530

Neil,

<snip> 

In my view the only option for a standardised signaling protocol for
RTCweb *would* be something entirely new that met the specific needs of
the environment. 

</snip>

Browser to browser real time communication is no different from other
real-time communication apart from the existing web infrastructure. In
case your argument is to use the existing web infrastructure like
websocket, I agree with you.

But in case it is not the reason, Could you please list the reason for
new signaling protocol requirement . 

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Neil
Stratford
Sent: Friday, October 07, 2011 4:47 PM
To: Ravindran Parthasarathi
Cc: samuel; Tim Panton; [email-masked]
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling
protocol

On Fri, Oct 7, 2011 at 11:36 AM, Ravindran Parthasarathi
<[email-masked]> wrote:

	At this moment, I don't think that there is a need for
developing new signaling protocol for RTCweb. IMO, The argument may be
which is best suitable rather than none of the protocol is suitable.

In my view the only option for a standardised signalling protocol for
RTCweb *would* be something entirely new that met the specific needs of
the environment. 

- No server side infrastructure (SIP proxies etc) to maintain or
configure.

Which would lead to something looking like a browser maintained peer to
peer network, at which point we are re-inventing the web, which sounds
like something beyond this group. So I strongly support not picking a
default and instead encourage some innovation at the javascript level.

Neil

---

From: Neil Stratford <[email-masked]>
Date: Fri, 7 Oct 2011 12:53:51 +0100

On Fri, Oct 7, 2011 at 12:40 PM, Ravindran Parthasarathi <
[email-masked]> wrote:

> real-time communication apart from the existing web infrastructure. In case
> your argument is to use the existing web infrastructure like websocket, I
> agree with you.
>

It is different to traditional RTC - we have a javascript execution engine
intimately tied in to every client. This completely changes the solution
space.

> **
>
> But in case it is not the reason, Could you please list the reason for new
> signaling protocol requirement .
>

I already listed them:

> ****
> **
> ****

My argument is that if we want the ultimate goal of simplicity for end user
web developers then we should minimise everything they have to touch - and
that includes removing any requirement for server side infrastructure beyond
the basic bare minimum, which would mean no SIP proxies, no websocket
servers etc etc.

But as I said, we don't need to standardise a protocol at all, so we
shouldn't. If we are lucky we'll see a whole spectrum of solutions.

Neil

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 7 Oct 2011 14:31:05 +0200

> signaling protocol requirement .

Ravindran, could you please read the entire mails? Neil crearly said
at the end of his mail:

"So I strongly support not picking a default and instead encourage
some innovation at the javascript level."

Do you read the "strongly" word?

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

---

From: Tim Panton <[email-masked]>
Date: Fri, 7 Oct 2011 13:40:28 +0100

If you had the curtesy to actually read what I'd written, you would have seen that I made 3 arguments.

Just to reinforce my point about the un-suitability of existing protocols, I've now worked on 4 web-rtc
like projects, using 4 different pre-existing protocols (XMPP, SIP, IAX2, proprietary),
so I have quite a bit experience on which to base my remarks. They all worked ok in the problem
space we used them in (which is why we selected each of them for their respective projects),
but no one protocol would have done the job for all the projects. 

Premature standardisation is the enemy of innovation - to coin a phrase. 
This isn't a sunset market, it is a new dawn, we should standardize as little as we possibly can.

You can choose not to agree with my opinions, but please don't mis-represent my remarks.

Tim.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 7 Oct 2011 18:50:22 +0000

Neil makes an excellent point which has only been briefly brought up but should be made more explicit: picking a standard signaling protocol for the Browser to implement is only half the problem - the other half of the problem is the Web Server has to implement it too, tie it into a location database, possibly with authentication and authorization policy rules, and whatever else the specific Web application needs.

There is no "20 lines of code" solution once you realize that.  It may be 20 lines of JavaScript, but that's only part of the problem/solution.  In fact, the most likely way to get to 20 lines of code for the Web Server owner is for him/her to use a public JS library for signaling which is paired with a web server module written for that specific JS library.

-hadriel

On Oct 7, 2011, at 7:16 AM, Neil Stratford wrote:

> 
> If we did go down the hypothetical new standard protocol route (which I really think we shouldn't) my requirements would be:
> - No special understanding in the server side web application beyond discovering peer identities you might want to communicate with.
> 
> Which would lead to something looking like a browser maintained peer to peer network, at which point we are re-inventing the web, which sounds like something beyond this group. So I strongly support not picking a default and instead encourage some innovation at the javascript level.
> 
> Neil
>

---

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

On Oct 7, 2011, at 1:53 PM, Neil Stratford wrote:

> On Fri, Oct 7, 2011 at 12:40 PM, Ravindran Parthasarathi <[email-masked]> wrote:
> Browser to browser real time communication is no different from other real-time communication apart from the existing web infrastructure. In case your argument is to use the existing web infrastructure like websocket, I agree with you.
> 
> 
> It is different to traditional RTC - we have a javascript execution engine intimately tied in to every client. This completely changes the solution space.
>  
> 
> But in case it is not the reason, Could you please list the reason for new signaling protocol requirement .
> 
> 
> I already listed them: 
> 
>  
> 

Looks like some zeroconf style thing, it could be an interesting thing to explore. Do you have any ideas on how the discovery would work over the Internet?

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: Neil Stratford <[email-masked]>
Date: Sat, 8 Oct 2011 14:34:12 +0100

On Sat, Oct 8, 2011 at 10:30 AM, Saul Ibarra Corretge
<[email-masked]>wrote:

> Looks like some zeroconf style thing, it could be an interesting thing to
> explore. Do you have any ideas on how the discovery would work over the
> Internet?

I imagine a signalling protocol such as this would look a lot like p2psip,
though there is something interesting about baking a p2p overlay network
into the browser and exposing it through an API that could then be used to
build all kinds of services in javascript, including p2p SIP signalling for
RTC.

The great thing about *not* defining a signalling protocol is that we are
free to experiment with signalling in all kinds of ways.

---

From: Saul Ibarra Corretge <[email-masked]>
Date: Sat, 8 Oct 2011 15:46:13 +0200

On Oct 8, 2011, at 3:34 PM, Neil Stratford wrote:

> On Sat, Oct 8, 2011 at 10:30 AM, Saul Ibarra Corretge <[email-masked]> wrote:
> 
> I imagine a signalling protocol such as this would look a lot like p2psip, though there is something interesting about baking a p2p overlay network into the browser and exposing it through an API that could then be used to build all kinds of services in javascript, including p2p SIP signalling for RTC.
> 
> The great thing about *not* defining a signalling protocol is that we are free to experiment with signalling in all kinds of ways.

I'm all for it :-)

-- 
Saúl Ibarra Corretgé
AG Projects

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 8 Oct 2011 18:37:51 +0200

> free to experiment with signalling in all kinds of ways.

Agreed. Defining a default/mandatory signaling protocol would limit
future scenarios. We don't know yet what RTCweb will be used for.
Signaling should depend on the needs of each service bringing media
capabilities, and that is achieved by providing the signaling within a
custom JavaScript code.

Anyhow I expect I will read again (probably in any other thread) the
same mail speaking about "the need for a default signaling protocol,
as H323 or MEGACO", by ignoring any rationale given in this and other
mails but most of the people in this maillist. I should make some SPAM
filtering rule.

Regards.

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

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 17 Oct 2011 13:15:15 +0530

<snip> My argument is that if we want the ultimate goal of simplicity
for end user web developers then we should minimise everything they have
to touch - and that includes removing any requirement for server side
infrastructure beyond the basic bare minimum, which would mean no SIP
proxies, no websocket servers etc etc.

 </snip>

Without server interaction, it is not possible for browser to establish
the session with other browser. Unlike other endpoint, browser needs
server to provide routing or  perform the authentication or atleast
configuration information. AFAIK, RTCWeb client to RTCWeb client is not
the motive of the work. If so, SIP is the IETF protocol between RTCWeb
client to RTCWeb client which MUST be recommended because of the UA to
UA communication nature. IOW, RTCWeb server signaling plays the key role
which calls for standardization as browser & RTCWebserver is not
required from the same vendor.

Thanks

Partha

Sent: Friday, October 07, 2011 5:24 PM

On Fri, Oct 7, 2011 at 12:40 PM, Ravindran Parthasarathi
<[email-masked]> wrote:

	Browser to browser real time communication is no different from
other real-time communication apart from the existing web
infrastructure. In case your argument is to use the existing web
infrastructure like websocket, I agree with you.

It is different to traditional RTC - we have a javascript execution
engine intimately tied in to every client. This completely changes the
solution space.

	But in case it is not the reason, Could you please list the
reason for new signaling protocol requirement .

I already listed them: 

	- No special understanding in the server side web application
beyond discovering peer identities you might want to communicate with.

My argument is that if we want the ultimate goal of simplicity for end
user web developers then we should minimise everything they have to
touch - and that includes removing any requirement for server side
infrastructure beyond the basic bare minimum, which would mean no SIP
proxies, no websocket servers etc etc.

Neil

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 17 Oct 2011 13:26:05 +0530

Hadriel,

<snip> Neil makes an excellent point which has only been briefly brought
up but
>should be made more explicit: picking a standard signaling protocol for
>the Browser to implement is only half the problem - the other half of
>the problem is the Web Server has to implement it too, tie it into a
>location database, possibly with authentication and authorization
policy
>rules, and whatever else the specific Web application needs. </snip>

My way of looking at the problem is between RTCWeb client (browser +
javascript) and RTCWeb server signaling. I think that we are in the
agreement that server has to perform couple of functionality like
authentication and authorization policy which is normally dealt in all
signaling protocol. My point is that it is better to spell out RTCWeb
standard protocol between RTCWeb client and RTCWeb server by which
RTCWeb server vendors shall interop smoothly with RTCWeb client. I
missed to spell out in my draft about RTCWeb server dependency but
pointed out the issues in gateway development of RTCWeb server & legacy
server and it may be because I'm more concern about gateways ;-) I'll
clarify in the next revision.

Also, I'm not against creative RTCweb developer to innovate new
signaling protocol for their website. But IETF MUST not mandate every
web developer to create the signaling protocol to make RTCWeb solution
work. 

Thanks
Partha

>From: Hadriel Kaplan [mailto:[email-masked]]
>Sent: Saturday, October 08, 2011 12:20 AM
>To: <[email-masked]>
>Cc: Ravindran Parthasarathi; Neil Stratford
>Neil makes an excellent point which has only been briefly brought up
but
>should be made more explicit: picking a standard signaling protocol for
>the Browser to implement is only half the problem - the other half of
>the problem is the Web Server has to implement it too, tie it into a
>location database, possibly with authentication and authorization
policy
>rules, and whatever else the specific Web application needs.
>
>There is no "20 lines of code" solution once you realize that.  It may
>be 20 lines of JavaScript, but that's only part of the
problem/solution.
>In fact, the most likely way to get to 20 lines of code for the Web
>Server owner is for him/her to use a public JS library for signaling
>which is paired with a web server module written for that specific JS
>library.
>
>-hadriel
>
>
>> If we did go down the hypothetical new standard protocol route (which
>I really think we shouldn't) my requirements would be:
>> Which would lead to something looking like a browser maintained peer
>to peer network, at which point we are re-inventing the web, which
>sounds like something beyond this group. So I strongly support not
>picking a default and instead encourage some innovation at the
>javascript level.
>>
>> Neil
>>

---

From: Tim Panton <[email-masked]>
Date: Mon, 17 Oct 2011 08:57:13 +0100

On 17 Oct 2011, at 08:45, Ravindran Parthasarathi wrote:

> RTCWeb server signaling plays the key role which calls for standardization as browser & RTCWebserver is not required from the same vendor.

And that is where we differ. The web server can _serve_ it's javascript to the browser. 
So the only standards needed are the pre-existing web standards of javascript and http.

The browser only has to be capable of running the javascript served to ensure compatibility.
That's the way that everything on the web works these days, from shopping carts to realtime 
chat. The browser is given site-specific code to run that interacts with site-specific code on
the web server. The web server may choose to convert those requests into a standard protocol 
for further processing (e.g. SQL), or may deal with the request internally.

Note, I'm not ruling out the use of SIP, but as  Iñaki Baz Castillo has demonstrated, that too
can be accomplished purely with existing web technologies. No embedded signalling code 
is needed.

Tim.

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 17 Oct 2011 18:34:03 +0530

Tim,

Please read inline.

Thanks

Partha

From: Tim Panton [mailto:[email-masked]] 
Sent: Monday, October 17, 2011 1:27 PM
To: Ravindran Parthasarathi
Cc: Neil Stratford; samuel; [email-masked]
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol

<partha> Here, webserver acts as a configuration/provisional module to browser and dynamically load the Javascript based signaling protocol in the endpoint.  Please note that Javascript is a programming environment and not the signaling replacement. Apart from this webserver needs to develop its own signaling protocol to acts as RTCWeb server.  In case of Inaki SIP over websocket usecase, RTCWeb server acts as SIP proxy or SIP B2BUA.

The argument here is whether the complete protocol & application has to be developed in each webserver vs the signaling protocol API exists in browser, IETF defined standard signaling protocol in webserver, web programmer invokes server API & client API to make the RTCWeb application. I prefer the second approach because web developer has no need to understand the underlying intricacies.  You can easily the understand the complication involved in signaling protocol by the offer/answer discussion in RTCWeb alias. 

</partha> 

<partha> HTTP is not replacement of SIP in RTCWeb. I agree to the extend that websocket change the signaling paradigm in RTCWeb because two communication established between client & server then routing issue is resolved automatically which is one of the core function of signaling protocol </partha>

<partha> Javascript is the programming environment </partha>

can be accomplished purely with existing web technologies.

<partha> I'm not favor Inaki solution of SIP over websocket because it is overkill for signaling protocol. Websocket solves routing issues between browser-webserver- browser, so the lightweight protocol over websocket will be sufficient and there is no need of complicated SIP based Javascript stack. 

Also, I'm not believer of the downloading complete signaling protocol script because it will delay the setup time which is crucial in lot of real-time application. Of course, it may not be critical for free application but not for professional services.

AFAIK, signaling protocol codebase expands very quickly with the addition of new services and leads to more delay in the setup of the session.  </partha>

 No embedded signalling code 

is needed.

Tim.

---

From: "Roy, Radhika R USA CIV (US)" <[email-masked]>
Date: Mon, 17 Oct 2011 13:50:44 +0000

Folks:

If servers are intelligent enough to "route" the calls among themselves, there are no need for any proxies.

So, proxies are needed for "routing" in the application layer.

BR/Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran Parthasarathi
Sent: Monday, October 17, 2011 3:45 AM
To: Neil Stratford
Cc: [email-masked]
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol

<snip> My argument is that if we want the ultimate goal of simplicity for end user web developers then we should minimise everything they have to touch - and that includes removing any requirement for server side infrastructure beyond the basic bare minimum, which would mean no SIP proxies, no websocket servers etc etc.

But as I said, we don't need to standardise a protocol at all, so we shouldn't. If we are lucky we'll see a whole spectrum of solutions.

 </snip>

Without server interaction, it is not possible for browser to establish the session with other browser. Unlike other endpoint, browser needs server to provide routing or  perform the authentication or atleast configuration information. AFAIK, RTCWeb client to RTCWeb client is not the motive of the work. If so, SIP is the IETF protocol between RTCWeb client to RTCWeb client which MUST be recommended because of the UA to UA communication nature. IOW, RTCWeb server signaling plays the key role which calls for standardization as browser & RTCWebserver is not required from the same vendor.

Thanks

Partha

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 17 Oct 2011 19:26:55 +0530

Hi Radhika,

I agree with you for "proxy" requirement and it is classified as
"federation" in RTCWeb which is outside the scope of current discussion.

IOW, single RTCWeb server knows where to route the session between any
two known RTCWeb client but RTCweb client will not aware how to route to
other RTCWeb client.

Thanks
Partha

>From: Roy, Radhika R USA CIV (US) [mailto:[email-masked]]
>Sent: Monday, October 17, 2011 7:21 PM
>To: Ravindran Parthasarathi; Neil Stratford
>Cc: [email-masked]
>Subject: RE: [rtcweb] Review request for RTCWeb standard signaling
>protocol
>
>Folks:
>
>If servers are intelligent enough to "route" the calls among
themselves,
>there are no need for any proxies.
>
>Of Ravindran Parthasarathi

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 17 Oct 2011 17:51:07 +0200

2011/10/17 Ravindran Parthasarathi <[email-masked]>:

Again the same...

Ravindran, you are repeating the *same* arguments in different
mails/threads. You always *ignore* and don't reply to responses given
to your arguments. You are also manipulating some given responses by
making them to look as if their content agree with your insistent
proposal.

You are trying to manipulate this WG and that is dishonest. STOP please.

Unfortunatelly for you, your mails will always receive the deserved response:

> <partha> I’m not favor Inaki solution of SIP over websocket because it is
> overkill for signaling protocol.

Demonstrate it !!!

I know that SIP over websocket is NOT an overkill (because I *use*
it). You DONT KNOW the opposite. You CANNOT assert the opposite.
Stop lying please!

> Websocket solves routing issues between
> browser-webserver- browser, so the lightweight protocol over websocket will
> be sufficient and there is no need of complicated SIP based Javascript
> stack.

Use whatever you want but don't force me to use what you want. Neither
insist on creating a "default signaling protocol" for the reaons given
1000 times in this maillist (those reasons you ignore again and again
and you will NEVER reply to).

> Also, I’m not believer of the downloading complete signaling protocol script
> because it will delay the setup time which is crucial in lot of real-time
> application. Of course, it may not be critical for free application but not
> for professional services.

So you don't understand how the WWW works. The user visits a web page,
the browser downloads all the HTML, CSS, images and JavaScript stuff
and, *after that*, the web application is ready to be used. It does
not depend just on having a signaling protocol built-in the browser.

Now the problem is downloading a ~150KB JavaScript file??? There are
images taking more space in lot of webs!

> AFAIK, signaling protocol codebase expands very quickly with the addition of
> new services and leads to more delay in the setup of the session.  </partha>

And how is supposed your proposed "default signaling protocol" to
handle those "new services"? If you try NOW to make a "default
signaling protocol" for RTCweb that means that you MUST know *NOW* all
the possible requirements of any RTCweb future communication. You
don't know them, I don't know them, nobody knows them!

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

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 17 Oct 2011 22:30:06 +0530

The point to be noted is folks put forth the same argument again & again..each time, it is not possible to come up new answer ;-) I noticed often you complain as if your important is missed out. We are arguing only about "nothing" vs "something" as a RTCWeb signaling protocol.

I clearly explained why SIP over websocket is an overkill in the below mail thread. Please read it and don't argue that it is working. All the working stuff is not good. Infact for any protocol, the first idea pop-up is to tunnel the complete inside (For Ex: ISUP over SIP) but always better ways to solve it.

I think that you confusing the argument with script & protocol. I agree that WWW world works with PHP for server side and Javascript, CSS for client side but I'm talking about HTTP protocol in case of legacy web. Of course, HTTP is not designed for real-time communication. So, we need some signaling protocol like Jingle, Websocket with offer/answer (ROAP) to make it work. Let us talk about the protocol and not about the programming environment.

The base idea of defining the protocol is to provide the basic building blocks and new service shall be developed using these building block. In case basic building block is well defined, building the new service will not be impossible. Normally, standard protocol will undergo through review which the basic new service needs. 

I'm talking about the performance because I know that success story SIP written in C over SIP written in Java. In case you argue for SIP plugin vs native SIP, the performance may not be much difference. Also, the download of the entire protocol is worse than in-build protocol by any means.

-Partha

>Sent: Monday, October 17, 2011 9:21 PM
>Cc: Tim Panton; [email-masked]

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Tue, 18 Oct 2011 01:09:26 +0800

Hi Partha

Though I agree with you that SIP over Websockets is an overkill on web browsers, there is a need for some kind of signaling protocol for communicating offer / answer model between 2 web browser clients.  This was one of my comments on Inaki's SIP over Websockets transport.  

My point is there is a need for some kind of signaling protocol to be used over Websockets - be it SIP or XMPP -  but these should be used as Websocket sub protocol.

Regards
Ranjit
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ravindran Parthasarathi [[email-masked]]
Sent: Monday, October 17, 2011 10:30 PM
To: Iñaki Baz Castillo
Cc: [email-masked]
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol

-Partha

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 17 Oct 2011 19:19:18 +0200

2011/10/17 Ravindran Parthasarathi <[email-masked]>:

> I clearly explained why SIP over websocket is an overkill in the below mail thread. Please read it and don't argue that it is working.

I argue that it *works* and it is *not* an overkill.

> All the working stuff is not good.

Are you asserting that my software is not good??? who are you to say that???
Have I said that most probably all the software you have coded sucks?

> Infact for any protocol, the first idea pop-up is to tunnel the complete inside (For Ex: ISUP over SIP) but always better ways to solve it.

So, why do you tunnel SIP over UDP or TCP? Instead create a new
transport level protocol on top of the IP layer and call it
SIP-Ravindran.

> I think that you confusing the argument with script & protocol. I agree that WWW world works with PHP for server side and Javascript, CSS for client side but I'm talking about HTTP protocol in case of legacy web. Of course, HTTP is not designed for real-time communication. So, we need some signaling protocol like Jingle, Websocket with offer/answer (ROAP) to make it work.

ROAP is just about negotiating media! You still need a signaling
protocol (for example to tell the server "who you want to call"). Such
signaling protocol can be a custom JSON over WebSocket, or can be SIP
over WebSocket or whatever over WebSocket (or over HTTP with Comet).

And you still don't understand that WebSocket is not an application
protocol, but a transport protocol. You insist in saying "Websocket
with offer/answer (ROAP)", so how to signal the destination of the
audio/video call? You need a WebSocket subprotocol on top of the
WebSocket transport for that, for example *SIP* (or whatever you
choose).

> I'm talking about the performance because I know that success story SIP written in C over SIP written in Java. In case you argue for SIP plugin vs native SIP, the performance may not be much differ…

Ok ok, say what you want (the same again and again). Good luck and bye.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 17 Oct 2011 19:21:11 +0200

2011/10/17 Avasarala, Ranjit <[email-masked]>:
> Though I agree with you that SIP over Websockets is an overkill on web browsers,

And you can assert that because.... oh, you cannot! or have you tried it?

> My point is there is a need for some kind of signaling protocol to be used over Websockets - be it SIP or XMPP -  but these should be used as Websocket sub protocol

Sure. Check http://tools.ietf.org/html/draft-ibc-rtcweb-sip-websocket-00

-----------------------------------------
Abstract

   This document specifies a WebSocket subprotocol for a new transport
   in SIP (Session Initiation Protocol). [...]
------------------------------------------

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 17 Oct 2011 19:35:28 +0200

> Sure. Check http://tools.ietf.org/html/draft-ibc-rtcweb-sip-websocket-00

And also check http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-00

------------------
An XMPP Sub-protocol for WebSocket
draft-moffitt-xmpp-over-websocket-00
------------------

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

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 18 Oct 2011 03:13:57 +0530

Hi Ranjit,

I agree with you for using signaling protocol to be used over websocket.

Thanks
Partha

>From: Avasarala, Ranjit [mailto:[email-masked]]
>Sent: Monday, October 17, 2011 10:39 PM
>To: Ravindran Parthasarathi; Iñaki Baz Castillo
>Cc: [email-masked]
>Though I agree with you that SIP over Websockets is an overkill on web
>browsers, there is a need for some kind of signaling protocol for
>communicating offer / answer model between 2 web browser clients.  This
>was one of my comments on Inaki's SIP over Websockets transport.
>
>My point is there is a need for some kind of signaling protocol to be
>used over Websockets - be it SIP or XMPP -  but these should be used as
>Websocket sub protocol.
>
>Regards
>Ranjit
>From: [email-masked] [[email-masked]] On Behalf Of
>Ravindran Parthasarathi [[email-masked]]
>The point to be noted is folks put forth the same argument again &
>again..each time, it is not possible to come up new answer ;-) I noticed
>often you complain as if your important is missed out. We are arguing
>only about "nothing" vs "something" as a RTCWeb signaling protocol.
>
>I clearly explained why SIP over websocket is an overkill in the below
>mail thread. Please read it and don't argue that it is working. All the
>working stuff is not good. Infact for any protocol, the first idea pop-
>up is to tunnel the complete inside (For Ex: ISUP over SIP) but always
>better ways to solve it.
>
>I think that you confusing the argument with script & protocol. I agree
>that WWW world works with PHP for server side and Javascript, CSS for
>client side but I'm talking about HTTP protocol in case of legacy web.
>Of course, HTTP is not designed for real-time communication. So, we need
>some signaling protocol like Jingle, Websocket with offer/answer (ROAP)
>to make it work. Let us talk about the protocol and not about the
>programming environment.
>
>The base idea of defining the protocol is to provide the basic building
>blocks and new service shall be developed using these building block. In
>case basic building block is well defined, building the new service will
>not be impossible. Normally, standard protocol will undergo through
>review which the basic new service needs.
>
>I'm talking about the performance because I know that success story SIP
>written in C over SIP written in Java. In case you argue for SIP plugin
>vs native SIP, the performance may not be much difference. Also, the
>download of the entire protocol is worse than in-build protocol by any
>means.
>
>-Partha
>
>>> <partha> I'm not favor Inaki solution of SIP over websocket because
>it
>>is
>>> browser-webserver- browser, so the lightweight protocol over
>websocket
>>will
>>> Also, I'm not believer of the downloading complete signaling protocol
>>script

---

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

> I clearly explained why SIP over websocket is an overkill in the below mail thread. Please read it and don't argue that it is working. All the working stuff is not good. Infact for any protocol, th…

Let me connect the dots: you are advocating for a new 'simple' protocol instead of taking an existing one, SIP for example, which you called 'overkill'. And earlier in this thread you mentioned that you are interested in gateways.

I now understand what you are trying to do.

--
Saúl Ibarra Corretgé
AG Projects

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 18 Oct 2011 13:45:44 +0530

Saul,

One minor correction in your mail: I have mentioned "SIP over websocket" is an overkill and not SIP.

Thanks
Partha

>From: Saúl Ibarra Corretgé [mailto:[email-masked]]
>Sent: Tuesday, October 18, 2011 12:32 PM
>Cc: Iñaki Baz Castillo; [email-masked]
>Let me connect the dots: you are advocating for a new 'simple' protocol
>instead of taking an existing one, SIP for example, which you called
>'overkill'. And earlier in this thread you mentioned that you are
>interested in gateways.
>

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Tue, 18 Oct 2011 16:38:27 +0800

That's the whole issue. We need some mechanism for web browsers to negotiate offer/answer and ICE candidates between each other. Using SIP for this over websockets would bring in unnecessary overheads. But we still need some mechanism. So something which is "simple" is needed.

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran Parthasarathi
Sent: Tuesday, October 18, 2011 1:46 PM
To: Saúl Ibarra Corretgé
Cc: [email-masked]
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol

Saul,

Thanks
Partha

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Oct 2011 10:48:45 +0200

> One minor correction in your mail: I have mentioned "SIP over websocket" is an overkill and not SIP.

Ravindran, please forget "SIP over WebSocket". I've never proposed it
to be a default RTCweb signaling protocol, not at all, so if you don't
like it just don't use it.

BTW what I understand given your insistent proposal is that you need
the RTCweb signaling protocol (messages in-the-wire) to be an IETF
standard so you get a market for building and selling gateway boxes
between such "IETF-RTCweb-Protocol" and other IETF standard protocols
(as SIP). It's clear that you like gateways and you want gateways.

Said that I apologize to this WG for some of my mails yesterday. It
won't happen again.

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Tue, 18 Oct 2011 11:38:21 +0200

> One minor correction in your mail: I have mentioned "SIP over websocket" is an overkill and not SIP.

You confuse me. You said before that the JS libraries would take time to download and all that, and now you say that SIP is not overkill. I don't see another way of using SIP in a browser (without plugins) than using JS for the stack and WebSocket as a transport.

Either way, there seems to be a consensus that no signaling protocol should be specified, time to move on.

--
Saúl Ibarra Corretgé
AG Projects

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 18 Oct 2011 17:01:22 +0530

Agreed Ranjit.

>Sent: Tuesday, October 18, 2011 2:08 PM
>To: Ravindran Parthasarathi; Saúl Ibarra Corretgé
>Cc: [email-masked]
>That's the whole issue. We need some mechanism for web browsers to
>negotiate offer/answer and ICE candidates between each other. Using SIP
>for this over websockets would bring in unnecessary overheads. But we
>still need some mechanism. So something which is "simple" is needed.
>
>Regards
>Ranjit
>

---

From: "Roy, Radhika R USA CIV (US)" <[email-masked]>
Date: Tue, 18 Oct 2011 13:08:08 +0000

Hi, Saúl

Is there a way to do negotiations with different codec types and different features of a given codec without using a signaling protocol between the two functional entities?

BR/Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Saúl Ibarra Corretgé
Sent: Tuesday, October 18, 2011 5:38 AM
To: Ravindran Parthasarathi
Cc: [email-masked]
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol

--
Saúl Ibarra Corretgé
AG Projects

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 18 Oct 2011 09:16:57 -0400

Yes, something "simple" would be nice but the definition of "simple enough but still allowing me to do what I want to achieve" is very much dependent on the needs of each specific use case/service. There is no universal definition of "simple" here. So, I guess this is yet another argument in favor of not standardizing the protocol between browser and webserver so that everybody can design/use whatever is "simple but good enough" from their perspective.

Thanks,
Tolga

> Of Avasarala, Ranjit
> Sent: Tuesday, October 18, 2011 4:38 AM

---

From: Tim Panton <[email-masked]>
Date: Tue, 18 Oct 2011 14:25:31 +0100

> Is there a way to do negotiations with different codec types and different features of a given codec without using a signaling protocol between the two functional entities?

No, you always need  a transport to get the supported codec description list from one end to the other. 
What you don't have to specify is the protocol that the transport uses, or the decision making process that each end uses
to select the capabilities it wants to employ in this instance of this web app.

Here is an example that illustrates how it could work in a 'protocol free' way.

User A could query the browser for the codec description list at the start of a web game session, the web 
app could upload that to the session storage on the game server. 
User B does the same thing.
At some point later users A and B encounter each other in the game. - the server _already_knows_ the capabilites 
of their respective browsers and instructs them to do an ice negotiation to find a transport between them.
Once that is done it informs them _both_ of it's codec selection - which may be based on their game status.

The video session proceeds as part of the game until the 2 users part, at which point the session is torn down.

I'm by no means saying that this is the _only_ way connections can be made, just that if we get this API right
we can do things this way.
Tim.

---

From: "Roy, Radhika R USA CIV (US)" <[email-masked]>
Date: Tue, 18 Oct 2011 13:48:37 +0000

Folks:

Tolga is right.

We have a very complex problem to solve. It is called negotiations between different types of codecs and between different features of each codec type.

Let us see how simple a protocol can be based on these simple requirements.

BR/Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Asveren, Tolga
Sent: Tuesday, October 18, 2011 9:17 AM
To: Avasarala, Ranjit; Ravindran Parthasarathi; Saúl Ibarra Corretgé
Cc: [email-masked]
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol

Thanks,
Tolga

---

From: "Roy, Radhika R USA CIV (US)" <[email-masked]>
Date: Tue, 18 Oct 2011 13:59:41 +0000

Tim:

The puzzle is this. The other user may not agree completely with the offer of the first user. Even the other user may agree with a given codec type, he/she may not agree other features including bandwidth of the codec.

It simple turns out that a freedom needs to be given for negotiations some-like offer/answer.

Well, if we can avoid these complexities, let us find out (e.g. Pre-defined some constraints etc.).

Or, if an API is good enough exposing all the codec parameters and offer/answer signaling can be avoided, let us find it out.

BR/Radhika

-----Original Message-----
From: Tim Panton [mailto:[email-masked]] 
Sent: Tuesday, October 18, 2011 9:26 AM
To: Roy, Radhika R USA CIV (US)
Cc: Saúl Ibarra Corretgé; Ravindran Parthasarathi; [email-masked]
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol

No, you always need  a transport to get the supported codec description list from one end to the other. 
What you don't have to specify is the protocol that the transport uses, or the decision making process that each end uses to select the capabilities it wants to employ in this instance of this web app.

User A could query the browser for the codec description list at the start of a web game session, the web app could upload that to the session storage on the game server. 
User B does the same thing.
At some point later users A and B encounter each other in the game. - the server _already_knows_ the capabilites of their respective browsers and instructs them to do an ice negotiation to find a transport between them.
Once that is done it informs them _both_ of it's codec selection - which may be based on their game status.

I'm by no means saying that this is the _only_ way connections can be made, just that if we get this API right we can do things this way.
Tim.

---

From: Tim Panton <[email-masked]>
Date: Tue, 18 Oct 2011 15:19:50 +0100

> It simple turns out that a freedom needs to be given for negotiations some-like offer/answer.

The example I gave had _no_ negotiation, no back and forth, because the application's webserver was
told all the capabilities in advance, (at login in my example), it simply _decided_ based on
it's view of the union of the capabilities of the two ends. It then informed them of the choice
(which may have been asymmetric by the way) and told them to get on with it.

To the extent that there was a 'negotiation',  it took place in a single thread on the web server, 
with no propagation delays or locks needed.

> Or, if an API is good enough exposing all the codec parameters and offer/answer signaling can be avoided, let us find it out.

Offer - Answer really only crops up because there is a requirement (which I personally put very low on our priorities) to be able
to interop with legacy video phones without  needing a media gateway. 

Tim.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 18 Oct 2011 07:46:24 -0700

> (which may have been asymmetric by the way) and told them to get on with
The working group decided very early on to require a mandatory-to-implement
codec to ensure that there were no negotiation failures.  If the web server
always selects the mandatory to implement codec, then this should work.  It
may be sub-optimal (a better codec might have been available for this
session), but it would cause a complete connection.

The issue comes when you use a pair of codec sets from time T and run the
intersection algorithm at some later time.  The risk is that the overall
resource set available at one or more of the nodes may have changed, and
this can have an impact on its ability or preferences.  The classic example
is battery life on mobiles.  If I send you a capability set when I have a
fully charged battery, it may include computationally expensive algorithms
that take a lot of energy; those might be lower preference or elided from
the set after hours of game play in which I drew the battery down.

I also note that this is not really protocol free, it's just that the format
by which the API results are returned to the webserver running the
intersection algorithm are not standard; there's still a (private) protocol
in use.

regards,

Ted

> > Or, if an API is good enough exposing all the codec parameters and
> offer/answer signaling can be avoided, let us find it out.
>
> Offer - Answer really only crops up because there is a requirement (which I
> personally put very low on our priorities) to be able
> >> Is there a way to do negotiations with different codec types and
> different features of a given codec without using a signaling protocol
> between the two functional entities?
> >>
> >> BR/Radhika
> >
> > What you don't have to specify is the protocol that the transport uses,
> or the decision making process that each end uses to select the capabilities
> it wants to employ in this instance of this web app.
> >
> > User A could query the browser for the codec description list at the
> start of a web game session, the web app could upload that to the session
> storage on the game server.
> > At some point later users A and B encounter each other in the game. - the
> server _already_knows_ the capabilites of their respective browsers and
> instructs them to do an ice negotiation to find a transport between them.
> > I'm by no means saying that this is the _only_ way connections can be
> made, just that if we get this API right we can do things this way.
> > Tim.
> >
>

---

From: Tim Panton <[email-masked]>
Date: Tue, 18 Oct 2011 16:02:02 +0100

On 18 Oct 2011, at 15:46, Ted Hardie wrote:

> The working group decided very early on to require a mandatory-to-implement codec to ensure that there were no negotiation failures.  If the web server always selects the mandatory to implement codec, then this should work.  It may be sub-optimal (a better codec might have been available for this session), but it would cause a complete connection.

That would be the trivial case of the intersection algorithm.

> 
> The issue comes when you use a pair of codec sets from time T and run the intersection algorithm at some later time.  The risk is that the overall resource set available at one or more of the nodes may have changed, and this can have an impact on its ability or preferences.  The classic example is battery life on mobiles.  If I send you a capability set when I have a fully charged battery, it may include computationally expensive algorithms that take a lot of energy; those might be lower preference or elided from the set after hours of game play in which I drew the battery down.  

On the other hand, As a user I might find the next 20 seconds of play critical and opt to go 'hi-def' despite the low battery warning. Some of the current proposals would make that very hard to do.

> 
> I also note that this is not really protocol free, it's just that the format by which the API results are returned to the webserver running the intersection algorithm are not standard; there's still a (private) protocol in use.

Agreed, the data has to move somehow. I'm not sure I dignify sending some JSON object over HTTP as a 'protocol', I see it as a pre-existing transport.
There is indeed a private (in the sense that it isn't standardized) intersection algorithm running, but my point was that it wouldn't _have_ to
run in the browser, it might well run in the server. The current round of proposals seem to me to preclude that almost completely , which very much
goes against the grain in the context of a web service.

Tim.

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 18 Oct 2011 23:35:22 +0530

Tolga/Radhika,

In case I read Ranjit mail correctly, the "simpler" protocol than "SIP over websocket" is required which does not require to perform signaling routing functionality like via header, route header handling as two-way communication between browser to RTCWeb server is established using websocket. But, It does not mean that media negotiation ("offer/answer") is not required. I have mentioned this media negotiation requirement for signaling in Bullet 2 of Sec 5 in draft-partha-rtcweb-signaling-00 draft as 

    " The mechanism has to provide the way to pass description about the
      media transmission between two RTCweb clients"

Also, the attempt for "standard" signaling protocol is not an attempt to stop custom-build signaling protocol and Sec 4 of draft-partha-rtcweb-signaling-00 draft explains this as

but standard signaling protocol facilities for the quick development of the generic RTCWeb usecase without the need of developing of new signaling protocol per website. In case you still feel that my draft does not reflect this notion, Please let me know.

Thanks
Partha

>Sent: Tuesday, October 18, 2011 7:19 PM
>To: Asveren, Tolga; Avasarala, Ranjit; Ravindran Parthasarathi; Saúl
>Ibarra Corretgé
>Cc: [email-masked]
>We have a very complex problem to solve. It is called negotiations
>between different types of codecs and between different features of each
>codec type.
>
>Of Asveren, Tolga
>Yes, something "simple" would be nice but the definition of "simple
>enough but still allowing me to do what I want to achieve" is very much
>dependent on the needs of each specific use case/service. There is no
>universal definition of "simple" here. So, I guess this is yet another
>argument in favor of not standardizing the protocol between browser and
>webserver so that everybody can design/use whatever is "simple but good
>enough" from their perspective.
>
>Thanks,
>Tolga
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 18 Oct 2011 14:18:34 -0400

Just for clarity, my use of the term "simple" in this thread was a bit rhetorical to indicate that I do not agree with Ranjit's view that a "simple standard protocol" is needed between browser and webserver.

I am even not sure whether full offer/answer semantics need to be supported between webserver and JS (or better said, whether that needs to be the only way of doing things). I would think that supporting what Tim Panton describes in another thread (codec selection done in webserver) could be nice to achieve -among other models- if possible. 

Thanks,
Tolga

> From: Ravindran Parthasarathi
> Sent: Tuesday, October 18, 2011 2:05 PM
> To: Roy, Radhika R USA CIV (US); Asveren, Tolga; Avasarala, Ranjit; Saúl
> Ibarra Corretgé
> Cc: [email-masked]
> In case I read Ranjit mail correctly, the "simpler" protocol than "SIP
> over websocket" is required which does not require to perform signaling
> routing functionality like via header, route header handling as two-way
> communication between browser to RTCWeb server is established using
> websocket. But, It does not mean that media negotiation ("offer/answer")
> is not required. I have mentioned this media negotiation requirement for
> signaling in Bullet 2 of Sec 5 in draft-partha-rtcweb-signaling-00 draft
> as
> 
> Also, the attempt for "standard" signaling protocol is not an attempt to
> stop custom-build signaling protocol and Sec 4 of draft-partha-rtcweb-
> signaling-00 draft explains this as
> 
> but standard signaling protocol facilities for the quick development of
> the generic RTCWeb usecase without the need of developing of new signaling
> protocol per website. In case you still feel that my draft does not
> reflect this notion, Please let me know.
> 
> 
> Thanks
> Partha
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Oct 2011 20:19:44 +0200

2011/10/18 Asveren, Tolga <[email-masked]>:
> I would think that supporting what Tim Panton describes in another thread (codec selection done in webserver) could be nice to achieve -among other models- if possible.

I hope the intelligence is NOT required to be in the web server.

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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 18 Oct 2011 14:28:32 -0400

Yes, not required, but possible -if we can achieve that level of flexibility-.

Overall, there are two models here:
i- Webbrowser/JS as signaling/media entity
ii- Webbrowser/JS as a media entity controlled by webserver

It seems focus is on i- but I heard a few people mentioning about ii- and no direct rejection yet. Supporting both models would require a careful design of RTCWeb stack/JS interface so that it is flexible enough but also can be used easily for simple variations of each model.

Thanks,
Tolga

> Sent: Tuesday, October 18, 2011 2:20 PM
> To: Asveren, Tolga
> Cc: Ravindran Parthasarathi; Roy, Radhika R USA CIV (US); Avasarala,
> Ranjit; Saúl Ibarra Corretgé; [email-masked]
> > I would think that supporting what Tim Panton describes in another
> thread (codec selection done in webserver) could be nice to achieve -among
> other models- if possible.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Oct 2011 20:34:54 +0200

> but standard signaling protocol facilities for the quick development of the generic RTCWeb usecase without the need of developing of new signaling protocol per website. In case you still feel that…

When RTCweb becomes a reality there will appear thousands of
JavaScript libraries implementing different RTCweb signaling
protocols, each one with its own features and capabilities. Do you
understand that a website admin will be able to choose the one he
prefers?

Visit 100 random cool websites. Probably 50% of them use JQuery JS
library. Does it mean that each web developer had to build his own JS
library? not at all, they use JQuery.

Now your reply will be "downloading the JS library everytime is not
efficient". Ok, visit 100 random cool websites. Probably 50% of them
use JQuery JS library. How many times have you downloaded the JQuery
library (assuming that every site has its own copy of the .js)? ... 50
times. Is that a problem? not for the rest of the humans in the world.

So please stop making up issues that don't exist. The WWW world does
not work as you propose, and anyhow it has succeeded.

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

---

From: Jim McEachern <[email-masked]>
Date: Tue, 18 Oct 2011 19:31:41 +0000

Tolga,
I'm confused by your statement that "supporting both models would require a careful design of RTCWeb stack/JS interface...". Surely the same information would have to be supported by the API whether the intelligence was in the JS or in the web server. Other than a strong requirement for it being asynchronous (which has already been proposed for other reasons) I would have thought the API could be the same whether the intelligence is in the JS or the web server. 

For the record, I am not arguing either way on where the intelligence should be. I'm simply trying to understand the requirements.

Jim

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 18 Oct 2011 15:45:24 -0400

Mea culpa, yes it is more about the nature of relationship between RTCWeb in browser and JS/webserver.

Thanks,
Tolga

> From: Jim McEachern [mailto:[email-masked]]
> Sent: Tuesday, October 18, 2011 3:32 PM
> To: Asveren, Tolga
> I'm confused by your statement that "supporting both models would require
> a careful design of RTCWeb stack/JS interface...". Surely the same
> information would have to be supported by the API whether the intelligence
> was in the JS or in the web server. Other than a strong requirement for it
> being asynchronous (which has already been proposed for other reasons) I
> would have thought the API could be the same whether the intelligence is
> in the JS or the web server.
> 
> For the record, I am not arguing either way on where the intelligence
> should be. I'm simply trying to understand the requirements.
> 
> Jim
> 
> 
> > It seems focus is on i- but I heard a few people mentioning about ii-
> and no direct rejection yet. Supporting both models would require a
> careful design of RTCWeb stack/JS interface so that it is flexible enough
> but also can be used easily for simple variations of each model.
> >
> > Thanks,
> > Tolga
> >

---

From: Ted Hardie <[email-masked]>
Date: Tue, 18 Oct 2011 12:58:32 -0700

> understand that a website admin will be able to choose the one he
You make this sound like you believe this to be an advantage.  Having seen
the bit-rot in quite a few libraries,  I'm less included to assume that
every library created will be feature complete and well-maintained.  I'm
equally leery of presuming that it is easy to chose among them.  Checking
for embedded malware, to take a simple example, makes the task longer and
more fraught with issues than you might suppose.

> times. Is that a problem? not for the rest of the humans in the world.
It's certainly less efficient and, given the majority of users now accessing
the Internet via mobile devices which are power and bandwidth constrained,
that sort of wastefulness should not be trivially dismissed.  I

> not work as you propose, and anyhow it has succeeded.
You set up a strawman that you attempted to knock down.  He did not propose
it, you did.  I also don't think you scored even a TKO on the strawman.
Again, please focus on your own points,

thanks,

Ted Hardie

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 18 Oct 2011 16:30:49 -0400

Some opinions about the topics under discussion:

i- One difference between JS library and browser support is that service developer can choose the JS library they want to use (or develop their own). It is up to them to make sure that it works fine, does not have malicious behavior etc... If they don't do their homework, their service will fail. OTOH, service developer has no control over what is/will be supported in the browser, e.g. browser-X supporting forking only after release-Y. I also would expect that security requirement is more on the browser so that it does not let potentially malicious things to be done and this would be controlled by the enduser by its choice of browser.

ii- How big do we expect JS libraries to be? I think we assume that battery/bandwidth is not a showstopper for realtime communication so I would think JS library size would be a factor only if its ratio v.s. media is non-negligible.

Thanks,

Tolga

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Tuesday, October 18, 2011 3:59 PM
To: Iñaki Baz Castillo
Cc: [email-masked]
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol

You make this sound like you believe this to be an advantage.  Having seen the bit-rot in quite a few libraries,  I'm less included to assume that every library created will be feature complete and well-maintained.  I'm equally leery of presuming that it is easy to chose among them.  Checking for embedded malware, to take a simple example, makes the task longer and more fraught with issues than you might suppose.

It's certainly less efficient and, given the majority of users now accessing the Internet via mobile devices which are power and bandwidth constrained, that sort of wastefulness should not be trivially dismissed.  I

You set up a strawman that you attempted to knock down.  He did not propose it, you did.  I also don't think you scored even a TKO on the strawman.  Again, please focus on your own points, 

thanks,

Ted Hardie

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 18 Oct 2011 20:43:22 +0000

On Oct 18, 2011, at 3:58 PM, Ted Hardie wrote:

On Tue, Oct 18, 2011 at 11:34 AM, Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>> wrote:

You make this sound like you believe this to be an advantage.

It *is* an advantage.  It puts the power in the hands of the app developer, not the browser developer.

Having seen the bit-rot in quite a few libraries,

Have you ever used Internet Explorer??

(and I'm not slamming IE because I think their developers are bad - they have a very tough job of keeping compatibility with numerous Windows OS versions, drivers, etc. - I just think they'll focus on doing that rather dealing with signaling protocol changes/bug-fixes for RTCWeb in any timely manner)

It's certainly less efficient and, given the majority of users now accessing the Internet via mobile devices which are power and bandwidth constrained, that sort of wastefulness should not be trivially dismissed.

If a mobile platform is so constrained of power and bandwidth that downloading a JS library is difficult, it's unlikely it would be able to handle RTP/RTCP media regardless.

-hadriel

---

From: Ted Hardie <[email-masked]>
Date: Tue, 18 Oct 2011 16:40:38 -0700

> developer, not the browser developer.
As Peter Parker's uncle Ben tells, us, with great power comes great
responsibility.  Yes, it gives them a choice, but it also makes them
responsible for something that is, bluntly, infrastructure plumbing that
most of them would rather just worked.

>  Have you ever used Internet Explorer??

Not lately; it doesn't run on any of my current platforms.

> (and I'm not slamming IE because I think their developers are bad - they
> have a very tough job of keeping compatibility with numerous Windows OS
> versions, drivers, etc. - I just think they'll focus on doing that rather
> dealing with signaling protocol changes/bug-fixes for RTCWeb in any timely
> manner)
>
>   It's certainly less efficient and, given the majority of users now
> accessing the Internet via mobile devices which are power and bandwidth
> constrained, that sort of wastefulness should not be trivially dismissed.
>
>
>  If a mobile platform is so constrained of power and bandwidth that
> downloading a JS library is difficult, it's unlikely it would be able to
> handle RTP/RTCP media regardless.
>
>
You don't get to be rich by making a lot of money, you get to be rich by
keeping it.  The same is true with energy in mobile systems.  Pay attention
to it all the time, and there's a fair chance you will never run out.  Pay
attention to it only when you're low, and you're likely paying attention to
late.

regards,

Ted

---

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

Hi Tolga,

My basic doubt is how to you ensure jquery library does not have malware without understanding its detail functionality. AFAIK, Small Web developer test cycle is very different from exhaustive testing by OEM. 

In case your concern is related to browser compatibility for the specific service or RTCWeb compliant, it is unavoidable and it is based on my end-user browser experience. IETF-81 meetecho conference tool supports HTML5 which is not working in my browsers (IE8 in windows XP) and I forced to download Chrome to attend IETF RTCWeb session from remote. In fact I'm asking for standard because with having HTML5 sort of standard itself, I'm not getting update with few browsers and without any standard, none of the browsers (Chrome, Firefox) will support.

Based on the above, if you conclude that it is better for everybody to write signaling protocol and then it may apply to RTCWeb media protocol as well because it is not guaranteed that browser-x will be RTCWeb compliant at which release-y. I doubt whether I will get IE update for HTML5 or RTCWeb anytime soon without OS upgrade ;-). Of course, lot of Real-time web application is possible without RTCWeb browser using Jquery and plugins. Your proposal is to avoid plugin only and keep jquery as such but plugin may be preferred in case of custom build application wherein compressed RTP/RTCP is the focus.

 So, IMO standards may not help for the above scenarios. Wherein IETF standards helps for 

1)      Ensuring interop between RTCWeb client (browser which are compatible) and RTCWeb server for signaling,  RTCWeb client to RTCWeb client for media

2)      Comparatively easy RTCWeb application development in case framework of the standard signaling protocol exists in the RTCWeb client and RTCWeb server.

3)      I'm worried for the delay because every conference session from 512 kbps internet connection may take nearly 2 min to join the conference after I login.  The setup time matters because for every meeting, I have to login before 2 min :-(. 

4)      In case RTCWeb signaling is defined, RTCWeb signaling to legacy signaling  gateway will be available for low cost in terms of $ compare to the gateway which has to convert custom build.

5)      Also ensure that Novice RTCWeb developer does not use intellectual property of others (jquery library) without knowing in detail.

Also, Some of the usecase which are not well discussed in this forum is about RTCWeb usage with Enterprise, call center. I'm seeing RTCWeb as a next generation collaborative mechanism (web + VoIP) rather than just plugin removal WG.

Please note that I'm not talking about API because it is the programming environment and W3C stuff.

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Asveren, Tolga
Sent: Wednesday, October 19, 2011 2:01 AM
To: Ted Hardie; Iñaki Baz Castillo
Cc: [email-masked]
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol

Thanks,

Tolga

	

thanks,

Ted Hardie

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

---

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

Inaki/Saul,

It is not that I'm interested in RTCWeb gateway but it is the best known solution currently. Please look into my earlier mail thread (http://www.ietf.org/mail-archive/web/rtcweb/current/msg01058.html) for asking not to have gateways and the issues involved in developing gateways. But in case two protocols like SIP, websocket are started using for the signaling within the same session, the interop is possible only with gateways or tunneling wherein I prefer gateway.  

I agree that the primary focus of this WG is to browser-to-browser without federation in mind. But the power of collaboration using RTCWeb will be realized in case federation protocol are used. For example, search for the keyword in Google from the Android browser, go to the website, click in the website leads to the call in the call center of the website company without involving any PSTN network. Here, website of the company acts as a service provider for the company and reduce the PSTN/SIP trunk cost drastically.

Thanks
Partha

>Sent: Tuesday, October 18, 2011 2:19 PM
>Cc: Saúl Ibarra Corretgé; [email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 19 Oct 2011 05:11:25 +0000

Hi Partha,
comments inline

> It is not that I'm interested in RTCWeb gateway but it is the best known solution currently. Please look into my earlier mail thread (http://www.ietf.org/mail-archive/web/rtcweb/current/msg01058.ht…

I am confused by your statements.  In the email thread you cited above, and in your draft, you imply that websocket is a signaling protocol or browser-to-browser protocol.  It isn't.  For all intents and purposes of this WG, it's a transport.  That's all.  It's like TCP, UDP or SCTP.  And it goes between the browser and a web server, not between browsers.  What's put onto that transport socket is up to the JavaScript and web server code.

I also don't understand what you mean by "interop is only possible with gateways or tunneling".  I don't see how tunneling anything solves interop of anything.  But for gateways, yes if everything spoke a standard protocol, making gateways would be easier - but it doesn't require the RTCWeb<->browser path to speak that signaling protocol; it only requires the web-server to speak it.  In fact it might not even require that - it might be possible to have a gateway be a JavaScript client too.

> I agree that the primary focus of this WG is to browser-to-browser without federation in mind. But the power of collaboration using RTCWeb will be realized in case federation protocol are used. For…

So?  How does this require a standard signaling protocol on the browser?

-hadriel

---

From: Randell Jesup <[email-masked]>
Date: Wed, 19 Oct 2011 03:13:11 -0400

> with no propagation delays or locks needed.

This example you give raises some security issues based on the current 
proposals.  We require that the user ok access to the camera and 
microphone; this is a call set up "on the fly" with apparently no 
individual certification from the user.

This use-case would require the JS application get pre-authorization of 
media access, before any actual access occurs, and have that access 
persist until <something>, across multiple individual connections.

So is this outside of the current security model, since it seems to 
bring in a number of new requirements?  To support this, we would need:

1) pre-authorization of camera/mic access
2) authorization continues until a particular active state with the 
server ends (leaving the game)

This could be handled most simply by considering this to be a single 
'call' to the server, which has a default 'forked' instance answered by 
the server with media 'on-hold'.  This 'call' is also forked by the 
server as needed to other players who happen to be nearby/call/etc. 
Since these are forks of an existing call, no individual authorization 
is required (effectively it's the equivalent to a mesh conference where 
users join and leave over time).  The 'call' ends when the user 
terminates the call to the server.

With that sort of setup, I think we can probably handle it within the 
current security model.  The big thing we would need to make sure of is 
making sure forking is available, and that authorization could occur at 
the start with the server, even if the server doesn't want to actually 
receive media.  (In a push, it could receive and drop media.)

As this is all forking of an initial "call", you can handle it with 
normal forking negotiation.  The server would take the two active 
"calls" from the users, and generate a forked "answer" to each.  It does 
point out that each side thinks it made an offer and the other side 
answered.  It requires the server handle the answer generation correctly 
in order to give a proper answer that will match what the device it's 
masquerading as will be ok with.

> to interop with legacy video phones without  needing a media gateway.

I do not see that as the reason for offer-answer semantics; and I don't 
know that we can meet that requirement thus far - and which requirement 
from the use-case document covers this?  What exactly does it require?

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Wed, 19 Oct 2011 03:43:27 -0400

On 10/18/2011 7:40 PM, Ted Hardie wrote:
>
> On Tue, Oct 18, 2011 at 1:43 PM, Hadriel Kaplan <[email-masked]
> <mailto:[email-masked]>> wrote:

I'll come back to where I've been before - Give those who want it access 
to use their own signaling (on top of ROAP at the browser interface), 
and provide a "simple" default signaling mechanism that *can* be used on 
top of ROAP.

Responses to arguments against this:

1) Don't lock us in to a existing protocol because it blocks doing X

    This doesn't lock anyone in; all can use the ROAP interface directly
    and ignore this protocol offered by the browser.

2) If it's baked into the browsers, it will take years to update/bugfix

    A specific service (website/app) can replace the "standard" protocol
    with their updated implementation in JS any time they want - and
    could even serve it only to people running non-updated browsers.

3) It will take forever to design and agree to a new protocol

    A valid, good point.  That would point one to use an existing
    protocol, or a subset of one.

4) It bloats the browser with something no one will use

    I agree it will increase the browser size.  I would disagree that no
    one would use it.

I'll note that such a signaling library in the browser doesn't *have* to 
be required; a browser could offer it, and the service's app could use 
it if available and download a JS version if not.

This (and ROAP, and standard servers for the protocol) would allow the 
infamous "20-line" JS client, without tying anyone's hands.

>>     accessing the Internet via mobile devices which are power and
>>     bandwidth constrained, that sort of wastefulness should not be
>>     trivially dismissed.
>
>     downloading a JS library is difficult, it's unlikely it would be
>     able to handle RTP/RTCP media regardless.
>
>
> keeping it.  The same is true with energy in mobile systems.  Pay
> attention to it all the time, and there's a fair chance you will never
> run out.  Pay attention to it only when you're low, and you're likely
> paying attention to late.

150KB signaling libraries can take time (and energy!) to download; if 
you only have the bandwidth for a narrowband audio call (and rtcweb is 
not just for video!) it could take up to 45 seconds worth of in-call 
bandwidth to download the signaling library alone.  Now, hopefully this 
is cached if it's a service you use a lot, but you can't count on it 
being cached in any particular instance.  Even if you have a 128K 
ISDN-equivalent connection, it's still around 10 seconds just to 
download the library.   Always remember, not everyone has megabit 
bandwidth, or a good wireless connection - and as Ted mentions, even 
those who do are often energy-constrained.  This is even more the case 
in developing countries that may be skipping a lot of the wired 
infrastructure we take for granted.

I'll also note that while browsers are very good at running JS code 
fast, it isn't always the most efficient way to go, and over time is 
less efficient due to repeated re-parsing and re-JIT-ing the same code. 
  A built-in-but-optional protocol would be more efficient both in usage 
(faster is also less energy spent) and in not requiring re-download and 
re-parse/re-JIT.  A major issue? probably not, but a valid consideration.

-- 
Randell Jesup
[email-masked]

---

From: Neil Stratford <[email-masked]>
Date: Wed, 19 Oct 2011 09:33:42 +0100

>   and ignore this protocol offered by the browser.

At this point you are already locked in to a protocol that must fit the ROAP
model, which I see as a problem if you want to build a solutuion that
doesn't look exactly like a traditional RTC system based on SDP o/a.

Neil

---

From: Tim Panton <[email-masked]>
Date: Wed, 19 Oct 2011 11:51:00 +0100

On 19 Oct 2011, at 08:43, Randell Jesup wrote:

> I'll come back to where I've been before - Give those who want it access to use their own signaling (on top of ROAP at the browser interface), and provide a "simple" default signaling mechanism that *can* be used on top of ROAP.
> 
> I'll note that such a signaling library in the browser doesn't *have* to be required; a browser could offer it, and the service's app could use it if available and download a JS version if not.
> 
> This (and ROAP, and standard servers for the protocol) would allow the infamous "20-line" JS client, without tying anyone's hands.
> 
> 150KB signaling libraries can take time (and energy!) to download; if you only have the bandwidth for a narrowband audio call (and rtcweb is not just for video!) it could take up to 45 seconds worth of in-call bandwidth to download the signaling library alone.  Now, hopefully this is cached if it's a service you use a lot, but you can't count on it being cached in any particular instance.  Even if you have a 128K ISDN-equivalent connection, it's still around 10 seconds just to download the library.   Always remember, not everyone has megabit bandwidth, or a good wireless connection - and as Ted mentions, even those who do are often energy-constrained.  This is even more the case in developing countries that may be skipping a lot of the wired infrastructure we take for granted.

True - but those are _exactly_ the environments which _won't_ need all the second order requirements of detailed management of video codecs 
and multiple streams (i.e. the ones that make us 'need' SDP). They will run a single codec (amr-nb presumably) and not negotiate. The signalling 
library for that could be _incredibly_ simple, small and efficient, provided that they don't have to implement a full legacy protocol and can delegate
the hard work to a solar powered webserver elsewhere. 
  
(As an aside, why would you use a PSTN-alike-web app on a GSM phone if you were worried about battery life? 
GSM's power management is going to trounce anything we can do on the VoIP side for some years. 
So this use case requires the _tightest_ possible web integration to justify it)

As a datapoint, phono's xmpp/jingle implementation (including support for 4 different audio backends) is < 100k , It does IM and audio with multiple codecs. I doubt that adding video would tip it over the 100k mark. But that is a full legacy protocol. 
Setting up a basic audio call should be the proverbial 20 lines of javascript - if one uses Neil's low-levelAPI proposal.

> 
> I'll also note that while browsers are very good at running JS code fast, it isn't always the most efficient way to go, and over time is less efficient due to repeated re-parsing and re-JIT-ing the same code.  A built-in-but-optional protocol would be more efficient both in usage (faster is also less energy spent) and in not requiring re-download and re-parse/re-JIT.  A major issue? probably not, but a valid consideration.

Sure, but you have to weigh that benefit against the downsides of picking the _wrong_ protocol. (which I've already ranted about at length)

I take the point that this is an 'built-in-but-optional protocol' - 
but worry about the slippery slope from 'optional' to 'default' to 'only-supported-way' to 'standard' .
How do you propose to  prevent that natural and inevitable progression taking place 
(probably before the first browser ships with it in) ?

---

From: Tim Panton <[email-masked]>
Date: Wed, 19 Oct 2011 12:06:04 +0100

On 19 Oct 2011, at 08:13, Randell Jesup wrote:

> This example you give raises some security issues based on the current proposals.  We require that the user ok access to the camera and microphone; this is a call set up "on the fly" with apparently no individual certification from the user.
> 
> This use-case would require the JS application get pre-authorization of media access, before any actual access occurs, and have that access persist until <something>, across multiple individual connections.
> 
> So is this outside of the current security model, since it seems to bring in a number of new requirements?  To support this, we would need:
> 
> 2) authorization continues until a particular active state with the server ends (leaving the game)

Oh, I thought that there had been some discussion on preserving authorization for a site - so that I can mark a site as
'trusted' and not have to see the permission request again. Without that sort of feature, rtcWEB/webRTC will get annoying _really_ fast.
Once it is 'trusted' the game can create and tear down calls at will, with no need to fork anything.
(I have to authorize each call separately in the current model ?!?)

> 
> This could be handled most simply by considering this to be a single 'call' to the server, which has a default 'forked' instance answered by the server with media 'on-hold'.  This 'call' is also forked by the server as needed to other players who happen to be nearby/call/etc. Since these are forks of an existing call, no individual authorization is required (effectively it's the equivalent to a mesh conference where users join and leave over time).  The 'call' ends when the user terminates the call to the server.
> 
> With that sort of setup, I think we can probably handle it within the current security model.  The big thing we would need to make sure of is making sure forking is available, and that authorization could occur at the start with the server, even if the server doesn't want to actually receive media.  (In a push, it could receive and drop media.)
> 
> As this is all forking of an initial "call", you can handle it with normal forking negotiation.  The server would take the two active "calls" from the users, and generate a forked "answer" to each.  It does point out that each side thinks it made an offer and the other side answered.  It requires the server handle the answer generation correctly in order to give a proper answer that will match what the device it's masquerading as will be ok with.
> 
> I do not see that as the reason for offer-answer semantics; and I don't know that we can meet that requirement thus far - and which requirement from the use-case document covers this?  What exactly does it require?

(sorry, loose terminology - let's call it a desire or wish rather than a requirement).

As I recall (from somewhere on this list) Cullen's draft-jennings-rtcweb-api foundered on the difficulty of specifying video codecs in a way that was
SDP compatible. I'm afraid I can't cite where - a quick search didn't turn it up. If we accepted that video media was always from browser to browser, or
browser to rtcWEB aware proxy that wouldn't be an issue (as far as I can see).

Tim.

---

From: Neil Stratford <[email-masked]>
Date: Wed, 19 Oct 2011 12:33:28 +0100

> attention to it only when you're low, and you're likely paying attention to

The low energy example is a great reason why we wouldn't want a single
standard protocol. In the low energy case you want to move all the smarts
out of the handset and into the server, which requires a different protocol
to the one you'd use for a high power desktop application.

Forcing a handset to implement a protocol that is expressive enough for all
the possible uses on the desktop seems like a bad idea.

Neil

---

From: Randell Jesup <[email-masked]>
Date: Wed, 19 Oct 2011 10:59:46 -0400

Changed title; see below for why.

On 10/19/2011 7:06 AM, Tim Panton wrote:
>> This use-case would require the JS application get pre-authorization of media access, before any actual access occurs, and have that access persist until<something>, across multiple individual connections.
>>

This has not yet been decided; people have certainly talked to wanting 
to find ways to minimize or avoid user authorizations for certain 
classes of services, and I have also pushed such efforts, both here and 
within Mozilla.

However, at this point, no clear solution has been proposed; there are 
several ideas in play (leveraging "installed webapps", etc), but without 
some decision to modify the threat model it's tough.

Without that, the app will probably want to use UI generated by 
getUserMedia() as part of their UI.  That would also mean that the app 
would want to be able to present some indication as to *why* they're 
being asked to enable (incoming caller id, name of application since 
they may have many tabs open, etc), since they don't control the UI for 
getUserMedia() itself.  This is W3C territory, so I'm cc'ing this to 
that list.

-- 
Randell Jesup
[email-masked]

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 20 Oct 2011 05:01:39 +0530

Hadriel,

Please read inline.

Thanks
Partha

>Sent: Wednesday, October 19, 2011 10:41 AM
>Cc: Iñaki Baz Castillo; <[email-masked]>
>Subject: Re: [rtcweb] Gateway need and usecase [was RE: Review request
>forRTCWeb standard signaling protocol]
>
>Hi Partha,
>comments inline
>
>> It is not that I'm interested in RTCWeb gateway but it is the best
>known solution currently. Please look into my earlier mail thread
>(http://www.ietf.org/mail-archive/web/rtcweb/current/msg01058.html) for
>asking not to have gateways and the issues involved in developing
>gateways. But in case two protocols like SIP, websocket are started
>using for the signaling within the same session, the interop is possible
>only with gateways or tunneling wherein I prefer gateway.
>
>I am confused by your statements.  In the email thread you cited above,
>and in your draft, you imply that websocket is a signaling protocol or
>browser-to-browser protocol.  It isn't.  For all intents and purposes of
>this WG, it's a transport.  That's all.  It's like TCP, UDP or SCTP.

<partha> I'm not saying websocket as browser-to-browser protocol. In browser-web server-browser topology, websocket helps to create two-way communication between browsers through web server. So, SDP shall be carried between two browsers using two websocket (browser1 to web server, browser2 to web server) using ROAP sort of protocol. 

In analogy, SIP protocol acts as a transport mechanism for passing SDP between two user agents (UAC & UAS) through proxy/B2BUA. Please note that browser has to no need of maintaining its own identity of the user. You may debate than the point of discussion is media control protocol and not signaling protocol. If so, we will discuss in detail to correct the terminology for common understanding. </partha>

>And it goes between the browser and a web server, not between browsers.
<partha> Yes </partha>

>What's put onto that transport socket is up to the JavaScript and web
>server code.
>
<partha> It is the open item discussion between "low level API" vs. "ROAP API" vs. any other high level API </partha>

>I also don't understand what you mean by "interop is only possible with
>gateways or tunneling".  I don't see how tunneling anything solves
>interop of anything.  
<partha> Here, the topology is browser--web server & SIP-proxy GW----UA. Browser shall tunnel SIP messages over websocket by which web server & SIP-proxy GW entity shall transport the same SIP message to the UA without any gateway functionality. </partha>

But for gateways, yes if everything spoke a
>standard protocol, making gateways would be easier - but it doesn't
>require the RTCWeb<->browser path to speak that signaling protocol; it
>only requires the web-server to speak it.  In fact it might not even
>require that - it might be possible to have a gateway be a JavaScript
>client too.
>

<partha> Let us take the topology of browser---web server & SIP UA GW----UA, browser & web server communication is using some signaling protocol whereas  UA to SIP-UA GW communicates using SIP. Here, I'm interested in ROAP sort of protocol to be standardized by which gateway building is easier. For this requirement, browser has to incorporate ROAP sort of protocol and not custom build signaling. </partha>

>
>> I agree that the primary focus of this WG is to browser-to-browser
>without federation in mind. But the power of collaboration using RTCWeb
>will be realized in case federation protocol are used. For example,
>search for the keyword in Google from the Android browser, go to the
>website, click in the website leads to the call in the call center of
>the website company without involving any PSTN network. Here, website of
>the company acts as a service provider for the company and reduce the
>PSTN/SIP trunk cost drastically.
>

---

From: José Luis Millán <[email-masked]>
Date: Thu, 20 Oct 2011 08:30:21 +0200

Partha,

Reading your earlier mail thread
(http://www.ietf.org/mail-archive/web/rtcweb/current/msg01058.html):

" I'm asking for the single protocol based on my gateway implementation
experience in signaling protocol like SIP, H.323, and basic of MEGACO,
Q.931 (ISDN) etc., My understanding is that mapping of between tow
protocols leads to get the common set in both protocol and under
utilization of specific protocol functionality. The mapping is not
perfect lot of times and one of the example which I know in IETF product
is RFC 3398. It is not possible in RFC 3398 to proper reverse mapping of
cause code for ISUP in case conversion in first gateway converts ISUP to
SIP, second gateway converts is SIP to ISUP, ISUP cause code value in
second gateway is not same what is received in first gateway and this
leads to lot of interop issue which includes passing of reason SIP
header with Q.931 IE recently as per IETF-80 decision (workaround bug
fix). This is not the only mapping failure which I have seen during the
gateway implementation. So, I prefer to look for the strong reason for
putting multiple protocol (SIP, websocket) as a RTCWeb architecture. "

I would like to stract this last phrase:

"So, I prefer to look for the strong reason for
putting multiple protocol (SIP, websocket) as a RTCWeb architecture. "

Still confusing concepts. Many people have already said (I don't think
this is the list where this things have to be explained..) that
WebSocket is used here as a mere transport protocol, not Singalling.

With this misunderstanding of what is being speaking here, how is it
posible this list to have hundreds of emails from you trying to
convince people to do things the way you are benefited?

rtcweb;

I call upon the list moderator to control in some way this behaviour
in favour of the mission of this mailing list.