Re: [sr-dev] RFC 6141 & CANCEL transaction matching

Hi All, I searched list archives and have not seen a discussion on this issue. According to 3261, CANCEL transaction matching follows the rules listed in section 17.2.3: [...snip...] 1. the branch parameter in the request is equal to the one in the top Via header field of the request that created the transaction, and 2. the sent-by value in the top Via of the request is equal to the one in the request that created the transaction, and [...snip...] However, according to RFC 6141 (which I don't think kamailio implemented yet) suggests generating a CANCEL request (UAC) after losing contact (section 5.5): [...snip...] When a UAC moves to a new contact and loses its old contact, it will not be able to receive responses to the re-INVITE. Consequently, it will never generate an ACK request. Such a UAC SHOULD generate a CANCEL request to cancel the re-INVITE and cause the INVITE client transaction corresponding to the re-INVITE to enter the "Terminated" state. The UAC SHOULD also send a new re-INVITE in order to make sure that both UAs have a common view of the state of the session. [...snip...] My interpretation is that sent-by comparison is ruled out because clearly IP:PORT will not match anymore. Do you think this is the right interpretation? Is there a plan to implement RFC 6141? Regards, -volkan _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev