Subject: [rtcweb] Regarding Federation Arguments

From: Magnus Westerlund <[email-masked]>
Date: Thu, 3 Nov 2011 11:29:54 +0100

WG,

There has been a number of posts that makes arguments based on
federation and the federation protocol. This is the protocol used
between the webservers, called "Signalling path" in the trappzoid
picture (from draft-ietf-rtcweb-overview-02) below:

                +-----------+             +-----------+
                |   Web     |             |   Web     |
                |           |  Signalling |           |
                |           |-------------|           |
                |  Server   |   path      |  Server   |
                |           |             |           |
                +-----------+             +-----------+
                     /                           \
                    /                             \   Proprietary over
                   /                               \  HTTP/Websockets
                  /                                 \
                 /  Proprietary over                 \
                /   HTTP/Websockets                   \
               /                                       \
         +-----------+                           +-----------+
         |JS/HTML/CSS|                           |JS/HTML/CSS|
         +-----------+                           +-----------+
         +-----------+                           +-----------+
         |           |                           |           |
         |           |                           |           |
         |  Browser  | ------------------------- |  Browser  |
         |           |          Media path       |           |
         |           |                           |           |
         +-----------+                           +-----------+

                      Figure 2: Browser RTC Trapezoid

Please consider that the current WG consensus is well captured in the
overview draft:

   If the two Web servers are operated by different entities, the
   signalling path needs to be agreed upon, either by standardization or
   by other means of agreement; for example, both servers might
   implement SIP, and the servers would talk SIP to each other, and each
   would translate between the SIP protocol and their proprietary
   representation for sending to their application running in the
   browser.  This part is outside the scope of the RTCWEB standars
   suite.

So, it may be SIP, it doesn't need to be SIP. The important from the
WG's perspective is that is a possible deployment model we intended to
support. It is not the only deployment model. We don't define what is
used on the signalling path and there is freedom here.

Please consider that when writing arguments so that you don't
misrepresent the current WG consensus or ignore the set of possibilities
that currently are considered.

If you don't like the WG consensus, then suggest to change it and see if
you get support for it.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 3 Nov 2011 12:23:01 +0100

> used on the signalling path and there is freedom here.

I strongly agree with these conclusions: Freedom in-the-wire and let
the Web to decide.

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

---

From: Ravindran Parthasarathi <[email-masked]>
Date: Thu, 3 Nov 2011 11:48:46 +0000

I agree with the consensus that there is no need to mandate any signaling protocol as Federation protocol for WebRTC. Let Federation protocol be SIP or Jingle or any signaling protocol for that matter. 

I'm interested in asking the folks whether WG will be interested to see the "informational" draft on mapping with WebRTC signaling (ROAP + other mechanism) to standard federation protocol like SIP, Jingle. draft-kaplan-rtcweb-sip-interworking-requirements-00 focus on the interworking with deployed SIP devices. My proposal is to extend the draft to  accommodate other standard federation protocol and also consider the possible other deployment scenario. The intention of the draft is to provide the implementation guidelines for the WebRTC Federation.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Magnus Westerlund
>Sent: Thursday, November 03, 2011 4:00 PM
>To: [email-masked]
>Subject: [rtcweb] Regarding Federation Arguments
>
>WG,
>
>_______________________________________________
>rtcweb mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 3 Nov 2011 13:28:36 +0100

2011/11/3 Ravindran Parthasarathi <[email-masked]>:
> I agree with the consensus that there is no need to mandate any signaling protocol as Federation protocol for WebRTC.

Do you? I could find ~100 mails from you (including a draft and
slides) in which you advocate for the opposite, and not just about the
federation protocol, but also about mandating the in-the-wire protocol
in browser to server communication.

So I celebrate you agree now with the consensus :)

> Let Federation protocol be SIP or Jingle or any signaling protocol for that matter.
>

IMHO given that the consensus is not to define browser-to-server nor
server-to-server protocols, we should focus on remaining items rather
than spending time in informational topics. Or at least, I would wait
until remaining items are more defined (it could help in the document
you have in mind). Of course you are free to write it whenever you
want.

Regards.

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

---

From: Wolfgang Beck <[email-masked]>
Date: Thu, 3 Nov 2011 16:35:28 +0100

The trapezoid federation model has important drawbacks:

