Skip to main content

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}