[SIPForum-discussion] To-tag Change

Fri Feb 8 19:58:16 UTC 2008

You aren't wrong - but the thing to take away is that there are _two  
different dialogs_
being talked about.

Consider first this diagram - (you may need to make sure you're  
viewing in a fixed width font):
                UAS
              /
             / 180 to-tag=a
UAC--->Proxy
             \ 200 to-tag=b
              \
               UAS

The top UAS returns a 180 with a to-tag of a, the bottom later  
returns a 200 with a to-tag of b.

At that point, your UAC is in _two_ dialogs, one early (with a to-tag  
of a) and one confirmed.
And you will abandon the early one if it doesn't complete quickly  
after that 200 (remember
that you can get multiple 200 OKs, one from each potential branch).

Now, if there wasn't a fork and you had simply

UAC--->Proxy--->UAS

and the UAS was emitting both the 180 and the 200 (with different to- 
tags), then the UAS is probably,
but not necessarily, doing something wrong. If the UAS were a gateway  
or b2bua or anything else that
could reasonably be representing two things on the other side of it,  
then its behavior is probably correct.

And here's the clencher:

As the UAC, you ->CANT TELL THE DIFFERENCE<- between the two  
scenarios above.
To you, its just stuff on the other side of that proxy - you have to  
assume something forked
if you see a 180 and a 200 with different to-tags in response to the  
same request.

RjS

On Feb 8, 2008, at 1:43 PM, BIENVENIDO A 007MUNDO wrote:

> 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
> 	