Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion
Iñaki Baz Castillo <ibc@aliax.net> Thu, 20 October 2011 11:45 UTC
Return-Path: <ibc@aliax.net>
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 098F421F8AFF for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 04:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.627
X-Spam-Level:
X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 USDczyI5Mokj for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 04:45:30 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F082021F8AE6 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 04:45:29 -0700 (PDT)
Received: by vws5 with SMTP id 5so2309564vws.31 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 04:45:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.25.75 with SMTP id a11mr10377672vdg.1.1319111127139; Thu, 20 Oct 2011 04:45:27 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Thu, 20 Oct 2011 04:45:27 -0700 (PDT)
In-Reply-To: <4EA0025E.6080604@alvestrand.no>
References: <CA+9kkMBQDne_p7LmH_e38NQWqjjNh0jKjuLMZrtNh10db90hYg@mail.gmail.com> <4E9E9794.8000901@alvestrand.no> <4E9FD139.2010406@ericsson.com> <CALiegfkbdXLf2E38i8ELSCsD6JOUJnWMasQuYK13BhzBwji2_Q@mail.gmail.com> <4EA0025E.6080604@alvestrand.no>
Date: Thu, 20 Oct 2011 13:45:27 +0200
Message-ID: <CALiegfnZTQWPQCsvycn1UBamUuURrRm536Cuvfq_Qou_q9NuPQ@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion
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: Thu, 20 Oct 2011 11:45:31 -0000
2011/10/20 Harald Alvestrand <harald@alvestrand.no>: > While I may quibble with Inaki about the terminology he proposes, I think I > support what he's driving at in the "components" Web page. > > In the -overview-02 draft section 7, the term "media negotiations" is used > for what he calls "media signalling"; it is trying to get at the same > distinction. > > In his category of "info signalling", I would quibble a bit in that I see > "channel-related signalling" (a term I just invented, describing which media > is sent on which SSRC on which port) as distinct from "identity-related > signalling", where the whole question of "who am I talking to" is relevant. Hi Harald, the terms I propose are just suggestions. I just wanted to identify the different "signaling" components, how to name them is just a matter of taste and I agree that your suggested names could be just better. :) As a suggestion, I think that the overview draft could include and explain those terms so all the WG can refer to the standard names and avoid confusion. > I believe "channel-related signalling" needs to be treated together with > "media signalling". That's indeed the usual approach: the "channel-related signalling" acts as a transport layer for the "media signalling". This is true in SIP, XMPP and any other VoIP protocol. The point here is: If we assume that "channel-related signalling" carries "media signalling" (as everybody agree I hope), what would entail mandating a RTCweb default signaling protocol? It would mean that we define/mandate both signalings (the format of the in-the-wire messages), and that means that a website developer is not free anymore to design his own message format and message exchange mechanism/protocol. This is not just about the "media signaling" but also about the "channel-related signalling". We cannot mandate that because WWW already allows each developer to decide his messages and protocol, and we don't know the requirements of all the websites (and future websites) in the world, so we cannot create and mandate a singaling protocol which fulfills every needs. We cannot assume that every RTC communication involves a single "From" and a single "To", we cannot assume that the hypothetical user_id format (to identify the destination user) is valid for all the websites, neither we can assume that every RTC communication has a specific "user" destination. IMHO RTCweb (and W3C) should be limited to define: - A JavaScript API to manage media sessions (communication between custom JS and the browser). If this involves state values then let's call it a "protocol". ROAP accomplishes with this. - Media related stuff (RTP, SRTP, codecs management, ICE, RTP security/validation...). How the "channel-related signalling" and the "media signaling" is carried in-the-wire should not be defined (IMHO) because it adds dangerous constrains and it's against the spirit of the WWW world (in which the lack of constrains is the key of its success). We cannot go to Facebook and say "if you want to add RTCweb in your website you must create user identifiers in this exact format, authentication must be done in this way, you can add to the message request just these fields...", that is a no-go. As shown in other thread, currently Facebook JS sends the following HTTP POST when a user sends a IM to other user in Facebook: --------------------- POST /ajax/chat/send.php?__a=1 HTTP/1.1' Host: www.facebook.com' User-Agent: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv:10.0a1) Gecko/20111017 Firefox/10.0a1' Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' Accept-Language: en-us,en;q=0.5' Accept-Encoding: gzip, deflate' DNT: 1' Connection: keep-alive' X-SVN-Rev: 460802' Content-Type: application/x-www-form-urlencoded; charset=UTF-8' Referer: http://www.facebook.com/?sfrm=1' Content-Length: 399' Cookie: datr=ZuyfTjurvmsqvYVBDcXF8u; c_user=104442654509775; L=2; lu=RgQytVtJJBQSvWUNOYzs0oQg; sct=1319153603; xs=60%3A1c179a6dfb7f08277477b20e778bd391; p=112; presence=EM319103631L212REp_5f1B04654409875F4EriF0CEstateFDutF1319103633096EvisF1H0EblcF0EsndF1ODiFA21B02602687525A2C_5dEfFA21B02602687525A2EuctF1319103618EsF0CEblFD55F1G319103604PEuoFD1B02602687525FDexpF1319103680370EflF_5b1_5dEolF0CCEalFD1B02602687525FDiF0EmF0CCCC; wd=1366x675' Pragma: no-cache' Cache-Control: no-cache' ' msg_id=1319103647568%3A3620978310&client_time=1319103646048&to=100002772687525&num_tabs=1&pvs_time&msg_text=hello&to_offline=false&to_idle=false&window_id=2877189837&sidebar_launched=true&sidebar_enabled=true&sidebar_capable=true&sidebar_should_show=false&sidebar_visible=false&post_form_id=449eb730c851e127f21d8a88b6a00667&fb_dtsg=AQC3StlW&lsd&post_form_id_source=AsyncRequest&__user=100002654409995 --------------------- Who will tell Facebook that it cannot use a similar message for RTCweb audio/video request and instead Facebook must use a specific request format with specific and limited fields? Not me :) Best regards. -- Iñaki Baz Castillo <ibc@aliax.net>
- Re: [rtcweb] Friday Call details for signaling di… Harald Alvestrand
- [rtcweb] Friday Call details for signaling discus… Ted Hardie
- [rtcweb] Friday Agenda: Re: Friday Call details f… Magnus Westerlund
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Iñaki Baz Castillo
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Harald Alvestrand
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Iñaki Baz Castillo
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Iñaki Baz Castillo
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Harald Alvestrand
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Magnus Westerlund
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Magnus Westerlund
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Wolfgang Beck
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Matthew Kaufman
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Bernard Aboba
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Harald Alvestrand
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Hadriel Kaplan
- Re: [rtcweb] Friday Agenda: Re: Friday Call detai… Christer Holmberg