Subject: [midcom] new I-D on "symmetric STUN"

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Nov 2001 15:34:28 -0500

Folks,

I've talked in the past about the fact that STUN used to have a bit about
handling the symmetric case, but that we yanked it out since its
sufficiently orthonogonal (and a fairly crowded space). I've just submitted
an I-D that documents that piece of the solution. Its a very simple
mechanism, more or less the same as STUN, which uses a relay server. The
protocol is called "Traversal Using Relay NAT" or TURN. Until it appears in
the archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-00.txt

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 15 Nov 2001 18:45:12 -0500

-----Original Message-----
From: Steve Davies [mailto:[email-masked]]
Sent: Thursday, November 15, 2001 4:42 PM
To: 'Jonathan Rosenberg'; [email-masked]'
Subject: RE: [midcom] new I-D on "symmetric STUN"

>Interesting TURN of events or should I say 'U TURN'. 

This is not a u-turn at all. I have mentioned this aspect of the proposal on
the list for sometime. I myself am still hazy on the merits of an
application layer vpn style approach (which is what this, and yours, are),
as compared to pure VPN. Indeed, there is a section in my draft which begins
to discuss the issues.

>Puns aside, this proposal says nothing that hasn't already been proposed.

Really? It is not bitwise or semanticwise identical to your proposal, so how
do you claim it has already been proposed? It avoids a control connection,
which you have. It avoids tunnelling, which you do. It avoids the
complexities of the probe packets, which your proposal has, and mine does
not. Thus, how do you claim this is the same?

> While I am 
>pleased to see TURN uses IDENTICAL concepts to the Davies proposal,

See above, for at least three substantive differences. We've focused on
simplicity. Thats not the same. Both do obtain addresses for use in UDP and
TCP from an intermediary. That is certainly shared, but its also unavoidable
for a solution to the symmetric problem. Even VPN and RSIP do this too. The
differences are in how this is done.

> it contains many flaws 
>(too numerous to go into here).

A fine technical assessment! Thats right up there with "it just won't work"
and "it won't scale" in the category of vacuous criticisms.

>If we agree on the concepts and Jonathan et al are 
>interested in a quick solution, then surely it makes sense to jointly work
on the most 
>mature incarnation of those concepts. Why re-invent the wheel?

Indeed. With existing VPN solutions I am unsure about the need for TURN or
your proposal. My document at least begins to discuss what the pros and cons
might be. Interesting to note that STUN is the only protocol that actually
does something new. 

-Jonathan R.
---

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 15 Nov 2001 17:38:14 -0800

Jonathan,

I believe that in your Figure 2, message (4), the port number for the mapped
address 
should be "1124" and not "1123".

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, November 14, 2001 12:34
> To: [email-masked]'
> Subject: [midcom] new I-D on "symmetric STUN"
> 
> 
> Folks,
>

---

From: Mark Taylor <[email-masked]>
Date: Fri, 16 Nov 2001 06:45:58 -0800 (PST)

The main difference between the Davies and STUN/TURN
is that one speaks of a firewall strategy while the
other is effectively silent. The other differences are
really inconsequential and superficial.

What benefits does the Davies firewall strate3gy
bring?

In addition, the purpose of STUN is really not clear
to me. The information that it gathers seems to be
something that would be done only very rarely and
could probably be obtained from an inquiry to the
network designer. Indeed if the answer turns out to be
a symmetric NAT, a TURN server would have to be
provided outside of the NAT which is something that
would have to be done physically. STUN and TURN as
protocols that adapt to network configurations is a
concept that seems very fuzzy to me. I must be missing
something about their operation.

__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Nov 2001 03:49:06 -0500

John,

You are right; we need to have real differences discussed and honest
assessments of strengths and weakenesses. Let me try to do that.

STUN by itself is a bit hard to compare to the Davies proposal since its a
bit of apples/oranges. STUN provides a discovery capability, which is not
present in the Davies draft. STUN allows you to obtain an address from your
own nat that you can use in applications, which the Davies draft doesn't.
The Davies approach is to not bother with such things, and instead go for
the full symmetric solution in all cases. This has the advantage of being a
single solution which works broadly, but this generality comes at a cost.
The cost is that media is ALWAYS routed to the provider network, even when
it doesn't really have to. The result could be big increases in latency (I
call my neighbor; my provider is on the west coast, so my media goes from
New Jersey to California and back to New Jersey), and also additional cost
for the provider to purchase the bandwidth for the media to come in and go
back out. I personally believe that we should be avoiding triangle routing
of media at all costs. Whether you agree with that will heavily influence
your assessment of the solutions.

TURN is more comparable to the Davies draft. They share commonalities. Both
use a service provider intermediary to terminate UDP and TCP traffic. Both
provide the client with an IP address and port that will route to this
intermediary. Both support bidirectional sending on the "connections"
established between the client and the intermediary. There are many
differences too:

 * the Davies proposal uses a single connection between the client and
intermediary, over which control commands and outbound TCP and UDP
"subchannels" can be established. There is no such thing in TURN. The reason
is that the Davies draft assumes that outbound TCP connections would only be
allowed towards a statically configured address and port, that of the
intermediary. So, all other traffic needs to go within this connection, and
thus muxing is needed. I found this odd; if the firewall policy prevents
outbound TCP connections to anywhere but the intermediary, and the
intermediary's job is to allow you to make outbound TCP connections to
anywhere, for example, this would be a violation of enterprise firewall
policy. Similar for UDP. So, TURN assumes that the firewall allows outbound
UDP and outbound TCP to anywhere, since if it doesn't, you're not supposed
to be doing it anyway. Since the assumption is a firewall policy that allows
outbound messaging anywhere, the need for a separate multiplexed connection
is eliminated in TURN.

* the Davies proposal uses a "control channel" within their multiplex
connection. The presence of a separate control channel allows for messaging
to the client outside of the "data channels" that are established. One of
the things this enables is for a tcp listener to be created at the
intermediary, and for that listener to have lots of connections made to  it.
As each connection is made, the client is informed of this (through the
control channel). Since TURN has no control channel, there is no ability to
let the client know when a connection is established, and no ability to
support multiple connections to a specific listener. Its a one-one mapping
only. This would not be sufficient for building a web server behind a NAT,
for example, but thats not what TURN is trying to solve. Presumably, if the
enterprise is disallowing incoming connections from anywhere to the inside,
its to prevent users from doing things like running a web server. If the
enteprirse is allowing outbound TCP, it means its OK for the user to make a
connection to a single peer. So, we support a similar model, but with roles
"turned" - you have a single connection to a single peer, but its initiated
from the peer rather than from you. TURN doesn't let you do more than that.
When only a single peer can connect to a TCP listener, you don't need much
of the functionality in the Davies draft.

* The Davies proposal has this interesting "probe" mechanism that allows the
intermediary to associate a UDP "connection" from the client with commands
on the control channel. The association is only needed because commands can
be sent on the channel. The commands allow you to do things like explicitly
set the remote destination, even changing it after its set up. There is no
such capability in TURN, for much the same reasons as described above. TURN
allows a client to connect to a single peer with UDP, its just that the peer
initiates, instead of the client inside. Thats it. With that restriction,
there is no need to set the remote addresses, or to change them, and thus
the control channel is not needed, and thus the probes are not needed. 

Overall, TURN is much, much simpler than the Davies proposal since:

(1) it does not attempt to do things that are outside of the scope of the
administrator's firewall policy,
(2) it does less than the Davies proposal, because it merely supports peer
to peer connectivity where the external entity initiates to the inside,
rather than the other way around (thus the name TURN). Because it does less,
its oodles simpler.

If you want to do things like build an HTTP server, you are far better off
using a VPN, IMHO. TURN is meant to facilitate a class of applications that
have requirements similar to client-server applications permitted by
firewalls and NATs, but where the "server" is unknown, and it initiates
communications to the client first. This includes a LOT of applications, I
think, and because it tries hard to stay within the bounds of enterprise
firewall policy, is something I believe administrators would be aggreable to
allowing. 

I hope I have not misrepresented features in the Davies draft; I am sure
Steve will correct me with vigor in the event that I have.

Thanks,
Jonathan R.

---
  
-----Original Message-----
From: John LaCour [mailto:[email-masked]]
Sent: Thursday, November 15, 2001 4:58 PM
To: 'Steve Davies'; 'Jonathan Rosenberg'; [email-masked]'
Subject: RE: [midcom] new I-D on "symmetric STUN"

Steve,

You may or may not be correct, but this message does next to nothing
to help any of us evaluate the merits of either proposal.

Just because something was created earlier or even implemented doesn't
make it inherently better.

Rather than try to strong-arm us, you really need to enumerate the many
flaws and how your proposal addresses them.  If you want to be
completely forthcoming coming you should also discuss the weaknesses
of your own proposal and why you've made those trade-offs.

In fairness to you and Jonathan, I haven't done a thorough review of
either proposal yet.  This message should not be misconstrued
as  supporting either proposal.  Rather I'm trying to encourage
you to tell us something useful.

-John
-----Original Message-----
From: Steve Davies [mailto:[email-masked]]
Sent: Thursday, November 15, 2001 1:42 PM
To: 'Jonathan Rosenberg'; [email-masked]'
Subject: RE: [midcom] new I-D on "symmetric STUN"

Interesting TURN of events or should I say 'U TURN'. 
Puns aside, this proposal says nothing that hasn't already been proposed.
While I am pleased to see TURN uses IDENTICAL concepts to the Davies
proposal, it contains many flaws (too numerous to go into here). Fix those
flaws and you end up with the Davies proposal. Not only does TURN come a
month after the deadline set in Melinda's rules of engagement, but the
development of such a new and immature proposal is by definition not in the
best interests of a pre-midcom solution. If we agree on the concepts and
Jonathan et al are interested in a quick solution, then surely it makes
sense to jointly work on the most mature incarnation of those concepts. Why
re-invent the wheel?
Steve 
-----Original Message----- 
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: 14 November 2001 20:34 
To: [email-masked]' 
Subject: [midcom] new I-D on "symmetric STUN" 

Folks,

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Nov 2001 04:24:05 -0500

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Thursday, November 15, 2001 8:38 PM
To: 'Jonathan Rosenberg'; [email-masked]'
Subject: RE: [midcom] new I-D on "symmetric STUN"

>Jonathan, 
>I believe that in your Figure 2, message (4), the port number for the
mapped address 
>should be "1124" and not "1123". 

Yup. Thanks.

-Jonathan R.

---

---

From: Orit Levin <[email-masked]>
Date: Sat, 17 Nov 2001 08:31:55 -0500

Closely following the latest developments on this arena, I also was amused
(and pleased) by the latest TURN of the events.
Without bothering with the syntax of the both proposals, I could see that
TURN technique is a (central) part of the "Davies complete solution".
1. STUN suggests learning the topology and (if possible) achieving traversal
without help from a proxy on the public side.
2. TURN suggests a protocol between a single entity in the private network
and a server on the public side in order to pinhole the NAT "from the
inside" (complying with the local security policies) and use this hole (in a
strictly managed manner) to send the traffic from the public side through
the public server.
The single entity in the private network can be a proxy (representing many
end users) if agreed with the local policies. In this case it is highly
desirable to be able to use a single "hole" on behalf of these many users.
Note, that it doesn't make this solution tunneling or VPN. 
4. Davies proposal builds around this basic "pinholing technique" an added
feature: if the server in the private network is installed (for the reason
explained above), it talks to the public server (using Davies protocol) in
order to agree on a single hole for all the transferred streams.
5. At this stage of the solution, having two servers talking to each other
on both sides of the firewall/NAT, it is tempting to add additional
tunneling/VPN solution for the "signaling part" of the story. It is more
secure (because it is closer to a real VPN) and in some situations would be
the only working solution. It doesn't necessarily mean that there is a need
for additional standardization for this case.
 
I see a problem with current Davies proposal in a sense that it bundles all
the steps above tightly together. On the other hand, Davies solution
successfully uses the exact technique presented in TURN for a couple of
years now. Moreover, there are additional proprietary implementations in the
market that have been inspired by NAT behavior and RSIP efforts and are
using the same idea, documented in TURN.
 
I believe, that we need to integrate the theory with the practical
experience in a single TURN protocol including functionality (4) above. It
improves the solution a lot. In terms of security, you will not install a
server in your private network if your policy doesn't allow for it.
I would like to hear from Steve Davies whether my understanding is correct
and what additional flows the current TURN may have. 
 
Also, it may be very helpful to publish the expanded Davies solution (and
other solutions) as a common practice documents so that the community would
better understand existing techniques with their pros and cons.
 
Orit Levin
Chief Architect
RADVISION Inc.
TEL: +1.201.529.4300 x 230
FAX: +1.201.529.3516

-----Original Message----- 
From: Jonathan Rosenberg [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: 14 November 2001 20:34 
To: [email-masked]' 
Subject: [midcom] new I-D on "symmetric STUN" 
 
Folks, 
<http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-00.txt>  
http://www.jdrosen.net <http://www.jdrosen.net>                       PHONE:
(973) 952-5000 
http://www.dynamicsoft.com <http://www.dynamicsoft.com>  
  
_______________________________________________ 
midcom mailing list 
[email-masked] 
http://www1.ietf.org/mailman/listinfo/midcom
<http://www1.ietf.org/mailman/listinfo/midcom>

---

From: Steve Davies <[email-masked]>
Date: Mon, 19 Nov 2001 17:04:48 -0000

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: 15 November 2001 23:45
To: 'Steve Davies'; Jonathan Rosenberg; [email-masked]'
Subject: RE: [midcom] new I-D on "symmetric STUN"

>>... this proposal says nothing that hasn't already been proposed.

> do you claim it has already been proposed?  

The reason I said that TURN is the same as what has been proposed elsewhere
is because it uses the following core concepts in common with other
proposals made to the list, including the Davies proposal (henceforth called
FANTOM - Firewall And NAT Traversal Overt Method). 

The common core concepts includes:
* the use of a public forwarding intermediary, 
* ensuring all connections are outbound connections, 
* use of designated ports on the intermediary to which outbound connections
are made and from which in-bound traffic comes
* a client-server protocol to dynamically map and track (a) the logical
channels the terminal/endpoint is using 
with (b) outbound connections to the intermediaries with (c) unique
transport addresses dynamically allocated on the server. 

Both TURN and FANTOM use these core concepts to build a solution. Without
them, neither would work. TURN presents as if it were a new concept for the
group, whereas the concepts have been presented in other drafts presented to
the list. These concepts have also been explained in public presentations
for the past year. As a minimum a new draft of this nature, coming after the
other drafts, should compare and contrast what it is saying with what has
already been presented.

True, at the bit level the protocols are different, but there are likely to
be many thousands of permutations using the above concepts that achieve the
similar or the same results. I do not think it is in the groups interest to
enumerate all of these individually.  Instead, it would be better to discuss
the strengths and weaknesses of the methods used to implement the concepts,
and explore those variations as a group, hopefully developing an optimal
bit-level solution (subject to the time constraints that we have).  This
isn't achieved by presenting an allegedly new solution in isolation. If it
is felt that the differences in TURN have value, then it would have been
better to present TURN as a delta to the FANTOM (or Sen) procedure, along
with a discussion of why it is better.  The debate would then have moved on,
rather just being mired even further.

The key contributors to the resulting solution would then be able to present
a combined draft that included the insight of the whole group.  After all,
given the short time scale we have, collaborating and working together, with
proper respect for each parties contributions, is going to be the fastest
way to get to a deployable solution.

Steve

---

From: "Sanjoy Sen" <[email-masked]>
Date: Tue, 27 Nov 2001 16:32:41 -0600

Steve et. al., 
 
   I'm catching up with the discussions after a period out of office. Some
comments/questions on FANTOM. My apologies if they have already been
discussed.
 
1) Your App. Proxy is also an RTP Proxy. So for a simple two party call
where both are behind NAPT, the media need to traverse at least 3 RTP
proxies. Is this correct? 
 
2) Not sure what you gain by making the media go through the App. Proxy? For
example, in our proposal, we have the terminal send the empty RTP packets
(equivalent to your probes) directly to the Media intermediary in the SP
network to establish the media binds. 
 
3) For SIP services, your AP and PEA both will house a SIP Proxy function,
RTP Proxy function, as well as your control protocol+ RTP/RTCP probes. What
is the implication of putting all these functions in one box from capacity,
fault-tolerance and security p.o.v. ? For example, the AP will be doing
refreshes for all NAT binds for all RTP sessions on behalf of all terminals.
 
4) Are you planning on using a standard protocol as this control protocol?
In Sen proposal, we've used an existing device control protocol. The sen
proposal essentially needs no new protocol development.
 
5) Your requirement for always allowing traffic from some "well-known"
address/port of PEA to the AP in the private network is a big concern. This
is typically NOT done in traditional enterprise FW. Such a FW will typically
close the pin-hole after sometime, hence the need for signaling path
refreshes (using PING or REGISTER) both in our scheme and Jonathan's.

Thanks,
Sanjoy

-----Original Message-----
From: Steve Davies [mailto:[email-masked]]
Sent: Tuesday, November 20, 2001 11:18 AM
To: 'John LaCour'; [email-masked]'
Cc: 'Jonathan Rosenberg'
Subject: RE: [midcom] new I-D on "symmetric STUN"

John, 

You are quite right. This email didn't help move the debate forward much.
I'm afraid I got a little frustrated with the politics. Nevertheless, I
stick by my statements so let me give you a couple of examples of the flaws
I see. 

* FANTOM uses an out-of-band signalling method 'Create Media Flow' to assign
transport addresses on the remote server/public intemediary. It then sends
outbound UDP Probes (with a session identifier) to create the dynamic NAT
assignment and to complete the mapping between the resultant random source
port the probe came from, and the transport addresses the Create Media Flow
method assigned, and the call. The first probe effectively creates an
outbound UDP connection down which media may flow in either direction for
that call. Please note that media is NOT tunneled in FANTOM.

TURN tries to simplify this approach by combining the 'probe' (the method to
create the dynamic NAT assignment) with an in-band signalling method to
assign transport addresses on the public intermediary. This is the ALLOCATE
method in TURN. 

One of the main reasons FANTOM has out-of-band signalling was to conform to
the spirit of RTP/RTCP by assigning consecutive port pairs to represent the
receive RTP/RTCP addresses at the intermediary. A single method 'Create
Media Flow' does that. Having grabbed a port pair, 2 UDP outbound
connections are needed to the intermediary to receive the respective RTP and
RTCP flows. Hence the Probes. 

TURN cannot conform to the spirit of RTP in this way because the ALLOCATE
method only reserves a single transport address on the intermediary. If it
requested 2 transport addresses, a probe or very similar mechanism would be
required to establish the second outbound UDP connection. Even worse, the
way TURN is specified, there is a good chance that as a TURN server runs out
of resource the associated RTP and RTCP transport addresses could have
different IP addresses. NOT ALLOWED.

There are many other advantages to using a separate Probe message. One very
good use of probes is to keep NAT bindings assigned, i.e. they are sent at
regular intervals to prevent the NAT from timing out. TURN has no probe or
NAT keep-alive methods which breaks the solution on at least 2 counts. In
one case, a terminal may make an ALLOCATE to obtain an address with which to
register with a public SIP proxy. It then sits there waiting to receive
incoming calls. However, without some traffic such as a probe or a NAT keep
alive, the NAT assignment created by the ALLOCATE times out, which means the
terminal won't receive incoming call notifications. A second case when the
NAT binding may time out is when the remote party is not talking and their
terminal implements silence suppression. 

FANTOM uses probes to ensure this doesn't happen. In FANTOM probes are
designed to be easily recognisable in order to help the implementation of an
efficient forwarding intermediary.

* TURN doesn't use a tunnel. FANTOM does. Some think that this implies
FANTOM is a VPN variant. FANTOM is most definitely not, but we'll deal with
that separately. FANTOM uses a tunnel for multiplexing out-of-band call
control and the out-of-band FANTOM client-server protocol into a single
connection. The connection is TCP because we valued reliability and the
life-time is more easily managed by the NAT. It could be UDP but we didn't
feel we needed to re-invent a UDP session with TCP characteristics. 

We envisaged that the client end of FANTOM would be implemented in severals
ways. For example, it could be implemented in a standalone system, serving
many terminals in a single enterprise. In Centrex applications there would
be no local proxy. In this case the FANTOM client would have to handle
multiple simultaneous call setups and cleardowns. We judged a single
persistant tunnel for all call control from the FANTOM client to FANTOM
server was the most efficient use of resources. 

To avoid tunnels, a similar TURN implementation would require the standalone
client to create many UDP connections to the intermediary - one for each
terminal wanting to receive incoming calls. As we remarked above, these UDP
connections need to keep NAT bindings through some sort of NAT-keep-alive
messages. The SEN proposal implemented a similar technique and found it to
be too resource intensive - hence their SIP proposal extensions. 

Having a tunnel in FANTOM has further advantages, not least in allowing
out-of-band signalling and control. The benefit here is that the protocol
can be extended to include other functions such as network management
without breaking the architecture. We want FANTOM to be extensible.

This email is getting quite long so I'll conclude by remarking that I hope
that these explanations indicate that while  FANTOM appears more complex
than TURN, there is a reason behind each method FANTOM implements. We
haven't made it complex for complexity's sake. FANTOM may be unfamiliar, but
that's no reason to start from scratch which I fear TURN is. 

Steve 

