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 <abalas...@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 <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/ > -- 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: