sr-users May 2023

sr-users@lists.kamailio.org

40 participants
49 discussions

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

DNS resolution with ipops
by harneet singh 22 May '23

22 May '23

Hi Experts, I am planning to use *dns_query*() API from the ipops module, which I understand from some documentation that it internally uses *getaddrinfo*(). I wanted to check if someone can comment on the DNS Cache mechanism in this case. * Does Kamailio retain any *dns cache* while using this API, or would it be actually doing the resolution for each call. * In light of the above, does Kamailio honour the *TTL value i*n response to the DNS Query? Regards, Harneet Singh -- "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle

2 1

MySQL duplicate entry error on location after 5.5 => 5.6 upgrade
by Benoit Panizzon 22 May '23

22 May '23

Hi list Since updating 5.5 to 5.6 i often see this message in the logs: ERROR: db_mysql [km_dbase.c:122]: db_mysql_submit_query(): driver error on query: Duplicate entry 'uloc-645ca178-f29e-1' for key 'location.ruid_idx' (1062) ERROR: <core> [db_query.c:244]: db_do_insert_cmd(): error while submitting query ERROR: usrloc [ucontact.c:687]: db_insert_ucontact(): inserting contact in db failed ****** (uloc-645ca178-f29e-1) ERROR: usrloc [urecord.c:420]: wb_timer(): inserting contact into database failed (aor: *******) usrloc is dmq synced between two nodes. Were there some changes which could have caused this issue? 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 ______________________________________________________

1 0

Kamailio v5.7.0 Released - new major version is out
by Daniel-Constantin Mierla 21 May '23

21 May '23

Kamailio v5.7.0 is out – it comes with 4 new modules and a large set of improvements touching again more than 60 existing modules. You can read a bit more detailed release notes at: * https://www.kamailio.org/w/kamailio-v5-7-0-release-notes/ Many thanks to all developers and community members that made possible this release. v5.7.0 brings more flexibility and optimizations across many components, new variables and transformations, expression-based preprocessor values and conditions, alternative TLS module using WolfSSL project, improvements to STIR/SHAKEN, IMS/VoLTE, more functions exported to KEMI interface, including a new KEMI Python3 interpreter. ... just to list only a few here. Enjoy Kamailio v5.7.0! Thank you for flying Kamailio! Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com

2 1

db_redis and ursloc - problem after restarting kamailio
by Koldo Aingeru 18 May '23

18 May '23

Hi, I've encountered a problem using db_redis for location, we recently migrated to redis from mysql and just found out this yesterday. We are using the usrloc module with db_mode = 2, so the location info is written to redis every 60 seconds. When restarting, Kamailio reads all the contacts and loads them into memory, but for some contacts it loads the “methods” key with an incorrect value. If in the REGISTER there are no methods kamailio saves it with methods= -1: { "jsonrpc": "2.0", "result": { "AoR": “zzzzzzz", "Contacts": [{ "Contact": { "Address": "sip:1540305477794@W.X.Y.Z:5060", "Expires": 2752, "Q": -1, "Call-ID": "7d3965a85bfd0e88-32357(a)W.X.Y.Z", "CSeq": 11, "User-Agent": “xxxxxxx", "Received": "sip:W.X.Y.Z:5060", "Path": "<sip:A.B.C.D;lr;received=sip:W.X.Y.Z:5060>", "State": "CS_SYNC", "Flags": 0, "CFlags": 64, "Socket": “udp:A.B.C.D:5060", "Methods": -1, "Ruid": "uloc-644a176b-6472-4641", "Instance": "[not set]", "Reg-Id": 0, "Server-Id": 0, "Tcpconn-Id": -1, "Keepalive": 1, "Last-Keepalive": 1684246829, "Last-Modified": 1684246829 } }] }, "id": 19286 } But when restarting kamailio, the same contacts has a methods= 0 { "jsonrpc": "2.0", "result": { "AoR": “zzzzzzz", "Contacts": [{ "Contact": { "Address": "sip:1540305477794@W.X.Y.Z:5060", "Expires": 2697, "Q": -1, "Call-ID": "7d3965a85bfd0e88-32357(a)W.X.Y.Z", "CSeq": 11, "User-Agent": “xxxxxxx", "Received": "sip:W.X.Y.Z:5060", "Path": "<sip:A.B.C.D;lr;received=sip:W.X.Y.Z:5060>", "State": "CS_SYNC", "Flags": 0, "CFlags": 64, "Socket": “udp:A.B.C.D:5060", "Methods”: 0, "Ruid": "uloc-644a176b-6472-4641", "Instance": "[not set]", "Reg-Id": 0, "Server-Id": 0, "Tcpconn-Id": -1, "Keepalive": 1, "Last-Keepalive": 1684246829, "Last-Modified": 1684246829 } }] }, "id": 19286 } In the schema file for redis the key is correctly set as int and in redis I can see it saved as -1. So when a call comes in, the lookup() function returns a -2 as it doesn’t support the INVITE method and the call fails. This is happening in kamailio 5.2.8 and kamailio 5.2.1 (old versions, I know, we are working on updating it); with mysql as a backend it works perfectly after a restart. We do have the param method_filtering=1 , changing to 0 makes it works. We seem to have this since forever and for what I can see, is not unusual as is in the default kamailio.cfg provided (even the default value for it is 0). Has anyone else encountered this? Thanks! ======================================== Koldo Aingeru Marcos Fdez. Ingeniería de Sistemas Sarenet S.A.U. 944209470 Parque Tecnológico, Edificio 103 48170 Zamudio, Bizkaia www.sarenet.es ========================================

2 2

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