Re: [rtcweb] Regarding Federation Arguments

Harald Alvestrand <harald@alvestrand.no> Wed, 09 November 2011 12:26 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CCD21F86F6 for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 04:26:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.552
X-Spam-Level:
X-Spam-Status: No, score=-110.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biAOc8b5Ic+D for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 04:26:25 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 656E821F86C3 for <rtcweb@ietf.org>; Wed, 9 Nov 2011 04:26:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B854D39E12B for <rtcweb@ietf.org>; Wed, 9 Nov 2011 13:26:24 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YoxJuHCrMqU for <rtcweb@ietf.org>; Wed, 9 Nov 2011 13:26:21 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id F2FF139E04C for <rtcweb@ietf.org>; Wed, 9 Nov 2011 13:26:20 +0100 (CET)
Message-ID: <4EBA716C.5050004@alvestrand.no>
Date: Wed, 09 Nov 2011 13:26:20 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4EB26D22.5090000@ericsson.com> <FA65A239-CC86-4AC3-8A5A-91B7701C3FB5@cisco.com>
In-Reply-To: <FA65A239-CC86-4AC3-8A5A-91B7701C3FB5@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Regarding Federation Arguments
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Nov 2011 12:26:26 -0000

On 11/09/2011 12:09 AM, Cullen Jennings wrote:
> I don't understand the meaning of the sentence
>
>   This part is outside the scope of the RTCWEB standards
>    suite.
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.
> 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.
>
>
> On Nov 3, 2011, at 4:29 AM, Magnus Westerlund wrote:
>
>> 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: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>