From razvan at opensips.org Thu Sep 4 08:39:59 2025 From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=) Date: Thu, 4 Sep 2025 11:39:59 +0300 Subject: [OpenSIPS-Users] Event route for timeout cache In-Reply-To: <25ccf346-f46f-44f7-bf73-3332821f4e87@gmail.com> References: <25ccf346-f46f-44f7-bf73-3332821f4e87@gmail.com> Message-ID: <115044f6-35fb-4ab0-9a11-955acbbb1b6f@opensips.org> Indeed, this is currently not supported, but nice to have :). Please open a PR [1] for this, to keep track of it. [1] https://github.com/OpenSIPS/opensips/issues Best regards, Răzvan Crainea OpenSIPS Core Developer / SIPhub CTO http://www.opensips-solutions.com / https://www.siphub.com On 8/31/25 9:32 AM, Ihor Olkhovskyi wrote: > Eric, > > Quickly looking through a code, especially at > > https://github.com/OpenSIPS/opensips/ > blob/617d3339037f7c20581b2998a6913311cfecd5b5/modules/cachedb_local/ > cachedb_local.c#L818, > > there is no mechanism to raise an event in the code. > > Le 29/08/2025 à 17:15, Eric Dev a écrit : >> Hello all, >> >> I have some experience with kamailio and totally new to opensips. >> >> And for some requirements i need to move to opensips. >> >> I found that opensips use the cache_local to provide kamailio htable >> functionnality but i did not found a way in opensips to get notified >> in an event_route  for exemple when a key expires. >> >> So my general question is , is there a way in opensips to store some >> data somewhere with expiring time and get notified (with key and >> value) when the data expires ? >> >> Is there a way to achieve it in opensips ? >> >> Thanks. >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From spce at lard.at Thu Sep 4 16:58:07 2025 From: spce at lard.at (Sipwise Mailinglist) Date: Thu, 4 Sep 2025 18:58:07 +0200 Subject: [OpenSIPS-Users] Variable Manipulation Message-ID: <52e7704e-04dd-40b7-8c85-c656819cfc82@lard.at> Hi guys, I need to add a "Generic number" parameter to an ISUP IAM message. To set the odd/even indicator I need to check the parity of the From number. I would like to check this with an bitwise AND. I cannot use $fU directly for this operation, because it preserves the leading + from the E.164 number. Is there a way to grab the username part without the + or strip the leading + from $fU and write the output to a variable? Thanks in advance, Malte From spce at lard.at Thu Sep 4 17:46:46 2025 From: spce at lard.at (Sipwise Mailinglist) Date: Thu, 4 Sep 2025 19:46:46 +0200 Subject: [OpenSIPS-Users] Variable Manipulation In-Reply-To: <0ccb97d6-7c45-47da-8d1b-59c6895c5f5b@rikrobson.co.uk> References: <52e7704e-04dd-40b7-8c85-c656819cfc82@lard.at> <0ccb97d6-7c45-47da-8d1b-59c6895c5f5b@rikrobson.co.uk> Message-ID: <167617ad-6045-40ab-b032-f6ae3affe0f5@lard.at> Hi Rik, thanks a lot. It works! [ $(fU{s.substr,1,0}{s.int}) & 1 ] Malte On 04/09/2025 19:24, Richard Robson wrote: > Hi, > > Use string manipulation to remove the leading + > > https://www.opensips.org/Documentation/Script-Tran-3-6#toc6 > > Regard, > > Rik > > On 04/09/2025 17:58, Sipwise Mailinglist wrote: >> Hi guys, >> >> I need to add a "Generic number" parameter to an ISUP IAM message. To >> set the odd/even indicator I need to check the parity of the From >> number. >> >> I would like to check this with an bitwise AND. I cannot use $fU >> directly for this operation, because it preserves the leading + from >> the E.164 number. >> >> Is there a way to grab the username part without the + or strip the >> leading + from $fU and write the output to a variable? >> >> >> Thanks in advance, >> >> Malte >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users From medeanwz at gmail.com Sun Sep 7 17:03:53 2025 From: medeanwz at gmail.com (M S) Date: Sun, 7 Sep 2025 19:03:53 +0200 Subject: [OpenSIPS-Users] media_exchange_from_uri Message-ID: Hi list, I am trying to use media_exchange_from_uri to play hold music. I use the sample code from opensips blog: if (has_totag() && is_method("INVITE")) { # catch the on-hold re-invite if(is_audio_on_hold()) { if (media_exchange_from_uri("sip:moh at media.server.ip")) exit; } else { # call has resumed - terminate any ongoing media played media_terminate(); } } But the behaviour is strange. A invite comes to proxy B, rtpproxy is engaged and invite is sent to C A,Aport <=> B,Bport1 - B,Bport2 <=> C,Cport A pressing hold: Invite with a=sendonly is received. With the above configuration, B sends an INVITE (B ip and Bport1) to media.server.ip (D). Media server D responds with 200 OK (D ip and Dport). Opensips B2B sends D,Dport SDP to C (so C expects to receive RTP from D port). While C expects to receive RTP from D directly, D has exchanged SDP with B and therefore sends RTP to B! Why is this happening? Thank you :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From medeanwz at gmail.com Sun Sep 7 18:34:42 2025 From: medeanwz at gmail.com (M S) Date: Sun, 7 Sep 2025 20:34:42 +0200 Subject: [OpenSIPS-Users] media_exchange_from_uri In-Reply-To: References: Message-ID: A(caller) <=> B(opensips) <=> C(callee) B(opensips) <=> D(media server) I tried it with the "callee" leg in media_exchange_from_uri too. technically, the B machine in the middle should send the ip/port of A and D to each other in SDPs to make sure media is direct between A and D - but B to D invite always has the B's ip/port in it. It should be due to something in my script, but what could it be? On Sun, Sep 7, 2025 at 7:03 PM M S wrote: > Hi list, > I am trying to use media_exchange_from_uri to play hold music. I use the > sample code from opensips blog: > > if (has_totag() && is_method("INVITE")) { > # catch the on-hold re-invite > if(is_audio_on_hold()) { > if (media_exchange_from_uri("sip:moh at media.server.ip")) > exit; > } else { > # call has resumed - terminate any ongoing media played > media_terminate(); > } > } > > > But the behaviour is strange. > > A invite comes to proxy B, rtpproxy is engaged and invite is sent to C > > A,Aport <=> B,Bport1 - B,Bport2 <=> C,Cport > > A pressing hold: Invite with a=sendonly is received. With the above configuration, B sends an INVITE (B ip and Bport1) to media.server.ip (D). > > Media server D responds with 200 OK (D ip and Dport). Opensips B2B sends D,Dport SDP to C (so C expects to receive RTP from D port). > > While C expects to receive RTP from D directly, D has exchanged SDP with B and therefore sends RTP to B! > > Why is this happening? > > > Thank you :) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From julian.santer at rolmail.net Mon Sep 8 09:08:40 2025 From: julian.santer at rolmail.net (Julian Santer) Date: Mon, 8 Sep 2025 11:08:40 +0200 Subject: [OpenSIPS-Users] OpenSips 3.4.12 crashes with segfault randomly Message-ID: <109m6e7$12io$1@ciao.gmane.io> Hello everyone! One of our OpenSIPS instances recently started having issues with restarts after seemingly random segfaults. Before, the server was working without any problems for the longest time. It seems, that some kind of, maybe malformed packet or something, is triggering this. These are the OpenSIPs details: version: opensips 3.4.12 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. git revision: 6440465a9 main.c compiled on with gcc 12 I've followed the "OpenSIPS crashes" part of the documentation and have the Logs and Backtraces. I'll attach them below. If someone has some hints on where to find the issue or maybe had something similar, I would appreciate the help 🙂 ... 2025-09-02T18:10:23.618904+02:00 gw-consumer1 kernel: [8579393.594925] opensips[804304]: segfault at 18 ip 00007f019405091a sp 00007ffc5cfcff10 error 4 in tm.so[7f0194017000+46000] likely on CPU 0 (core 0, socket 0) 2025-09-02T18:10:23.618936+02:00 gw-consumer1 kernel: [8579393.594944] Code: 48 8b 05 81 05 03 00 48 8b 00 f6 40 18 08 0f 85 e9 fb ff ff e9 64 fe ff ff 0f 1f 80 00 00 00 00 48 8b 05 59 05 03 00 48 8b 00 40 18 08 0f 85 c9 fb ff ff e9 44 fe ff ff 0f 1f 80 00 00 00 00 2025-09-02T18:10:23.620397+02:00 gw-consumer1 OpenSIPS[804304]: CRITICAL:core:sig_usr: segfault in process pid: 804304, id: 45 2025-09-02T18:10:23.721130+02:00 gw-consumer1 OpenSIPS[804263]: WARNING:core:utimer_ticker: utimer task already scheduled 100 ms ago (now 56230 ms), delaying execution 2025-09-02T18:10:23.752211+02:00 gw-consumer1 OpenSIPS[804259]: INFO:core:handle_sigs: child process 804304 exited by a signal 11 2025-09-02T18:10:23.752324+02:00 gw-consumer1 OpenSIPS[804259]: INFO:core:handle_sigs: core was generated 2025-09-02T18:10:23.752366+02:00 gw-consumer1 OpenSIPS[804259]: INFO:core:handle_sigs: terminating due to SIGCHLD ... Here the short version of the GDB ... Reading symbols from /usr/sbin/opensips... Reading symbols from /usr/lib/debug/.build-id/02/46eb235cd53dad2b8bc1e57cb2e4057daa0af4.debug... warning: Can't open file /dev/zero (deleted) during file-backed mapping note processing [New LWP 804304] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid -f /etc/opensips/opensips.cfg'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f019405091a in retransmission_handler (retr_tl=0x7f0194553ad8) at ./modules/tm/timer.c:313 313 ./modules/tm/timer.c: No such file or directory. ... I tried to look at the source code for Opensips version 3.4.12, but no luck... Here is the full GDB Trace: (gdb) bt full #0 0x00007f019405091a in retransmission_handler (retr_tl=0x7f0194553ad8) at ./modules/tm/timer.c:313 r_buf = 0x7f0194553a90 id = r_buf = id = __FUNCTION__ = "retransmission_handler" __mptr = #1 utimer_routine (uticks=56100000, set=) at ./modules/tm/timer.c:1153 tl = 0x7f0194553ad8 tmp_tl = 0x0 begin = {tv_sec = 1756829423, tv_nsec = 617548290} id = 4 __FUNCTION__ = "utimer_routine" #2 0x0000555ae09ac3a6 in handle_timer_job () at ./timer.c:1006 t = 0x7f01944c9208 l = _ijiffies = 56130000 _ijiffies_extra = 0 __FUNCTION__ = "handle_timer_job" #3 0x0000555ae09ac755 in handle_io (fm=0x7f01981d2538, event_type=1, idx=) at ./timer.c:765 n = -1742920392 __FUNCTION__ = "handle_io" #4 0x0000555ae09ad139 in io_wait_loop_epoll (repeat=, t=, h=) at ./io_wait_loop.h:305 ret = n = r = 1 i = e = ep_event = {events = 2496488960, data = {ptr = 0xe0b17a4c054f8400, fd = 89097216, u32 = 89097216, u64 = 16190856602298844160}} fd = curr_time = error = __FUNCTION__ = "io_wait_loop_epoll" #5 0x0000555ae09ae16d in start_timer_extra_processes (chd_rank=chd_rank at entry=0x555ae0bbd218 ) at ./timer.c:932 i = p_id = ifp_th = {proc_desc = 0x555ae0ad0b8b "Timer handler", flags = 4, type = TYPE_TIMER} __FUNCTION__ = "start_timer_extra_processes" #6 0x0000555ae08fe9e4 in main_loop () at ./main.c:249 startup_done = 0x0 last_check = 0 rc = chd_rank = 41 startup_done = last_check = rc = profiling_handler = {desc = 0x555ae0ab2f98 "_ProfilerStart_child()", on_child_init = 0x555ae0931fb0 <_ProfilerStart_child>, _next = 0x0} __FUNCTION__ = "main_loop" error = #7 main (argc=, argv=) at ./main.c:966 c = r = tmp = 0x7ffc5cfd0e4b "" tmp_len = port = proto = 0 protos_no = options = 0x555ae0ab3260 "f:cCm:M:b:l:n:N:rRvdDFEVhw:t:u:g:p:P:G:W:o:a:k:s:" ret = -1 seed = 1271792197 rfd = procs_no = __FUNCTION__ = "main" Best Regards Benjamin Herbst From benjamin.herbst at konverto.eu Mon Sep 8 06:35:28 2025 From: benjamin.herbst at konverto.eu (Benjamin Herbst) Date: Mon, 8 Sep 2025 08:35:28 +0200 Subject: [OpenSIPS-Users] Segfault after some timer issue Message-ID: <109ltfg$ear$1@ciao.gmane.io> Hello everyone! One of our OpenSIPS instances recently started having issues with restarts after seemingly random segfaults. Before, the server was working without any problems for the longest time. It seems, that some kind of, maybe malformed packet or something, is triggering this. These are the OpenSIPs details: version: opensips 3.4.12 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll, sigio_rt, select. git revision: 6440465a9 main.c compiled on with gcc 12 I've followed the "OpenSIPS crashes" part of the documentation and have the Logs and Backtraces. I'll attach them below. If someone has some hints on where to find the issue or maybe had something similar, I would appreciate the help 🙂 ... 2025-09-02T18:10:23.618904+02:00 gw-consumer1 kernel: [8579393.594925] opensips[804304]: segfault at 18 ip 00007f019405091a sp 00007ffc5cfcff10 error 4 in tm.so[7f0194017000+46000] likely on CPU 0 (core 0, socket 0) 2025-09-02T18:10:23.618936+02:00 gw-consumer1 kernel: [8579393.594944] Code: 48 8b 05 81 05 03 00 48 8b 00 f6 40 18 08 0f 85 e9 fb ff ff e9 64 fe ff ff 0f 1f 80 00 00 00 00 48 8b 05 59 05 03 00 48 8b 00 40 18 08 0f 85 c9 fb ff ff e9 44 fe ff ff 0f 1f 80 00 00 00 00 2025-09-02T18:10:23.620397+02:00 gw-consumer1 OpenSIPS[804304]: CRITICAL:core:sig_usr: segfault in process pid: 804304, id: 45 2025-09-02T18:10:23.721130+02:00 gw-consumer1 OpenSIPS[804263]: WARNING:core:utimer_ticker: utimer task already scheduled 100 ms ago (now 56230 ms), delaying execution 2025-09-02T18:10:23.752211+02:00 gw-consumer1 OpenSIPS[804259]: INFO:core:handle_sigs: child process 804304 exited by a signal 11 2025-09-02T18:10:23.752324+02:00 gw-consumer1 OpenSIPS[804259]: INFO:core:handle_sigs: core was generated 2025-09-02T18:10:23.752366+02:00 gw-consumer1 OpenSIPS[804259]: INFO:core:handle_sigs: terminating due to SIGCHLD ... Here the short version of the GDB ... Reading symbols from /usr/sbin/opensips... Reading symbols from /usr/lib/debug/.build-id/02/46eb235cd53dad2b8bc1e57cb2e4057daa0af4.debug... warning: Can't open file /dev/zero (deleted) during file-backed mapping note processing [New LWP 804304] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid -f /etc/opensips/opensips.cfg'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f019405091a in retransmission_handler (retr_tl=0x7f0194553ad8) at ./modules/tm/timer.c:313 313 ./modules/tm/timer.c: No such file or directory. ... I tried to look at the source code for Opensips version 3.4.12, but no luck... Here is the full GDB Trace: (gdb) bt full #0 0x00007f019405091a in retransmission_handler (retr_tl=0x7f0194553ad8) at ./modules/tm/timer.c:313 r_buf = 0x7f0194553a90 id = r_buf = id = __FUNCTION__ = "retransmission_handler" __mptr = #1 utimer_routine (uticks=56100000, set=) at ./modules/tm/timer.c:1153 tl = 0x7f0194553ad8 tmp_tl = 0x0 begin = {tv_sec = 1756829423, tv_nsec = 617548290} id = 4 __FUNCTION__ = "utimer_routine" #2 0x0000555ae09ac3a6 in handle_timer_job () at ./timer.c:1006 t = 0x7f01944c9208 l = _ijiffies = 56130000 _ijiffies_extra = 0 __FUNCTION__ = "handle_timer_job" #3 0x0000555ae09ac755 in handle_io (fm=0x7f01981d2538, event_type=1, idx=) at ./timer.c:765 n = -1742920392 __FUNCTION__ = "handle_io" #4 0x0000555ae09ad139 in io_wait_loop_epoll (repeat=, t=, h=) at ./io_wait_loop.h:305 ret = n = r = 1 i = e = ep_event = {events = 2496488960, data = {ptr = 0xe0b17a4c054f8400, fd = 89097216, u32 = 89097216, u64 = 16190856602298844160}} fd = curr_time = error = __FUNCTION__ = "io_wait_loop_epoll" #5 0x0000555ae09ae16d in start_timer_extra_processes (chd_rank=chd_rank at entry=0x555ae0bbd218 ) at ./timer.c:932 i = p_id = ifp_th = {proc_desc = 0x555ae0ad0b8b "Timer handler", flags = 4, type = TYPE_TIMER} __FUNCTION__ = "start_timer_extra_processes" #6 0x0000555ae08fe9e4 in main_loop () at ./main.c:249 startup_done = 0x0 last_check = 0 rc = chd_rank = 41 startup_done = last_check = rc = profiling_handler = {desc = 0x555ae0ab2f98 "_ProfilerStart_child()", on_child_init = 0x555ae0931fb0 <_ProfilerStart_child>, _next = 0x0} __FUNCTION__ = "main_loop" error = #7 main (argc=, argv=) at ./main.c:966 c = r = tmp = 0x7ffc5cfd0e4b "" tmp_len = port = proto = 0 protos_no = options = 0x555ae0ab3260 "f:cCm:M:b:l:n:N:rRvdDFEVhw:t:u:g:p:P:G:W:o:a:k:s:" ret = -1 seed = 1271792197 rfd = procs_no = __FUNCTION__ = "main" Best Regards Benjamin Herbst From julian.santer at rolmail.net Mon Sep 8 10:12:29 2025 From: julian.santer at rolmail.net (Julian Santer) Date: Mon, 8 Sep 2025 12:12:29 +0200 Subject: [OpenSIPS-Users] OpenSips 3.4.12 crashes with segfault randomly In-Reply-To: <109m6e7$12io$1@ciao.gmane.io> References: <109m6e7$12io$1@ciao.gmane.io> Message-ID: <109ma5t$kkk$1@ciao.gmane.io> Hello everyone, this issue is a duble of "Segfault after some timer issue" sent from Benjamin Herbst. Kind regards, Julian Santer Am 08.09.25 um 11:08 schrieb Julian Santer via Users: > Hello everyone! > > One of our OpenSIPS instances recently started having issues with > restarts after seemingly random segfaults. Before, the server was > working without any problems for the longest time. > It seems, that some kind of, maybe malformed packet or something, is > triggering this. > > These are the OpenSIPs details: > > version: opensips 3.4.12 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > poll method support: poll, epoll, sigio_rt, select. > git revision: 6440465a9 > main.c compiled on with gcc 12 > > > I've followed the "OpenSIPS crashes" part of the documentation and have > the Logs and Backtraces. I'll attach them below. > > If someone has some hints on where to find the issue or maybe had > something similar, I would appreciate the help 🙂 > > > ... > 2025-09-02T18:10:23.618904+02:00 gw-consumer1 kernel: [8579393.594925] > opensips[804304]: segfault at 18 ip 00007f019405091a sp 00007ffc5cfcff10 > error 4 in tm.so[7f0194017000+46000] likely on CPU 0 (core 0, > socket 0) > 2025-09-02T18:10:23.618936+02:00 gw-consumer1 kernel: [8579393.594944] > Code: 48 8b 05 81 05 03 00 48 8b 00 f6 40 18 08 0f 85 e9 fb ff ff e9 64 > fe ff ff 0f 1f 80 00 00 00 00 48 8b 05 59 05 03 00 48 8b 00 6> 40 18 08 0f 85 c9 fb ff ff e9 44 fe ff ff 0f 1f 80 00 00 00 00 > 2025-09-02T18:10:23.620397+02:00 gw-consumer1 OpenSIPS[804304]: > CRITICAL:core:sig_usr: segfault in process pid: 804304, id: 45 > 2025-09-02T18:10:23.721130+02:00 gw-consumer1 OpenSIPS[804263]: > WARNING:core:utimer_ticker: utimer task already scheduled > 100 ms ago (now 56230 ms), delaying execution > 2025-09-02T18:10:23.752211+02:00 gw-consumer1 OpenSIPS[804259]: > INFO:core:handle_sigs: child process 804304 exited by a signal 11 > 2025-09-02T18:10:23.752324+02:00 gw-consumer1 OpenSIPS[804259]: > INFO:core:handle_sigs: core was generated > 2025-09-02T18:10:23.752366+02:00 gw-consumer1 OpenSIPS[804259]: > INFO:core:handle_sigs: terminating due to SIGCHLD > ... > > > Here the short version of the GDB > > ... > Reading symbols from /usr/sbin/opensips... > Reading symbols from /usr/lib/debug/.build- > id/02/46eb235cd53dad2b8bc1e57cb2e4057daa0af4.debug... > > warning: Can't open file /dev/zero (deleted) during file-backed mapping > note processing > [New LWP 804304] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid > -f /etc/opensips/opensips.cfg'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00007f019405091a in retransmission_handler (retr_tl=0x7f0194553ad8) > at ./modules/tm/timer.c:313 > 313 ./modules/tm/timer.c: No such file or directory. > ... > > I tried to look at the source code for Opensips version 3.4.12, but no > luck... > > > Here is the full GDB Trace: > > > (gdb) bt full > #0 0x00007f019405091a in retransmission_handler (retr_tl=0x7f0194553ad8) > at ./modules/tm/timer.c:313 > r_buf = 0x7f0194553a90 > id = > r_buf = > id = > __FUNCTION__ = "retransmission_handler" > __mptr = > #1 utimer_routine (uticks=56100000, set=) at ./modules/ > tm/timer.c:1153 > tl = 0x7f0194553ad8 > tmp_tl = 0x0 > begin = {tv_sec = 1756829423, tv_nsec = 617548290} > id = 4 > __FUNCTION__ = "utimer_routine" > #2 0x0000555ae09ac3a6 in handle_timer_job () at ./timer.c:1006 > t = 0x7f01944c9208 > l = > _ijiffies = 56130000 > _ijiffies_extra = 0 > __FUNCTION__ = "handle_timer_job" > #3 0x0000555ae09ac755 in handle_io (fm=0x7f01981d2538, event_type=1, > idx=) at ./timer.c:765 > n = -1742920392 > __FUNCTION__ = "handle_io" > #4 0x0000555ae09ad139 in io_wait_loop_epoll (repeat=, > t=, h=) at ./io_wait_loop.h:305 > ret = > n = > r = 1 > i = > e = > ep_event = {events = 2496488960, data = {ptr = 0xe0b17a4c054f8400, fd = > 89097216, u32 = 89097216, u64 = 16190856602298844160}} > fd = > curr_time = > error = > __FUNCTION__ = "io_wait_loop_epoll" > #5 0x0000555ae09ae16d in start_timer_extra_processes > (chd_rank=chd_rank at entry=0x555ae0bbd218 ) at ./timer.c:932 > i = > p_id = > ifp_th = {proc_desc = 0x555ae0ad0b8b "Timer handler", flags = 4, type = > TYPE_TIMER} > __FUNCTION__ = "start_timer_extra_processes" > #6 0x0000555ae08fe9e4 in main_loop () at ./main.c:249 > startup_done = 0x0 > last_check = 0 > rc = > chd_rank = 41 > startup_done = > last_check = > rc = > profiling_handler = {desc = 0x555ae0ab2f98 "_ProfilerStart_child()", > on_child_init = 0x555ae0931fb0 <_ProfilerStart_child>, _next = 0x0} > __FUNCTION__ = "main_loop" > error = > #7 main (argc=, argv=) at ./main.c:966 > c = > r = > tmp = 0x7ffc5cfd0e4b "" > tmp_len = > port = > proto = 0 > protos_no = > options = 0x555ae0ab3260 > "f:cCm:M:b:l:n:N:rRvdDFEVhw:t:u:g:p:P:G:W:o:a:k:s:" > ret = -1 > seed = 1271792197 > rfd = > procs_no = > __FUNCTION__ = "main" > > > Best Regards > Benjamin Herbst > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From medeanwz at gmail.com Mon Sep 8 11:02:31 2025 From: medeanwz at gmail.com (M S) Date: Mon, 8 Sep 2025 13:02:31 +0200 Subject: [OpenSIPS-Users] media_exchange_from_uri In-Reply-To: References: Message-ID: For anyone who comes across this post in future - this is a bug in 3.1 and above (probably when topology hiding is used) which seems to have been fixed in 3.4 A workaround is to keep the SDP from caller or callee and send it as the third variable of media_exchange_from_uri function to establish the connection correctly. On Sun, Sep 7, 2025 at 8:34 PM M S wrote: > A(caller) <=> B(opensips) <=> C(callee) > B(opensips) <=> D(media server) > > I tried it with the "callee" leg in media_exchange_from_uri too. > technically, the B machine in the middle should send the ip/port of A and D > to each other in SDPs to make sure media is direct between A and D - but B > to D invite always has the B's ip/port in it. It should be due to something > in my script, but what could it be? > > On Sun, Sep 7, 2025 at 7:03 PM M S wrote: > >> Hi list, >> I am trying to use media_exchange_from_uri to play hold music. I use the >> sample code from opensips blog: >> >> if (has_totag() && is_method("INVITE")) { >> # catch the on-hold re-invite >> if(is_audio_on_hold()) { >> if (media_exchange_from_uri("sip:moh at media.server.ip")) >> exit; >> } else { >> # call has resumed - terminate any ongoing media played >> media_terminate(); >> } >> } >> >> >> But the behaviour is strange. >> >> A invite comes to proxy B, rtpproxy is engaged and invite is sent to C >> >> A,Aport <=> B,Bport1 - B,Bport2 <=> C,Cport >> >> A pressing hold: Invite with a=sendonly is received. With the above configuration, B sends an INVITE (B ip and Bport1) to media.server.ip (D). >> >> Media server D responds with 200 OK (D ip and Dport). Opensips B2B sends D,Dport SDP to C (so C expects to receive RTP from D port). >> >> While C expects to receive RTP from D directly, D has exchanged SDP with B and therefore sends RTP to B! >> >> Why is this happening? >> >> >> Thank you :) >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From anestis at omninet.gr Sat Sep 13 15:25:36 2025 From: anestis at omninet.gr (Anestis Mavrofyllidis) Date: Sat, 13 Sep 2025 18:25:36 +0300 Subject: [OpenSIPS-Users] SDP Manipulation in Opensips 3.6 Message-ID: An HTML attachment was scrubbed... URL: From manuel.tausendfreund at dtms.de Tue Sep 16 09:23:39 2025 From: manuel.tausendfreund at dtms.de (Manuel Tausendfreund) Date: Tue, 16 Sep 2025 09:23:39 +0000 Subject: [OpenSIPS-Users] Better Example for the Python Mod Message-ID: <7617b6a8fd914e6daa7362b872c19416@dtms.de> Hello, after a Couple from hours with Try an Error. I think we need better Examples for Python Module. ( https://opensips.org/docs/modules/3.4.x/python.html all other docs have the same problem ) First When you try to call a Function with python_exec() python_exec('test_func',$var(optinal)) it should be announced you need 2 Function Parameter ##### Python code def test_func (self, sip, data): ##### sip, for the actual call data, for the optinal data. Second, and from my point of view the the most important Call the sipfunctions --> get_pseudoVar and set_pseudoVar the pseudoVar must be complete as string in the function set. ##### Python code sip.get_pseudoVar('$avp(py_str)') sip.set_pseudoVar('$avp(py_str)', 'test str') ##### And last Return is only number 1 or 0 (when you try a string you get a -1) BR Moppi -------------- next part -------------- An HTML attachment was scrubbed... URL: From julian.santer at rolmail.net Thu Sep 18 08:45:03 2025 From: julian.santer at rolmail.net (Julian Santer) Date: Thu, 18 Sep 2025 10:45:03 +0200 Subject: [OpenSIPS-Users] Segfault after some timer issue In-Reply-To: <109ltfg$ear$1@ciao.gmane.io> References: <109ltfg$ear$1@ciao.gmane.io> Message-ID: <10aggq0$6bi$1@ciao.gmane.io> Hello everyone, setting enable_stats to 1 in the tm module solved the issue. Many thanks to Bogdan for the hint. Kind regards, Julian Santer Am 08.09.25 um 08:35 schrieb Benjamin Herbst via Users: > Hello everyone! > > One of our OpenSIPS instances recently started having issues with > restarts after seemingly random segfaults. Before, the server was > working without any problems for the longest time. > It seems, that some kind of, maybe malformed packet or something, is > triggering this. > > These are the OpenSIPs details: > > version: opensips 3.4.12 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT > ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, > MAX_URI_SIZE 1024, BUF_SIZE 65535 > poll method support: poll, epoll, sigio_rt, select. > git revision: 6440465a9 > main.c compiled on with gcc 12 > > > I've followed the "OpenSIPS crashes" part of the documentation and have > the Logs and Backtraces. I'll attach them below. > > If someone has some hints on where to find the issue or maybe had > something similar, I would appreciate the help 🙂 > > > ... > 2025-09-02T18:10:23.618904+02:00 gw-consumer1 kernel: [8579393.594925] > opensips[804304]: segfault at 18 ip 00007f019405091a sp 00007ffc5cfcff10 > error 4 in tm.so[7f0194017000+46000] likely on CPU 0 (core 0, > socket 0) > 2025-09-02T18:10:23.618936+02:00 gw-consumer1 kernel: [8579393.594944] > Code: 48 8b 05 81 05 03 00 48 8b 00 f6 40 18 08 0f 85 e9 fb ff ff e9 64 > fe ff ff 0f 1f 80 00 00 00 00 48 8b 05 59 05 03 00 48 8b 00 6> 40 18 08 0f 85 c9 fb ff ff e9 44 fe ff ff 0f 1f 80 00 00 00 00 > 2025-09-02T18:10:23.620397+02:00 gw-consumer1 OpenSIPS[804304]: > CRITICAL:core:sig_usr: segfault in process pid: 804304, id: 45 > 2025-09-02T18:10:23.721130+02:00 gw-consumer1 OpenSIPS[804263]: > WARNING:core:utimer_ticker: utimer task already scheduled > 100 ms ago (now 56230 ms), delaying execution > 2025-09-02T18:10:23.752211+02:00 gw-consumer1 OpenSIPS[804259]: > INFO:core:handle_sigs: child process 804304 exited by a signal 11 > 2025-09-02T18:10:23.752324+02:00 gw-consumer1 OpenSIPS[804259]: > INFO:core:handle_sigs: core was generated > 2025-09-02T18:10:23.752366+02:00 gw-consumer1 OpenSIPS[804259]: > INFO:core:handle_sigs: terminating due to SIGCHLD > ... > > > Here the short version of the GDB > > ... > Reading symbols from /usr/sbin/opensips... > Reading symbols from /usr/lib/debug/.build- > id/02/46eb235cd53dad2b8bc1e57cb2e4057daa0af4.debug... > > warning: Can't open file /dev/zero (deleted) during file-backed mapping > note processing > [New LWP 804304] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid > -f /etc/opensips/opensips.cfg'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00007f019405091a in retransmission_handler (retr_tl=0x7f0194553ad8) > at ./modules/tm/timer.c:313 > 313 ./modules/tm/timer.c: No such file or directory. > ... > > I tried to look at the source code for Opensips version 3.4.12, but no > luck... > > > Here is the full GDB Trace: > > > (gdb) bt full > #0 0x00007f019405091a in retransmission_handler (retr_tl=0x7f0194553ad8) > at ./modules/tm/timer.c:313 > r_buf = 0x7f0194553a90 > id = > r_buf = > id = > __FUNCTION__ = "retransmission_handler" > __mptr = > #1 utimer_routine (uticks=56100000, set=) at ./modules/ > tm/timer.c:1153 > tl = 0x7f0194553ad8 > tmp_tl = 0x0 > begin = {tv_sec = 1756829423, tv_nsec = 617548290} > id = 4 > __FUNCTION__ = "utimer_routine" > #2 0x0000555ae09ac3a6 in handle_timer_job () at ./timer.c:1006 > t = 0x7f01944c9208 > l = > _ijiffies = 56130000 > _ijiffies_extra = 0 > __FUNCTION__ = "handle_timer_job" > #3 0x0000555ae09ac755 in handle_io (fm=0x7f01981d2538, event_type=1, > idx=) at ./timer.c:765 > n = -1742920392 > __FUNCTION__ = "handle_io" > #4 0x0000555ae09ad139 in io_wait_loop_epoll (repeat=, > t=, h=) at ./io_wait_loop.h:305 > ret = > n = > r = 1 > i = > e = > ep_event = {events = 2496488960, data = {ptr = 0xe0b17a4c054f8400, fd = > 89097216, u32 = 89097216, u64 = 16190856602298844160}} > fd = > curr_time = > error = > __FUNCTION__ = "io_wait_loop_epoll" > #5 0x0000555ae09ae16d in start_timer_extra_processes > (chd_rank=chd_rank at entry=0x555ae0bbd218 ) at ./timer.c:932 > i = > p_id = > ifp_th = {proc_desc = 0x555ae0ad0b8b "Timer handler", flags = 4, type = > TYPE_TIMER} > __FUNCTION__ = "start_timer_extra_processes" > #6 0x0000555ae08fe9e4 in main_loop () at ./main.c:249 > startup_done = 0x0 > last_check = 0 > rc = > chd_rank = 41 > startup_done = > last_check = > rc = > profiling_handler = {desc = 0x555ae0ab2f98 "_ProfilerStart_child()", > on_child_init = 0x555ae0931fb0 <_ProfilerStart_child>, _next = 0x0} > __FUNCTION__ = "main_loop" > error = > #7 main (argc=, argv=) at ./main.c:966 > c = > r = > tmp = 0x7ffc5cfd0e4b "" > tmp_len = > port = > proto = 0 > protos_no = > options = 0x555ae0ab3260 > "f:cCm:M:b:l:n:N:rRvdDFEVhw:t:u:g:p:P:G:W:o:a:k:s:" > ret = -1 > seed = 1271792197 > rfd = > procs_no = > __FUNCTION__ = "main" > > > Best Regards > Benjamin Herbst > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From spce at lard.at Thu Sep 18 14:44:01 2025 From: spce at lard.at (Sipwise Mailinglist) Date: Thu, 18 Sep 2025 16:44:01 +0200 Subject: [OpenSIPS-Users] add_isup_part for locally generated replies Message-ID: Hi, is it possible to add an ISUP part to a locally generated reply? I am trying to do so for a test case. t_reply(500,"Internal Server Error"); add_isup_part("REL"); $isup_param(Cause indicators | Location) =5; $isup_param(Cause indicators | Coding standard) =0; $isup_param(Cause indicators | Cause value) =87; Output: DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:core:parse_headers: flags=ffffffffffffffff Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:core:parse_headers: flags=78 Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:tm:t_lookup_request: start searching: hash=17848, isACK=0 Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:tm:matching_3261: RFC3261 transaction matching failed Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:tm:t_lookup_request: no transaction found Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:core:parse_to_param: tag=5F0F57F8-68CC1909000E1991-313F66C0 Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:core:parse_to_param: end of header reached, state=11 Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:core:_parse_to: end of header reached, state=29 Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:core:_parse_to: display={"+xxx"}, ruri={sip:+xxx at sip.xxx.at;user=phone} Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:tm:run_any_trans_callbacks: trans=0x7feb50127638, callback type 1, id 0 entered Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:core:parse_headers: flags=ffffffffffffffff Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:tm:_reply_light: reply sent out. buf=0x7feb53e76fb8: SIP/2.0 1..., shmem=0x7feb5012abd0: SIP/2.0 1 Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:tm:_reply_light: finished Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:core:MD5StringArray: MD5 calculated: 5da55ba68866cceb8fea7af41a440fc9 Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:core:parse_headers: flags=ffffffffffffffff Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:tm:cleanup_uac_timers: RETR/FR timers reset Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:tm:set_timer: relative timeout is 500000 Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:tm:insert_timer_unsafe: [4]: 0x7feb50127780 (3000000) Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:tm:insert_timer_unsafe: [0]: 0x7feb501277b0 (7) Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:tm:_reply_light: reply sent out. buf=0x7feb53e76fb8: SIP/2.0 5..., shmem=0x7feb5012abd0: SIP/2.0 5 Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:tm:_reply_light: finished Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: INFO:sip_i:init_rel_default: Unable to map Cause indicators from SIP by default Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: INFO:sip_i:add_isup_part_cmd: Unable to set all Release message parameters by default Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: DBG:core:add_body_part: adding mime , hdrs , body=<> Thanks, Malte -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Mon Sep 22 10:57:11 2025 From: razvan at opensips.org (=?UTF-8?Q?R=C4=83zvan_Crainea?=) Date: Mon, 22 Sep 2025 13:57:11 +0300 Subject: [OpenSIPS-Users] add_isup_part for locally generated replies In-Reply-To: References: Message-ID: <15a9ffa6-f488-4fa0-afd7-fa54ecc2aff8@opensips.org> Hi, Malte! I don't think this is currently supported, as the body should have been attached to the t_reply_with_body() [1] function, but I am not sure you can grab the isup body to attach it to the message. Please open a feature request for this [2]. [1] https://opensips.org/docs/modules/3.6.x/tm.html#func_t_reply_with_body [2] https://github.com/OpenSIPS/opensips/issues Best regards, Răzvan Crainea OpenSIPS Core Developer / SIPhub CTO http://www.opensips-solutions.com / https://www.siphub.com On 9/18/25 5:44 PM, Sipwise Mailinglist wrote: > Hi, > > is it possible to add an ISUP part to a locally generated reply? I am > trying to do so for a test case. > > t_reply(500,"Internal Server Error"); > add_isup_part("REL"); > $isup_param(Cause indicators | Location) =5; > $isup_param(Cause indicators | Coding standard) =0; > $isup_param(Cause indicators | Cause value) =87; > > Output: > > DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:parse_headers: flags=ffffffffffffffff > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:parse_headers: flags=78 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:t_lookup_request: start searching: hash=17848, isACK=0 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:matching_3261: RFC3261 transaction matching failed > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:t_lookup_request: no transaction found > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:parse_to_param: tag=5F0F57F8-68CC1909000E1991-313F66C0 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:parse_to_param: end of header reached, state=11 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:_parse_to: end of header reached, state=29 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:_parse_to: display={"+xxx"}, ruri={sip:+xxx at sip.xxx.at;user=phone} > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:run_any_trans_callbacks: trans=0x7feb50127638, callback type 1, > id 0 entered > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:parse_headers: flags=ffffffffffffffff > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:_reply_light: reply sent out. buf=0x7feb53e76fb8: SIP/2.0 1..., > shmem=0x7feb5012abd0: SIP/2.0 1 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:_reply_light: finished > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:MD5StringArray: MD5 calculated: 5da55ba68866cceb8fea7af41a440fc9 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:parse_headers: flags=ffffffffffffffff > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:cleanup_uac_timers: RETR/FR timers reset > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:set_timer: relative timeout is 500000 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:insert_timer_unsafe: [4]: 0x7feb50127780 (3000000) > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:insert_timer_unsafe: [0]: 0x7feb501277b0 (7) > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:_reply_light: reply sent out. buf=0x7feb53e76fb8: SIP/2.0 5..., > shmem=0x7feb5012abd0: SIP/2.0 5 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:_reply_light: finished > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > INFO:sip_i:init_rel_default: Unable to map Cause indicators from SIP by > default > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > INFO:sip_i:add_isup_part_cmd: Unable to set all Release message > parameters by default > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:add_body_part: adding mime , > hdrs > , body=<> > > Thanks, > > Malte > > Hi, > > is it possible to add an ISUP part to a locally generated reply? I am > trying to do so for a test case. > > t_reply(500,"Internal Server Error"); > add_isup_part("REL"); > $isup_param(Cause indicators | Location) =5; > $isup_param(Cause indicators | Coding standard) =0; > $isup_param(Cause indicators | Cause value) =87; > > Output: > > DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:parse_headers: flags=ffffffffffffffff > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:parse_headers: flags=78 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:t_lookup_request: start searching: hash=17848, isACK=0 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:matching_3261: RFC3261 transaction matching failed > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:t_lookup_request: no transaction found > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:parse_to_param: tag=5F0F57F8-68CC1909000E1991-313F66C0 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:parse_to_param: end of header reached, state=11 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:_parse_to: end of header reached, state=29 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:_parse_to: display={"+xxx"}, ruri={sip:+xxx at sip.xxx.at;user=phone} > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:run_any_trans_callbacks: trans=0x7feb50127638, callback type 1, > id 0 entered > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:parse_headers: flags=ffffffffffffffff > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:_reply_light: reply sent out. buf=0x7feb53e76fb8: SIP/2.0 1..., > shmem=0x7feb5012abd0: SIP/2.0 1 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:_reply_light: finished > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:MD5StringArray: MD5 calculated: 5da55ba68866cceb8fea7af41a440fc9 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:parse_headers: flags=ffffffffffffffff > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:cleanup_uac_timers: RETR/FR timers reset > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:set_timer: relative timeout is 500000 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:insert_timer_unsafe: [4]: 0x7feb50127780 (3000000) > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:insert_timer_unsafe: [0]: 0x7feb501277b0 (7) > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:_reply_light: reply sent out. buf=0x7feb53e76fb8: SIP/2.0 5..., > shmem=0x7feb5012abd0: SIP/2.0 5 > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:tm:_reply_light: finished > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > INFO:sip_i:init_rel_default: Unable to map Cause indicators from SIP by > default > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > INFO:sip_i:add_isup_part_cmd: Unable to set all Release message > parameters by default > Sep 18 16:36:57 opensips-test /usr/sbin/opensips[92433]: > DBG:core:add_body_part: adding mime , > hdrs >, body=<> > > Thanks, > > Malte > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From prathibhab.tvm at gmail.com Wed Sep 24 12:19:25 2025 From: prathibhab.tvm at gmail.com (bp) Date: Wed, 24 Sep 2025 17:49:25 +0530 Subject: [OpenSIPS-Users] opensip-3.6 hangs at 32 seconds Message-ID: Exactly at 32 seconds after the call is established, the call gets terminated automatically. The same occurs with the latest verion in git. -- Regards, B.Prathibha -------------- next part -------------- An HTML attachment was scrubbed... URL: From alidogan at plan.com Wed Sep 24 12:27:27 2025 From: alidogan at plan.com (Ali Dogan) Date: Wed, 24 Sep 2025 12:27:27 +0000 Subject: [OpenSIPS-Users] opensip-3.6 hangs at 32 seconds In-Reply-To: References: Message-ID: This does seem like SIP Timer issue. Check call flow for missing ACK for 200OK. Ali Dogan +44(0)3300 88 18 18 alidogan at plan.com plan.com is the trading name of Plan Communications Limited, registered in the Isle of Man with company number 010273V and Registered Office at No.5 Victoria Street, Douglas, Isle of Man, IM1 2LR. This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Plan. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. ________________________________ From: Users on behalf of bp Sent: Wednesday, September 24, 2025 15:19 To: OpenSIPS users mailling list Subject: [OpenSIPS-Users] opensip-3.6 hangs at 32 seconds This message was sent from outside plan.com. Please do not click links or open attachments unless you recognise the source of this email and know the content is safe. Exactly at 32 seconds after the call is established, the call gets terminated automatically. The same occurs with the latest verion in git. -- Regards, B.Prathibha -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.bieuzent at free.fr Wed Sep 24 12:55:33 2025 From: alain.bieuzent at free.fr (Alain Bieuzent) Date: Wed, 24 Sep 2025 14:55:33 +0200 Subject: [OpenSIPS-Users] Replace avp_check() for opensips 3.5 Message-ID: <1F27F0D7-3A3E-417A-858C-4C550E16024B@free.fr> Hello everyone, With version 3.5, the avp_check() function no longer exists and must be replaced. What would be the "cleanest" way to perform the following check: if (avp_check("$avp(codecs)","re/PCMA/g")) { xlog("L_INFO", "$ci|Log codecs|PCMA exist in SDP and in DB - X-CODEC: PCMA"); } Thanks in advance Alain -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Sep 24 13:31:27 2025 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 24 Sep 2025 16:31:27 +0300 Subject: [OpenSIPS-Users] rtp.io module In-Reply-To: References: Message-ID: Hi, Ihor! Yes, rtp.io has no packaging logic at the moment, not being mentioned in either the control or rules files, so it simply gets skipped during the package builds. To fix this, we would need a rtpproxy project clone during the build (git submodule?), then build it as static library flavor (as "librtpproxy.a" file, using --enable-librtpproxy, and not just "rtpproxy" binary).  Then, the rtp.io module would simply build against the ".a" file, finally producing "rtp.io.so".  The rest is history :) Could be worth putting up a feature request for this, it also seems to be a good-first-issue candidate (couple hours of work). Best regards, On 21.08.2025 16:57, Ihor Olkhovskyi wrote: > Hello! > > As I got, in a debian repo there is no rtp.io package? > Or I've missed something? > > -- > Best regards, > Ihor (Igor) > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Liviu Chircu www.opensips-solutions.com |www.siphub.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Sep 24 13:53:19 2025 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 24 Sep 2025 16:53:19 +0300 Subject: [OpenSIPS-Users] SDP Manipulation in Opensips 3.6 In-Reply-To: References: Message-ID: Hi Anestis, In case you haven't solved the problem, surely there has to be a way using pre-3.6 code, try something resembling: $var(sdp) = ${rb(application/sdp){re.subst,/a=ptime:[0-9]*\r\n//g});  -> just sample code, YMMV -- store the RE inside a $var if cfg syntax does not parse this! rtpengine_manage(...., , , $var(sdp)); # pass it the modified SDP buffer, should work just fine Now, with 3.6+, the solution SHOULD look like: $sdp.line(a=ptime) = NULL; # delete the 1st a=ptime found $sdp.stream(audio/a=ptime) = NULL; # more accurate; delete the 1st ptime line found in the 1st audio stream rtpengine_manage(); ... but this hasn't been thoroughly tested yet, such usage combination could could even cause a crash as of now (new SDP changes system + old SDP changes system used together).  I am already working on better management of the $sdp changes during failure_route.  Will also take a look at some more onreply_route usage scenarios afterwards. Best regards, On 13.09.2025 18:25, Anestis Mavrofyllidis wrote: > I have tried the new way: > $sdp.line(a=ptime) = NULL, > Right before the end of the route I can see in the log a correct $sdp; > the $mb is still the initial, before the sdp change. -- Liviu Chircu www.opensips-solutions.com | www.siphub.com From liviu at opensips.org Wed Sep 24 14:01:59 2025 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 24 Sep 2025 17:01:59 +0300 Subject: [OpenSIPS-Users] Replace avp_check() for opensips 3.5 In-Reply-To: <1F27F0D7-3A3E-417A-858C-4C550E16024B@free.fr> References: <1F27F0D7-3A3E-417A-858C-4C550E16024B@free.fr> Message-ID: Hello Alain, I checked the avp_check (ha!) code, and it also seems to be using the "case-insensitive" regex flag.  Which means, the following is the direct equivalent in modern opensips.cfg syntax: if ($avp(codecs) =~ "PCMA") {      xlog("L_INFO", "$ci|Log codecs|PCMA exist in SDP and in DB - X-CODEC: PCMA"); } Case-*insensitive* regex matching, just as before. Best regards, On 24.09.2025 15:55, Alain Bieuzent via Users wrote: > > Hello everyone, > > With version 3.5, the avp_check() function no longer exists and must > be replaced. > > What would be the "cleanest" way to perform the following check: > > if (avp_check("$avp(codecs)","re/PCMA/g")) > > { > > xlog("L_INFO", "$ci|Log codecs|PCMA exist in SDP and in DB - X-CODEC: > PCMA"); > > } > > Thanks in advance > > Alain > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Liviu Chircu www.opensips-solutions.com |www.siphub.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.bieuzent at free.fr Wed Sep 24 14:24:32 2025 From: alain.bieuzent at free.fr (Alain Bieuzent) Date: Wed, 24 Sep 2025 16:24:32 +0200 Subject: [OpenSIPS-Users] Replace avp_check() for opensips 3.5 In-Reply-To: References: <1F27F0D7-3A3E-417A-858C-4C550E16024B@free.fr> Message-ID: <6241ADE5-AC11-4FC5-B17A-6E16A0AE4858@free.fr> Thanks Liviu, The correct way is single or double quotation mark ? Because un documentation it’s written : =~ - regular expression matching (e.g. $rU =~ '^1800*' is "$rU begins with 1800" ) Regards De : Users au nom de Liviu Chircu Répondre à : OpenSIPS users mailling list Date : mercredi 24 septembre 2025 à 16:04 À : Objet : Re: [OpenSIPS-Users] Replace avp_check() for opensips 3.5 Hello Alain, I checked the avp_check (ha!) code, and it also seems to be using the "case-insensitive" regex flag. Which means, the following is the direct equivalent in modern opensips.cfg syntax: if ($avp(codecs) =~ "PCMA") { xlog("L_INFO", "$ci|Log codecs|PCMA exist in SDP and in DB - X-CODEC: PCMA"); } Case-insensitive regex matching, just as before. Best regards, On 24.09.2025 15:55, Alain Bieuzent via Users wrote: Hello everyone, With version 3.5, the avp_check() function no longer exists and must be replaced. What would be the "cleanest" way to perform the following check: if (avp_check("$avp(codecs)","re/PCMA/g")) { xlog("L_INFO", "$ci|Log codecs|PCMA exist in SDP and in DB - X-CODEC: PCMA"); } Thanks in advance Alain _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Liviu Chircu www.opensips-solutions.com | www.siphub.com _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Sep 24 14:41:07 2025 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 24 Sep 2025 17:41:07 +0300 Subject: [OpenSIPS-Users] Replace avp_check() for opensips 3.5 In-Reply-To: <6241ADE5-AC11-4FC5-B17A-6E16A0AE4858@free.fr> References: <1F27F0D7-3A3E-417A-858C-4C550E16024B@free.fr> <6241ADE5-AC11-4FC5-B17A-6E16A0AE4858@free.fr> Message-ID: Unlike in bash... in opensips.cfg there is no difference between double-quote " and single-quote ', they both behave like strings, expand any variables inside, etc. On 24.09.2025 17:24, Alain Bieuzent via Users wrote: > > Thanks Liviu, > > The correct way is single or double quotation mark ? > > Because un documentation it’s written : > > =~ - regular expression matching (e.g. $rU =~ '^1800*' is "$rU begins > with 1800" ) > -- Liviu Chircu www.opensips-solutions.com |www.siphub.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alain.bieuzent at free.fr Wed Sep 24 14:48:20 2025 From: alain.bieuzent at free.fr (Alain Bieuzent) Date: Wed, 24 Sep 2025 16:48:20 +0200 Subject: [OpenSIPS-Users] Replace avp_check() for opensips 3.5 In-Reply-To: References: <1F27F0D7-3A3E-417A-858C-4C550E16024B@free.fr> <6241ADE5-AC11-4FC5-B17A-6E16A0AE4858@free.fr> Message-ID: <56654352-B052-4BC9-8370-295F9EF11026@free.fr> thanks De : Liviu Chircu Date : mercredi 24 septembre 2025 à 16:41 À : Alain Bieuzent , OpenSIPS users mailling list Objet : Re: [OpenSIPS-Users] Replace avp_check() for opensips 3.5 Unlike in bash... in opensips.cfg there is no difference between double-quote " and single-quote ', they both behave like strings, expand any variables inside, etc. On 24.09.2025 17:24, Alain Bieuzent via Users wrote: Thanks Liviu, The correct way is single or double quotation mark ? Because un documentation it’s written : =~ - regular expression matching (e.g. $rU =~ '^1800*' is "$rU begins with 1800" ) -- Liviu Chircu www.opensips-solutions.com | www.siphub.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From prathibhab.tvm at gmail.com Thu Sep 25 01:35:12 2025 From: prathibhab.tvm at gmail.com (bp) Date: Thu, 25 Sep 2025 07:05:12 +0530 Subject: [OpenSIPS-Users] opensip-3.6 hangs at 32 seconds In-Reply-To: References: Message-ID: sngrep shows empty output. On Wed, 24 Sept 2025 at 18:01, Ali Dogan wrote: > This does seem like SIP Timer issue. Check call flow for missing ACK for > 200OK. > > > Ali Dogan > [image: plan.com] > +44(0)3300 88 18 18 <+44(0)3300%2088%2018%2018> > alidogan at plan.com > [image: Facebook] [image: Instagram] > [image: LinkedIn] > > plan.com is the trading name of Plan > Communications Limited, registered in the Isle of Man with company number > 010273V and Registered Office at No.5 Victoria Street, Douglas, Isle of > Man, IM1 2LR. This email and any attachments to it may be confidential and > are intended solely for the use of the individual to whom it is addressed. > Any views or opinions expressed are solely those of the author and do not > necessarily represent those of Plan. If you are not the intended recipient > of this email, you must neither take any action based upon its contents, > nor copy or show it to anyone. Please contact the sender if you believe you > have received this email in error. > ​​​​ > ------------------------------ > *From:* Users on behalf of bp < > prathibhab.tvm at gmail.com> > *Sent:* Wednesday, September 24, 2025 15:19 > *To:* OpenSIPS users mailling list > *Subject:* [OpenSIPS-Users] opensip-3.6 hangs at 32 seconds > > This message was sent from outside plan.com. Please do not click links or > open attachments unless you recognise the source of this email and know the > content is safe. > > Exactly at 32 seconds after the call is established, the call gets > terminated automatically. > > The same occurs with the latest verion in git. > -- > Regards, > B.Prathibha > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, B.Prathibha -------------- next part -------------- An HTML attachment was scrubbed... URL: From prathibhab.tvm at gmail.com Fri Sep 26 07:20:48 2025 From: prathibhab.tvm at gmail.com (bp) Date: Fri, 26 Sep 2025 12:50:48 +0530 Subject: [OpenSIPS-Users] opensip-3.6 hangs at 32 seconds In-Reply-To: References: Message-ID: ERROR:core:tcp_connect_blocking_timeout: connect timed out, 299521 us elapsed out of 300000 us ERROR:proto_wss:ws_sync_connect: tcp_blocking_connect failed ERROR:proto_wss:ws_connect: connect failed ERROR:proto_wss:proto_wss_send: connect failed On Thu, 25 Sept 2025 at 07:05, bp wrote: > sngrep shows empty output. > > On Wed, 24 Sept 2025 at 18:01, Ali Dogan wrote: > >> This does seem like SIP Timer issue. Check call flow for missing ACK for >> 200OK. >> >> >> Ali Dogan >> [image: plan.com] >> +44(0)3300 88 18 18 <+44(0)3300%2088%2018%2018> >> alidogan at plan.com >> [image: Facebook] [image: Instagram] >> [image: LinkedIn] >> >> plan.com is the trading name of Plan >> Communications Limited, registered in the Isle of Man with company number >> 010273V and Registered Office at No.5 Victoria Street, Douglas, Isle of >> Man, IM1 2LR. This email and any attachments to it may be confidential and >> are intended solely for the use of the individual to whom it is addressed. >> Any views or opinions expressed are solely those of the author and do not >> necessarily represent those of Plan. If you are not the intended recipient >> of this email, you must neither take any action based upon its contents, >> nor copy or show it to anyone. Please contact the sender if you believe you >> have received this email in error. >> ​​​​ >> ------------------------------ >> *From:* Users on behalf of bp < >> prathibhab.tvm at gmail.com> >> *Sent:* Wednesday, September 24, 2025 15:19 >> *To:* OpenSIPS users mailling list >> *Subject:* [OpenSIPS-Users] opensip-3.6 hangs at 32 seconds >> >> This message was sent from outside plan.com. Please do not click links >> or open attachments unless you recognise the source of this email and know >> the content is safe. >> >> Exactly at 32 seconds after the call is established, the call gets >> terminated automatically. >> >> The same occurs with the latest verion in git. >> -- >> Regards, >> B.Prathibha >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > -- > Regards, > B.Prathibha > -- Regards, B.Prathibha -------------- next part -------------- An HTML attachment was scrubbed... URL: From prathibhab.tvm at gmail.com Fri Sep 26 10:49:13 2025 From: prathibhab.tvm at gmail.com (bp) Date: Fri, 26 Sep 2025 16:19:13 +0530 Subject: [OpenSIPS-Users] opensip-3.6 hangs at 32 seconds In-Reply-To: References: Message-ID: Added fix_nated_contact(); in on_reply_route On Fri, 26 Sept 2025 at 12:50, bp wrote: > ERROR:core:tcp_connect_blocking_timeout: connect timed out, 299521 us > elapsed out of 300000 us > ERROR:proto_wss:ws_sync_connect: tcp_blocking_connect failed > ERROR:proto_wss:ws_connect: connect failed > ERROR:proto_wss:proto_wss_send: connect failed > > On Thu, 25 Sept 2025 at 07:05, bp wrote: > >> sngrep shows empty output. >> >> On Wed, 24 Sept 2025 at 18:01, Ali Dogan wrote: >> >>> This does seem like SIP Timer issue. Check call flow for missing ACK for >>> 200OK. >>> >>> >>> Ali Dogan >>> [image: plan.com] >>> +44(0)3300 88 18 18 <+44(0)3300%2088%2018%2018> >>> alidogan at plan.com >>> [image: Facebook] [image: Instagram] >>> [image: LinkedIn] >>> >>> plan.com is the trading name of Plan >>> Communications Limited, registered in the Isle of Man with company number >>> 010273V and Registered Office at No.5 Victoria Street, Douglas, Isle of >>> Man, IM1 2LR. This email and any attachments to it may be confidential and >>> are intended solely for the use of the individual to whom it is addressed. >>> Any views or opinions expressed are solely those of the author and do not >>> necessarily represent those of Plan. If you are not the intended recipient >>> of this email, you must neither take any action based upon its contents, >>> nor copy or show it to anyone. Please contact the sender if you believe you >>> have received this email in error. >>> ​​​​ >>> ------------------------------ >>> *From:* Users on behalf of bp < >>> prathibhab.tvm at gmail.com> >>> *Sent:* Wednesday, September 24, 2025 15:19 >>> *To:* OpenSIPS users mailling list >>> *Subject:* [OpenSIPS-Users] opensip-3.6 hangs at 32 seconds >>> >>> This message was sent from outside plan.com. Please do not click links >>> or open attachments unless you recognise the source of this email and know >>> the content is safe. >>> >>> Exactly at 32 seconds after the call is established, the call gets >>> terminated automatically. >>> >>> The same occurs with the latest verion in git. >>> -- >>> Regards, >>> B.Prathibha >>> _______________________________________________ >>> Users mailing list >>> Users at lists.opensips.org >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> >> -- >> Regards, >> B.Prathibha >> > > > -- > Regards, > B.Prathibha > -- Regards, B.Prathibha -------------- next part -------------- An HTML attachment was scrubbed... URL: From prathibhab.tvm at gmail.com Fri Sep 26 11:18:37 2025 From: prathibhab.tvm at gmail.com (bp) Date: Fri, 26 Sep 2025 16:48:37 +0530 Subject: [OpenSIPS-Users] opensip-3.6 hangs at 32 seconds In-Reply-To: References: Message-ID: I was in video call for 5 minutes. When user1 terminated the call, it didn't end for user2. On Fri, 26 Sept 2025 at 16:19, bp wrote: > Added > > fix_nated_contact(); > > in on_reply_route > > On Fri, 26 Sept 2025 at 12:50, bp wrote: > >> ERROR:core:tcp_connect_blocking_timeout: connect timed out, 299521 us >> elapsed out of 300000 us >> ERROR:proto_wss:ws_sync_connect: tcp_blocking_connect failed >> ERROR:proto_wss:ws_connect: connect failed >> ERROR:proto_wss:proto_wss_send: connect failed >> >> On Thu, 25 Sept 2025 at 07:05, bp wrote: >> >>> sngrep shows empty output. >>> >>> On Wed, 24 Sept 2025 at 18:01, Ali Dogan wrote: >>> >>>> This does seem like SIP Timer issue. Check call flow for missing ACK >>>> for 200OK. >>>> >>>> >>>> Ali Dogan >>>> [image: plan.com] >>>> +44(0)3300 88 18 18 <+44(0)3300%2088%2018%2018> >>>> alidogan at plan.com >>>> [image: Facebook] [image: Instagram] >>>> [image: LinkedIn] >>>> >>>> plan.com is the trading name of Plan >>>> Communications Limited, registered in the Isle of Man with company number >>>> 010273V and Registered Office at No.5 Victoria Street, Douglas, Isle of >>>> Man, IM1 2LR. This email and any attachments to it may be confidential and >>>> are intended solely for the use of the individual to whom it is addressed. >>>> Any views or opinions expressed are solely those of the author and do not >>>> necessarily represent those of Plan. If you are not the intended recipient >>>> of this email, you must neither take any action based upon its contents, >>>> nor copy or show it to anyone. Please contact the sender if you believe you >>>> have received this email in error. >>>> ​​​​ >>>> ------------------------------ >>>> *From:* Users on behalf of bp < >>>> prathibhab.tvm at gmail.com> >>>> *Sent:* Wednesday, September 24, 2025 15:19 >>>> *To:* OpenSIPS users mailling list >>>> *Subject:* [OpenSIPS-Users] opensip-3.6 hangs at 32 seconds >>>> >>>> This message was sent from outside plan.com. Please do not click links >>>> or open attachments unless you recognise the source of this email and know >>>> the content is safe. >>>> >>>> Exactly at 32 seconds after the call is established, the call gets >>>> terminated automatically. >>>> >>>> The same occurs with the latest verion in git. >>>> -- >>>> Regards, >>>> B.Prathibha >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.opensips.org >>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>> >>> >>> >>> -- >>> Regards, >>> B.Prathibha >>> >> >> >> -- >> Regards, >> B.Prathibha >> > > > -- > Regards, > B.Prathibha > -- Regards, B.Prathibha -------------- next part -------------- An HTML attachment was scrubbed... URL: From prathibhab.tvm at gmail.com Fri Sep 26 11:32:55 2025 From: prathibhab.tvm at gmail.com (bp) Date: Fri, 26 Sep 2025 17:02:55 +0530 Subject: [OpenSIPS-Users] opensip-3.6 hangs at 32 seconds In-Reply-To: References: Message-ID: If I end the call without 1 minut there is no issue. On Fri, 26 Sept 2025 at 16:48, bp wrote: > I was in video call for 5 minutes. When user1 terminated the call, it > didn't end for user2. > > On Fri, 26 Sept 2025 at 16:19, bp wrote: > >> Added >> >> fix_nated_contact(); >> >> in on_reply_route >> >> On Fri, 26 Sept 2025 at 12:50, bp wrote: >> >>> ERROR:core:tcp_connect_blocking_timeout: connect timed out, 299521 us >>> elapsed out of 300000 us >>> ERROR:proto_wss:ws_sync_connect: tcp_blocking_connect failed >>> ERROR:proto_wss:ws_connect: connect failed >>> ERROR:proto_wss:proto_wss_send: connect failed >>> >>> On Thu, 25 Sept 2025 at 07:05, bp wrote: >>> >>>> sngrep shows empty output. >>>> >>>> On Wed, 24 Sept 2025 at 18:01, Ali Dogan wrote: >>>> >>>>> This does seem like SIP Timer issue. Check call flow for missing ACK >>>>> for 200OK. >>>>> >>>>> >>>>> Ali Dogan >>>>> [image: plan.com] >>>>> +44(0)3300 88 18 18 <+44(0)3300%2088%2018%2018> >>>>> alidogan at plan.com >>>>> [image: Facebook] [image: >>>>> Instagram] [image: LinkedIn] >>>>> >>>>> plan.com is the trading name of Plan >>>>> Communications Limited, registered in the Isle of Man with company number >>>>> 010273V and Registered Office at No.5 Victoria Street, Douglas, Isle of >>>>> Man, IM1 2LR. This email and any attachments to it may be confidential and >>>>> are intended solely for the use of the individual to whom it is addressed. >>>>> Any views or opinions expressed are solely those of the author and do not >>>>> necessarily represent those of Plan. If you are not the intended recipient >>>>> of this email, you must neither take any action based upon its contents, >>>>> nor copy or show it to anyone. Please contact the sender if you believe you >>>>> have received this email in error. >>>>> ​​​​ >>>>> ------------------------------ >>>>> *From:* Users on behalf of bp < >>>>> prathibhab.tvm at gmail.com> >>>>> *Sent:* Wednesday, September 24, 2025 15:19 >>>>> *To:* OpenSIPS users mailling list >>>>> *Subject:* [OpenSIPS-Users] opensip-3.6 hangs at 32 seconds >>>>> >>>>> This message was sent from outside plan.com. Please do not click >>>>> links or open attachments unless you recognise the source of this email and >>>>> know the content is safe. >>>>> >>>>> Exactly at 32 seconds after the call is established, the call gets >>>>> terminated automatically. >>>>> >>>>> The same occurs with the latest verion in git. >>>>> -- >>>>> Regards, >>>>> B.Prathibha >>>>> _______________________________________________ >>>>> Users mailing list >>>>> Users at lists.opensips.org >>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> B.Prathibha >>>> >>> >>> >>> -- >>> Regards, >>> B.Prathibha >>> >> >> >> -- >> Regards, >> B.Prathibha >> > > > -- > Regards, > B.Prathibha > -- Regards, B.Prathibha -------------- next part -------------- An HTML attachment was scrubbed... URL: From medeanwz at gmail.com Fri Sep 26 17:10:51 2025 From: medeanwz at gmail.com (M S) Date: Fri, 26 Sep 2025 19:10:51 +0200 Subject: [OpenSIPS-Users] 3.4 dlg_send_sequential Cseq bug Message-ID: There is a bug in 3.4's dialog or tm module: A ------- B (opensips) ------------ C Call from A to B and then proxied to C. C accepts and answers and acknowledges. 10 seconds later C sends a Re-Invite (Cseq x) A responds with 200 OK (which is proxied to C). As soon as C receives 200 OK, C sends an in-dialog INFO to B (Cseq x+1) B sends INFO to A and receives ACK, ACK is sent to C (Cseq x+1) ~~ At this point, A sends ACK to the reinvite (Cseq was x). B ends this ACK to C with Cseq x+1 which is incorrect. This seems to be caused by Cseq mapping. It did not exist in 3.1. trace: 2025/09/26 16:10:21.361305 1.2.3.4:5060 -> 5.6.7.8:5060 INVITE sip:9.10.11.12;did=33b.ae0baf63 SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4;rport;branch=z9hG4bKBSyUDj3X836DH Route: Max-Forwards: 26 From: "0445566000" ;tag=2m7re1yvj3F5F To: "1112223333" ;tag=wzxe7s9s-CC-1049-OFC-32 Call-ID: ww0q0moisw7zh30z9e9ow7qsoiz3i9s0 CSeq: 104891418 INVITE Contact: User-Agent: FreeSWITCH-mod_sofia/1.10.12-release+git~20240802T210227Z~a88d069d6f~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 222 X-FS-Support: update_display,send_info v=0 o=FreeSWITCH 1758866897 1758866898 IN IP4 1.2.3.4 s=FreeSWITCH c=IN IP4 1.2.3.4 t=0 0 m=audio 23516 RTP/AVP 8 116 a=rtpmap:8 PCMA/8000 a=rtpmap:116 telephone-event/8000 a=fmtp:116 0-15 a=ptime:20 2025/09/26 16:10:21.361421 5.6.7.8:5060 -> 1.2.3.4:5060 SIP/2.0 100 Giving it a try Via: SIP/2.0/UDP 1.2.3.4;received=1.2.3.4;rport=5060;branch=z9hG4bKBSyUDj3X836DH To: "1112223333" ;tag=wzxe7s9s-CC-1049-OFC-32 From: "0445566000" ;tag=2m7re1yvj3F5F Call-ID: ww0q0moisw7zh30z9e9ow7qsoiz3i9s0 CSeq: 104891418 INVITE Content-Length: 0 2025/09/26 16:10:21.361910 5.6.7.8:5060 -> 9.10.11.12:5060 INVITE sip:9.10.11.12;did=33b.ae0baf63 SIP/2.0 Via: SIP/2.0/UDP 5.6.7.8:5060;branch=z9hG4bK5ee.de615a07.0 Via: SIP/2.0/UDP 1.2.3.4;received=1.2.3.4;rport=5060;branch=z9hG4bKBSyUDj3X836DH Max-Forwards: 25 From: "0445566000" ;tag=2m7re1yvj3F5F To: "1112223333" ;tag=wzxe7s9s-CC-1049-OFC-32 Call-ID: ww0q0moisw7zh30z9e9ow7qsoiz3i9s0 CSeq: 5 INVITE Contact: User-Agent: FreeSWITCH-mod_sofia/1.10.12-release+git~20240802T210227Z~a88d069d6f~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: path, replaces Content-Type: application/sdp Content-Disposition: session Content-Length: 222 P-hint: rr-enforced v=0 o=FreeSWITCH 1758866897 1758866898 IN IP4 1.2.3.4 s=FreeSWITCH c=IN IP4 1.2.3.4 t=0 0 m=audio 23516 RTP/AVP 8 116 a=rtpmap:8 PCMA/8000 a=rtpmap:116 telephone-event/8000 a=fmtp:116 0-15 a=ptime:20 2025/09/26 16:10:21.362769 9.10.11.12:5060 -> 5.6.7.8:5060 SIP/2.0 100 Giving it a try Via: SIP/2.0/UDP 5.6.7.8:5060 ;received=5.6.7.8;rport=5060;branch=z9hG4bK5ee.de615a07.0 Via: SIP/2.0/UDP 1.2.3.4;received=1.2.3.4;rport=5060;branch=z9hG4bKBSyUDj3X836DH To: "1112223333" ;tag=wzxe7s9s-CC-1049-OFC-32 From: "0445566000" ;tag=2m7re1yvj3F5F Call-ID: ww0q0moisw7zh30z9e9ow7qsoiz3i9s0 CSeq: 5 INVITE Content-Length: 0 2025/09/26 16:10:21.380894 9.10.11.12:5060 -> 5.6.7.8:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 5.6.7.8:5060 ;received=5.6.7.8;rport=5060;branch=z9hG4bK5ee.de615a07.0 Via: SIP/2.0/UDP 1.2.3.4;received=1.2.3.4;rport=5060;branch=z9hG4bKBSyUDj3X836DH Call-ID: ww0q0moisw7zh30z9e9ow7qsoiz3i9s0 From: "0445566000" ;tag=2m7re1yvj3F5F To: "1112223333" ;tag=wzxe7s9s-CC-1049-OFC-32 CSeq: 5 INVITE Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,NOTIFY,MESSAGE,REFER,PUBLISH Contact: Content-Length: 210 Content-Type: application/sdp v=0 o=HuaweiSoftx3000 1743551938 1743551940 IN IP4 9.10.11.12 s=ATMS SBC c=IN IP4 9.10.11.12 t=0 0 m=audio 16874 RTP/AVP 8 116 a=rtpmap:8 PCMA/8000 a=rtpmap:116 telephone-event/8000 a=ptime:20 2025/09/26 16:10:21.381041 5.6.7.8:5060 -> 1.2.3.4:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 1.2.3.4;received=1.2.3.4;rport=5060;branch=z9hG4bKBSyUDj3X836DH Call-ID: ww0q0moisw7zh30z9e9ow7qsoiz3i9s0 From: "0445566000" ;tag=2m7re1yvj3F5F To: "1112223333" ;tag=wzxe7s9s-CC-1049-OFC-32 CSeq: 104891418 INVITE Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REGISTER,PRACK,INFO,UPDATE,SUBSCRIBE,NOTIFY,MESSAGE,REFER,PUBLISH Contact: Content-Length: 210 Content-Type: application/sdp v=0 o=HuaweiSoftx3000 1743551938 1743551940 IN IP4 9.10.11.12 s=ATMS SBC c=IN IP4 9.10.11.12 t=0 0 m=audio 16874 RTP/AVP 8 116 a=rtpmap:8 PCMA/8000 a=rtpmap:116 telephone-event/8000 a=ptime:20 2025/09/26 16:10:21.401668 1.2.3.4:5060 -> 5.6.7.8:5060 INFO sip:9.10.11.12;did=33b.ae0baf63 SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4;rport;branch=z9hG4bKc2QmFDm15cX0c Route: Max-Forwards: 70 From: "0445566000" ;tag=2m7re1yvj3F5F To: "1112223333" ;tag=wzxe7s9s-CC-1049-OFC-32 Call-ID: ww0q0moisw7zh30z9e9ow7qsoiz3i9s0 CSeq: 104891419 INFO Contact: User-Agent: FreeSWITCH-mod_sofia/1.10.12-release+git~20240802T210227Z~a88d069d6f~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: path, replaces Content-Type: service/hostedpbx Content-Disposition: Info-Package Content-Length: 168 Info-Package: extraservice service=queue;action=3;cid=981112223333;cidname=1112223333;dest=445566000;forwarder=3;all=0.0,0.0;bll=0.0,0.0; 2025/09/26 16:10:21.402216 5.6.7.8:5060 -> 9.10.11.12:5060 INFO sip:9.10.11.12;did=33b.ae0baf63 SIP/2.0 Via: SIP/2.0/UDP 5.6.7.8:5060;branch=z9hG4bK4ee.6e62ffd4.0 Via: SIP/2.0/UDP 1.2.3.4;received=1.2.3.4;rport=5060;branch=z9hG4bKc2QmFDm15cX0c Max-Forwards: 30 From: "0445566000" ;tag=2m7re1yvj3F5F To: "1112223333" ;tag=wzxe7s9s-CC-1049-OFC-32 Call-ID: ww0q0moisw7zh30z9e9ow7qsoiz3i9s0 CSeq: 6 INFO Contact: User-Agent: FreeSWITCH-mod_sofia/1.10.12-release+git~20240802T210227Z~a88d069d6f~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: path, replaces Content-Type: service/hostedpbx Content-Disposition: Info-Package Content-Length: 168 Info-Package: extraservice P-hint: rr-enforced service=queue;action=3;cid=981112223333;cidname=1112223333;dest=445566000;forwarder=3;all=0.0,0.0;bll=0.0,0.0; 2025/09/26 16:10:21.403096 1.2.3.4:5060 -> 5.6.7.8:5060 ACK sip:9.10.11.12;did=33b.ae0baf63 SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4;rport;branch=z9hG4bKDBHDH8442NKKr Route: Max-Forwards: 70 From: "0445566000" ;tag=2m7re1yvj3F5F To: "1112223333" ;tag=wzxe7s9s-CC-1049-OFC-32 Call-ID: ww0q0moisw7zh30z9e9ow7qsoiz3i9s0 CSeq: 104891418 ACK Content-Length: 0 2025/09/26 16:10:21.403365 5.6.7.8:5060 -> 9.10.11.12:5060 ACK sip:9.10.11.12;did=33b.ae0baf63 SIP/2.0 Via: SIP/2.0/UDP 5.6.7.8:5060;branch=z9hG4bK5ee.de615a07.2 Via: SIP/2.0/UDP 1.2.3.4;received=1.2.3.4;rport=5060;branch=z9hG4bKDBHDH8442NKKr Max-Forwards: 30 From: "0445566000" ;tag=2m7re1yvj3F5F To: "1112223333" ;tag=wzxe7s9s-CC-1049-OFC-32 Call-ID: ww0q0moisw7zh30z9e9ow7qsoiz3i9s0 CSeq: 6 ACK Content-Length: 0 P-hint: rr-enforced 2025/09/26 16:10:21.403477 9.10.11.12:5060 -> 5.6.7.8:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 5.6.7.8:5060 ;received=5.6.7.8;rport=5060;branch=z9hG4bK4ee.6e62ffd4.0 Via: SIP/2.0/UDP 1.2.3.4;received=1.2.3.4;rport=5060;branch=z9hG4bKc2QmFDm15cX0c To: "1112223333" ;tag=wzxe7s9s-CC-1049-OFC-32 From: "0445566000" ;tag=2m7re1yvj3F5F Call-ID: ww0q0moisw7zh30z9e9ow7qsoiz3i9s0 CSeq: 6 INFO Content-Length: 0 2025/09/26 16:10:21.403615 5.6.7.8:5060 -> 1.2.3.4:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 1.2.3.4;received=1.2.3.4;rport=5060;branch=z9hG4bKc2QmFDm15cX0c To: "1112223333" ;tag=wzxe7s9s-CC-1049-OFC-32 From: "0445566000" ;tag=2m7re1yvj3F5F Call-ID: ww0q0moisw7zh30z9e9ow7qsoiz3i9s0 CSeq: 104891419 INFO Content-Length: 0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From medeanwz at gmail.com Sat Sep 27 11:03:34 2025 From: medeanwz at gmail.com (M S) Date: Sat, 27 Sep 2025 13:03:34 +0200 Subject: [OpenSIPS-Users] CDR change before sending to database Message-ID: Hi list, I was wondering if anybody has any ideas about making changes to CDR variables before sending them to the database. Documents say the acc module calls E_ACC_CDR, is this before sending it to the database, or in a parallel branch? if I change a variable in here, does it change what's written to the database? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: