Resending response after trimming the contents........ Rajnish:
Your reasoning below is flawed. CANCEL is a hop to hop request. A 2xx response to a CANCEL only indicates that the next hop has seen your request. It knows about the transaction you want to CANCEL and has accepted the request to CANCEL the previous transaction. It doesn't mean that the UAS (called party) has seen the CANCEL request and accepted to process the request. Thus attempting to deduce anything about the pending INVITE transaction using response to CANCEL is totally flawed. You have to wait for the final response to the INVITE transaction to decide what to do with it. Having said that, the only purpose CANCEL response serves is to let the UAC know if the transction identified in the CANCEL is a transaction that the next hop knows. A 2xx response indicates that the transaction identifiers in the CANCEL request match an previous transaction and the request will be processed by the *next* hop. A 481 response indicates that the transaction identifiers are invalid and will not be processed by your *next* hop. Beyond that there is no significance for this response. It says nothing about the final called party (meaning B's UAS in case where A calls B). Given the above, for the scenario under consideration a 2xx response for the CANCEL makes sense as the INVITE transaction would still be *alive* if the changes proposed in bug 769 is incorporated. Thanks Venkatesh On 5/19/06, Rajnish Jain <[EMAIL PROTECTED]> wrote: > > Jeroen, > > I think "to BYE or not to BYE" is really based on the policy implemented > in > the UAC, but that question only comes in picture if the CANCEL received a > 200. When the CANCEL fetches a 200, then all that means is that the UAC > wasn't quick enough to terminate a proceeding call. The call has now been > accepted and CANCEL is history. The UAC MAY or MAY NOT send a BYE at this > point. It is based on the policy implemented in the UAC. I agree that most > UACs will send a BYE, but that is because their implementers decided to do > so to mimic our experience with PSTN. The protocol did not necessitate > them > to do so. An implementation can let a human user make that decision. As a > theoretical example, if the caller is going to get billed anyway (say for > atleast 3 minutes, a typical rounding period implemented in billing > applications) the caller may just as well decide to talk to the called > party. > > On the other hand, if the CANCEL fetches a 481, then that means the UAC > made > it in time. The UAS is now working on tearing down the call. No further > action from the UAC is needed. The UAC will receive a 487 for the INVITE > (in > case, the UAS is RFC 2543 compliant UAC will need to terminate the INVITE > transaction on its own after 64*T1). There is no BYE whatsoever in this > scenario. The "to BYE or not to BYE" question does not arise here. > > So, there is a huge difference between CANCEL returning a 200 versus 481. > That is why I think the race condition in draft-hasebe section 3.1.2should > continue to have a 481 response for CANCEL regardless of how we fix RFC > 3261 > bug # 769. > > Rajnish > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
