Struct Requet 

pub struct Requet<'a, 'b, T, M>
where
    T: Observer + 'static,
{
    pub address: &'a SessionAddr,
    pub bytes: &'b mut BytesMut,
    pub service: &'a ServiceContext<T>,
    pub message: &'a M,
}

The request of the service.

Fields

address: &'a SessionAddr

bytes: &'b mut BytesMut

service: &'a ServiceContext<T>

message: &'a M

Implementations

impl<'a, 'b, T> Requet<'a, 'b, T, MessageRef<'a>>

where T: Observer + 'static,

pub fn verify_ip(&self, address: &SocketAddr) -> bool

Check if the ip address belongs to the current turn server.

pub fn auth(&self) -> Option<(&str, [u8; 16])>

The key for the HMAC depends on whether long-term or short-term credentials are in use. For long-term credentials, the key is 16 bytes:

key = MD5(username “:” realm “:” SASLprep(password))

That is, the 16-byte key is formed by taking the MD5 hash of the result of concatenating the following five fields: (1) the username, with any quotes and trailing nulls removed, as taken from the USERNAME attribute (in which case SASLprep has already been applied); (2) a single colon; (3) the realm, with any quotes and trailing nulls removed; (4) a single colon; and (5) the password, with any trailing nulls removed and after processing using SASLprep. For example, if the username was ‘user’, the realm was ‘realm’, and the password was ‘pass’, then the 16-byte HMAC key would be the result of performing an MD5 hash on the string ‘user:realm:pass’, the resulting hash being 0x8493fbc53ba582fb4c044c456bdc40eb.

For short-term credentials:

key = SASLprep(password)

where MD5 is defined in RFC 1321 [RFC1321] and SASLprep() is defined in RFC 4013 [RFC4013].

The structure of the key when used with long-term credentials facilitates deployment in systems that also utilize SIP. Typically, SIP systems utilizing SIP’s digest authentication mechanism do not actually store the password in the database. Rather, they store a value called H(A1), which is equal to the key defined above.

Based on the rules above, the hash used to construct MESSAGE- INTEGRITY includes the length field from the STUN message header. Prior to performing the hash, the MESSAGE-INTEGRITY attribute MUST be inserted into the message (with dummy content). The length MUST then be set to point to the length of the message up to, and including, the MESSAGE-INTEGRITY attribute itself, but excluding any attributes after it. Once the computation is performed, the value of the MESSAGE-INTEGRITY attribute can be filled in, and the value of the length in the STUN header can be set to its correct value – the length of the entire message. Similarly, when validating the MESSAGE-INTEGRITY, the length field should be adjusted to point to the end of the MESSAGE-INTEGRITY attribute prior to calculating the HMAC. Such adjustment is necessary when attributes, such as FINGERPRINT, appear after MESSAGE-INTEGRITY.