<div dir="ltr">Hi All,<br><br>I searched list archives and have not seen a discussion on this issue.<br><br>According to 3261, CANCEL transaction matching follows the rules listed in section 17.2.3:<br><br>[...snip...]<br>      1. the branch parameter in the request is equal to the one in the<br>         top Via header field of the request that created the<br>         transaction, and<br><br>      2. the sent-by value in the top Via of the request is equal to the<br>         one in the request that created the transaction, and<br>[...snip...]<br><br>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):<br><br>[...snip...]<br><br>   When a UAC moves to a new contact and loses its old contact, it will<br>   not be able to receive responses to the re-INVITE.  Consequently, it<br>   will never generate an ACK request.<br><br>   Such a UAC SHOULD generate a CANCEL request to cancel the re-INVITE<br>   and cause the INVITE client transaction corresponding to the<br>   re-INVITE to enter the "Terminated" state.  The UAC SHOULD also send<br>   a new re-INVITE in order to make sure that both UAs have a common<br>   view of the state of the session.<br><div>[...snip...]</div><div><br></div><div>My interpretation is that sent-by comparison is ruled out because clearly IP:PORT will not match anymore.</div><div><br></div><div>Do you think this is the right interpretation?</div><div><br></div><div>Is there a plan to implement RFC 6141?</div><div><br></div><div>Regards,</div><div>-volkan</div></div>