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
