[SIPForum-discussion] To-tag Change

Fri Feb 8 20:21:42 UTC 2008

Proxy should really check for responses based on branch ID and cancel other requests in case of forking to avoid this condition. If 18x is recieved, other requests should be cancelled.

I know the application is ringing multiple endpoints and pick the one that answers but then for that, one should use B2BUA which can mantain To tags leg by leg instead of passing transparently which will really avoid this issue. So even when 18x came from one endpoint, when 200OK is sent, first leg still uses same tags to avoid this condition. Transparency with proxy casues these issues.

M 

-----Original Message-----
From: discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.org] On Behalf Of BIENVENIDO A 007MUNDO
Sent: Friday, February 08, 2008 2:43 PM
To: Robert Sparks
Cc: j.martinez at javeriana.edu.co; discussion at sipforum.org
Subject: Re: [SIPForum-discussion] To-tag Change

Hi,
Thanks a lot. 

When the responses (180 and 200) are sent through a "Proxy" the "UAC" will receive differents "To-tag" for a single request.

UAC--------PROXY-------UA´s things emitted (diferent to tag in 180 and 200)

I understood from RFC that "To-tag", "From-tag" and "Call-Id" must be the same in a dialog (Messages 101-199 included) Am I wrong?

RFC 3261

[Page 12]

  Call-ID contains a globally unique identifier for this call,

   generated by the combination of a random string and the softphone's

   host name or IP address.  The combination of the To tag, From tag,

   and Call-ID completely defines a peer-to-peer SIP relationship

   between Alice and Bob and is referred to as a dialog.

8.2.6.2 Headers and Tags

   [...]

If a request contained a To tag in the request, the To header field

   in the response MUST equal that of the request.  However, if the To

   header field in the request did not contain a tag, the URI in the To

   header field in the response MUST equal the URI in the To header

   field; additionally, the UAS MUST add a tag to the To header field in

   the response (with the exception of the 100 (Trying) response, in

   which a tag MAY be present).  This serves to identify the UAS that is

   responding, possibly resulting in a component of a dialog ID.  The

   same tag MUST be used for all responses to that request, both final

   and provisional (again excepting the 100 (Trying)).  Procedures for

   the generation of tags are defined in Section 19.3.

12.1 Creation of a Dialog

   Dialogs are created through the generation of non-failure responses

   to requests with specific methods.  Within this specification, only

   2xx and 101-199 responses with a To tag, where the request was

   INVITE, will establish a dialog.  A dialog established by a non-final

   response to a request is in the "early" state and it is called an

   early dialog.  Extensions MAY define other means for creating

   dialogs.  Section 13 gives more details that are specific to the

   INVITE method.  Here, we describe the process for creation of dialog

   state that is not dependent on the method.

	-----Mensaje original----- 
	De: Robert Sparks [mailto:rjsparks at nostrum.com] 
	Enviado el: vie 08/02/2008 12:38 
	Para: BIENVENIDO A 007MUNDO 
	CC: discussion at sipforum.org; j.martinez at javeriana.edu.co 
	Asunto: Re: [SIPForum-discussion] To-tag Change

	You can see a 200 with a different to-tag than you saw in the 180 in 
	the real world.
	Its not that the thing emitting the responses changed the tags - its 
	that different things emitted the responses.

	If the request forked somewhere downstream from you, you could have 
	one branch of the fork return a 180
	and the other return a 200, leading to what you're seeing.

	RjS

	On Feb 8, 2008, at 11:12 AM, BIENVENIDO A 007MUNDO wrote:

	> Hi,
	>
	> Do you think that is possible to change "To-tag" field in a 200ok 
	> message after receiving 18X message with to-tag?
	>
	> The references aren't clear neither RFC3261 nor drafts (for example 
	> http://tools.ietf.org/id/draft-ietf-sipping-service-examples-13.txt).
	>
	> In draft example 2.9 (call forwarding - no answer "sequential 
	> forking"), "To-tag" F5 message (180) is different than "To-tag" in 
	> F13 message (200ok), otherwise in RFC3261 the session is 
	> established with unique ID, this ID is composed of "From-tag", 
	> "Call-Id" and "To-tag".
	>
	> My Switch doesn't accept 200ok with different "To-tag" if 
	> previously has received a 180 message.
	>
	> Can someone clarify this issue please?
	>
	>  Thanks,
	>
	> José.
	>
	>
	> _______________________________________________
	> This is the SIP Forum discussion mailing list
	> TO UNSUBSCRIBE, or edit your delivery options, please visit http:// <http:///> 
	> sipforum.org/mailman/listinfo/discussion
	> Post to the list at discussion at sipforum.org

_______________________________________________
This is the SIP Forum discussion mailing list TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org