Subject: [midcom] Submission of a new Internet draft

From: "Sanjoy Sen" <[email-masked]>
Date: Thu, 4 Oct 2001 18:23:11 -0500

Folks,

	We've submitted an ID called "Midcom-unaware NAT/Firewall Traversal"
describing an alternative solution framework (that is implementable today)
to solve the problem of traversing deployed NAT/FW's. Two key components of
this solution working in tandem are a SIP Proxy & an RTP Proxy. The solution
needs interaction between the Proxies, but does not need the clients know
about the NAT binds or types and is applicable to all traditional types of
NAT's/Firewalls. Attached is a copy of the submitted draft for your reading
until it appears in the IETF website.

Best Regards,

Sanjoy Sen

=========
Interactive Multimedia Server
Nortel Networks
Ph: 972-685-8274, Fax: 972-685-3813
Mobile: 972-571-2062

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 7 Oct 2001 14:33:20 -0400

A very nice draft. Some comments:.

First off, please note that your draft requires the end systems to support
symmetric RTP. You don't explicitly state that, but since you have the
clients "priming" the nats by sending RTP packets to the RTP proxy, with the
media going back to the source address. That is not normal RTP behavior, but
is what we call symmetric RTP. You can tell its symmetric RTP since, in your
proposal, the IP/port in the SDP sent from the client is actually never used
by the RTP proxy to figure out where to send media. 

The mechanism you describe in this draft is largely the same as what we
proposed in draft-rosenberg-sip-entfw-01.txt (NOT the current -02 version,
which is much different), which had the proxies performing the rewrites of
the SDP as you describe. As we began to work through the details of this
solution, it became terribly complex. THe main reason for that is that you
have to assume multiple domains, each of which has its own proxy, and that
you can have cases where the user is not natted on one side, the other side,
or both. Add to that the need to determine whether one side, the other side,
or both support symmetric RTP. 

As an example of what I mean, you show an RTP proxy only on the originating
domain. What if the originating domain doesn't support this capability? What
if the originating domain doesn't use nats at all, in fact? In that case,
the terminating proxy also needs to do this (rewrite SDP and act as a b2bua)
when its users are natted. But, what if the originating domain IS natted?
Does that mean there are TWO RTP proxies on each call setup path? 

It gets really complicated when you add, as a goal, direct media
communications whenever possible. In your proposal, media always flows
through this intermediary. Since the location of that device is generally
going to be physically uncorrelated with the location of the endpoints,
media latency can suffer a LOT. As such, you really only want that thing in
there when its needed. If you want to ensure direct media whenever possible,
then you get into further complications of making decisions based on which
type of nats there are. We came up with on the order of 100 different cases
that needed to be considered (something like 7 different yes/no orthogonal
variables).

The approach you propose also requires that there are call stateful B2BUAs
in each call path, which has significant impacts on performance and fault
tolerance in particular. The cost to the VoIP provider is VERY high from
this solution, because of all the additional rtp traffic that comes in, and
back out. 

Our conclusion was that the whole mess gets a lot easier when you push the
intelligence to the end systems. Rather than the proxy mucking with SDP,
being call stateful, and so on, the client simply discovers its public IP
address, and the type of nat, and uses that information. Once the client
knows what its situation is, it can involve a RTP media proxy only in the
case where its behing a symmetric NAT.

As such, our approach is truly a client discovery mechanism, which is
EXACTLY how it would work if midcom were deployed. If midcom were in place,
the client would talk to its enterprise/residential NAT, obtain some
addresses, and put those in SDP. No B2BUAs. No proxies mucking with SDP.
None of that. In our case, the same thing happens. However, since the client
can't speak midcom to the nat, it speaks stun THROUGH the nat, to a server
on the other side. The result is the same, though - it gets an IP address,
and puts those in SDP. No B2BUAs. No proxies mucking with SDP. The solution
retains all of the scalability and fault tolerance characteristics of SIP,
and also ensures that direct media takes place whenever possible. This saves
the VoIP provider money and improves the voice quality perceived by the
endpoints.

STUn also allows other applications to work, just as midcom will. 

As an important note on our proposal, it does not cover the symmetric NAT
case at the moment. We did originally have that in a version of the doc that
the co-authors were passing around. It requires stronger security than the
pure reflector case, since you have to have an RTP proxy of sorts, with the
stun request asking for a binding on that RTP proxy. The use of resources
like that requires better security. There were also more complex failure and
load balancing considerations. As such, its easily added back in, or even
better we think, documented separately. However, the idea is the same - the
client sends a request to the server, and the server tells it the IP address
to use.

Also, I'd like to point out Melinda's statement:

  What I'm after here is something that's more-or-less consistent
  with the midcom notion that the external address is "learned" by
  the endpoint and then used for signaling purposes. 

No such thing happens in your proposal. The endpoints are not learning their
addresses. THis is, however, exactly how stun works.

A few minor comments:

1. You write:

 4. The destination port of the requests at the Signaling Proxy 
  server is the same as the source port of the corresponding responses. 

That is not true for rfc2543, since the responses are sent to the source IP,
but to the port written in the Via header, or 5060 if not present. This will
not work through NAPT. This has been fixed with our SIP extensions for an
rport parameter:

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

which is a SIP wg work item.

2. You write:

 Proxy/Register (Signaling server). The SIP REGISTER message contains 
  an extension tag carried in the Proxy-Require header, indicating to 
  the Proxy that the client is behind a NAT (Note: the client or the 
  Proxy does not care about the type of NAT, as the same solution 
  applies to all types). This packet is NAT-ed by the Enterprise NAT 
  with a new source IP address and port. If the Proxy supports the 
  extension tag, it creates an association between the IP address and 
  port from which the packet arrived and the actual address of the 
  user. The response to the Registration message is sent to this IP 
  address and port (not to the Contact address in the REGISTER).  

This is also covered by the above draft, using the Translate header. Note
that implicit translation requests do not work, because registrations are
not always for the purpose of binding an address-of-record to the host
sending the registration.

Thanks,
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
  
-----Original Message-----
From: Sanjoy Sen [mailto:[email-masked]]
Sent: Thursday, October 04, 2001 7:23 PM
To: [email-masked]
Cc: Patrick Sollee; Sean March
Subject: [midcom] Submission of a new Internet draft

Folks, 

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

---

From: "Sanjoy Sen" <[email-masked]>
Date: Mon, 8 Oct 2001 16:17:41 -0500

Jonathan,

   Thanks for your insightful comments! Please see responses inline. 

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Sunday, October 07, 2001 1:33 PM
> To: Sen, Sanjoy [NGB:B602:EXCH]; [email-masked]
> Cc: Sollee, Patrick [NGC:B610:EXCH]; March, Sean [NGC:B642:EXCH]
> Subject: RE: [midcom] Submission of a new Internet draft
> 
> 

Yes, but the only restriction is send & receive ports are the same, which is
easily configurable in the majority of the VoIP clients available today. But
having the RTP Proxy in between allows us to avoid any SDP extensions
(needed for Symmetric RTP) needed to tell the "passive" entity to send the
RTP packets to the source address of the received RTP packets. 

The primary goal of the media proxy method is to allow deployment of
multimedia services in the fastest way possible without requiring a lot of
development on the application clients.

> the SDP as you describe. 

Quite similar. However, the draft talks about supporting SDP extensions for
Bi-directional RTP which we don't need to.

> As we began to work through the 
> details of this

To ease complexity, the following rules are used:
1. The SIP BBUA supports multiple domains.
2. All media for cross domain calls uses the RTP proxy.
3. Media for calls within the same domain (assuming the originator
and terminator have the same firewall setting) do not use the 
RTP proxy.  This implies that endpoints within the same domain
are in the same address space.  If this is not the case, then
seperate domains need to be used for each address space.

If the UA's are not behind NAT's, the RTP Proxy can be bypassed.

> Does that mean there are TWO RTP proxies on each call setup path?

The BBUAs representing the originator and terminator can be seperate. Each
BBUA is responsible for modifing the SIP signalling so that its users are
addressable.  In a cross domain call, one or more the RTP proxy(s) would
always be used when the users are NAT-ed. Even if the both the users 
are behind NAT's, the call can still go through a single RTP Proxy, when the
other domain does not support RTP Proxy. Also, if the two endpoints were
registered with the same BBUA (BBUA support multiple domains), then one RTP
proxy would be used.
 
> that needed to be considered (something like 7 different 

Media does not always flow through the RTP Proxy. If the endpoints are in
the same domain, and are behind the same NAT/FW, then media does not
traverse the RTP Proxy. 

> this solution, because of all the additional rtp traffic that 

The cost is primarily a management issue from the Service Provider
perspective. The only requirement is that the SIP Proxy will find the Media
Proxy closest to the UA. The voice quality issue is negligible because the
Media Proxy is expected to be in the Service Provider (or even within the
Enterprise) network close to the end-users. The latency impact we've noted
in live deployments in major service provider networks has been negligible.
We use standard mechanisms to deploy fault-tolerant BBUA's and RTP Proxies.
A less sophisticated version of the solution can also be used for small
Enterprise customers. On the other hand, the solution adds the benefits of
address hiding, and services such as Legal Intercept and Supervision Listen
In.  

Also, a stun-like protocol will need more software upgrades on the
Enterprise clients, which has
cost disadvantages too. Doesn't it?

> case where its behing a symmetric NAT.

The real tradeoff here is how much intelligence you want to put in the
client as opposed to
that in the network. Our solution is "simple" and "dumb" in the sense that
neither the client
nor the Proxy need to know about the Enterprise NAT binds or types. It
eliminates the need for SDP extensions for Symmetric RTP and a few of the
SIP extensions (e.g., NAT type). The tradeoff is against the performance
impact on the network, which has been discussed earlier.  Also, our solution
is targeted primarily for Enterprise customers (although applicable for
residential too), for whom we believe something like a Full Cone NAT (alone)
does not make a great deal of sense. The most prevalent (we believe to be >
90%) cases will be Restricted Cone NAT's and Symmetric NAT's, both of which
will need RTP Proxy-like devices. So our conclusion was the additional
client signaling development complexity to support Full Cone NAT's is not
worth doing. 
 
In residential environment with sharewares and other publicly available
software on the net, the stun approach is probably better since you can't
afford putting a media proxy for a single host.

> addresses, and put those in SDP. 

It depends on where the Midcom Agent resides - the client or the Proxy.
Midcom would also allow the Proxy to do all these things transparently for
the client, which is also desirable. 

> No B2BUAs. No proxies 
> mucking with SDP.

As stated earlier, the voice quality issue is negligible because the Media
Proxy
is expected to be in the Service Provider (or even in Enterprise) network
close
to the end-users.

> STUn also allows other applications to work, just as midcom will.

The usage of the media proxies do not limit the application to SIP.

> addresses. THis is, however, exactly how stun works.

It depends where the Midcom Agent is located - according to the Midcom
framework, this can reside in the client or in the Proxy. Our target is
doing minimal software upgrade on the clients. The clients in our case are
also learning the RTP Proxy address to send media to. It is also learning
about the NAT binding when the 200 OK response of the REGISTER comes back,
but we don't want the client to send it to the remote end, as we prefer the
"SDP-mangling" to happen at the Proxy instead of the client for reasons
described earlier.

> sending the registration.

Agreed.

Thanks,
Sanjoy

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 8 Oct 2001 16:20:03 -0700

> The primary goal of the media proxy method is to allow deployment 
> of multimedia services in the fastest way possible without requiring 
> a lot of development on the application clients.

The media proxy is only transparent if it is located in the immediate
proximity of the firewall, e.g. in a DMZ, so that the proxy can actually
send packets to the "private address" of the client. If this is not the
case, then you cannot have a solution that is transparent to the client;
for example, a proxy located in the middle of the network does not help
you at all if yur client is located behind a residential NAT. If you
want to do that, you need to use some form of tunnel between the proxy
and the client, and you need to run some form of proxy control protocol,
in effect a variation of the future MIDCOM protocol. 

It is true that the application needs to be made aware of the STUN
service, but there are very high incentives for application developers
to do just that: the STUN awareness can be confined to the client
located behind a NAT, which means no impact on proxies or server, and
very minimal impact on the remote client; the transmission can be
peer-to-peer, which means that there is no need to provision a proxy and
to buy extra transmission capacity for all the calls routed through it.

-- Christian Huitema

---

From: "Sanjoy Sen" <[email-masked]>
Date: Tue, 9 Oct 2001 12:44:41 -0500

Christian, Please see responses inline. Regards.

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Monday, October 08, 2001 6:20 PM
> To: Sen, Sanjoy [NGB:B602:EXCH]; Jonathan Rosenberg; midcom
> Cc: Sollee, Patrick [NGC:B610:EXCH]; March, Sean 
> [NGC:B642:EXCH]; Aoun,
> Cedric [QPD:MA01:EXCH]
> you at all if yur client is located behind a residential NAT. 

We never claimed that the media proxy is transparent to the client, did we?
The client is unaware of the differences between the media destinations. I
also
wanted to point out here that this is exactly what you need for legal
intercept.
We sure need a control protocol between the Signaling & Media proxies, but
an existing device control protocol can be virtually reused.

> very minimal impact on the remote client; 

Yes, but there're other network elements involved such as reflectors, as
well as control protocol between client-reflector and between the
reflectors. Also, for types of NAT which we believe to be the most prevalent
among Enterprise, you've to involve some sort of Media proxy. Not sure how
much we gain here? 

> the transmission can be

In our case, the clients can bypass the RTP Proxy (i.e., peer-peer) when
they're not behind NAT's or behind the same NAT.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Oct 2001 10:01:16 -0400

Inline.

-----Original Message-----
From: Sanjoy Sen [mailto:[email-masked]]
Sent: Monday, October 08, 2001 5:18 PM
To: 'Jonathan Rosenberg'; [email-masked]
Cc: Patrick Sollee; Sean March; Cedric Aoun
Subject: RE: [midcom] Submission of a new Internet draft

>Yes, but the only restriction is send & receive ports are the same, which
is easily 
>configurable in the majority of the VoIP clients available today. But
having the RTP 
>Proxy in between allows us to avoid any SDP extensions (needed for
Symmetric RTP) needed 
>to tell the "passive" entity to send the RTP packets to the source address
of the 
>received RTP packets. 
multimedia services 
>in the fastest way possible without requiring a lot of development on the
application 
>clients.

Well, you are already requiring changes to the clients for the SIP
extensions. Once you need to touch them even a drop, there is not much pain
for additional changes.

>Quite similar. However, the draft talks about supporting SDP extensions for
Bi-
>directional RTP which we don't need to. 

And the reason for that is that you are using an external intermediary so
long as either of the parties is behind any kind of nat. This is really the
fundamental issue. My goal is to provide a solution that is cheap for
providers to deploy, and provides acceptable voice quality to users. To me,
that means I avoid triangle routing of media to the provider's network,
which is both expensive and can add a huge amount of delay. It also gets in
the way of things like SRTP, which would not be possible end-to-end with
your solution. In our solution, we end up with an intermediary ONLY when
both sides are behind symmetric NATs, which is a much much smaller subset of
cases.

In fact, if you take the pain of always going through an intermediary, there
are even simpler solutions than yours. Just use a VPN, for example. THis
way, the client sends all media and signaling through a VPN server in the
providers network, and the VPN would provide the client with a publically
routable IP on the VPN server. Problem solved, and we could do it without
touching the clients. 

Why is this a bad solution? Well, the provider now needs to handle all this
RTP traffic through the VPN server, and voice latencies will frequently be
bad. Same with your approach.

>2. All media for cross domain calls uses the RTP proxy. 

Which will indeed result in two intermediaries for cross-domain calls where
both sides are natted.

>Media does not always flow through the RTP Proxy. If the endpoints are in
the same 
>domain, and are behind the same NAT/FW, then media does not traverse the
RTP Proxy. 

I think you will find that determination of this (whether both endpoints are
behind the same NAT) is a very nontrivial exercise. I think you have a
centrex-style model in mind for this, where you can tell by the domains in
the From and To fields whether both are behind the same nat. That won't work
in dozens and dozens of cases. The most basic case is where I am behind an
enterprise nat, and am using service from a retail provider (say, foo.com),
so that my address is sip:[email-masked]. If I call someone else who also
has a foo.com address, but who works in a different enterprise, how, per se,
will the foo.com proxy know whether we are behind the same nat (which we're
not in this case) or a different one?

>The cost is primarily a management issue from the Service Provider
perspective.

That is false. It is false because you have made an unreasonable assumption
about topological and geographical proximity, see below.

>The only 
>requirement is that the SIP Proxy will find the Media Proxy closest to the
UA. The voice 
>quality issue is negligible because the Media Proxy is expected to be in
the Service 
>Provider (or even within the Enterprise) network close to the end-users. 

That is a monstrous assumption that will almost always NOT be true. Your
assumption is a specific centrex-like model where the provider contracts
with the enterprise, so that they can place an RTP proxy near the enterprise
nat, but on the public side of it. That is a very specific, very narrow
case, and will not work for any kind of retail model. Much more common will
be when you have a retail provider (like net2phone, dialpad, deltathree,
etc.) who signs up customers. The provider has no relationship with the
enterprise (if there even is one, remember residential users!). They don't
know the network topology. How is the provider to select an RTP proxy that
is topologically and geopraphically close to the subscriber?? That is a
known HARD problem, and I would assert that the costs of solving it are
profound (requiring deployment of a network similar to Akamai in order to do
this). How can you realistically claim that this is not prohibitively
expensive?

Even without a distributed RTP proxy network like this, its expensive. The
more likely case is that the provider has a farm of RTP proxies in their
primary data center (say, in San Jose). This means that a call from me to my
neighbor will go from New Jersey, to San Jose, and back to Jersey. That adds
substantial latencies, and is also expensive for the provider. Now, they
need to by enough bandwidth in the S.J. data center to support twice the
bandwidth (in and out) for each simultenaous call they would ever carry! How
can you claim that is not expensive? Compare that to the alternative where,
using stun, almost no traffic flows through an intermediary (and arguably,
you might not even bother with one). Thus, you need only be a signaling
point, not a media transit point. Much cheaper, much lower latency.

>Also, a stun-like protocol will need more software upgrades on the
Enterprise clients, 
>which has 

You are already doing that even in your solution.

There are not so many SIP clients deployed at this time in any case. Let us
do it right while we still can.

>The real tradeoff here is how much intelligence you want to put in the
client as opposed 
>to 
neither the 
>client 
eliminates the 
>need for SDP extensions for Symmetric RTP and a few of the SIP extensions
(e.g., NAT 
>type). The tradeoff is against the performance impact on the network, which
has been 
>discussed earlier. 

You are already changing the client. You are changing the proxies. Whether
you change them "more" with a few additional capabilities is irrelevant in
terms of total cost. However, the operational cost of your solution is high,
whereas it is nearly zero in our proposal.

> Also, our solution is targeted primarily for Enterprise customers 
>(although applicable for residential too),

I would like to know how you have solved the problem of locating RTP proxies
close to residential users. 

 for whom we believe something like a Full Cone 
>NAT (alone) does not make a great deal of sense. The most prevalent (we
believe to be > 
>90%) cases will be Restricted Cone NAT's and Symmetric NAT's, both of which
will need RTP 
>Proxy-like devices. 

That is not a consistent assessment from what I have heard from people who
have actually tested them. I hear its about 30% full cone, 40% restricted
cone. 

>It depends on where the Midcom Agent resides - the client or the Proxy.
Midcom would also 
>allow the Proxy to do all these things transparently for the client, which
is also 
>desirable. 

In your solution, there are two nats - the residential/enterprise one, and
the "RTP proxy" which is effectively a nat as well. You are using midcom
from your sip B2BUA to that media proxy, but there is no midcom type of
solution for the first nat. My point is, if midcom were deployed, we would
not use your solution at all. The client would talk to its
enterprise/residential nat, and obtain a binding, and put that in its SDP in
the INVITE. There would be no RTP proxy. Our approach mirrors what the
solution would be if we had midcom, but I talk through the nat, instead of
to it.

>The usage of the media proxies do not limit the application to SIP. 

It limits it to applications that use media proxies. For H.323, you could
reuse them, but you'd need to upgrade your gatekeepers to do this. It would
not be useful at all for games, for example.

That is not true for stun. Stun is just as useful for a game where I need to
receive UDP updates of game moves. It works even when there is no network
server at all (like gnutella), and it requires NO relationship between the
stun server and the application. Indeed, people with public IP connectivity
could simply deploy stun servers as a public service, to assist people in
discovering and dealing with their nat connectivity.

Stun also helps with diagnostics, and allows you to launch a complaint
against a provider or vendor for deploying a nat when you didn't think there
should be one of that type.

-Jonathan R.

---

---

From: "Patrick Sollee" <[email-masked]>
Date: Thu, 11 Oct 2001 11:15:53 -0500

Jonathan,

As you say, your proposal requires an intermediatary when 
symmetric NATs are used. Most enterprises have firewalls in
addition to NATs.  These firewalls, when "UDP conversations"
are activated, function in a similar way to symetric NATs.
(allow inbound traffic only from IP+Port where traffic was
sent to).

If both domains in a cross domain call are hosted by the same
service provider then only 1 RTP Proxy is used.

Each endpoint is responsible for knowing if it is behind a 
firewall/NAT. This is done during configuration of the 
endpoint.  If a single domain spans multiple different
IP address space, then that domain is configured to route
all media via the RTP Proxy. We have observed that the most
common case, though, is a particular enterprise has one domain, and
the devices within that domain are in the same IP address
space. This allows media to stay within the enterprise (not
use the RTP Proxy).

Determining which RTP Proxy to use based on the location of the
client is a difficult issue in the pure residential case. However,
it is not difficult in the enterprise case.

As for delays encountered when using the RTP Proxy, an argument 
could be made that it will be less, since the path from the ISPs
to the SIP telephony provider would be well known, and hence 
provisioned with large bandwidth. As opposed to the path directly
from one endpoint to another, where the path travers many hops.
In addition, once the media traffic hits the SIP telephony provider,
it will be treated with greater care (less hops, more bandwidth) than
it would be treated on the internet.

Thanks,
Pat

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Thursday, October 11, 2001 9:01 AM
To: Sen, Sanjoy [NGB:B602:EXCH]; Jonathan Rosenberg; [email-masked]
Cc: Sollee, Patrick [NGC:B610:EXCH]; March, Sean [NGC:B642:EXCH]; Aoun,
Cedric [QPD:MA01:EXCH]

Inline.

-----Original Message-----
From: Sanjoy Sen [mailto:[email-masked]]
Sent: Monday, October 08, 2001 5:18 PM
To: 'Jonathan Rosenberg'; [email-masked]
Cc: Patrick Sollee; Sean March; Cedric Aoun
Subject: RE: [midcom] Submission of a new Internet draft

is easily 
having the RTP 
Symmetric RTP) needed 
of the 
multimedia services 
application 

Bi-

the same 
RTP Proxy. 

perspective.

UA. The voice 
the Service 

Enterprise clients, 

client as opposed 
neither the 
eliminates the 
(e.g., NAT 
has been 

believe to be > 
will need RTP 

Midcom would also 
is also 

-Jonathan R.

---