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

From: Paul Francis <[email-masked]>
Date: Fri, 05 Jan 2001 14:34:33 -0800

Why is it that the receiver tag in the via header indicate the received
network address but not also the received port (in section 6.47.2
Receiver-tagged Via Header Fields)?

It seems you'd want this too to deal with port translation in a NAT box.
For instance, using the example from section 6.47.2, if you got the
following via header:

     Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3

but the NAT box at 199.172.136.3 was also doing port translation and used,
say, port 13488, then this would fail to return the packet to the proxy at
10.0.0.1 because the NAT box wouldn't know how to route the packet.

Seems what you'd want instead is:

     Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3:13488

PF

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Mon, 8 Jan 2001 10:05:30 -0000

> Receiver-tagged Via Header Fields)?

In a nutshell: the port is generally not considered useful since
just because a client sends from a particular port, it doesn't
mean that it's also listening on that port.

(I vote that this becomes a FAQ.)

Cheers,

 - Jo.

---

From: Neil Deason <[email-masked]>
Date: Mon, 08 Jan 2001 11:06:36 +0000

> (I vote that this becomes a FAQ.)

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?

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 08 Jan 2001 13:16:43 -0500

> reference be removed and these two sections consolidated into

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.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Paul Francis <[email-masked]>
Date: Mon, 08 Jan 2001 12:01:28 -0800

> > > mean that it's also listening on that port.

Got it.  Thanks.

> rather than a NAT example, removing mention of NATs altogether.

This strikes me as potentially not adequately addressing the issue, for two
reasons.

First, it seems to me that the received tag is is certainly useful for the
NAT case where there is no port translation, and so off hand seems to solve
the problem there.  This is an important case, so removing any discussion of
NAT seems a bad idea.

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.  The corner case is
where, for some reason, the host wants to send packets out via one IP
address, and then receive them via another IP address, and I don't think
this needs solving for.

So assuming that we still want to be able to solve for at least the NAT with
no port translation case, I think the original NAT example makes sense.
What is needed is either:

1.  Text describing the NAT case that isn't solved (i.e., port translation
where the port used to send the packet is not the same as the listen
port...by the way, is this a common scenario?), or
2.  Actually make an effort to solve even for the case of NAT port
translation.  This would take some thought, but I guess it would require
something where the sending host indicates in the via header what source
port its outgoing packet used, and the receiving host detecting that the
port has changed, and further noting that if the source port is not the same
as the listen port, to do some kind of error because it isn't going to be
able to return a packet anyway...

PF

---

From: Neil Deason <[email-masked]>
Date: Tue, 09 Jan 2001 13:32:10 +0000

> the problem there.  This is an important case, so removing any discussion of

Mentioning the word NAT is unhelpful there because the 
following text is not a complete solution. This causes
confusion and questions like your own.

> arrange to put the same address in the SIP header. 

You cannot guarantee that every SIP implementation will 
in fact know this. So it makes the protocol more robust for
the receiving party to check what happened than rely on 
the sender to set things up right.

> The corner case is

NAT/Firewall issues need to be addressed but not within 
the confines of the core spec where we need to be looking 
for what can be taken out not added. There are already drafts 
on the subject hopefully something will arise out of them.

Cheers,
Neil

---

From: "Robert Sparks" <[email-masked]>
Date: Tue, 9 Jan 2001 09:29:30 -0600

a.s. This got a little long - sorry
     It does contain a concrete proposal.
------------
I think we are falling into a set of traps
with the REFER discussions, endangering an
already overdue deliverable.

The worst is specification creep. The group
was pretty happy with the functionality of
the current draft. When we tripped up on the
timeout problem, we saw a host of extra 
functionality we could add while working
around that problem.

Most of us have gravitated towards a model
where REFER is answered with a set of
reciprocal responses (essentially NOTIFYs,
possibly of a different name, with or without
an explicit subscribe). What we _haven't_
spent much time on is the profile of those
responses. How many can there be? What do
they contain?

I really anticipate the answers to those last
questions will vary widely depending on the
application using REFER. We want to be able
to do other things than transfer (this is 
why the method got renamed from TRANSFER).
A rich response set for a REFER that triggers
a SUBSCRIBE is likely to be entirely different
in character from one that triggers an INVITE.

PROPOSAL
In interests of meeting our working group
deliverable on this topic (now _WAY_ overdue),
I suggest that obtaining this rich response
set has shown itself to be too big a bite. I
propose that it is time to fall back to a single
REFERDONE reciprocal request, carrying the
information that is provided in the current
draft's final response. This would provide a
baseline version of REFER that would meet the
requirements the current draft addresses.

I further propose that when we complete that work,
we can return to REFER and define an extension that
would get the richer response set, addressing the
current lack of definition of that response set
with something like sip-event profiles.

RjS

---

From: Sean Olson <[email-masked]>
Date: Tue, 09 Jan 2001 11:15:44 -0600

I'm sorry, I don't see the standardization of the
REFERDONE as being any easier than the standardization
of a NOTIFY to serve the same purpose.

To satisfy a need stated by Billy, the
body of the NOTIFY could simply be the SDP
from the 200 OK (assuming an INVITE) or empty
for a BYE. Uses of REFER for other methods would
need to be specified in extension drafts.
The Event: token could be "referdone".

Is there anything else that needs to be specified
for the use of NOTIFY that I am missing?

I don't wish to drag this out forever. I think
the solution is fairly simple and straightforward
and could be extended in the future.

Please point out faults with this proposal and
areas of implementation difficulty.
/sean

---

From: Rick Dean <[email-masked]>
Date: Tue, 9 Jan 2001 11:31:07 -0600

> areas of implementation difficulty.

Excellent.  I agree.  No REFERDONE method.
Simply make it a header which is included in 
a method which makes sense.

"refer-status: 200 ok"

This follows the SIP way of everything globbed
into one message.  

--
Rick  :-)
[email-masked]

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 09 Jan 2001 13:49:42 -0500

Hi,

I agree with Sean that an implicit NOTIFY is straightforward, no more
complicated than REFERDONE and solves the timeout problem.  I hope we don't
need a meeting to close this issue.  ;-)

The "other" problem, however, is the one that opened the can of worms.
What primitive(s) do you use to get attended transfer to work?  All of the
proposals (something like 4 of them) work and solve the requirement for an
attended transfer.  Some of these proposals deal more with the  bis draft
(see Tom Taylor's post today).  Everyone seems to want other features as
well, but we need to see at least a "sketch" of the complete features
picture associated with each proposal.  This is why I proposed the one-day
face-to-face meeting.

thanks,
-rohan

---

From: "Robert Sparks" <[email-masked]>
Date: Tue, 9 Jan 2001 13:23:34 -0600

As far as I can thell, You and Sean are assuming you get
exactly one NOTIFY then. 

At that point we're just quibbling on the method name.

Or do you disagree? If you are assuming more than one
NOTIFY, then I think you missed my point.

RjS

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Tuesday, January 09, 2001 12:50 PM
> To: Sean Olson; Robert Sparks
> Cc: [email-masked]
> Subject: Re: [SIP] REFER progress
> 
> 
> Hi,
>

---

From: Sean Olson <[email-masked]>
Date: Tue, 09 Jan 2001 14:36:30 -0600

True. We are quibbling on the method name.
NOTIFY fits the need quite nicely. Why
invent something new? Of course, on the
question of more than one NOTIFY, I see
no reason why it couldn't be done. For
simplicity, I'm willing to start with the
model of a single NOTIFY indicating the
final response of the "referred" transaction.
(No one mention forking and we will all get
through this without a nervous breakdown :)

/sean