6 Oct
2017
6 Oct
'17
4: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