Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-00

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

2011/10/25 Ravindran Parthasarathi <[e-mail]>:
> I'll take A1-1 requirement of SIP forking wherein it is very much
> possible for RTCWEB-SIP gateway to hide the forking functionality from
> browser and it is normal B2BUA (SBC in market term) functionality in SIP
> wherein originating SIP UA does not support forking properly. IOW,
> please don't add requirement in RTCWeb for the sake SIP interop and it
> is possible to design the better gateway if required.

Please take into account that some of us also desire to interoperate
with SIP but we *don't* need a B2BUA/SBC neither a protocol gateway
for such interconnection (instead we are using *now* a SIP proxy
implementing SIP over WebSocket so the JavaScript application becomes
a real SIP UA).

Having said that, SIP forking is a *feature* rather than a punishment.
It adds complexity of course, but still it's an useful feature. Some
of us want to deal with that complexity at UA level (JavaScript). Some
others would prefer not to allow forking in their RTC-Web scenarios so
have no need to deal with forking. Let's the people choose it.



> I'm looking for
> standard RTCWeb signaling protocol like ROAP by which better solution
> for RTCWeb-federation gateway is documented in IETF.

Yes, you want to mandate some specific in-the-wire signaling protocol
in RTCweb and force me, and others, to use a RTCWeb-SIP gateway box
(regardless I already have my RTCweb solution ready to interop with a
SIP network in the signaling plane without using protocol gateways). I
would ask you to read this draft in which different RTCweb scenarios
are described:

  http://tools.ietf.org/html/draft-sipdoc-rtcweb-open-wire-protocol-00



> Also, I'm interested in hearing about other RTCWeb federation protocol
> like Jingle before doing the deep-dive into the requirement because my
> gut feeling is that we will end-up in multiple federation protocol
> rather than single.

I hope that we will end with *no one* federation protocol so each
website can decide what to use in case it wants to federate with other
website. Web will decide, as it always does. The important point here
is to leave the Web the freedom to choose whichever federation
mechanism. Some mechanism/protocol will success more than others and
will become de facto RTCweb federation protocol in the Web. This is
how things work in the Web.


Regards.


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