Hello,

Just a generic remark - if you manage also the asterisk, I’d suggest to not use 
the SIP authentication method for outgoing calls and just allow all calls from 
Kamailio towards asterisk. This would make your setup easier and call setup 
also (slightly) faster.

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com<https://gilawa.com/>

From: Mathias Schneuwly <[email protected]>
Sent: Friday, January 13, 2023 9:08 AM
To: [email protected]
Subject: [SR-Users] Parallel call forking with call authorization

Hi

As a first notice; I already wrote to the mailing list, but without 
registration. I read afterwards that I should register first because of spam 
reasons. If this is a duplicate, then I'm sorry. I'm new to mailing lists...

I've an issue with parallel call forking together with call authentication. I 
hope somebody can give me some hints about what the problem could be and how I 
could solve this problem.

I'm using Kamailio 5.5.4 with the python KEMI binding.

Kamailio is in front of an Asterisk, which requires call authorization. 
RTPEngine is also inplace which does SRTP to RTP bridging. Simple calls from 
and to Asterisk through Kamailio and RTPEngine work without any issue. So the 
basic setup seems to work fine. The problem starts when I do parallel call 
forking where both calls are sent to Asterisk. If I use 
"KSR.tm.t_on_failure("trunk_authentication")" for authentication, the first 
branch is authenticating and the device rings, but the second branch does not 
authenticate. Well, that's not 100% true, if the SIP timeout appears on the 
first branch, I can see in the log, that the second branch enters the 
trunk_authentication method, but then, the call is already terminated.

Call forking to two devices (not behind Asterisk and without call 
authentication) works also as expected.

I made some trials with "KSR.tm.t_on_branch_failure("trunk_authentication")" 
but in this case, the behavior is strange. Then the authentication for both 
branches work and both devices are ringing. If a device hooks up, the second 
device does not stop ringing. And after a few seconds, the first device cancels 
the call, because it did not get the ACKs. I can also see that the CANCEL is 
sent from Kamailio to Asterisk, but Asterisk does not react to it.

For trunk authentication, I'm using the implementation from the well known 
examples plus a few own stuff. Btw, NAT is not enabled...:
    def trunk_authentication(self, msg):
        scode = KSR.pv.get("$T_reply_code")
        self.log('notice', 'trunk_authentication {}'.format(scode))

        if WITH_NAT and self.ksr_route_natmanage(msg) == -255:
            return 1

        # Call manage_rtp_engine to destroy RTPEngine if it has been used.
        call_context = self.get_call_context(msg=msg)
        callee_object = call_context.callee.get_callee_object()
        if callee_object.connection_type:
            call_context.manage_rtp_engine()

        if KSR.tm.t_is_canceled() > 0:
            return 1

        if scode in [401, 407]:
            KSR.pv.sets('$avp(auser)', 
KSR.pv.get('$sel(cfg_get.asterisk.trunk_username)'))
            KSR.pv.sets('$avp(apass)', 
KSR.pv.get('$sel(cfg_get.asterisk.trunk_password)'))
            if KSR.uac.uac_auth():
                # enable additional event routes for forwarded requests
                # - serial forking, RTP relaying handling, a.s.o.
                if KSR.is_method_in('IBSU'):
                    if KSR.tm.t_is_set("branch_route") < 0:
                        KSR.tm.t_on_branch("ksr_branch_manage")
                self.log('notice', 'Authentication Asterisk trunk')
                if KSR.tm.t_relay() < 0:
                    KSR.sl.sl_reply_error()
        return 1

Any ideas?

Best regards
Mathias
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

Reply via email to