[rtcweb] Another consideration about signaling

[Iñaki Baz Castillo <[e-mail]>]

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
<[e-mail]>