sr-users May 2023

sr-users@lists.kamailio.org

40 participants
53 discussions

Is Min-SE check broken?
by harneet singh 31 May '23

31 May '23

Hi All, I am facing an issue in understanding how the min_se should be working in kamailio. As per the SST documentation, it seems like if the min_se is configured as 500, then any value of Session-Expires OR MIN-SE if lower than 500, can be responded to by a 422. However, I strangely see the reverse happening. To investigate further, I looked in to the ki_sst_check_min() code in the master, and these seems like a potential issue. Ref Code: Inside ki_sst_check_min(), there is an if condition like below: if (sst_min_se < MIN(minse, se.interval)) { However, shouldn't it be the other way around? ie if (sst_min_se > MIN(minse, se.interval)) { because we need to send 422 if the received value(in INVITE etc) is smaller than the sst configure min_se value? I also found a different documentation, at https://git.sgu.ru/oldssu/ex-opensips/blob/cb9df8d59dbb254a9d862569fd5d11f6… where the check is as below? if (sst_min_se > MIN(minse, se.interval)) { Can someone confirm if this is broken, or my understanding is incorrect? Regards, Harneet -- "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle

2 3

http_client using JWT?
by Benoît Panizzon 31 May '23

31 May '23

Hi The http_client module support the somehow old fashioned way to submit credentials as part of the URL. Our 'held' server developer would love to use either JWT or a Bearer Token in the Auth-Header or a 'cookie-jar' to authenticate the requests. Is this somehow possible? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

3 2

Knowing about the uac module with primary and secondary proxy setting
by MUSLIH K 31 May '23

31 May '23

Hi, *sip_provider_proxy1[* uac module-register] ---> *kamailio* [dispatcher Module] ----> *Asterisk1* ----> *Asterisk 2* in my configuration kamailio register to the sip provider using *uac module*, sip information are stored in database (uacreg). when a incoming call(INVITE) come to kamailio it will dispatch call to Asterisk using* "dispatcher module".* Here i have couple of questions 1. If my SIP provider has a secondary proxy as a failover server (sip_provider_proxy2), can I configure Kamailio with the uac module to use the secondary proxy if the primary proxy fails? 2. Since my application is inbound-only, registration failure is only identified when the registration expires (3600 seconds = 1 hour). Can I use the dispatcher module to select the SIP proxy and switch the registration to the secondary proxy if the primary proxy is not reachable (using OPTIONS)?

2 2

DISABLE SDP MEDIA STREAMS
by Patrick Karton 29 May '23

29 May '23

Hello kamailio community, i know its an unusual query but i would like to know if there is a cleaner/proper.right way to disable some (or all) media streams in SDP. i have come with a solution by sdpops module with subst_body function like this. route[SDP_DISABLE_UNAUTHORIZED_MEDIA]{ # disable text,media and video media streams subst_body('#^m=(video|text|audio)[ ]+[0-9/]+(.*)$#m=\1 0 \2#ig'); # update originator ip address subst_body('#^o=([^ ]+)[ ]+([^ ]+)[ ]+([^ ]+)[ ]+([^ ]+)[ ]+([^ ]+)[ ]+([^ ]+)$#o=\1 \2 \3 \4 \5 7.7.7.7#ig'); # 1 2 2 4 5 6 # name sid snumber network net-type addr # update connection ip address subst_body('#^c=([^ ]+)[ ]+([^ ]+)[ ]+([^ ]+)$#c=\1 \2 7.7.7.7#ig'); # 1 2 3 # network net-type addr #remove all media attributes sdp_remove_line_by_prefix("a=fmtp"); sdp_remove_line_by_prefix("a=X-"); sdp_remove_line_by_prefix("a=rtcp"); sdp_remove_line_by_prefix("a=ssrc"); sdp_remove_line_by_prefix("a=sendrecv"); sdp_remove_line_by_prefix("a=sendonly"); sdp_remove_line_by_prefix("a=recvonly"); sdp_remove_line_by_prefix("a=inactive"); sdp_remove_line_by_prefix("b="); } is it the right way to do it. if not can someone provide me an alternative solution. Thanks :)

3 2

Re: [sr-dev] Troubles with outbound kamailio call to other server
by Henning Westerholt 26 May '23

26 May '23

Hello (added sr-users, as its probably more a usage question). The SIP message (the BYE) cannot be parsed apparently. From the log it looks that there is an invalid character in the first line. Do a network trace to analyse the packets that its actually send and try to get some more clues from that. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com > -----Original Message----- > From: aaron.soto(a)dialapplet.com <aaron.soto(a)dialapplet.com> > Sent: Freitag, 26. Mai 2023 10:44 > To: sr-dev(a)lists.kamailio.org > Subject: [sr-dev] Troubles with outbound kamailio call to other server > > Hi everyone, > I'm having the following errors in kamailio when i try to make an outbound call to > other server, I don't know what does it mean, if some one can help me > > 11(25) ERROR: <core> [core/receive.c:310]: receive_msg(): core parsing of SIP > message failed (XX.XX.XX.XX.5060/1) > 13(27) ERROR: <core> [core/parser/parse_fline.c:271]: parse_first_line(): > parse_first_line: bad message (offset: 65) > 13(27) ERROR: <core> [core/parser/msg_parser.c:681]: parse_msg(): ERROR: > parse_msg: message=<BY > sip:asterisk@10.0.5.158:4080;alias=10.0.5.158~44730~1 SIP/2.0 > Via: SIP/2.0/UDP 84.127.226.15:5060;branch=z9hG4bK3bc90b47;rport > Route: <sip:34.252.151.179:4060;r2=on;lr;ftag=5c7f862f-9692-4028-8af0- > ebc224ba0e2a;vsf=AAAAAAAAAAAAAAAAAAAJCQABGgUAAAMJLjE4ODo1MDYw; > nat=yes>,<sip:10.0.5.40:4070;r2=on;lr;ftag=5c7f862f-9692-4028-8af0- > ebc224ba0e2a;vsf=AAAAAAAAAAAAAAAAAAAJCQABGgUAAAMJLjE4ODo1MDYw; > nat=yes> > Max-Forwards: 70 > From: <sip:692598435@kamailio.voip.svc.cluster.local>;tag=as6f32aa26 > To: <sip:963441038@192.168.123.66:4060>;tag=5c7f862f-9692-4028-8af0- > ebc224ba0e2a > Call-ID: b9a49c52-7829-4cdf-a88c-0064cc5bb438 > CSeq: 102 BYE > User-Agent: Asterisk PBX 11.2-cert3 > X-Asterisk-HangupCause: No user responding > X-Asterisk-HangupCauseCode: 18 > Content-Length: 0 > > > > _______________________________________________ > Kamailio (SER) - Development Mailing List To unsubscribe send an email to sr-dev- > leave(a)lists.kamailio.org

1 0

Consistent huntable responses based on failure_route question
by John Hardiman 25 May '23

25 May '23

Hi Kamailio list, I hope you are all well? I am looking for some assistance on a specific error I am trying to work around. Kamailio 5.5.3 - Ubuntu 20.04 Kemi Python script (but I think this is more default failure_route behaviour) Dispatcher module which hunts to a group of FreeSWITCH that I have configured to send 503 responses on. My scenario is fairly simple, I am trying to respond back to a carrier for huntable responses (503 specifically) by calling a failure route below: def ksr_failure_manage(self, msg): if KSR.tm.t_any_timeout()>0 : self.ksr_send_reply_clear_rtpengine(msg, 503, "Timeout to destination") KSR.err("Timeout to Invite for %s from IP %s" % (KSR.pv.get("$ci"),KSR.pv.get("$si"))) return 1 else: self.ksr_send_reply_clear_rtpengine(msg, 503, "Unknown error failover to next node") KSR.err("Failed but not timeout for %s from IP %s" % (KSR.pv.get("$ci"),KSR.pv.get("$si"))) return 1 This works and a 503 with the correct message is sent if the invite doesn't get a response after 2 seconds. (My specific test case here) # Timers for call setup 2 minutes for any 1xx provisional response received # If no invite response received in 2 seconds end the call as per failure route. KSR.tm.t_set_fr(120000, 2000) self.ksr_route_relay(msg) KSR.tm.t_on_failure("ksr_failure_manage") return -255 The issue is after a few more milliseconds after my initial 503 a 408 is sent. Also after the failover if the carrier tries the same Kamailio again it gets a 500 rather than a 408. 408: [cid:image001.png@01D98F15.CD07DCB0] 500: [cid:image002.png@01D98F15.CD07DCB0] My steps to get around this have been to change the default tm code to 503 below, but this has not changed the default response and the above behaviour unfortunately: # ----- tm params ----- # auto-discard branches from previous serial forking leg modparam("tm", "failure_reply_mode", 3) # setting default reason code and response for general errors to allow failover. modparam("tm", "default_code", 503) modparam("tm", "default_reason", "Unknown reason try next node") My question is: How can I make sure my failure route is the final response here. Or if I cannot make sure of this, how can I change the default mapped response to be a consistent SIP response (503 specifically) Many thanks in advance as I am scratching my head on this one a bit. John.

2 2

Override listen advertise address
by Calvin E. 25 May '23

25 May '23

Using 5.6.x, a scenario designed for a public IP now needs to support life in the cloud behind NAT. I'd like to avoid having two listeners to separate on-net from off-net traffic. In a HA scenario, it would be nice to have only one floating IP. Is it possible to use the same local address and port for external/public and internal/private traffic? Should set_advertised_address() override the listen advertise address? Initial testing did not produce the expected result. I want to make sure I'm following a sane pattern before going down a rabbit hole. The idea is to toggle the advertised address by checking if the sender or recipient is rfc1918(). For the dispatcher module, is it possible to use socket names like below? In testing it appeared that only one of the two names was valid. listen=udp:10.0.0.10:5060 name "onnet" listen=udp:10.0.0.10:5060 advertise 11.11.11.11:5060 name "offnet"

3 4

lost module: best practice handling delay caused by held / lis procedure?
by Benoit Panizzon 25 May '23

25 May '23

Hi gang In 2024, Switzerland will start using NG112 (NG911) procedures to transmit the caller location via Geolocation URL via LIS Server to a PSAP. So time to start testing this on my devel plattform. Kamailio ships with the lost module which looks promising. In short, the Procedure is as follows: Customer calls emergency number. Kamailio performs a http request to our inhouse HELD server with the identification of the calling customer. HELD server looks up the location of the caller and pushes a HELD XML object to the Swiss LIS Server, which then is queried by the emergency PSAP receiving the call. LIS server return and URL. HELD server returns the URL to Kamailio. Kamailio adds Geolocation Header with that URL and relays the call. This takes some time and as the call is not yet being relayed while waiting for the held request to complete, there is no 100 trying being sent and the emergency call is bound to time out. So, shall I call t_reply("100","Performing HELD lkup") before calling the lost module? Or is there a better way? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

3 7

cancel at first call after startup kamailio not relay
by Giuseppe Pandolfi 23 May '23

23 May '23

Hi, I have a problem with kamailio v 5.6.1 on mips architecture: version: kamailio 5.6.1 (mips/linux) flags: USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX-NOSMP, USE_PTHREAD_MUTEX, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 14:22:18 Apr 27 2023 Using default script for make a call from sip ua to PSTN system (#!define WITH_PSTN), the cancel sent for the first call after start kamailio doesn't relay to PSTN system and I have the trace error beelow: 2(3203) BUG: {1 27018 CANCEL 0tBgb95Z.0eE5VVrAkoP06nvunIknKNz} tm [t_cancel.c:318]: cancel_branch(): local_cancel buffer=(nil) != BUSY_BUFFER (trying to continue) 12(3203) ERROR: {1 27018 CANCEL 0tBgb95Z.0eE5VVrAkoP06nvunIknKNz} tm [t_fwd.c:1434]: e2e_cancel(): cancel error the next calls works fine. Does anyone have any suggestions? Beelow trace at debug level: 37(3695) INFO: <core> [core/cfg/cfg_ctx.c:602]: cfg_set_now(): core.debug has been changed to 3 37(3695) DEBUG: ctl [io_listener.c:518]: handle_stream_read(): bytes processed: 23 12(3670) DEBUG: <core> [core/parser/parse_fline.c:250]: parse_first_line(): first line type 1 (request) flags 1 12(3670) DEBUG: <core> [core/parser/msg_parser.c:677]: parse_msg(): SIP Request: 12(3670) DEBUG: <core> [core/parser/msg_parser.c:679]: parse_msg(): method: <CANCEL> 12(3670) DEBUG: <core> [core/parser/msg_parser.c:681]: parse_msg(): uri: <sip:100@192.168.2.238:5060> 12(3670) DEBUG: <core> [core/parser/msg_parser.c:683]: parse_msg(): version: <SIP/2.0> 12(3670) DEBUG: <core> [core/parser/parse_hname2.c:302]: parse_sip_header_name(): parsed header name [Via] type 1 12(3670) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 235, <rport> = <n/a>; state=6 12(3670) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKPjLBcUXshEKW2s9T0en9czTYAsciW1vV-W>; state=16 12(3670) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 12(3670) DEBUG: <core> [core/parser/msg_parser.c:555]: parse_headers(): Via found, flags=2 12(3670) DEBUG: <core> [core/parser/msg_parser.c:557]: parse_headers(): this is the first via 12(3670) DEBUG: <core> [core/parser/parse_hname2.c:302]: parse_sip_header_name(): parsed header name [Max-Forwards] type 8 12(3670) DEBUG: <core> [core/parser/parse_hname2.c:302]: parse_sip_header_name(): parsed header name [From] type 4 12(3670) DEBUG: <core> [core/parser/parse_hname2.c:302]: parse_sip_header_name(): parsed header name [To] type 3 12(3670) DEBUG: <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=9 12(3670) DEBUG: <core> [core/parser/msg_parser.c:173]: get_hdr_field(): <To> [23]; uri=[sip:100@192.168.2.238] 12(3670) DEBUG: <core> [core/parser/msg_parser.c:176]: get_hdr_field(): to body (23)[sip:100@192.168.2.238 ], to tag (0)[] 12(3670) DEBUG: <core> [core/parser/parse_hname2.c:302]: parse_sip_header_name(): parsed header name [Call-ID] type 6 12(3670) DEBUG: <core> [core/parser/parse_hname2.c:302]: parse_sip_header_name(): parsed header name [CSeq] type 5 12(3670) DEBUG: <core> [core/parser/msg_parser.c:154]: get_hdr_field(): cseq <CSeq>: <17038> <CANCEL> 12(3670) DEBUG: <core> [core/receive.c:394]: receive_msg(): --- received sip message - request - call-id: [CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU] - cseq: [17038 CANCEL] 12(3670) DEBUG: <core> [core/parser/parse_hname2.c:302]: parse_sip_header_name(): parsed header name [User-Agent] type 28 12(3670) DEBUG: <core> [core/parser/parse_hname2.c:302]: parse_sip_header_name(): parsed header name [Content-Length] type 12 12(3670) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field(): content_length=0 12(3670) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of header 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/receive.c:261]: ksr_evrt_pre_routing(): event route core:pre-routing not defined 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/receive.c:471]: receive_msg(): preparing to run routing scripts... 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} maxfwd [mf_funcs.c:74]: is_maxfwd_present(): value = 70 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:247]: check_ruri_sip_version(): check_ruri_sip_version entered 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:270]: check_ruri_sip_version(): check_ruri_sip_version passed 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:297]: check_ruri_scheme(): check_ruri_scheme passed 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:318]: check_required_headers(): check_required_headers entered 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:340]: check_required_headers(): check_required_headers passed 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:348]: check_via1_header(): check via1 header 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:506]: check_cseq_method(): check_cseq_method entered 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:539]: check_cseq_method(): check_cseq_method passed 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:548]: check_cseq_value(): check_cseq_value entered 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:576]: check_cseq_value(): check_cseq_value passed 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:585]: check_cl(): check_cl entered 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:610]: check_cl(): check_cl passed 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:622]: check_expires_value(): check_expires_value entered 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:659]: check_expires_value(): no expires header found 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:758]: check_parse_uris(): check_parse_uris entered 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:762]: check_parse_uris(): parsing ruri 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:776]: check_parse_uris(): looking up From header 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=Jjj1QBeRxydZ5rq.-xKCfcJZhlPANj9N 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/parser/parse_addr_spec.c:884]: parse_addr_spec(): end of header reached, state=29 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:791]: check_parse_uris(): looking up To header 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity.c:837]: check_parse_uris(): check_parse_uris passed 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} sanity [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 1 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:727]: t_lookupOriginalT(): searching on hash entry 10182 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:440]: matching_3261(): RFC3261 transaction matched, tid=PjLBcUXshEKW2s9T0en9czTYAsciW1vV-W 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:823]: t_lookupOriginalT(): canceled transaction found (0x729bff78)! 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:826]: t_lookupOriginalT(): found - lookup completed 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [tm.c:1232]: ki_t_lookup_cancel_flags(): lookup_original: t_lookupOriginalT returned: 0x729bff78 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:1348]: t_newtran(): msg (0x771181ec) id=1/3670 global id=0/0 T start=0xffffffff 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:498]: t_lookup_request(): start searching: hash=10182, isACK=0 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:456]: matching_3261(): RFC3261 transaction matching failed - via branch [z9hG4bKPjLBcUXshEKW2s9T0en9czTYAsciW1vV-W] 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:675]: t_lookup_request(): no transaction found 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/crypto/md5utils.c:67]: MD5StringArray(): MD5 calculated: dd71ad9d7511b02a5fc83c3c70ce307f 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:727]: t_lookupOriginalT(): searching on hash entry 10182 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:432]: matching_3261(): matched skip method - s:0x2 t:0x2 m:0x2 - continue searching 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:440]: matching_3261(): RFC3261 transaction matched, tid=PjLBcUXshEKW2s9T0en9czTYAsciW1vV-W 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:823]: t_lookupOriginalT(): canceled transaction found (0x729bff78)! 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_lookup.c:826]: t_lookupOriginalT(): found - lookup completed 12(3670) BUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_cancel.c:318]: cancel_branch(): local_cancel buffer=(nil) != BUSY_BUFFER (trying to continue) 12(3670) ERROR: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_fwd.c:1434]: e2e_cancel(): cancel error 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_reply.c:1763]: cleanup_uac_timers(): RETR/FR timers reset 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_reply.c:638]: _reply_light(): reply sent out - buf=0x77101e68: SIP/2.0 500 cancel e... shmem=0x729c5b60: SIP/2.0 500 cancel e 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_funcs.c:120]: put_on_wait(): put T [0x729c36d8] on wait 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_reply.c:648]: _reply_light(): finished 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} tm [t_funcs.c:373]: t_relay_to(): new transaction forwarded 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/receive.c:529]: receive_msg(): request-route executed in: 9868 usec 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/usr_avp.c:637]: destroy_avp_list(): destroying list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/xavp.c:541]: xavp_destroy_list(): destroying xavp list (nil) 12(3670) DEBUG: {1 17038 CANCEL CYxrNJtcCFZKS.PJN29LlEBd0aejPQUU} <core> [core/receive.c:628]: receive_msg(): cleaning up 34(3692) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x729c36d8 (p:0x72866768/n:0x729bff78) 34(3692) DEBUG: tm [h_table.c:132]: free_cell_helper(): freeing transaction 0x729c36d8 from timer.c:650

1 0

mk_proxy(): could not resolve hostname
by ajosebar＠gmail.com 23 May '23

23 May '23

I have Kamailio 5.6 on Debian 11. I need to use the function forward within a routing block in my configuration file: forward("udp:192.168.28.51:5060"); But when I start the kamailio service I got: CRITICAL: [core/proxy.c:264]: mk_proxy(): could not resolve hostname: "udp:192.168.28.51:5060" The same occurs when I use the dns nane : forward("udp:raspberry3.emtelco.co:5060"); Any ideas ? Regards

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users May 2023