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

José Luis Millán <jmillan@aliax.net> Tue, 20 September 2011 12:33 UTC

Return-Path: <jmillan@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 156A721F8C4D for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 05:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 C4BYQculUhXC for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 05:33:28 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 16BC621F8C45 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 05:33:28 -0700 (PDT)
Received: by iaby26 with SMTP id y26so720405iab.31 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 05:35:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.0.221 with SMTP id 29mr1223440ibc.56.1316522079854; Tue, 20 Sep 2011 05:34:39 -0700 (PDT)
Received: by 10.231.36.201 with HTTP; Tue, 20 Sep 2011 05:34:39 -0700 (PDT)
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF510F0E12@sonusinmail02.sonusnet.com>
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <16880306-5B3A-4EFD-ADE4-1201138D9182@acmepacket.com> <8584590C8D7DD141AA96D01920FC6C698C896B71@gbplmail03.genband.com> <CA+9kkMAwnnKKO5+q6ey4Z0QNxax1QF21vVtw8FNsHy_rmfenjQ@mail.gmail.com> <4E76E078.5020708@jesup.org> <8548CBBD-4E12-48F3-BC59-341FF45EF22F@acmepacket.com> <4E77495E.4000409@jesup.org> <CALiegfkTdCAeEdZbXP1Y9L6i4Anjrgf1CG6ZNj35WGoHL3p_Ew@mail.gmail.com> <4E774F92.4040405@jesup.org> <8ECCEE59-E855-4EA9-92B9-543D1585B1F0@ag-projects.com> <4E778F1F.9090105@jesup.org> <CEA0AC9E-6387-4066-95DC-0D70302E80A7@ag-projects.com> <4E77C3EC.9060801@jesup.org> <CAD5OKxtciYxaVpb7b3G9yMg1A97b9dkjkOpppZcSRzS5SAO3+A@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0DD8@sonusinmail02.sonusnet.com> <CALiegfkCrusXTrJt9ez4CkYNBUR4s8MDD75KsjexS0z-c=uPZA@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0E12@sonusinmail02.sonusnet.com>
Date: Tue, 20 Sep 2011 14:34:39 +0200
Message-ID: <CABw3bnNR_s2Y8UjQNA8xHmdB6Ds7-sWxVYq05MWOG-LgkaOR6g@mail.gmail.com>
From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= <jmillan@aliax.net>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
Content-Type: multipart/alternative; boundary=00151773d3d2e8a1a004ad5eae22
Cc: Randell Jesup <randell-ietf@jesup.org>, rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
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: Tue, 20 Sep 2011 12:33:29 -0000

Hello,

2011/9/20 Ravindran Parthasarathi <pravindran@sonusnet.com>;

> Hi Inaki,
>
> I have answered to you in the another thread (
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg01172.html).  I
> understand that there are lot of thread, So you might have confused.


To be honest, I'm also confused. You opened two new threads to respond to
Saúl and Tim respectively from the original one.


>  As I indicated in the earlier mail, I'll come up with the write up to
> discuss the need for "RTCWeb default signaling protocol".


That`s OK. Let's read it and discuss about it then.



> Please note in the mail thread that there is no mention of SIP as a RTCWeb
> default signaling protocol. The argument is between "nothing" vs "default"
> signaling protocol.
>

Up to now, that 'default' you mean is not even a formal proposal.


Thanks


> SIP or XMPP based protocol will be selected as a default protocol based on
> technical merit of a given RTCWeb signaling problem but it is a second
> stage.
>
> Thanks
> Partha
>
> >-----Original Message-----
> >From: Iñaki Baz Castillo [mailto:ibc@aliax.net]
> >Sent: Tuesday, September 20, 2011 1:39 PM
> >To: Ravindran Parthasarathi
> >Cc: Roman Shpount; Randell Jesup; rtcweb@ietf.org
> >Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About
> >defining a signaling protocol for WebRTC (or not)]
> >
> >2011/9/20 Ravindran Parthasarathi <pravindran@sonusnet.com>;:
> >> One of the main aim of the RTCWeb default signaling protocol is to
> >make two
> >> party real-time communication easy with less development effort for
> >any web
> >> developer.
> >
> >Hi, let me some comments please:
> >
> >1) "RTCWeb default signaling protocol" is not defined neither it
> >exists. I would ask you for not talking about it as if it was already
> >approved since that could become confusing for readers. Also, given
> >other threads it's clear that most of the people here is contrary to a
> >"RTCWeb default signaling protocol" or "SIP built-in the browser".
> >They have also given good rationale across multiple threads.
> >
> >2) If browsers speak pure SIP then the server side MUST also speak
> >SIP. How to accomplish with that in shared web hostings? Must the web
> >admins learn about SIP and installing/configuring a
> >OpenSER/Kamailio/OpenSIPS/SER SIP proxy/registrar? This question has
> >been made several times in some threads. No reply yet (same occurs
> >with other given arguments).
> >
> >3) Making the signaling path a separate flow means that the web server
> >(so the web application in server side) would not be aware about
> >sessions status. So if for example two users visit the same page and
> >speak through their web browsers and later one of them logouts from
> >the web, the server has no easy way to force the call termination.
> >Neither a "forum-administrator" could reject an spammer from an audio
> >conference room (or it would be hard to accomplish). In contrast, if
> >the signaling is carried via HTTP/WebSocket, the logic is centralized
> >and the server application would be aware of existing sessions.
> >
> >
> >Best regards.
> >
> >
> >--
> >Iñaki Baz Castillo
> ><ibc@aliax.net>;
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>