rtpengine - optional srtp

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

rtpengine - optional srtp

Daniel-Constantin Mierla-6
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


_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: rtpengine - optional srtp

Richard Fuchs
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

_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: rtpengine - optional srtp

Daniel-Constantin Mierla-6


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

--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com


_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: rtpengine - optional srtp

Sebastian Damm-2
In reply to this post by Richard Fuchs
Hello,

On Tue, Sep 5, 2017 at 4:08 PM, Richard Fuchs <[hidden email]> 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

_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users