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
Hello,
the cancel is matched based on via branch value or the other tokens in the request (callid, cseq, ...). If you want to restrict on matching by source ip/port, you have to do it in the configuration file.
I guess that gives you what you need by default.
Cheers, Daniel
On 04/06/15 21:22, Volkan Hatem wrote:
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi Daniel,
I see that call-id (and other dialog identifiers) matching are controlled by configuration but not IP:Port in via. It's hard-coded in via_matching() called from matching_3261().
Thanks, -volkan
On Fri, Jun 5, 2015 at 9:49 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
the cancel is matched based on via branch value or the other tokens in the request (callid, cseq, ...). If you want to restrict on matching by source ip/port, you have to do it in the configuration file.
I guess that gives you what you need by default.
Cheers, Daniel
On 04/06/15 21:22, Volkan Hatem wrote:
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 listsr-dev@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Book: SIP Routing With Kamailio - http://www.asipto.com
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Daniel-Constantin Mierla -
Volkan Hatem