- The server-to-server protocol can be too simple: if it doesn't cover
you requirements, you have to wait for standardization. If your
requirement is too specific, it will never be standardized.

- The server-to-server protocol can be too complex: your application
may not need feature x of the protocol (eg forking,
early media), but your software still has to support the complexities
associated with it.

The server-to-server protocol determines the complexity of the server
or JS client. You can let the server translate the server-to-server
protocol into something simpler or let the JS client deal with it. But
you can't escape
the protocol's complexity.

- The server-to-server protocol can even be too simple *and* too
complex at the same time: you don't need feature x's complexities, but
you desperately need feature z. Which is not covered by the standard.

- If there are many providers, the number of server-to-server
relationships -- which are trust relationships -- become unmanageable.
It's quite possible that hubs will emerge to which smaller providers
connect. The hub needs to see all signaling traffic. We're not talking
about a tightly controlled hub in a walled garden, but about Internet
giants who have a commercial interest in profiling user behavior.

Of course, identity providers in the model described in
draft-beck-rtcweb-alt-ic-00 can profile their users, too. They get
less information, though. With client certificates, only the called
RTCWEB provider knows about a call.

Wolfgang Beck

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Nov 2011 16:09:25 -0700

I don't understand the meaning of the sentence 

 This part is outside the scope of the RTCWEB standards
  suite.

I think we need to construct a solution that can work if domains want to federate with SIP - therefore this should be one our use cases. However, I think domain should be free to choose whatever they want to federate - it just needs to be possible to federate. I'd like to see this clarified.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 Nov 2011 16:28:06 -0800

[BA]  I don't understand that sentence either, partly because it's not clear to me what "this" refers to.  The previous sentence talks about "the signaling path needs to be agreed upon, either by standardization or by other means of agreement", but also talks about "their proprietary representation".  Is "this" referring to the former or the latter?   Here's a rewrite that makes more sense (at least to me):  "If the two Web servers are operated by different entities, the inter-domain signalling mechanism needs to be agreed upon, either by standardization or by other means of agreement.  Existing protocols that support federation (SIP or XMPP) could be used to enable inter-domain federation between servers, while either a standards-based or proprietary protocol could be used between the browser and the web server.  For example, if both domains implement SIP,  SIP could be used for inter-domain communication between servers, along with either a standardized signaling mechanism (e.g. SIP over Websockets) or a a proprietary signaling mechanism used between the application running in the browser and the web server.   Similarly, if both domains implement XMPP, XMPP couild be used for inter-domain communication between XMPP servers, with either a standardized signaling mechanism (e.g. XMPP over Websockets or BOSH) or a proprietary signaling mechanism used between the application running in the browser and the web server."   Cullen said: "I don't understand the meaning of the sentence 
 
This part is outside the scope of the RTCWEB standards suite.

I think we need to construct a solution that can work if domains want to federate with SIP - therefore this should be one our use cases. However, I think domain should be free to choose whatever they want to federate - it just needs to be possible to federate. I'd like to see this clarified."
  ============================================================== "If the two Web servers are operated by different entities, the
signalling path needs to be agreed upon, either by standardization or
by other means of agreement; for example, both servers mightimplement SIP, and the servers would talk SIP to each other, and eachwould translate between the SIP protocol and their proprietary
representation for sending to their application running in the
browser.This part is outside the scope of the RTCWEB standars
suite."

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Nov 2011 01:33:24 +0100

2011/11/9 Bernard Aboba <[email-masked]>:
> Here's a rewrite that makes more sense (at least to me):
>
> "If the two Web servers are operated by different entities, the
> inter-domain signalling mechanism needs to be agreed upon, either by
> standardization or by other means of agreement.  Existing protocols that
> support federation (SIP or XMPP) could be used to enable inter-domain
> federation between servers, while either a standards-based or proprietary
> protocol could be used between the browser and the web server.
>
> For example, if both domains implement SIP,  SIP could be used for
> inter-domain communication between servers, along with either a standardized
> signaling mechanism (e.g. SIP over Websockets) or a a proprietary signaling
> mechanism used between the application running in the browser and the web
> server.
>
> Similarly, if both domains implement XMPP, XMPP couild be used for
> inter-domain communication between XMPP servers, with either a standardized
> signaling mechanism (e.g. XMPP over Websockets or BOSH) or a proprietary
> signaling mechanism used between the application running in the browser and
> the web server."

