[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Bug? Matching rules of Server Transaction
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
FengZhang <y01317@njupt.edu.cn> wrote:
> 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
>
_______________________________________________
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