[Sip] Bug? Matching rules of Server Transaction

[FengZhang <y01317@njupt.edu.cn>]

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:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP Bob.biloxi.example.com:5060;branch=z9hG4bK74bf
   Max-Forwards: 70
   From: Bob <sip:bob@biloxi.example.com>;tag=31451098
   To: Carol <sip:carol@biloxi.example.com>;tag=8675309
   Call-ID: rt4353gs2egg@pc.biloxi.example.com
   CSeq: 1 NOTIFY
   Contact: <sip:carol@Bob.biloxi.example.com>
   Event: dialog
   Subscription-State: active;expires=3600
   Content-Type: application/dialog-info+xml
   Content-Length: ...

</NOTIFY_F1>

<NOTIFY_F2>

   NOTIFY sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/UDP Bob.biloxi.example.com:5060;branch=z9hG4bK74bf
   Max-Forwards: 70
   From: Bob <sip:bob@biloxi.example.com>;tag=31451098
   To: Carol <sip:carol@biloxi.example.com>;tag=8675309
   Call-ID: rt4353gs2egg@pc.biloxi.example.com
   CSeq: 2 NOTIFY
   Contact: <sip:carol@Bob.biloxi.example.com>
   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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip