PacPhone

Main Page

P2Pnat Media

What is P2Pnat Media?
How is P2Pnat MEDIA different to ICE?
P2Pnat media is simple, while ICE is complex
Does P2Pnat Media proxy media as little as ICE does?
Why can this be done in H.323 and not SIP?
Is P2Pnat compatible with legacy H.323 equipment?
Does P2Pnat require additional services?
Where can I get more information on P2Pnat?
How does P2Pnat Media actually work?

What is P2Pnat Media?

P2Pnat Media or "Point to Point through NAT Media" is a revolutionary method of NAT traversal in which the local NAT topography of the devices is taken into consideration when the servers decide how two devices are to flow media between each other. In most cases, media is allowed to flow directly between the devices, even when those devices reside behind NAT or Firewalls.

How is P2Pnat Media different than ICE?

P2Pnat Media is different than ICE in that there is no blind trial and error "guesses" (candidates) which can add long delays in establishment of direct media connectivity. P2Pnat Media utilises network intelligence, rather than dumb device probing, to efficiently collect information on the devices's NAT status. It then uses that information when placing the call to determine how the devices are going to send the media and then instruct the devices on how to configure themselves to achieve direct connectivity.

Quick comparison Table:

	P2Pnat Media	ICE
Interoperability with other equipment?	Yes.The intelligence is in the gatekeeper and the gatekeeper can determine, based on advertised capabilities and the NAT test performed by the NATed Endpoint, how the endpoint is to contact other endpoints that do and do not support P2Pnat Media. As it is built on existing H.460.18/19 technology, it can revert back to H.460.18/19 for incoming connections from existing endpoints.	No. Since ICE is a solution only for end devices, both devices must support ICE for it to work. There is no interoperability with existing equipment.
Calls fail due to media failure associated with NAT?	No.Since the NAT characteristics of the two endpoints are know before the call is placed then the most appropriate solution can be determined for the endpoints to contact each other directly before the call is placed. If a solution is not found then the call is rejected by an ARJ.	Yes. The NAT status of the two endpoints is not known until you place the call and in the placing of the call you hope that a workable path in found. If not then the call will fail due to media connection problems associated with NAT.
Media establishment delays?	No.The endpoint is instructed how to configure itself for the call before placing the call meaning a solution has already been found and the call can proceed as if it were a non-NATed call.	Yes. How the endpoints are to connect is not know so a range of candidates is proposed to each endpoint. There are delays, as the endpoints have to go through the candidates to find a workable media path.
Extra Bandwidth and Messages on the wire?	P2Pnat media contains no extra H.323 signalling messages and the only extra messages are to open STUN pinholes in the NAT as instructed by the gatekeeper.	The list of proposed candidates have to be eliminated one-by-one so every candidate must be proposed for every call adding a series of messages going off in different directions.
Unintended Issues with Implementation?	None known at this time.	Yes. Sending packets to candidates that may not exist may cause problems to other equipment on the network listening at that IP/Port and may cause the equipment to fail.
Deployment Considerations	Uses the standard ARQ/ACF/LRQ/LCF mechanism to exchange NAT information between the endpoint and its gatekeeper and with other gatekeepers and domains. Such deployments have proven to be highly scalable.STUN servers are determined by the gatekeeper and can be dynamically assigned to minimise congestion at any one STUN server.	Every piece of equipment must support ICE. STUN servers are statically provisioned in the endpoints.
Calls Between Devices on the same LAN	When the gatekeeper and two devices are on the same LAN, the endpoints will be instructed to direct media directly between themselves without opening pinholes through a NAT/FW device.	Calls placed between phones on a LAN will result in opening ports through a NAT/FW device, as the devices have no way to know that the peer is local.
Calls Between Devices that appear to be behind the same NAT	The Gatekeeper can determine that devices appear to be behind the same NAT. However, the appearance may not be accurate, as there may be nested NATs in use. As such, the Gatekeeper can employ a media proxy to ensure media is properly conveyed. Annex A covers this case and provides a solution where, if a P2P route is found between the devices, media can switch from a proxy mode to P2P mode without disruption.	ICE has no inherent means of determining whether a device is behind the same NAT or nested NATs. In the case they are behind the same NAT, media can flow point-to-point. In the case that nested NAT devices are employed, conveyance of media end-to-end may fail entirely.

P2Pnat media is simple, while ICE is complex

