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

[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?



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




> 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,
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.

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.

regards,

Ted