12 Dec
2022
12 Dec
'22
11:45 p.m.
Hi,
Is there any good solution for the scenario of an auth_challenge() with two separate
transaction suspensions?
To clarify (simplified):
request_route {
...
t_newtran();
if(!is_present_hf("Authorization") &&
!is_present_hf("Proxy-Authorization")) {
auth_challenge("$fd", "1");
exit;
}
# TM suspend/continue
t_newtran();
async credentials query("RESUME_AUTH");
}
route[RESUME_AUTH] {
# Credentials received into PVs.
if(!pv_auth_check("...")) {
auth_challenge("$fd", "1");
exit;
}
# Create transaction shell if not exists already from auth query.
if(!t_lookup_request())
t_newtran();
# TM suspend/continue
async route query("RESUME_ROUTING");
}
route[RESUME_ROUTING] {
# Unmarshal etc.
t_relay(); # etc.
}
What happens here is that the first auth_challenge() results in a retransmission of its
407 challenge without absorbing the negative ACK. This is despite the ostensibly stateful
behaviour of auth_challenge() without "force_stateless_reply" enabled.
In this case, it eclipses the second, unrelated 407 challenge from the subsequent routing
query (407 challenge with +1 CSeq):

-- 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/
12 Dec
12 Dec
11:53 p.m.
To be clear, the two t_newtran() calls in the main request_route were naturally a typo.
:-) Only the first one was intended.
On Dec 12, 2022, at 3:45 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Hi,
Is there any good solution for the scenario of an auth_challenge() with two separate
transaction suspensions?
To clarify (simplified):
request_route {
...
t_newtran();
if(!is_present_hf("Authorization") &&
!is_present_hf("Proxy-Authorization")) {
auth_challenge("$fd", "1");
exit;
}
# TM suspend/continue
t_newtran();
async credentials query("RESUME_AUTH");
}
route[RESUME_AUTH] {
# Credentials received into PVs.
if(!pv_auth_check("...")) {
auth_challenge("$fd", "1");
exit;
}
# Create transaction shell if not exists already from auth query.
if(!t_lookup_request())
t_newtran();
# TM suspend/continue
async route query("RESUME_ROUTING");
}
route[RESUME_ROUTING] {
# Unmarshal etc.
t_relay(); # etc.
}
What happens here is that the first auth_challenge() results in a retransmission of its
407 challenge without absorbing the negative ACK. This is despite the ostensibly stateful
behaviour of auth_challenge() without "force_stateless_reply" enabled.
In this case, it eclipses the second, unrelated 407 challenge from the subsequent routing
query (407 challenge with +1 CSeq):
<Screenshot 2022-12-12 at 3.44.15 PM.jpeg>
-- 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/
13 Dec
13 Dec
11:14 a.m.
Hello,
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.
For clarification: do you need to do authentication two times? Second
time with pv function?
Cheers,
Daniel
On 12.12.22 21:53, Alex Balashov wrote:
To be clear, the two t_newtran() calls in the main
request_route were naturally a typo. :-) Only the first one was intended.
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
On Dec 12, 2022, at 3:45 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Hi,
Is there any good solution for the scenario of an auth_challenge() with two separate
transaction suspensions?
To clarify (simplified):
request_route {
...
t_newtran();
if(!is_present_hf("Authorization") &&
!is_present_hf("Proxy-Authorization")) {
auth_challenge("$fd", "1");
exit;
}
# TM suspend/continue
t_newtran();
async credentials query("RESUME_AUTH");
}
route[RESUME_AUTH] {
# Credentials received into PVs.
if(!pv_auth_check("...")) {
auth_challenge("$fd", "1");
exit;
}
# Create transaction shell if not exists already from auth query.
if(!t_lookup_request())
t_newtran();
# TM suspend/continue
async route query("RESUME_ROUTING");
}
route[RESUME_ROUTING] {
# Unmarshal etc.
t_relay(); # etc.
}
What happens here is that the first auth_challenge() results in a retransmission of its
407 challenge without absorbing the negative ACK. This is despite the ostensibly stateful
behaviour of auth_challenge() without "force_stateless_reply" enabled.
In this case, it eclipses the second, unrelated 407 challenge from the subsequent routing
query (407 challenge with +1 CSeq):
<Screenshot 2022-12-12 at 3.44.15 PM.jpeg>
-- 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
sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
4:54 p.m.
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/
15 Dec
15 Dec
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/
7:51 p.m.
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 <abalashov(a)evaristesys.com>
Sent: Thursday, December 15, 2022 5:36 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
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/
8 p.m.
Hi Henning,
On Dec 15, 2022, at 11:51 AM, Henning Westerholt
<hw(a)gilawa.com> wrote:
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)
}
Yeah, that's more or less what I've got, except the first part.
I don't auth_challenge() every request because some requests are allowed by static IP,
and I don't know whether to auth_challenge() them unless I am already in the async
resume context.
I have eliminated the independent credentials query. At this point my process is more:
request_route {
...
http_async_query(API, RESUME)
}
route[RESUME] {
if(method == "INVITE") {
if(has_auth_attrib()) {
if(!pv_auth_check(...)) {
auth_challenge("realm", "1");
exit;
}
}
# Get more routing info.
http_async_query(API, RESUME2)
return;
}
}
route[RESUME2} {
t_relay() etc
}
-- 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/
8:23 p.m.
Well, the difference seems pretty clear. In a scenario with an auth challenge and no
subsequent INVITE+credentials, the negative ACK is matched:
4(54) DEBUG: <core> [core/receive.c:389]: receive_msg(): --- received sip message -
request - call-id: [01eed151-4234-4518-9a0e-9b9168f21a3f] - cseq: [288439 ACK]
4(54) DEBUG: <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route
core:pre-routing not defined
4(54) DEBUG: <core> [core/receive.c:471]: receive_msg(): preparing to run routing
scripts...
4(54) DEBUG: sl [sl_funcs.c:447]: sl_filter_ACK(): too late to be a local ACK!
4(54) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name():
parsed header name [Content-Length] type 12
4(54) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
4(54) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of
header
4(54) DEBUG: maxfwd [mf_funcs.c:55]: is_maxfwd_present(): max_forwards header not found!
4(54) DEBUG: siputils [checks.c:123]: has_totag(): totag found
4(54) DEBUG: rr [loose.c:108]: find_first_route(): No Route headers found
4(54) DEBUG: rr [loose.c:1006]: loose_route_mode(): There is no Route HF
4(54) DEBUG: tm [t_lookup.c:1053]: t_check_msg(): msg (0xffffa72f7088) id=14/54 global
id=13/54 T start=0
4(54) DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=42311,
isACK=1
4(54) DEBUG: tm [t_lookup.c:439]: matching_3261(): RFC3261 transaction matched,
tid=SG.ceb57d44-7388-4739-9a86-d44ea04d974d
4(54) DEBUG: tm [t_lookup.c:692]: t_lookup_request(): transaction found
(T=0xffffa2f428a8)
4(54) DEBUG: tm [t_lookup.c:1122]: t_check_msg(): msg (0xffffa72f7088) id=14/54 global
id=14/54 T end=0xffffa2f428a8
4(54) DEBUG: tm [t_reply.c:1763]: cleanup_uac_timers(): RETR/FR timers reset
4(54) DEBUG: tm [t_funcs.c:120]: put_on_wait(): put T [0xffffa2f428a8] on wait
4(54) DEBUG: <core> [core/timer.c:557]: timer_add_safe(): timer_add called on an
active timer 0xffffa2f42930 (0xffffa2d05d08, 0xffffa2d05d08), flags 201
4(54) DEBUG: tm [t_funcs.c:143]: put_on_wait(): transaction 0xffffa2f428a8 already on
wait
However, in a scenario with an auth challenge with subsequent INVITE+credentials, the same
negative ACK is not matched to a known transaction.
2(52) DEBUG: <core> [core/receive.c:389]: receive_msg(): --- received sip message -
request - call-id: [895a7051-3e0c-410a-88ea-4bad7a1c21b6] - cseq: [939189 ACK]
2(52) DEBUG: <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route
core:pre-routing not defined
2(52) DEBUG: <core> [core/receive.c:471]: receive_msg(): preparing to run routing
scripts...
2(52) DEBUG: sl [sl_funcs.c:447]: sl_filter_ACK(): too late to be a local ACK!
2(52) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name():
parsed header name [Content-Length] type 12
2(52) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
2(52) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of
header
2(52) DEBUG: maxfwd [mf_funcs.c:55]: is_maxfwd_present(): max_forwards header not found!
2(52) DEBUG: siputils [checks.c:123]: has_totag(): totag found
2(52) DEBUG: rr [loose.c:108]: find_first_route(): No Route headers found
2(52) DEBUG: rr [loose.c:1006]: loose_route_mode(): There is no Route HF
2(52) DEBUG: tm [t_lookup.c:1053]: t_check_msg(): msg (0xffffa72f7088) id=19/52 global
id=18/52 T start=0
2(52) DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=21251,
isACK=1
2(52) DEBUG: tm [t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed -
via branch [z9hG4bKSG.c52861b7-2535-4080-84f5-2819c4169843]
2(52) DEBUG: tm [t_lookup.c:675]: t_lookup_request(): no transaction found
This makes sense intuitively; the auth_challenge(), and resulting 407 challenge, should
have ended the old transaction, so the negative ACK should just be absorbed.
But in that case, why does the 407 keep being retransmitted?
-- Alex
On Dec 15, 2022, at 12:00 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Hi Henning,
--
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 15, 2022, at 11:51 AM, Henning Westerholt
<hw(a)gilawa.com> wrote:
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)
}
Yeah, that's more or less what I've got, except the first part.
I don't auth_challenge() every request because some requests are allowed by static
IP, and I don't know whether to auth_challenge() them unless I am already in the async
resume context.
I have eliminated the independent credentials query. At this point my process is more:
request_route {
...
http_async_query(API, RESUME)
}
route[RESUME] {
if(method == "INVITE") {
if(has_auth_attrib()) {
if(!pv_auth_check(...)) {
auth_challenge("realm", "1");
exit;
}
}
# Get more routing info.
http_async_query(API, RESUME2)
return;
}
}
route[RESUME2} {
t_relay() etc
}
-- 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/
8:42 p.m.
As a test, I tried to put the auth_challenge() in the request_route before any async
suspension, and in that case works fine.
The issue is definitely with the way auth_challenge() issued from _within_ an async resume
route (failure_route context) bears upon transaction state.
-- Alex
On Dec 15, 2022, at 12:23 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Well, the difference seems pretty clear. In a scenario with an auth challenge and no
subsequent INVITE+credentials, the negative ACK is matched:
4(54) DEBUG: <core> [core/receive.c:389]: receive_msg(): --- received sip message -
request - call-id: [01eed151-4234-4518-9a0e-9b9168f21a3f] - cseq: [288439 ACK]
4(54) DEBUG: <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route
core:pre-routing not defined
4(54) DEBUG: <core> [core/receive.c:471]: receive_msg(): preparing to run routing
scripts...
4(54) DEBUG: sl [sl_funcs.c:447]: sl_filter_ACK(): too late to be a local ACK!
4(54) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name():
parsed header name [Content-Length] type 12
4(54) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
4(54) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of
header
4(54) DEBUG: maxfwd [mf_funcs.c:55]: is_maxfwd_present(): max_forwards header not found!
4(54) DEBUG: siputils [checks.c:123]: has_totag(): totag found
4(54) DEBUG: rr [loose.c:108]: find_first_route(): No Route headers found
4(54) DEBUG: rr [loose.c:1006]: loose_route_mode(): There is no Route HF
4(54) DEBUG: tm [t_lookup.c:1053]: t_check_msg(): msg (0xffffa72f7088) id=14/54 global
id=13/54 T start=0
4(54) DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=42311,
isACK=1
4(54) DEBUG: tm [t_lookup.c:439]: matching_3261(): RFC3261 transaction matched,
tid=SG.ceb57d44-7388-4739-9a86-d44ea04d974d
4(54) DEBUG: tm [t_lookup.c:692]: t_lookup_request(): transaction found
(T=0xffffa2f428a8)
4(54) DEBUG: tm [t_lookup.c:1122]: t_check_msg(): msg (0xffffa72f7088) id=14/54 global
id=14/54 T end=0xffffa2f428a8
4(54) DEBUG: tm [t_reply.c:1763]: cleanup_uac_timers(): RETR/FR timers reset
4(54) DEBUG: tm [t_funcs.c:120]: put_on_wait(): put T [0xffffa2f428a8] on wait
4(54) DEBUG: <core> [core/timer.c:557]: timer_add_safe(): timer_add called on an
active timer 0xffffa2f42930 (0xffffa2d05d08, 0xffffa2d05d08), flags 201
4(54) DEBUG: tm [t_funcs.c:143]: put_on_wait(): transaction 0xffffa2f428a8 already on
wait
However, in a scenario with an auth challenge with subsequent INVITE+credentials, the
same negative ACK is not matched to a known transaction.
2(52) DEBUG: <core> [core/receive.c:389]: receive_msg(): --- received sip message -
request - call-id: [895a7051-3e0c-410a-88ea-4bad7a1c21b6] - cseq: [939189 ACK]
2(52) DEBUG: <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route
core:pre-routing not defined
2(52) DEBUG: <core> [core/receive.c:471]: receive_msg(): preparing to run routing
scripts...
2(52) DEBUG: sl [sl_funcs.c:447]: sl_filter_ACK(): too late to be a local ACK!
2(52) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name():
parsed header name [Content-Length] type 12
2(52) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
2(52) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of
header
2(52) DEBUG: maxfwd [mf_funcs.c:55]: is_maxfwd_present(): max_forwards header not found!
2(52) DEBUG: siputils [checks.c:123]: has_totag(): totag found
2(52) DEBUG: rr [loose.c:108]: find_first_route(): No Route headers found
2(52) DEBUG: rr [loose.c:1006]: loose_route_mode(): There is no Route HF
2(52) DEBUG: tm [t_lookup.c:1053]: t_check_msg(): msg (0xffffa72f7088) id=19/52 global
id=18/52 T start=0
2(52) DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=21251,
isACK=1
2(52) DEBUG: tm [t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed -
via branch [z9hG4bKSG.c52861b7-2535-4080-84f5-2819c4169843]
2(52) DEBUG: tm [t_lookup.c:675]: t_lookup_request(): no transaction found
This makes sense intuitively; the auth_challenge(), and resulting 407 challenge, should
have ended the old transaction, so the negative ACK should just be absorbed.
But in that case, why does the 407 keep being retransmitted?
-- 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/
On Dec 15, 2022, at 12:00 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Hi Henning,
--
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 15, 2022, at 11:51 AM, Henning Westerholt
<hw(a)gilawa.com> wrote:
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)
}
Yeah, that's more or less what I've got, except the first part.
I don't auth_challenge() every request because some requests are allowed by static
IP, and I don't know whether to auth_challenge() them unless I am already in the async
resume context.
I have eliminated the independent credentials query. At this point my process is more:
request_route {
...
http_async_query(API, RESUME)
}
route[RESUME] {
if(method == "INVITE") {
if(has_auth_attrib()) {
if(!pv_auth_check(...)) {
auth_challenge("realm", "1");
exit;
}
}
# Get more routing info.
http_async_query(API, RESUME2)
return;
}
}
route[RESUME2} {
t_relay() etc
}
-- 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/
10:21 p.m.
Adding further to this, it seems to me the real problem is that I can't use
t_release() in an async resume route, because it's internally structured to take place
inside a failure_route context. If I could, I think that would rid me of the first
transaction after I send the challenge and call 'exit'.
On Dec 15, 2022, at 12:42 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
As a test, I tried to put the auth_challenge() in the request_route before any async
suspension, and in that case works fine.
The issue is definitely with the way auth_challenge() issued from _within_ an async
resume route (failure_route context) bears upon transaction state.
-- 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/
On Dec 15, 2022, at 12:23 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Well, the difference seems pretty clear. In a scenario with an auth challenge and no
subsequent INVITE+credentials, the negative ACK is matched:
4(54) DEBUG: <core> [core/receive.c:389]: receive_msg(): --- received sip message -
request - call-id: [01eed151-4234-4518-9a0e-9b9168f21a3f] - cseq: [288439 ACK]
4(54) DEBUG: <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route
core:pre-routing not defined
4(54) DEBUG: <core> [core/receive.c:471]: receive_msg(): preparing to run routing
scripts...
4(54) DEBUG: sl [sl_funcs.c:447]: sl_filter_ACK(): too late to be a local ACK!
4(54) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name():
parsed header name [Content-Length] type 12
4(54) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
4(54) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of
header
4(54) DEBUG: maxfwd [mf_funcs.c:55]: is_maxfwd_present(): max_forwards header not found!
4(54) DEBUG: siputils [checks.c:123]: has_totag(): totag found
4(54) DEBUG: rr [loose.c:108]: find_first_route(): No Route headers found
4(54) DEBUG: rr [loose.c:1006]: loose_route_mode(): There is no Route HF
4(54) DEBUG: tm [t_lookup.c:1053]: t_check_msg(): msg (0xffffa72f7088) id=14/54 global
id=13/54 T start=0
4(54) DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=42311,
isACK=1
4(54) DEBUG: tm [t_lookup.c:439]: matching_3261(): RFC3261 transaction matched,
tid=SG.ceb57d44-7388-4739-9a86-d44ea04d974d
4(54) DEBUG: tm [t_lookup.c:692]: t_lookup_request(): transaction found
(T=0xffffa2f428a8)
4(54) DEBUG: tm [t_lookup.c:1122]: t_check_msg(): msg (0xffffa72f7088) id=14/54 global
id=14/54 T end=0xffffa2f428a8
4(54) DEBUG: tm [t_reply.c:1763]: cleanup_uac_timers(): RETR/FR timers reset
4(54) DEBUG: tm [t_funcs.c:120]: put_on_wait(): put T [0xffffa2f428a8] on wait
4(54) DEBUG: <core> [core/timer.c:557]: timer_add_safe(): timer_add called on an
active timer 0xffffa2f42930 (0xffffa2d05d08, 0xffffa2d05d08), flags 201
4(54) DEBUG: tm [t_funcs.c:143]: put_on_wait(): transaction 0xffffa2f428a8 already on
wait
However, in a scenario with an auth challenge with subsequent INVITE+credentials, the
same negative ACK is not matched to a known transaction.
2(52) DEBUG: <core> [core/receive.c:389]: receive_msg(): --- received sip message -
request - call-id: [895a7051-3e0c-410a-88ea-4bad7a1c21b6] - cseq: [939189 ACK]
2(52) DEBUG: <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route
core:pre-routing not defined
2(52) DEBUG: <core> [core/receive.c:471]: receive_msg(): preparing to run routing
scripts...
2(52) DEBUG: sl [sl_funcs.c:447]: sl_filter_ACK(): too late to be a local ACK!
2(52) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name():
parsed header name [Content-Length] type 12
2(52) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
2(52) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of
header
2(52) DEBUG: maxfwd [mf_funcs.c:55]: is_maxfwd_present(): max_forwards header not found!
2(52) DEBUG: siputils [checks.c:123]: has_totag(): totag found
2(52) DEBUG: rr [loose.c:108]: find_first_route(): No Route headers found
2(52) DEBUG: rr [loose.c:1006]: loose_route_mode(): There is no Route HF
2(52) DEBUG: tm [t_lookup.c:1053]: t_check_msg(): msg (0xffffa72f7088) id=19/52 global
id=18/52 T start=0
2(52) DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=21251,
isACK=1
2(52) DEBUG: tm [t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed -
via branch [z9hG4bKSG.c52861b7-2535-4080-84f5-2819c4169843]
2(52) DEBUG: tm [t_lookup.c:675]: t_lookup_request(): no transaction found
This makes sense intuitively; the auth_challenge(), and resulting 407 challenge, should
have ended the old transaction, so the negative ACK should just be absorbed.
But in that case, why does the 407 keep being retransmitted?
-- 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/
On Dec 15, 2022, at 12:00 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Hi Henning,
--
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 15, 2022, at 11:51 AM, Henning Westerholt
<hw(a)gilawa.com> wrote:
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)
}
Yeah, that's more or less what I've got, except the first part.
I don't auth_challenge() every request because some requests are allowed by static
IP, and I don't know whether to auth_challenge() them unless I am already in the async
resume context.
I have eliminated the independent credentials query. At this point my process is more:
request_route {
...
http_async_query(API, RESUME)
}
route[RESUME] {
if(method == "INVITE") {
if(has_auth_attrib()) {
if(!pv_auth_check(...)) {
auth_challenge("realm", "1");
exit;
}
}
# Get more routing info.
http_async_query(API, RESUME2)
return;
}
}
route[RESUME2} {
t_relay() etc
}
-- 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/
10:40 p.m.
Setting tm.wt_timer to a very low value (e.g. 200 ms) does provide a hack around this
behaviour, but it doesn't seem to me that this is the correct solution.
│AC
172.24.0.9:39777 172.24.0.7:5060 │K
──────────┬───────── ──────────┬───────── │si
19:38:44.386913 │ INVITE (SDP) │ │p:
+0.001550 │ ──────────────────────────> │ │10
19:38:44.388463 │ 100 trying -- your call is │ │0@
+0.003336 │ <────────────────────────── │ │si
19:38:44.391799 │ 407 Proxy Authentication R │ │p-
+0.000234 │ <────────────────────────── │ │pr
19:38:44.392033 │ ACK │ │ox
+0.201070 │ ──────────────────────────> │ │y-
19:38:44.593103 │ INVITE (SDP) │ │di
+0.004226 │ ──────────────────────────> │ │ge
19:38:44.597329 │ 100 trying -- your call is │ │st
+0.003063 │ <────────────────────────── │ │-a
19:38:44.600392 │ 407 Proxy Authentication R │ │ut
+0.000489 │ <────────────────────────── │ │h:
19:38:44.600881 │ ACK │ │50
│ ──────────────────────────> │ │60
│ │ │ S
The real question is why the negative ACK for the first transaction doesn't seem to be
having the intended effect in this scenario.
-- Alex
On Dec 15, 2022, at 2:21 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Adding further to this, it seems to me the real problem is that I can't use
t_release() in an async resume route, because it's internally structured to take place
inside a failure_route context. If I could, I think that would rid me of the first
transaction after I send the challenge and call 'exit'.
--
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 15, 2022, at 12:42 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
As a test, I tried to put the auth_challenge() in the request_route before any async
suspension, and in that case works fine.
The issue is definitely with the way auth_challenge() issued from _within_ an async
resume route (failure_route context) bears upon transaction state.
-- 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/
On Dec 15, 2022, at 12:23 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Well, the difference seems pretty clear. In a scenario with an auth challenge and no
subsequent INVITE+credentials, the negative ACK is matched:
4(54) DEBUG: <core> [core/receive.c:389]: receive_msg(): --- received sip message -
request - call-id: [01eed151-4234-4518-9a0e-9b9168f21a3f] - cseq: [288439 ACK]
4(54) DEBUG: <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route
core:pre-routing not defined
4(54) DEBUG: <core> [core/receive.c:471]: receive_msg(): preparing to run routing
scripts...
4(54) DEBUG: sl [sl_funcs.c:447]: sl_filter_ACK(): too late to be a local ACK!
4(54) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name():
parsed header name [Content-Length] type 12
4(54) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
4(54) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of
header
4(54) DEBUG: maxfwd [mf_funcs.c:55]: is_maxfwd_present(): max_forwards header not found!
4(54) DEBUG: siputils [checks.c:123]: has_totag(): totag found
4(54) DEBUG: rr [loose.c:108]: find_first_route(): No Route headers found
4(54) DEBUG: rr [loose.c:1006]: loose_route_mode(): There is no Route HF
4(54) DEBUG: tm [t_lookup.c:1053]: t_check_msg(): msg (0xffffa72f7088) id=14/54 global
id=13/54 T start=0
4(54) DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=42311,
isACK=1
4(54) DEBUG: tm [t_lookup.c:439]: matching_3261(): RFC3261 transaction matched,
tid=SG.ceb57d44-7388-4739-9a86-d44ea04d974d
4(54) DEBUG: tm [t_lookup.c:692]: t_lookup_request(): transaction found
(T=0xffffa2f428a8)
4(54) DEBUG: tm [t_lookup.c:1122]: t_check_msg(): msg (0xffffa72f7088) id=14/54 global
id=14/54 T end=0xffffa2f428a8
4(54) DEBUG: tm [t_reply.c:1763]: cleanup_uac_timers(): RETR/FR timers reset
4(54) DEBUG: tm [t_funcs.c:120]: put_on_wait(): put T [0xffffa2f428a8] on wait
4(54) DEBUG: <core> [core/timer.c:557]: timer_add_safe(): timer_add called on an
active timer 0xffffa2f42930 (0xffffa2d05d08, 0xffffa2d05d08), flags 201
4(54) DEBUG: tm [t_funcs.c:143]: put_on_wait(): transaction 0xffffa2f428a8 already on
wait
However, in a scenario with an auth challenge with subsequent INVITE+credentials, the
same negative ACK is not matched to a known transaction.
2(52) DEBUG: <core> [core/receive.c:389]: receive_msg(): --- received sip message -
request - call-id: [895a7051-3e0c-410a-88ea-4bad7a1c21b6] - cseq: [939189 ACK]
2(52) DEBUG: <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route
core:pre-routing not defined
2(52) DEBUG: <core> [core/receive.c:471]: receive_msg(): preparing to run routing
scripts...
2(52) DEBUG: sl [sl_funcs.c:447]: sl_filter_ACK(): too late to be a local ACK!
2(52) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name():
parsed header name [Content-Length] type 12
2(52) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
2(52) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of
header
2(52) DEBUG: maxfwd [mf_funcs.c:55]: is_maxfwd_present(): max_forwards header not found!
2(52) DEBUG: siputils [checks.c:123]: has_totag(): totag found
2(52) DEBUG: rr [loose.c:108]: find_first_route(): No Route headers found
2(52) DEBUG: rr [loose.c:1006]: loose_route_mode(): There is no Route HF
2(52) DEBUG: tm [t_lookup.c:1053]: t_check_msg(): msg (0xffffa72f7088) id=19/52 global
id=18/52 T start=0
2(52) DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=21251,
isACK=1
2(52) DEBUG: tm [t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed -
via branch [z9hG4bKSG.c52861b7-2535-4080-84f5-2819c4169843]
2(52) DEBUG: tm [t_lookup.c:675]: t_lookup_request(): no transaction found
This makes sense intuitively; the auth_challenge(), and resulting 407 challenge, should
have ended the old transaction, so the negative ACK should just be absorbed.
But in that case, why does the 407 keep being retransmitted?
-- 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/
On Dec 15, 2022, at 12:00 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Hi Henning,
> On Dec 15, 2022, at 11:51 AM, Henning Westerholt <hw(a)gilawa.com> wrote:
>
> 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)
> }
Yeah, that's more or less what I've got, except the first part.
I don't auth_challenge() every request because some requests are allowed by static
IP, and I don't know whether to auth_challenge() them unless I am already in the async
resume context.
I have eliminated the independent credentials query. At this point my process is more:
request_route {
...
http_async_query(API, RESUME)
}
route[RESUME] {
if(method == "INVITE") {
if(has_auth_attrib()) {
if(!pv_auth_check(...)) {
auth_challenge("realm", "1");
exit;
}
}
# Get more routing info.
http_async_query(API, RESUME2)
return;
}
}
route[RESUME2} {
t_relay() etc
}
-- 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/
11:03 p.m.
One more thing, and I apologise profusely for the spam:
This is not caused by immediate re-suspension of the transaction upon successful
authorisation of new INVITE+credentials. Even if I attempt to complete the onward routing
in the same route which does the authentication, without any further TM suspend/continue,
I get the 407 retransmissions from the previous transaction, e.g.
route[RESUME] {
pv_auth_check() and the rest
$ru = "sip:asterisk-receiver:5060";
t_on_reply("MAIN_REPLY");
if(!t_relay())
t_reply("500", "Internal server error");
exit;
}
I can't say for sure what's going on, not knowing TM internals.
-- Alex
On Dec 15, 2022, at 2:40 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Setting tm.wt_timer to a very low value (e.g. 200 ms) does provide a hack around this
behaviour, but it doesn't seem to me that this is the correct solution.
│AC
172.24.0.9:39777 172.24.0.7:5060 │K
──────────┬───────── ──────────┬───────── │si
19:38:44.386913 │ INVITE (SDP) │ │p:
+0.001550 │ ──────────────────────────> │ │10
19:38:44.388463 │ 100 trying -- your call is │ │0@
+0.003336 │ <────────────────────────── │ │si
19:38:44.391799 │ 407 Proxy Authentication R │ │p-
+0.000234 │ <────────────────────────── │ │pr
19:38:44.392033 │ ACK │ │ox
+0.201070 │ ──────────────────────────> │ │y-
19:38:44.593103 │ INVITE (SDP) │ │di
+0.004226 │ ──────────────────────────> │ │ge
19:38:44.597329 │ 100 trying -- your call is │ │st
+0.003063 │ <────────────────────────── │ │-a
19:38:44.600392 │ 407 Proxy Authentication R │ │ut
+0.000489 │ <────────────────────────── │ │h:
19:38:44.600881 │ ACK │ │50
│ ──────────────────────────> │ │60
│ │ │ S
The real question is why the negative ACK for the first transaction doesn't seem to
be having the intended effect in this scenario.
-- 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/
On Dec 15, 2022, at 2:21 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Adding further to this, it seems to me the real problem is that I can't use
t_release() in an async resume route, because it's internally structured to take place
inside a failure_route context. If I could, I think that would rid me of the first
transaction after I send the challenge and call 'exit'.
--
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 15, 2022, at 12:42 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
As a test, I tried to put the auth_challenge() in the request_route before any async
suspension, and in that case works fine.
The issue is definitely with the way auth_challenge() issued from _within_ an async
resume route (failure_route context) bears upon transaction state.
-- 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/
On Dec 15, 2022, at 12:23 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Well, the difference seems pretty clear. In a scenario with an auth challenge and no
subsequent INVITE+credentials, the negative ACK is matched:
4(54) DEBUG: <core> [core/receive.c:389]: receive_msg(): --- received sip message -
request - call-id: [01eed151-4234-4518-9a0e-9b9168f21a3f] - cseq: [288439 ACK]
4(54) DEBUG: <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route
core:pre-routing not defined
4(54) DEBUG: <core> [core/receive.c:471]: receive_msg(): preparing to run routing
scripts...
4(54) DEBUG: sl [sl_funcs.c:447]: sl_filter_ACK(): too late to be a local ACK!
4(54) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name():
parsed header name [Content-Length] type 12
4(54) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
4(54) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of
header
4(54) DEBUG: maxfwd [mf_funcs.c:55]: is_maxfwd_present(): max_forwards header not found!
4(54) DEBUG: siputils [checks.c:123]: has_totag(): totag found
4(54) DEBUG: rr [loose.c:108]: find_first_route(): No Route headers found
4(54) DEBUG: rr [loose.c:1006]: loose_route_mode(): There is no Route HF
4(54) DEBUG: tm [t_lookup.c:1053]: t_check_msg(): msg (0xffffa72f7088) id=14/54 global
id=13/54 T start=0
4(54) DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=42311,
isACK=1
4(54) DEBUG: tm [t_lookup.c:439]: matching_3261(): RFC3261 transaction matched,
tid=SG.ceb57d44-7388-4739-9a86-d44ea04d974d
4(54) DEBUG: tm [t_lookup.c:692]: t_lookup_request(): transaction found
(T=0xffffa2f428a8)
4(54) DEBUG: tm [t_lookup.c:1122]: t_check_msg(): msg (0xffffa72f7088) id=14/54 global
id=14/54 T end=0xffffa2f428a8
4(54) DEBUG: tm [t_reply.c:1763]: cleanup_uac_timers(): RETR/FR timers reset
4(54) DEBUG: tm [t_funcs.c:120]: put_on_wait(): put T [0xffffa2f428a8] on wait
4(54) DEBUG: <core> [core/timer.c:557]: timer_add_safe(): timer_add called on an
active timer 0xffffa2f42930 (0xffffa2d05d08, 0xffffa2d05d08), flags 201
4(54) DEBUG: tm [t_funcs.c:143]: put_on_wait(): transaction 0xffffa2f428a8 already on
wait
However, in a scenario with an auth challenge with subsequent INVITE+credentials, the
same negative ACK is not matched to a known transaction.
2(52) DEBUG: <core> [core/receive.c:389]: receive_msg(): --- received sip message -
request - call-id: [895a7051-3e0c-410a-88ea-4bad7a1c21b6] - cseq: [939189 ACK]
2(52) DEBUG: <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route
core:pre-routing not defined
2(52) DEBUG: <core> [core/receive.c:471]: receive_msg(): preparing to run routing
scripts...
2(52) DEBUG: sl [sl_funcs.c:447]: sl_filter_ACK(): too late to be a local ACK!
2(52) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name():
parsed header name [Content-Length] type 12
2(52) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
2(52) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of
header
2(52) DEBUG: maxfwd [mf_funcs.c:55]: is_maxfwd_present(): max_forwards header not found!
2(52) DEBUG: siputils [checks.c:123]: has_totag(): totag found
2(52) DEBUG: rr [loose.c:108]: find_first_route(): No Route headers found
2(52) DEBUG: rr [loose.c:1006]: loose_route_mode(): There is no Route HF
2(52) DEBUG: tm [t_lookup.c:1053]: t_check_msg(): msg (0xffffa72f7088) id=19/52 global
id=18/52 T start=0
2(52) DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=21251,
isACK=1
2(52) DEBUG: tm [t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed -
via branch [z9hG4bKSG.c52861b7-2535-4080-84f5-2819c4169843]
2(52) DEBUG: tm [t_lookup.c:675]: t_lookup_request(): no transaction found
This makes sense intuitively; the auth_challenge(), and resulting 407 challenge, should
have ended the old transaction, so the negative ACK should just be absorbed.
But in that case, why does the 407 keep being retransmitted?
-- Alex
> On Dec 15, 2022, at 12:00 PM, Alex Balashov <abalashov(a)evaristesys.com> wrote:
>
> Hi Henning,
>
>> On Dec 15, 2022, at 11:51 AM, Henning Westerholt <hw(a)gilawa.com> wrote:
>>
>> 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)
>> }
>
> Yeah, that's more or less what I've got, except the first part.
>
> I don't auth_challenge() every request because some requests are allowed by
static IP, and I don't know whether to auth_challenge() them unless I am already in
the async resume context.
>
> I have eliminated the independent credentials query. At this point my process is
more:
>
> request_route {
> ...
>
> http_async_query(API, RESUME)
> }
>
> route[RESUME] {
> if(method == "INVITE") {
> if(has_auth_attrib()) {
> if(!pv_auth_check(...)) {
> auth_challenge("realm", "1");
> exit;
> }
> }
>
> # Get more routing info.
> http_async_query(API, RESUME2)
> return;
> }
> }
>
> route[RESUME2} {
> t_relay() etc
> }
>
> -- 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/
--
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/
16 Dec
16 Dec
11:40 a.m.
Hi Alex,
Thanks for sharing more insights about that. Yes, indeed hard to say why its happens
without digging into TM internals.
Does this also happens e.g. if you just create a reply with send_reply/t_reply, and not
with the auth_challenge()?
If it’s a generic issue, it might be sensible to create an issue about it to at least
document it in a structure way.
Cheers,
Henning
From: Alex Balashov <abalashov(a)evaristesys.com>
Sent: Thursday, December 15, 2022 9:03 PM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: [SR-Users] Re: auth_challenge() and async
One more thing, and I apologise profusely for the spam:
This is not caused by immediate re-suspension of the transaction upon successful
authorisation of new INVITE+credentials. Even if I attempt to complete the onward routing
in the same route which does the authentication, without any further TM suspend/continue,
I get the 407 retransmissions from the previous transaction, e.g.
route[RESUME] {
pv_auth_check() and the rest
$ru = "sip:asterisk-receiver:5060";
t_on_reply("MAIN_REPLY");
if(!t_relay())
t_reply("500", "Internal server error");
exit;
}
I can't say for sure what's going on, not knowing TM internals.
-- Alex
On Dec 15, 2022, at 2:40 PM, Alex Balashov
<abalashov@evaristesys.com<mailto:abalashov@evaristesys.com>> wrote:
Setting tm.wt_timer to a very low value (e.g. 200 ms) does provide a hack around this
behaviour, but it doesn't seem to me that this is the correct solution.
│AC
172.24.0.9:39777 172.24.0.7:5060 │K
──────────┬───────── ──────────┬───────── │si
19:38:44.386913 │ INVITE (SDP) │ │p:
+0.001550 │ ──────────────────────────> │ │10
19:38:44.388463 │ 100 trying -- your call is │ │0@
+0.003336 │ <────────────────────────── │ │si
19:38:44.391799 │ 407 Proxy Authentication R │ │p-
+0.000234 │ <────────────────────────── │ │pr
19:38:44.392033 │ ACK │ │ox
+0.201070 │ ──────────────────────────> │ │y-
19:38:44.593103 │ INVITE (SDP) │ │di
+0.004226 │ ──────────────────────────> │ │ge
19:38:44.597329 │ 100 trying -- your call is │ │st
+0.003063 │ <────────────────────────── │ │-a
19:38:44.600392 │ 407 Proxy Authentication R │ │ut
+0.000489 │ <────────────────────────── │ │h:
19:38:44.600881 │ ACK │ │50
│ ──────────────────────────> │ │60
│ │ │ S
The real question is why the negative ACK for the first transaction doesn't seem to be
having the intended effect in this scenario.
-- Alex
On Dec 15, 2022, at 2:21 PM, Alex Balashov
<abalashov@evaristesys.com<mailto:abalashov@evaristesys.com>> wrote:
Adding further to this, it seems to me the real problem is that I can't use
t_release() in an async resume route, because it's internally structured to take place
inside a failure_route context. If I could, I think that would rid me of the first
transaction after I send the challenge and call 'exit'.
On Dec 15, 2022, at 12:42 PM, Alex Balashov
<abalashov@evaristesys.com<mailto:abalashov@evaristesys.com>> wrote:
As a test, I tried to put the auth_challenge() in the request_route before any async
suspension, and in that case works fine.
The issue is definitely with the way auth_challenge() issued from _within_ an async resume
route (failure_route context) bears upon transaction state.
-- Alex
On Dec 15, 2022, at 12:23 PM, Alex Balashov
<abalashov@evaristesys.com<mailto:abalashov@evaristesys.com>> wrote:
Well, the difference seems pretty clear. In a scenario with an auth challenge and no
subsequent INVITE+credentials, the negative ACK is matched:
4(54) DEBUG: <core> [core/receive.c:389]: receive_msg(): --- received sip message -
request - call-id: [01eed151-4234-4518-9a0e-9b9168f21a3f] - cseq: [288439 ACK]
4(54) DEBUG: <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route
core:pre-routing not defined
4(54) DEBUG: <core> [core/receive.c:471]: receive_msg(): preparing to run routing
scripts...
4(54) DEBUG: sl [sl_funcs.c:447]: sl_filter_ACK(): too late to be a local ACK!
4(54) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name():
parsed header name [Content-Length] type 12
4(54) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
4(54) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of
header
4(54) DEBUG: maxfwd [mf_funcs.c:55]: is_maxfwd_present(): max_forwards header not found!
4(54) DEBUG: siputils [checks.c:123]: has_totag(): totag found
4(54) DEBUG: rr [loose.c:108]: find_first_route(): No Route headers found
4(54) DEBUG: rr [loose.c:1006]: loose_route_mode(): There is no Route HF
4(54) DEBUG: tm [t_lookup.c:1053]: t_check_msg(): msg (0xffffa72f7088) id=14/54 global
id=13/54 T start=0
4(54) DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=42311,
isACK=1
4(54) DEBUG: tm [t_lookup.c:439]: matching_3261(): RFC3261 transaction matched,
tid=SG.ceb57d44-7388-4739-9a86-d44ea04d974d
4(54) DEBUG: tm [t_lookup.c:692]: t_lookup_request(): transaction found
(T=0xffffa2f428a8)
4(54) DEBUG: tm [t_lookup.c:1122]: t_check_msg(): msg (0xffffa72f7088) id=14/54 global
id=14/54 T end=0xffffa2f428a8
4(54) DEBUG: tm [t_reply.c:1763]: cleanup_uac_timers(): RETR/FR timers reset
4(54) DEBUG: tm [t_funcs.c:120]: put_on_wait(): put T [0xffffa2f428a8] on wait
4(54) DEBUG: <core> [core/timer.c:557]: timer_add_safe(): timer_add called on an
active timer 0xffffa2f42930 (0xffffa2d05d08, 0xffffa2d05d08), flags 201
4(54) DEBUG: tm [t_funcs.c:143]: put_on_wait(): transaction 0xffffa2f428a8 already on
wait
However, in a scenario with an auth challenge with subsequent INVITE+credentials, the same
negative ACK is not matched to a known transaction.
2(52) DEBUG: <core> [core/receive.c:389]: receive_msg(): --- received sip message -
request - call-id: [895a7051-3e0c-410a-88ea-4bad7a1c21b6] - cseq: [939189 ACK]
2(52) DEBUG: <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route
core:pre-routing not defined
2(52) DEBUG: <core> [core/receive.c:471]: receive_msg(): preparing to run routing
scripts...
2(52) DEBUG: sl [sl_funcs.c:447]: sl_filter_ACK(): too late to be a local ACK!
2(52) DEBUG: <core> [core/parser/parse_hname2.c:301]: parse_sip_header_name():
parsed header name [Content-Length] type 12
2(52) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field():
content_length=0
2(52) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of
header
2(52) DEBUG: maxfwd [mf_funcs.c:55]: is_maxfwd_present(): max_forwards header not found!
2(52) DEBUG: siputils [checks.c:123]: has_totag(): totag found
2(52) DEBUG: rr [loose.c:108]: find_first_route(): No Route headers found
2(52) DEBUG: rr [loose.c:1006]: loose_route_mode(): There is no Route HF
2(52) DEBUG: tm [t_lookup.c:1053]: t_check_msg(): msg (0xffffa72f7088) id=19/52 global
id=18/52 T start=0
2(52) DEBUG: tm [t_lookup.c:497]: t_lookup_request(): start searching: hash=21251,
isACK=1
2(52) DEBUG: tm [t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed -
via branch [z9hG4bKSG.c52861b7-2535-4080-84f5-2819c4169843]
2(52) DEBUG: tm [t_lookup.c:675]: t_lookup_request(): no transaction found
This makes sense intuitively; the auth_challenge(), and resulting 407 challenge, should
have ended the old transaction, so the negative ACK should just be absorbed.
But in that case, why does the 407 keep being retransmitted?
-- Alex
On Dec 15, 2022, at 12:00 PM, Alex Balashov
<abalashov@evaristesys.com<mailto:abalashov@evaristesys.com>> wrote:
Hi Henning,
On Dec 15, 2022, at 11:51 AM, Henning Westerholt
<hw@gilawa.com<mailto:hw@gilawa.com>> wrote:
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)
}
Yeah, that's more or less what I've got, except the first part.
I don't auth_challenge() every request because some requests are allowed by static IP,
and I don't know whether to auth_challenge() them unless I am already in the async
resume context.
I have eliminated the independent credentials query. At this point my process is more:
request_route {
...
http_async_query(API, RESUME)
}
route[RESUME] {
if(method == "INVITE") {
if(has_auth_attrib()) {
if(!pv_auth_check(...)) {
auth_challenge("realm", "1");
exit;
}
}
# Get more routing info.
http_async_query(API, RESUME2)
return;
}
}
route[RESUME2} {
t_relay() etc
}
-- 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/
--
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/
--
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/
1:10 p.m.
On Dec 16, 2022, at 3:40 AM, Henning Westerholt
<hw(a)gilawa.com> wrote:
Does this also happens e.g. if you just create a reply with send_reply/t_reply, and not
with the auth_challenge()?
Yes, I did think to try that, and the problem still happens.
Sorry, I just didn't want to add more spam to the thread. :-)
-- 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/
1:38 p.m.
One other data point I can add is that the problem is independent of any particular
module's way of suspending the transaction, though of course in hindsight this is
obvious.
That is to say, just a manual t_suspend() will trigger the issue, no need to use
`http_async_client` or any other module offering async operation ...
--
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/
2:36 p.m.
Hi Alex,
Thanks. As said, maybe it makes sense to create an issue about to document it e.g., in the
tm docs.
Cheers,
Henning
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com
-----Original Message-----
From: Alex Balashov <abalashov(a)evaristesys.com>
Sent: Friday, December 16, 2022 11:38 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: [SR-Users] Re: auth_challenge() and async
One other data point I can add is that the problem is independent of any particular
module's way of suspending the transaction, though of course in hindsight this is
obvious.
That is to say, just a manual t_suspend() will trigger the issue, no need to use
`http_async_client` or any other module offering async operation ...
--
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-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
5:09 p.m.
But what exactly shall we document?
"Don't suspend a transaction and do an auth challenge + exit from the resume
route unless you want the first transaction to be drawn out of wait state by a rapid
subsequent INVITE, despite prior receipt of a negative ACK for the challenge?" :-)
-- Alex
On Dec 16, 2022, at 6:36 AM, Henning Westerholt
<hw(a)gilawa.com> wrote:
Hi Alex,
Thanks. As said, maybe it makes sense to create an issue about to document it e.g., in
the tm docs.
Cheers,
Henning
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com
-----Original Message-----
From: Alex Balashov <abalashov(a)evaristesys.com>
Sent: Friday, December 16, 2022 11:38 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: [SR-Users] Re: auth_challenge() and async
One other data point I can add is that the problem is independent of any particular
module's way of suspending the transaction, though of course in hindsight this is
obvious.
That is to say, just a manual t_suspend() will trigger the issue, no need to use
`http_async_client` or any other module offering async operation ...
--
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-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
--
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/
20 Dec
20 Dec
1:17 a.m.
Just to conclude this, I have worked around it by setting tm.wt_timer to about ~300 ms,
which is low enough to shuffle the old transaction off before the retransmissions ad
nauseum can start.
But I don't think this is the ideal solution to this problem.
-- Alex
On Dec 16, 2022, at 9:09 AM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
But what exactly shall we document?
"Don't suspend a transaction and do an auth challenge + exit from the resume
route unless you want the first transaction to be drawn out of wait state by a rapid
subsequent INVITE, despite prior receipt of a negative ACK for the challenge?" :-)
-- 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/
On Dec 16, 2022, at 6:36 AM, Henning Westerholt
<hw(a)gilawa.com> wrote:
Hi Alex,
Thanks. As said, maybe it makes sense to create an issue about to document it e.g., in
the tm docs.
Cheers,
Henning
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://gilawa.com
-----Original Message-----
From: Alex Balashov <abalashov(a)evaristesys.com>
Sent: Friday, December 16, 2022 11:38 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: [SR-Users] Re: auth_challenge() and async
One other data point I can add is that the problem is independent of any particular
module's way of suspending the transaction, though of course in hindsight this is
obvious.
That is to say, just a manual t_suspend() will trigger the issue, no need to use
`http_async_client` or any other module offering async operation ...
--
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-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
--
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/
704
days inactive
711
days old
17 comments
3 participants
participants (3)
-
Alex Balashov -
Daniel-Constantin Mierla -
Henning Westerholt