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 <[email protected]>
Sent: Thursday, December 15, 2022 5:36 PM
To: Kamailio (SER) - Users Mailing List <[email protected]>
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
<[email protected]<mailto:[email protected]>> wrote:
On Dec 13, 2022, at 3:14 AM, Daniel-Constantin Mierla
<[email protected]<mailto:[email protected]>> 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/
__________________________________________________________
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:
