Midcom-unaware NAT/Firewall Traversal
draft-sen-midcom-fw-nat-01
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Sanjoy Sen , Pat Sollee , Sean March | ||
| Last updated | 2002-05-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Bundled session applications such as FTP, H.323, SIP and RTSP, which use a signaling/control connection to establish a data/media flow, are usually broken, en-route, by Middleboxes such as NAT. Midcom proposes to solve this problem by allowing the Middlebox to be controlled through a generalized control interface by an application-aware entity called Midcom Agent. Since ubiquitous deployment of Midcom is still a few years away, an interim solution is needed to allow applications traverse NAT and Firewalls seamlessly without the help of embedded Application Layer Gateways (ALG). In this draft, a pre-Midcom solution framework is developed. A solution for the problem of NAT/FW traversal is needed both for the signaling and media/data paths. Two key components of the proposed solution are: (1) a Signaling Proxy server on the signaling path, and (2) a Media Proxy server on the media path. The Signaling server interacts with the Media server through a control interface. Although the primary applicability of this framework is shown for real-time RTP/UDP-based SIP multimedia sessions, these concepts should be generally applicable to other types of data sessions established through a control connection.
Authors
Sanjoy Sen
Pat Sollee
Sean March
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)