Re: [rtcweb] Another consideration about signaling

["Kevin P. Fleming" <[e-mail]>]

On 10/08/2011 04:51 PM, José Luis Millán wrote:
> 2011/10/8 Kevin P. Fleming<[e-mail]>:
>> On 10/08/2011 04:02 AM, José Luis Millán wrote:
>>>
>>> Kevin,
>>>
>>> 2011/10/7 Kevin P. Fleming<[e-mail]>:
>>>>
>>>> On 09/16/2011 10:42 AM, Iñaki Baz Castillo 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).

> Sorry if I'm not underdstanding you well. I understand from the
> paragraph above that the client may use these APIs to consult the
> server about it's own state (client's state).
>
> The web application does not need to monitor the signalling, but will
> be aware of its own state (sessions..) by simply relying on the
> signalling API. ie: Client executes the 'call' method of the API 'X',
> this method executes the corresponding callbacks according to the
> state of the running call: 'trying', 'ringing', 'ok'. This way the
> client is aware of its own state.
>
> If this is not what you meant, could you please clarify?

I interpreted the paragraph above from Inaki's post very differently, so 
I'll try to describe it more concretely.

Imagine we have users Alice, Bob and Charlie, all of who are using a web 
application called XYZ that utilizes RTCWEB functionality to allow 
communication between its users. The XYZ application has two major 
components: a set of Javascript/HTML that it pushes out to the browsers, 
and a set of code (language/platform is irrelevant) that runs on the 
server that pushed the code out, and communicates with that JavaScript code.

When the XYZ application's Javascript wants to setup sessions to other 
users of the application it uses the local WebRTC APIs to access the 
browser's interfaces for media, and uses *some* sort of signaling 
protocol over HTTP/WebSocket to establish the sessions through the XYZ 
application server. This could be SIP, Jingle, or something else entirely.

In order for XYZ's Javascript running in Alice's browser to display the 
state of *her* sessions with the XYZ application, the Javascript doesn't 
need any help; it already knows what sessions it has established and 
their states. The signaling protocol is irrelevant here. If the XYZ 
application server implements the chosen signaling protocol itself, then 
it *also* knows the states of these sessions, and by extension it knows 
the states of all the other sessions that XYZ application users are 
involved in.

If the XYZ application wants to display in Alice's browser the states of 
other sessions that Alice is not involved in (this is what I believe 
Inaki was referring to above), then it can use this information that it 
has (by virtue of implementing the signaling protocol itself) in order 
to push information out to her browser for it to display.

The situation changes quite a lot if the XYZ application server does 
*not* implement the signaling protocol itself, though. If it just acts 
as a conduit for that signaling to be sent between the browser and a 
'communications server' of some type (I suspect this will be a very 
common deployment model, as web application developers aren't going to 
want to shoehorn an entire communications server into their web 
application containers if they can avoid it), then it doesn't know the 
state of any of these sessions at all; it just knows that it has seen 
session signaling messages going back and forth.

In this situation, if the XYZ application wants to display the states of 
other sessions, it will have to have some API between itself and the 
communications server (the browser is not involved here) in order to 
monitor (and potentially control) those sessions. This allows the web 
application developer to be completely insulated from the signaling 
protocol that is used, and instead just use an API provided by the 
communications server in order to track and control communications 
sessions. Thus, the choice of signaling protocol is irrelevant, as long 
as a hypothetical web application developer can find and use a suitable 
communications server that implements the chosen protocol *and* provides 
adequate APIs for the web application to fulfill its requirements.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [e-mail] | SIP: [e-mail] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org