Subject: RE: [SIP] question on received tag in via header,draft-ietf-sip-r fc2543bis-02.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Jan 2001 00:40:34 -0500

> -----Original Message-----
> From: Paul Francis [mailto:[email-masked]]
> Sent: Monday, January 08, 2001 3:01 PM
> To: Henning G. Schulzrinne; Neil Deason
> Cc: Jo Hornsby; Paul Francis; [email-masked]
> Subject: Re: [SIP] question on received tag in via
> header,draft-ietf-sip-rfc2543bis-02.txt
> 
> > > I would further ask that we simply the SIP spec in this area.
> > > 6.47.1 Requests (p.77) and 6.47.2 Receiver-tagged Via Header
> > > Fields (p.78) both contain text about adding the received
> > > parameter. In 6.47.2 this crops up in relation to NATs. As the
> > > received param alone will not solve NAT issues can this
> > > reference be removed and these two sections consolidated into
> > > one?
> >
> > I've combined the material into 6.47.2 and made up a 
> multi-homed example
> > rather than a NAT example, removing mention of NATs altogether.
> 
> This strikes me as potentially not adequately addressing the 
> issue, for two
> reasons.
>
> Second, it seems to me that if you really did not want to use 
> this for any
> kind of NAT, then I would question whether it would be better 
> to remove the
> received tag altogether, on the basis that the multihomed 
> case is such a
> corner case that it isn't worth putting the tag in the via 
> header.  The
> reasoning here is that the SIP implementation can certainly 
> arrange to know
> what the source address on the IP packet is going to be, so 
> it can also
> arrange to put the same address in the SIP header.

In practice, it seems to be much, much harder to do this than you might
think. Part of it has to do with a separation of protocol layering that we'd
like to have. Its good to be able to build a stack where the socket and
network I/O issues happen last, after the sip message formatting and sip
machinery has done its job. Secondly, its just not easy to obtain the source
address where the packet will go. There are definitely issues in having this
work ubiquitously across operating systems, machines, and languages.

Also, I think it will be quite common for a host to be multihomed, and to
not be reachable from any host on both networks. The classic case are users
who connect to work through VPNs. 

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

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip