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

[Christer Holmberg <[e-mail]>]

Hi,

>In case of SIP forking interop with WebRTC, it is possible for WebRTC-SIP gateway to handle this scenario and not by browser. In fact, it is my review comment to 
>draft-kaplan-rtcweb-sip-interworking-requirements-00 (Para 2 in http://www.ietf.org/mail-archive/web/rtcweb/current/msg02316.html) where this mail thread started.

In theory, I'm sure the gateway could handle most cases.

Things may look simple on a PowerPoint slide, showing a simple use-case, but from my experience you may end up with very complex and "clumsy" procedures, depending on how complex your call establishment procedures are.

>Even if WebRTC supports both serial & parallel forking, whether WebRTC signaling will take up the same shape of SIP forking wherein initial INVITE only forks and not for RE-INVITE? In case of WebRTC 
>forking, it is very much possible for different shape of forking.

Well, we can not only say that we support forking. We do need to specify exactly what we mean by "forking support", and what possible restrictions we have.

Regards,

Christer




>-----Original Message-----
>From: Christer Holmberg [mailto:[e-mail]]
>Sent: Saturday, October 29, 2011 1:20 AM
>To: Ravindran Parthasarathi; Iñaki Baz Castillo
>Cc: [e-mail]
>Subject: RE: [rtcweb] RTCWeb Forking usecase [was RE:draft-kaplan-
>rtcweb-sip-interworking-requirements-00]
>
>
>Hi,
>
>In my opinion, interworking with SIP is itself such use-case :)
>
>I think the question is whether a browser should be able to handle
>parallel forking, or if serial forking is enough.
>
>In my opinion serial forking is enough, ie the JS app (or, if you want,
>a gateway) informs the browser about the currently active remote media
>parameters.
>
>Regards,
>
>Christer
>
>
>________________________________________
>From: [e-mail] [[e-mail]] On Behalf Of
>Ravindran Parthasarathi [[e-mail]]
>Sent: Friday, October 28, 2011 10:43 PM
>To: Iñaki Baz Castillo
>Cc: [e-mail]
>Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE:   draft-kaplan-
>rtcweb-sip-interworking-requirements-00]
>
>Inaki,
>
>ISTM, SIP specific functionality is pushed into WebRTC client
>unnecessary without well-defined WebRTC usecase.
>
>Thanks
>Partha
>
>>-----Original Message-----
>>From: Iñaki Baz Castillo [mailto:[e-mail]]
>>Sent: Saturday, October 29, 2011 1:04 AM
>>To: Ravindran Parthasarathi
>>Cc: Harald Alvestrand; [e-mail]; Hadriel Kaplan
>>Subject: Re: [rtcweb] RTCWeb Forking usecase [was RE: draft-kaplan-
>>rtcweb-sip-interworking-requirements-00]
>>
>>2011/10/28 Ravindran Parthasarathi <[e-mail]>:
>>> As I mentioned earlier, SIP (serial) forking requirement shall be met
>>by gateway signaling and no extra requirement for browser.
>>
>>Do it in your gateway if you want, but don't try to mandate it please.
>>As I also mentioned earlier, some of us are willing to handle forking
>>in the WebRTC client (at JavaScript level) and that is perfectly
>>possible.
>>
>>Regards.
>>
>>--
>>Iñaki Baz Castillo
>><[e-mail]>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb