5 Sep
2017
5 Sep
'17
9:32 a.m.
Hello,
wondering if anyone has a quick answer to spare some time searching the
web or source code -- is there a way to offer optional SRTP (just SDES
is also fine) in SDP with RTPEngine? The use case is when the target
device is not yet known to support (or not) SRTP.
There are couple of ways in specs or practices (e.g., RFC5939/6871, or
advertising crypto attributes on RTP/AVP stream, or offering two streams
one RTP and one SRTP), I am looking to find if it is possible to do it
with RTPEngine and which of the options are supported/what are the
parameters for doing it...
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com
5 Sep
5 Sep
5:08 p.m.
On 09/05/2017 02:32 AM, Daniel-Constantin Mierla wrote:
Hello,
wondering if anyone has a quick answer to spare some time searching the
web or source code -- is there a way to offer optional SRTP (just SDES
is also fine) in SDP with RTPEngine? The use case is when the target
device is not yet known to support (or not) SRTP.
There are couple of ways in specs or practices (e.g., RFC5939/6871, or
advertising crypto attributes on RTP/AVP stream, or offering two streams
one RTP and one SRTP), I am looking to find if it is possible to do it
with RTPEngine and which of the options are supported/what are the
parameters for doing it...
That's not currently supported (neither as an offerer nor as an
accepter). AFAIK the usual mantra is to offer SRTP first and then
fallback to RTP when a "not supported" (415) is received.
However, it shouldn't be too hard to implement if there's a specific use
case.
Cheers
6:08 p.m.
On 05.09.17 16:08, Richard Fuchs wrote:
On 09/05/2017 02:32 AM, Daniel-Constantin Mierla
wrote:
Thanks for the info.
The use case is to do 'best possible' secure communication, in the way
that SRTP is offered, but call should not fail if not supported. Doing
re-routing on 415 could be a solution, however, I met the situation when
the call was accepted but then now audio was heard. It may be a broken
UA after wall.
Anyhow, if it is easy to add and you have some spare time at some point,
it would simplify doing best possible secure session.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com
Hello,
wondering if anyone has a quick answer to spare some time searching the
web or source code -- is there a way to offer optional SRTP (just SDES
is also fine) in SDP with RTPEngine? The use case is when the target
device is not yet known to support (or not) SRTP.
There are couple of ways in specs or practices (e.g., RFC5939/6871, or
advertising crypto attributes on RTP/AVP stream, or offering two streams
one RTP and one SRTP), I am looking to find if it is possible to do it
with RTPEngine and which of the options are supported/what are the
parameters for doing it...
That's not currently supported (neither as an offerer nor as an
accepter). AFAIK the usual mantra is to offer SRTP first and then
fallback to RTP when a "not supported" (415) is received.
However, it shouldn't be too hard to implement if there's a specific
use case. 
6 Oct
6 Oct
5:49 p.m.
Hello,
On Tue, Sep 5, 2017 at 4:08 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
That's not currently supported (neither as an
offerer nor as an accepter).
AFAIK the usual mantra is to offer SRTP first and then fallback to RTP when
a "not supported" (415) is received.
I tried the solution in a free minute today, but wondered how the
actual Kamailio config code should look like. I tried doing it in a
failure branch route.
My branch route looks like this:
branch_route[callToPhoneExtension] {
route("checkNat");
# handle branch failure on calls to TLS devices
if (isbflagset(0)) {
t_on_branch_failure("handle_tls_branch");
}
}
route checkNat does some NAT foo and sets the branch flag 0 if the
call goes to a TLS device. And calls the RTP proxy with RTP/SAVP
parameter.
When the call fails (my Snom returns a 488), I jump into the branch
failure route.
event_route[tm:branch-failure:handle_tls_branch] {
if(t_check_status("488")) {
if (isbflagset(0) && !isbflagset(1)) {
xlog("L_NOTICE", "Call to TLS device was
rejected, trying without SRTP F=$fu T=$tu R=$ru\n");
rtpengine_delete();
t_reuse_branch();
setbflag(1);
route("rtpProxyOffer");
t_relay();
}
}
}
This way I call rtpengine again with the RTP/AVP parameter and then
send the call to the device again.
Is this the way it should look like? My Kamailio doesn't send out the
request without me setting $du manually due to a bug
(https://github.com/kamailio/kamailio/issues/1264), but otherwise it
does work.
Was my approach the right one?
Best Regards,
Sebastian
2610
days inactive
2641
days old
3 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Richard Fuchs -
Sebastian Damm