sr-users

sr-users@lists.kamailio.org

35 participants
37508 discussions

Start a nNew thread

The index indicates that the sipjson module is not present in 6.0.x.
by 13715209697＠139.com 10 May '25

10 May '25

https://www.kamailio.org/docs/modules/6.0.x/modules/

3 2

SIPP UAS scenario
by Sergio Charrua 09 May '25

09 May '25

Hi all! my DEV/LAB environment is comprised of 3 nodes: - SIP 1 with Asterisk and SIPP installed (IP 10.20.0.5) - SIP 2 with Kamailio 5.8 (IP 10.20.0.4) - SIP 3 with Asterisk and SIPP installed (IP 10.20.0.6) Kamailio is set as a stateful SIP Proxy and seems to be working fine (the configuration is pretty standard, using dispatcher to dispatch to destination, even though there is only 1 destination endpoint -» SIP 3) When establishing a call from SIP 1 using Asterisk, the termination is correctly done on SIP 3, also running Asterisk. Hanging up call on SIP 3 will send the correct BYE command to SIP 1 (of course, Kamailio is always between the dialogs) When establishing a call from SIP 1 using SIPP and UAC scenario, the termination is correctly done on SIP 3 also running SIPP with a UAS scenario. However, hanging up the call on SIP 3 (SIPP scenario has a Pause of 2 seconds then sends a BYE message), the BYE command is not forwarded by Kamailio and SIPP keep sending BYE commands. This is an example of the ACK and BYE command being sent from SIP 3: > ACK sip:10.20.0.6:5060;transport=UDP SIP/2.0 > Via: SIP/2.0/UDP > 10.20.0.4;branch=z9hG4bK680a.47d763c3f0732dbe0fdb64ccbeb3454a.0 > Via: SIP/2.0/UDP 10.20.0.5:5060 > ;received=10.20.0.5;branch=z9hG4bK01175d44;rport=5060 > Max-Forwards: 69 > From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=as023237be > To: <sip:1000@10.20.0.4>;tag=20 > Contact: <sip:anonymous@10.20.0.5:5060> > Call-ID: 568f1bbe197039983fc89cc6403b927b@10.20.0.5:5060 > CSeq: 102 ACK > User-Agent: Asterisk PBX 18.17.1 > Content-Length: 0 and then: > BYE sip:anonymous@10.20.0.5:5060 SIP/2.0 > Via: SIP/2.0/UDP 10.20.0.6:5060 > Route: <sip:10.20.0.4;lr=on;ftage=46906> > Max-Forwards: 70 > From: sipp <sip:sipp@10.20.0.6:5060>;tag=46906SIPpTag0120 > To: : "Anonymous" <sip:anonymous@anonymous.invalid>;tag=as023237be > Call-ID: 568f1bbe197039983fc89cc6403b927b@10.20.0.5:5060 > Cseq: 2 BYE > Contact: sip:sipp@10.20.0.6:5060 > Content-Length: 0 > Subject: Sending BYE I'm pretty sure that the issue is within the SIPP Scenario(s), and my guess goes to the UAS scenario on SIP 3 that has some issue with the BYE command, but I can't figure why the message is wrong! The goal is to have a Testing environment where we can simulate different call situations. SIPP is a wonderful tool but such a PITA !! Probably i am missing some detail somewhere.... Has anyone done such a testing environment? Can anyone share a SIPP UAS scenario where the BYE command is sent from the UAS (send BYE instead of recv BYE) ? SIPP is launched on SIP 1 with: sipp -sf uac.xml -i 10.20.0.5 -p 5060 10.20.0.4 -r 1 -m 1 SIPP is launched on SIP 3 with: sipp -aa -sf uas5.xml -i 10.20.0.6 -p 5060 Thanks in advance. Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

2 2

Kamailio Crash
by Ben Kaufman 09 May '25

09 May '25

Greetings, all, I have a redirect server doing CNAM lookup (via http_async) and STIR/SHAKEN validation with secsipidx that is crashing every few hours. Kamailio 6.0.1 running in a Debian 12 container on an Amazon Linux 2023 host with ARM CPU. root@0689d4fe5fed:/# kamailio -v version: kamailio 6.0.1 (aarch64/linux) fce50d flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT-NOSMP, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_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: fce50d compiled on 15:50:40 Apr 1 2025 with gcc 12.2.0 Back trace is here, so I think it's a secsipid related problem? Slightly sanitized this output (Removed SIP message specifics in step #42). What should be my next course of action? #0 __pthread_kill_implementation (threadid=281473196830752, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x0000ffff95c90ab4 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 #2 0x0000ffff95c4a72c in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x0000ffff95c3747c in __GI_abort () at ./stdlib/abort.c:79 #4 0x0000ffff95c84aac in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0xffff95d66d28 "%s\n") at ../sysdeps/posix/libc_fatal.c:156 #5 0x0000ffff95c9aebc in malloc_printerr (str=str@entry=0xffff95d62098 "double free or corruption (!prev)") at ./malloc/malloc.c:5660 #6 0x0000ffff95c9cee8 in _int_free (av=0xffff95db0af0 <main_arena>, p=p@entry=0xaaab05dd41b0, have_lock=<optimized out>, have_lock@entry=0) at ./malloc/malloc.c:4587 #7 0x0000ffff95c9f77c in __GI___libc_free (mem=<optimized out>) at ./malloc/malloc.c:3385 #8 0x0000ffff90eb0a0c in w_secsipid_get_url (msg=0xffff92f53030, purl=0xffff92e84e10 "\220M\350\222\377\377", povar=0xffff92e84fd0 "\004") at secsipid_mod.c:961 #9 0x0000aaaaea4fd710 in do_action (h=0xffffff40a610, a=0xffff92e8e9b0, msg=0xffff92f53030) at core/action.c:1133 #10 0x0000aaaaea50d3c4 in run_actions (h=0xffffff40a610, a=0xffff92e8e9b0, msg=0xffff92f53030) at core/action.c:1620 #11 0x0000aaaaea50db44 in run_actions_safe (h=0xffffff40bc50, a=0xffff92e8e9b0, msg=0xffff92f53030) at core/action.c:1683 #12 0x0000aaaaea71a7e0 in rval_get_long (h=0xffffff40bc50, msg=0xffff92f53030, i=0xffffff40ab48, rv=0xffff92e8fc78, cache=0x0) at core/rvalue.c:973 #13 0x0000aaaaea7200f0 in rval_expr_eval_long (h=0xffffff40bc50, msg=0xffff92f53030, res=0xffffff40ab48, rve=0xffff92e8fc70) at core/rvalue.c:1852 #14 0x0000aaaaea720118 in rval_expr_eval_long (h=0xffffff40bc50, msg=0xffff92f53030, res=0xffffff40b080, rve=0xffff92e903b0) at core/rvalue.c:1862 #15 0x0000aaaaea4fd090 in do_action (h=0xffffff40bc50, a=0xffff92e91810, msg=0xffff92f53030) at core/action.c:1099 #16 0x0000aaaaea50d3c4 in run_actions (h=0xffffff40bc50, a=0xffff92e8d690, msg=0xffff92f53030) at core/action.c:1620 #17 0x0000aaaaea4f9400 in do_action (h=0xffffff40bc50, a=0xffff92e82210, msg=0xffff92f53030) at core/action.c:711 #18 0x0000aaaaea50d3c4 in run_actions (h=0xffffff40bc50, a=0xffff92e82210, msg=0xffff92f53030) at core/action.c:1620 #19 0x0000aaaaea50db44 in run_actions_safe (h=0xffffff40daf0, a=0xffff92e82210, msg=0xffff92f53030) at core/action.c:1683 #20 0x0000aaaaea71a7e0 in rval_get_long (h=0xffffff40daf0, msg=0xffff92f53030, i=0xffffff40c188, rv=0xffff92e82378, cache=0x0) at core/rvalue.c:973 #21 0x0000aaaaea7200f0 in rval_expr_eval_long (h=0xffffff40daf0, msg=0xffff92f53030, res=0xffffff40c188, rve=0xffff92e82370) at core/rvalue.c:1852 #22 0x0000aaaaea720118 in rval_expr_eval_long (h=0xffffff40daf0, msg=0xffff92f53030, res=0xffffff40c6c0, rve=0xffff92e82ab0) at core/rvalue.c:1862 #23 0x0000aaaaea4fd090 in do_action (h=0xffffff40daf0, a=0xffff92e83a90, msg=0xffff92f53030) at core/action.c:1099 #24 0x0000aaaaea50d3c4 in run_actions (h=0xffffff40daf0, a=0xffff92e83a90, msg=0xffff92f53030) at core/action.c:1620 #25 0x0000aaaaea4fd5e8 in do_action (h=0xffffff40daf0, a=0xffff92e83bf0, msg=0xffff92f53030) at core/action.c:1119 #26 0x0000aaaaea50d3c4 in run_actions (h=0xffffff40daf0, a=0xffff92e79450, msg=0xffff92f53030) at core/action.c:1620 #27 0x0000aaaaea4f9400 in do_action (h=0xffffff40daf0, a=0xffff92e75710, msg=0xffff92f53030) at core/action.c:711 #28 0x0000aaaaea50d3c4 in run_actions (h=0xffffff40daf0, a=0xffff92e75710, msg=0xffff92f53030) at core/action.c:1620 #29 0x0000aaaaea50db44 in run_actions_safe (h=0xffffff4101f8, a=0xffff92e75710, msg=0xffff92f53030) at core/action.c:1683 #30 0x0000aaaaea71a7e0 in rval_get_long (h=0xffffff4101f8, msg=0xffff92f53030, i=0xffffff40e028, rv=0xffff92e75878, cache=0x0) at core/rvalue.c:973 #31 0x0000aaaaea7200f0 in rval_expr_eval_long (h=0xffffff4101f8, msg=0xffff92f53030, res=0xffffff40e028, rve=0xffff92e75870) at core/rvalue.c:1852 #32 0x0000aaaaea720118 in rval_expr_eval_long (h=0xffffff4101f8, msg=0xffff92f53030, res=0xffffff40e560, rve=0xffff92e75fb0) at core/rvalue.c:1862 #33 0x0000aaaaea4fd090 in do_action (h=0xffffff4101f8, a=0xffff92e76e10, msg=0xffff92f53030) at core/action.c:1099 #34 0x0000aaaaea50d3c4 in run_actions (h=0xffffff4101f8, a=0xffff92e74500, msg=0xffff92f53030) at core/action.c:1620 #35 0x0000aaaaea5095fc in do_action (h=0xffffff4101f8, a=0xffff92e79110, msg=0xffff92f53030) at core/action.c:1401 #36 0x0000aaaaea50d3c4 in run_actions (h=0xffffff4101f8, a=0xffff92e71a40, msg=0xffff92f53030) at core/action.c:1620 #37 0x0000aaaaea4f9400 in do_action (h=0xffffff4101f8, a=0xffff92dd8520, msg=0xffff92f53030) at core/action.c:711 #38 0x0000aaaaea50d3c4 in run_actions (h=0xffffff4101f8, a=0xffff92dd7e30, msg=0xffff92f53030) at core/action.c:1620 #39 0x0000aaaaea4fd5a8 in do_action (h=0xffffff4101f8, a=0xffff92dd8680, msg=0xffff92f53030) at core/action.c:1115 #40 0x0000aaaaea50d3c4 in run_actions (h=0xffffff4101f8, a=0xffff92dce4c0, msg=0xffff92f53030) at core/action.c:1620 #41 0x0000aaaaea50dbf4 in run_top_route (a=0xffff92dce4c0, msg=0xffff92f53030, c=0x0) at core/action.c:1703 #42 0x0000aaaaea6bfff8 in receive_msg ( buf=0xaaaaeac284b8 <buf> "INVITE sip:2345678901@1.2.3.4 SIP/2.0\r\nRecord-Route: <sip:1.2.3.5;lr=on;ftag=gK045643d5>\r\nRecord-Route: <sip:1.2.3.6;lr=on;ftag=gK045643d5>\r\nVia: SIP/2.0/UDP 1.2.3.5:5060;branch"..., len=2492, rcv_info=0xffffff410a10) at core/receive.c:520 #43 0x0000aaaaea85abe0 in udp_rcv_loop () at core/udp_server.c:770 #44 0x0000aaaaea4e26a8 in main_loop () at main.c:1895 #45 0x0000aaaaea4f1e88 in main (argc=16, argv=0xffffff411178) at main.c:3406 Kaufman Senior Voice Engineer E: bkaufman(a)bcmone.com SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768 [img]<https://www.sip.us> [img]<https://www.siptrunk.com> [img]<https://www.flowroute.com> NOTE: This e-mail and any attachments are from BCM One, Inc. and are intended solely for the use and review of the individual(s) to whom it is addressed. If you believe you received this e-mail in error, please notify the sender immediately, delete the e-mail (and any attachments) from your computer and do not copy or disclose it to anyone else.

2 3

Having issues with compilation of evapi module and evapi_async_relay functions
by Steve Lim 02 May '25

02 May '25

Hello, We're trying to compile the evapi module. Tested on an upgraded 5.8.6 install as well as a new 6.0.1 install. tm module is loaded (for async), but our issues seem to run deeper. evapi_relay and evapi_async_relay are both not found by the core loader as per load failure (same pattern for evapi_async_relay, ommited for brevity) : 0(21496) DEBUG: <core> [core/sr_module.c:766]: find_mod_export_record(): export of <evapi_relay> not found (flags 1) 0(21496) DEBUG: <core> [core/sr_module.c:766]: find_mod_export_record(): export of <evapi_relay> not found (flags 0) 0(21496) ERROR: <core> [core/cfg.y:3877]: yyparse(): cfg. parser: failed to find command evapi_relay (params 2) 0(21496) CRITICAL: <core> [core/cfg.y:4018]: yyerror_at(): parse error in config file /etc/kamailio/kamailio.cfg, line 111, column 43: unknown command, missing loadmodule? earlier up, we're able to set the bind_addr parameter, so it appears that kamailio does recognize the module (and would fail anyways if it didn't since it's supposed to be loaded) 0(21496) DEBUG: <core> [core/modparam.c:112]: set_mod_param_regex(): 'evapi' matches module 'evapi' 0(21496) DEBUG: <core> [core/sr_module.c:852]: find_param_export(): found <bind_addr> in module evapi [/usr/local/lib64/kamailio/modules/evapi.so] 0(21496) DEBUG: <core> [core/modparam.c:135]: set_mod_param_regex(): found <bind_addr> in module evapi [/usr/local/lib64/kamailio/modules/evapi.so] quick look with nm shows that evapi_relay is exported, but evapi_async_relay isn't. root@kamailio-devel:~# nm -D /usr/local/lib64/kamailio/modules/evapi.so | grep relay 0000000000011dd7 T _evapi_relay 0000000000013b3f T evapi_relay 0000000000013b63 T evapi_relay_multicast 0000000000013b8d T evapi_relay_unicast What am I missing out here? Why can't I we get to the evapi_relay exported function and why isn't evapi_async_relay even showing up as exported? Thanks!

