Subject: [Sip] To-Tag

From: Buettner Werner <[email-masked]>
Date: Tue, 27 Nov 2001 16:17:42 +0100

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.  

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.html] 

But, if this view is correct, then the call flow examples are incorrect.  In RFC2543 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.

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.  

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.  Wouldn´t 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 Büttner
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