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
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
On 05.09.17 16:08, Richard Fuchs wrote:
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.
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
Hello,
On Tue, Sep 5, 2017 at 4:08 PM, Richard Fuchs rfuchs@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
-
Daniel-Constantin Mierla -
Richard Fuchs -
Sebastian Damm