reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

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

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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel