[SR-Users] rtpengine flags UDP/TLS/RTP/SAVP and UDP/TLS/RTP/SAVPF

[Richard Fuchs]

On 11/17/2014 08:14 AM, Juha Heinanen wrote:
> Juha Heinanen writes:
> 
>> rtpengine source code, however, seems to know also these DTLS ones:
>>
>> daemon/call.c:		.name		= "UDP/TLS/RTP/SAVP",
>> daemon/call.c:		.name		= "UDP/TLS/RTP/SAVPF",
>>
>> can they be used in rtpengine_offer/answer calls even when they are
>> missing from README?
> 
> i made a test where invite has
> 
>   m=audio 50152 UDP/TLS/RTP/SAVP 96 97 8 0 101
> 
> and i call rtpengine_offer on it like this:
> 
>   rtpengine_offer(ICE=force replace-session-connection replace-origin via-branch=1 RTP/AVP trust-address)
> 
> and on 200 OK from callee which has
> 
>   m=audio 50162 RTP/AVP 96 97 8 0 101
> 
> i call rtpengine_answer like this:
> 
>   rtpengine_answer(ICE=force UDP/TLS/RTP/SAVP via-branch=2 trust-address)
> 
> rtpengine complains about it:
> 
>   Nov 17 15:07:32 rautu rtpengine[29718]: Unknown flag encountered: 'UDP/TLS/RTP/SAVP'
> 
> but still it has converted m line of the 200 OK to caller to this:
> 
>   m=audio 50180 UDP/TLS/RTP/SAVP 96 97 8 0 101
> 
> and audio works fine between the RTP/AVP UA (sems) and UDP/TLS/RTP/SAVP
> UA (baresip).
> 
> why the unknown flag message?

Because it's an unknown flag. :)

You only need to specify the transport protocol in an answer if you want
to change it from whatever the offering client sent (for whatever
reason). If you don't specify the protocol in the answer (and you
essentially did that as your flag wasn't understood and ignored), it
will reply with the same protocol that the offering client used, which
is normally what you want.

The command flags "RTP/AVP" etc are translated into the key
"transport-protocol=$X" within the control protocol. If you wish to
force usage of one of the UDP/TLS/... protocol, you should be able to do
so by spelling it out in your command. I believe this is not documented,
but should work.

FTR, RFC 5764 states that "UDP/TLS/..." must be used when DTLS-SRTP is
used, only WebRTC doesn't seem to honour that and omits this prefix,
possibly because SDES exists (or used to exist) as an alternative to
DTLS-SRTP within WebRTC. Which actually makes me wonder if WebRTC
clients actually understand the UDP/TLS/... protocols...

cheers