sr-users April 2022

sr-users@lists.kamailio.org

49 participants
62 discussions

Incorrect Socket and Tcpconn-Id with Mid-Registrar and WebSockets

by Grant Bagdasarian

Hi, We're attempting to implement a mid-registrar for websocket connections but are running into some issues where the tcpconn-id and socket attributes are not stored correctly in memory (usrloc). REGISTER Flow: UA1 -> P1 (Mid-Registrar) ~> P2 (Core Proxy/Registrar) INVITE Flow: UA2 -> P2 -> P1 -> UA1 UA1: baresip cli connecting to P1 using websockets UA2: softphone Everything is running locally on a dev machine, and we're using Docker to launch P1 and P2. The below code snippet is what we use on P1, and has been simplified. The general idea is as following: 1) UA1 sets up the websocket connection and sends a REGISTER request to P1 2) P1 checks if this request has already been sent to P2 2.a) If not, then relay the request to P2. Upon receiving a 200 OK from P2 we save the registration in usrloc 2.b) If so, then absorb the request (save) and generate a reply 3) UA2 tries to call UA1 via P1 and P2 The problem occurs at 2.a since the REGISTER request is forwarded using UDP and the 200 OK is also received using UDP. When the registration is stored in reply route, the Socket (udp:x.x.x.x:xxxx) and Tcpconn-Id (-1) are not set to what we would prefer (see Output 1) TCP was also tried as the transport between P1 and P2. Upon receiving the reply from P2 the Tcpconn-Id and Socket of the connection between P1 and P2 was saved in the binding. When 2.b occurs the Socket and Tcpconn-Id are set to the correct values (see Output 2) Making a call when the binding state is at 2.a we receive the following error: "TCP/TLS connection (id: 0) for WebSocket could not be found" Making a call when the binding state is at 2.b works perfectly fine since the correct Tcpconn-Id is set. We did find a solution, or rather a workaround to this issue: 1) Always call the save function in request_route 2) If P2 responds with an error (non-200 OK) use the unregister function to remove the binding We also tried the tcpops tcp_set_otcpid and tcp_set_otcpid_flag functions after lookup, but this didn't do anything. KEMI Script def ksr_request_route(self, msg): if kemi.is_REGISTER(): aor = "aor" if result := kemi.htable.sht_is_null("registrations", aor) == 1: kemi.tm.t_on_reply("ksr_register_reply_route") kemi.dispatcher.ds_select_dst(1, 4) kemi.tm.t_relay() return 1 kemi.registrar.save("registrations", 1) return 1 if kemi.is_INVITE(): aor = "aor" if result := kemi.registrar.lookup_uri("registrations", aor): kemi.tm.t_relay() return 1 def ksr_register_reply_route(self, msg): if kemi.tm.t_check_status("200") == 1: kemi.registrar.save("registrations", 1) aor = "aor" kemi.htable.sht_sets("registrations", aor, "") return 1 Output 1: Binding state when request is being forwarded kamcmd ul.dump { Domains: { Domain: { Domain: registrations Size: 1024 AoRs: { Info: { AoR: grant(a)127.0.0.1 HashID: 409622189 Contacts: { Contact: { Address: sip:grant-0x7fe915a79138@172.16.99.12:9;transport=ws Expires: 13 Q: 1.000000 Call-ID: 7cdfbf93f23bb54f CSeq: 34818 User-Agent: n/a Received: sip:192.168.80.1:62184;transport=ws Path: [not set] State: CS_NEW Flags: 1 CFlags: 20 Socket: udp:10.2.0.15:5060 Methods: -1 Ruid: uloc-626a80d3-46-1 Instance: <urn:uuid:c67df38d-d5e0-e834-1d98-a8df2d3f291b> Reg-Id: 0 Server-Id: 0 Tcpconn-Id: -1 Keepalive: 0 Last-Keepalive: 1651146965 KA-Roundtrip: 0 Last-Modified: 1651146965 } } } } Stats: { Records: 1 Max-Slots: 1 } } } } kamcmd core.tcp_list { id: 1 type: WS state: CONN_OK timeout: 2 lifetime: 120 ref_count: 2 src_ip: 192.168.80.1 src_port: 62184 dst_ip: 192.168.80.15 dst_port: 80 } kamcmd ws.dump { connections: { 1: ws:192.168.80.1:62184 -> ws:192.168.80.15:80 (state: OPEN, last used 3s ago, sub-protocol: sip) } info: { wscounter: 1 truncated: no } } Output 2: Binding state when request is being absorbed kamcmd ul.dump { Domains: { Domain: { Domain: registrations Size: 1024 AoRs: { Info: { AoR: grant(a)127.0.0.1 HashID: 409622189 Contacts: { Contact: { Address: sip:grant-0x7fe915a79138@172.16.99.12:9;transport=ws Expires: 9 Q: 1.000000 Call-ID: 7cdfbf93f23bb54f CSeq: 34819 User-Agent: baresip v2.0.2 (x86_64/darwin) Received: sip:192.168.80.1:62184;transport=ws Path: [not set] State: CS_NEW Flags: 1 CFlags: 20 Socket: tcp:192.168.80.15:80 Methods: 5087 Ruid: uloc-626a80d3-46-1 Instance: <urn:uuid:c67df38d-d5e0-e834-1d98-a8df2d3f291b> Reg-Id: 0 Server-Id: 0 Tcpconn-Id: 1 Keepalive: 0 Last-Keepalive: 1651146979 KA-Roundtrip: 0 Last-Modified: 1651146979 } } } } Stats: { Records: 1 Max-Slots: 1 } } } } kamcmd core.tcp_list { id: 1 type: WS state: CONN_OK timeout: 3 lifetime: 120 ref_count: 2 src_ip: 192.168.80.1 src_port: 62184 dst_ip: 192.168.80.15 dst_port: 80 } kamcmd ws.dump { connections: { 1: ws:192.168.80.1:62184 -> ws:192.168.80.15:80 (state: OPEN, last used 1s ago, sub-protocol: sip) } info: { wscounter: 1 truncated: no } }

1 year, 12 months

TOPOS, 183 (before a 200OK) and SIP INFO

by Giovanni Tommasini

Hi kamailiers, I ask your help for a strange situation with topos, 183 (before a 200OK) and SIP INFO My topology is kamailio in front of asterisks; so kamailio has 2 interfaces (1Public to talk with customers and carriers and 1 Private to talk with asterisk). In the image: - the first column is the customer - the second is the public interface of kamailio - the third is the private interface of kamaiio - the fourth is asterisk As you can see in the image, the customer send an INVITE and the carrier give back the IVR messages in a 183 (before a 200OK) asking for an IVR selection. The customer (configured to use SIP INFO) types a key and sends in INFO, but as you can see kamailio sends the INFO to himself to private interface instead of sending it to asterisk as if the contact that handled topos contained incorrect information. [image: Schermata 2022-04-26 alle 19.40.32.png] - If the customer is configured with a RFC2833 - or if the IVR messages is not in a 183 but is sent after a 200OK - or if I disabe TOPOS *all works fine* I used kamailio 5.5.3, I also try to upgrade to 5.5.4 but nothing change Maybe could be connected with https://github.com/kamailio/kamailio/issues/2344 https://github.com/kamailio/kamailio/issues/1077 Could be a kamailio bug for this particular situation or am I getting lost in a glass of water? thanks a lot cheers Giovanni Tommasini *evoseed s.r.l.* phone: +39 340 11 28 800 mail: giovanni.tommasini(a)evoseed.io site: evoseed.io address: Via Lucrezio 13, Trieste Italy

1 year, 12 months

Kamailio functionality clarification - call forwarding no replay (call is ringing but not answered)

by Pavel Veselovsky

Hallo all, I would need help with Kamailio. I hope, you can give me some hints. I would like use Kamailio for CFNRy feature call forward no replay, i.e. - call is forked to multiple destination - 180 is received, call is ringing, but not answered, no 200 OK is received from destinations - after predefined time (CFNRy timer), the specific branch has to be rerouted to another destination Expected behaviour is described in this flow: [image: image.png] My current behavior: - Kamailio TM module is involved for parallel forking ( https://www.kamailio.org/docs/modules/stable/modules/tm.html#:~:text=1.-,Ov… ) - all branches are CANCEL-ed, it is not possible send CANCEL just to one specific branch [image: image.png] My questions: - is it possible to CANCEL just specific branch of parallel forked calls? - is it possible start timer just for specific branch? - do you think is it possible implement this feature with Kamailio? Thanks a lot in advance for any comments. Pavel.

1 year, 12 months

t_check_trans failed on ACK

by Linux Vince

I am using Kamailio as registrar and proxy for underlying asterisk server. I am able to call but ACK on 200 OK respond from client phones are not validating transaction and thus not relaying correctly. Below are my Invites and 200 OK responses. Invite from Asterisk to Kamailio INVITE sip:31313004@rigel.com:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 65.20.69.72:5060 ;rport;branch=z9hG4bKd6ffff9d46ceb899c245ece204e51c87 From: "R31313005 N31313005" <sip:31313005@65.20.69.72:5060 ;user=phone>;tag=GR52RWG346-34 To: "31313004(a)rigel.com" <sip:31313004@rigel.com:5060> Call-ID: 1558172022-144148450000000029280449(a)65.20.69.72 CSeq: 1 INVITE Contact: <sip:65.20.69.72:5060> max-forwards: 70 Allow: PUBLISH, SUBSCRIBE, MESSAGE, ACK, NOTIFY, OPTIONS, REFER, INFO, BYE, CANCEL, INVITE Content-Type: application/sdp Content-Length: 228 v=0 o=Clarent 155866 155867 IN IP4 65.20.69.72 s=Clarent CallManager c=IN IP4 65.20.69.72 t=0 0 m=audio 45168 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 Invite from Kamailio to Phone INVITE sip:31313004@65.20.67.118;lhst=180.211.119.50:25759;lm=midreg SIP/2.0 Record-Route: <sip:65.20.67.118;lr;ftag=GR52RWG346-34> Via: SIP/2.0/UDP 65.20.67.118;branch=z9hG4bK6cc3.dad7580d3e28f55cbb749dbb82f0c9eb.0 Via: SIP/2.0/UDP 65.20.69.72:5060 ;received=65.20.69.72;rport=5060;branch=z9hG4bKd6ffff9d46ceb899c245ece204e51c87 From: "R31313005 N31313005" <sip:31313005@65.20.69.72:5060 ;user=phone>;tag=GR52RWG346-34 To: "31313004(a)rigel.com" <sip:31313004@rigel.com:5060> Call-ID: 1558172022-144148450000000029280449(a)65.20.69.72 CSeq: 1 INVITE Contact: <sip:65.20.69.72:5060> max-forwards: 69 Allow: PUBLISH, SUBSCRIBE, MESSAGE, ACK, NOTIFY, OPTIONS, REFER, INFO, BYE, CANCEL, INVITE Content-Type: application/sdp Content-Length: 228 v=0 o=Clarent 155866 155867 IN IP4 65.20.69.72 s=Clarent CallManager c=IN IP4 65.20.69.72 t=0 0 m=audio 45168 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 200 OK from Phone to Kamailio SIP/2.0 200 OK Via: SIP/2.0/UDP 65.20.67.118;received=65.20.67.118;branch=z9hG4bK6cc3.dad7580d3e28f55cbb749dbb82f0c9eb.0 Via: SIP/2.0/UDP 65.20.69.72:5060 ;rport=5060;received=65.20.69.72;branch=z9hG4bKd6ffff9d46ceb899c245ece204e51c87 Record-Route: <sip:65.20.67.118;lr;ftag=GR52RWG346-34> Call-ID: 1558172022-144148450000000029280449(a)65.20.69.72 From: "R31313005 N31313005" <sip:31313005@65.20.69.72 ;user=phone>;tag=GR52RWG346-34 To: "31313004(a)rigel.com" <sip:31313004@rigel.com >;tag=4ecc1f21f1544fd783965f27ff6d95d2 CSeq: 1 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Contact: <sip:31313004@180.211.119.50:57935;ob> Supported: replaces, 100rel, timer, norefersub Content-Type: application/sdp Content-Length: 322 v=0 o=- 3860150297 3860150298 IN IP4 180.211.119.50 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 4016 RTP/AVP 0 101 c=IN IP4 180.211.119.50 b=TIAS:64000 a=rtcp:4017 IN IP4 180.211.119.50 a=sendrecv a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ssrc:1461220511 cname:3b657c275d2a43f6 200 OK from kamailio to asterisk SIP/2.0 200 OK Via: SIP/2.0/UDP 65.20.69.72:5060 ;rport=5060;received=65.20.69.72;branch=z9hG4bKd6ffff9d46ceb899c245ece204e51c87 Record-Route: <sip:65.20.67.118;lr;ftag=GR52RWG346-34> Call-ID: 1558172022-144148450000000029280449(a)65.20.69.72 From: "R31313005 N31313005" <sip:31313005@65.20.69.72 ;user=phone>;tag=GR52RWG346-34 To: "31313004(a)rigel.com" <sip:31313004@rigel.com >;tag=4ecc1f21f1544fd783965f27ff6d95d2 CSeq: 1 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Contact: <sip:31313004@180.211.119.50:57935;ob> Supported: replaces, 100rel, timer, norefersub Content-Type: application/sdp Content-Length: 322 v=0 o=- 3860150297 3860150298 IN IP4 180.211.119.50 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 4016 RTP/AVP 0 101 c=IN IP4 180.211.119.50 b=TIAS:64000 a=rtcp:4017 IN IP4 180.211.119.50 a=sendrecv a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ssrc:1461220511 cname:3b657c275d2a43f6 ACK from phone to Kamailio ACK sip:31313004@180.211.119.50:57935;ob SIP/2.0 Via: SIP/2.0/UDP 65.20.69.72:5060 ;rport;branch=z9hG4bK111270de2729ade9e048afa0f9fbb8df Route: <sip:65.20.67.118;lr;ftag=GR52RWG346-34> From: "R31313005 N31313005" <sip:31313005@65.20.69.72:5060 ;user=phone>;tag=GR52RWG346-34 To: "31313004(a)rigel.com" <sip:31313004@rigel.com >;tag=4ecc1f21f1544fd783965f27ff6d95d2 Call-ID: 1558172022-144148450000000029280449(a)65.20.69.72 CSeq: 1 ACK Contact: <sip:65.20.69.72:5060> max-forwards: 70 Allow: PUBLISH, SUBSCRIBE, MESSAGE, ACK, NOTIFY, OPTIONS, REFER, INFO, BYE, CANCEL, INVITE This ACK is failing on transaction check and not routing correctly to phone. Any help? Thanks

1 year, 12 months

Modify session name in SDP

by ZZ Wave

Hello. Kamailio 5.2.1, Debian 10. I need to change session name (s=) in SDP before relaying it to next hop, and for unknown reason I can't do it with virtually any TEXTOPS function, everything replace*, subst*, *body*... For example this from TEXTOPS documentation: subst_body('/^s=(.*)/s=root/') just before 'final' t_relay(). Either Kamailio just adds "s=root" to SDP leaving first "s=" intact, or adds just "root", or does nothing. Also I've tried msg_apply_changes() before and after these manipulations, still no result. Is it possible to make this in Kamailio without source code modification?

1 year, 12 months

High performance

by Muborakshohi Masoud

Hello! I have kamailio 5.5 configured with digest authentication. DB Mysql, 2 rtpengine one on the same server with kamailio, the other is separate. Rtpengins work in bridge mode, internal/external/external-ipV6. Kamailio listen 3 address: internal/external/external-ipV6 work in mixed mode: ipV4-ipV4, ipV4-ipV6, ipV6-ipV6. OS Debian 10, CPU 1 core, Ram 4gb, Disk not ssd. internal address is used for the gateway model of the connection to the PSTN. Before sending a call to PSTN, a request is sent to Billing by Diameter (request over the network, ims_charging ), Billing responds in the region of 10-17 milliseconds. usrloc db_mode = 0; UAS contacts are received according to the PUSH scheme (we send PUSH via http and get a REGISTER). children = 8 for each; When running synthetic tests with sipp, I get 36 cps as a maximum, but there are a lot of retrans. This is a test environment. Product: I plan to get 100 cps; 20k concurrent calls, hardware will be 128GB RAM ddr4-2400; Intel Xeon Silver 4216, Optane SSD. 2 such servers, kamailio/rtpengine are configured exactly according to the scheme of the test environment. Question: Can you please tell me how many children, shm/pv do I need? Is it worth going in the direction of asynchrony, or is the standard one enough for my purpose? I will be very glad for any help. Thank you! -- Отправлено из Mail.ru для Android

1 year, 12 months

Intermittent error seen when using a python script in kamailio

by Wojciech Kopciewicz

Hi, Intermittently we are observing the following error when checking if given header is present in SIP INVITE: SystemError: returned a result with an error set The complete stack trace is (some names redacted): 11(28) ERROR: {1 195 INVITE nMHZDN.10nOIDt4ldOwz5cqz0XnMepA9} app_python3 [python_support.c:156]: python_handle_exception(): apy_exec: modify_headers((null)): Unhandled exception in the Python code: TypeError: an integer is required (got type NoneType) The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/etc/kamailio/kamailio.py", line 25, in modify_headers self.modify_header("SomeHeader") File "/etc/kamailio/kamailio.py", line 29, in modify_header present = KSR.hdr.is_present(header_name) SystemError: returned a result with an error set Kamailio version (kamailio -v output): version: kamailio 5.4.6 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, 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, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, 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 with gcc 8.3.0 Operation system: Linux kamailio-5c7484c74d-vhhr8 5.4.0-1056-azure #58~18.04.1-Ubuntu SMP Wed Jul 28 23:14:18 UTC 2021 x86_64 GNU/Linux Are you able to help me find the root cause of this issue? Pozdrawiam / Best regards, Wojtek -- *For more information on how and why we collect your personal information, please visit our Privacy Policy <https://www.motorolasolutions.com/en_us/about/privacy-policy.html?elqTrackI…>.*

1 year, 12 months

LCR issues (request_uri)

by Antoine DEBARRE

Hi, I'm trying to use LCR with kamailio v5.5.4 gw, rule and rule_target are stored on mysql. for lcr rules, do you know if prefix is mandatory ? I first wanted to start using request_uri instead and leave the prefix column null/empty because prefix seems not to support regexp, I don't want to add the same rule with different prefixes. but I'm facing issues my database is fulfilled with : lcr_gw +----+--------+--------------+---------------+----------+------+--------+------------+-----------+-------+--------+-------------+-------+---------+ | id | lcr_id | gw_name | ip_addr | hostname | port | params | uri_scheme | transport | strip | prefix | tag | flags | defunct | +----+--------+--------------+---------------+----------+------+--------+------------+-----------+-------+--------+-------------+-------+---------+ | 1 | 1 | carrier1 | 10.78.51.3 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | fd=carrier1 | 0 | NULL | | 2 | 1 | carrier2 | 10.78.51.3 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | fd=carrier2 | 0 | NULL | | 3 | 1 | carrier3 | 10.192.50.212 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | NULL | 0 | NULL | | 6 | 1 | carrier4 | 10.192.50.3 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | fd=carrier4 | 0 | NULL | | 10 | 1 | carrier5 | 10.192.50.3 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | fd=carrier5 | 0 | NULL | | 18 | 1 | carrier6 | 10.192.50.214 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | NULL | 0 | NULL | | 20 | 1 | carrier7 | 10.192.50.210 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | NULL | 0 | NULL | | 30 | 1 | carrier8 | 10.192.50.211 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | NULL | 0 | NULL | | 31 | 1 | carrier9 | 10.192.50.216 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | NULL | 0 | NULL | | 32 | 2 | media1 | 10.192.50.232 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | NULL | 0 | NULL | | 33 | 2 | media2 | 10.192.50.233 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | NULL | 0 | NULL | | 34 | 2 | media3 | 10.192.50.234 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | NULL | 0 | NULL | | 35 | 2 | media4 | 10.192.50.235 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | NULL | 0 | NULL | | 36 | 2 | media5 | 10.192.50.240 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | NULL | 0 | NULL | | 37 | 2 | media6 | 10.192.50.241 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | NULL | 0 | NULL | | 38 | 2 | media7 | 10.192.50.242 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | NULL | 0 | NULL | | 39 | 3 | xivo-231 | 10.192.50.231 | NULL | 5060 | NULL | NULL | 1 | NULL | NULL | cps=5;cc=50 | 0 | NULL | +----+--------+--------------+---------------+----------+------+--------+------------+-----------+-------+--------+-------------+-------+---------+ lcr_rule +----+------------------------+-----------------------------------+------------------+--------+----------+-----------+---------+---------+ | id | desc | request_uri | lcr_id | prefix | from_uri | mt_tvalue | stopper | enabled | +----+------------------------+-----------------------------------+------------------+--------+----------+-----------+---------+---------+ | 1 | Default | .+ | 1 | NULL | NULL | NULL | 0 | 1 | | 2 | France GSM | (0|(|00|\+)33)[67]\d{8} | 1 | NULL | NULL | NULL | 1 | 1 | | 3 | France | (0|(|00|\+)33)[1-59]\d{8} | 1 | NULL | NULL | NULL | 1 | 1 | | 4 | International default | (00|\+)[1-9].+ | 1 | NULL | NULL | NULL | 1 | 1 | | 5 | Italy | (00|\+)39.+ | 1 | NULL | NULL | NULL | 1 | 1 | | 14 | to_oldmedias | .+ | 2 | NULL | NULL | NULL | 0 | 1 | +----+------------------------+-----------------------------------+-------------------+--------+----------+-----------+---------+---------+ lcr_rule_target +----+--------+---------+-------+----------+--------+ | id | lcr_id | rule_id | gw_id | priority | weight | +----+--------+---------+-------+----------+--------+ | 25 | 1 | 3 | 3 | 1 | 1 | | 26 | 1 | 3 | 18 | 2 | 1 | | 28 | 1 | 3 | 30 | 3 | 1 | | 29 | 1 | 2 | 30 | 4 | 1 | | 30 | 1 | 2 | 3 | 2 | 1 | | 31 | 1 | 2 | 18 | 3 | 1 | | 32 | 1 | 2 | 20 | 1 | 1 | | 33 | 1 | 1 | 30 | 1 | 1 | | 34 | 1 | 12 | 1 | 1 | 1 | | 35 | 1 | 12 | 10 | 1 | 1 | | 37 | 2 | 14 | 32 | 1 | 1 | | 38 | 2 | 14 | 33 | 1 | 1 | | 39 | 2 | 14 | 34 | 1 | 1 | | 40 | 2 | 14 | 35 | 1 | 1 | | 41 | 2 | 14 | 36 | 1 | 1 | | 42 | 2 | 14 | 37 | 1 | 1 | | 43 | 2 | 14 | 38 | 1 | 1 | | 45 | 1 | 2 | 10 | 3 | 1 | +----+--------+---------+-------+----------+--------+ to test gws, I use kamcmd for example : kamcmd lcr.load_gws 1 s:0600000001 s:02111111111 s:0600000001 arg 1 : prefix or $rU arg 2 : from_uri arg 3 : request_uri result is OK with 5 gateways selected but in real test situation with the following config file : kamailio.cfg : request_route { ... if(!load_gws(1,$rU,$fU)) { sl_send_reply("500", "Cannot load gateways"); exit; } ## - dumping the list of lcr gateways $var(i) = 0; while( $(avp(lcr_gw_uri)[$var(i)]) != $null) { xlog("L_ERR","loaded gw_uri_avp[$var(i)]=’$(avp(lcr_gw_uri)[$var(i)])’\n"); $var(i) = $var(i) + 1; } if(!next_gw()) { sl_send_reply("503", "No gateways found"); exit; } } ..... => we receive a 503 "No gateways found", which indicate that load_gws() is OK, but wasn't able to parse avp lcr_gw_uri (we have no xlog output) Then I noticed that some calls are OK and others are KO (with same pattern for $rU) => lcr rule id 2 So I with debug=3 *call to 0611111111 => load_gws OK and next_gw OK* lcr [lcr_mod.c:3018]: do_from_gw(): request did not come from gw lcr [lcr_mod.c:3018]: do_from_gw(): request did not come from gw lcr [lcr_mod.c:3004]: do_from_gw(): request game from gw lcr [lcr_mod.c:3009]: do_from_gw(): added tag_avp <cps=5;cc=50> lcr [lcr_mod.c:2264]: ki_load_gws_furi(): load_gws(1, 0611111111, 0211111111) lcr [lcr_mod.c:2313]: ki_load_gws_furi(): from uri <0211111111> did not match to from regex <AMD> lcr [lcr_mod.c:2349]: ki_load_gws_furi(): request uri < sip:0611111111@10.192.50.227:5060> did not match to request regex <(00|\+)39.+> lcr [lcr_mod.c:2349]: ki_load_gws_furi(): request uri < sip:0611111111@10.192.50.227:5060> did not match to request regex <(00|\+)[1-9].+> lcr [lcr_mod.c:2349]: ki_load_gws_furi(): request uri < sip:0611111111@10.192.50.227:5060> did not match to request regex <(0|(|00|\+)33)[1-59]\d{8}> lcr [lcr_mod.c:2369]: ki_load_gws_furi(): added matched_gws[0]=[4, 0, 3, 2329862] lcr [lcr_mod.c:2369]: ki_load_gws_furi(): added matched_gws[1]=[5, 0, 1, 5553909] lcr [lcr_mod.c:2369]: ki_load_gws_furi(): added matched_gws[2]=[8, 0, 3, 7256660] lcr [lcr_mod.c:2369]: ki_load_gws_furi(): added matched_gws[3]=[7, 0, 2, 3129551] lcr [lcr_mod.c:2369]: ki_load_gws_furi(): added matched_gws[4]=[6, 0, 4, 2234577] lcr [lcr_mod.c:2085]: add_gws_into_avps(): added gw_uri_avp <6|sip:|0|||3543318538||5060||;transport=udp|0|2> with weight <2234577> lcr [lcr_mod.c:2085]: add_gws_into_avps(): added gw_uri_avp <4|sip:|0||fd=carrier5|53657610||5060||;transport=udp|0|2> with weight <2329862> lcr [lcr_mod.c:2085]: add_gws_into_avps(): added gw_uri_avp <8|sip:|0|||3593650186||5060||;transport=udp|0|2> with weight <7256660> lcr [lcr_mod.c:2085]: add_gws_into_avps(): added gw_uri_avp <7|sip:|0|||3560095754||5060||;transport=udp|0|2> with weight <3129551> lcr [lcr_mod.c:2085]: add_gws_into_avps(): added gw_uri_avp <5|sip:|0|||3526541322||5060||;transport=udp|0|2> with weight <5553909> lcr [lcr_mod.c:2610]: generate_uris(): r_uri <sip:0611111111@10.192.50.210:5060;transport=udp>, dst_uri <> lcr [lcr_mod.c:2904]: ki_next_gw(): added ruri_user_avp <0611111111> lcr [lcr_mod.c:2950]: ki_next_gw(): added tag_avp <> lcr [lcr_mod.c:2965]: ki_next_gw(): added defunct_gw_avp <3526541322> lcr [lcr_mod.c:2610]: generate_uris(): r_uri <sip:0611111111@10.192.50.212:5060;transport=udp>, dst_uri <> lcr [lcr_mod.c:2950]: ki_next_gw(): added tag_avp <> lcr [lcr_mod.c:2965]: ki_next_gw(): added defunct_gw_avp <3560095754> lcr [lcr_mod.c:2610]: generate_uris(): r_uri <sip:0611111111@10.192.50.214:5060;transport=udp>, dst_uri <> lcr [lcr_mod.c:2950]: ki_next_gw(): added tag_avp <> lcr [lcr_mod.c:2965]: ki_next_gw(): added defunct_gw_avp <3593650186> lcr [lcr_mod.c:2610]: generate_uris(): r_uri <sip:0611111111@10.192.50.3:5060;transport=udp>, dst_uri <> lcr [lcr_mod.c:2950]: ki_next_gw(): added tag_avp <fd=carrier5> lcr [lcr_mod.c:2965]: ki_next_gw(): added defunct_gw_avp <53657610> lcr [lcr_mod.c:2610]: generate_uris(): r_uri <sip:0611111111@10.192.50.211:5060;transport=udp>, dst_uri <> lcr [lcr_mod.c:2950]: ki_next_gw(): added tag_avp <> lcr [lcr_mod.c:2965]: ki_next_gw(): added defunct_gw_avp <3543318538> the right gws are selected and call are routed to them *call to 0600000001 => load_gws OK and next_gw KO* lcr [lcr_mod.c:3018]: do_from_gw(): request did not come from gw lcr [lcr_mod.c:3018]: do_from_gw(): request did not come from gw lcr [lcr_mod.c:3004]: do_from_gw(): request game from gw lcr [lcr_mod.c:3009]: do_from_gw(): added tag_avp <cps=5;cc=50> lcr [lcr_mod.c:2264]: ki_load_gws_furi(): load_gws(1, 0600000001, 0211111111) lcr [lcr_mod.c:2313]: ki_load_gws_furi(): from uri <0170619309> did not match to from regex <AMD> lcr [lcr_mod.c:2349]: ki_load_gws_furi(): request uri < sip:0600000001@10.192.50.227:5060> did not match to request regex <(00|\+)39.+> the process stops after trying to match rule with regexp <(00|\+)39.+> Don't know if it's a bug or if I misunderstood something ! Thanks in advance ! Best regards, -- <https://app.livestorm.co/comdata-group/metaverse-what-will-cx-look-like-in-…>

1 year, 12 months

Local Registration Cache

by Linux Vince

Hello, I am trying to implement scenario described in this thread by Daniel-Constantin Mierla. I am able to cache registration using save but i am not able to handle unregistration. Unregister function of registrar module is not available in onreply routes and I cannot unregister until upstream registrar returns 200 OK on Expire 0 message. Is there any workaround to fix this? Thanks,

1 year, 12 months

SSL errors with websocket clients

by Vinicius Kwiecien Ruoso

Hi all! How are you? I have a kamailio instance and some users are having issues connecting via websocket using TLS. The logs show SSLv3 errors. Cannot find why that error would show up if SSLv2/3 is not enabled. Double checked it via SSLLabs that only TLSv1.2 is allowed in the service. Error sample: ``` 15(36) ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS accept:error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown 15(36) ERROR: <core> [core/tcp_read.c:1512]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7fafc8768190 r: 0x7fafc8768278 (-1) ``` This instance has close to 400 websocket connections opened during the day. I have a high log level enabled. I was not able to identify any reason why this happens. The certificate is a Letsencrypt certificate. The issue is that sometimes clients have a hard time connecting to the websocket and that maybe related. Below are a few more details about the config. Please let me know if you have any pointers on how to debug those connection issues. 8<----- TLS config: modparam("tls", "tls_method", "TLSv1.2+") modparam("tls", "verify_certificate", 0) modparam("tls", "require_certificate", 0) modparam("tls", "low_mem_threshold1", 0) modparam("tls", "low_mem_threshold2", 0) modparam("tls", "private_key", "/etc/certs/tls.key") modparam("tls", "certificate", "/etc/certs/tls.crt") version: kamailio 5.3.9 (x86_64/linux) 8<----- This is related to the issue https://github.com/kamailio/kamailio/issues/3085 (as pointed out it is not a problem in Kamailio code). Thanks, Vinicius

2 years

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 April 2022