[SIPForum-discussion] To-tag Change

Fri Feb 8 20:46:32 UTC 2008

I dont disagree with this functionality sitting on UAC but only if the UAC is doing forking, this would be easy to handle. But with a single request going out of a UAC and different dialogs getting created, this can be complex. So thats why I believe either the front ended proxy  or B2BUA should handle it or even use a B2BUA be used with media routing if possible, which can handle this better from tags and better handling from SDP standpoint.

Just a thought.

M

-----Original Message-----
From: Robert Sparks [mailto:rjsparks at nostrum.com] 
Sent: Friday, February 08, 2008 3:30 PM
To: Manpreet Singh
Cc: BIENVENIDO A 007MUNDO; j.martinez at javeriana.edu.co; discussion at sipforum.org
Subject: Re: [SIPForum-discussion] To-tag Change

No, a proxy should not do what you suggest - that would, in fact, break many of the existing services that use proxies on the planet.

Yes you can try to push the complexity off to the other side of a b2bua. But if you are building a UAC, you're a lot better off dealing with the complexity yourself (you'll work in more real world environments).

RjS

On Feb 8, 2008, at 2:21 PM, Manpreet Singh wrote:

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