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 <abalas...@evaristesys.com> wrote: > > >> On Dec 13, 2022, at 3:14 AM, Daniel-Constantin Mierla <mico...@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/
__________________________________________________________ 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: