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]?
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
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
