pub async fn process<'a>(
ctx: Context,
reader: MessageReader<'_, '_>,
bytes: &'a mut BytesMut,
) -> Result<Option<Response<'a>>, StunError>Expand description
process create permission request
When the server receives the CreatePermission request, it processes as per 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.
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.