Re: [rtcweb] Another consideration about signaling

+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