Subject: [rtcweb] Another consideration about signaling

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 16 Sep 2011 17:42:13 +0200

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
<[email-masked]>

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 16 Sep 2011 15:56:48 -0500

+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).

>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

> 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
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
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
(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
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
<[email-masked]>
_______________________________________________
rtcwe
> b mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Dzonatas Sol <[email-masked]>
Date: Fri, 16 Sep 2011 14:10:32 -0700

> that creative developers may assemble into rich apps.

Let JSON be the default for websockets, and we can call those lambda 
expressions.

>
> On 9/16/11 10:42 AM, "I�aki Baz Castillo"<[email-masked]>  wrote:
>
>    
>> Hi all,
>>      

-- 

---
<i>The wheel.</i metro-link=t dzonatasolyndra>