reTurn ToDo List

Table of Contents General TODO TURN TODO's RFC5389 TODO's Client TODO Client Notes

reduce library use - remove BOOST and/or rutil requirement - remove ASIO for client??
allow multiple interfaces to be used for relay
per user allocation quota enforcement
cleanup stun message class so that there are accessors for all data members
Multi-threaded support
Bandwidth check
TCP Relay
Short Term passwords do not make any sense in reTurnServer (outside of RFC3489 backcompat) - they need to be supported on client APIs
reTurn Server Asynchronous Authentication

Clients need to install permissions before data can be sent - need to queue outbound data until CreateChannel response is received
ChannelData messages must be padded to a multiple of 4 bytes, the padding is not to be reflected in the encoded length
When client receives a Data Ind - it should ensure it is from an endpoint that it believes that it has installed a permission for, otherwise drop
It is recommended that the client check if a permission exists towards the peer that just send a ChannelData message, if not - discard
Could add checking that ChannelData messages always begin with bits 0b01, since bits 0b10 and 0b11 are reserved
Need to give clients the ability to add Don't Fragment header to Allocate request
If request with Don't Fragment fails with 420 code, then it can be retried without Don't Fragment (this will likely remain the responsibilty of the reTurn client application)
It is recommended that the server impose limits on both the number of allocations active at one time for a given username and on the amount of bandwidth those allocations use. - 486 (Allocation Quota Exceeded)
Port allocation algorithm should be better to ensure we won't run into collisions with other applications - port allocations should be random
If the client receives a 400 response to a channel-bind request, then it is recommended that the allocation be deleted, and the client start again with a new allocation

Username must contain UTF-8 sequence of bytes, and must have been processed by SASLprep
Realm qdtext or quoted-pair - It must UTF-8 encoded and MUST be less than 128 characters (which can be as long as 763 bytes), and must be processed by SASLprep
Nonce qdtext or quoted-pair - MUST be less than 128 characters (which can be as long as 763 bytes)
Software must be a UTF-8 sequence of less than 128 characters (which can be as long as 763 byes)
The Password used in the HMAC key must be SASLprep processed
remove quotes and trailing nulls from username, realm. remove trailing nulls from password before forming MD5 hash for message integrity
Errorcode Reason Phrase must be a UTF-8 sequence of less than 128 characters (which can be as long as 763 byes)
need handling for 300 Try Alternate response - currently applications responsibility
the following values should be configurable
- Initial RTO (default 500ms)
- Rc (default 7)
- Rm (default 16)
actual RTO should be calculated
UDP retransmissions should stop if a hard ICMP error is seen
DNS SRV Discovery - currently only does host record lookup (using ASIO) - _stun._udp, _stun._tcp, _stuns._tcp, _turn._udp, _turn._tcp, _turns._tcp

rework synchronous sockets to use Asynchrous sockets to unify implementation better
keepalive usage??
add option to require message integrity - depends on usage - ICE
add ability to install a permission or binding without sending data

retries should be paced at 500ms, 1000ms, 2000ms, etc. - after 442, 443, or 444 response - currently applications responsibility
If a client receives a 437 allocation mismatch response to an allocate, then it should retry using a different client transport address - it should do this 3 times (this will likely remain the responsibilty of the reTurn client application)
To prevent race conditions a client MUST wait 5 mins after the channel binding expires before attempting to bind the channel number to a different transport address or the transport address to a different channel number (within the same allocation?).

Provide feedback