-----Original Message----- 
From: John LaCour [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: 15 November 2001 21:58 
To: 'Steve Davies'; 'Jonathan Rosenberg'; [email-masked]' 
Subject: RE: [midcom] new I-D on "symmetric STUN" 

Steve, 

  

-John 
-----Original Message----- 
From: Steve Davies [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, November 15, 2001 1:42 PM 
To: 'Jonathan Rosenberg'; [email-masked]' 
Subject: RE: [midcom] new I-D on "symmetric STUN" 

Steve

---

From: Steve Davies <[email-masked]>
Date: Fri, 30 Nov 2001 14:49:56 -0000

Sanjoy,

Thanks for the questions. Answers in-line....

-----Original Message-----
From: Sanjoy Sen [mailto:[email-masked]]
Sent: 27 November 2001 22:33
To: 'Steve Davies'; 'John LaCour'; [email-masked]'
Cc: 'Jonathan Rosenberg'
Subject: RE: [midcom] new I-D on "symmetric STUN"

[snip] 
 
> 1) Your App. Proxy is also an RTP Proxy. So for a simple two party call
where both are behind NAPT, 
> the media need to traverse at least 3 RTP proxies. Is this correct?

Ans: The FANTOM client, like the TURN client, may be implemented on the UA,
in which case only the external RTP proxy is traversed, as in your proposal.
The FANTOM client may also be implemented as a standalone system or be
co-resident in an IP-PBX or IAD. In this case you are correct. Why? See 2
below.  
 
> 2) Not sure what you gain by making the media go through the App. Proxy?
For example, in our proposal, 
> we have the terminal send the empty RTP packets (equivalent to your
probes) directly to the Media 
> intermediary in the SP network to establish the media binds. 

Ans: The reason FANTOM is specified in this way is because we felt a
pre-midcom solution should require ABSOLUTELY NO changes (protocol or
behavioural) to enterprise endpoints and should work with existing systems.
FANTOM places NO pre-requisite for symmetric bi-directional, continual RTP.
The FANTOM client is responsible for making outbound UDP connection and the
NAT keep-alives, so the UA can implement uni-directional RTP or silence
suppression if it wishes. A major benefit of the FANTOM client (whether
co-resident or standalone) is that we can minimise the pin-holes required in
the firewall to just a few - our optimal solution is just 3 - one TCP and 2
UDP. With FANTOM, a FW admnistrator can restrict external UDP to just
symmetric UDP to/from the FANTOM server's 2 UDP ports. With your proposal,
the firewall administrator has to work on IP addresses of the RTP proxies,
which means that as the service scales, the administrator is continually
adding  extra IP addresses to the FW access list. The more work the FW
administrator does the greater the chances of error.

The extra hops that FANTOM requires in the enterprise is insignificant in
latency and bandwidth particularly in a switched Ethernet configuration.
 
> 3) For SIP services, your AP and PEA both will house a SIP Proxy function,
RTP Proxy function, as well 
> as your control protocol+ RTP/RTCP probes. What is the implication of
putting all these functions in 
> one box from capacity, fault-tolerance and security p.o.v. ? 

Ans: Only the AP has a SIP or H.323 or MGCP (or...) proxy function. Those
who have attended any of my presentations (VON, SIP Summit etc.) will have
deduced that the functions readily break out and can reside on different
processors so that a distributed fault tolerant architecture can be
implemented if required.
 
> For example, the AP will be doing refreshes for all NAT binds for all RTP
sessions on behalf of all terminals.

Ans: Yes FANTOM is tuned to the network infrastructure obviating the need
for applications to know about it. We have designed the FANTOM probe to be
very distinguishable from media making a silicon or efficient software
implementations possible.

> 4) Are you planning on using a standard protocol as this control protocol?
In Sen proposal, we've used 
> an existing device control protocol. The sen proposal essentially needs no
new protocol development.

Ans: Do you mean between the FANTOM client and the FANTOM server or between
the signalling proxy and the RTP proxy? FANTOM is the control protocol
between client and server. Like you, our philosophy is to use existing
methods where appropriate. But we don't based a solution on having to change
a protocol or terminal behaviour to make it work. That's too hard a sell.
 
> 5) Your requirement for always allowing traffic from some "well-known"
address/port of PEA to the AP 
> in the private network is a big concern. This is typically NOT done in
traditional enterprise FW. 

Ans: On the contrary it is (a) common practice - that's what well know ports
are for, and (b) of huge benefit - our server element may be deployed in an
enterprise DMZ for a non-service provider solution. Neither yours nor TURN
can be - it must always be in the public Internet.
 
> Such a FW will typically close the pin-hole after sometime, hence the need
for signaling path refreshes 
> using PING or REGISTER) both in our scheme and Jonathan's.

Ans: This is the reason we mux the signalling with the control channel. It
removes the need to do lots of refreshes for multiple paths. Again FANTOM
takes care of it on behalf of the terminal.

Steve