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