Thanks, Nataraju A.B.

-----Original Message----- From: sip-implementors-bounces@cs.columbia.edu [mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Juha Heinanen Sent: Thursday, April 01, 2004 2:47 PM To: Klaus Darilion Cc: serusers@lists.iptel.org; sip-implementors@cs.columbia.edu; serdev@lists.iptel.org Subject: [Sip-implementors] [Serdev] Re: [Serusers] Forking Proxy

Klaus Darilion writes:

UA1 behaves wrong - per RFC 3261 the dialog will be established by

the

200 OK message (not by 180), therefore the to-tag from the 200 OK

must

be used.

klaus,

can you point out the section/paragraph in rfc 3261 that tells that the to-tag from the 200 ok must be used. i scanned the document for a while i didn't find it. the closest i found is this:

[ABN] the base line for to-tag handling in UAC is that the new 1xx or 2xx might match for an existing dialog or create a new dialog depending on the to-tag value. If the to-tag in 2xx matches the one in dialog block then the dialog will transitioned to confirmed state and no tag updation happens effectively same tag used in further transactions in that dialog. If the To-Tag does not match any of the existing dialogs for that call then it creates a new dialog and stored in call block then that tag will be used in further transactions in that dialog which in turn part of the call.

13.2.2 Processing INVITE Responses

If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the confirmed state, and the route set for the dialog MUST be recomputed based on the 2xx response using the procedures of Section 12.2.1.

but it only mentions about recomputing the route set, not the rest of the dialog state.

-- juha _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Confidentiality Notice

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments.