Subject: [midcom] Framework-02 - NAPT Service Example

From: "Bob Penfield" <[email-masked]>
Date: Tue, 19 Jun 2001 16:00:04 -0400

Suresh,

I have a few minor issues/questions with the NAPT service example.

In section 7.2 it says:

   SIP calls to the private SIP phone will
   arrive as TCP/UDP sessions with destination address and port set
   to Ma and 5060 respectively.

I think this might be a bit misleading. The SIP messages flowing from the
external phone to the private phone will arrive at the SIP Proxy first.
According to the time flow, the proxy asks the middlebox for the port
previously bound to Ma:5060 (presumably the private phone's SIP port
Pa:5060). Is their an assumption here that the private phone has registered
with the proxy to establish the NAT for the SIP port? Or does this mean that
the proxy knows the private address and is establishing the NAT for the SIP
flow?

Using just one port (Ma:5060) is fine if there is only one SIP phone in that
private network. If there is more than one SIP phone, additional ports on
the middlebox (Ma) will be needed for mapping to private phones.

I believe someone (maybe me) suggested that an example where the proxy was
inside the private network might be a little simpler. Also, I think it might
be a more likely scenario in real deployments.

When the proxy is inside the private network, only one NAT is needed for the
SIP message flow. The SIP proxy would establish the mapping of Ma:5060 to
its SIP port (let's call it Sa:5060 where Sa is the IP address of the SIP
proxy) when it started up. This would make the above statement from section
7.2 correct. The proxy knows how to route the SIP messages to all the SIP
phones in the private network. For a given session, only the NAPT operations
for the RTP and RTCP streams would be required.

I think the "100 Trying" response in all the flows should be immediately
after the proxy receives the INVITE to stop the calling side from
retransmitting the INVITE.

thanks,

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

From: Andrew Molitor <[email-masked]>
Date: Tue, 19 Jun 2001 17:19:09 -0500 (CDT)

> the proxy knows the private address and is establishing the NAT for the SIP

	Gosh, this certainly is confusing now that I look closely!

	There are a couple of ways to make this scenario work, in
SIP-land. That is, the scenario where the proxy (which we assume includes
the SIP registrar function) is outside, and the phone(s) are inside.

	One way is described in great and wonderous detail by Rosenberg
et al:

	- the phone registers using TCP, which flows through the NAT/NAPT
	  widget in the normal way -- no MIDCOM involved, really.
	- the phone keeps the TCP stream open
	- the proxy, upon receipt of an INVITE, searches live TCP
	  streams FIRST before consulting its database

	In this scenario, the SIP proxy doesn't need to know the phone's
private IP address, or do any NAT binding work to pass signaling to the
phone. For this scenario, picture is too complicated, containing a
bunch of stuff for binding port 5060 and so on. With a middlebox,
the other elements of the Rosenberg et al proposal become mostly
unnecessary.

	Another way to to teach the proxy about private IP addresses.
It could know that [email-masked], 192.168.1.1' is behind
middlebox A, and [email-masked], 192.168.1.1' is behind
middlebox B. Then, when an INVITE comes in for [email-masked]
it can do MIDCOM magic to middlebox A, requesting a binding of
'192.168.1.1, port 5060', and get back 'Ma:<some random port>'
which it uses to send signaling to Andrew's phone (note: NOT to port
5060!). Of course, when a call comes in for the esteemed Mr. Penfield,
the proxy does the exact same thing -- to a different middlebox.
This resolves the apparent ambiguity of two people, both registered
at 192.168.1.1.

	For this scenario, the picture is about right, but neglects
the fact that for more than one phone, they really can't all use Ma:5060,
they'll have to use Ma:<random port>.

> the middlebox (Ma) will be needed for mapping to private phones.

	Precisely!

> be a more likely scenario in real deployments.

	Much easier. It allows the use of perfectly ordinary proxies,
as well, instead of proxies which extend SIP (or interpret SIP is rather
specific ways, as in the Rosenberg-like scenario).