sr-users July 2025

sr-users@lists.kamailio.org

56 participants
45 discussions

Unknown character set utf8mb4
by Igor Potjevlesch 31 Jul '25

31 Jul '25

Hello, We move to fresh version of Kamailio 6. We have a MySQL backend in an old version. We have many errors like this: ERROR: db_mysql [km_dbase.c:127]: db_mysql_submit_query(): driver error on query: Unknown character set: 'utf8mb4' (1115) ERROR: <core> [lib/srdb1/db_query.c:393]: db_do_update(): error while submitting query ERROR: dialog [dlg_db_handler.c:1000]: update_dialog_dbinfo_unsafe(): could not update database info ERROR: db_mysql [km_dbase.c:127]: db_mysql_submit_query(): driver error on query: Unknown character set: 'utf8mb4' (1115) ERROR: <core> [lib/srdb1/db_query.c:158]: db_do_query_internal(): error while submitting query ERROR: avpops [avpops_impl.c:328]: ops_dbload_avps(): db_load failed ERROR: db_mysql [km_dbase.c:127]: db_mysql_submit_query(): driver error on query: Unknown character set: 'utf8mb4' (1115) ERROR: <core> [lib/srdb1/db_query.c:158]: db_do_query_internal(): error while submitting query ERROR: avpops [avpops_impl.c:328]: ops_dbload_avps(): db_load failed It looks like the accounting module is not affected because we have writes in acc table. Registrar is affected because dump from location to location table is not working. Is there a way to make it work with older version of MySQL? Regards, Igor. -- Cet e-mail a été vérifié par le logiciel antivirus d'Avast. www.avast.com

2 4

Rtpengine: RTP Inject and RTP Bleed vulnerabilities despite proper configuration (CVSS v4.0 Score: 9.3 / Critical)
by Sandro Gauci 31 Jul '25

31 Jul '25

Rtpengine: RTP Inject and RTP Bleed vulnerabilities despite proper configuration (CVSS v4.0 Score: 9.3 / Critical) - CVSS v4.0 - Exploitability: High - Complexity: Low - Vulnerable system: Medium - Subsequent system: Medium - Exploitation: High - Security requirements: High - Vector: https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N… - Other references: CVE-2025-53399 (https://www.cve.org/CVERecord?id=CVE-2025-53399) - Fixed versions: >= mr13.4.1.1 (https://github.com/sipwise/rtpengine/releases/tag/mr13.4.1.1) - Enable Security Advisory: https://github.com/EnableSecurity/advisories/tree/master/ES2025-01-rtpengin… - Tested vulnerable versions: mr13.3.1.4 and lower - Timeline: - First report: 2025-04-24 - Triaged: 2025-04-30 - Fix provided for testing: 2025-05-05 - Various back and forth and more fixes: 2025-05 / 2025-06 - Vendor applied all fixes satisfactorily to master branch: 2025-06-05 - Enable Security verified and confirmed fix: 2025-06-26 - Vendor release with fix (mr13.4.1.1): 2025-07-03 - Enable Security advisory: 2025-07-31 DESCRIPTION Media servers often support source address learning to dynamically adapt to network conditions and client behavior. This is especially useful in scenarios involving NAT where the source IP and port of incoming RTP packets may differ from what was initially signaled via SDP over SIP. However, this mechanism can be exploited for two types of attacks if malicious packets are accepted as legitimate: 1. RTP Bleed - when a victim's media (e.g., audio) can be redirected to an attacker-controlled host 2. RTP Inject – when attackers can insert arbitrary RTP packets into active calls Note: Neither of these attacks requires the attacker to act as a man-in-the-middle. Additionally, when rtpengine relays SRTP packets in vulnerable versions, it does not validate their authentication tag, also allowing RTP Bleed and RTP Inject despite the use of SRTP which should guarantee confidentiality and integrity. Instead of dropping packets with missing or invalid authentication tags, it forwards them for processing. The purpose of this advisory is to describe security fixes that aim to fully address or at least mitigate these RTP Bleed and RTP Inject attacks wherever possible. While complete elimination of these vulnerabilities may not always be achievable due to the inherent nature of RTP learning mechanisms, the fixes provide significant improvements in security posture. TECHNICAL DETAILS Rtpengine provides the following learning modes through the --endpoint-learning option: - delayed (default): waits 3 seconds before learning the source address from the first RTP packet received after the delay. - immediate: learns the address from the very first incoming packet, with no delay. - no-learning: disables learning entirely, which is the only mode that is not vulnerable but can break connectivity for clients behind NAT. - heuristic: combines a 3-second delay with a ranking system that prefers addresses matching the original SDP, falling back to partial matches or any observed address if necessary. Additionally, rtpengine supports an optional strict source flag that forces continued inspection of source addresses and ports of incoming RTP packets. It does this after the learning phase, enforcing what was previously learned. The strict source flag is meant to prevent RTP Inject but needs the learning mode to work as expected for it to also work correctly. The often recommended mitigation is to make use of SRTP, with the assumption that rtpengine would discard any RTP packets that fail the authentication tag check. However, in rtpengine mr13.3.1.4 and lower, this was not found to be the case when using SDES-SRTP. The following is a behavior matrix for rtpengine versions mr13.3.1.4 and lower showing different learning modes and flags. This table shows that none of the learning modes nor strict source mitigated the attacks described, except for the combination of strict source with no-learning: | Delayed | Heuristic | No learning | Immediate | no strict source | Inject, Bleed | Inject, Bleed | Inject only | Inject, Bleed | strict source | Inject, Bleed | Inject, Bleed | No Inject or Bleed | Inject, Bleed | The same behavior occurred whether rtpengine relayed plaintext RTP or SDES-SRTP. The heuristic flag did not prevent RTP Bleed or RTP Inject attacks, even when the correct IPs and ports are exchanged over SDP. With the updated version, rtpengine's heuristic behavior was changed so that the learning modes behave as expected, giving administrators the opportunity to mitigate these vulnerabilities while still handling NAT complexities. The following is the same behavior matrix, but with the fixed version: | Delayed | Heuristic | No learning | Immediate | no strict source | Inject, Bleed | Inject, <5 packets Bleed | Inject only | Inject, Bleed | strict source | Inject, Bleed | <5 packets Inject, <5 packets Bleed | No Inject or Bleed | Inject, Bleed | This means that with the updated version, the heuristic mode limits attacks to at most the first 5 packets for both injection and bleeding. We believe that in many live environments, the recommended setup would be to use heuristic learning with strict source, which keeps the flexibility of endpoint learning while significantly mitigating RTP inject and RTP bleed attacks. In the case of SDES-SRTP, we also recommend using heuristic learning mode with strict source, which keeps the flexibility of endpoint learning while mitigating RTP inject and RTP bleed. However, for complete protection with SRTP, a patch specific to SRTP was introduced by adding a new recrypt flag. This flag forces rtpengine to decrypt and then re-encrypt RTP packets, thus validating the authentication tag before any further processing. This ensures that unauthenticated packets are discarded. This new flag should be used in addition to the previously recommended learning mode and flag. Patched version behavior matrix for SDES-SRTP, with and without recrypt: | Delayed | Heuristic | No-learning | Immediate | Without recrypt | Inject, Bleed | Inject, <5 packets Bleed | Inject only | Inject, Bleed | With recrypt | No Inject or Bleed | No Inject or Bleed | No Inject or Bleed | No Inject or Bleed | There is the special case of DTLS-SRTP, typically used for WebRTC environments, which was found vulnerable to RTP Bleed but not RTP Inject. This was due to the logic applied in this case, where learning mode occurred before the RTP packets were properly validated. This has also received a security fix. IMPACT In the case of plaintext RTP, this vulnerability allows attackers to perform RTP Inject as well as RTP Bleed. RTP Inject affects the integrity of the media while RTP Bleed affects the confidentiality of calls. In cases where rtpengine is relaying plaintext RTP as well as when it relays SRTP (in vulnerable versions), the vulnerabilities will cause Denial of Service because the RTP packets will be sent to the attacker instead of the legitimate recipient. HOW TO REPRODUCE THE ISSUE To reproduce this issue in a reliable manner, a security tester needs three different parties each with their own IP address: 1. Vulnerable rtpengine server 2. An attacker node 3. A victim user node Steps: 1. Run tcpdump on the attacker node to monitor for incoming packets from the target: tcpdump -iany -w /tmp/rtpbleed.pcap src host <target_ip> and not icmp 2. Save the following Python script as sprayrtp.py: import socket, argparse parser = argparse.ArgumentParser(description="Spray simple RTP packets over a port range") parser.add_argument("target", help="Target IP address") parser.add_argument("start_port", type=int, help="First UDP port to spray") parser.add_argument("end_port", type=int, help="Last UDP port to spray") args = parser.parse_args() rtppacket=[0x80, 0x0, 0xee, 0x3c, 0x4, 0x42, 0xa2, 0xc1, 0xef, 0xa, 0x7, 0xde] rtppacket+=[0x0 for _ in range(160)] sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) while True: for port in range(args.start_port, args.end_port + 1): sock.sendto(bytes(rtppacket), (args.target, port)) 3. Run the script on the attacker node against the target: python3 sprayrtp.py <target_ip> <start_port> <end_port> 4. From the victim user node, place a number of calls that make use of SRTP. 5. Observe that tcpdump on the attacker node will show incoming packets from the vulnerable target. Note: a SIP signaling server such as Kamailio or OpenSIPS is usually part of the setup as well. SOLUTIONS AND RECOMMENDATIONS It is recommended to upgrade to a fixed version, and to either disable learning entirely or use the heuristic learning mode in conjunction with the strict source flag. When using SDES-SRTP, it is recommended to use both strict source and recrypt flags for complete protection. While fixes for the heuristic mode were backported to earlier versions, the new recrypt flag is only available in the latest version. In the case of DTLS-SRTP, a fix was made so that SRTP validation occurs before learning mode. We highly recommend upgrading to access these security features. The first version that includes the fixes is available at https://github.com/sipwise/rtpengine/releases/tag/mr13.4.1.1. ABOUT ENABLE SECURITY Enable Security (https://www.enablesecurity.com) provides quality penetration testing to help protect your real-time communications systems against attack. DISCLAIMER The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information. DISCLOSURE POLICY This report is subject to Enable Security's vulnerability disclosure policy which can be found at https://github.com/EnableSecurity/Vulnerability-Disclosure-Policy.

2 2

No audio Over VPN
by Fernando Lopes 31 Jul '25

31 Jul '25

Hello everyone, I'm having some issues with SIP when the VPN is active. I'm running a Docker container inside WSL. My WSL IP is 172.31.217.74, and my machine's IP is 192.168.1.77. When I connect to the VPN, I get the IP 192.168.1.129. When I place a call, I see this log. I've tried disabling ICE, setting the public IP of the SIP server in MicroSIP, and manually specifying my local machine IP. This does change the c= and a= parameters in the SDP, but it still doesn't work. Everything works fine without the VPN. I need the VPN active to access certain endpoints, but SIP stops working once it's connected. INVITE sip:100@localhost;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 172.31.208.1:54367;rport;branch=z9hG4bKPjb591721e91454d2bae56a9edfc645ebe;alias Max-Forwards: 70 From: "6001" <sip:6001@localhost>;tag=daa078657d2949e68935f308beeb8b89 To: <sip:100@localhost> Contact: "6001" <sip:6001@172.31.208.1:54367;transport=TCP;ob>;+sip.ice Call-ID: 49c169a9e92d4b23ad70709636ccab4f CSeq: 13400 INVITE Route: <sip:172.31.217.74;transport=tcp;lr> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 User-Agent: MicroSIP/3.21.6 Content-Type: application/sdp Content-Length: 1345 v=0 o=- 3962710251 3962710251 IN IP4 192.168.1.129 s=pjmedia b=AS:84 t=0 0 a=X-nat:0 m=audio 4030 RTP/AVP 8 0 96 97 98 9 99 100 101 102 103 c=IN IP4 192.168.1.129 b=TIAS:64000 a=rtcp:4001 IN IP4 192.168.1.129 ... a=ice-ufrag:1d266809 a=ice-pwd:2f7e2ef6047a47d832ed0f55 a=candidate:Hc0a80181 1 UDP 2130706431 192.168.1.129 4030 typ host a=candidate:Hc0a8014d 1 UDP 2130706175 192.168.1.77 4030 typ host a=candidate:Hc0a83801 1 UDP 2130705919 192.168.56.1 4030 typ host a=candidate:Hac1fd001 1 UDP 2130705663 172.31.208.1 4030 typ host a=candidate:Hc0a80181 2 UDP 2130706430 192.168.1.129 4001 typ host a=candidate:Hc0a8014d 2 UDP 2130706174 192.168.1.77 4001 typ host a=candidate:Hc0a83801 2 UDP 2130705918 192.168.56.1 4001 typ host a=candidate:Hac1fd001 2 UDP 2130705662 172.31.208.1 4001 typ host Does anyone know where the problem may be?

4 5

kamailio 5.8.6 sanity problem
by ale Gural 31 Jul '25

31 Jul '25

Hello, when kamailio 5.8.6 got the follow SIP message. INVITE sip:026774800@kamnet:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.25.206.73:5060;branch=z9hG4bK6204h710copg0h2s34a0.1 From: <sip:506555021@kamnet :5060;transport=UDP;user=phone>;tag=BN-1778920881-1-1752995491-343935404 To: <urn:service:sos.police@kamnet> Call-ID: 5f6d530-13f3cbf9-fb215-7f1546651f58-4d0f660a-13c4-764 CSeq: 1 INVITE X-SessionId: -1778920881 User-Agent: BN4000-3.9.2-706 Max-Forwards: 60 Supported: norefersub,timer,100rel,199 P-Asserted-Identity: <sip:506555021@hotmobile.co.il:5060 ;transport=UDP;user=phone> P-Asserted-Identity: <tel:506555021;phone-context=+972> Contact: <sip:10.25.206.73:5060;yop=00.00.84CE62D9.0000.7009;transport=udp> P-Early-Media: supported P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=425074efe02c6a01 Content-Disposition: session;handling=required Allow: INVITE,CANCEL,ACK,BYE,OPTIONS,INFO,PRACK,UPDATE,REFER,NOTIFY Content-Type: application/sdp Content-Length: 207 v=0 o=BN4000 0 0 IN IP4 10.9.21.56 s=- c=IN IP4 10.9.21.56 t=0 0 m=audio 54732 RTP/AVP 8 0 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=maxptime:20 a=ptime:20 the TO To: <urn:service:sos.police@kamnet>, the problem is kamailio 5.8.6 response with 400 bad to header but kamailio 5.7.5 continue with normal call. here you can see the sanity log for both kamailio: kamailio 5.8.6 Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:254]: check_ruri_sip_version(): check_ruri_sip_version entered Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:278]: check_ruri_sip_version(): check_ruri_sip_version passed Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:286]: check_ruri_scheme(): check_ruri_scheme entered Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:305]: check_ruri_scheme(): check_ruri_scheme passed Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:327]: check_required_headers(): check_required_headers entered Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:350]: check_required_headers(): check_required_headers passed Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:519]: check_cseq_method(): check_cseq_method entered Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:553]: check_cseq_method(): check_cseq_method passed Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:563]: check_cseq_value(): check_cseq_value entered Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:591]: check_cseq_value(): check_cseq_value passed Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:601]: check_cl(): check_cl entered Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:626]: check_cl(): check_cl passed Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:643]: check_expires_value(): check_expires_value entered Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:679]: check_expires_value(): no expires header found Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:776]: check_parse_uris(): check_parse_uris entered Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:780]: check_parse_uris(): parsing ruri Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:793]: check_parse_uris(): looking up From header Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: sanity [sanity.c:808]: check_parse_uris(): looking up To header Jul 20 17:08:15 vm-tkamprov-n 671587 DEBUG: <core> [core/parser/parse_uri.c:1369]: parse_uri(): bad char '@' in state 5 parsed: <urn:service:sos.police> (22) / <urn:service:sos.police@kamnet> (29) Jul 20 17:08:15 vm-tkamprov-n 671587 ERROR: <core> [core/parser/parse_to.c:81]: parse_to_uri(): failed to parse To uri Jul 20 17:08:15 vm-tkamprov-n 671587 WARNING: sanity [sanity.c:810]: check_parse_uris(): invalid To header or uri kamailio 5.7.5 Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:253]: check_ruri_sip_version(): check_ruri_sip_version entered Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:277]: check_ruri_sip_version(): check_ruri_sip_version passed Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:285]: check_ruri_scheme(): check_ruri_scheme entered Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:304]: check_ruri_scheme(): check_ruri_scheme passed Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:326]: check_required_headers(): check_required_headers entered Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:349]: check_required_headers(): check_required_headers passed Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:518]: check_cseq_method(): check_cseq_method entered Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:552]: check_cseq_method(): check_cseq_method passed Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:562]: check_cseq_value(): check_cseq_value entered Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:590]: check_cseq_value(): check_cseq_value passed Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:600]: check_cl(): check_cl entered Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:625]: check_cl(): check_cl passed Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:638]: check_expires_value(): check_expires_value entered Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:674]: check_expires_value(): no expires header found Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:771]: check_parse_uris(): check_parse_uris entered Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:775]: check_parse_uris(): parsing ruri Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:788]: check_parse_uris(): looking up From header Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:803]: check_parse_uris(): looking up To header Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity.c:853]: check_parse_uris(): check_parse_uris passed Jul 20 17:00:51 vm-tkamprov-n 662105 DEBUG: sanity [sanity_mod.c:252]: w_sanity_check(): sanity checks result: 1 Thanks

4 8

Postgres connections optimization #4342
by Stephane Savonitto 30 Jul '25

30 Jul '25

Hello, On P-CSCF when running we have 200+ permanent connection to postgres db, even if there is no traffic. Is there a way to manage connections dynamically using a pool like using PgBouncer ? Regards, Stéphane

5 8

Dispatcher failover to the next least loaded destination
by i.ribakov＠zaleos.net 30 Jul '25

30 Jul '25

Hi all, I'm wondering if it is currently supported to perform failover while respecting the call load distribution algorithm. What makes me doubt this is possible is the following wording in the documentation: > The rest of the destination list is taken in order of the entries in set - anyhow, until a re-route to next destination happens, the load on each address can change. From it it's not clear if ds_next_dst() will simplify use next entry from the AVP list or if it will attempt to intelligently choose next entry from the AVP list taking into the account updated call load of the remaining entries.

3 2

Kamailio DNS functions available for HTTP too?
by Sergio Charrua 29 Jul '25

29 Jul '25

Hi all, I was looking at the following document kamailio/doc/tutorials/dns.txt at master · kamailio/kamailio <https://github.com/kamailio/kamailio/blob/master/doc/tutorials/dns.txt> and wondering if these functionalities are only available for SIP (as it mentions TM module) or can they be used also for HTTP Requests, using HTTP Async Client module. Can anyone clarify ? The final goal is to have HTTP Async Requests sent to a domain name that can resolve to the next available IP address of the HTTP server (for failover): if address #1 is down, send the http request to the next available server. Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

1 0

reading out "response" and "integrity-protected" from "Authorization" header field
by Valentin Christoph 29 Jul '25

29 Jul '25

Hi all, Again an IMS question. The 3GPP TS 24.229 specifies some additional parameters for the "Authorization" header field in REGISTER requests, e.g. the "integrity-protected" parameter and the "response" parameter. Now the question: is it the only way to read out these parameters from the "Authorization" header field, by implementing new pseudo variables, e.g. $aip and $are, or is there an easy way using $hdr() from the configuration? I want to avoid sophisticated regular expressions. Thanks, Christoph

2 1

Unable to find MOH files
by 17603019528＠163.com 28 Jul '25

28 Jul '25

Hi everyone When I use the mohqueue module, I get the following error message: ``` 0(7901) ERROR: mohqueue [mohq_db.c:484]: update_mohq_lst(): Queue,Field (abc,mohdir): Unable to find MOH files (/var/kamailio/MOH//HeWillCall.8.*)! 0(7901) ERROR: mohqueue [mohqueue_mod.c:400]: mod_init(): Unable to load rtpproxy_answer! 0(7901) ERROR: <core> [core/sr_module.c:1039]: init_mod(): Error while initializing module mohqueue (/usr/local/lib64/kamailio/modules/mohqueue.so) ``` here is the audio file: ``` ll /var/kamailio/MOH/HeWillCall.8 -rwxrwxrwx. 1 root root 550080 Jul 28 13:53 /var/kamailio/MOH/HeWillCall.8 ``` kamailio version: kamailio 5.8.5 (x86_64/linux)

