Right now our implementation of REQUESTED-TRANSPORT attribute only allows :udp as a selected protocol. Every other value will raise during encoding, and raise or return an error when decoding such message.
It seemed convenient at the beginning - we aimed to be compliant only with original TURN RFC (for start) which allows only UDP as a requested relay transport.
However, this approach is not so good when working on a server side of things. There is a special error code which needs to be sent back by the server when it doesn't understand, provide or allow relay over requested transport protocol.
We need figure out how to decode this attribute when we don't know the protocol included, so that the server can use Jerboa to decode such message and respond appropriately.
Right now our implementation of REQUESTED-TRANSPORT attribute only allows
:udp
as a selected protocol. Every other value will raise during encoding, and raise or return an error when decoding such message.It seemed convenient at the beginning - we aimed to be compliant only with original TURN RFC (for start) which allows only UDP as a requested relay transport.
However, this approach is not so good when working on a server side of things. There is a special error code which needs to be sent back by the server when it doesn't understand, provide or allow relay over requested transport protocol.
We need figure out how to decode this attribute when we don't know the protocol included, so that the server can use Jerboa to decode such message and respond appropriately.