Re: [rtcweb] Another consideration about signaling

Henry Sinnreich <henry.sinnreich@gmail.com> Fri, 16 September 2011 20:54 UTC

Return-Path: <henry.sinnreich@gmail.com>
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 33ACB21F8D1D for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 13:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_BACKHAIR_43=1, 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 z98nlcCT1CTz for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 13:54:40 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBD721F8D1B for <rtcweb@ietf.org>; Fri, 16 Sep 2011 13:54:40 -0700 (PDT)
Received: by gxk19 with SMTP id 19so3849701gxk.31 for <rtcweb@ietf.org>; Fri, 16 Sep 2011 13:56:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=sPL/66yFnMshM9MpCWgBP5U13m85ioJk9ze+VLmCJUc=; b=LWq/s7fQCDWDSKJnwRAIqYNwmVKnsRMS9SfQRDZ28WS5qc9Fa+Ij85DN+glHNV+/Oc KlAQaaphwjwZJ88yFuTRQPpwaFKeUoNlNjBbrFKUINZhFo/7CWPJEVIzI8fcq6DJIkgv 6+KE/lD5IQXTf0QIPwoG5Cjq6XWea29t8Otgg=
Received: by 10.236.183.170 with SMTP id q30mr14781825yhm.42.1316206613141; Fri, 16 Sep 2011 13:56:53 -0700 (PDT)
Received: from [192.168.15.2] (cpe-76-184-249-163.tx.res.rr.com. [76.184.249.163]) by mx.google.com with ESMTPS id f63sm8895391yhj.14.2011.09.16.13.56.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Sep 2011 13:56:51 -0700 (PDT)
User-Agent: Microsoft-Entourage/12.30.0.110427
Date: Fri, 16 Sep 2011 15:56:48 -0500
From: Henry Sinnreich <henry.sinnreich@gmail.com>
To: =?ISO-8859-1?B?SfFha2k=?= Baz Castillo <ibc@aliax.net>, <rtcweb@ietf.org>
Message-ID: <CA992240.1D961%henry.sinnreich@gmail.com>
Thread-Topic: [rtcweb] Another consideration about signaling
Thread-Index: Acx0syZzLo57rL1lF0KNa/24X9wTtQ==
In-Reply-To: <CALiegfmoPWfhtBRiOfgLHG1uhJK_kK2t11xMoop-fT6qW4DUJQ@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Subject: Re: [rtcweb] Another consideration about signaling
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: Fri, 16 Sep 2011 20:54:41 -0000

+1

These are indeed critical items to consider

>if the signaling is implemented within HTTP or WebSocket (by using
>any custom mechanism), it would be easy for the web server to know the active
>sessions status in detail, and it could use such a information for rendering
>it in the webpage (so others web visitors can see the status of my calls, for
>example).

>I just see advantages in *non* mandating a separate and specific
>signaling protocol within rtcweb, even more taking into account
>that this is supposed to be an added value for the web. This is: a
>web-browser MUST NOT be a native SIP phone (IMHO).

Though I would add the "other web visitors" may well be other app components
that creative developers may assemble into rich apps.

Thanks, Henry


On 9/16/11 10:42 AM, "Iñaki Baz Castillo" <ibc@aliax.net> wrote:

> Hi all,

Let's imagine that rtcweb defines a specific signaling protocol
> (i.e.
SIP) so browsers MUST use it natively for signaling the media
> streams.
Of course this would require a SIP proxy/server in server side
> (think
about NAT) which IMHO seems a showstopper (how to deploy such a
> SIP
proxy in shared web hostings? a "mod_sip" for Apache? should I make
> a
XMPP<->SIP protocol gateway in order to intercommunicate web-browsers
with
> pure XMPP clients?)

But there is another important drawback with this
> assumption:

A web site could be interested in drawing in the web the status
> of the
different audio/video streams between users connected to the web.
> This
could mean displaying in the web the active streams (audio/video),
when a
> session is on hold, when it's resumed again, when a new stream
is added to a
> multimedia session (i.e. offering video within an
already established audio
> session).

If the signaling uses a separate channel (i.e. SIP) then there is
> no
way for the web server to know what happens during multimedia sessions
(or
> it would be really difficult to achieve). So multimedia sessions
would be
> completely separated from the web page itself. Is that what
we want?

In the
> other side, if the signaling is implemented within HTTP or
WebSocket (by using
> any custom mechanism), it would be easy for the
web server to know the active
> sessions status in detail, and it could
use such a information for rendering
> it in the webpage (so others web
visitors can see the status of my calls, for
> example).

I just see advantages in *non* mandating a separate and
> specific
signaling protocol within rtcweb, even more taking into account
> that
this is supposed to be an added value for the web. This is: a
web-browser
> MUST NOT be a native SIP phone (IMHO). I wouldn't like to
see a competition
> between Firefox 12 and Chrome 17 in next SIPit
(Session Initiation Protocol
> Interoperability Test).

Best regards.

-- 
Iñaki Baz
> Castillo
<ibc@aliax.net>
_______________________________________________
rtcwe
> b mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb