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