| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
I just realized you might be referring to the stack behaviour after applying changes from that older post (http://list.resiprocate.org/archive/resiprocate-devel/ ). One of the reasons those changes didn't get applied was that no one had a chance to review them, unfortunately that is still the case. You could try contacting the original author for his thoughts if you like.msg08981.html Thanks,ScottOn Mon, Jul 31, 2017 at 10:31 AM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote: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.ScottOn Sun, Jul 30, 2017 at 10:36 AM, 海滨 <lhb8859138@xxxxxxx> 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@xxxxxxx> wrote:
Hi Scott,you can check the code:TransactionState.cxx[line:246] in 1.10.2 . Thankselse 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@xxxxxxx> wrote:
Hi Scott,After re-check the code change here(http://list.resiprocate.org/archive/resiprocate-devel/m ), I find something confused.sg08981.html 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().sentHos t(); + s << header(h_Vias).front().sentPor t(); + if (method() != ACK) + { + s << method(); + } + else + { + s << INVITE; + } At 2017-06-19 23:02:42, "Scott Godin" <sgodin@xxxxxxxxxxxxxxx> wrote:
I think it should be implemented. We just need someone with the time to implement it and test it out. :)ScottOn Mon, Jun 19, 2017 at 11:00 AM, 163 <lhb8859138@xxxxxxx> 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 forall requests sent by the UA. The exceptions to this rule are CANCELand ACK for non-2xx responses. As discussed below, a CANCEL requestwill have the same value of the branch parameter as the request itcancels. As discussed in Section 17.1.1.3, an ACK for a non-2xxresponse will also have the same branch ID as the INVITE whoseresponse it acknowledges.The uniqueness property of the branch ID parameter, to facilitateits use as a transaction ID, was not part of RFC 2543.The branch ID inserted by an element compliant with thisspecification MUST always begin with the characters "z9hG4bK". These7 characters are used as a magic cookie (7 is deemed sufficient toensure that an older RFC 2543 implementation would not pick such avalue), so that servers receiving the request can determine that thebranch ID was constructed in the fashion described by thisspecification (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 TransactionsWhen a request is received from the network by the server, it has tobe matched to an existing transaction. This is accomplished in thefollowing manner.The branch parameter in the topmost Via header field of the requestis examined. If it is present and begins with the magic cookie"z9hG4bK", the request was generated by a client transactioncompliant to this specification. Therefore, the branch parameterwill be unique across all transactions sent by that client. Therequest matches a transaction if:1. the branch parameter in the request is equal to the one in thetop Via header field of the request that created thetransaction, and2. the sent-by value in the top Via of the request is equal to theone in the request that created the transaction, and3. the method of the request matches the one that created thetransaction, except for ACK, where the method of the requestthat created the transaction is INVITE.This matching rule applies to both INVITE and non-INVITE transactionsalike.The sent-by value is used as part of the matching process becausethere could be accidental or malicious duplication of branchparameters from different clients."Note: This has been brought up in the past, but it never did get addressed: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.ScottOn Fri, Jun 16, 2017 at 10:23 PM, 海滨 <lhb8859138@xxxxxxx> 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=A2. Server send the 200 response to the Client A immediatly3. 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@resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-de vel