|
Hi,
I can see two scenarios in
general, where a CANCEL might arrive when the response context is not
present.
1 - to CANCEL an INVITE :
In this case,
either the stateful proxy decided it will forward the INVITE statelessly,
or, the CANCEL and the 2xx crossed over.
2 - to CANCEL any non-INVITE:
(INFO, or any other request, if the UAC is 2543 compliant)
In this
case, the only possiblity is that this proxy forwarded this non-INVITE request
statelessly. This is because, all non-INVITE transactions would be alive for
64*T1 sec after the final response, and hence the chance of a response context
not being there is remote.
[Prakash]=.
I get the scenario,but I guess that for this specific scenario, we could not
change the implementation(which is generic). Since
this would mean that for a Stateful proxy, if an incoming CANCEL is got, and
there is no matching transaction, then a 481 would never be sent and instead CANCEL be forwarded statelessly always.
CANCEL is recommended to be forwarded always by the proxy if the response context is not available, as there is no way to verify, at least, that this CANCEL is NOT for a previous request that this proxy forwarded statelessly. Also add to that, the scenario of cross-overs-with-forking-further-downstream, it must be a generic behaviour for the proxy to always forward CANCEL this way.
481, could still be returned by UAS.
- Kannan *****************************************************************This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** |
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
