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]> wrote:
>
>
>> On Dec 13, 2022, at 3:14 AM, Daniel-Constantin Mierla <[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:
