Re: [rtcweb] Signalling, SDP, and the way we think about interconnecting RTCWEB applications

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

2011/10/15 Ted Hardie <[e-mail]>:
> On Fri, Oct 14, 2011 at 2:41 PM, Iñaki Baz Castillo
>>
>> IMHO RTCweb (specially the JS API for managing media sessions) must be
>> designed in a way that it's possible for a developer to implement a
>> SIP client in JavaScript or another custom signaling protocol having a
>> gateway that maps it to/from SIP. This means that SIP features as
>> parallel forking, early media, conference... should be possible using
>> the RTCweb JavaScript API.
>
> Do you think you could support SIP identity with a javascript client?

Yes. The spec (RFC 4474) does NOT mandate that the SIP client MUST to
have a list of CA's and verify the retrieved certificate by itself. A
JavaScript client receiving an incoming INVITE with Identity and
Identity-Info header could make a webservice call (i.e. using AJAX)
and ask its web server to retrieve it and verify it in behalf of the
client. And still that is SIP.

So yes, I could support SIP Indentity with a JavaScript client.


>> So, assuming that there MUST NOT exist a *standard* signaling protocol
>> for federation in RTCweb, what is the purpose of speaking about
>> "federation"?
>
> I don't think RFC 2119 MUST NOTs belong here.
>
> Understanding federation as a use case does not mandate a "one ring to rule
> them all" approach to federation.  We could define one (as XMPP defines how
> different XMPP servers pass traffic among themselves).  That would not
> mandate that all servers use it.  We could also choose not to define one,
> but if we support the use case, we would have to understand what the minimal
> set of data that had to be pass over the protocols implementing the
> federation would be, what security is required, and so on.

So just imagine that SIP is used for federation and make the
requirements assuming that.


>> Probably we all are speaking about the same concept, but
>> for me "federation" means a RTCweb server communicating with other
>> RTCweb server. If Hadriel and you meant "RTCweb server communicating
>> with a SIP network" then I repeat my first paragraph :)
>>
>> So in order to accomplish with requirements of Hadriel we need to make
>> the RTCweb client stack and the RTCweb JavaScript API flexible enough
>> so all (or most of) the SIP features can be implemented in JavaScript
>> (I mean "audio/video features" since all the signaling can already be
>> coded in different ways).
>>
>> Hope it's more clear now.
>>
>
> Well, given that you don't believe in the need for a protocol here at all,

A protocol is needed, of course. But not a *specific* protocol.


> but only an incredibly flexible API, it seems a bit unclear why you're not
> making these points on the W3C public mailing list for this activity.

I expect such work must come once the requirements for such API are
done in this WG.


> A truly well structured API here will imply, at least in my view, at least a
> common model for negotiation and a common set of structured data to be
> passed via this javascript-implemented protocol.  Doing that without
> defining a standard protocol is actually harder than doing it while defining
> a protocol.
>
> I've heard the various arguments against defining one, but none of them
> seems to stand up against the base fact that you can have a standard
> protocol--known to be available--without restricting the ability to create
> proprietary protocols using the same API.

There have been lot of arguments contrary to defining a "default
signaling protocol". I don't want to repeat them again, but neither
answer as if they don't exist.


Regards.


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