1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
/* $Id: doc_turn.h 3553 2011-05-05 06:14:19Z nanang $ */
/*
* Copyright (C) 2008-2011 Teluu Inc. (http://www.teluu.com)
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
/**
@defgroup PJNATH_TURN TURN: Traversal Using Relays around NAT
@brief TURN protocol implementation
@ingroup PJNATH
\section turn_intro_sec Introduction to TURN
When a direct communication path cannot be found, it is necessary to
use the services of an intermediate host that acts as a relay for the
packets. This relay typically sits in the public Internet and relays
packets between two hosts that both sit behind NATs.
TURN allows a host behind a NAT (called the TURN client) to request that
another host (called the TURN server) act as a relay. The client can
arrange for the server to relay packets to and from certain other hosts
(called peers) and can control aspects of how the relaying is done.
The client does this by obtaining an IP address and port on the
server, called the relayed-transport-address. When a peer sends a
packet to the relayed-transport-address, the server relays the packet
to the client. When the client sends a data packet to the server,
the server relays it to the appropriate peer using the relayed-
transport-address as the source.
\section turn_op_sec Overview of TURN operations
<b>Discovering TURN server</b>.\n
Client learns the IP address of the TURN
server either through some privisioning or by querying DNS SRV records
for TURN service for the specified domain. Client may use UDP or TCP (or
TLS) to connect to the TURN server.
<b>Authentication</b>.\n
All TURN operations requires the use of authentication
(it uses STUN long term autentication method), hence client must be
configured with the correct credential to use the service.
<b>Allocation</b>.\n
Client creates one "relay port" (or called <b>relayed-transport-address</b>
in TURN terminology) in the TURN server by sending TURN \a Allocate request,
hence this process is called creating allocation. Once the allocation is
successful, client will be given the IP address and port of the "relay
port" in the Allocate response.
<b>Sending data through the relay</b>.\n
Once allocation has been created, client may send data to any remote
endpoints (called peers in TURN terminology) via the "relay port". It does
so by sending Send Indication to the TURN server, giving the peer address
in the indication message. But note that at this point peers are not allowed
to send data towards the client (via the "relay port") before permission is
installed for that peer.
<b>Creating permissions</b>.\n
Permission needs to be created in the TURN server so that a peer can send
data to the client via the relay port (a peer in this case is identified by
its IP address). Without this, when the TURN server receives data from the
peer in the "relay port", it will drop this data.
<b>Receiving data from peers</b>.\n
Once permission has been installed for the peer, any data received by the
TURN server (from that peer) in the "relay port" will be relayed back to
client by using Data Indication.
<b>Using ChannelData</b>.\n
TURN provides optimized framing to the data by using ChannelData
packetization. The client activates this format by sending ChannelBind
request to the TURN server, which provides (channel) binding which maps a
particular peer address with a channel number. Data sent or received to/for
this peer will then use ChannelData format instead of Send or Data
Indications.
<b>Refreshing the allocation, permissions, and channel bindings</b>.\n
Allocations, permissions, and channel bindings need to be refreshed
periodically by client, or otherwise they will expire.
<b>Destroying the allocation</b>.\n
Once the "relay port" is no longer needed, client destroys the allocation
by sending Refresh request with LIFETIME attribute set to zero.
\section turn_org_sec Library organizations
The TURN functionalities in PJNATH primarily consist of
\ref PJNATH_TURN_SOCK and \ref PJNATH_TURN_SESSION. Please see more
below.
\section turn_using_sec Using TURN transport
The \ref PJNATH_TURN_SOCK is a ready to use object for relaying
application data via a TURN server, by managing all the operations
above.
Among other things it provides the following features:
- resolution of the TURN server with DNS SRV
- interface to create allocation, permissions, and channel
bindings
- interface to send and receive packets through the relay
- provides callback to notify the application about incoming data
- managing the allocation, permissions, and channel bindings
Please see \ref PJNATH_TURN_SOCK for more documentation about and
on how to use this object.
\section turn_owntransport_sec Creating custom TURN transport
The \ref PJNATH_TURN_SESSION is a transport-independent object to
manage a client TURN session. It contains the core logic for managing
the TURN client session as listed in TURN operations above, but
in transport-independent manner (i.e. it doesn't have a socket), so
that developer can integrate TURN client functionality into existing
framework that already has its own means to send and receive data,
or to support new transport types to TURN, such as TLS.
You can create your own (custom) TURN transport by wrapping this
into your own object, and provide it with the means to send and
receive packets.
Please see \ref PJNATH_TURN_SESSION for more information.
\section turn_samples_sec Samples
The \ref turn_client_sample is a sample application to use the
\ref PJNATH_TURN_SOCK. Also there is a sample TURN server in
the distribution as well.
Also see <b>\ref samples_page</b> for other samples.
*/
/**
* @defgroup PJNATH_TURN_SOCK TURN client transport
* @brief Client transport utilizing TURN relay
* @ingroup PJNATH_TURN
*/
/**
* @defgroup PJNATH_TURN_SESSION TURN client session
* @brief Transport independent TURN client session
* @ingroup PJNATH_TURN
*/
|
