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

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

Harald,

Thanks for the clarification. "Fedex IVR" usecase is under browser to GW/server section (sec 4.3) which is a SIP based forking requirement. If you look at carefully, "Fedex IVR non-final response" scenario could have be achieved cleanly using two separate offer/answer exchange & two final responses (INVITE/200/ACK, RE-INVITE/200/ACK) :

1) customer - fedex IVR offer/answer exchange
2) fedex agent - Customer offer/answer exchange

but it may be avoided in legacy for billing reasons which should not be major concern for RTCWeb. In case of SIP forking, it is assumed that 2nd answer override the 1st answer in the media plane.

As I mentioned earlier, SIP (serial) forking requirement shall be met by gateway signaling and no extra requirement for browser. Also, switching media stream from one responder to other responder in Fedex IVR usecase is not so easy because of legacy media handling (ICE, RTCP) differences as mentioned in draft-kaplan-rtcweb-sip-interworking-requirements-00.

ISTM, we don't have RTCWeb specific forking usecase till now.

Thanks
Partha 
 
>-----Original Message-----
>From: Harald Alvestrand [mailto:[e-mail]]
>Sent: Friday, October 28, 2011 11:58 PM
>To: Ravindran Parthasarathi
>Cc: Iñaki Baz Castillo; [e-mail]; Hadriel Kaplan
>Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-
>rtcweb-sip-interworking-requirements-00]
>
>On 10/28/2011 10:56 AM, Ravindran Parthasarathi wrote:
>> 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.
>I believe the "Fedex IVR" case was specifically intended to surface the
>requirement for "non-final responses" (switching a media stream from the
>initial responder to a next responder).
>That's one form of forking ("serial fork"?)
>
>I haven't understood forking to be a requirement in any other use case.