What all this means is that you always use the tags from the INVITE transaction that established the dialog in the BYE request. If your 3261-compliant UA sent an INVITE which arrived at a 2543-compliant UA, there may not be a to-tag returned in the response. The to-tag will be null/empty, and when your UA sends a BYE, it would not have a to-tag. However, if the response to the INVITE does have a to-tag, you must include the to-tag in the BYE, otherwise, the other UA might reject it with 481. The key phrase in statement 2 being "If the BYE does not match an existing dialog", which it will not if the tags are omitted in the BYE.
cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 [EMAIL PROTECTED] ----- Original Message ----- From: "Kaul, Amit" <[EMAIL PROTECTED]> To: "Sip-Implementors" <[EMAIL PROTECTED]> Sent: Tuesday, September 03, 2002 11:45 PM Subject: [Sip-implementors] Rule for BYE received without Tags > Hi, > > I have a question regarding the backward compatibility of RFC3261 with > RFC2543, which arises due to following two statements :- > > Statement1 > ---------- > >From Section 12.1, RFC3261 :- > > "A UAC MUST be prepared to receive a response without a tag in the To field, > in which case the tag is considered to have a value of null. > This is to maintain backwards compatibility with RFC 2543, which did not > mandate To tags." > > Statement2 > ---------- > >From Section 15.1.2, RFC3261 :- > > "If the BYE does not match an existing dialog, the UAS core SHOULD generate > a 481(Call/Transaction Does Not Exist) response and pass that to the server > transaction. > This rule means that a BYE sent without tags by a UAC will be rejected. > This is a change from RFC 2543, which allowed BYE without tags." > > Rule in Statement2 seems to suggest that for BYE, backward compatibility > regarding the tags (From or To Tags) should not be there in implementations > conforming to RFC3261, as it is there for INVITE (statement1). > > Is this understanding correct ? If yes, then there seems to be a potential > backward compatibility issue here for RFC3261 complaint implementations. > > thanks > __amit > > > > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
