Re: [rtcweb] Another consideration about signaling

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

2011/10/10 Kevin P. Fleming <[e-mail]>:
> That's correct; the only reason I brought it up is that the choice of SIP as
> the RTCWEB signaling protocol, or something else, does not impact this at
> all. Choosing Jingle does not make this easier for the web application
> developer, and choosing SIP does not make it harder... in either case, they
> either *are* the signaling endpoint at the server end, or they aren't.
> Originally you had stated that if SIP was chosen, it would make this sort of
> application harder to build, because the application would not be likely to
> implement a SIP UA itself, and so it wouldn't have access to the session
> state information.

Not exactly, I meant that, in case the browser speaks *native* SIP
with a centralized SIP proxy, then it would be hard to get sessions
information in the web server (as it would require some custom and
complex communication with the SIP proxy). The same if it's a XMPP
server or whatever.

But if the signaling is carried via HTTP or WebSocket, the siteadmin
can choose to pass all the signaling through the web server so it
would be fully aware of the sessions status.

So I meant the server rather than the client. The client, of course,
must know the sessions he is involved in :)



> I'm not advocating that SIP be chosen... but for entirely different reasons

The fact is that nobody advocates for a specific signaling protocol
(well, just a person which insists and insists...). We need no default
signaling protocol at all, but just freedom for each siteadmin to
provide the signaling protocol it desired (of course, it should be
carried via HTTP or WebSocket, as those protocols are the ones that a
webbrowser can speak being controlled via JavaScript).


Regards.


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