turn_server/service/routing.rs
1use std::{net::SocketAddr, sync::Arc};
2
3use bytes::BytesMut;
4
5use super::{
6 Service, ServiceHandler,
7 session::{DEFAULT_SESSION_LIFETIME, Identifier, Session, SessionManager},
8};
9
10use crate::codec::{
11 DecodeResult, Decoder,
12 channel_data::ChannelData,
13 crypto::Password,
14 message::{
15 Message, MessageEncoder,
16 attributes::{error::ErrorType, *},
17 methods::*,
18 },
19};
20
21struct Request<'a, 'b, T, M>
22where
23 T: ServiceHandler,
24{
25 id: &'a Identifier,
26 encode_buffer: &'b mut BytesMut,
27 state: &'a RouterState<T>,
28 payload: &'a M,
29}
30
31impl<'a, 'b, T> Request<'a, 'b, T, Message<'a>>
32where
33 T: ServiceHandler,
34{
35 // Verify the IP address specified by the client in the request, such as the
36 // peer address used when creating permissions and binding channels. Currently,
37 // only peer addresses that are local addresses of the TURN server are allowed;
38 // arbitrary addresses are not permitted.
39 //
40 // Allowing arbitrary addresses would pose security risks, such as enabling
41 // the TURN server to forward data to any target.
42 #[inline(always)]
43 fn verify_ip(&self, address: &SocketAddr) -> bool {
44 self.state
45 .interfaces
46 .iter()
47 .any(|item| item.ip() == address.ip())
48 }
49
50 // The key for the HMAC depends on whether long-term or short-term
51 // credentials are in use. For long-term credentials, the key is 16
52 // bytes:
53 //
54 // key = MD5(username ":" realm ":" SASLprep(password))
55 //
56 // That is, the 16-byte key is formed by taking the MD5 hash of the
57 // result of concatenating the following five fields: (1) the username,
58 // with any quotes and trailing nulls removed, as taken from the
59 // USERNAME attribute (in which case SASLprep has already been applied);
60 // (2) a single colon; (3) the realm, with any quotes and trailing nulls
61 // removed; (4) a single colon; and (5) the password, with any trailing
62 // nulls removed and after processing using SASLprep. For example, if
63 // the username was 'user', the realm was 'realm', and the password was
64 // 'pass', then the 16-byte HMAC key would be the result of performing
65 // an MD5 hash on the string 'user:realm:pass', the resulting hash being
66 // 0x8493fbc53ba582fb4c044c456bdc40eb.
67 //
68 // For short-term credentials:
69 //
70 // key = SASLprep(password)
71 //
72 // where MD5 is defined in RFC 1321 [RFC1321] and SASLprep() is defined
73 // in RFC 4013 [RFC4013].
74 //
75 // The structure of the key when used with long-term credentials
76 // facilitates deployment in systems that also utilize SIP. Typically,
77 // SIP systems utilizing SIP's digest authentication mechanism do not
78 // actually store the password in the database. Rather, they store a
79 // value called H(A1), which is equal to the key defined above.
80 //
81 // Based on the rules above, the hash used to construct MESSAGE-
82 // INTEGRITY includes the length field from the STUN message header.
83 // Prior to performing the hash, the MESSAGE-INTEGRITY attribute MUST be
84 // inserted into the message (with dummy content). The length MUST then
85 // be set to point to the length of the message up to, and including,
86 // the MESSAGE-INTEGRITY attribute itself, but excluding any attributes
87 // after it. Once the computation is performed, the value of the
88 // MESSAGE-INTEGRITY attribute can be filled in, and the value of the
89 // length in the STUN header can be set to its correct value -- the
90 // length of the entire message. Similarly, when validating the
91 // MESSAGE-INTEGRITY, the length field should be adjusted to point to
92 // the end of the MESSAGE-INTEGRITY attribute prior to calculating the
93 // HMAC. Such adjustment is necessary when attributes, such as
94 // FINGERPRINT, appear after MESSAGE-INTEGRITY.
95 #[inline(always)]
96 async fn verify(&self) -> Option<(&str, Password)> {
97 let username = self.payload.get::<UserName>()?;
98 let algorithm = self
99 .payload
100 .get::<PasswordAlgorithm>()
101 .unwrap_or(PasswordAlgorithm::Md5);
102
103 let password = self
104 .state
105 .manager
106 .get_password(self.id, username, algorithm)
107 .await?;
108
109 if self.payload.verify(&password).is_err() {
110 return None;
111 }
112
113 Some((username, password))
114 }
115}
116
117/// The target of the response.
118#[derive(Debug, Clone, Copy, Default)]
119pub struct Target {
120 pub endpoint: Option<SocketAddr>,
121 pub relay: Option<SocketAddr>,
122}
123
124/// The response.
125#[derive(Debug)]
126pub struct Response<'a> {
127 /// if the method is None, the response is a channel data response
128 pub method: Option<Method>,
129 /// the bytes of the response
130 pub bytes: &'a [u8],
131 /// the target of the response
132 pub target: Target,
133}
134
135pub(crate) struct RouterState<T>
136where
137 T: ServiceHandler,
138{
139 pub realm: String,
140 pub software: String,
141 pub manager: Arc<SessionManager<T>>,
142 pub endpoint: SocketAddr,
143 pub interface: SocketAddr,
144 pub interfaces: Arc<Vec<SocketAddr>>,
145 pub handler: T,
146}
147
148pub struct Router<T>
149where
150 T: ServiceHandler,
151{
152 current_id: Identifier,
153 state: RouterState<T>,
154 decoder: Decoder,
155 bytes: BytesMut,
156}
157
158impl<T> Router<T>
159where
160 T: ServiceHandler + Clone,
161{
162 pub fn new(service: &Service<T>, endpoint: SocketAddr, interface: SocketAddr) -> Self {
163 Self {
164 bytes: BytesMut::with_capacity(4096),
165 decoder: Decoder::default(),
166 // This is a placeholder address that will be updated on first route call
167 current_id: Identifier::new(
168 "0.0.0.0:0"
169 .parse()
170 .expect("Failed to parse placeholder address"),
171 interface,
172 ),
173 state: RouterState {
174 interfaces: service.interfaces.clone(),
175 software: service.software.clone(),
176 handler: service.handler.clone(),
177 manager: service.manager.clone(),
178 realm: service.realm.clone(),
179 interface,
180 endpoint,
181 },
182 }
183 }
184
185 pub async fn route<'a, 'b: 'a>(
186 &'b mut self,
187 bytes: &'b [u8],
188 address: SocketAddr,
189 ) -> Result<Option<Response<'a>>, crate::codec::Error> {
190 {
191 *self.current_id.source_mut() = address;
192 }
193
194 Ok(match self.decoder.decode(bytes)? {
195 DecodeResult::ChannelData(channel) => channel_data(
196 bytes,
197 Request {
198 id: &self.current_id,
199 state: &self.state,
200 encode_buffer: &mut self.bytes,
201 payload: &channel,
202 },
203 ),
204 DecodeResult::Message(message) => {
205 let req = Request {
206 id: &self.current_id,
207 state: &self.state,
208 encode_buffer: &mut self.bytes,
209 payload: &message,
210 };
211
212 match req.payload.method() {
213 BINDING_REQUEST => binding(req),
214 ALLOCATE_REQUEST => allocate(req).await,
215 CREATE_PERMISSION_REQUEST => create_permission(req).await,
216 CHANNEL_BIND_REQUEST => channel_bind(req).await,
217 REFRESH_REQUEST => refresh(req).await,
218 SEND_INDICATION => indication(req),
219 _ => None,
220 }
221 }
222 })
223 }
224}
225
226fn reject<'a, T>(req: Request<'_, 'a, T, Message<'_>>, error: ErrorType) -> Option<Response<'a>>
227where
228 T: ServiceHandler,
229{
230 let method = req.payload.method().error()?;
231
232 {
233 let mut message = MessageEncoder::extend(method, req.payload, req.encode_buffer);
234 message.append::<ErrorCode>(ErrorCode::from(error));
235
236 if error == ErrorType::Unauthorized {
237 message.append::<Realm>(&req.state.realm);
238 message.append::<Nonce>(
239 req.state
240 .manager
241 .get_session_or_default(req.id)
242 .get_ref()?
243 .nonce(),
244 );
245
246 message.append::<PasswordAlgorithms>(vec![
247 PasswordAlgorithm::Md5,
248 PasswordAlgorithm::Sha256,
249 ]);
250 }
251
252 message.flush(None).ok()?;
253 }
254
255 Some(Response {
256 target: Target::default(),
257 bytes: req.encode_buffer,
258 method: Some(method),
259 })
260}
261
262/// [rfc8489](https://tools.ietf.org/html/rfc8489)
263///
264/// In the Binding request/response transaction, a Binding request is
265/// sent from a STUN client to a STUN server. When the Binding request
266/// arrives at the STUN server, it may have passed through one or more
267/// NATs between the STUN client and the STUN server (in Figure 1, there
268/// are two such NATs). As the Binding request message passes through a
269/// NAT, the NAT will modify the source transport address (that is, the
270/// source IP address and the source port) of the packet. As a result,
271/// the source transport address of the request received by the server
272/// will be the public IP address and port created by the NAT closest to
273/// the server. This is called a "reflexive transport address". The
274/// STUN server copies that source transport address into an XOR-MAPPED-
275/// ADDRESS attribute in the STUN Binding response and sends the Binding
276/// response back to the STUN client. As this packet passes back through
277/// a NAT, the NAT will modify the destination transport address in the
278/// IP header, but the transport address in the XOR-MAPPED-ADDRESS
279/// attribute within the body of the STUN response will remain untouched.
280/// In this way, the client can learn its reflexive transport address
281/// allocated by the outermost NAT with respect to the STUN server.
282fn binding<'a, T>(req: Request<'_, 'a, T, Message<'_>>) -> Option<Response<'a>>
283where
284 T: ServiceHandler,
285{
286 {
287 let mut message = MessageEncoder::extend(BINDING_RESPONSE, req.payload, req.encode_buffer);
288 message.append::<XorMappedAddress>(req.id.source());
289 message.append::<MappedAddress>(req.id.source());
290 message.append::<ResponseOrigin>(req.state.interface);
291 message.append::<Software>(&req.state.software);
292 message.flush(None).ok()?;
293 }
294
295 Some(Response {
296 method: Some(BINDING_RESPONSE),
297 target: Target::default(),
298 bytes: req.encode_buffer,
299 })
300}
301
302/// [rfc8489](https://tools.ietf.org/html/rfc8489)
303///
304/// In all cases, the server SHOULD only allocate ports from the range
305/// 49152 - 65535 (the Dynamic and/or Private Port range [PORT-NUMBERS]),
306/// unless the TURN server application knows, through some means not
307/// specified here, that other applications running on the same host as
308/// the TURN server application will not be impacted by allocating ports
309/// outside this range. This condition can often be satisfied by running
310/// the TURN server application on a dedicated machine and/or by
311/// arranging that any other applications on the machine allocate ports
312/// before the TURN server application starts. In any case, the TURN
313/// server SHOULD NOT allocate ports in the range 0 - 1023 (the Well-
314/// Known Port range) to discourage clients from using TURN to run
315/// standard contexts.
316async fn allocate<'a, T>(req: Request<'_, 'a, T, Message<'_>>) -> Option<Response<'a>>
317where
318 T: ServiceHandler,
319{
320 if req.payload.get::<RequestedTransport>().is_none() {
321 return reject(req, ErrorType::ServerError);
322 }
323
324 let Some((username, password)) = req.verify().await else {
325 return reject(req, ErrorType::Unauthorized);
326 };
327
328 let lifetime = req.payload.get::<Lifetime>();
329
330 let Some(port) = req.state.manager.allocate(req.id, lifetime) else {
331 return reject(req, ErrorType::AllocationQuotaReached);
332 };
333
334 req.state.handler.on_allocated(req.id, username, port);
335
336 {
337 let mut message = MessageEncoder::extend(ALLOCATE_RESPONSE, req.payload, req.encode_buffer);
338 message.append::<XorRelayedAddress>(SocketAddr::new(req.state.interface.ip(), port));
339 message.append::<XorMappedAddress>(req.id.source());
340 message.append::<Lifetime>(lifetime.unwrap_or(DEFAULT_SESSION_LIFETIME as u32));
341 message.append::<Software>(&req.state.software);
342 message.flush(Some(&password)).ok()?;
343 }
344
345 Some(Response {
346 target: Target::default(),
347 method: Some(ALLOCATE_RESPONSE),
348 bytes: req.encode_buffer,
349 })
350}
351
352/// The server MAY impose restrictions on the IP address and port values
353/// allowed in the XOR-PEER-ADDRESS attribute; if a value is not allowed,
354/// the server rejects the request with a 403 (Forbidden) error.
355///
356/// If the request is valid, but the server is unable to fulfill the
357/// request due to some capacity limit or similar, the server replies
358/// with a 508 (Insufficient Capacity) error.
359///
360/// Otherwise, the server replies with a ChannelBind success response.
361/// There are no required attributes in a successful ChannelBind
362/// response.
363///
364/// If the server can satisfy the request, then the server creates or
365/// refreshes the channel binding using the channel number in the
366/// CHANNEL-NUMBER attribute and the transport address in the XOR-PEER-
367/// ADDRESS attribute. The server also installs or refreshes a
368/// permission for the IP address in the XOR-PEER-ADDRESS attribute as
369/// described in Section 9.
370///
371/// NOTE: A server need not do anything special to implement
372/// idempotency of ChannelBind requests over UDP using the
373/// "stateless stack approach". Retransmitted ChannelBind requests
374/// will simply refresh the channel binding and the corresponding
375/// permission. Furthermore, the client must wait 5 minutes before
376/// binding a previously bound channel number or peer address to a
377/// different channel, eliminating the possibility that the
378/// transaction would initially fail but succeed on a
379/// retransmission.
380async fn channel_bind<'a, T>(req: Request<'_, 'a, T, Message<'_>>) -> Option<Response<'a>>
381where
382 T: ServiceHandler,
383{
384 let Some(peer) = req.payload.get::<XorPeerAddress>() else {
385 return reject(req, ErrorType::BadRequest);
386 };
387
388 if !req.verify_ip(&peer) {
389 return reject(req, ErrorType::PeerAddressFamilyMismatch);
390 }
391
392 let Some(number) = req.payload.get::<ChannelNumber>() else {
393 return reject(req, ErrorType::BadRequest);
394 };
395
396 if !(0x4000..=0x7FFF).contains(&number) {
397 return reject(req, ErrorType::BadRequest);
398 }
399
400 let Some((username, password)) = req.verify().await else {
401 return reject(req, ErrorType::Unauthorized);
402 };
403
404 if !req
405 .state
406 .manager
407 .bind_channel(req.id, &req.state.endpoint, peer.port(), number)
408 {
409 return reject(req, ErrorType::Forbidden);
410 }
411
412 req.state.handler.on_channel_bind(req.id, username, number);
413
414 {
415 MessageEncoder::extend(CHANNEL_BIND_RESPONSE, req.payload, req.encode_buffer)
416 .flush(Some(&password))
417 .ok()?;
418 }
419
420 Some(Response {
421 target: Target::default(),
422 method: Some(CHANNEL_BIND_RESPONSE),
423 bytes: req.encode_buffer,
424 })
425}
426
427/// [rfc8489](https://tools.ietf.org/html/rfc8489)
428///
429/// When the server receives the CreatePermission request, it processes
430/// as per [Section 5](https://tools.ietf.org/html/rfc8656#section-5)
431/// plus the specific rules mentioned here.
432///
433/// The message is checked for validity. The CreatePermission request
434/// MUST contain at least one XOR-PEER-ADDRESS attribute and MAY contain
435/// multiple such attributes. If no such attribute exists, or if any of
436/// these attributes are invalid, then a 400 (Bad Request) error is
437/// returned. If the request is valid, but the server is unable to
438/// satisfy the request due to some capacity limit or similar, then a 508
439/// (Insufficient Capacity) error is returned.
440///
441/// If an XOR-PEER-ADDRESS attribute contains an address of an address
442/// family that is not the same as that of a relayed transport address
443/// for the allocation, the server MUST generate an error response with
444/// the 443 (Peer Address Family Mismatch) response code.
445///
446/// The server MAY impose restrictions on the IP address allowed in the
447/// XOR-PEER-ADDRESS attribute; if a value is not allowed, the server
448/// rejects the request with a 403 (Forbidden) error.
449///
450/// If the message is valid and the server is capable of carrying out the
451/// request, then the server installs or refreshes a permission for the
452/// IP address contained in each XOR-PEER-ADDRESS attribute as described
453/// in [Section 9](https://tools.ietf.org/html/rfc8656#section-9).
454/// The port portion of each attribute is ignored and may be any arbitrary
455/// value.
456///
457/// The server then responds with a CreatePermission success response.
458/// There are no mandatory attributes in the success response.
459///
460/// NOTE: A server need not do anything special to implement idempotency of
461/// CreatePermission requests over UDP using the "stateless stack approach".
462/// Retransmitted CreatePermission requests will simply refresh the
463/// permissions.
464async fn create_permission<'a, T>(req: Request<'_, 'a, T, Message<'_>>) -> Option<Response<'a>>
465where
466 T: ServiceHandler,
467{
468 let Some((username, password)) = req.verify().await else {
469 return reject(req, ErrorType::Unauthorized);
470 };
471
472 let mut ports = Vec::with_capacity(15);
473 for it in req.payload.get_all::<XorPeerAddress>() {
474 if !req.verify_ip(&it) {
475 return reject(req, ErrorType::PeerAddressFamilyMismatch);
476 }
477
478 ports.push(it.port());
479 }
480
481 if !req
482 .state
483 .manager
484 .create_permission(req.id, &req.state.endpoint, &ports)
485 {
486 return reject(req, ErrorType::Forbidden);
487 }
488
489 req.state
490 .handler
491 .on_create_permission(req.id, username, &ports);
492
493 {
494 MessageEncoder::extend(CREATE_PERMISSION_RESPONSE, req.payload, req.encode_buffer)
495 .flush(Some(&password))
496 .ok()?;
497 }
498
499 Some(Response {
500 method: Some(CREATE_PERMISSION_RESPONSE),
501 target: Target::default(),
502 bytes: req.encode_buffer,
503 })
504}
505
506/// When the server receives a Send indication, it processes as per
507/// [Section 5](https://tools.ietf.org/html/rfc8656#section-5) plus
508/// the specific rules mentioned here.
509///
510/// The message is first checked for validity. The Send indication MUST
511/// contain both an XOR-PEER-ADDRESS attribute and a DATA attribute. If
512/// one of these attributes is missing or invalid, then the message is
513/// discarded. Note that the DATA attribute is allowed to contain zero
514/// bytes of data.
515///
516/// The Send indication may also contain the DONT-FRAGMENT attribute. If
517/// the server is unable to set the DF bit on outgoing UDP datagrams when
518/// this attribute is present, then the server acts as if the DONT-
519/// FRAGMENT attribute is an unknown comprehension-required attribute
520/// (and thus the Send indication is discarded).
521///
522/// The server also checks that there is a permission installed for the
523/// IP address contained in the XOR-PEER-ADDRESS attribute. If no such
524/// permission exists, the message is discarded. Note that a Send
525/// indication never causes the server to refresh the permission.
526///
527/// The server MAY impose restrictions on the IP address and port values
528/// allowed in the XOR-PEER-ADDRESS attribute; if a value is not allowed,
529/// the server silently discards the Send indication.
530///
531/// If everything is OK, then the server forms a UDP datagram as follows:
532///
533/// * the source transport address is the relayed transport address of the
534/// allocation, where the allocation is determined by the 5-tuple on which the
535/// Send indication arrived;
536///
537/// * the destination transport address is taken from the XOR-PEER-ADDRESS
538/// attribute;
539///
540/// * the data following the UDP header is the contents of the value field of
541/// the DATA attribute.
542///
543/// The handling of the DONT-FRAGMENT attribute (if present), is
544/// described in Sections [14](https://tools.ietf.org/html/rfc8656#section-14)
545/// and [15](https://tools.ietf.org/html/rfc8656#section-15).
546///
547/// The resulting UDP datagram is then sent to the peer.
548#[rustfmt::skip]
549fn indication<'a, T>(req: Request<'_, 'a, T, Message<'_>>) -> Option<Response<'a>>
550where
551 T: ServiceHandler,
552{
553 let peer = req.payload.get::<XorPeerAddress>()?;
554 let data = req.payload.get::<Data>()?;
555
556 if let Some(Session::Authenticated { allocate_port, .. }) =
557 req.state.manager.get_session(req.id).get_ref() && let Some(local_port) = *allocate_port
558 {
559 let relay = req.state.manager.get_relay_address(req.id, peer.port())?;
560
561 {
562 let mut message = MessageEncoder::extend(DATA_INDICATION, req.payload, req.encode_buffer);
563 message.append::<XorPeerAddress>(SocketAddr::new(req.state.interface.ip(), local_port));
564 message.append::<Data>(data);
565 message.flush(None).ok()?;
566 }
567
568 return Some(Response {
569 method: Some(DATA_INDICATION),
570 bytes: req.encode_buffer,
571 target: Target {
572 relay: Some(relay.source()),
573 endpoint: if req.state.endpoint != relay.endpoint() {
574 Some(relay.endpoint())
575 } else {
576 None
577 },
578 },
579 });
580 }
581
582 None
583}
584
585/// If the server receives a Refresh Request with a REQUESTED-ADDRESS-
586/// FAMILY attribute and the attribute value does not match the address
587/// family of the allocation, the server MUST reply with a 443 (Peer
588/// Address Family Mismatch) Refresh error response.
589///
590/// The server computes a value called the "desired lifetime" as follows:
591/// if the request contains a LIFETIME attribute and the attribute value
592/// is zero, then the "desired lifetime" is zero. Otherwise, if the
593/// request contains a LIFETIME attribute, then the server computes the
594/// minimum of the client's requested lifetime and the server's maximum
595/// allowed lifetime. If this computed value is greater than the default
596/// lifetime, then the "desired lifetime" is the computed value.
597/// Otherwise, the "desired lifetime" is the default lifetime.
598///
599/// Subsequent processing depends on the "desired lifetime" value:
600///
601/// * If the "desired lifetime" is zero, then the request succeeds and the
602/// allocation is deleted.
603///
604/// * If the "desired lifetime" is non-zero, then the request succeeds and the
605/// allocation's time-to-expiry is set to the "desired lifetime".
606///
607/// If the request succeeds, then the server sends a success response
608/// containing:
609///
610/// * A LIFETIME attribute containing the current value of the time-to-expiry
611/// timer.
612///
613/// NOTE: A server need not do anything special to implement
614/// idempotency of Refresh requests over UDP using the "stateless
615/// stack approach". Retransmitted Refresh requests with a non-
616/// zero "desired lifetime" will simply refresh the allocation. A
617/// retransmitted Refresh request with a zero "desired lifetime"
618/// will cause a 437 (Allocation Mismatch) response if the
619/// allocation has already been deleted, but the client will treat
620/// this as equivalent to a success response (see below).
621async fn refresh<'a, T>(req: Request<'_, 'a, T, Message<'_>>) -> Option<Response<'a>>
622where
623 T: ServiceHandler,
624{
625 let Some((username, password)) = req.verify().await else {
626 return reject(req, ErrorType::Unauthorized);
627 };
628
629 let lifetime = req
630 .payload
631 .get::<Lifetime>()
632 .unwrap_or(DEFAULT_SESSION_LIFETIME as u32);
633 if !req.state.manager.refresh(req.id, lifetime) {
634 return reject(req, ErrorType::AllocationMismatch);
635 }
636
637 req.state.handler.on_refresh(req.id, username, lifetime);
638
639 {
640 let mut message = MessageEncoder::extend(REFRESH_RESPONSE, req.payload, req.encode_buffer);
641 message.append::<Lifetime>(lifetime);
642 message.flush(Some(&password)).ok()?;
643 }
644
645 Some(Response {
646 target: Target::default(),
647 method: Some(REFRESH_RESPONSE),
648 bytes: req.encode_buffer,
649 })
650}
651
652/// If the ChannelData message is received on a channel that is not bound
653/// to any peer, then the message is silently discarded.
654///
655/// On the client, it is RECOMMENDED that the client discard the
656/// ChannelData message if the client believes there is no active
657/// permission towards the peer. On the server, the receipt of a
658/// ChannelData message MUST NOT refresh either the channel binding or
659/// the permission towards the peer.
660///
661/// On the server, if no errors are detected, the server relays the
662/// application data to the peer by forming a UDP datagram as follows:
663///
664/// * the source transport address is the relayed transport address of the
665/// allocation, where the allocation is determined by the 5-tuple on which the
666/// ChannelData message arrived;
667///
668/// * the destination transport address is the transport address to which the
669/// channel is bound;
670///
671/// * the data following the UDP header is the contents of the data field of the
672/// ChannelData message.
673///
674/// The resulting UDP datagram is then sent to the peer. Note that if
675/// the Length field in the ChannelData message is 0, then there will be
676/// no data in the UDP datagram, but the UDP datagram is still formed and
677/// sent [(Section 4.1 of [RFC6263])](https://tools.ietf.org/html/rfc6263#section-4.1).
678fn channel_data<'a, T>(
679 bytes: &'a [u8],
680 req: Request<'_, 'a, T, ChannelData<'_>>,
681) -> Option<Response<'a>>
682where
683 T: ServiceHandler,
684{
685 let relay = req
686 .state
687 .manager
688 .get_channel_relay_address(req.id, req.payload.number())?;
689
690 Some(Response {
691 bytes,
692 target: Target {
693 relay: Some(relay.source()),
694 endpoint: if req.state.endpoint != relay.endpoint() {
695 Some(relay.endpoint())
696 } else {
697 None
698 },
699 },
700 method: None,
701 })
702}