[reSIProcate] Why resiprocate just use the branch parameter in via header to distinguish transaction

[Scott Godin]

Hello,

" First and foremost, the Server should be using *Call-ID* to distinguish
between SIP dialogues.  Before it ever get to looking at Via header
Branch-IDs, they should 1st be looking at Call-ID to establish unique SIP
dialogue contexts."

I disagree with your client.  Dialog Id's are higher level than transaction
Id's.  There should never be a need to examine the DialogId components
(Call Id, To tag, or From tag) to differentiate SIP transactions.  In fact
the branch parameter in the Via header is intended to be unique (RFC3261 -
Section 8.1.1.7):
"   The branch parameter value MUST be unique across space and time for
   all requests sent by the UA.  The exceptions to this rule are CANCEL
   and ACK for non-2xx responses.  As discussed below, a CANCEL request
   will have the same value of the branch parameter as the request it
   cancels.  As discussed in Section 17.1.1.3, an ACK for a non-2xx
   response will also have the same branch ID as the INVITE whose
   response it acknowledges.

      The uniqueness property of the branch ID parameter, to facilitate
      its use as a transaction ID, was not part of RFC 2543.

   The branch ID inserted by an element compliant with this
   specification MUST always begin with the characters "z9hG4bK".  These
   7 characters are used as a magic cookie (7 is deemed sufficient to
   ensure that an older RFC 2543 implementation would not pick such a
   value), so that servers receiving the request can determine that the
   branch ID was constructed in the fashion described by this
   specification (that is, globally unique).  Beyond this requirement,
   the precise format of the branch token is implementation-defined. "

That being said - resip should be including the sent-by in it's transaction
indexing.

17.2.3 Matching Requests to Server Transactions

   When a request is received from the network by the server, it has to
   be matched to an existing transaction.  This is accomplished in the
   following manner.

   The branch parameter in the topmost Via header field of the request
   is examined.  If it is present and begins with the magic cookie
   "z9hG4bK", the request was generated by a client transaction
   compliant to this specification.  Therefore, the branch parameter
   will be unique across all transactions sent by that client.  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."


Note:  This has been brought up in the past, but it never did get addressed:
http://list.resiprocate.org/archive/resiprocate-devel/msg08981.html
http://list.resiprocate.org/archive/resiprocate-devel/msg08982.html

Despite the fact that resip really should be including the "sent-by" value
in the matching, in practice this has not hindered resip compatibility,
since almost all other stack generate the branch parameter using some form
of random number generation.


Scott

On Fri, Jun 16, 2017 at 10:23 PM, 海滨 <lhb8859138 at 163.com> wrote:

> Hi All,
>
> Here is the issue I meet in our product:
> 1. Client A send the option request to Server with the branch parameter =
> XXX, sent-by=A
> 2. Server send the 200 response to the Client A immediatly
> 3. within 64*T1,Client B send the option request to Server with the
> same branch parameter =XXX , but sent-by=B.
> 4. The Server send the last 200 response to Client  A, instead of Client
> B. So Client B can't receive any response for this option request.
> It seems that the resiprocate handle the second option request from Client
> B with the old transaction and consider this request as retransmission.
> Here are my question:
> 1. In sip standard, the sent-by in via header is also the key value to
> distinguish transaction. so whether the resiprocate need enhancement for
> that?
> 2. The call-ids are different between these two option request, so the
> designer of clients explain that as below. is he right for the dialog and
> transaction explanation? in his opinion, the second option request
> shouldn't handled by the old transaction,because the call-id is different
> from the first one.
>  First and foremost, the Server should be using *Call-ID* to distinguish
> between SIP dialogues.  Before it ever get to looking at Via header
> Branch-IDs, they should 1st be looking at Call-ID to establish unique SIP
> dialogue contexts.  From the RFC:
>
>    Call-ID contains a globally unique identifier for this call,
>
>    generated by the combination of a random string and the softphone's
>
>    host name or IP address.  The combination of the To tag, From tag,
>
>    and Call-ID completely defines a peer-to-peer SIP relationship
>
>    between Alice and Bob and is referred to as a dialog.
>
>
> You are appreciated if can provide help.
> Thanks very much.
>
>
>
>
> _______________________________________________
> 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/20170619/43961f5e/attachment.htm>