P2Pnat Media has a different set of objectives than ICE. The purpose is to establish direct media quickly and efficiently between devices not just to find the best or multiple paths. With P2Pnat Media, the Gatekeeper collects information on the endpoints in advance and examines this information and formulates how NATs are to be traversed during call setup process before calls are even placed, removing complexity from endpoints and delay and hence delivering a more robust means of media establishment.

To it's credit, ICE, now in draft 15, almost 4 years in development and 100 pages in length, does try almost all known methods to guess how to send media directly between the devices, it supports some of the most obscure network configurations, but it does so at the expense of degradation in performance. It may take several seconds to work through the various candidates to find a workable candidate while the call parties wait for the media to be established. Worse, there is never a guarantee that ICE can find a direct path between the devices.

P2Pnat media takes a more pragmatic approach by determining in advance what NAT Traversal methods will work and advises endpoints at the time of call establishment.

Does P2Pnat Media proxy media as little as ICE does?

No It has slightly higher proxying requirements than ICE. With ICE, you can typically reduce the call proxying requirement to about 8% (with a centralised media proxy), but with P2Pnat Media it may be slightly higher at about 10%. However, the load can be shared across the gatekeepers involved, (reducing the media proxy load on any single gatekeeper to 5%). It is true to say there is a trade off with slightly higher proxying requirements for more efficient media establishment, but since this proxying load can be shared, it makes P2Pnat Media overall a more efficient system.

Why can this be done in H.323 and not SIP?

In H.323 call routing is intelligent in that, prior to sending the call setup (equiv. to SIP INVITE), a request is first sent to the local gatekeeper to request a destination address to send the call setup. The gatekeeper then sends requests to other gatekeepers enquiring on behalf of the endpoint. When a destination is located, the endpoint is informed as to where to send the setup message. P2Pnat Media extends this mechanism to include the ability to exchange and process NAT traversal information.

SIP does not have this pre-call address resolution mechanism to be able to facilitate the collection, calculation and configuration for NAT. Calls start with the INVITE which removes the possibility for more intelligent call handling.

Is P2Pnat compatible with legacy H.323 equipment?

Yes, P2Pnat Media utilises the Generic Extensibility Framework defined in H.323v4. This means that even if a Gatekeeper does not support the feature, it can still pass the fields onto other gatekeepers that do. Thus, only the local gatekeepers need to support the feature and all other intermediary H.323 equipment just passes on the capability negotiation data to the remote gatekeeper.

P2Pnat Media also supports calling H.323 devices that do not support P2Pnat Media by providing default inputs into the NAT Traversal calculations and allowing NAT/FW endpoints to directly connect to other devices without requiring proxying in many cases. In the worse case, a media proxy is inserted in the call prior to call establishment.

Does P2Pnat Media require additional services?

Yes P2Pnat Media requires some form of NAT friendly call signalling service such as H.460.17/18 or GnuGk Nat and as a last resort proxying facilities of H.460.19 or GnuGk. It also requires NAT "testing" facilities of STUN (RFC3489) to determine the characteristics of the NAT. The gatekeeper allocates the STUN server to use and instructs the endpoint when to test and if it is to be used to traverse the NAT for a call.

Where can I get more information on P2Pnat Media?

You can view the following relevent documents:
White Paper on H.460.17/18/19 (which P2Pnat Media is Built upon)
GnuGk NAT Traversal Method (alternative to H.460.17/18/19)
Presentation of P2Pnat Media at ITU Rapporteur meeting in Shenzen China March 2007 (ppt)
Proposed H.460 Standard draft documents for P2Pnat Media updated 20/6 (zip)

So how does P2Pnat Media actually work?

The gatekeeper collects network topography information from the endpoint upon registration.

Endpoint information collected:
1. Whether the endpoint is detected as being behind a NAT/FW.
2. The type of NAT/FW detected.

When placing a call the gatekeeper managing each devices's registration must also supply its own information as to how it may assist in NAT traversal.

Gatekeeper information collected
1. Whether the gatekeeper can provide NAT assistance. (ie Proxy media).
2. Whether the gatekeeper must proxy media. ie. The device is behind the gatekeeper on a private LAN and the gatekeeper act as a border element and must proxy media to traverse on/off the LAN.

The above NAT information for both devices is collected by the caller’s gatekeeper and analysed. Using a logical progression of steps the most appropriate method to connect the media is determined. The proposed method is transmitted to the devices and the devices configure themselves as per those instructions for the particular call.

Call Flow diagrams (highly technical click to enlarge)