1 1

WebRTC error NS_ERROR_NET_TIMEOUT
by David Cunningham 01 May '25

01 May '25

Hello, Does anyone know of a reason (besides the obvious like network down) why users might experience a NS_ERROR_NET_TIMEOUT error in their browser when connecting to WebRTC port 8443 on Kamailio (version 5.2.7)? This only happens intermittently, so debugging it is tricky. The number of connections to Kamailio port 8443 peaks at around 4150 daily. The max open files ulimit in Linux is 65535, and in the Kamailio configuration we have "tcp_max_connections=32768" and "tls_max_connections=32000". Would anyone have any suggestions on where the problem might be? Thanks in advance! -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

2 2

Looking for Documentation/Guidance to Setup Kamailio and RTPProxy to Terminate Encryption for Asterisk
by Joshua Ruehlig 30 Apr '25

30 Apr '25

Hello, I am fairly new to SIP and just recently setup Asterisk for a few purposes. 1) To have my Hikvision doorbell videocall my phone when someone presses it 2) Videocalling between me and my families' phones/tablets 3) Eventually have a home phone setup for POTS calling. I currently have an ObiHai202 that is still working with GoogleVoice, so this not a priority at the moment. I wanted to have encryption for SIP and RTP outside of my network, but wanted this to all be terminated on my OPNsense router. I can install Kamailio and RTPProxy on OPNsense since they are available for FreeBSD, but it looks like Rtpengine is currently not ported. Ideally I wanted most logic to be handled on my Asterisk server, and have Kamailio/RTPProxy do the bare minimum of encrypting/decryption and rewriting headers as needed. ## Diagram of my Targeted Setup ## * Android Phones / Tablets running Linphone || SIPS(TLS) / SRTP || * OPNsense Router ~ WAN_IP(dynamic)=DOMAIN.com / LAN_IP=10.0.1.1 - Kamailio / RTPProxy || SIP(UDP) / RTP || * FreeBSD Application Server ~ LAN_IP=10.0.1.17 / Internal_IP=192.168.10.17 - Asterisk || SIP(UDP) / RTP || * Hikvision Doorbell ~ Internal_IP=192.168.10.100 #### From my reading so far I have a few questions... * To setup Kamailio > Asterisk it looks like I need to setup the dispatcher module; I also I may need to write some routing code. Am I correct, that I will need to use the dispatcher module? Will I need to modify the routing code/logic or is the default usually sufficient? * I read RTPProxy does support SRTP, but I don't see any configuration options related to encryption. I assume this is just enabled in Asterisk/Kamailio? * For Asterisk configuration I believe I just need to define the outbound_proxy. But now I am not sure how I can require SRTP between my Linphone clients and RTPProxy, while the leg between RTPProxy and Asterisk is unencrypted RTP? Thanks for any help that is provided!

1 2

Kamailio TLS Listener Not Binding to Port (5061 or 10061)
by steven.muchwe 29 Apr '25

29 Apr '25

Hello Kamailio Community, I’ve been troubleshooting an issue with Kamailio where the TLS listener fails to bind to any specified ports (5061, 10061, etc.), despite valid configurations and certificates. Here’s a summary of my setup and steps taken: 1. *Environment Details*: - Kamailio version: 5.7.4 - OpenSSL version: 3.0.13 - Operating System: Ubuntu (Noble Release) - TLS module (tls.so) is installed and loaded. 2. *Issue Details*: - Configurations validate successfully (config file ok). - OpenSSL works perfectly when testing certificates and keys with s_server, binding to ports (5061 and others). - Kamailio fails to bind TLS listeners (ss -tulnp shows no activity on the specified ports). 3. *Steps Already Taken*: - Simplified TLS configuration (minimal_tls.cfg) with: plaintext listen=tls:10.14.202.39:5061 loadmodule "tls.so" modparam("tls", "certificate", "/home/localtech/vicissl/868a963bc33d5eae.crt") modparam("tls", "private_key", "/home/localtech/vicissl/private.key") - Tested multiple ports (5061, 10061, 15061). - Checked firewall settings (iptables) and confirmed no restrictions. - Rebuilt Kamailio from source and ensured TLS modules are linked to OpenSSL. - Ran Kamailio with maximum debugging (-ddd) to examine logs—no binding-related errors appeared. 4. *Log Excerpts*: (Attach relevant logs showing TLS initialization or lack of binding activity.) 5. *Question*: What additional steps or configurations should I explore to resolve this issue? Could this be a compatibility problem between Kamailio 5.7.4 and OpenSSL 3.0.13? Any guidance or insights would be greatly appreciated! Best regards, Steven Muchwe Njoroge

4 8

Re: SIP Call Drops After 0.32 Seconds – Asterisk on Kubernetes with Kamailio + RTPengine
by airsay＠duck.com 29 Apr '25

29 Apr '25

