Subject: [Sip] Comments and suggestions to draft-ietf-sip-nat-01.txt

From: "Kristoffer Gronowski" <[email-masked]>
Date: Tue, 8 Jan 2002 15:43:01 +0100

Hi! We have implemented the draft on our SIP server and client and I
have some reflections and suggestions to propose.

Section 3 "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."

Should a retransmit value smaller then 32 seconds (11 retransmissions)
be permitted?
This would encourage clients to send requests to often and possibly
flood the system!
It might be OK to do it more often if a 2xx response is received.

Section 4. Translate header is sent back to client.
Is this really necessary? The bottom Via contain both the white and
black IP addresses and ports? The reason for this is that we want to
minimize the packet sizes for sip messages and not send redundant data.
(In the GPRS case the client is often on a NAT network with limited
uplink capabilities.)

We have tried to solve the firewall problem with the same approach.
Since the majority of the firewalls has statful inspection. Then the
state can be kept alive with the same approach. The UA has to send a SIP
message frequently enough. A firewall can be seen as a symmetrical NAT
without the address translation part. This makes it more difficult to
detect. One simple solution is that the UA lets the end user to specify
if behind FW or not. For a more complex UA the probing approach with
sending OPTIONS SIP message can be used.

One of the biggest concerns is that the record routing in the proxy is
fairly expensive operation. A suggestion is to tag the contact with the
nat=sym parameter and only record route those requests. This will solve
both the tricky NAT's and stateful inspection firewalls!

REGISTER sip:[email-masked] SIP/2.0
From: sip:[email-masked]
To: sip:[email-masked]
Via: SIP/2.0/UDP 10.0.1.100;rport
Translate: sip:[email-masked]:2234;nat=sym
Contact: sip:[email-masked]:2234

SIP/2.0 200 OK
From: sip:[email-masked]
To: sip:[email-masked]
Via: SIP/2.0/UDP 10.0.1.100;rport=2397;received=77.2.3.88
Contact: sip:[email-masked]:2397;nat=sym

To put the NAT parameter on the contact feels quite natural since it
describes the contacts property and routing essential information.

Another recommendation should be to check all the final responses sent
from the server to the UA. The Via header black and white addresses
should be compared with the once that the UA is believed to have. This
is due to the fact that a NAT can change the used white port at given
times. The UA should detect this and refresh it's registration so that
other UA can find it! If the UA can handle presence the SUBSCRIBE SIP
messages have to be refreshed as well!

The last issue is if this draft should contain solutions for the IM and
presence extension so that they can handle NAT's?

Regards Kristoffer!

Kristoffer Gronowski
Sen. Software Developer
Hotsip AB
mailto: [email-masked]
sip: [email-masked]

_______________________________________________
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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 25 Jan 2002 01:15:10 -0500

> This would encourage clients to send requests to often and possibly

I doubt this will be a frequent need, since most calls are answered or
aborted within 20s anyway. However, this requirement can be relaxed a
little, in the sense that, it needs to retransmit the INVITE if no
provisional responses are received after 20s. The resolution of the
issue with Timer C is such that the UAS will send new provisional
responses to refresh the timer, this has the benefit of also keeping the
nat binding alive.

If you want to increase this 20s value above 32s, you run the risk of
total call failure. That is a penalty of using UDP; TCP is preferred for
NAT traversal.

> It might be OK to do it more often if a 2xx response is received.

Huh? If a 2xx is received, you're done, there is no need to resend the
INVITE.

> black IP addresses and ports?

I am assuming that by "white" you mean the public address, and by
"black" you mean the private one (or perhaps, vice a versa). THis is the
first time I have heard such terms.

This is a good point, though. As far as I can tell, the value in
Translate will be the same as the rport/received in the top via, so it
is redundant. I will remove it unless someone can think of a problem
with that.

> without the address translation part. 

That depends on the policy of the firewall. Some firewalls behave that
way, others may block UDP entirely.

> This makes it more difficult to

STUN describes a mechanism for detecting the presence of this kind of
firewall. I think that will suffice. 

> both the tricky NAT's and stateful inspection firewalls!

Thats fine. Its a local policy decision that can be made by the proxy. I
can add mention of it.

> describes the contacts property and routing essential information.

I don't follow this. Why do that? The UA already knows its behind a
symmetric NAT (it did tell the registrar). The registrar knows it too.
What is gained by returning it in the contact of the registration
response?

> other UA can find it! 

If UDP is in use, the registration refreshes frequently enough that you
would notice there first, though. For TCP, the binding wouldn't change
while the TCP connection is opened. Thus, I am not sure this really adds
anything.

> If the UA can handle presence the SUBSCRIBE SIP

I don't think so. Only the register needs to be refreshed. As long as
its binding is maintained, the contact provided in the SUBSCRIBE is
valid. If, however, the binding changes, then a refresh of SUBSCRIBE is
needed. I can mention that.

> presence extension so that they can handle NAT's?

There is nothing specific that needs to be done for IM or presence. The
issue you mention above for SUBSCRIBE will occur for all methods which
establish dialogs. A general discussion for refreshing contacts in
active dialogs, when the binding changes, will cover INVITE and
SUBSCRIBE and anything else. 

Thanks for your comments,

Jonathan R.

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

Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip