[sr-dev] RFC 6141 & CANCEL transaction matching

[Volkan Hatem]

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 at 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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20150605/f596d152/attachment.html>