← Back to branch summary

~ubuntu-branches/ubuntu/trusty/sflphone/trusty

« back to all changes in this revision

Viewing changes to daemon/libs/pjproject-2.1.0/pjnath/docs/doc_nat.h

  • Committer: Package Import Robot
  • Author(s): Mark Purcell
  • Date: 2014-01-28 18:23:36 UTC
  • mfrom: (4.3.4 sid)
  • Revision ID: package-import@ubuntu.com-20140128182336-jrsv0k9u6cawc068
Tags: 1.3.0-1
http://bugs.debian.org/735846
http://bugs.debian.org/727164
http://bugs.debian.org/718178
http://bugs.debian.org/736583
http://bugs.debian.org/722040
http://bugs.debian.org/736746
* New upstream release 
  - Fixes "New Upstream Release" (Closes: #735846)
  - Fixes "Ringtone does not stop" (Closes: #727164)
  - Fixes "[sflphone-kde] crash on startup" (Closes: #718178)
  - Fixes "sflphone GUI crashes when call is hung up" (Closes: #736583)
* Build-Depends: ensure GnuTLS 2.6
  - libucommon-dev (>= 6.0.7-1.1), libccrtp-dev (>= 2.0.6-3)
  - Fixes "FTBFS Build-Depends libgnutls{26,28}-dev" (Closes: #722040)
* Fix "boost 1.49 is going away" unversioned Build-Depends: (Closes: #736746)
* Add Build-Depends: libsndfile-dev, nepomuk-core-dev

Show diffs side-by-side

added added

removed removed

Lines of Context:
daemon/libs/pjproject-2.1.0/pjnath/docs/doc_nat.h
 
1
/* $Id: doc_nat.h 3553 2011-05-05 06:14:19Z nanang $ */
 
2
/* 
 
3
 * Copyright (C) 2008-2011 Teluu Inc. (http://www.teluu.com)
 
4
 *
 
5
 * This program is free software; you can redistribute it and/or modify
 
6
 * it under the terms of the GNU General Public License as published by
 
7
 * the Free Software Foundation; either version 2 of the License, or
 
8
 * (at your option) any later version.
 
9
 *
 
10
 * This program is distributed in the hope that it will be useful,
 
11
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 
12
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 
13
 * GNU General Public License for more details.
 
14
 *
 
15
 * You should have received a copy of the GNU General Public License
 
16
 * along with this program; if not, write to the Free Software
 
17
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA 
 
18
 */
 
19
 
 
20
 
 
21
/**
 
22
 
 
23
@defgroup nat_intro Introduction to Network Address Translation (NAT) and NAT Traversal
 
24
@brief This page describes NAT and the problems caused by it and the solutions
 
25
 
 
26
 
 
27
 
 
28
\section into Introduction to NAT
 
29
 
 
30
 
 
31
NAT (Network Address Translation) is a mechanism where a device performs 
 
32
modifications to the TCP/IP address/port number of a packet and maps the 
 
33
IP address from one realm to another (usually from private IP address to 
 
34
public IP address and vice versa). This works by the NAT device allocating
 
35
a temporary port number on the public side of the NAT upon forwarding 
 
36
outbound packet from the internal host towards the Internet, maintaining
 
37
this mapping for some predefined time, and forwarding the inbound packets
 
38
received from the Internet on this public port back to the internal host.
 
39
 
 
40
 
 
41
NAT devices are installed primarily to alleviate the exhaustion of IPv4 
 
42
address space by allowing multiple hosts to share a public/Internet address.
 
43
Also due to its mapping nature (i.e. a mapping can only be created by 
 
44
a transmission from an internal host), NAT device is preferred to be 
 
45
installed even when IPv4 address exhaustion is not a problem (for example
 
46
when there is only one host at home), to provide some sort of security/shield
 
47
for the internal hosts against threats from the Internet.
 
48
 
 
49
 
 
50
Despite the fact that NAT provides some shields for the internal network,
 
51
one must distinguish NAT solution from firewall solution. NAT is not 
 
52
a firewall solution. A firewall is a security solution designed to enforce
 
53
the security policy of an organization, while NAT is a connectivity solution
 
54
to allow multiple hosts to use a single public IP address. Understandably
 
55
both functionalities are difficult to separate at times, since many 
 
56
(typically consumer) products claims to do both with the same device and
 
57
simply label the device a �NAT box�. But we do want to make this distinction
 
58
rather clear, as PJNATH is a NAT traversal helper and not a firewall bypass
 
59
solution (yet).
 
60
 
 
61
 
 
62
 
 
63
\section problems The NAT traversal problems
 
64
 
 
65
 
 
66
While NAT would work well for typical client server communications (such as
 
67
web and email), since it's always the client that initiates the conversation
 
68
and normally client doesn't need to maintain the connection for a long time,
 
69
installation of NAT would cause major problem for peer-to-peer communication,
 
70
such as (and especially) VoIP. These problems will be explained in more detail
 
71
below.
 
72
 
 
73
 
 
74
\subsection peer_addr Peer address problem
 
75
 
 
76
 
 
77
In VoIP, normally we want the media (audio, and video) to flow directly
 
78
between the clients, since relaying is costly (both in terms of bandwidth
 
79
cost for service provider, and additional latency introduced by relaying).
 
80
To do this, each client informs its media transport address to the other
 
81
client , by sending it via the VoIP signaling path, and the other side would
 
82
send its media to this transport address.
 
83
 
 
84
 
 
85
And there lies the problem. If the client software is not NAT aware, then
 
86
it would send its private IP address to the other client, and the other
 
87
client would not be able to send media to this address.
 
88
 
 
89
 
 
90
Traditionally this was solved by using STUN. With this mechanism, the client
 
91
first finds out its public IP address/port by querying a STUN server, then
 
92
send sthis public address instead of its private address to the other 
 
93
client. When both sides are using this mechanism, they can then send media 
 
94
packets to these addresses, thereby creating a mapping in the NAT (also 
 
95
called opening a "hole", hence this mechanism is also popularly called 
 
96
"hole punching") and both can then communicate with each other.
 
97
 
 
98
 
 
99
But this mechanism does not work in all cases, as will be explained below.
 
100
 
 
101
 
 
102
 
 
103
\subsection hairpin Hairpinning behavior
 
104
 
 
105
 
 
106
Hairpin is a behavior where a NAT device forwards packets from a host in
 
107
internal network (lets call it host A) back to some other host (host B) in
 
108
the same internal network, when it detects that the (public IP address)
 
109
destination of the packet is actually a mapped IP address that was created
 
110
for the internal host (host B). This is a desirable behavior of a NAT, 
 
111
but unfortunately not all NAT devices support this.
 
112
 
 
113
 
 
114
Lacking this behavior, two (internal) hosts behind the same NAT will not
 
115
be able to communicate with each other if they exchange their public
 
116
addresses (resolved by STUN above) to each other.
 
117
 
 
118
 
 
119
 
 
120
\subsection symmetric Symmetric behavior
 
121
 
 
122
 
 
123
NAT devices don't behave uniformly and people have been trying to classify
 
124
their behavior into different classes. Traditionally NAT devices are
 
125
classified into Full Cone, Restricted Cone, Port Restricted Cone, and 
 
126
Symmetric types, according to <A HREF="http://www.ietf.org/rfc/rfc3489.txt">RFC 3489</A>
 
127
section 5. A more recent method of classification, as explained by 
 
128
<A HREF="http://www.ietf.org/rfc/rfc4787.txt">RFC 4787</A>, divides 
 
129
the NAT behavioral types into two attributes: the mapping behavior 
 
130
attribute and the filtering behavior attribute. Each attribute can be 
 
131
one of three types: <i>Endpoint-Independent</i>, <i>Address-Dependent</i>,
 
132
or <i>Address and Port-Dependent</i>. With this new classification method,
 
133
a Symmetric NAT actually is an Address and Port-Dependent mapping NAT.
 
134
 
 
135
 
 
136
Among these types, the Symmetric type is the hardest one to work with. 
 
137
The problem is because the NAT allocates different mapping (of the same
 
138
internal host) for the communication to the STUN server and the 
 
139
communication to the other (external) hosts, so the IP address/port that
 
140
is informed by one host to the other is meaningless for the recipient 
 
141
since this is not the actual IP address/port mapping that the NAT device 
 
142
creates. The result is when the recipient host tries to send a packet to 
 
143
this address, the NAT device would drop the packet since it does not 
 
144
recognize the sender of the packet as the "authorized" hosts to send 
 
145
to this address.
 
146
 
 
147
 
 
148
There are two solutions for this. The first, we could make the client 
 
149
smarter by switching transmission of the media to the source address of 
 
150
the media packets. This would work since normally clients uses a well 
 
151
known trick called symmetric RTP, where they use one socket for both 
 
152
transmitting and receiving RTP/media packets. We also use this 
 
153
mechanism in PJMEDIA media transport. But this solution only works 
 
154
if a client behind a symmetric NAT is not communicating with other 
 
155
client behind either symmetric NAT or port-restricted NAT.
 
156
 
 
157
 
 
158
The second solution is to use media relay, but as have been mentioned 
 
159
above, relaying is costly, both in terms of bandwidth cost for service
 
160
provider and additional latency introduced by relaying.
 
161
 
 
162
 
 
163
 
 
164
\subsection binding_timeout Binding timeout
 
165
 
 
166
When a NAT device creates a binding (a public-private IP address 
 
167
mapping), it will associate a timer with it. The timer is used to 
 
168
destroy the binding once there is no activity/traffic associated with 
 
169
the binding. Because of this, a NAT aware application that wishes to 
 
170
keep the binding open must periodically send outbound packets, 
 
171
a mechanism known as keep-alive, or otherwise it will ultimately 
 
172
loose the binding and unable to receive incoming packets from Internet.
 
173
 
 
174
 
 
175
\section solutions The NAT traversal solutions
 
176
 
 
177
 
 
178
\subsection stun Old STUN (RFC 3489)
 
179
 
 
180
The original STUN (Simple Traversal of User Datagram Protocol (UDP) 
 
181
Through Network Address Translators (NATs)) as defined by 
 
182
<A HREF="http://www.ietf.org/rfc/rfc3489.txt">RFC 3489</A>
 
183
(published in 2003, but the work was started as early as 2001) was 
 
184
meant to be a standalone, standard-based solution for the NAT 
 
185
connectivity problems above. It is equipped with NAT type detection 
 
186
algoritm and methods to hole-punch the NAT in order to let traffic 
 
187
to get through and has been proven to be quite successful in 
 
188
traversing many types of NATs, hence it has gained a lot of popularity
 
189
 as a simple and effective NAT traversal solution.
 
190
 
 
191
But since then the smart people at IETF has realized that STUN alone 
 
192
is not going to be enough. Besides its nature that STUN solution cannot 
 
193
solve the symmetric-to-symmetric or port-restricted connection, 
 
194
people have also discovered that NAT behavior can change for different 
 
195
traffic (or for the same traffic overtime) hence it was concluded that 
 
196
NAT type detection could produce unreliable results hence one should not 
 
197
rely too much on it.
 
198
 
 
199
Because of this, STUN has since moved its efforts to different strategy. 
 
200
Instead of attempting to provide a standalone solution, it's now providing 
 
201
a part solution and framework to build other (STUN based) protocols 
 
202
on top of it, such as TURN and ICE.
 
203
 
 
204
 
 
205
\subsection stunbis STUN/STUNbis (RFC 5389)
 
206
 
 
207
The Session Traversal Utilities for NAT (STUN) is the further development 
 
208
of the old STUN. While it still provides a mechanism for a client to 
 
209
query its public/mapped address to a STUN server, it has deprecated 
 
210
the use of NAT type detection, and now it serves as a framework to build 
 
211
other protocols on top of it (such as TURN and ICE).
 
212
 
 
213
 
 
214
\subsection midcom_turn Old TURN (draft-rosenberg-midcom-turn)
 
215
 
 
216
Traversal Using Relay NAT (TURN), a standard-based effort started as early
 
217
as in November 2001, was meant to be the complementary method for the 
 
218
(old) STUN to complete the solution. The original idea was the host to use 
 
219
STUN to detect the NAT type, and when it has found that the NAT type is 
 
220
symmetric it would use TURN to relay the traffic. But as stated above, 
 
221
this approach was deemed to be unreliable, and now the prefered way to use
 
222
TURN (and it's a new TURN specification as well) is to combine it with ICE.
 
223
 
 
224
 
 
225
\subsection turn TURN (draft-ietf-behave-turn)
 
226
 
 
227
Traversal Using Relays around NAT (TURN) is the latest development of TURN. 
 
228
While the protocol details have changed a lot, the objective is still 
 
229
the same, that is to provide relaying control for the application. 
 
230
As mentioned above, preferably TURN should be used with ICE since relaying 
 
231
is costly in terms of both bandwidth and latency, hence it should be used 
 
232
as the last resort.
 
233
 
 
234
 
 
235
\subsection b2bua B2BUA approach
 
236
 
 
237
A SIP Back to Back User Agents (B2BUA) is a SIP entity that sits in the 
 
238
middle of SIP traffic and acts as SIP user agents on both call legs. 
 
239
The primary motivations to have a B2BUA are to be able to provision 
 
240
the call (e.g. billing, enforcing policy) and to help with NAT traversal 
 
241
for the clients. Normally a B2BUA would be equipped with media relaying 
 
242
or otherwise it wouldn't be very useful.
 
243
 
 
244
Products that fall into this category include SIP Session Border 
 
245
Controllers (SBC), and PBXs such as Asterisk are technically a B2BUA 
 
246
as well.
 
247
 
 
248
The benefit of B2BUA with regard to helping NAT traversal is it does not 
 
249
require any modifications to the client to make it go through NATs. 
 
250
And since basically it is a relay, it should be able to traverse 
 
251
symmetric NAT successfully.
 
252
 
 
253
However, since it is a relay, the usual relaying drawbacks apply, 
 
254
namely the bandwidth and latency issue. More over, since a B2BUA acts 
 
255
as user agent in either call-legs (i.e. it terminates the SIP 
 
256
signaling/call on one leg, albeit it creates another call on the other 
 
257
leg), it may also introduce serious issues with end-to-end SIP signaling.
 
258
 
 
259
 
 
260
\subsection alg ALG approach
 
261
 
 
262
Nowdays many NAT devices (such as consumer ADSL routers) are equipped 
 
263
with intelligence to inspect and fix VoIP traffic in its effort to help 
 
264
it with the NAT traversal. This feature is called Application Layer 
 
265
Gateway (ALG) intelligence. The idea is since the NAT device knows about 
 
266
the mapping, it might as well try to fix the application traffic so that 
 
267
the traffic could better traverse the NAT. Some tricks that are 
 
268
performed include for example replacing the private IP addresses/ports 
 
269
in the SIP/SDP packet with the mapped public address/port of the host 
 
270
that sends the packet.
 
271
 
 
272
Despite many claims about its usefullness, in reality this has given us 
 
273
more problems than the fix. Too many devices such as these break the 
 
274
SIP signaling, and in more advanced case, ICE negotiation. Some 
 
275
examples of bad situations that we have encountered in the past:
 
276
 
 
277
 - NAT device alters the Via address/port fields in the SIP response 
 
278
   message, making the response fail to pass SIP response verification 
 
279
   as defined by SIP RFC.
 
280
 - In other case, the modifications in the Via headers of the SIP 
 
281
   response hides the important information from the SIP server, 
 
282
   nameny the actual IP address/port of the client as seen by the SIP 
 
283
   server.
 
284
 - Modifications in the Contact URI of REGISTER request/response makes 
 
285
   the client unable to detect it's registered binding.
 
286
 - Modifications in the IP addresses/ports in SDP causes ICE 
 
287
   negotiation to fail with ice-mismatch status.
 
288
 - The complexity of the ALG processing in itself seems to have caused 
 
289
   the device to behave erraticly with managing the address bindings 
 
290
   (e.g. it creates a new binding for the second packet sent by the 
 
291
   client, even when the previous packet was sent just second ago, or
 
292
   it just sends inbound packet to the wrong host).
 
293
 
 
294
 
 
295
Many man-months efforts have been spent just to troubleshoot issues 
 
296
caused by these ALG (mal)functioning, and as it adds complexity to 
 
297
the problem rather than solving it, in general we do not like this 
 
298
approach at all and would prefer it to go away.
 
299
 
 
300
 
 
301
\subsection upnp UPnP
 
302
 
 
303
The Universal Plug and Play (UPnP) is a set of protocol specifications 
 
304
to control network appliances and one of its specification is to 
 
305
control NAT device. With this protocol, a client can instruct the 
 
306
NAT device to open a port in the NAT's public side and use this port 
 
307
for its communication. UPnP has gained popularity due to its 
 
308
simplicity, and one can expect it to be available on majority of 
 
309
NAT devices.
 
310
 
 
311
The drawback of UPnP is since it uses multicast in its communication,
 
312
it will only allow client to control one NAT device that is in the 
 
313
same multicast domain. While this normally is not a problem in 
 
314
household installations (where people normally only have one NAT 
 
315
router), it will not work if the client is behind cascaded routers 
 
316
installation. More over uPnP has serious issues with security due to 
 
317
its lack of authentication, it's probably not the prefered solution 
 
318
for organizations.
 
319
 
 
320
\subsection other Other solutions
 
321
 
 
322
Other solutions to NAT traversal includes:
 
323
 
 
324
 - SOCKS, which supports UDP protocol since SOCKS5.
 
325
 
 
326
 
 
327
 
 
328
\section ice ICE Solution - The Protocol that Works Harder
 
329
 
 
330
A new protocol is being standardized (it's in Work Group Last Call/WGLC 
 
331
stage at the time this article was written) by the IETF, called 
 
332
Interactive Connectivity Establishment (ICE). ICE is the ultimate 
 
333
weapon a client can have in its NAT traversal solution arsenals, 
 
334
as it promises that if there is indeed one path for two clients 
 
335
to communicate, then ICE will find this path. And if there are 
 
336
more than one paths which the clients can communicate, ICE will 
 
337
use the best/most efficient one.
 
338
 
 
339
ICE works by combining several protocols (such as STUN and TURN) 
 
340
altogether and offering several candidate paths for the communication, 
 
341
thereby maximising the chance of success, but at the same time also 
 
342
has the capability to prioritize the candidates, so that the more 
 
343
expensive alternative (namely relay) will only be used as the last
 
344
resort when else fails. ICE negotiation process involves several 
 
345
stages:
 
346
 
 
347
 - candidate gathering, where the client finds out all the possible 
 
348
   addresses that it can use for the communication. It may find 
 
349
   three types of candidates: host candidate to represent its 
 
350
   physical NICs, server reflexive candidate for the address that 
 
351
   has been resolved from STUN, and relay candidate for the address 
 
352
   that the client has allocated from a TURN relay.
 
353
 - prioritizing these candidates. Typically the relay candidate will
 
354
   have the lowest priority to use since it's the most expensive.
 
355
 - encoding these candidates, sending it to remote peer, and 
 
356
   negotiating it with offer-answer.
 
357
 - pairing the candidates, where it pairs every local candidates 
 
358
   with every remote candidates that it receives from the remote peer.
 
359
 - checking the connectivity for each candidate pairs.
 
360
 - concluding the result. Since every possible path combinations are 
 
361
   checked, if there is a path to communicate ICE will find it.
 
362
 
 
363
 
 
364
There are many benetifs of ICE:
 
365
 
 
366
 - it's standard based.
 
367
 - it works where STUN works (and more)
 
368
 - unlike standalone STUN solution, it solves the hairpinning issue, 
 
369
   since it also offers host candidates.
 
370
 - just as relaying solutions, it works with symmetric NATs. But unlike 
 
371
   plain relaying, relay is only used as the last resort, thereby 
 
372
   minimizing the bandwidth and latency issue of relaying.
 
373
 - it offers a generic framework for offering and checking address 
 
374
   candidates. While the ICE core standard only talks about using STUN 
 
375
   and TURN, implementors can add more types of candidates in the ICE 
 
376
   offer, for example UDP over TCP or HTTP relays, or even uPnP 
 
377
   candidates, and this could be done transparently for the remote 
 
378
   peer hence it's compatible and usable even when the remote peer 
 
379
   does not support these.
 
380
 - it also adds some kind of security particularly against DoS attacks, 
 
381
   since media address must be acknowledged before it can be used.
 
382
 
 
383
 
 
384
Having said that, ICE is a complex protocol to implement, making 
 
385
interoperability an issue, and at this time of writing we don't see 
 
386
many implementations of it yet. Fortunately, PJNATH has been one of 
 
387
the first hence more mature ICE implementation, being first released
 
388
on mid-2007, and we have been testing our implementation at 
 
389
<A HREF="http://www.sipit.net">SIP Interoperability Test (SIPit)</A>
 
390
events regularly, so hopefully we are one of the most stable as well.
 
391
 
 
392
 
 
393
\section pjnath PJNATH - The building blocks for effective NAT traversal solution
 
394
 
 
395
PJSIP NAT Helper (PJNATH) is a library which contains the implementation 
 
396
of standard based NAT traversal solutions. PJNATH can be used as a 
 
397
stand-alone library for your software, or you may use PJSUA-LIB library, 
 
398
a very high level library integrating PJSIP, PJMEDIA, and PJNATH into 
 
399
simple to use APIs.
 
400
 
 
401
PJNATH has the following features:
 
402
 
 
403
 - STUNbis implementation, providing both ready to use STUN-aware socket 
 
404
   and framework to implement higher level STUN based protocols such as 
 
405
   TURN and ICE.
 
406
 - NAT type detection, useful for troubleshooting purposes.
 
407
 - TURN implementation.
 
408
 - ICE implementation.
 
409
 
 
410
 
 
411
More protocols will be implemented in the future.
 
412
 
 
413
Go back to \ref index.
 
414
 
 
415
 */