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 <abalas...@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 <abalas...@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 <abalas...@evaristesys.com> 
>>> wrote:
>>> 
>>> Hi Henning,
>>> 
>>>> On Dec 15, 2022, at 11:51 AM, Henning Westerholt <h...@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/

__________________________________________________________
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:

Reply via email to