Subject: RE: [Sip] To-Tag

From: Robert Sparks <[email-masked]>
Date: Tue, 27 Nov 2001 10:53:02 -0500

inline

> -----Original Message-----
> From: Buettner Werner [mailto:[email-masked]]
> Sent: Tuesday, November 27, 2001 9:18 AM
> To: [email-masked]'
> Subject: [Sip] To-Tag
> 
> 
> Dear All
> 
> I have two questions, and hope that some of you will find the 
> time to answer.
> 
> The first question concerns the interpretation of the 
> To-Header tag usage in the SIP protocol.  This question has 
> arisen after bis05 was released.
> 
>  Consider the following scenario:  (diagram in terminal 
> font!!! - fixed width)
> 
>    UAC                  Proxy A               Proxy B
UAS
>     |                     |                      |
|
>     |------ Invite ------>|----- Invite -------> |---- Invite
--------->|
>     |                     |                      |
|
>     |<--- 180, tag A -----|<--- 180, tag A ----- |<---- 180,  tag A
-----|
>     |                     |                      |
|
>     |                     |        (*)           |<---- 480,  tag A
-----|
>     |                     |                      |---- ACK,  tag A
----->|
>     |                     |<---- 480, tag B -----|
|
>     |                     |---- ACK, tag B ----->|
|
>     |<---- 480, tag C ----|                      |
|
>     |---- ACK, tag C ---->|                      |
|

> > This call flow is taken from the call flow draft 
> [draft-ietf-sip-call-flows-05.txt, 3.2.4]
> 
> In the draft it is stated that the to-tag has the purpose of 
> distinguishing between different UAS when forking is done.  
> This has prompted us to include the to-tag in order to match 
> up requests and following responses.  However, as you can see 
> (marked with a *) the tags between the 180 response at proxy 
> B and the follow-up 480 response are different.  This causes 
> problems in the transaction handling.  

There was a thread on exactly this on sip-implementors
recently (Titled "How does a forking proxy handle To tag
in error response selection"). 

You are perceiving a false problem above. You can generate
exactly the same set of messages from the UAC's perspective
by having request fork, and having a 480 be returned as the
"best" response from a different UAS. See the sip-implementors
thread for more detail.

> 
> Another example: In the call flow draft [refer 
> draft-ietf-sip-call-flows-05.txt, page 32 steps F7,F8, F9 and 
> F10] which accompany the RFC2543 drafts it is shown that the 
> non 200 responses (407 in this specific example) which are 
> received are tagged by each proxy with a different tag.  This 
> tag is then also present in the following ACK message.  
> 
> But, it is mentioned in RFC2543 bis 04 or 05that the proxy is 
> only allowed to set the to tag for locally generated 
> responses.  My interpretation of this is that the proxy may 
> (and must) only tag responses which terminate a request at 
> that point, and not responses which are received from further 
> downstream (even if they are negative responses to INVITEs 
> which are ACKed step by step.  Furthermore, I refer you all 
> to a mail by Robert Sparks on the mailing list, which seems 
> to strengthen this view.  
> [refer 
>
http://www1.ietf.org/mail-archive/working-groups/sip/current/msg01706.ht
ml] 

I disagree that my message strengthens the view you are putting
forth.

Again, refer to the thread on sip-implementors - there was
quite a bit of discussion around this. To summarize:

When a stateful proxy sends a non-200 response upstream to a
request that might create a dialog (that's a pretty restrictive
set of preconditions - read it carefully - in particular it means
we're talking about requests that don't already have a To tag),
the next upstream element can not distinguish whether the proxy 
forwarded a response keeping a tag, or made up its own response 
with a new tag.

Most implementations are likely to just reuse a tag when "forwarding"
a non-200 response in that situation, but if one chooses to use its
own tag, nothing breaks (and nothing outside that proxy can tell).
Consider in particular the act of "forwarding" a 401 or 407 where
you are required to gather the challenges from all the other 401
and 407 responses and include them in this one. What you are really
doing is making your own response based on information from the 
responses received. You can consider that to be the case for any
non-200 response you forward under these preconditions.

Now - if the request had a To tag, its a different story - the To
tag in every response will necessarily match the To tag in the request.

> But, if this view is correct, then the call flow examples are
> incorrect.

They are correct with respect to this issue.
 
>            In RFC2542 it is furthermore mentioned that several
> parameters including TO, FROM CALL-ID etc are used to establish 
> whether an ACK is for the proxy (hence, does not need proxying).
> If these responses could be tagged by the proxy then surely the
> tag would be enough to establish this.

I don't understand your question?

> 
> It would be very kind if someone could provide me with some
> clarification on this point, since it seems like there is more
> than one interpretation possible.  Also, it seems like an attempt
> was done in bis-05 to clarify this point (which means that there
> was some sort of confusing), but I am not sure if I understand
> it correctly.  

Hopefully this (and the thread on sip-implementors) covers it
for you. I did add clarifying text on this point to the proxy
section in the spec - it will be available with bis-06.

> 
> Secondly, I would like to know why it is not possible to add a
> port number to the maddr parameter?  Consider receiving a
> "305 use proxy" with the following contact:
> 
> Contact: <sip:siemens.de:6666>
> 
> If the original INVITE had a request line which looked like
> this:  INVITE sip:[email-masked] SIP/2.0
> 
> then the contact of the 305 message should be witten as a
> maddr parameter within the request line of the new invite 
> request.  But, where does one place the port if a maddr 
> parameter cannot consist of a host and port number?  
> We have currently solved the problem on the UDP/TCP 
> layer.  Hence, send the same invite response to 
> siemens.de port 6666.  Wouldnt it be nicer if the maddr 
> parameter could have a port part as well.  After all, 
> each host address could have a specific port number, too.
> 
> I thank you for your time and effort in advance.
> 
> Sincere Regards
> 
> Werner Bttner
> Siemens AG
> ICN WN CC NA D12
> Network Aplications - hiQ6200
> 

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip