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

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

2011/10/14 Ted Hardie <[e-mail]>:
> Not speaking for Google, but I have no idea what you mean by "pure Internet
> world" here.

"Pure Internet" is just Internet, and that is not a private network or
a telco IP infrastructure. I just meant that.


> I'm also not really clear what your aim is.  Hadriel has said
> that the overall system must be designed such that it is possible to use SIP
> as a federation protocol, but that it should not be restricted so that only
> SIP can be used as a federation protocol.  Perhaps if you responded to his
> point on this issue, the rest of your comments might seem more clear.

Ok, let me try again:

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. I think we agree here :)

So, assuming that there MUST NOT exist a *standard* signaling protocol
for federation in RTCweb, what is the purpose of speaking about
"federation"? 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.

Best regards.




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