Subject: RE: [Sip] To-Tag

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Nov 2001 13:43:41 -0500

some further clarifications inline.

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Tuesday, November 27, 2001 10:53 AM
> To: 'Buettner Werner'; [email-masked]'
> Subject: RE: [Sip] To-Tag
> 
> > > 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.  

Transaction handling doesn't depend on a To tag being added in the response.
Section 17.1.3 of bis-05 is very clear on that. 

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

I think the question is how a proxy knows whether or not it needs to forward
an ACK. If the proxy could choose its own tag, it could easily know whether
to forward it, by looking at the tag in the ACK.

This is really not needed. Whether its generated or simply forwarded, the
tag in the non-2xx response needs to match the tag in the ACK. Anything
running a server transaction would store this as part of the state of the
server transaction. Whenever you get an ACK that doesn't match a server
transaction, the proxy will forward it. 

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

The port is the port from the host part of the URL. 

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

Whilst I agree this would be nice, its not backwards compatible to add a
port to the maddr. The set of cases where you want to use maddr to route
through an intermediary to a URL that has a non-standard port is small
enough for me not to worry about.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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