Comments inline. -Rockson
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz Castillo Sent: Thursday, August 14, 2008 7:12 AM To: [email protected] Subject: [Sip-implementors] About CANCEL proccesing in a UAS Hi, "9.2 Server Behaviour" doesn't clarify the UAS behaviour very well: 1) UAS receives a CANCEL for which there is not an INVITE transaction. UAS must reply a 481 but: - Should UAS generate a transaction for that CANCEL? [RL]yes. To absorb any retransmission. 2) - UAS receives a CANCEL for an INVITE transaction for which UAS has already sent a final response. In this case RFC3261 says: "the CANCEL request has no effect on the processing of the original request, no effect on any session state, and no effect on the responses generated for the original request." - But should UAS reply a 4XX? [RL] since INVITE server transaction would be terminated on delivery of 2xx, so I think CANCEL cannot match any to-be-cancelled transaction, so 481 would be sent. However, draft-sparks-sip-invfix intends change INVITE trasanction , so I think 200(CANCEL) will be sent after this draft is accepted to update RFC3261. - In that case, should it create a transaction? I hope no, since a maliciosus user could generate many CANCEL's and the UAS will create so many transactions. [RL]yes. To absorb any retransmission. 3) UAS receives a CANCEL that matches an active NON-INVITE transaction. RFC says: "A CANCEL request has no impact on the processing of transactions with any other method defined in this specification (INVITE)". - Which response should UAS sent? a 481? a 400? [RL] I think 200(CANCEL) will be sent since rfc says "Regardless of the method of the original request, as long as the CANCEL matched an existing transaction, the UAS answers the CANCEL request itself with a 200 (OK) response. " 200 only means CANCEL is reached at UAS, it does not mean anything previous transaction would be cancelled. We can send 200 for acknowledge CANCEL, but continue processing non-INVITE req without any impact. - Should it create a transaction for this? [RL]yes. To absorb any retransmission. I assume reply for 3) are "481" and "No", and probably this never occurs since non INVITE transactions are expected to finish inmediatelly. Thanks for clarification. -- Iñaki Baz Castillo _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
