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 <h...@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
>
>
>
> *From:* Mathias Schneuwly <math...@schneuwlys.ch>
> *Sent:* Friday, January 13, 2023 10:37 AM
> *To:* Henning Westerholt <h...@gilawa.com>
> *Cc:* 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 <
> h...@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
>
>
>
> *From:* Mathias Schneuwly <math...@schneuwlys.ch>
> *Sent:* Friday, January 13, 2023 9:08 AM
> *To:* 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
>
>
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
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