I will let the more experienced Kamailio folks comment on the technical/Kamailio/RTP modifications that you need to make. The SIP standard requires an ACK to a 200 OK to be sent within that 32 second window. If an ACK is not received, the session is torn down. You would need to do a packet capture to review the Contact header in the SIP and the c: in the SDP. I'm just getting bedded in with SIP, reading Alan B Johnston's "SIP: Understanding the Session Initiation Protocol". Excellent introduction to understanding SIP. Best regards Sent from my iPhone > On 23 Apr 2025, at 16:35, Fernando Lopes via sr-users <sr-users_at_lists.kamailio.org_airsay(a)duck.com> wrote: > > Hello everyone, > I'm running into an issue with SIP calls in my current setup and would really appreciate some help. > > Setup: > I have a machine named sip00 (IP: 192.168.1.75) running Kamailio + RTPengine. > Kamailio is dispatching calls to sip:192.168.1.190:32210;transport=tcp. This IP points to another machine running Asterisk inside a Kubernetes cluster. > RTPengine is configured with an RTP port range of 10000–20000, and my router is set to allow that same range. > > Asterisk Kubernetes Service Configuration: > yaml > Copy > Edit > spec: > ports: > - name: tcp-port > protocol: TCP > port: 5060 > targetPort: 5060 > nodePort: 32210 > - name: udp-port > protocol: UDP > port: 5060 > targetPort: 5060 > nodePort: 32210 > > Problem: > When I initiate a SIP call, the router forwards traffic to Kamailio + RTPengine, which then sends it to the Asterisk server on 192.168.1.190. > Everything seems fine initially, but at exactly 0.32 seconds into the call, Asterisk sends a BYE and no longer responds with 200 OK to the SIP dialog — even though I'm still receiving and sending audio. Then, at around 01:04, I get a 408 Request Timeout. > > Questions: > Do I need to explicitly expose the RTP port range (10000–20000) in the Asterisk Kubernetes service as well? > Why is Asterisk sending a BYE so early if audio is still flowing? > Could it be a signaling timeout or an issue with SIP dialog tracking? > Any help or pointers would be greatly appreciated! > > Thanks in advance! > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users(a)lists.kamailio.org > To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only to the sender!

7 7

[Serusers] Digest Authentication with Tenor DX
by Ashutosh Kumar 29 Apr '25

29 Apr '25

Hi, Does someone have any idea/experience with Quintum DX radius server's support for digest mode authentication. The Access-Request packets sent by SER are getting an error back. Guide. Regards, Ashutosh Kumar Chetu, Inc. Ph : 1(305) 402 6724 - Witin US Ph : 91 120 5323340 - Outside US Fax:1 (305) 832 5987 For more information, please visit http://www.chetu.com

2 1

SIP Call Drops After 0.32 Seconds – Asterisk on Kubernetes with Kamailio + RTPengine
by Fernando Lopes 29 Apr '25

29 Apr '25

Hello everyone, I'm running into an issue with SIP calls in my current setup and would really appreciate some help. Setup: I have a machine named sip00 (IP: 192.168.1.75) running Kamailio + RTPengine. Kamailio is dispatching calls to sip:192.168.1.190:32210;transport=tcp. This IP points to another machine running Asterisk inside a Kubernetes cluster. RTPengine is configured with an RTP port range of 10000–20000, and my router is set to allow that same range. Asterisk Kubernetes Service Configuration: yaml Copy Edit spec: ports: - name: tcp-port protocol: TCP port: 5060 targetPort: 5060 nodePort: 32210 - name: udp-port protocol: UDP port: 5060 targetPort: 5060 nodePort: 32210 Problem: When I initiate a SIP call, the router forwards traffic to Kamailio + RTPengine, which then sends it to the Asterisk server on 192.168.1.190. Everything seems fine initially, but at exactly 0.32 seconds into the call, Asterisk sends a BYE and no longer responds with 200 OK to the SIP dialog — even though I'm still receiving and sending audio. Then, at around 01:04, I get a 408 Request Timeout. Questions: Do I need to explicitly expose the RTP port range (10000–20000) in the Asterisk Kubernetes service as well? Why is Asterisk sending a BYE so early if audio is still flowing? Could it be a signaling timeout or an issue with SIP dialog tracking? Any help or pointers would be greatly appreciated! Thanks in advance!

2 1

← Newer
1
2
3
4
5
6
7
8
9
...
3751
Older →

Jump to page:

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