Hi,

According to section 17.2.3 of rfc-3261.


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.



While doing such a matching, should the method in CSEQ header be used or the 
method in Request Line be used?

Though in a well-formed message both these will be the same, in case of a 
malformed message, these may be different.



Regards,

Krishna/Suganya

________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for 
the use of the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be circulated or used for any purpose 
other than for what it is intended. If you have received this message in 
error,please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly prohibited from using, 
copying, altering, or disclosing the contents of this message. Aricent accepts 
no responsibility for loss or damage arising from the use of the information 
transmitted by this email including damage from virus."
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to