Hi Paul & Brett, Thanks for your detailed clarification. Just final doubt if
in the INVITE request will have "Request-Disposition: no-fork" then Call
forwarding will not happen for that request ?
Thanks,Sourav
On Tuesday, 5 May 2015 6:53 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:
On 5/5/15 4:21 AM, Sourav Dhar Chaudhuri wrote:
> Hi Paul,
> Thanks for your response. So it means the Call Forwarding always
> need minimum requirement that Caller [UAC] must have support for
> handling forking response in case SBC does not have the "fix" you mentioned.
>
> Also my second doubt why this thing not been properly highlighted
> in RFC 5359. Is support to handle forking response is mandatory
> requirement for a SIP Caller [UAC]?
I wasn't an author of that, so can't say for certain. But it has a
normative reference on RFC3261. And support for multiple early dialogs,
at least to the extent I described, is not optional there. It would get
tiresome for every sip document to emphasize every mandatory feature of
3261 that must be supported.
Thanks,
Paul
> Thanks,
> Sourav
>
>
>
> On Monday, 4 May 2015 9:38 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:
>
>
> On 5/4/15 10:49 AM, Sourav Dhar Chaudhuri wrote:
> > Hi , I have a question on To tag change during Call Forwarding
> [Unconditional / Busy/ No Answer]. As per RFC 5359, it can be noticed
> that To tag value is getting changed from 181 Call is being forwarded to
> 180 Ringing response during Call Forwarding.
> > Now my query is if a caller does not support forking then any call
> originated from that caller will never be forwarded? Since To tag value
> is getting changed during Call Forwarding.
> > Also how the caller is maintaining the state during call
> Forwarding? Since initial INVITE is getting two provisional response
> having two different To tag. For the initial provisional response there
> is no final response. Only the final response is coming from the
> transferred callee. Then what will be the status of the call leg
> generated for first provisional response?
>
> This is basic SIP. A UAC that doesn't support this is *broken*.
>
> When you see the first to-tag that establishes one early dialog. When
> you see the 2nd to-tag that establishes a 2nd early dialog. You need to
> maintain state for those independently.
>
> When you get a 200 response on the 2nd early dialog you don't know with
> certainty whether the first dialog is gone or not. It is *possible* that
> you could still get a 200 response on that dialog until it times out,
> even though it is more likely that it has been canceled downstream.
>
> I think there are SBCs that "fix" this by hiding the existence of two
> dialogs from the caller. But the caller can't really depend on that
> unless it is deployed in an environment where it knows there is always
> such an SBC in the path.
>
>
> Thanks,
>
> Paul
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> <mailto:Sip-implementors@lists.cs.columbia.edu>
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
