17 Nov
2014
17 Nov
'14
1:36 p.m.
rtpengine README lists these rtp protocol and profile flags:
+ RTP/AVP, RTP/SAVP, RTP/AVPF, RTP/SAVPF
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?
-- juha
17 Nov
17 Nov
2:14 p.m.
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?
-- juha
6 p.m.
New subject: rtpengine flags UDP/TLS/RTP/SAVP and UDP/TLS/RTP/SAVPF
On 11/17/2014 08:14 AM, Juha Heinanen wrote:
Juha Heinanen writes:
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
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?
18 Nov
18 Nov
1:15 a.m.
New subject: rtpengine flags UDP/TLS/RTP/SAVP and UDP/TLS/RTP/SAVPF
Richard Fuchs writes:
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.
nice to hear. it simplifies my kamailio config a bit.
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...
based on my tests, jssip at least does not understand UDP/TLS/..., which
is causing trouble. in order to make the mess bigger, looks like sdp
will be dropped from next generation webrtc altogether (see
http://ortc.org). this makes me wonder if it makes sense at all to try
to support webrtc clients in a sip proxy.
-- juha
3470
days inactive
3471
days old
3 comments
2 participants
participants (2)
-
Juha Heinanen -
Richard Fuchs