| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
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: 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@xxxxxxx> wrote:
|