Subject: [Sip] WGLC for draft-ietf-sip-nat

From: "Dean Willis" <[email-masked]>
Date: Fri, 6 Sep 2002 15:10:29 -0500

Version 02 of draft-ietf-sip-nat was posted two months ago (5Jul02) in
response to earlier suggestions and there seem to have been no further
comments.

I am therefore requesting working group last call of the sip-nat draft.
According to our posted milestones, this should have concluded last call
last week, so we're not doing too badly. I'd like to send it on to the
IESG by 20Sep, so get your comments in posthaste.

The draft in question is available at:

http://www.ietf.org/internet-drafts/draft-ietf-sip-nat-02.txt

As usual, please post dicussion to the list and copy the lead author,
[email-masked]

Thanks,

--
Dean

_______________________________________________
Sip mailing list  https://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

---

From: Chris Martin <[email-masked]>
Date: Fri, 06 Sep 2002 19:18:25 -0500

I have been absent from this list for awhile, and just caught this
message... I agree with the following paragraphs, 

"In the case where there is a NAT between the client and server, in
   order for the response to always be received, the NAT binding must
   remain in existence for the duration of the transaction. Most UDP NAT
   bindings appear to have a timeout of about one minute. Therefore,
   non-INVITE transactions will have no problem. For INVITE
   transactions, the client may need to retransmit its INVITE every 20
   seconds or so, even after receiving a provisional response, in order
   to keep the binding open to receive the final response.

        OPEN ISSUE: This is awful. Perhaps a further sign that the
        only real answer is TCP? Or, perhaps this belongs in
        sipping-nat-scenarios, not here.
"

From my brief reading of the draft it appears that only SIP rport is
being requested...  how is this useful to sdp negotiation...is it merely
for such items as IM?

I think that this would be useful, and possibly not require the multiple
invites mentioned, if the rport were used in the sdp as well... then the
media could maintain the open connections.

Since I am shooting very quickly from the hip with jsut a five minute
speed read of the draft let me know if this is way off or if I am going
in the right direction and reasoning and I will put more of my thoughts
on this in a form that can be useful for use within this draft. (With a
lot more effort  :^)    )

I will try to read more this weekend and offer more input as well.

Christopher A. Martin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 06 Sep 2002 21:44:50 -0400

Responses inline.

> being requested...  how is this useful to sdp negotiation...is it merely

Its only for SIP. In fact, its only for getting responses back when the 
request is sent through a NAT; handling registrations through a NAT is 
also not addressed here. Dealing with NAT for media signaled through SDP 
is a different problem as well.

> media could maintain the open connections.

Huh?

Media isn't sent to the proxy. To deal with media, you need something 
like STUN or SPAN/TURN.

-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

---

From: Chris Martin <[email-masked]>
Date: Fri, 06 Sep 2002 22:03:57 -0500

> Media isn't sent to the proxy. To deal with media, you need something

Good catch...  :^)   Sometimes I get ahead of myself.... thats speed
reading for ya.

:^)

---

From: "Steve Silverman" <[email-masked]>
Date: Mon, 9 Sep 2002 11:05:42 -0400

If the system can not complete a phone call in less than one minute, the
caller will have hung up long ago.  When you dial a call today, how long
will you wait for the called party?  In most parts of the world, about 10
seconds is  the limit and then the caller hangs up and tries again.

Steve Silverman

---

From: Chris Martin <[email-masked]>
Date: Mon, 09 Sep 2002 18:04:33 -0500

This is one of the reasons that I am wodering why we need this
functionality. My comment earlier, that Johnathan responded to, was in
relation to a client to client communication (though I didnt explain it
clearly and the response was appropriate to my answer).  

In a situation such as this, client to client, a mechanism to keep a
translation open I thought it might be useful.  But if this is merely to
keep a sip session open during sip session establishment, I havent seen
a need for this as all sip traffic going through NAT that I have seen
hasnt had an issue with timeouts.  On the other hand registrations may
be a good reason to do this, but is already addressed at this point by
many clients that now offer a nat feature that permits a more permanent
feature to maintain constant ports per client for this purpose.... so
why do this at all?

Chris

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Sep 2002 23:43:00 -0400

Chris Martin wrote:
> functionality.

Which functionality? Your original note was talking about SDP, which is 
not what the sip-nat draft is about. Or, are you questioning the need 
for sip-nat at all?

> My comment earlier, that Johnathan responded to, was in
> translation open I thought it might be useful. 

SIP-NAT is not about keeping translations open. sip-nat is about making 
sure responses are received properly for any request sent through a NAT. 
If you want to keep a binding active to receive media traffic, you use 
STUN.

> But if this is merely to
> hasnt had an issue with timeouts.

Your comment makes no sense to me without defining "this".

> On the other hand registrations may

I cannot understand this sentence since I do not know what a "nat 
feature that permits a more permanent feature" is, nor do I know what 
"this" is.

Please, before complaining about this specification, kindly spell out 
exactly what your complaints are.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 09 Sep 2002 23:46:57 -0400

> seconds is  the limit and then the caller hangs up and tries again.

Great, and that case works.

However, we have sevearl other cases of concern. The most irritating of 
these is the case where a UAS is a gateway that connects to an 800 
number system that actually never generates an ACM. Rather, it uses the 
reverse media path to prompt the user that they are in a queue. Once the 
user is out of the queue, the call is actually answered. As a result of 
this, the call can "ring" for minutes, perhaps even hours. To keep the 
binding alive to receive the SIP response is this case, the client will 
need to retransmit the INVITE every 30s or so. Of course, TCP is better 
here, and won't require any retransmits. The provisional response sent 
by the UAS, in order to keep timer C going, will maintain the bindings.

However, the main feature provided by this specification, rport, ensures 
that the response, whether generated immediately or later on, is 
received by the UAC behind the NAT.

-Jonathan R.

---

From: Chris Martin <[email-masked]>
Date: Tue, 10 Sep 2002 19:17:41 -0500

> not what the sip-nat draft is about. Or, are you questioning the need

Yes that was off topic and out of place.... :^) I was thinking of my
current focus which is traversal/enablement.... not part of this thread.

And yes, the question is why sip-nat...

> If you want to keep a binding active to receive media traffic, you use

By having the ability of ensuring that sip is recieved properly I am
assuming that the intention is that of maintaining a nat binding for sip
to be contacted through. I am not referring to media traffic.. you
clarified the intent in your first email. I am now questioning why
sip-nat? Not to be argumentative, merely to understand the intent.

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 10 Sep 2002 18:50:58 -0700

Hi Chris,

We have sufficient interest and consensus to proceed with this 
(chartered) document, even if you think it will not be useful to you 
personally.  If you want further explanations about why 
draft-ietf-sip-nat is useful, please take that discussion off the list. 
If there are other SIP and NAT related topics you would like to see 
addressed that are not discussed in draft-ietf-sipping-nat-
scenarios-00.txt, then you are free to propose this as new work in 
SIPPING.

thanks,
-rohan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Sep 2002 22:32:57 -0400

Chris Martin wrote:

> to be contacted through.

No, that is not correct.

The normal behavior for sending a response to a SIP request is to send 
it to the source IP address of the request, but to the port in the Via 
header. This rule will cause responses to be lost through all NAT types, 
even if the bindings last forever. sip-nat allows for the response to 
actually be received.

-Jonathan R.

---

From: Chris Martin <[email-masked]>
Date: Tue, 10 Sep 2002 21:36:05 -0500

Thanks Johnathan, thats what I was looking for, and it makes perfect sense
now. (I was premature earlier...)

:^)

Chris