4 4

Re: Delivery Status Notification (Delay)
by palany 26 Jul '25

26 Jul '25

XxSent from my Galaxy -------- Original message --------From: David Villasmil via sr-users <sr-users(a)lists.kamailio.org> Date: 09/07/2025 18:09 (GMT+02:00) To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> Cc: David Villasmil <david.villasmil.work(a)gmail.com> Subject: [SR-Users] Re: Delivery Status Notification (Delay) i'm seeing this for some reason, anyone knows why?Regards,David Villasmilemail: david.villasmil.work(a)gmail.comOn Wed, Jul 9, 2025 at 3:34 PM Mail Delivery Subsystem <mailer-daemon(a)googlemail.com> wrote: Delivery incomplete There was a temporary problem delivering your message to users(a)lists.openser.org. Gmail will retry for 21 more hours. You'll be notified if the delivery fails permanently. The response from the remote server was: 454 4.7.1 : Relay access denied ---------- Forwarded message ----------From: David Villasmil <david.villasmil.work(a)gmail.com>To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org>, openser users <users(a)lists.openser.org>Cc: Bcc: Date: Mon, 7 Jul 2025 12:44:38 +0200Subject: Stir/ShakenHello,I've seen people wondering how to implement Stir/shaken on Kamailio and OpenSIPS. It occurred to me that making a docker image would help a lot of people so I did. You can find it in https://hub.docker.com/repository/docker/davidcsi/kamailio-stirshaken/gener… and in the description you can read how it works and how to use it.Hope it helps! David Villasmilemail: david.villasmil.work(a)gmail.com

1 0

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 July 2025