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

Mon Jun 19 10:02:42 CDT 2017

I think it should be implemented.  We just need someone with the time to
implement it and test it out.  :)

Scott

On Mon, Jun 19, 2017 at 11:00 AM, 163 <lhb8859138 at 163.com> wrote:

> Hi Scott,
>
> do you mean  there is no plan to address the sent-by enhancement?
> I think it is better to implement this proposed solution, then the resip
> can comply with the transaction matching rules defined in the sip standard.
> right?
> Thanks
>
> ------------------------------------------
>
> 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/d2e40298/attachment.htm>