Which basically means the same as saying nothing or "if you want do
whatever you want".

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

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 09 Nov 2011 13:26:20 +0100

>   This part is outside the scope of the RTCWEB standards
Sorry, can you give a better sentence?
The point is

"you won't find the spec for this protocol in the RTCWEB protocol 
specifications, and that's because we want it to not be there".

but that seems a bit too person-oriented to be put into the spec.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 09 Nov 2011 13:37:46 +0100

On 11/09/2011 01:28 AM, Bernard Aboba wrote:
> [BA]  I don't understand that sentence either, partly because it's not 
> clear to me what "this" refers to.  The previous sentence talks about 
> "the signaling path needs to be agreed upon, either by standardization 
> or by other means of agreement", but also talks about "their 
> proprietary representation".  Is "this" referring to the former or the 
> latter?
>
> standardization or by other means of agreement.  Existing
can we avoid using the term "domain" here? It's not used before this 
point. "inter-server" or "inter-entity" would do, since those words are 
already present.
> protocols that support federation (SIP or XMPP) could be used to 
> enable inter-domain federation
That needs to be "for example SIP or XMPP" - if people want to use 
something else, that's up to them.
"Federation" is another term with lots of implied meanings that isn't 
otherwise used in the document.

can we simply say "Existing protocols (for example SIP or XMPP) could be 
used between the servers"?
> between servers, while either a standards-based or proprietary 
> inter-domain communication between servers, along with either a 
> standardized signaling mechanism (e.g. SIP over Websockets) or a a 
> proprietary signaling mechanism used between the application running 
> in the browser and the web server.
>
> inter-domain communication between XMPP servers, with either a 
> standardized signaling mechanism (e.g. XMPP over Websockets or BOSH) 
> or a proprietary signaling mechanism used between the application 
> running in the browser and the web server."

Combined rephrase of the new language:

"If the two Web servers are operated by different entities, the 
inter-server signalling mechanism needs to be agreed upon, either by 
standardization or by other means of agreement.  Existing protocols (for 
example SIP or XMPP) could be used between servers, while either a 
standards-based or proprietary protocol could be used between the 
browser and the web server.

For example, if both domains implement SIP,  SIP could be used for 
communication between servers, along with either a standardized 
signaling mechanism (e.g. SIP over Websockets) or a a proprietary 
signaling mechanism used between the application running in the browser 
and the web server.

Similarly, if both domains implement XMPP, XMPP couild be used for 
communication between XMPP servers, with either a standardized signaling 
mechanism (e.g. XMPP over Websockets or BOSH) or a proprietary signaling 
mechanism used between the application running in the browser and the 
web server."

I'm happy to use the longer paragraph if we can remove the words 
"domain" and "federation" from it; I think it says the same thing as 
what's already there, but if Cullen agrees with Bernard that the words 
are more easily interpreted than mine, let's switch.

>
>
>
> Cullen said:
>
> "I don't understand the meaning of the sentence
>
> I think we need to construct a solution that can work if domains want 
> to federate with SIP - therefore this should be one our use cases. 
> However, I think domain should be free to choose whatever they want to 
> federate - it just needs to be possible to federate. I'd like to see 
> this clarified."
>
>
>
> ==============================================================
>

---

From: Wolfgang Beck <[email-masked]>
Date: Wed, 9 Nov 2011 17:55:59 +0100

