[SR-Users] rtpengine - optional srtp

Sebastian Damm damm at sipgate.de
Fri Oct 6 16:49:13 CEST 2017


Hello,

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



More information about the sr-users mailing list