Subject: [midcom] some points regarding the Sen proposal

From: "Sanjoy Sen" <[email-masked]>
Date: Wed, 28 Nov 2001 16:09:16 -0600

All,

   I would like to highlight a few important differences between the Sen
proposal and TURN, FANTOM on the use of the Intermediary-based solution:

1) New protocol development vs NO new protocol development:
An average common practise may go either way, but the cost/complexity issues
for a solution deemed to be near-term need to be clearly analysed. There're
two fundamental requirements here: 1) establish a bind on the Intermediary
and let the endpoint know about it, and 2) establish & keep refreshing the
NAT bind, or settle on a permanently open bind. 

Both TURN, FANTOM rely on a new protocol to capture and transfer the
Intermediary binds. Sen proposal piggy-backs the bind information on the
existing application signaling (this is what makes the Sen proposal appear
SIP specific, but the same principle is applicable to any other signaling
protocol - this will be illustrated in the next version of the draft). No
new protocol is required. 

For refreshing the binds, both the Sen and TURN/STUN proposals rely on
"sacrifice" packets - they leverage on existing application signaling
packets and silence RTP packets (this would work even in the face of silence
suppression as comfort noise packets are almost always generated in existing
codecs; if not, empty RTP packets are used). Again, advantage is that no new
protocol development required. FANTOM either keeps the bind open or rely on
new probe packets. 

2) Use of symmetric RTP:
Sen proposal uses symmetric RTP configuration - which simply means the
client sends and receives RTP packets in the same port. This is a trivial
configuration done in most clients and saves a lot of unwarranted overhead
such as maintaining too many binds (for a single media session, you need 4),
refreshing each of them independently etc. 

3) The Sen proposal does not impose any restriction on the Enterprise NAT/FW
policy. 

4) From complexity perspective, the Sen proposal is equivalent to TURN with
the additional vantage that no new protocol development required. Both Sen
and TURN uses a single Intermediary, while FANTOM uses two signaling & media
proxies. The Sen (and FANTOM?) proposal is primarily targetted towards the
needs of Large/Medium Enterprises and Carriers where media/signaling
route-pinning provides advantages in terms of QoS, billing, security etc.
STUN/TURN offers much more flexibility and economy for residential, SOHO,
SME markets.

5) The use of an existing device control protocol in the Sen proposal
between the signaling Proxy and the Media Proxy makes it closest to a future
Midcom protocol. 

Regards,
Sanjoy