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
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
pub mod routing;
pub mod session;
use std::{net::SocketAddr, sync::Arc};
use crate::codec::{crypto::Password, message::attributes::PasswordAlgorithm};
use self::{
routing::Router,
session::{Identifier, SessionManager, SessionManagerOptions, ports::PortRange},
};
pub trait ServiceHandler: Send + Sync + 'static {
fn get_password(
&self,
username: &str,
algorithm: PasswordAlgorithm,
) -> impl Future<Output = Option<Password>> + Send;
/// allocate request
///
/// [rfc8489](https://tools.ietf.org/html/rfc8489)
///
/// In all cases, the server SHOULD only allocate ports from the range
/// 49152 - 65535 (the Dynamic and/or Private Port range [PORT-NUMBERS]),
/// unless the TURN server application knows, through some means not
/// specified here, that other applications running on the same host as
/// the TURN server application will not be impacted by allocating ports
/// outside this range. This condition can often be satisfied by running
/// the TURN server application on a dedicated machine and/or by
/// arranging that any other applications on the machine allocate ports
/// before the TURN server application starts. In any case, the TURN
/// server SHOULD NOT allocate ports in the range 0 - 1023 (the Well-
/// Known Port range) to discourage clients from using TURN to run
/// standard services.
#[allow(unused_variables)]
fn on_allocated(&self, id: &Identifier, username: &str, port: u16) {}
/// channel binding request
///
/// The server MAY impose restrictions on the IP address and port values
/// allowed in the XOR-PEER-ADDRESS attribute; if a value is not allowed,
/// the server rejects the request with a 403 (Forbidden) error.
///
/// If the request is valid, but the server is unable to fulfill the
/// request due to some capacity limit or similar, the server replies
/// with a 508 (Insufficient Capacity) error.
///
/// Otherwise, the server replies with a ChannelBind success response.
/// There are no required attributes in a successful ChannelBind
/// response.
///
/// If the server can satisfy the request, then the server creates or
/// refreshes the channel binding using the channel number in the
/// CHANNEL-NUMBER attribute and the transport address in the XOR-PEER-
/// ADDRESS attribute. The server also installs or refreshes a
/// permission for the IP address in the XOR-PEER-ADDRESS attribute as
/// described in Section 9.
///
/// NOTE: A server need not do anything special to implement
/// idempotency of ChannelBind requests over UDP using the
/// "stateless stack approach". Retransmitted ChannelBind requests
/// will simply refresh the channel binding and the corresponding
/// permission. Furthermore, the client must wait 5 minutes before
/// binding a previously bound channel number or peer address to a
/// different channel, eliminating the possibility that the
/// transaction would initially fail but succeed on a
/// retransmission.
#[allow(unused_variables)]
fn on_channel_bind(&self, id: &Identifier, username: &str, channel: u16) {}
/// create permission request
///
/// [rfc8489](https://tools.ietf.org/html/rfc8489)
///
/// When the server receives the CreatePermission request, it processes
/// as per [Section 5](https://tools.ietf.org/html/rfc8656#section-5)
/// plus the specific rules mentioned here.
///
/// The message is checked for validity. The CreatePermission request
/// MUST contain at least one XOR-PEER-ADDRESS attribute and MAY contain
/// multiple such attributes. If no such attribute exists, or if any of
/// these attributes are invalid, then a 400 (Bad Request) error is
/// returned. If the request is valid, but the server is unable to
/// satisfy the request due to some capacity limit or similar, then a 508
/// (Insufficient Capacity) error is returned.
///
/// If an XOR-PEER-ADDRESS attribute contains an address of an address
/// family that is not the same as that of a relayed transport address
/// for the allocation, the server MUST generate an error response with
/// the 443 (Peer Address Family Mismatch) response code.
///
/// The server MAY impose restrictions on the IP address allowed in the
/// XOR-PEER-ADDRESS attribute; if a value is not allowed, the server
/// rejects the request with a 403 (Forbidden) error.
///
/// If the message is valid and the server is capable of carrying out the
/// request, then the server installs or refreshes a permission for the
/// IP address contained in each XOR-PEER-ADDRESS attribute as described
/// in [Section 9](https://tools.ietf.org/html/rfc8656#section-9).
/// The port portion of each attribute is ignored and may be any arbitrary
/// value.
///
/// The server then responds with a CreatePermission success response.
/// There are no mandatory attributes in the success response.
///
/// NOTE: A server need not do anything special to implement
/// idempotency of CreatePermission requests over UDP using the
/// "stateless stack approach". Retransmitted CreatePermission
/// requests will simply refresh the permissions.
#[allow(unused_variables)]
fn on_create_permission(&self, id: &Identifier, username: &str, ports: &[u16]) {}
/// refresh request
///
/// If the server receives a Refresh Request with a REQUESTED-ADDRESS-
/// FAMILY attribute and the attribute value does not match the address
/// family of the allocation, the server MUST reply with a 443 (Peer
/// Address Family Mismatch) Refresh error response.
///
/// The server computes a value called the "desired lifetime" as follows:
/// if the request contains a LIFETIME attribute and the attribute value
/// is zero, then the "desired lifetime" is zero. Otherwise, if the
/// request contains a LIFETIME attribute, then the server computes the
/// minimum of the client's requested lifetime and the server's maximum
/// allowed lifetime. If this computed value is greater than the default
/// lifetime, then the "desired lifetime" is the computed value.
/// Otherwise, the "desired lifetime" is the default lifetime.
///
/// Subsequent processing depends on the "desired lifetime" value:
///
/// * If the "desired lifetime" is zero, then the request succeeds and
/// the allocation is deleted.
///
/// * If the "desired lifetime" is non-zero, then the request succeeds
/// and the allocation's time-to-expiry is set to the "desired
/// lifetime".
///
/// If the request succeeds, then the server sends a success response
/// containing:
///
/// * A LIFETIME attribute containing the current value of the time-to-
/// expiry timer.
///
/// NOTE: A server need not do anything special to implement
/// idempotency of Refresh requests over UDP using the "stateless
/// stack approach". Retransmitted Refresh requests with a non-
/// zero "desired lifetime" will simply refresh the allocation. A
/// retransmitted Refresh request with a zero "desired lifetime"
/// will cause a 437 (Allocation Mismatch) response if the
/// allocation has already been deleted, but the client will treat
/// this as equivalent to a success response (see below).
#[allow(unused_variables)]
fn on_refresh(&self, id: &Identifier, username: &str, lifetime: u32) {}
/// session destroy
///
/// Triggered when the session leaves from the turn. Possible reasons: the
/// session life cycle has expired, external active deletion, or active
/// exit of the session.
#[allow(unused_variables)]
fn on_destroy(&self, id: &Identifier, username: &str) {}
}
pub struct ServiceOptions<T> {
pub port_range: PortRange,
pub realm: String,
pub interfaces: Vec<SocketAddr>,
pub handler: T,
}
/// Turn service.
#[derive(Clone)]
pub struct Service<T> {
interfaces: Arc<Vec<SocketAddr>>,
manager: Arc<SessionManager<T>>,
software: String,
realm: String,
handler: T,
}
impl<T> Service<T>
where
T: ServiceHandler + Clone,
{
/// Create turn service.
pub fn new(options: ServiceOptions<T>) -> Self {
Self {
manager: SessionManager::new(SessionManagerOptions {
port_range: options.port_range,
handler: options.handler.clone(),
}),
interfaces: Arc::new(options.interfaces),
software: crate::SOFTWARE.to_string(),
handler: options.handler,
realm: options.realm,
}
}
/// create a router.
pub fn make_router(&self, endpoint: SocketAddr, interface: SocketAddr) -> Router<T> {
Router::new(self, endpoint, interface)
}
pub fn get_session_manager(&self) -> &SessionManager<T> {
&self.manager
}
}