On Wed, Nov 9, 2011 at 1:37 PM, Harald Alvestrand <[email-masked]> wrote:
> [on Bernard's comments]
> between servers, while either a standards-based or proprietary protocol
> could be used between the browser and the web server.

My concern about this trapezoid style connection of servers is this:
in order to limit the number protocol translators,
RTCWEB providers will use only a small number of server-to-server
protocols, most likely SIP and Jingle.

This will inevitably have influence on the JS client  / server
protocol design: why bother with innovative features that
don't translate well to SIP and Jingle anyway? Why not just do
Jingle/SIP over Websocket? And the opportunity of RTCWEB will be gone.
We will just see browser-based SIP, Jingle clients with fancy CSS
themes.

This has happened with SIP. As most of the interconnection is done
through the PSTN, we don't see many exciting new SIP applications in
wide use.

It's a pity that the VWRAP people are no longer active in the IETF.
They really had a fresh view on those issues. Their
interconnection requirements where just to complex for the trapezoid
and nobody of them had a limiting telephony background.

Wolfgang Beck

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 09 Nov 2011 18:26:31 +0100

On 11/09/2011 05:55 PM, Wolfgang Beck wrote:
> On Wed, Nov 9, 2011 at 1:37 PM, Harald Alvestrand<[email-masked]>  wrote:
>> [on Bernard's comments]
Please!!!!!!!!!!!

The trapezoid is ONE possible deployment scenario.
As the overview document says:

    A commonly imagined model of deployment is the one depicted below.

It is neither the only possible one nor even a recommended one. It is 
just commonly imagined.

If you want innovative applications ..... go innovate, and come back 
when you know *exactly why* something in the specs gets in your way!

> and nobody of them had a limiting telephony background.
Without pointers to docs, I can't evaluate this statement. Be specific!

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 9 Nov 2011 20:37:47 +0100

> through the PSTN, we don't see many exciting new SIP applications in

I don't fully understand why some SIP folks try to "export" the SIP
trapezoid model to WebRTC taking into account that such trapezoid has
never succeeded in pure SIP networks.

Anyhow, reading the last mails in this thread... what are we
discussing about? IHMO all of us (at least in this thread) agree on
the fact that mandating/defining a server-to-server interconnection
model is a no-go. Is it just about the exact text for the draft? It's
easy, just say "two WebRTC sites can federate by using any mechanism
they desire for such interconnection. It could be pure SIP, XMPP or
whatever protocol/mechanism they agree."

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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 10 Nov 2011 11:06:40 +0000

It is a bad situation to implement "n" protocols in Gateways for federation 
as there is no standard to refer. Atleast in case of IP telephony, there is 
a convergence that SIP will be used as a de-facto protocol (no H.323/Megaco). 
It is really tough to manage in case there is no guidelines for RTCWeb server.

As I earlier mentioned, there is no need to mandate any specific protocol but
Guidelines is important. Also, I agree with your earlier mail that Federation work
item may not require to be completed in the normal WebRTC time-to-market manner.

Thanks
Partha

>Of Iñaki Baz Castillo
>Sent: Thursday, November 10, 2011 1:08 AM
>To: Wolfgang Beck
>Cc: <[email-masked]>
>Subject: Re: [rtcweb] Regarding Federation Arguments
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 10 Nov 2011 17:32:56 +0100

> It is really tough to manage in case there is no guidelines for RTCWeb server.

Hi Ravindran, WebRTC is not SIP nor a protocol to be mapped to SIP.
It's something different which "could" offer features similar to SIP
or a really different experience.

A WebRTC scenario could offer just multiconference calls (let's say a
poker game in which every participant talk and listens to all the
participants), or could offer just video calls, or just audio. This is
not about legacy telephony anymore, so there is no chance to make a
"guideline" for interoperability between WebRTC and SIP. Of course
some WebRTC scenarios could offer capabilities like VoIP so
interoperability with SIP networks would make sense, but we should not
assume that this is the main purpose of WebRTC.

IMHO we should stop talking about SIP in this WG.

> item may not require to be completed in the normal WebRTC time-to-market manner.

I agree. The document you propose could be useful for some scenarios,
sure, but it should not make the WG to spent time on it for now. First
priority is to define WebRTC regardless federation with other specific
networks.

Regards.

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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 11 Nov 2011 05:20:43 +0000

Inaki,

Please read inline

Thanks
Partha

>From: Iñaki Baz Castillo [mailto:[email-masked]]
>Sent: Thursday, November 03, 2011 5:59 PM
>To: Ravindran Parthasarathi
>Cc: Magnus Westerlund; [email-masked]
>> I agree with the consensus that there is no need to mandate any
>signaling protocol as Federation protocol for WebRTC.
>
<partha> I thought that you would have clear after looking at my slide 
on the last RTCWeb call wherein providing the standard mechanism vs low level 
mechanism. IMO, your Low (freedom) based level API and standard on-wire 
protocol are complementary because both serve two different purpose.
Freedom based API helps to build SIP over websocket kind of application or
Proprietary Facebook or Google based WebRTC mechanism.
But standard on-wire (say ROAP over JSON) helps folks not to look into
Protocol intricacies in the browser. It is very much possible to co-exist. 
I really don't where is your concern </partha>

>So I celebrate you agree now with the consensus :)
<partha> Good that we have some common understanding after the long discussion
 </partha>
>> I'm interested in asking the folks whether WG will be interested to
>see the "informational" draft on mapping with WebRTC signaling (ROAP +
>other mechanism) to standard federation protocol like SIP, Jingle.
>draft-kaplan-rtcweb-sip-interworking-requirements-00 focus on the
>interworking with deployed SIP devices. My proposal is to extend the
>draft to  accommodate other standard federation protocol and also
>consider the possible other deployment scenario. The intention of the
>draft is to provide the implementation guidelines for the WebRTC
>Federation.
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Nov 2011 08:11:14 +0100

Hi,

>So I celebrate you agree now with the consensus :)

