[reSIProcate] Considering sent-by value in transaction-id

[Scott Godin]

Hi Tibor,

These changes make sense to me and I like that you cache the newly
formatted tid.  Since transaction matching is so key to stack, I want to
give others ample opportunity to review this patch.  I'm thinking this will
be ok for repro, but we will need to validate that as well.

Ideally we are trying to encourage people to setup a GIT pull request for
patches, since it makes it easier for everyone to review and try out the
changes.

Thanks for your contribution!

Scott

On Fri, Dec 4, 2015 at 9:04 AM, Tibor Velencei <Tibor.Velencei at gamma.co.uk>
wrote:

> Dear All,
>
> We met with a situation in which Resip's stack considered an incoming
> invite as a retransmit even though it belonged to a subsequent SIP dialog.
> The sender UA generated the same branch-id which was recently
> used for a previous invite transaction but the sent-by value in the
> Via header was different. We discovered that Resip's stack disregards
> the sent-by value to identify transactions even though RFC 3261
> (https://tools.ietf.org/html/rfc3261#section-17.2.3) says:
>
> The request matches a transaction if:
>
>      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
>
>      3. the method of the request matches the one that created the
>         transaction, except for ACK, where the method of the request
>         that created the transaction is INVITE.
>
> This matching rule applies to both INVITE and non-INVITE transactions
> alike.
>
>      The sent-by value is used as part of the matching process because
>      there could be accidental or malicious duplication of branch
>      parameters from different clients.
>
> Here is a patch proposal which is a solution for us. It is for Resiprocate
> 1.7 but 1.10 still the same in this way. Sorry about that.
> Possibly you can advise a more appropriate one.
>
> Best Regards,
> Tibor
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20151204/768cefc6/attachment.htm>