[reSIProcate] Why resiprocate just use the branch parameter in via header to distinguish transaction
Scott Godin
sgodin at sipspectrum.com
Mon Jul 31 09:31:50 CDT 2017
Cancel processing is a fairly fundamental feature of the stack. I'm
certain if it was broken a large number of users would be reporting it.
In fact the comment from the code you included in your email explains
exactly why the stack is adding a CANCEL token to the TID:
// Note: For cancel requests the tid member passed in will
have the token "cancel" appended
// to it, so that the cancel request can be treated as it's own
transaction. sip->getTransactionId()
// will be the original tid from the wire and should match the
tid of the INVITE request being
// cancelled.
TransactionState* matchingInvite =
controller.mServerTransactionMap.find(sip->getTransactionId());
The find method above, is doing the find with the raw transactionid and not
the one with "cancel" appended to it.
Perhaps if you shared a STACK level log and a wireshark pcap (if the
messages aren't logging) we might be able to help you determine what's
going on.
Scott
On Sun, Jul 30, 2017 at 10:36 AM, 海滨 <lhb8859138 at 163.com> wrote:
> Hi Scott,
>
> Just one correction:
> If the server receive the invite msg then receive the cancel msg with the
> same branchId, it seems that the server can't find the correlate invite
> transaction for the cancel request if implement below solution.
>
> Maybe we need append "INVITE" instead for both "ACK" and "CANCEL" methods
> for server transaction in getTransactionId().
>
> Thanks.
>
>
> At 2017-07-30 11:31:16, "海滨" <lhb8859138 at 163.com> wrote:
>
>
> Hi Scott,
>
> you can check the code:TransactionState.cxx[line:246] in 1.10.2 .
> Thanks
>
> else if (method == CANCEL)
> {
> // Note: For cancel requests the tid member passed in will
> have the token "cancel" appended
> // to it, so that the cancel request can be treated as it's
> own transaction. sip->getTransactionId()
> // will be the original tid from the wire and should match the
> tid of the INVITE request being
> // cancelled.
> TransactionState* matchingInvite =
> controller.mServerTransactionMap.find(
> sip->getTransactionId());
> if (matchingInvite == 0)
> {
> InfoLog (<< "No matching INVITE for incoming (from wire)
> CANCEL to uas");
> //was TransactionState::sendToTU(tu, controller,
> Helper::makeResponse(*sip, 481));
> SipMessage* response = Helper::makeResponse(*sip, 481);
> Tuple target(sip->getSource());
> controller.mTransportSelector.transmit(response, target);
>
>
>
> At 2017-07-29 16:37:02, "海滨" <lhb8859138 at 163.com> wrote:
>
> Hi Scott,
>
> After re-check the code change here(http://list.resiprocate.
> org/archive/resiprocate-devel/msg08981.html), I find something confused.
> Why add the "method" after send-by when get the transaction id of server
> side?
> If the server receive the invite msg then receive the cancel msg with the
> same branchId, it seems that the server can't find the correlate
> transaction for the cancel request.
> Thanks.
>
> + s << header(h_Vias).front().param(p_branch).getTransactionId();
> + s << header(h_Vias).front().sentHost();
> + s << header(h_Vias).front().sentPort();
> + if (method() != ACK)
> + {
> + s << method();
> + }
> + else
> + {
> + s << INVITE;
> + }
>
>
>
>
>
>
> At 2017-06-19 23:02:42, "Scott Godin" <sgodin at sipspectrum.com> wrote:
>
> 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
>>>
>>
>>
>
>
>
>
>
>
> 【网易自营|30天无忧退货】不到同款1折价！Tory Burch制造商美式休闲人字拖限时仅29.9元>>
> <http://you.163.com/item/detail?id=1185012&from=web_gg_mail_jiaobiao_9>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20170731/9edaa2e9/attachment.htm>
More information about the resiprocate-devel
mailing list