I would appretiate if we don't use the word "consensus", unless it has actually been declared by the WG chairs.

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 11 Nov 2011 19:44:17 +0800

+1

Iñaki Baz Castillo said:
> 
> WebRTC is not SIP...
> 
> IMHO we should stop talking about SIP in this WG....

> First priority is to define WebRTC regardless of federation...

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 11 Nov 2011 17:41:10 +0100

El 11/11/2011 06:23, "Ravindran, Parthasarathi" <[email-masked]>
escribió:
>
>  IMO, your Low (freedom) based level API

I've never proposed an API.

> and standard on-wire
> I really don't where is your concern

This is the very same argument again. IMHO it is time for you to assume
that this WG has decided by consensus that there will be no standard
in-the-wire protocol in WebRTC, nor a suggested proposal by this WG.

IMHO the only reason for having a "standard" WebrTC signaling protocol is
to make a business for gateway vendors building "standard WebRTC-to-SIP
gateways". I cannot imagine other reasons. That is not a legitime argument
in a IETF specification.

Anyhow I will not discuss again about this subject. There is consensus.
Time to move on. Please spend your time in helping with open subjects
rather than trying to reopen the discussion about the standard protocol.

Regards.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 11 Nov 2011 17:48:28 +0100

Hi, I expected that this means consensus:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg02509.html

Regards.
El 11/11/2011 08:13, "Christer Holmberg" <[email-masked]>

---

From: Dan York <[email-masked]>
Date: Fri, 11 Nov 2011 13:24:11 -0500

+1

-- 
Dan York  [email-masked]
http://www.danyork.com/   skype:danyork
Phone: +1-802-735-1624
Twitter - http://twitter.com/danyork
--------------------------------------------------------
All comments and opinions are entirely my own and have no connection whatsoever to any employer, past or present. Indeed, by tomorrow even I might be disavowing these comments.
--------------------------------------------------------

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Nov 2011 20:16:25 +0100

Hi,

> http://www.ietf.org/mail-archive/web/rtcweb/current/msg02509.html

That e-mail is about browser-to-server protocol. I thought you were talking about a server-to-server protocol. My appologies if I missunderstood.

Regards,

Christer

Regards.

El 11/11/2011 08:13, "Christer Holmberg" <[email-masked]<mailto:[email-masked]>> escribió:

Hi,

Regards,

Christer

---

From: Erik Lagerway <[email-masked]>
Date: Fri, 11 Nov 2011 19:07:31 -0800

Yes, I agree. SIP should take a back seat in this WG, as should jingle etc.

---

From: Ted Hardie <[email-masked]>
Date: Sun, 13 Nov 2011 01:04:49 -0800

I must ask you not to call consensus for this working group. If you feel
strongly that a matter has reached consensus, contact the chairs and
discuss with us the timing.

Ted Hardie

---

From: Neil Stratford <[email-masked]>
Date: Sun, 13 Nov 2011 09:26:17 +0000

+1

On Sat, Nov 12, 2011 at 3:07 AM, Erik Lagerway <[email-masked]> wrote:

> <[email-masked]>[email-masked]
> Dan York   <[email-masked]>[email-masked]
> <http://www.danyork.com/>http://www.danyork.com/   skype:danyork
> Phone: +1-802-735-1624
> Twitter -  <http://twitter.com/danyork>http://twitter.com/danyork
> All comments and opinions are entirely my own and have no connection
> whatsoever to any employer, past or present. Indeed, by tomorrow even I
> might be disavowing these comments.

---

From: Tim Panton <[email-masked]>
Date: Sun, 13 Nov 2011 11:48:26 +0000

+1
(as if you hadn't guessed)