Subject: [Sip] Bug? Matching rules of Server Transaction

From: FengZhang <[email-masked]>
Date: Tue, 17 Jun 2003 21:10:3 +0800

sipHi all,

  When I fulfill "Call pickup" service , I meet a problem about Server Transaction matching rules. As RFC3261 says in section 17.2.3:
<quote>
   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.
</quote>

   So, if the notifier notifies subscriber the resources state in two NOTIFY messages, as below:

             notifier                      subscriber
                |        ............          |
                |-------NOTIFY (F1)----------->|
                |<------200 OK (F2)------------|
                |                              |  the interval is less Timer J, J does not fire yet.
                |                              |
                |-------NOTIFY (F3)----------->|
                |<------200 OK (F4)------------|
                |                              |

  the message is :
<NOTIFY_F1>

 NOTIFY sip:[email-masked] SIP/2.0
   Via: SIP/2.0/UDP Bob.biloxi.example.com:5060;branch=z9hG4bK74bf
   Max-Forwards: 70
   From: Bob <sip:[email-masked]>;tag=31451098
   To: Carol <sip:[email-masked]>;tag=8675309
   Call-ID: [email-masked]
   CSeq: 1 NOTIFY
   Contact: <sip:[email-masked]>
   Event: dialog
   Subscription-State: active;expires=3600
   Content-Type: application/dialog-info+xml
   Content-Length: ...

</NOTIFY_F1>

<NOTIFY_F2>

   NOTIFY sip:[email-masked] SIP/2.0
   Via: SIP/2.0/UDP Bob.biloxi.example.com:5060;branch=z9hG4bK74bf
   Max-Forwards: 70
   From: Bob <sip:[email-masked]>;tag=31451098
   To: Carol <sip:[email-masked]>;tag=8675309
   Call-ID: [email-masked]
   CSeq: 2 NOTIFY
   Contact: <sip:[email-masked]>
   Event: dialog
   Subscription-State: active;expires=3600
   Content-Type: application/dialog-info+xml
   Content-Length: ...

</NOTIFY_F2>

  Notice that the two NOTIFY have the SAME branch & the magic cookie "z9hG4bK", using the matching rules in 17.2.3, all the three rules MATCH! So I can judge F3 belongs to the same transaction which created by F1, because timer J does not fire, and F2 is sent to response F1 , as per 17.2.2 of RFC3261, when F3 comes, I will think F3 is the retransmision of F2!
But they are not the same indeed: different CSeq and report different resource's state!

  Maybe I missing somthing, but I'm really puzzled .

  Thanks a lot to clarify!

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "A. N. Gautham" <[email-masked]>
Date: Thu, 19 Jun 2003 09:35:01 +0530

Hi,
	If an entity inserts a branch parameter that begins with the magic cookie, then it is 3261 compliant. In 3261, the branch parameter has to be unique. As given in Section 8.1.1.7 of 3261, " 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." Thus, the two NOTIFY requests (F1) and (F3) MUST have different branch parameters since they belong to different transactions. Since this has not been followed by the 'notifier', you are finding that F3 gets treated as a retransmission of F1.
	Hope this helps

-Gautham.

On Tue, 17 Jun 2003 21:10:3 +0800