[rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-rtcweb-sip-interworking-requirements-00]

["Ravindran Parthasarathi" <[e-mail]>]

By looking at draft-ietf-rtcweb-use-cases-and-requirements-06, I could not see any specific requirement for RTCWeb forking. In case SIP forking is the only requirement for RTCWeb and also, RTCWeb does not have any specific forking requirement, then the gateway between RTCWeb & SIP shall take care of the functionality. I'm asking this question to get the clarity on whether SIP forking feature has to impact RTCWeb client requirement or not. 

Thanks
Partha

>-----Original Message-----
>From: Iñaki Baz Castillo [mailto:[e-mail]]
>Sent: Tuesday, October 25, 2011 2:09 PM
>To: Ravindran Parthasarathi
>Cc: Hadriel Kaplan; [e-mail]
>Subject: Re: [rtcweb] draft-kaplan-rtcweb-sip-interworking-requirements-
>00
>
>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]>