[SR-Users] Re: Parallel call forking with call authorization

Hello Mathias, ok – if you got more details about that particular issue with the KEMI compared to the traditional cfg language, just open an issue on our tracker about it. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: Mathias Schneuwly &lt;mathias(a)schneuwlys.ch&gt; Sent: Friday, January 13, 2023 11:47 AM To: Henning Westerholt &lt;hw(a)gilawa.com&gt; Cc: sr-users(a)lists.kamailio.org Subject: Re: [SR-Users] Parallel call forking with call authorization Hi Henning We wanted to reach some sort of security, but you are probably right, that restricting the access from certain IPs would be good enough instead of call authentication. I need to think about it. But anyway, to me, something with failure-route and parallel call forking seems to be odd (at least using the python KEMI interpreter). More or less the same setup using the standard Kamailio dialplan (instead of KEMI), seems to work as expected. Best regards Mathias Am Fr., 13. Jan. 2023 um 11:04 Uhr schrieb Henning Westerholt <hw@gilawa.com<mailto:hw@gilawa.com>>: Hello Mathias, I do not fully understand your remark about the concerns that somebody else send calls to your asterisk over that special endpoint. If you configure the asterisk to only accept calls from a particular IP address, this should not be a problem. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: Mathias Schneuwly <mathias@schneuwlys.ch<mailto:mathias@schneuwlys.ch>> Sent: Friday, January 13, 2023 10:37 AM To: Henning Westerholt <hw@gilawa.com<mailto:hw@gilawa.com>> Cc: sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> Subject: Re: [SR-Users] Parallel call forking with call authorization Thanks for your reply This is what I'm doing at the moment to continue with the task as long as it does not work as I would expect. Without call authentication, the parallel forking works as expected. If somehow possible I would like to keep it since I don't want anybody to send calls to Asterisk using this endpoint. This is a special context in Asterisk which provides some special functions like incoming and outgoing call authentication using Pin and others... Best regards Mathias Am Fr., 13. Jan. 2023 um 10:20 Uhr schrieb Henning Westerholt <hw@gilawa.com<mailto:hw@gilawa.com>>: 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 <mathias@schneuwlys.ch<mailto:mathias@schneuwlys.ch>> Sent: Friday, January 13, 2023 9:08 AM To: sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org> 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