[SR-Users] Re: auth_challenge() and async

Hi Alex, it might not help you much, but recently I was implementing a similar structure in one larger migration project, and it seems to work fine. I am not using any special flags for the challenge etc.. It’s basically like this (pseudo-code) route{ if no auth user -> auth_challenge() else -> http_async_query(API, AUTH) } route[AUTH] { get API result for password if API failure -> auth_challenge() else -> pv_auth_check(..) route(next steps) } Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com<https://gilawa.com/> From: Alex Balashov &lt;abalashov(a)evaristesys.com&gt; Sent: Thursday, December 15, 2022 5:36 PM To: Kamailio (SER) - Users Mailing List &lt;sr-users(a)lists.kamailio.org&gt; Subject: [SR-Users] Re: auth_challenge() and async Just as an update, still haven't been able to solve this. I have tried a number of different permutations, but it seems that whenever a new INVITE (CSeq+1) comes in response to an auth challenge sent from a async resume route, the 407 challenge for the old INVITE keeps being retransmitted. It does not appear to matter if the auth challenge is failed: │IN 172.24.0.9:60921 172.24.0.7:5060 │VI ──────────┬───────── ──────────┬───────── │TE 16:30:56.392948 │ INVITE (SDP) │ │ s +0.000355 │ ──────────────────────────> │ │ip 16:30:56.393303 │ 100 trying -- your call is │ │:1 +0.002757 │ <────────────────────────── │ │00 16:30:56.396060 │ 407 Proxy Authentication R │ │@s +0.000213 │ <────────────────────────── │ │ip 16:30:56.396273 │ ACK │ │-p +0.201427 │ ──────────────────────────> │ │ro 16:30:56.597700 │ INVITE (SDP) │ │xy +0.000432 │ ──────────────────────────> │ │-d 16:30:56.598132 │ 100 trying -- your call is │ │ig +0.001420 │ <────────────────────────── │ │es 16:30:56.599552 │ 407 Proxy Authentication R │ │t- +0.000227 │ <────────────────────────── │ │au 16:30:56.599779 │ ACK │ │th +0.237534 │ ──────────────────────────> │ │:5 16:30:56.837313 │ 407 Proxy Authentication R │ │06 +1.000347 │ <────────────────────────── │ │0 16:30:57.837660 │ 407 Proxy Authentication R │ │SI +1.999542 │ <<<──────────────────────── │ │P/ 16:30:59.837202 │ 407 Proxy Authentication R │ │2. +0.000090 │ <<<──────────────────────── │ │0 16:30:59.837292 │ 407 Proxy Authentication R │ │Vi │ <<<──────────────────────── │ │a: │ │ │ S Or successful: │IN 172.24.0.9:49685 172.24.0.7:5060 172.24.0.8:│VI0 ──────────┬───────── ──────────┬───────── ──────────┬───│TE─ 16:30:56.835874 │ INVITE (SDP) │ │ │ s +0.001246 │ ──────────────────────────> │ │ │ip 16:30:56.837120 │ 100 trying -- your call is │ │ │:1 +0.003917 │ <────────────────────────── │ │ │00 16:30:56.841037 │ 407 Proxy Authentication R │ │ │@s +0.000577 │ <────────────────────────── │ │ │ip 16:30:56.841614 │ ACK │ │ │-p +0.200484 │ ──────────────────────────> │ │ │ro 16:30:57.042098 │ INVITE (SDP) │ │ │xy +0.000823 │ ──────────────────────────> │ │ │-d 16:30:57.042921 │ 100 trying -- your call is │ │ │ig +0.009837 │ <────────────────────────── │ │ │es 16:30:57.052758 │ │ INVITE (SDP) │ │t- +0.001506 │ │ ──────────────────────────> │ │au 16:30:57.054264 │ │ 100 Trying │ │th +0.001558 │ │ <────────────────────────── │ │:5 16:30:57.055822 │ │ 200 OK (SDP) │ │06 +0.000664 │ │ <────────────────────────── │ │0 16:30:57.056486 │ 200 OK (SDP) │ │ │SI +0.000854 │ <────────────────────────── │ │ │P/ 16:30:57.057340 │ ACK │ │ │2. +0.000447 │ ──────────────────────────> │ │ │0 16:30:57.057787 │ │ ACK │ │Vi +0.279666 │ │ ──────────────────────────> │ │a: 16:30:57.337453 │ 407 Proxy Authentication R │ │ │ S +0.224273 │ <────────────────────────── │ │ │IP 16:30:57.561726 │ │ BYE │ │/2 +0.001295 │ │ <────────────────────────── │ │.0 16:30:57.563021 │ BYE │ │ │/U +0.002180 │ <────────────────────────── │ │ │DP 16:30:57.565201 │ 200 OK Now │ │ │ 1 +0.000327 │ ──────────────────────────> │ │ │72 16:30:57.565528 │ │ 200 OK Now │ │.2 +0.771759 │ │ ──────────────────────────> │ │4. 16:30:58.337287 │ 407 Proxy Authentication R │ │ │0. +2.000408 │ <────────────────────────── │ │ │9: 16:31:00.337695 │ 407 Proxy Authentication R │ │ │49 +0.000158 │ <<<──────────────────────── │ │ │68 16:31:00.337853 │ 407 Proxy Authentication R │ │ │5; │ <<<──────────────────────── │ │ │rp │ │ │ │or │ │ │ │t; What does matter is if there is a subsequent INVITE at all. If there's not, no problem, no retransmission: │IN 172.24.0.9:33672 172.24.0.7:5060 │VI ──────────┬───────── ──────────┬───────── │TE 16:34:56.823495 │ INVITE (SDP) │ │ s +0.001047 │ ──────────────────────────> │ │ip 16:34:56.824542 │ 100 trying -- your call is │ │:1 +0.002516 │ <────────────────────────── │ │00 16:34:56.827058 │ 407 Proxy Authentication R │ │@s +0.000351 │ <────────────────────────── │ │ip 16:34:56.827409 │ ACK │ │-p │ ──────────────────────────> │ │ro │ │ │xy If the negative ACK were not being matched, I would think the retransmission would happen here too. It seems to happen because the subsequent INVITE keeps the old transaction alive and in its previous state somehow. Any suggestions welcome! -- Alex On Dec 13, 2022, at 8:54 AM, Alex Balashov <abalashov@evaristesys.com<mailto:abalashov@evaristesys.com>> wrote: On Dec 13, 2022, at 3:14 AM, Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>> wrote: change of cseq results in a different transaction, there should be two at the same time for a short interval. Try to see if debug=3 offers any hints. Makes sense. What I'm wondering is why the ACK for the negative reply (407) isn't processed and doesn't seem to result in immediate termination of the first transaction. This doesn't happen if I only suspend once. There is no problem in that scenario. For clarification: do you need to do authentication two times? Second time with pv function? No, the process is basically that I don't know whether I need to do digest authentication until a preliminary routing query happens (async) first, and if I do, then I return a 407 challenge from that transaction. I then receive a new INVITE with digest credentials, and I (async) query for the credentials-info (HA1 of password), and then I auth_check() the received digest credentials against the info. If not valid, I issue another auth challenge, and if valid, I continue with route processing (again async). This sounds like a mess that Kamailio's async stuff wasn't really intended to support, maybe. I'm wondering if the simplest thing to seed the credentials-info into Kamailio somehow, e.g. via JSONRPC+htable, so that an async query is not required in order to obtain it dynamically. I was hoping to avoid that, but maybe there's not another way to do it? -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/