15 Dec
2022
15 Dec
'22
7:36 p.m.
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(a)evaristesys.com> wrote:
--
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/
On Dec 13, 2022, at 3:14 AM, Daniel-Constantin
Mierla <miconda(a)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/