From razvan at opensips.org Fri Feb 1 06:44:35 2019 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Fri, 1 Feb 2019 13:44:35 +0200 Subject: [OpenSIPS-Users] OpenSIPS at FOSDEM'19 Message-ID: <90b988ba-893d-e4a0-352e-e9ae8fdc1cc2@opensips.org> Hello, everyone! This year the OpenSIPS team will be present again in Brussels at FOSDEM'19[1]! Me and Liviu will have a presentation in the RTC room about Building a Multi-Node SIP Platform Using OpenSIPS[2]. The presentation is scheduled for Sunday, 12:45 in the H.1309 (Van Rijn) room[3]. For those of you who will be attending FOSDEM this year, make sure you don't miss it, it will contain some nice surprises :). [1] https://fosdem.org/2019/ [2] https://fosdem.org/2019/schedule/event/opensips/ [3] https://fosdem.org/2019/schedule/room/h1309_van_rijn/ See you all there! -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com From Ben.Newlin at genesys.com Fri Feb 1 16:25:18 2019 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Fri, 1 Feb 2019 21:25:18 +0000 Subject: [OpenSIPS-Users] error_route not triggering Message-ID: <51FCF29D-13E0-456C-8A68-4F7584D10E60@genesys.com> Anyone got any ideas on this? Does anyone have an error_route successfully working in 2.4.4? Ben Newlin From: Users on behalf of Ben Newlin Reply-To: OpenSIPS users mailling list Date: Thursday, January 24, 2019 at 5:16 PM To: OpenSIPS users mailling list Subject: [OpenSIPS-Users] error_route not triggering Hi, I recently noticed some parsing errors in our logs and after digging further I’ve realized that our error route is not triggering when this occurs. Is there some sort of subscribe or attach operation needed to get calls to the error route? The documentation states it will be called automatically. I’ve been able to reproduce the issue in our testbed. We are running OpenSIPS 2.4.4. My error route is defined like this: error_route { xlog("L_ALERT", "Error route called!\n"); } This is what I get from OpenSIPS logs: Jan 24 21:59:30 [329] ERROR:core:receive_msg: Unable to parse msg received from [203.0.113.4:48096] Jan 24 21:59:30 [336] ERROR:core:parse_first_line: bad request first line Jan 24 21:59:30 [336] ERROR:core:parse_first_line: at line 0 char 17: Jan 24 21:59:30 [336] ERROR:core:parse_first_line: parsed so far: INVITE sip:bad to Jan 24 21:59:30 [336] INFO:core:parse_first_line: bad message Jan 24 21:59:30 [336] ERROR:core:parse_msg: message= From johan at democon.be Sat Feb 2 08:06:33 2019 From: johan at democon.be (johan de clercq) Date: Sat, 2 Feb 2019 14:06:33 +0100 Subject: [OpenSIPS-Users] [NEW] Gateway between SIP and SMPP messages In-Reply-To: <652258ae-5160-921c-f6bb-555bb196ab8b@opensips.org> References: <9f3ba4b1-cd78-f390-debe-32c30d705251@opensips.org> <012f01d4b409$3ec9b9a0$bc5d2ce0$@democon.be> <652258ae-5160-921c-f6bb-555bb196ab8b@opensips.org> Message-ID: <00d101d4baf8$200e2280$602a6780$@democon.be> Razvan, Can I do the backport myself ? And how much work is it ? BR, -----Original Message----- From: Users On Behalf Of Razvan Crainea Sent: Friday, January 25, 2019 9:35 AM To: users at lists.opensips.org Subject: Re: [OpenSIPS-Users] [NEW] Gateway between SIP and SMPP messages Unfortunately this is a feature, not a bug, so it won't be backported to 2.4. Cheers, Răzvan On 1/24/19 7:21 PM, johan de clercq wrote: > Do you backport this to 2.4 ? > > BR, > > -----Original Message----- > From: Users On Behalf Of Razvan > Crainea > Sent: Thursday, January 24, 2019 5:37 PM > To: OpenSIPS users mailling list ; OpenSIPS > devel mailling list > Subject: [OpenSIPS-Users] [NEW] Gateway between SIP and SMPP messages > > Hi, Everyone! > > Check out the latest OpenSIPS module, proto_smpp[1], that you can use to create a two-way bridge between SIP and SMPP text messages. Read more about this on our blog[2]. > > [1] https://opensips.org/html/docs/modules/3.0.x/proto_smpp.html > [2] > https://blog.opensips.org/2019/01/24/gateway-between-sip-and-smpp-mess > ages/ > > Cheers, > -- > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > _______________________________________________ > 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 > -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com Meet the OpenSIPS team at the next OpenSIPS Summit: https://www.opensips.org/events _______________________________________________ Users mailing list Users at lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users From bogdan at opensips.org Mon Feb 4 02:39:52 2019 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 4 Feb 2019 09:39:52 +0200 Subject: [OpenSIPS-Users] Using sip_trace increases the number of failed_dialogs In-Reply-To: References: Message-ID: Hi, Somehow this is hard to believe - the tracing has no impact on the sip routing (and dialogs). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ On 01/11/2019 05:15 PM, Gholamreza Sabery wrote: > Hi, > Recently, I tried to integrate OpenSips with Homer5 and it was > successful (using HEPv2). However, when I use sip_trace; the number of > "failed_dialogs" (which is a statistics exported by dialog module) > increases dramatically. Notice that this increase, does not have a > negative effect on the real number of successful calls (CDR > statistics). I wonder why this happens. Any ideas? > > Regards > > > _______________________________________________ > 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 bogdan at opensips.org Mon Feb 4 02:50:37 2019 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 4 Feb 2019 09:50:37 +0200 Subject: [OpenSIPS-Users] sip capturing using hep In-Reply-To: <1188396276.205073.1547607997540@mail.yahoo.com> References: <1188396276.205073.1547607997540.ref@mail.yahoo.com> <1188396276.205073.1547607997540@mail.yahoo.com> Message-ID: <70d1391b-6f3a-6150-5d1c-60df6e46d78e@opensips.org> Hi Pasan, The "Resource temporarily unavailable" is similar to EAGAIN or EWOULDBLOCK - meaning that the send will block. But this is an UDP protocol, so there is nothing much to block - as UDP is a stateless protocol. Unless it is the buffer in the TCP/IP stack,between the application layer and the actual network layer - like the opensips is bursting data, but the kernel has no time to actually put it on wire. Try to monitor with netstat the size of the out buffer for the hep socket (on opensips side), and see if you see buffered data there (especially correlated with the logs you see). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ On 01/16/2019 05:06 AM, Pasan Meemaduma via Users wrote: > Hi Guys, > > I have following setup for homer integration with opensips. I'm having > an issue where opensips complains with following error time to time. I > tried tuning up buffer sizes, but it doesn't seems to help. Any > suggestion on how to get rid of this ? > > I'm using opensips 2.3.6 > > /usr/sbin/opensips[27139]: ERROR:proto_hep:hep_udp_send: > sendto(sock,0x7fc2facaff58,5792,0,0x7fc2fa84d858,16): Resource > temporarily unavailable(11) > > > sip traffic -> internet facing interface (public ip) (opensips) > internal admin interface (private ip ) > udp:9060 ---- > udp:9060 internal admin interface (private ip) > (opensips sip capturer) > > > When the above error pops out it appears all legit connections get > drop too for a brief period. I tried to increate send/recev buffer > sizes, but that didn't help. > > net.core.rmem_max > net.core.rmem_default > > net.core.wmem_max > net.core.wmem_default > > > _______________________________________________ > 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 bogdan at opensips.org Mon Feb 4 02:58:30 2019 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 4 Feb 2019 09:58:30 +0200 Subject: [OpenSIPS-Users] sips: automatically downgraded to sip: In-Reply-To: References: Message-ID: <45b1b34c-65ac-b90c-10f9-cebc3de192bc@opensips.org> Hi Wilhelm, Keep in mind that OPenSIPS is a routing engine that does what you tell it to do. The OpenSIPS does the translation from TLS to UDP as the callee device is registered via UDP. Now, how to handle a sips enforcement in the RURI is up to the logic in the proxy - if allows it to switch to a non-secure protocol or if applies constraints to stay with a secure protocol - but if you want this, you need to script it in your opensips.cfg. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ On 01/16/2019 06:03 PM, Wilhelm Lundgren wrote: > Hi, > > Im trying out some tls / sips things in my client. But im seeing > something strange in opensips. > I am using opensips 2.2.2, x64. > > Im registering my client with TLS and SIPS. Another client is > registering over UDP. I expected that when i send a SIP MESSAGE with > sips: in request and to / from tags etc, the UDP client should not > receive the message. However, opensips downgrades this message to > normal sip and sends it. > > Have i missunderstood "sips:" feature or have i configed something > wrong or is it not supported? > > Best Regards > Wilhelm > > > > _______________________________________________ > 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 bogdan at opensips.org Mon Feb 4 02:59:41 2019 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 4 Feb 2019 09:59:41 +0200 Subject: [OpenSIPS-Users] OpenSIPs Load_balancer replication In-Reply-To: References: Message-ID: Hi there, So, what actually do you want to replicate ? the dialogs? or the profiles used by the LB module to count the calls ? There are 2 different things. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ On 01/31/2019 09:37 PM, Social Boh wrote: > Hello, > > I'm trying to replicate load data about load_balancer module between > two OpenSIPs active instance. > > Table load_balancer use /b after resource name. > > Script use /b on the load_balance function. > > On the dialog module parameters: > > modparam("dialog", "dialog_replication_cluster", 1) > modparam("dialog", "profile_replication_cluster", 1) > > Cluster working correctly. > > When a call arrive to OpenSIPs1 on the OpenSIPs2: > > WARNING:dialog:fetch_socket_info: non-local socket > ...ignoring > WARNING:dialog:fetch_socket_info: non-local socket > ...ignoring > ERROR:dialog:dlg_replicated_create: Replicated dialog doesn't match > any listening sockets > ERROR:dialog:receive_dlg_repl: Failed to process a binary packet! > > How can I solve? > > Thank you > From bogdan at opensips.org Mon Feb 4 03:03:12 2019 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 4 Feb 2019 10:03:12 +0200 Subject: [OpenSIPS-Users] Cause of tcp_receive_timeout In-Reply-To: References: Message-ID: <5b703bcf-e17a-ca18-705e-d51a7a3f9f7b@opensips.org> Hi Hamid, By the fact that I'm able to see the SIP INVITE in the trace you provide, tell me that there is no TLS actually used :). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ On 01/17/2019 12:48 PM, Hamid Hashmi wrote: > > I am trying to load test TLS listener through sipp. REGISTER Request > is working on TLS but INVITE is not working. I changed the transport > to TCP and receive following logs > > |version: opensips 2.4.3 (x86_64/linux) flags: STATS: On, > DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_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: c49ae1d53 main.c > compiled on 14:23:04 Dec 5 2018 with gcc 4.8.5 | > |Jan 17 13:10:23 siplb_19 192.168.3.19[29333]: DBG:core:tcp_read_req: > Accepted connection from 192.168.3.60:36157 on interface > 192.168.3.60:2381! Jan 17 13:10:23 siplb_19 192.168.3.19[29333]: > DBG:core:tcp_read_req: Using the global ( per process ) buff Jan 17 > 13:10:23 siplb_19 192.168.3.19[29333]: DBG:core:tcp_handle_req: We > didn't manage to read a full request Jan 17 13:10:23 siplb_19 > 192.168.3.19[29333]: DBG:core:tcp_read_req: tcp_read_req end Jan 17 > 13:10:27 siplb_19 192.168.3.19[29333]: DBG:core:tcp_receive_timeout: > 0x7fe984baf740 expired - (18, 18) lt=129 Jan 17 13:10:27 siplb_19 > 192.168.3.19[29333]: DBG:core:io_watch_del: [TCP_worker] io_watch_del > op on index -1 7 (0x8c2da0, 7, -1, 0x10,0x1) fd_no=5 called Jan 17 > 13:10:27 siplb_19 192.168.3.19[29333]: DBG:core:tcpconn_release: > releasing con 0x7fe984baf740, state -2, fd=-1, id=1475809186 Jan 17 > 13:10:27 siplb_19 192.168.3.19[29333]: DBG:core:tcpconn_release: > extra_data (nil) Jan 17 13:10:27 siplb_19 192.168.3.19[29342]: > DBG:core:handle_tcp_worker: response= 7fe984baf740, -2 from tcp worker > 29333 (0) Jan 17 13:10:27 siplb_19 192.168.3.19[29342]: > DBG:core:tcpconn_destroy: destroying connection 0x7fe98| > > PCAP file is also attached. > > SIPP Caller 192.168.3.60 ------- > SIP Server 192.168.3.19 > > TLS connection working fine with the softphone. This only occurs when > I send TLS/TCP request through SIPp script. > > Regards > > *Hamid R. Hashmi* > > > > _______________________________________________ > 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 bogdan at opensips.org Mon Feb 4 03:05:39 2019 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 4 Feb 2019 10:05:39 +0200 Subject: [OpenSIPS-Users] phonenumber format into mysql database In-Reply-To: References: <669db766-70e1-598e-2820-847fc7818ec8@opensips.org> Message-ID: Hi Mickael, My turn :) . In drouting, the data is stored in memory as a decimal tree, so only digits are allowed. It is a constraint coming from how the search tree is structured. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ On 01/27/2019 08:51 AM, Mickael Hubert wrote: > Hi > I'm sorry for my late answer. I'm talking about drouting table for > example. > > > Le mer. 3 oct. 2018 22:14, Bogdan-Andrei Iancu > a écrit : > > Hi Mickael, > > AFAIK E164 is without '+' (which is actually a breakout code, not > part of the number itself). > > And when you say the numbers are stored in DB - which module/table > are you talking about ? > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > OpenSIPS Bootcamp 2018 > http://opensips.org/training/OpenSIPS_Bootcamp_2018/ > > On 10/03/2018 11:47 AM, Mickael Hubert wrote: >> Hi all, >> I have a non technical question. >> why phonenumbers into database are stocked whitout + sign (non >> E164 format) ? >> is it for a prformance purposes ? >> >> I'm looking for the best way to store E164 phonenumbers for a >> personnal dev. >> >> thanks in advance >> >> ++ >> Micka >> >> >> _______________________________________________ >> 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 bogdan at opensips.org Mon Feb 4 03:17:07 2019 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 4 Feb 2019 10:17:07 +0200 Subject: [OpenSIPS-Users] Cannot execute MI command on opensips-cp 8.2.4 In-Reply-To: References: Message-ID: <6e08dc50-170a-112f-2919-a78e3cc2fcff@opensips.org> Hi Aqs, Maybe there is an error in the boxes.global.inc.php - be sure the box has and 'mi' connector and the indexing of the boxes is correct. Just to be sure, do an update to the latest 8.2.4 code from git. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ On 01/25/2019 10:36 PM, Aqs Younas wrote: > Greetings list, > > I am trying to execute mi commands from opensips-cp but looks like > opensips-cp is unable to find the json URL and sending me the below > error. > > /16:06:52/ | *uptime* | > ------------------------------------------------------------------------ > Unknwon/Unsupported type[] for MI URL <> > > By looking at the below snippet of mi.php file, I see > > if ($_GET['action']=="change_box" && !empty($_POST['box_val'])) { > $current_box=$_POST['box_val']; > $_SESSION['mi_current_box']=$current_box ; > } else if (!empty($_SESSION['mi_current_box'])) { > $current_box=$_SESSION['mi_current_box']; > } else { > *$current_box="";* > } > > Somehow variable current_box is being populated as empty. > > My boxes.global.inc.php is configured like below. > $box_id=0; > // MI connector (via JSON backend): json:host:port/json > $boxes[$box_id]['mi']['conn']="json:127.0.0.1:8888/json > "; > > And i am able to use mi commands from the terminal. > > root at opensips:~# curl http://127.0.0.1:8888/json/uptime > {"Now": "Fri Jan 25 16:32:45 2019", "Up since": "Fri Jan 25 16:21:57 > 2019", "Up time": "648 [sec]"}root at opensips:~# > > I am at lost where else i need to define my server json URL. > > Any help is much appreciated. > > Thanks. > > > _______________________________________________ > 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 pasandev at ymail.com Mon Feb 4 03:17:16 2019 From: pasandev at ymail.com (Pasan Meemaduma) Date: Mon, 4 Feb 2019 08:17:16 +0000 (UTC) Subject: [OpenSIPS-Users] sip capturing using hep In-Reply-To: <70d1391b-6f3a-6150-5d1c-60df6e46d78e@opensips.org> References: <1188396276.205073.1547607997540.ref@mail.yahoo.com> <1188396276.205073.1547607997540@mail.yahoo.com> <70d1391b-6f3a-6150-5d1c-60df6e46d78e@opensips.org> Message-ID: <1406476727.2491043.1549268236040@mail.yahoo.com> Thanks for the reply Bogdan, After controlling what needs to be trace using hep, I was able to eliminate the above error. Its not happening now, It appears to be related with trying to capture all brute-force scan pkt causing the issue. But I'm not 100% sure, I'll try to do what you suggest and see how it goes. On Monday, 4 February 2019, 1:20:46 PM GMT+5:30, Bogdan-Andrei Iancu wrote: Hi Pasan, The "Resource temporarily unavailable" is similar to EAGAIN or EWOULDBLOCK - meaning that the send will block. But this is an UDP protocol, so there is nothing much to block - as UDP is a stateless protocol. Unless it is the buffer in the TCP/IP stack,between the application layer and the actual network layer - like the opensips is bursting data, but the kernel has no time to actually put it on wire. Try to monitor with netstat the size of the out buffer for the hep socket (on opensips side), and see if you see buffered data there (especially correlated with the logs you see). Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ On 01/16/2019 05:06 AM, Pasan Meemaduma via Users wrote: Hi Guys, I have following setup for homer integration with opensips. I'm having an issue where opensips complains with following error time to time. I tried tuning up buffer sizes, but it doesn't seems to help. Any suggestion on how to get rid of this ? I'm using opensips 2.3.6 /usr/sbin/opensips[27139]: ERROR:proto_hep:hep_udp_send: sendto(sock,0x7fc2facaff58,5792,0,0x7fc2fa84d858,16): Resource temporarily unavailable(11) sip traffic  ->   internet facing interface (public ip) (opensips)                         internal admin interface (private ip ) udp:9060  ---- >   udp:9060 internal admin interface (private ip)  (opensips sip capturer) When the above error pops out it appears all legit connections get drop too for a brief period. I tried to increate send/recev buffer sizes, but that didn't help. net.core.rmem_max net.core.rmem_default net.core.wmem_max net.core.wmem_default _______________________________________________ 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 bogdan at opensips.org Mon Feb 4 03:44:40 2019 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 4 Feb 2019 10:44:40 +0200 Subject: [OpenSIPS-Users] shmem statistics In-Reply-To: <68DA2169-7595-4B9D-8DFE-7618E13A0CD3@genesys.com> References: <1548324610.261055421@f338.i.mail.ru> <68DA2169-7595-4B9D-8DFE-7618E13A0CD3@genesys.com> Message-ID: <64933072-3acb-1dd4-6067-9ad198fe0ff3@opensips.org> Also note that each module may export a set of statistics (grouped per module name) - see the modules doc for this. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ On 01/24/2019 03:54 PM, Ben Newlin wrote: > Alexey, > > The statistics exported by the OpenSIPS core are described in the documentation here: http://www.opensips.org/Documentation/Interface-CoreStatistics-2-4 > > Ben Newlin > > On 1/24/19, 5:10 AM, "Users on behalf of Alexey Kazantsev via Users" wrote: > > Hi list! > > Where can I read more about what all this means? > I'd like to monitor some statistics with Zabbix and create graphs, > so I'd like to understand what parameters from these it's necessary > to monitor. > > shmem:total_size:: 67108864 > shmem:used_size:: 2858880 > shmem:real_used_size:: 2904352 > shmem:max_used_size:: 2919144 > shmem:free_size:: 64204512 > shmem:fragments:: 478 > > The same question about pkmem: group (no example due to too long > listing). > > ----------------------------------------------- > BR, Alexey > http://alexeyka.zantsev.com/ > _______________________________________________ > 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 bogdan at opensips.org Mon Feb 4 03:54:48 2019 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 4 Feb 2019 10:54:48 +0200 Subject: [OpenSIPS-Users] error_route not triggering In-Reply-To: References: Message-ID: <28373bd6-ccc8-1ddb-8d4e-e805ab62e81e@opensips.org> Hi Ben, There is nothing extra for you to do. The error route should be triggered. You get this error - https://github.com/OpenSIPS/opensips/blob/master/receive.c#L147 and if a request, the error route should be triggered (see line 151). Try to log in debug level, maybe you will get more relevant data. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ On 01/25/2019 12:14 AM, Ben Newlin wrote: > > Hi, > > I recently noticed some parsing errors in our logs and after digging > further I’ve realized that our error route is not triggering when this > occurs. Is there some sort of subscribe or attach operation needed to > get calls to the error route? The documentation states it will be > called automatically. I’ve been able to reproduce the issue in our > testbed. We are running OpenSIPS 2.4.4. > > My error route is defined like this: > > error_route > > { > > xlog("L_ALERT", "Error route called!\n"); > > } > > This is what I get from OpenSIPS logs: > > Jan 24 21:59:30 [329] ERROR:core:receive_msg: Unable to parse msg > received from [203.0.113.4:48096] > > Jan 24 21:59:30 [336] ERROR:core:parse_first_line: bad request first line > > Jan 24 21:59:30 [336] ERROR:core:parse_first_line: at line 0 char 17: > > Jan 24 21:59:30 [336] ERROR:core:parse_first_line: parsed so far: > INVITE sip:bad to > > Jan 24 21:59:30 [336] INFO:core:parse_first_line: bad message > > Jan 24 21:59:30 [336] ERROR:core:parse_msg: message= syntax\r\n at 203.0.113.2:5060;transport=UDP;user=phone SIP/2.0 > > My log from the error route is not called. > > Any help would be appreciated. I’m probably missing something simple. > > Ben Newlin > > > > _______________________________________________ > 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 bogdan at opensips.org Mon Feb 4 03:57:18 2019 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 4 Feb 2019 10:57:18 +0200 Subject: [OpenSIPS-Users] SHM Memory issue In-Reply-To: References: Message-ID: Hi Vishal, It looks like you are running out of shm/shared memory. You can check its internal usage by: opensipsctl fifo get_statistics shemem: What to do? Add more memory for OpenSIPS to use - see the '-m' startup parameter. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ On 01/25/2019 03:17 AM, Vishal Pai wrote: > Hello everyone > > I am using opensips version > > version: opensips 2.4.3 (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > F_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: c49ae1d53 > > > I am getting when there is increase the number of calls > > Jan 24 19:51:20 ns101756 /usr/local/sbin/opensips[1431]: > ERROR:core:fm_malloc: not enough free shm memory (59920 bytes left, > need 432), please increase the "-m" command line parameter! > Jan 24 19:51:20 ns101756 /usr/local/sbin/opensips[1431]: > INFO:core:fm_malloc: attempting defragmentation... > Jan 24 19:51:20 ns101756 /usr/local/sbin/opensips[1423]: > WARNING:core:utimer_ticker: utimer task already scheduled > for 30849800 ms (now 31196060 ms), it may overlap.. > Jan 24 19:51:20 ns101756 /usr/local/sbin/opensips[1431]: > INFO:core:fm_malloc: unable to alloc a big enough fragment! > Jan 24 19:51:20 ns101756 /usr/local/sbin/opensips[1431]: > ERROR:tm:build_local: no more share memory > Jan 24 19:51:20 ns101756 /usr/local/sbin/opensips[1431]: > ERROR:tm:cancel_branch: attempt to build a CANCEL failed > > Think it's memory issue. What is the best way to fix it up. > > > _______________________________________________ > 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 gmaruzz at gmail.com Mon Feb 4 09:59:35 2019 From: gmaruzz at gmail.com (Giovanni Maruzzelli) Date: Mon, 4 Feb 2019 15:59:35 +0100 Subject: [OpenSIPS-Users] TLS traffic visualization HOWTO Message-ID: # How to TRACE and visualize TLS and non-TLS SIP traffic in real time (thanks to Homer's Lorenzo Mangani for pointing me toward Frida) apt-get install python-pip pip install frida pip install hexdump wget https://raw.githubusercontent.com/google/ssl_logger/master/ssl_logger.py #first ssh terminal # create fifo pipe, then will send the content from fifo pipe to an sngrep without gui, which will be reading pcap from stdin, and sending eep packets to the other sngrep (third terminal) mkfifo /tmp/pipe cat /tmp/pipe | sngrep -N -q -H udp:127.0.0.1:5077 -I - #second ssh terminal # writes as pcap to fifo pipe what freeswitch writes and reads from ssl lib python ssl_logger_giova.py -pcap /tmp/pipe freeswitch #third ssh terminal # sngrep that receives packets from both the Ethernet device, and the eep packets sent by the other sngrep (eg, the tls packets ssl_logger grabs from freeswitch's ssl lib) sngrep -L udp:127.0.0.1:5077 (you may want to edit ssl_logger.py and change 228 to be 101 - LINKTYPE_IPV4 to be LINKTYPE_RAW ) -- Sincerely, Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Tue Feb 5 05:54:36 2019 From: spanda at 3clogic.com (Sasmita Panda) Date: Tue, 5 Feb 2019 16:24:36 +0530 Subject: [OpenSIPS-Users] I have some query regarding rest_client module of opensips . Message-ID: Hi All , I have a requirement . while doing lookup location , I got 3 contacts for 1 username . Now I will do serial fork on these contacts . Before doing serial fork , I wanted to hit a http url and get some data , that data will be 2 contact of the same username I have done db lookup before . Then will do the matching , and will override the DB contact with the contact I got from http get request . Is this possible ? If yes , Then how I will do this . What kind of data should be the http response , so that I can use it further ? Can anybody help me on this please . *Thanks & Regards* *Sasmita Panda* *Senior Network Testing and Software Engineer* *3CLogic , ph:07827611765* -------------- next part -------------- An HTML attachment was scrubbed... URL: From pasandev at ymail.com Tue Feb 5 20:40:25 2019 From: pasandev at ymail.com (Pasan Meemaduma) Date: Wed, 6 Feb 2019 01:40:25 +0000 (UTC) Subject: [OpenSIPS-Users] I have some query regarding rest_client module of opensips . In-Reply-To: References: Message-ID: <819612440.3690276.1549417225422@mail.yahoo.com> Hi Sasmita, I think json objects are the way to go. I have a similar call for blocking services where i make a rest api call to an api to block the service. both request/response is based on json data. opensips has json module for json object handling. On Tuesday, 5 February 2019, 4:25:28 PM GMT+5:30, Sasmita Panda wrote: Hi All ,  I have a requirement .  while doing lookup location , I got 3 contacts for 1 username . Now I will do serial fork on these contacts .  Before doing serial fork , I wanted to hit a http url and get some data , that data will be 2 contact of the same username I have done db lookup before .  Then will do the matching , and will override the DB contact with the contact I got from http get request .  Is this possible ? If yes , Then how I will do this . What kind of data should be the http response , so that I can use it further ?  Can anybody help me on this please .  Thanks & RegardsSasmita PandaSenior Network Testing and Software Engineer3CLogic , ph:07827611765_______________________________________________ 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 volga629 at networklab.ca Wed Feb 6 09:58:38 2019 From: volga629 at networklab.ca (Slava Bendersky) Date: Wed, 6 Feb 2019 09:58:38 -0500 (EST) Subject: [OpenSIPS-Users] presence and dns In-Reply-To: <519949054.40.1549465075255.JavaMail.bendersky@nlws01.networklab.lan> Message-ID: <28375595.52.1549465117374.JavaMail.bendersky@nlws01.networklab.lan> Hello Everyone, How to avoid dns look up while NOTIFY is trying to reach end point for presence subscriber. Feb 5 15:15:42 vprx00 /usr/sbin/opensips[3889]: INFO:presence:update_subscription: notify Feb 5 15:15:42 vprx00 /usr/sbin/opensips[3889]: INFO:presence:send_notify_request: NOTIFY sip:106 at domain.com via sip:106 at 158.69.151.88:58924;nat=yes;ob on behalf of sip:105@ domain.com for event presence, to_tag=656a154e9c9480ea0e92b7b8c389691c-0448, cseq=1 Feb 5 15:15:42 vprx00 /usr/sbin/opensips[3889]: CRITICAL:core:mk_proxy: could not resolve hostname: " domain.com " Feb 5 15:15:42 vprx00 /usr/sbin/opensips[3889]: ERROR:tm:uri2proxy: bad host name in URI Feb 5 15:15:42 vprx00 /usr/sbin/opensips[3889]: ERROR:tm:t_forward_nonack: failure to add branches Feb 5 15:15:42 vprx00 /usr/sbin/opensips[3889]: ERROR:tm:w_t_relay: t_forward_nonack failed Also Pua Dialog Info producing the error of extra parameters Feb 5 15:42:21 vprx00 /usr/sbin/opensips[4137]: ERROR:pua_dialoginfo:pack_cb_params: Failed to parse peer nameaddr [sip:105 at 10.30.100.41:5060#015#012] Feb 5 15:42:21 vprx00 /usr/sbin/opensips[4137]: ERROR:pua_dialoginfo:dialoginfo_set: Failed to allocate parameters Feb 5 18:27:20 vprx00 /usr/sbin/opensips[5451]: ERROR:pua_dialoginfo:pack_cb_params: Failed to parse peer nameaddr [sip:033003535812 at eficart.colpbx.com#015#012] Feb 5 18:27:20 vprx00 /usr/sbin/opensips[5451]: ERROR:pua_dialoginfo:dialoginfo_set: Failed to allocate parameters volga629 -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Thu Feb 7 03:38:35 2019 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 7 Feb 2019 10:38:35 +0200 Subject: [OpenSIPS-Users] OpenSIPS Ansible Role Message-ID: <4f4c0eb2-8ca7-5415-48d1-597553725f1f@opensips.org> Hello, everyone! I've just created a new repository in the OpenSIPS organization that contains an Ansible Role for installing OpenSIPS from the official sources[1]. The role can install OpenSIPS on Debian, Ubuntu and RedHat distributions. The role is also advertised in Ansible Galaxy, so you can install and use it very easy[2]. This project is open to anyone in the community, so if you want to enhance it with any features, feedback and PRs are more than welcome. [1] https://github.com/OpenSIPS/ansible-opensips [2] https://galaxy.ansible.com/razvancrainea/opensips Enjoy! -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com Meet the OpenSIPS team at the next OpenSIPS Summit: https://www.opensips.org/events From konrad.malewski at motorolasolutions.com Thu Feb 7 10:17:04 2019 From: konrad.malewski at motorolasolutions.com (Konrad Malewski) Date: Thu, 7 Feb 2019 16:17:04 +0100 Subject: [OpenSIPS-Users] B2BUA and BYE message generated from sipp Message-ID: Hello, I am new to opensips. I went through proxy tutorials and now I am trying to configure opensips in b2bua mode. I am using 3 dockers (UAS, UAC and opensips). I have problems with BYE message sent by UAC. Opensips is not able to match it to whole dialog (this is my interpretation) and returns 500 internal error (due to t_relay call, but without it there is no response at all). What am I missing from my config ? Thanks for any hint.... # UAS at 172.18.0.4: $ sipp --t tn -sn uas # UAC at 172.18.0.3 $ sipp -t tn -rsa 172.18.0.2 -sn uac -r 1 172.18.0.4 # opensips 2.4.4 (x86_64/linux) at 172.18.0.2 ////////opensips.cfg//////////// ####### Modules Section ######## #set module path mpath="/usr/lib/x86_64-linux-gnu/opensips/modules/" #### StateLess module loadmodule "sl.so" #### Transaction Module loadmodule "tm.so" modparam("tm", "fr_timeout", 5) modparam("tm", "fr_inv_timeout", 30) modparam("tm", "restart_fr_on_each_reply", 0) modparam("tm", "onreply_avp_mode", 1) #### Record Route Module loadmodule "rr.so" modparam("rr", "append_fromtag", 0) #### SIP MSG OPerationS module loadmodule "sipmsgops.so" #### FIFO Management Interface loadmodule "mi_fifo.so" modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo") modparam("mi_fifo", "fifo_mode", 0666) #### TCP protocol loadmodule "proto_tcp.so" loadmodule "topology_hiding.so" loadmodule "b2b_entities.so" loadmodule "b2b_logic.so" modparam("tm", "pass_provisional_replies", 1) ####### Routing Logic ######## route{ route(relay); } route[b2b_request] { xlog("B2B request - callid: $ci time [$Tf] method ($rm) r-uri ($ru) 2nd via ($hdr(via[1]))\n"); } route[b2b_reply] { xlog("B2B reply - callid %ci time [$Tf] method ($rm) r-uri ($ru) 2nd via ($hdr(via[1]))\n"); } route[relay] { if (is_method("INVITE") && !($si=="172.18.0.2" && $sp==5060)) { xlog("B2B init - callid $ci time [$Tf] method ($rm) r-uri ($ru) 2nd via ($hdr(via[1]))\n"); b2b_init_request("top hiding"); exit; } xlog("t_relay - callid $ci time [$Tf] method ($rm) r-uri ($ru) 2nd via ($hdr(via[1]))\n"); if (!t_relay()) { sl_reply_error(); }; exit; } //////////////////////////////// //////NGREP///////////////////// T 172.18.0.3:60750 -> 172.18.0.2:5060 [AP] INVITE sip:service at 172.18.0.4:5060 SIP/2.0. Via: SIP/2.0/TCP 172.18.0.3:5060;branch=z9hG4bK-382-1-0. From: sipp ;tag=382SIPpTag001. To: sut . Call-ID: 1-382 at 172.18.0.3. CSeq: 1 INVITE. Contact: sip:sipp at 172.18.0.3:5060. Max-Forwards: 70. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 131. . v=0. o=user1 53655765 2353687637 IN IP4 172.18.0.3. s=-. c=IN IP4 172.18.0.3. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. T 172.18.0.2:5060 -> 172.18.0.3:60750 [AP] SIP/2.0 100 Giving a try. Via: SIP/2.0/TCP 172.18.0.3:5060;branch=z9hG4bK-382-1-0. From: sipp ;tag=382SIPpTag001. To: sut . Call-ID: 1-382 at 172.18.0.3. CSeq: 1 INVITE. Server: OpenSIPS (2.4.4 (x86_64/linux)). Content-Length: 0. . T 172.18.0.2:43989 -> 172.18.0.4:5060 [AP] INVITE sip:service at 172.18.0.4:5060 SIP/2.0. Via: SIP/2.0/TCP 172.18.0.2:5060;branch=z9hG4bK0c85.96049b37.0. To: sip:service at 172.18.0.4:5060. From: sipp ;tag=42494589cc6520b7535401b81466113d. CSeq: 2 INVITE. Call-ID: B2B.95.8135310.1549535500. Max-Forwards: 70. Content-Length: 131. User-Agent: OpenSIPS (2.4.4 (x86_64/linux)). Content-Type: application/sdp. Contact: . . v=0. o=user1 53655765 2353687637 IN IP4 172.18.0.3. s=-. c=IN IP4 172.18.0.3. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. T 172.18.0.4:5060 -> 172.18.0.2:43989 [AP] SIP/2.0 180 Ringing. Via: SIP/2.0/TCP 172.18.0.2:5060;branch=z9hG4bK0c85.96049b37.0. From: sipp ;tag=42494589cc6520b7535401b81466113d. To: sip:service at 172.18.0.4:5060;tag=370SIPpTag0130. Call-ID: B2B.95.8135310.1549535500. CSeq: 2 INVITE. Contact: . Content-Length: 0. . T 172.18.0.4:5060 -> 172.18.0.2:43989 [AP] SIP/2.0 200 OK. Via: SIP/2.0/TCP 172.18.0.2:5060;branch=z9hG4bK0c85.96049b37.0. From: sipp ;tag=42494589cc6520b7535401b81466113d. To: sip:service at 172.18.0.4:5060;tag=370SIPpTag0130. Call-ID: B2B.95.8135310.1549535500. CSeq: 2 INVITE. Contact: . Content-Type: application/sdp. Content-Length: 131. . v=0. o=user1 53655765 2353687637 IN IP4 172.18.0.4. s=-. c=IN IP4 172.18.0.4. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. T 172.18.0.2:5060 -> 172.18.0.3:60750 [AP] SIP/2.0 180 Ringing. Via: SIP/2.0/TCP 172.18.0.3:5060;branch=z9hG4bK-382-1-0. From: sipp ;tag=382SIPpTag001. To: sut ;tag=B2B.407.108.1549535500. Call-ID: 1-382 at 172.18.0.3. CSeq: 1 INVITE. Contact: . Server: OpenSIPS (2.4.4 (x86_64/linux)). Content-Length: 0. . T 172.18.0.2:5060 -> 172.18.0.3:60750 [AP] SIP/2.0 200 OK. Via: SIP/2.0/TCP 172.18.0.3:5060;branch=z9hG4bK-382-1-0. From: sipp ;tag=382SIPpTag001. To: sut ;tag=B2B.407.108.1549535500. Call-ID: 1-382 at 172.18.0.3. CSeq: 1 INVITE. Content-Type: application/sdp. Contact: . Server: OpenSIPS (2.4.4 (x86_64/linux)). Content-Length: 131. . v=0. o=user1 53655765 2353687637 IN IP4 172.18.0.4. s=-. c=IN IP4 172.18.0.4. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. T 172.18.0.3:60750 -> 172.18.0.2:5060 [AP] ACK sip:service at 172.18.0.4:5060 SIP/2.0. Via: SIP/2.0/TCP 172.18.0.3:5060;branch=z9hG4bK-382-1-5. From: sipp ;tag=382SIPpTag001. To: sut ;tag=B2B.407.108.1549535500. Call-ID: 1-382 at 172.18.0.3. CSeq: 1 ACK. Contact: sip:sipp at 172.18.0.3:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . T 172.18.0.2:43989 -> 172.18.0.4:5060 [AP] ACK sip:172.18.0.4:5060;transport=TCP SIP/2.0. Via: SIP/2.0/TCP 172.18.0.2:5060;branch=z9hG4bK0c85.a6049b37.0. To: ;tag=370SIPpTag0130. From: sipp ;tag=42494589cc6520b7535401b81466113d. CSeq: 2 ACK. Call-ID: B2B.95.8135310.1549535500. Max-Forwards: 70. Content-Length: 0. User-Agent: OpenSIPS (2.4.4 (x86_64/linux)). Contact: . . T 172.18.0.3:60750 -> 172.18.0.2:5060 [AP] BYE sip:service at 172.18.0.4:5060 SIP/2.0. Via: SIP/2.0/TCP 172.18.0.3:5060;branch=z9hG4bK-382-1-7. From: sipp ;tag=382SIPpTag001. To: sut ;tag=B2B.407.108.1549535500. Call-ID: 1-382 at 172.18.0.3. CSeq: 2 BYE. Contact: sip:sipp at 172.18.0.3:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . T 172.18.0.2:5060 -> 172.18.0.3:60750 [AP] SIP/2.0 500 Server error occurred (7/TM). Via: SIP/2.0/TCP 172.18.0.3:5060;branch=z9hG4bK-382-1-7. From: sipp ;tag=382SIPpTag001. To: sut ;tag=B2B.407.108.1549535500. Call-ID: 1-382 at 172.18.0.3. CSeq: 2 BYE. Server: OpenSIPS (2.4.4 (x86_64/linux)). Content-Length: 0. . /////////////////////////////////// ////////////opensips.log/////////// => DBG:core:parse_msg: SIP Request: => DBG:core:parse_msg: method: => DBG:core:parse_msg: uri: => DBG:core:parse_msg: version: => DBG:core:parse_headers: flags=2 => DBG:core:parse_via_param: found param type 232, = ; state=16 => DBG:core:parse_via: end of header reached, state=5 => DBG:core:parse_headers: via found, flags=2 => DBG:core:parse_headers: this is the first via => DBG:core:receive_msg: After parse_msg... => DBG:core:receive_msg: preparing to run routing scripts... => DBG:sl:sl_filter_ACK: too late to be a local ACK! => DBG:core:parse_headers: flags=ffffffffffffffff => DBG:core:parse_to_param: tag=B2B.407.108.1549535500 => DBG:core:_parse_to: end of header reached, state=29 => DBG:core:_parse_to: display={sut}, ruri={sip:service at 172.18.0.4:5060} => DBG:core:get_hdr_field: [62]; uri=[sip:service at 172.18.0.4:5060] => DBG:core:get_hdr_field: to body [sut ] => DBG:core:get_hdr_field: cseq : <1> => DBG:core:get_hdr_field: content_length=0 => DBG:core:get_hdr_field: found end of header => DBG:b2b_entities:b2b_prescript_f: start - method = ACK => DBG:core:parse_to_param: tag=382SIPpTag001 => DBG:core:_parse_to: end of header reached, state=29 => DBG:core:_parse_to: display={sipp}, ruri={sip:sipp at 172.18.0.3:5060} => DBG:b2b_entities:b2b_parse_key: hash_index = [407] - local_index= [108] => DBG:b2b_entities:b2b_prescript_f: Received a b2b server request [ACK] => DBG:b2b_entities:b2b_search_htable_next_dlg: entering with start=(nil), table=0x7fdc845a2110, hash=407, label=108 => DBG:b2b_entities:b2b_search_htable_next_dlg: searching callid 16[ 1-382 at 172.18.0.3] => DBG:b2b_entities:b2b_search_htable_next_dlg: searching totag 22[B2B.407.108.1549535500] => DBG:b2b_entities:b2b_search_htable_next_dlg: searching fromtag 13[382SIPpTag001] => DBG:b2b_entities:b2b_search_htable_next_dlg: Match for server dlg [0x7fdc845bea48] dlg->uas_tran=[(nil)] => DBG:b2b_entities:b2b_prescript_f: Received request method[ACK] for dialog[0x7fdc845bea48] => DBG:tm:t_newtran: transaction on entrance=0xffffffffffffffff => DBG:core:parse_headers: flags=ffffffffffffffff => DBG:core:parse_headers: flags=78 => DBG:tm:t_lookup_request: start searching: hash=47941, isACK=1 => DBG:core:parse_headers: flags=38 => DBG:tm:t_lookup_request: REF_UNSAFE:[0x7fdc845bec78] after is 1 => DBG:tm:t_lookup_request: e2e proxy ACK found => DBG:tm:cleanup_uac_timers: RETR/FR timers reset => DBG:tm:insert_timer_unsafe: [2]: 0x7fdc845becf8 (51) => DBG:tm:t_unref_cell: UNREF_UNSAFE: [0x7fdc845bec78] after is 0 => DBG:b2b_logic:b2bl_parse_key: hash_index = [95] - local_index= [0] => DBG:core:parse_headers: flags=ffffffffffffffff => DBG:core:parse_headers: flags=ffffffffffffffff => DBG:b2b_logic:b2b_logic_notify: b2b_entities notification cb for [95.0] with entity [B2B.407.108.1549535500] => DBG:b2b_logic:b2bl_search_entity: Key [B2B.407.108.1549535500] => DBG:b2b_logic:b2b_logic_notify_request: b2b_entity key = B2B.407.108.1549535500 => DBG:b2b_logic:b2b_logic_notify_request: request received for tuple[0x7fdc845be810]->[95.0] => DBG:b2b_logic:b2b_logic_notify_request: Send request [ACK] to peer [B2B.95.8135310.1549535500] => DBG:b2b_entities:b2b_parse_key: hash_index = [95] - local_index= [8135310] => DBG:b2b_entities:b2b_search_htable_next_dlg: entering with start=(nil), table=0x7fdc845a4128, hash=95, label=8135310 => DBG:b2b_entities:b2b_search_htable_next_dlg: searching callid 25[B2B.95.8135310.1549535500] => DBG:b2b_entities:b2b_search_htable_next_dlg: searching totag 32[42494589cc6520b7535401b81466113d] => DBG:b2b_entities:b2b_search_htable_next_dlg: searching fromtag 14[370SIPpTag0130] => DBG:b2b_entities:b2b_send_request: Send request [ACK] for entity type [1] for dlg[0x7fdc845c43c0]->[B2B.95.8135310.1549535500] => DBG:b2b_entities:b2b_client_build_dlg: Rem_target = sip:172.18.0.4:5060 ;transport=TCP => DBG:b2b_entities:b2b_client_build_dlg: send sock= 172.18.0.2 => DBG:tm:t_uac: next_hop= => DBG:core:mk_proxy: doing DNS lookup... => DBG:tm:t_uac: sending socket is 172.18.0.2 => DBG:tm:dlg2hash: 22720 => DBG:tm:print_request_uri: sip:172.18.0.4:5060;transport=TCP => DBG:core:tcp_conn_get: con found in state 0 => DBG:core:tcp_conn_get: tcp connection found (0x7fdc845c3f68), acquiring fd => DBG:core:tcp_conn_get: c= 0x7fdc845c3f68, n=16, Usock=42 => DBG:core:handle_worker: read response= 7fdc845c3f68, 1, fd -1 from 4 (1827) => DBG:core:tcp_conn_get: after receive_fd: c= 0x7fdc845c3f68 n=8 fd=43 => DBG:core:proto_tcp_send: sending via fd 43... => DBG:core:async_tsend_stream: Async successful write from first try on 0x7fdc845c3f68 => DBG:core:proto_tcp_send: after write: c= 0x7fdc845c3f68 n/len=420/420 fd=43 => DBG:tm:cleanup_uac_timers: RETR/FR timers reset => DBG:tm:insert_timer_unsafe: [2]: 0x7fdc845c48a0 (51) => DBG:core:destroy_avp_list: destroying list (nil) => DBG:core:receive_msg: cleaning up => DBG:core:tcp_read_req: tcp_read_req end => DBG:core:tcp_read_req: Using the global ( per process ) buff => DBG:core:tcp_handle_req: content-length= 0 => DBG:core:tcp_handle_req: Nothing more to read on TCP conn 0x7fdc845be558, currently in state 0 => DBG:core:parse_msg: SIP Request: => DBG:core:parse_msg: method: => DBG:core:parse_msg: uri: => DBG:core:parse_msg: version: => DBG:core:parse_headers: flags=2 => DBG:core:parse_via_param: found param type 232, = ; state=16 => DBG:core:parse_via: end of header reached, state=5 => DBG:core:parse_headers: via found, flags=2 => DBG:core:parse_headers: this is the first via => DBG:core:receive_msg: After parse_msg... => DBG:core:receive_msg: preparing to run routing scripts... => DBG:core:parse_headers: flags=ffffffffffffffff => DBG:core:parse_to_param: tag=B2B.407.108.1549535500 => DBG:core:_parse_to: end of header reached, state=29 => DBG:core:_parse_to: display={sut}, ruri={sip:service at 172.18.0.4:5060} => DBG:core:get_hdr_field: [62]; uri=[sip:service at 172.18.0.4:5060] => DBG:core:get_hdr_field: to body [sut ] => DBG:core:get_hdr_field: cseq : <2> => DBG:core:get_hdr_field: content_length=0 => DBG:core:get_hdr_field: found end of header => DBG:b2b_entities:b2b_prescript_f: start - method = BYE => DBG:b2b_entities:b2b_prescript_f: host:port [172.18.0.4][5060] => DBG:core:grep_sock_info: checking if host==us: 10==10 && [172.18.0.4] == [172.18.0.2] => DBG:core:grep_sock_info: checking if port 5060 matches port 5060 => DBG:core:check_self: host != me => DBG:b2b_entities:b2b_prescript_f: RURI does not point to me => DBG:core:parse_headers: flags=ffffffffffffffff => t_relay - callid 1-382 at 172.18.0.3 time [Thu Feb 7 10:31:41 2019] method (BYE) r-uri (sip:service at 172.18.0.4:5060) 2nd via () /////////////////////////////////// -- Konrad Malewski -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Fri Feb 8 08:53:14 2019 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Fri, 8 Feb 2019 13:53:14 +0000 Subject: [OpenSIPS-Users] error_route not triggering In-Reply-To: <28373bd6-ccc8-1ddb-8d4e-e805ab62e81e@opensips.org> References: <28373bd6-ccc8-1ddb-8d4e-e805ab62e81e@opensips.org> Message-ID: <761C2A10-2E37-4DDA-BA3E-DAA319653257@genesys.com> Bogdan, I have increased the logging level to 6, but unfortunately there is only one new log line that is not helpful. Feb 8 13:37:53 [333] ERROR:core:parse_first_line: bad request first line Feb 8 13:37:53 [333] ERROR:core:parse_first_line: at line 0 char 17: Feb 8 13:37:53 [333] ERROR:core:parse_first_line: parsed so far: INVITE sip:bad to Feb 8 13:37:53 [333] INFO:core:parse_first_line: bad message Feb 8 13:37:53 [333] DBG:core:parse_msg: invalid message Feb 8 13:37:53 [333] ERROR:core:parse_msg: message= Date: Monday, February 4, 2019 at 3:55 AM To: OpenSIPS users mailling list , Ben Newlin Subject: Re: [OpenSIPS-Users] error_route not triggering Hi Ben, There is nothing extra for you to do. The error route should be triggered. You get this error - https://github.com/OpenSIPS/opensips/blob/master/receive.c#L147 and if a request, the error route should be triggered (see line 151). Try to log in debug level, maybe you will get more relevant data. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ On 01/25/2019 12:14 AM, Ben Newlin wrote: Hi, I recently noticed some parsing errors in our logs and after digging further I’ve realized that our error route is not triggering when this occurs. Is there some sort of subscribe or attach operation needed to get calls to the error route? The documentation states it will be called automatically. I’ve been able to reproduce the issue in our testbed. We are running OpenSIPS 2.4.4. My error route is defined like this: error_route { xlog("L_ALERT", "Error route called!\n"); } This is what I get from OpenSIPS logs: Jan 24 21:59:30 [329] ERROR:core:receive_msg: Unable to parse msg received from [203.0.113.4:48096] Jan 24 21:59:30 [336] ERROR:core:parse_first_line: bad request first line Jan 24 21:59:30 [336] ERROR:core:parse_first_line: at line 0 char 17: Jan 24 21:59:30 [336] ERROR:core:parse_first_line: parsed so far: INVITE sip:bad to Jan 24 21:59:30 [336] INFO:core:parse_first_line: bad message Jan 24 21:59:30 [336] ERROR:core:parse_msg: message= SIP/2.0 My log from the error route is not called. Any help would be appreciated. I’m probably missing something simple. Ben Newlin _______________________________________________ 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 markleethomas.esq at gmail.com Fri Feb 8 10:00:57 2019 From: markleethomas.esq at gmail.com (Mark Thomas) Date: Fri, 8 Feb 2019 10:00:57 -0500 Subject: [OpenSIPS-Users] Presence Message-ID: I have just enabled presence but it is not working. The first subscribe I send out is working fine. But it sends a second subscribe out and it responds with a 404.I have nothing in the presentity table. Watchers is populating. I am really at a loss as far as what I have going on here. Any help would be greatly appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Fri Feb 8 10:19:29 2019 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Fri, 8 Feb 2019 15:19:29 +0000 Subject: [OpenSIPS-Users] error_route not triggering In-Reply-To: <761C2A10-2E37-4DDA-BA3E-DAA319653257@genesys.com> References: <28373bd6-ccc8-1ddb-8d4e-e805ab62e81e@opensips.org> <761C2A10-2E37-4DDA-BA3E-DAA319653257@genesys.com> Message-ID: <72C64628-A239-4533-86BB-C4FBBD8381CA@genesys.com> Bogdan, Immediately after sending the below message I noticed this comment in the code you linked: /* if a REQUEST msg was detected (first line was successfully parsed) we should trigger the error route */ In my test I am creating a malformed first line. What is the reason to not trigger the error_route in this case? Would it be possible to make this configurable (or documented)? I have verified that when the parsing error is elsewhere in the message the error route is being triggered. Thanks for pointing me to that code! Ben Newlin From: Users on behalf of Ben Newlin Reply-To: OpenSIPS users mailling list Date: Friday, February 8, 2019 at 8:55 AM To: Bogdan-Andrei Iancu , OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] error_route not triggering Bogdan, I have increased the logging level to 6, but unfortunately there is only one new log line that is not helpful. Feb 8 13:37:53 [333] ERROR:core:parse_first_line: bad request first line Feb 8 13:37:53 [333] ERROR:core:parse_first_line: at line 0 char 17: Feb 8 13:37:53 [333] ERROR:core:parse_first_line: parsed so far: INVITE sip:bad to Feb 8 13:37:53 [333] INFO:core:parse_first_line: bad message Feb 8 13:37:53 [333] DBG:core:parse_msg: invalid message Feb 8 13:37:53 [333] ERROR:core:parse_msg: message= Date: Monday, February 4, 2019 at 3:55 AM To: OpenSIPS users mailling list , Ben Newlin Subject: Re: [OpenSIPS-Users] error_route not triggering Hi Ben, There is nothing extra for you to do. The error route should be triggered. You get this error - https://github.com/OpenSIPS/opensips/blob/master/receive.c#L147 and if a request, the error route should be triggered (see line 151). Try to log in debug level, maybe you will get more relevant data. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ On 01/25/2019 12:14 AM, Ben Newlin wrote: Hi, I recently noticed some parsing errors in our logs and after digging further I’ve realized that our error route is not triggering when this occurs. Is there some sort of subscribe or attach operation needed to get calls to the error route? The documentation states it will be called automatically. I’ve been able to reproduce the issue in our testbed. We are running OpenSIPS 2.4.4. My error route is defined like this: error_route { xlog("L_ALERT", "Error route called!\n"); } This is what I get from OpenSIPS logs: Jan 24 21:59:30 [329] ERROR:core:receive_msg: Unable to parse msg received from [203.0.113.4:48096] Jan 24 21:59:30 [336] ERROR:core:parse_first_line: bad request first line Jan 24 21:59:30 [336] ERROR:core:parse_first_line: at line 0 char 17: Jan 24 21:59:30 [336] ERROR:core:parse_first_line: parsed so far: INVITE sip:bad to Jan 24 21:59:30 [336] INFO:core:parse_first_line: bad message Jan 24 21:59:30 [336] ERROR:core:parse_msg: message= SIP/2.0 My log from the error route is not called. Any help would be appreciated. I’m probably missing something simple. Ben Newlin _______________________________________________ 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 markleethomas.esq at gmail.com Sat Feb 9 11:06:38 2019 From: markleethomas.esq at gmail.com (Mark Thomas) Date: Sat, 9 Feb 2019 11:06:38 -0500 Subject: [OpenSIPS-Users] Presence Message-ID: Alright I've gotten a little farther now with presence. My problem now is whenever a publish is being sent out it sends it to DNS and not routed using the location table. Any input on this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gr.sabery at gmail.com Sun Feb 10 09:28:26 2019 From: gr.sabery at gmail.com (Gholamreza Sabery) Date: Sun, 10 Feb 2019 17:58:26 +0330 Subject: [OpenSIPS-Users] Using sip_trace increases the number of failed_dialogs In-Reply-To: References: Message-ID: Dear Bodgan, Anyway it happens! I use sip_trace with "d" flag. Whenever I enable it, the number of failed dialogs start to increase and when I stop it, this strange thing does not happen anymore. I am using Opensips 2.3.2. Regards On Mon, Feb 4, 2019 at 11:10 AM Bogdan-Andrei Iancu wrote: > Hi, > > Somehow this is hard to believe - the tracing has no impact on the sip > routing (and dialogs). > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 2019 > https://www.opensips.org/events/Summit-2019Amsterdam/ > > On 01/11/2019 05:15 PM, Gholamreza Sabery wrote: > > Hi, > Recently, I tried to integrate OpenSips with Homer5 and it was successful > (using HEPv2). However, when I use sip_trace; the number of > "failed_dialogs" (which is a statistics exported by dialog module) > increases dramatically. Notice that this increase, does not have a negative > effect on the real number of successful calls (CDR statistics). I wonder > why this happens. Any ideas? > > Regards > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Mon Feb 11 22:13:40 2019 From: volga629 at networklab.ca (Slava Bendersky) Date: Mon, 11 Feb 2019 22:13:40 -0500 (EST) Subject: [OpenSIPS-Users] presence and dns In-Reply-To: <28375595.52.1549465117374.JavaMail.bendersky@nlws01.networklab.lan> References: <28375595.52.1549465117374.JavaMail.bendersky@nlws01.networklab.lan> Message-ID: <1770967090.170.1549941217924.JavaMail.bendersky@nlws01.networklab.lan> Hello Everyone, I manage fix route DNS issue for presence NOTIFY But I can't route presence NOTIFY with TLS transport on public leg Text in bold missing ;tranposrt=tls Do I need add local route and catch NOTIFY and add transport=tls ? Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1276]: INFO:presence:update_subscription: notify Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1276]: INFO:presence:send_notify_request: NOTIFY sip:106 at domain.com.tld via sip:106 at public_ip:18156;nat=yes ;ob on behalf of sip:105@ domain.com.tld for event presence, to_tag=656a154e9c9480ea0e92b7b8c389691c-5e5c, cseq=2 Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1276]: INFO:core:probe_max_sock_buff: using snd buffer of 416 kb Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1276]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 88 Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1276]: ERROR:proto_tls:tls_conn_init: no TLS client domain found Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1276]: ERROR:core:tcpconn_new: failed to do proto 3 specific init for conn 0x7f2be9aece58 Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1276]: ERROR:core:tcp_conn_new: tcpconn_new failed Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1276]: ERROR:proto_tls:tls_sync_connect: tcp_conn_create failed, closing the socket Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1276]: ERROR:proto_tls:proto_tls_send: connect failed Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1276]: ERROR:tm:msg_send: send() to public_ip:5081 for proto tls/3 failed Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1276]: ERROR:tm:t_forward_nonack: sending request failed Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1276]: ERROR:tm:w_t_relay: t_forward_nonack failed Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1280]: INFO:core:probe_max_sock_buff: using snd buffer of 416 kb Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1280]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 109 Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1277]: ERROR:proto_tls:tls_accept: New TLS connection from public_ip:49523 failed to accept Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1277]: ERROR:proto_tls:tls_read_req: failed to do pre-tls reading Feb 11 22:03:17 vprx00 /usr/sbin/opensips[1276]: WARNING:presence:p_tm_callback: completed with status [500] and to_tag [656a154e9c9480ea0e92b7b8c389691c-5e5c], cseq [CSeq: 2] volga629 ----- Original Message ----- From: "Slava Bendersky" To: "OpenSIPS users mailling list" Sent: Wednesday, February 6, 2019 10:58:38 AM Subject: [OpenSIPS-Users] presence and dns Hello Everyone, How to avoid dns look up while NOTIFY is trying to reach end point for presence subscriber. Feb 5 15:15:42 vprx00 /usr/sbin/opensips[3889]: INFO:presence:update_subscription: notify Feb 5 15:15:42 vprx00 /usr/sbin/opensips[3889]: INFO:presence:send_notify_request: NOTIFY sip:106 at domain.com via sip:106 at 158.69.151.88:58924;nat=yes;ob on behalf of sip:105@ domain.com for event presence, to_tag=656a154e9c9480ea0e92b7b8c389691c-0448, cseq=1 Feb 5 15:15:42 vprx00 /usr/sbin/opensips[3889]: CRITICAL:core:mk_proxy: could not resolve hostname: " domain.com " Feb 5 15:15:42 vprx00 /usr/sbin/opensips[3889]: ERROR:tm:uri2proxy: bad host name in URI Feb 5 15:15:42 vprx00 /usr/sbin/opensips[3889]: ERROR:tm:t_forward_nonack: failure to add branches Feb 5 15:15:42 vprx00 /usr/sbin/opensips[3889]: ERROR:tm:w_t_relay: t_forward_nonack failed Also Pua Dialog Info producing the error of extra parameters Feb 5 15:42:21 vprx00 /usr/sbin/opensips[4137]: ERROR:pua_dialoginfo:pack_cb_params: Failed to parse peer nameaddr [sip:105 at 10.30.100.41:5060#015#012] Feb 5 15:42:21 vprx00 /usr/sbin/opensips[4137]: ERROR:pua_dialoginfo:dialoginfo_set: Failed to allocate parameters Feb 5 18:27:20 vprx00 /usr/sbin/opensips[5451]: ERROR:pua_dialoginfo:pack_cb_params: Failed to parse peer nameaddr [sip:033003535812 at eficart.colpbx.com#015#012] Feb 5 18:27:20 vprx00 /usr/sbin/opensips[5451]: ERROR:pua_dialoginfo:dialoginfo_set: Failed to allocate parameters volga629 _______________________________________________ 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 xaled at web.de Tue Feb 12 08:02:00 2019 From: xaled at web.de (xaled) Date: Tue, 12 Feb 2019 14:02:00 +0100 Subject: [OpenSIPS-Users] Use of multiple outgoing TCP Trunks with B2B Message-ID: <005501d4c2d3$24da6ed0$6e8f4c70$@web.de> Hello, We have a use case with some specific requirements on the TCP connection usage by the outgoing register trunk. Requirements are imposed by the service provider and cannot be modified by us. a) Trunk must use TCP. b) There has to be a registration over an established TCP connection. c) INVITEs can be send only over established TCP connection that was previously used for successful registration. I managed to get around this limitations by using uac_registrant and b2b modules. I also set tcp_connection_lifetime=3600 to have the TCP connection open for a pretty long time between possible SIP communications. B2B module reuses TCP connection established by uac_registrant and it works so far. Now there is another limitation on this trunk and it is the number of parallel calls. We need more parallel calls then a single trunk is allowed to have. We can have additional trunks and multiply the capacity. I added additional trunk credentials to the uac_registrant DB and multiple registrations are successfully established. Here come the problems: 1) outgoing INVITE does not reuse any of the established TCP connection. Instead the new TCP connection is established. 2) Even if INVITE would reuse one of the established TCP connections the credentials used by INVITE have to match the ones that were used during the registration. Is there anything that can be done to correlate TCP connections and credentials between uac_registrant and B2B modules? In our case It would be enough to have a random pick of registered trunk with established TCP connection and relevant credentials for every forwarded INVITE to use additional capacity given by additional trunks. Thanks, Xaled From johan at democon.be Tue Feb 12 15:29:34 2019 From: johan at democon.be (johan de clercq) Date: Tue, 12 Feb 2019 21:29:34 +0100 Subject: [OpenSIPS-Users] tls -> udp Message-ID: <002201d4c311$ab007020$01015060$@democon.be> Hello Using opensips 2.4.4, Phone -> tls and srtp -> opensips -> udp -> provider I have a socket on 5061 tls and a socket on 5060 udp and mhomed is one, Call arrives in opensips but is not correctly routed to the provider. Feb 12 21:20:47 ns3012072 /usr/local/opensips/sbin/opensips[7140]: DBG:tm:run_trans_callbacks: trans=0x7ff70a24dc68, callback type 4, id 1 entered Feb 12 21:20:47 ns3012072 /usr/local/opensips/sbin/opensips[7140]: DBG:dialog:dlg_update_contact: Using the same contact for dialog 0x7ff70a24bdd8 on leg 0 Feb 12 21:20:47 ns3012072 /usr/local/opensips/sbin/opensips[7140]: DBG:core:mk_proxy: doing DNS lookup... Feb 12 21:20:47 ns3012072 /usr/local/opensips/sbin/opensips[7140]: DBG:core:sip_resolvehost: no port, has proto -> do SRV lookup! Feb 12 21:20:47 ns3012072 /usr/local/opensips/sbin/opensips[7140]: DBG:core:get_record: lookup(_sips._tcp. That is logic as the provider doesn't listen on tcp. How can I force opensips to relay from tls on the phone to udp at the provider ? Small homer trace in attachment. Johan De Clercq, Managing Director Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke Tel +3256980990 - GSM +32478720104 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 15602 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: HOMER5-5.135.140.139-003215666666-2_12_2019 21_14_39.pcap Type: application/octet-stream Size: 2740 bytes Desc: not available URL: From volga629 at networklab.ca Tue Feb 12 20:50:33 2019 From: volga629 at networklab.ca (Slava Bendersky) Date: Tue, 12 Feb 2019 20:50:33 -0500 (EST) Subject: [OpenSIPS-Users] Mid-Registrar REGISTER with Auth header In-Reply-To: <1022086004.452.1550021459697.JavaMail.bendersky@nlws01.networklab.lan> Message-ID: <11622003.477.1550022629695.JavaMail.bendersky@nlws01.networklab.lan> Hello Everyone, When REGISTER with Auth header ( registration update ) is send out contact header is not rewritten. Is this normal behavior ? Mid-Registrar is operation mode 2 #### REGISTRAR module loadmodule "mid_registrar.so" modparam("mid_registrar", "mode", 2) modparam("mid_registrar", "received_avp", "$avp(RECEIVED)") modparam("mid_registrar", "max_contacts", 10) modparam("mid_registrar", "tcp_persistent_flag", "TCP_PERSIST_REGISTRATIONS") modparam("mid_registrar", "outgoing_expires", 7200) 2019/02/12 20:05:47.343433 10.30.100.41:5060 -> 10.30.100.49:5160 REGISTER sip:domain.com:5160 SIP/2.0 Via: SIP/2.0/UDP 10.30.100.41:5060;branch=z9hG4bKdc87.52e497f3.0;i=6d42cd15 Via: SIP/2.0/TLS 192.168.1.58:5070;received=186.146.92.92;branch=z9hG4bK687754333;rport=48658;alias Route: From: ;tag=1228599454 To: Call-ID: 943618234-5070-1 at BJC.BGI.B.FI CSeq: 2004 REGISTER Contact: ;reg-id=6;+sip.instance="" Authorization: Digest username="106", realm="domain.com", nonce="0f668738-a4cd-4ede-9767-51439035aad0", uri="sip:domain.com:5160", response="27d5335eb36c0f0c 6c6d62c6f564fe", algorithm=MD5, cnonce="01204462", qop=auth, nc=00000004 X-Grandstream-PBX: true Max-Forwards: 69 User-Agent: Grandstream GXP2160 1.0.9.127 Expires: 180 Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE Content-Length: 0 Supported: path Path: -------------- next part -------------- An HTML attachment was scrubbed... URL: From pasandev at ymail.com Wed Feb 13 02:36:44 2019 From: pasandev at ymail.com (Pasan Meemaduma) Date: Wed, 13 Feb 2019 07:36:44 +0000 (UTC) Subject: [OpenSIPS-Users] locally generated replies References: <1287564603.96397.1550043404698.ref@mail.yahoo.com> Message-ID: <1287564603.96397.1550043404698@mail.yahoo.com> Hi Guys, How's it possible locally generated replied triggering on_reply_route ? I ran in to issue where all opensips process gets stuck in processing same call replies and causing other traffic to get drop. /usr/sbin/opensips[27464]: Call: Reply from a NAT endpoint - S=408 D=Request Timeout F=sip:xxx at xxx T=sip:yyy yy at x IP=a.b.c.d ID=asgasgasgas Request process by opensips before this is an ACK request belong to the call where I don't think It'll expect a reply. Could it be an issue If I call t_on_reply on an ACK msg ? I'm trying to figure out where the bug in my opensips routing script.  It causes all sip listerner processes to get stuck in a loop causing to generate above message. IP a.b.c.d is the sip server IP which confuse me as locally generated replies shouldn't trigger on_reply_route as per docs. Any clue is welcome. I'm using opensips 2.3.6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.quick at smartvox.co.uk Wed Feb 13 04:15:57 2019 From: john.quick at smartvox.co.uk (John Quick) Date: Wed, 13 Feb 2019 09:15:57 -0000 Subject: [OpenSIPS-Users] tls -> udp Message-ID: <000101d4c37c$baa47c90$2fed75b0$@smartvox.co.uk> Hi Johan, I've configured Proxy servers to do this a few times. You should do the following: 1) For Requests going from TLS to UDP, change any occurrence of "transport=tls" in the R-URI parameters. I use the following to do this: subst_uri('/transport=tls/transport=udp/I'); 2) Make sure OpenSIPS adds correct Record-Route headers. Default behaviour in this case is to add 2 RR headers when you call record_route(). Make sure double_rr has not been disabled in the modparam section. One header describes the TLS socket and the other header describes the UDP socket. These are needed for sequential Loose-Routed requests later in the dialogue. 3) Just before you relay the request over UDP, call the force_send_socket() function. For example: force_send_socket(udp:12.34.56.78:5060); Hope this helps. John Quick Smartvox Limited From vitalik.voip at gmail.com Wed Feb 13 08:09:17 2019 From: vitalik.voip at gmail.com (Vitalii Aleksandrov) Date: Wed, 13 Feb 2019 15:09:17 +0200 Subject: [OpenSIPS-Users] rtpengine_manage() fails when called from failure_route[] with additional flags. Message-ID: <42e3b7d1-9817-a316-edff-3a3f71483471@gmail.com> Hi, I use only rtpengine_manage() function of rtpengine_{offer,answer,delete} and it is called from different locations like request_route, onreply_route, failure_route. To have everything in one place I call a route[RTPENGINE_MANAGE] which in its turn prepares rtpengine parameters string (ICE, profiles, flags) and calls rtpengine_manage(). When this route is called from failure_route rtpengine_manage() is supposed to behave like rtpengine_delete() and it does. The only problem is that when it receives flags in its parameters string (no-rtcp-attribute in my case) it fails with "rtpengine:parse_flags: error processing flag `no-rtcp-attribute': no more memory" message instead of just ignoring useless for delete operation parameters. Attaching the patch that fixed this problem for me. Not sure if this is a bug or lack of module documentation. -------------- next part -------------- A non-text attachment was scrubbed... Name: rtpengine_delete.diff Type: text/x-patch Size: 918 bytes Desc: not available URL: From farmorg at gmail.com Wed Feb 13 09:30:44 2019 From: farmorg at gmail.com (Mark Farmer) Date: Wed, 13 Feb 2019 14:30:44 +0000 Subject: [OpenSIPS-Users] RTPProxy No Audio on Outbound Calls Message-ID: Hello everyone, all help gratefully received, I've been slogging away at this for ages! I have OpenSIPS 2.4.4 & RTPProxy behind 1:1 NAT's (different hosts). RTPProxy runs so: /usr/local/bin/rtpproxy -s unix:/var/run/rtpproxy/rtpproxy.sock -u rtpproxy rtpproxy -p /var/run/rtpproxy/rtpproxy.pid -s udp:10.96.16.58 7722 -l 10.96.0.58 10.98.0.58 -A ext.ip.addr.ess 10.98.0.58 -d DBUG LOG_LOCAL0 -m 10000 -M 20000 OpenSIPS is sitting between my provider & an Asterisk server which has phones registered. When I make calls 'Provider -> OpenSIPS/RTPProxy -> Asterisk -> Phone' all is good, 2 way audio. But when the call flows in the opposite direction, I get no audio since SDP is the same as the 1st call. How do I get it to reverse the rtpproxy_offer/answer flags? These are the bits that handles it all: route[RTPPROXY] { if (is_method("BYE|CANCEL")) { rtpproxy_unforce(); } if (is_method("INVITE")) { rtpproxy_offer("corwfie"); } } onreply_route[DROUTING] { if (is_method("BYE|CANCEL")) { sip_trace("tid","d"); rtpproxy_unforce(); } if ($rs=~"(2[0-9][0-9])") { rtpproxy_answer("corwfei"); } } -- Mark Farmer farmorg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.quick at smartvox.co.uk Wed Feb 13 12:53:54 2019 From: john.quick at smartvox.co.uk (John Quick) Date: Wed, 13 Feb 2019 17:53:54 -0000 Subject: [OpenSIPS-Users] RTPProxy No Audio on Outbound Calls Message-ID: <004301d4c3c5$15e415f0$41ac41d0$@smartvox.co.uk> Mark, You can detect if the INVITE came from your Asterisk by testing the $si pseudo-variable. That will allow you to identify the direction of the call. I usually set a flag for this purpose. For example: If ($si == "my.ast.er.isk") setflag(DIR_OUT); At the point where you engage the rtpproxy, you will then be able to reverse the internal/external parameters for the function call depending on the direction of the call If (isflagset(DIR_OUT)) { rtpproxy_offer("corfei"); } else { rtpproxy_offer("corfie"); } The same flag should still be valid in the onreply handler where you can do something similar. [Not sure if I have ie/ei the right way round in my example]. That said, I'm not sure this topology is a good one to be using. I would generally try to avoid having the media proxy behind NAT and also using it in bridging mode - it makes life too complicated. P.S. Looks like you sorted out the problems with the call to do_routing(). John Quick Smartvox Limited From mickael at winlux.fr Wed Feb 13 14:22:49 2019 From: mickael at winlux.fr (Mickael Hubert) Date: Wed, 13 Feb 2019 20:22:49 +0100 Subject: [OpenSIPS-Users] Check config files before stop opensips service Message-ID: I would like to know, if there is a way to check opensips's config files before stop service. Ex: If I do a syntax error into cfg files (with opensips started), I want to "ban" the daemon shutdown (service opensips stop) I'm playing with opensips.service and opensips -C -f $config to try to reach my goal, but I'm not be able to do at this moment... Do you have an idea please ? Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Wed Feb 13 15:33:33 2019 From: farmorg at gmail.com (Mark Farmer) Date: Wed, 13 Feb 2019 20:33:33 +0000 Subject: [OpenSIPS-Users] Confused about rtpproxy_offer() w/s Flags Message-ID: I'm struggling to understand the w & s flags to rtpproxy_offer etc. The documentation is a little unclear, is there any difference between the two? I seem to have had better results using w but I don't understand why that might be. TIA Mark. -- Mark Farmer farmorg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Fri Feb 15 04:54:23 2019 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Fri, 15 Feb 2019 11:54:23 +0200 Subject: [OpenSIPS-Users] rtpengine_manage() fails when called from failure_route[] with additional flags. In-Reply-To: <42e3b7d1-9817-a316-edff-3a3f71483471@gmail.com> References: <42e3b7d1-9817-a316-edff-3a3f71483471@gmail.com> Message-ID: Hi, Vitalii! It looks you are running out of memory. Make sure you have properly adjusted opensips with enough private memory. I don't think your patch is correct, since it does not parse flags for delete commands, although someone might need them. Best regards, Razvan On 2/13/19 3:09 PM, Vitalii Aleksandrov wrote: > Hi, > > I use only rtpengine_manage() function of > rtpengine_{offer,answer,delete} and it is called from different > locations like request_route, onreply_route, failure_route. > > To have everything in one place I call a route[RTPENGINE_MANAGE] which > in its turn prepares rtpengine parameters string (ICE, profiles, flags) > and calls rtpengine_manage(). When this route is called from > failure_route rtpengine_manage() is supposed to behave like > rtpengine_delete() and it does. The only problem is that when it > receives flags in its parameters string (no-rtcp-attribute in my case) > it fails with "rtpengine:parse_flags: error processing flag > `no-rtcp-attribute': no more memory" message instead of just ignoring > useless for delete operation parameters. > > Attaching the patch that fixed this problem for me. Not sure if this is > a bug or lack of module documentation. > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com Meet the OpenSIPS team at the next OpenSIPS Summit: https://www.opensips.org/events From razvan at opensips.org Fri Feb 15 04:57:34 2019 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Fri, 15 Feb 2019 11:57:34 +0200 Subject: [OpenSIPS-Users] Check config files before stop opensips service In-Reply-To: References: Message-ID: <0622a617-5fe6-74b8-b953-709f6564710e@opensips.org> Hi, Mickael! You can use either -C and -c parameters when starting OpenSIPS to check the config syntax. If you want to check it before stopping OpenSIPS, you'll have to adjust your opensips.service file to run a different ExecStop command, something like `/usr/sbin/opensips -C -f /etc/opensips/opensips.cfg && /usr/bin/pkill --pidfile %t/opensips/opensips.pid` Hope this helps! Răzvan On 2/13/19 9:22 PM, Mickael Hubert wrote: > I would like to know, if there is a way to check opensips's config files > before stop service. > Ex: If I do a syntax error into cfg files (with opensips started), I > want to "ban" the daemon shutdown (service opensips stop) > > I'm playing with opensips.service and opensips -C -f $config to try to > reach my goal, but I'm not be able to do at this moment... > > Do you have an idea please ? > Thanks in advance > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com Meet the OpenSIPS team at the next OpenSIPS Summit: https://www.opensips.org/events From razvan at opensips.org Fri Feb 15 04:59:18 2019 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Fri, 15 Feb 2019 11:59:18 +0200 Subject: [OpenSIPS-Users] Confused about rtpproxy_offer() w/s Flags In-Reply-To: References: Message-ID: <696e8eab-e652-bbee-7d0a-43840c701d5d@opensips.org> No, there is no difference between the w and s flags, they both activate symmetric NAT - the default behavior in rtpproxy, except started with -a (async). Best regards, Răzvan On 2/13/19 10:33 PM, Mark Farmer wrote: > I'm struggling to understand the w & s flags to rtpproxy_offer etc. > > The documentation is a little unclear, is there any difference between > the two? I seem to have had better results using w but I don't > understand why that might be. > > TIA > Mark. > > -- > Mark Farmer > farmorg at gmail.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com Meet the OpenSIPS team at the next OpenSIPS Summit: https://www.opensips.org/events From farmorg at gmail.com Fri Feb 15 11:05:45 2019 From: farmorg at gmail.com (Mark Farmer) Date: Fri, 15 Feb 2019 16:05:45 +0000 Subject: [OpenSIPS-Users] Confused about rtpproxy_offer() w/s Flags In-Reply-To: <696e8eab-e652-bbee-7d0a-43840c701d5d@opensips.org> References: <696e8eab-e652-bbee-7d0a-43840c701d5d@opensips.org> Message-ID: Thank you for the clarification, much appreciated. Mark. On Fri, 15 Feb 2019 at 10:02, Răzvan Crainea wrote: > No, there is no difference between the w and s flags, they both activate > symmetric NAT - the default behavior in rtpproxy, except started with -a > (async). > > Best regards, > Răzvan > > On 2/13/19 10:33 PM, Mark Farmer wrote: > > I'm struggling to understand the w & s flags to rtpproxy_offer etc. > > > > The documentation is a little unclear, is there any difference between > > the two? I seem to have had better results using w but I don't > > understand why that might be. > > > > TIA > > Mark. > > > > -- > > Mark Farmer > > farmorg at gmail.com > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > -- > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > Meet the OpenSIPS team at the next OpenSIPS Summit: > https://www.opensips.org/events > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Mark Farmer farmorg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mickael at winlux.fr Fri Feb 15 13:54:22 2019 From: mickael at winlux.fr (Mickael Hubert) Date: Fri, 15 Feb 2019 19:54:22 +0100 Subject: [OpenSIPS-Users] Check config files before stop opensips service In-Reply-To: <0622a617-5fe6-74b8-b953-709f6564710e@opensips.org> References: <0622a617-5fe6-74b8-b953-709f6564710e@opensips.org> Message-ID: Hi, thanks for your answer I already tried to this: `/usr/sbin/opensips -C -f /etc/opensips/opensips.cfg && /usr/bin/pkill --pidfile %t/opensips/opensips.pid` But even I have a syntax error before stop, the opensips check exit with error, but daemon is killed anyway. Even I havn't ExecStop, daemon is killed... I don't know why :( I will check in depth ;) ++ Le ven. 15 févr. 2019 à 10:58, Răzvan Crainea a écrit : > Hi, Mickael! > > You can use either -C and -c parameters when starting OpenSIPS to check > the config syntax. If you want to check it before stopping OpenSIPS, > you'll have to adjust your opensips.service file to run a different > ExecStop command, something like `/usr/sbin/opensips -C -f > /etc/opensips/opensips.cfg && /usr/bin/pkill --pidfile > %t/opensips/opensips.pid` > > Hope this helps! > Răzvan > > On 2/13/19 9:22 PM, Mickael Hubert wrote: > > I would like to know, if there is a way to check opensips's config files > > before stop service. > > Ex: If I do a syntax error into cfg files (with opensips started), I > > want to "ban" the daemon shutdown (service opensips stop) > > > > I'm playing with opensips.service and opensips -C -f $config to try to > > reach my goal, but I'm not be able to do at this moment... > > > > Do you have an idea please ? > > Thanks in advance > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > -- > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > Meet the OpenSIPS team at the next OpenSIPS Summit: > https://www.opensips.org/events > > _______________________________________________ > 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 johan at democon.be Sun Feb 17 06:35:01 2019 From: johan at democon.be (johan de clercq) Date: Sun, 17 Feb 2019 12:35:01 +0100 Subject: [OpenSIPS-Users] opensips 2.4.4: bug in tls_mgm Message-ID: <00b901d4c6b4$d232bb20$76983160$@democon.be> Hi, I believe that I have found a bug in tls_mgm: Using opensips default certificates: /usr/local/opensips/etc/opensips/tls# ls -lu total 24 -rw-r--r-- 1 root staff 2049 Feb 17 12:13 ca.conf -rw-r--r-- 1 root staff 1048 Feb 17 12:13 README -rw-r--r-- 1 root staff 1127 Feb 17 12:13 request.conf drwxr-sr-x 4 root staff 4096 Feb 17 12:16 rootCA drwxr-sr-x 2 root staff 4096 Feb 17 12:13 user -rw-r--r-- 1 root staff 591 Feb 17 12:13 user.conf /usr/local/opensips/etc/opensips/tls/rootCA# ls cacert.pem certs index.txt private serial Tls params: loadmodule "tls_mgm.so" modparam("tls_mgm", "server_domain", "sv_dom=5.135.140.139:5061") modparam("tls_mgm", "require_cert", "[sv_dom]0") modparam("tls_mgm", "verify_cert", "[sv_dom]0") modparam("tls_mgm", "tls_method", "[sv_dom]SSLv23") modparam("tls_mgm", "certificate", "[sv_dom]/usr/local/opensips/etc/opensips/tls/rootCA/cacert.pem") modparam("tls_mgm", "private_key", "[sv_dom]/usr/local/opensips/etc/opensips/tls/rootCA/private/cakey.pem") modparam("tls_mgm", "ca_list", "[sv_dom]/usr/local/opensips/etc/opensips/tls/rootCA/cacert.pem") #### PROTO_TLS module loadmodule "proto_tls.so" modparam("proto_tls", "trace_destination", "hep_dest") modparam("proto_tls", "trace_on", 1) I removed the passphrase: mv etc/tls/rootCA/private/cakey.pem etc/tls/rootCA/private/cakey.pem.protected openssl rsa -in etc/tls/rootCA/private/cakey.pem.protected -out etc/tls/rootCA/private/cakey.pem and then tried to run opensips from cmdline : ./opensips -f /usr/local/opensips/etc/opensips/opensips.cfg syslog output: Feb 17 12:22:01 ns3012072 ./opensips[28673]: ERROR:tls_mgm:load_certificate: unable to load certificate file '/usr/local/opensips//etc/opensips/tls/cert.pem' Feb 17 12:22:01 ns3012072 ./opensips[28673]: ERROR:tls_mgm:init_tls_domains: Failed to init TLS domain 'default' Feb 17 12:22:01 ns3012072 ./opensips[28673]: ERROR:core:init_mod: failed to initialize module tls_mgm Feb 17 12:22:01 ns3012072 ./opensips[28673]: ERROR:core:main: error while initializing modules Feb 17 12:22:01 ns3012072 ./opensips[28673]: CRITICAL:core:sig_usr: segfault in attendant (starter) process! Feb 17 12:22:01 ns3012072 kernel: [ 4024.678398] opensips[28673]: segfault at 7fcb76dbf850 ip 00007fcb76546f69 sp 00007ffe803ac150 error 4 in libcrypto.so.1.1[7fcb763df000+265000] Next I tried with: loadmodule "tls_mgm.so" #modparam("tls_mgm", "server_domain", "sv_dom=5.135.140.139:5061") modparam("tls_mgm", "require_cert", "0") modparam("tls_mgm", "verify_cert", "0") modparam("tls_mgm", "tls_method", "SSLv23") modparam("tls_mgm", "certificate", "/usr/local/opensips/etc/opensips/tls/rootCA/cacert.pem") modparam("tls_mgm", "private_key", "/usr/local/opensips/etc/opensips/tls/rootCA/private/cakey.pem") modparam("tls_mgm", "ca_list", "/usr/local/opensips/etc/opensips/tls/rootCA/cacert.pem") #### PROTO_TLS module loadmodule "proto_tls.so" modparam("proto_tls", "trace_destination", "hep_dest") modparam("proto_tls", "trace_on", 1) and then opensips starts. Can you please explain what I am doing wrong ? Johan De Clercq, Managing Director Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke Tel +3256980990 - GSM +32478720104 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 15602 bytes Desc: not available URL: From jehanzaib.kiani at gmail.com Mon Feb 18 03:11:19 2019 From: jehanzaib.kiani at gmail.com (J E H A N Z A I B) Date: Mon, 18 Feb 2019 21:11:19 +1300 Subject: [OpenSIPS-Users] uac registrant module issue Message-ID: Hi folks, I am facing a weird issue. can anyone help me please? opensips 2.2.2 with the below config. Trying to register my sip provider trunk on our opensips. loadmodule "uac_registrant.so" modparam("uac_registrant", "hash_size", 2) modparam("uac_registrant", "timer_interval", 120) modparam("uac_registrant", "db_url", "mysql://mydbuser:pass at databasename /mydb") modparam("uac_registrant", "table_name", "registrant") modparam("uac_registrant", "username_column", "username") modparam("uac_registrant", "password_column", "password") modparam("uac_registrant", "expiry_column", "expiry") modparam("uac_registrant", "aor_column", "aor") modparam("uac_registrant", "proxy_column", "proxy") Here is the table structure. | id | registrar | proxy | aor | third_party_registrant | username | password| binding_URI | binding_params | expiry | forced_socket When i reload: opensipsctl fifo reg_reload Feb 18 20:39:56 sbc1 /usr/sbin/opensips[14223]: DBG:db_mysql:db_mysql_str2val: converting INT [180] Feb 18 20:39:56 sbc1 /usr/sbin/opensips[14223]: INFO:uac_registrant:load_reg_info_from_db: loading [1] records from db Feb 18 20:39:56 sbc1 /usr/sbin/opensips[14223]: ERROR:core:parse_uri: bad uri, state 0 parsed: (4) / (22) Feb 18 20:39:56 sbc1 /usr/sbin/opensips[14223]: ERROR:uac_registrant:load_reg_info_from_db: cannot parse registrar uri [ test0102-p01.mytestprovider.com] Regards, Jehanzaib -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johan at democon.be Mon Feb 18 03:31:59 2019 From: Johan at democon.be (Johan De Clercq) Date: Mon, 18 Feb 2019 09:31:59 +0100 Subject: [OpenSIPS-Users] uac registrant module issue In-Reply-To: References: Message-ID: where is @ ? Op ma 18 feb. 2019 om 09:14 schreef J E H A N Z A I B < jehanzaib.kiani at gmail.com>: > Hi folks, > > I am facing a weird issue. can anyone help me please? > > opensips 2.2.2 with the below config. Trying to register my sip provider > trunk on our opensips. > > loadmodule "uac_registrant.so" > modparam("uac_registrant", "hash_size", 2) > modparam("uac_registrant", "timer_interval", 120) > modparam("uac_registrant", "db_url", "mysql://mydbuser:pass at databasename > /mydb") > modparam("uac_registrant", "table_name", "registrant") > modparam("uac_registrant", "username_column", "username") > modparam("uac_registrant", "password_column", "password") > modparam("uac_registrant", "expiry_column", "expiry") > modparam("uac_registrant", "aor_column", "aor") > modparam("uac_registrant", "proxy_column", "proxy") > > Here is the table structure. > | id | registrar | proxy | aor | third_party_registrant | username | > password| binding_URI | binding_params | expiry | forced_socket > When i reload: opensipsctl fifo reg_reload > Feb 18 20:39:56 sbc1 /usr/sbin/opensips[14223]: > DBG:db_mysql:db_mysql_str2val: converting INT [180] > Feb 18 20:39:56 sbc1 /usr/sbin/opensips[14223]: > INFO:uac_registrant:load_reg_info_from_db: loading [1] records from db > Feb 18 20:39:56 sbc1 /usr/sbin/opensips[14223]: ERROR:core:parse_uri: bad > uri, state 0 parsed: (4) / (22) > Feb 18 20:39:56 sbc1 /usr/sbin/opensips[14223]: > ERROR:uac_registrant:load_reg_info_from_db: cannot parse registrar uri [ > test0102-p01.mytestprovider.com] > > > Regards, > Jehanzaib > _______________________________________________ > 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 jehanzaib.kiani at gmail.com Mon Feb 18 03:52:27 2019 From: jehanzaib.kiani at gmail.com (J E H A N Z A I B) Date: Mon, 18 Feb 2019 21:52:27 +1300 Subject: [OpenSIPS-Users] uac registrant module issue In-Reply-To: References: Message-ID: Hi Johan, This is a registrar field which does not have @ do you want me to change it to username at host? On Mon, Feb 18, 2019 at 9:32 PM Johan De Clercq wrote: > where is @ ? > > Op ma 18 feb. 2019 om 09:14 schreef J E H A N Z A I B < > jehanzaib.kiani at gmail.com>: > >> Hi folks, >> >> I am facing a weird issue. can anyone help me please? >> >> opensips 2.2.2 with the below config. Trying to register my sip provider >> trunk on our opensips. >> >> loadmodule "uac_registrant.so" >> modparam("uac_registrant", "hash_size", 2) >> modparam("uac_registrant", "timer_interval", 120) >> modparam("uac_registrant", "db_url", "mysql://mydbuser:pass at databasename >> /mydb") >> modparam("uac_registrant", "table_name", "registrant") >> modparam("uac_registrant", "username_column", "username") >> modparam("uac_registrant", "password_column", "password") >> modparam("uac_registrant", "expiry_column", "expiry") >> modparam("uac_registrant", "aor_column", "aor") >> modparam("uac_registrant", "proxy_column", "proxy") >> >> Here is the table structure. >> | id | registrar | proxy | aor | third_party_registrant | username | >> password| binding_URI | binding_params | expiry | forced_socket >> When i reload: opensipsctl fifo reg_reload >> Feb 18 20:39:56 sbc1 /usr/sbin/opensips[14223]: >> DBG:db_mysql:db_mysql_str2val: converting INT [180] >> Feb 18 20:39:56 sbc1 /usr/sbin/opensips[14223]: >> INFO:uac_registrant:load_reg_info_from_db: loading [1] records from db >> Feb 18 20:39:56 sbc1 /usr/sbin/opensips[14223]: ERROR:core:parse_uri: bad >> uri, state 0 parsed: (4) / >> (22) >> Feb 18 20:39:56 sbc1 /usr/sbin/opensips[14223]: >> ERROR:uac_registrant:load_reg_info_from_db: cannot parse registrar uri [ >> test0102-p01.mytestprovider.com] >> >> >> Regards, >> Jehanzaib >> _______________________________________________ >> 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 > -- Regards, Jehanzaib -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurgan-rus at inbox.ru Mon Feb 18 06:08:01 2019 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Mon, 18 Feb 2019 14:08:01 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?uac_registrant_module_issue?= In-Reply-To: References: Message-ID: <1550488081.57616697@f526.i.mail.ru> Hi, Jehanzaib! Could you paste here the SELECT from your DB? Please set vertical oputput in your DB if possible ( \x for PGSQL, \G for MySQL). Here's a working example: opensips=> select * from sipgw01_registrant ORDER BY id DESC LIMIT 1; -[ RECORD 1 ]----------+------------------------------- id | 186 registrar | sip:999.201.888.35 proxy | aor | sip:7xxxzzz3333 at multifon.ru third_party_registrant | username | 7xxxzzz3333 password | mEgApAsS binding_uri | sip:7xxxzzz3333 at 999.209.888.74 binding_params | expiry | 180 forced_socket | ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/ From kurgan-rus at inbox.ru Mon Feb 18 06:13:52 2019 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Mon, 18 Feb 2019 14:13:52 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?uac_registrant_module_issue?= In-Reply-To: <1550488081.57616697@f526.i.mail.ru> References: <1550488081.57616697@f526.i.mail.ru> Message-ID: <1550488432.798459812@f515.i.mail.ru> Oh, it seems that either webserver/browsers change the 'at' sign to 'at' word (preposition). In my DB output there is no 'at' word, there's a proper sign like in e-mail address. Maybe you faced the same here in list and the actual problem is somewhere else. A screenshot/SIP debug can also be useful. ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/ From vitalik.voip at gmail.com Mon Feb 18 06:33:15 2019 From: vitalik.voip at gmail.com (Vitalii Aleksandrov) Date: Mon, 18 Feb 2019 13:33:15 +0200 Subject: [OpenSIPS-Users] rtpengine_manage() fails when called from failure_route[] with additional flags. In-Reply-To: References: <42e3b7d1-9817-a316-edff-3a3f71483471@gmail.com> Message-ID: <7b7a0987-5238-ac9c-e2db-e346425bc0ec@gmail.com> Hi Razvan, It's not a memory issue. If you check a few lines higher before my patch you'll find this: >         if (op == OP_OFFER || op == OP_ANSWER) { >                 ng_flags.flags = bencode_list(bencbuf); >                 ....... >         } ng_flags.flags bencode list is created only for OP_OFFER and OP_ANSWER and stays NULL for OP_DELETE operation. That's the reason why flags parsing fails for delete. From jehanzaib.kiani at gmail.com Mon Feb 18 06:45:01 2019 From: jehanzaib.kiani at gmail.com (J E H A N Z A I B) Date: Tue, 19 Feb 2019 00:45:01 +1300 Subject: [OpenSIPS-Users] uac registrant module issue In-Reply-To: <1550488081.57616697@f526.i.mail.ru> References: <1550488081.57616697@f526.i.mail.ru> Message-ID: Thank you ALex. I actually did not have sip: at the start in the registrar. Let me update the values in the database and test it out. Will get back to you shortly. Ty On Tue, Feb 19, 2019 at 12:11 AM Alexey Kazantsev via Users < users at lists.opensips.org> wrote: > Hi, Jehanzaib! > > Could you paste here the SELECT from your DB? > > Please set vertical oputput in your DB if possible > ( \x for PGSQL, \G for MySQL). > > Here's a working example: > > opensips=> select * from sipgw01_registrant ORDER BY id DESC LIMIT 1; > -[ RECORD 1 ]----------+------------------------------- > id | 186 > registrar | sip:999.201.888.35 > proxy | > aor | sip:7xxxzzz3333 at multifon.ru > third_party_registrant | > username | 7xxxzzz3333 > password | mEgApAsS > binding_uri | sip:7xxxzzz3333 at 999.209.888.74 > binding_params | > expiry | 180 > forced_socket | > > > ----------------------------------------------- > BR, Alexey > http://alexeyka.zantsev.com/ > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, Jehanzaib -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalik.voip at gmail.com Mon Feb 18 13:25:32 2019 From: vitalik.voip at gmail.com (Vitalii Aleksandrov) Date: Mon, 18 Feb 2019 20:25:32 +0200 Subject: [OpenSIPS-Users] rtpengine_manage() fails when called from failure_route[] with additional flags. In-Reply-To: References: <42e3b7d1-9817-a316-edff-3a3f71483471@gmail.com> Message-ID: <41d24af6-0fa5-f037-a9a9-a6976622f29f@gmail.com> Agree that flags for OP_DELETE are important. This patch fixes flags for me and OP_DELETE removes proper branch instead of the whole call: diff --git a/modules/rtpengine/rtpengine.c b/modules/rtpengine/rtpengine.c index 2d1a1d3..6eba189 100644 --- a/modules/rtpengine/rtpengine.c +++ b/modules/rtpengine/rtpengine.c @@ -1760,6 +1760,8 @@ static bencode_item_t *rtpe_function_call(bencode_buffer_t *bencbuf, struct sip_                         goto error;                 }                 bencode_dictionary_add_str(ng_flags.dict, "sdp", &body); +       } else if (op == OP_DELETE) { +               ng_flags.flags = bencode_list(bencbuf);         } > Hi, Vitalii! > > It looks you are running out of memory. Make sure you have properly > adjusted opensips with enough private memory. > > I don't think your patch is correct, since it does not parse flags for > delete commands, although someone might need them. > > Best regards, > Razvan > > On 2/13/19 3:09 PM, Vitalii Aleksandrov wrote: >> Hi, >> >> I use only rtpengine_manage() function of >> rtpengine_{offer,answer,delete} and it is called from different >> locations like request_route, onreply_route, failure_route. >> >> To have everything in one place I call a route[RTPENGINE_MANAGE] >> which in its turn prepares rtpengine parameters string (ICE, >> profiles, flags) and calls rtpengine_manage(). When this route is >> called from failure_route rtpengine_manage() is supposed to behave >> like rtpengine_delete() and it does. The only problem is that when it >> receives flags in its parameters string (no-rtcp-attribute in my >> case) it fails with "rtpengine:parse_flags: error processing flag >> `no-rtcp-attribute': no more memory" message instead of just ignoring >> useless for delete operation parameters. >> >> Attaching the patch that fixed this problem for me. Not sure if this >> is a bug or lack of module documentation. >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > From jehanzaib.kiani at gmail.com Tue Feb 19 04:14:24 2019 From: jehanzaib.kiani at gmail.com (J E H A N Z A I B) Date: Tue, 19 Feb 2019 22:14:24 +1300 Subject: [OpenSIPS-Users] uac registrant module issue In-Reply-To: References: <1550488081.57616697@f526.i.mail.ru> Message-ID: Hi Alex, I have made this work by adding sip: in the registrar. Awesome. thank you. One more thing, do you know how to route the call to this registered trunk ? I usually change the $duri but not sure how to route for this registered sip trunk. Ty Thank you On Tue, Feb 19, 2019 at 12:45 AM J E H A N Z A I B < jehanzaib.kiani at gmail.com> wrote: > Thank you ALex. > > I actually did not have sip: at the start in the registrar. > Let me update the values in the database and test it out. Will get back to > you shortly. > > Ty > > On Tue, Feb 19, 2019 at 12:11 AM Alexey Kazantsev via Users < > users at lists.opensips.org> wrote: > >> Hi, Jehanzaib! >> >> Could you paste here the SELECT from your DB? >> >> Please set vertical oputput in your DB if possible >> ( \x for PGSQL, \G for MySQL). >> >> Here's a working example: >> >> opensips=> select * from sipgw01_registrant ORDER BY id DESC LIMIT 1; >> -[ RECORD 1 ]----------+------------------------------- >> id | 186 >> registrar | sip:999.201.888.35 >> proxy | >> aor | sip:7xxxzzz3333 at multifon.ru >> third_party_registrant | >> username | 7xxxzzz3333 >> password | mEgApAsS >> binding_uri | sip:7xxxzzz3333 at 999.209.888.74 >> binding_params | >> expiry | 180 >> forced_socket | >> >> >> ----------------------------------------------- >> BR, Alexey >> http://alexeyka.zantsev.com/ >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > -- > Regards, > Jehanzaib > -- Regards, Jehanzaib -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurgan-rus at inbox.ru Tue Feb 19 06:26:39 2019 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Tue, 19 Feb 2019 14:26:39 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?uac_registrant_module_issue?= In-Reply-To: References: Message-ID: <1550575599.100983317@f516.i.mail.ru> Hi Jehanzaib, I never used such scenarios, I just receive inbound calls via registered connections. I think you should form request-URI using $ru [1] variable before sending your INVITE.  But I'm almost absolutely sure that your VoIP provider will check either From user or smth like that in your INVITEs, so be ready to use functions like uac_replace_from [2]  before calling t_relay. In the simplest case  it may be something like:   ...   $ru = "sip:xyz at 1.2.3.4"   uac_replace_from("...","...");   ...   t_relay(); [1]  https://www.opensips.org/Documentation/Script-CoreVar-2-4#toc75 [2]  https://opensips.org/html/docs/modules/2.4.x/uac.html#func_uac_replace_from_2 ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/ From ryandelgrosso at gmail.com Tue Feb 19 13:50:34 2019 From: ryandelgrosso at gmail.com (Ryan Delgrosso) Date: Tue, 19 Feb 2019 10:50:34 -0800 Subject: [OpenSIPS-Users] tls blocking question Message-ID: <029b60cc-9f8b-e47d-2105-f790cf277064@gmail.com> So I have a situation where 100% of my endpoints are TLS behind NAT bridging to UDP in core. I have tcp_async enabled and have set tcp_no_new_conn_bflag on packets coming from UDP side to TLS side, as well as setting it on the registered AOR's in mid-registrar. Setting up test scenarios I always seem to hit a wall where opensips stops passing packets where it seems to be waiting for some kind of timeout. I am also seeing these messages: Feb 19 18:46:16 sbc2 /opt/ringrx_edge_proxy/sbin/opensips[20755]: ERROR:proto_tls:tls_write: TLS write error: Feb 19 18:46:16 sbc2 /opt/ringrx_edge_proxy/sbin/opensips[20755]: ERROR:proto_tls:tls_blocking_write: TLS failed to send data Feb 19 18:46:16 sbc2 /opt/ringrx_edge_proxy/sbin/opensips[20755]: ERROR:proto_tls:proto_tls_send: failed to send Feb 19 18:46:16 sbc2 /opt/ringrx_edge_proxy/sbin/opensips[20755]: ERROR:sl:msg_send: send() to 1.1.1.1:1234 for proto tls/3 failed The IP is outside so its from a UDP to TCP flow. Is there another flag I need to set to prevent packets from originating new TLS sessions when none exist? Once it gets into this state it takes 30s or so before it starts passing packets again, but it does so from a buffer it seems since i can stop my tls generator, wait 30s and the core side sipp instance will again begin receiving packets. How can I prevent opensips from blocking like this on TLS sessions? From sagarmalam at gmail.com Wed Feb 20 09:49:55 2019 From: sagarmalam at gmail.com (sagar malam) Date: Wed, 20 Feb 2019 20:19:55 +0530 Subject: [OpenSIPS-Users] tls blocking question In-Reply-To: <029b60cc-9f8b-e47d-2105-f790cf277064@gmail.com> References: <029b60cc-9f8b-e47d-2105-f790cf277064@gmail.com> Message-ID: Try Keepalives, *http://www.opensips.org/html/docs/modules/2.4.x/nat_traversal.html#func_nat_keepalive * On Wed, Feb 20, 2019 at 12:24 AM Ryan Delgrosso wrote: > So I have a situation where 100% of my endpoints are TLS behind NAT > bridging to UDP in core. > > I have tcp_async enabled and have set tcp_no_new_conn_bflag on packets > coming from UDP side to TLS side, as well as setting it on the > registered AOR's in mid-registrar. > > Setting up test scenarios I always seem to hit a wall where opensips > stops passing packets where it seems to be waiting for some kind of > timeout. > > I am also seeing these messages: > > Feb 19 18:46:16 sbc2 /opt/ringrx_edge_proxy/sbin/opensips[20755]: > ERROR:proto_tls:tls_write: TLS write error: > Feb 19 18:46:16 sbc2 /opt/ringrx_edge_proxy/sbin/opensips[20755]: > ERROR:proto_tls:tls_blocking_write: TLS failed to send data > Feb 19 18:46:16 sbc2 /opt/ringrx_edge_proxy/sbin/opensips[20755]: > ERROR:proto_tls:proto_tls_send: failed to send > Feb 19 18:46:16 sbc2 /opt/ringrx_edge_proxy/sbin/opensips[20755]: > ERROR:sl:msg_send: send() to 1.1.1.1:1234 for proto tls/3 failed > > The IP is outside so its from a UDP to TCP flow. Is there another flag I > need to set to prevent packets from originating new TLS sessions when > none exist? > > Once it gets into this state it takes 30s or so before it starts passing > packets again, but it does so from a buffer it seems since i can stop my > tls generator, wait 30s and the core side sipp instance will again begin > receiving packets. > > How can I prevent opensips from blocking like this on TLS sessions? > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Thanks, Sagar -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Feb 25 07:26:03 2019 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 25 Feb 2019 14:26:03 +0200 Subject: [OpenSIPS-Users] [Blog] Auto process scaling, a cure for load and resources concerns Message-ID: During all the OpenSIPS trainings, one of the first questions that pops up when talking about configuring OpenSIPS is : “How do I know how many processes should I configure on my OpenSIPS?“. And later, this question escalates into the one of the most troubling question for people operating OpenSIPS : “Does my OpenSIPS have enough processes to support my traffic?“. The short answer is the new auto-scaling support in OpenSIPS 3.0 - a smart and easy to use feature that simply absolve you from any worries or concerns about proper scaling of your OpenSIPS – less worries, less work, more resource for you. https://blog.opensips.org/2019/02/25/auto-process-scaling-a-cure-for-load-and-resources-concerns/ Enjoy it, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ From johan at democon.be Mon Feb 25 15:08:02 2019 From: johan at democon.be (johan de clercq) Date: Mon, 25 Feb 2019 21:08:02 +0100 Subject: [OpenSIPS-Users] problem upgrading to opensips 3.0 Message-ID: <008201d4cd45$d05f96f0$711ec4d0$@democon.be> Hello, When upgrading to opensips 3.0 I run into the following problem: Feb 25 21:01:42 ns3012072 opensips[10887]: Not starting opensips: invalid configuration file! Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] ERROR:tls_mgm:split_param_val: No TLS domain name Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] CRITICAL:core:yyerror: parse error in config file /usr/local/opensips/etc/opensips/opensips.cfg, line 22, column 20-21: Parameter not found in module - can't set Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] ERROR:tls_mgm:split_param_val: No TLS domain name Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] CRITICAL:core:yyerror: parse error in config file /usr/local/opensips/etc/opensips/opensips.cfg, line 23, column 20-21: Parameter not found in module - can't set Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] ERROR:tls_mgm:split_param_val: No TLS domain name Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] CRITICAL:core:yyerror: parse error in config file /usr/local/opensips/etc/opensips/opensips.cfg, line 24, column 20-21: Parameter not found in module - can't set Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] ERROR:tls_mgm:split_param_val: No TLS domain name Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] CRITICAL:core:yyerror: parse error in config file /usr/local/opensips/etc/opensips/opensips.cfg, line 25, column 20-21: Parameter not found in module - can't set Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] ERROR:tls_mgm:split_param_val: No TLS domain name Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] CRITICAL:core:yyerror: parse error in config file /usr/local/opensips/etc/opensips/opensips.cfg, line 26, column 20-21: Parameter not found in module - can't set Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] ERROR:tls_mgm:split_param_val: No TLS domain name Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] CRITICAL:core:yyerror: parse error in config file /usr/local/opensips/etc/opensips/opensips.cfg, line 27, column 20-21: Parameter not found in module - can't set Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] ERROR:core:sr_load_module: could not open module : /usr/local/opensips/lib64/opensips/modules/mi_json.so: undefined symbol: crt_flush_fnct Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] ERROR:core:load_module: failed to load module Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] CRITICAL:core:yyerror: parse error in config file /usr/local/opensips/etc/opensips/opensips.cfg, line 153, column 13-14: failed to load module mi_json.so Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] ERROR:core:main: bad config file (7 errors) When tls_mgm config is as below and working in opensips2.4: loadmodule "tls_mgm.so" modparam("tls_mgm", "certificate", "/usr/local/opensips/etc/opensips/tls/rootCA/cacert.pem") modparam("tls_mgm", "private_key", "/usr/local/opensips/etc/opensips/tls/rootCA/private/cakey.pem") modparam("tls_mgm", "ca_list", "/usr/local/opensips/etc/opensips/tls/rootCA/cacert.pem") modparam("tls_mgm", "require_cert", "0") modparam("tls_mgm", "verify_cert", "0") modparam("tls_mgm", "tls_method", "SSLv23") Same thing for mi_json: #### HTTPD module loadmodule "httpd.so" modparam("httpd", "port", 8888) #### MI_HTTP module loadmodule "json.so" loadmodule "mi_http.so" loadmodule "mi_json.so" can you please advice on what my problem is ? BR, Johan De Clercq, Managing Director Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke Tel +3256980990 - GSM +32478720104 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 15602 bytes Desc: not available URL: From kurgan-rus at inbox.ru Tue Feb 26 02:47:35 2019 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Tue, 26 Feb 2019 10:47:35 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?OpenSIPS_2=2E4=2E4=2C_db=5Fpostgres=2E?= =?utf-8?q?so_number_of_connections?= Message-ID: <1551167255.781289135@f433.i.mail.ru> Hi list! OpenSIPS 2.4.4 (x86_64/linux). CentOS 7.6.1810. # we increased this value from default "2" modparam("db_postgres", "max_db_queries", 20) modparam("db_postgres", "exec_query_threshold", 60000) modparam("acc", "db_url", "postgres://user:PaSs at pg-server/db") modparam("avpops", "db_url", "postgres://user:PaSs at pg-server/db") modparam("dispatcher", "db_url", "postgres://user:PaSs at pg-server/db") modparam("clusterer", "db_url", "postgres://user:PaSs at pg-server/db") My colleague noticed an interesting behavior with PG DB connection. 'netstat -tulpan | grep %pg-server-ip%' showed only 1 ESTABLISHED connection. When we configured 5432 port explicitly for the 'acc' module (which uses the DB most actively) ... modparam("acc", "db_url", "postgres://user:PaSs at pg-server:5432/db") ... we saw several dozens of connections. And the load on the workers also decreased after that. Is it a bug? ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/ From bogdan at opensips.org Tue Feb 26 04:20:52 2019 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Tue, 26 Feb 2019 11:20:52 +0200 Subject: [OpenSIPS-Users] problem upgrading to opensips 3.0 In-Reply-To: <008201d4cd45$d05f96f0$711ec4d0$@democon.be> References: <008201d4cd45$d05f96f0$711ec4d0$@democon.be> Message-ID: <2c5efbda-5a07-6c99-bcdb-fa04c4c21739@opensips.org> Hi Johan, Please check this migration document : http://www.opensips.org/Documentation/Migration-2-4-0-to-3-0-0#toc17 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2019 https://www.opensips.org/events/Summit-2019Amsterdam/ On 02/25/2019 10:08 PM, johan de clercq wrote: > > Hello, > > When upgrading to opensips 3.0 I run into the following problem: > > Feb 25 21:01:42 ns3012072 opensips[10887]: Not starting opensips: > invalid configuration file! > > Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] > ERROR:tls_mgm:split_param_val: No TLS domain name > > Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] > CRITICAL:core:yyerror: parse error in config file > /usr/local/opensips/etc/opensips/opensips.cfg, line 22, column 20-21: > Parameter not found in module - can't set > > Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] > ERROR:tls_mgm:split_param_val: No TLS domain name > > Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] > CRITICAL:core:yyerror: parse error in config file > /usr/local/opensips/etc/opensips/opensips.cfg, line 23, column 20-21: > Parameter not found in module - can't set > > Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] > ERROR:tls_mgm:split_param_val: No TLS domain name > > Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] > CRITICAL:core:yyerror: parse error in config file > /usr/local/opensips/etc/opensips/opensips.cfg, line 24, column 20-21: > Parameter not found in module - can't set > > Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] > ERROR:tls_mgm:split_param_val: No TLS domain name > > Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] > CRITICAL:core:yyerror: parse error in config file > /usr/local/opensips/etc/opensips/opensips.cfg, line 25, column 20-21: > Parameter not found in module - can't set > > Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] > ERROR:tls_mgm:split_param_val: No TLS domain name > > Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] > CRITICAL:core:yyerror: parse error in config file > /usr/local/opensips/etc/opensips/opensips.cfg, line 26, column 20-21: > Parameter not found in module - can't set > > Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] > ERROR:tls_mgm:split_param_val: No TLS domain name > > Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] > CRITICAL:core:yyerror: parse error in config file > /usr/local/opensips/etc/opensips/opensips.cfg, line 27, column 20-21: > Parameter not found in module - can't set > > Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] > ERROR:core:sr_load_module: could not open module > : > /usr/local/opensips/lib64/opensips/modules/mi_json.so: undefined > symbol: crt_flush_fnct > > Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] > ERROR:core:load_module: failed to load module > > Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] > CRITICAL:core:yyerror: parse error in config file > /usr/local/opensips/etc/opensips/opensips.cfg, line 153, column 13-14: > failed to load module mi_json.so > > Feb 25 21:01:42 ns3012072 opensips[10887]: Feb 25 21:01:42 [10899] > ERROR:core:main: bad config file (7 errors) > > When tls_mgm config is as below and working in opensips2.4: > > loadmodule "tls_mgm.so" > > modparam("tls_mgm", "certificate", > "/usr/local/opensips/etc/opensips/tls/rootCA/cacert.pem") > > modparam("tls_mgm", "private_key", > "/usr/local/opensips/etc/opensips/tls/rootCA/private/cakey.pem") > > modparam("tls_mgm", "ca_list", > "/usr/local/opensips/etc/opensips/tls/rootCA/cacert.pem") > > modparam("tls_mgm", "require_cert", "0") > > modparam("tls_mgm", "verify_cert", "0") > > modparam("tls_mgm", "tls_method", "SSLv23") > > Same thing for mi_json: > > #### HTTPD module > > loadmodule "httpd.so" > > modparam("httpd", "port", 8888) > > #### MI_HTTP module > > loadmodule "json.so" > > loadmodule "mi_http.so" > > loadmodule "mi_json.so" > > can you please advice on what my problem is ? > > BR, > > cid:F3100D46-F00D-4610-87ED-3E91DA790A82 > > Johan De Clercq, Managing Director > Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke > > Tel +3256980990– GSM +32478720104 > > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 15602 bytes Desc: not available URL: From voransoy at gmail.com Wed Feb 27 08:21:39 2019 From: voransoy at gmail.com (Volkan Oransoy) Date: Wed, 27 Feb 2019 16:21:39 +0300 Subject: [OpenSIPS-Users] TLS issue with WSS Message-ID: Hi all, I am trying to apply this tutorial to my test environment but I couldn't solve a problem with TLS handshake. https://www.opensips.org/Documentation/Tutorials-WebSocket-2-2 My configuration is simply like that. listen=ws:10.10.10.10:8080 listen=wss:10.10.10.10:443 ... loadmodule "proto_tls.so" loadmodule "proto_wss.so" loadmodule "proto_ws.so" loadmodule "tls_mgm.so" modparam("tls_mgm", "certificate","/etc/letsencrypt/live/ testserver.example.net/fullchain.pem") modparam("tls_mgm", "private_key","/etc/letsencrypt/live/ testserver.example.net/privkey.pem") When I try to connect the server via a websocket client like SIP.js or jssip, I got this error. Feb 27 15:22:39 [26842] DBG:core:probe_max_sock_buff: getsockopt: snd is initially 425984 Feb 27 15:22:39 [26842] INFO:core:probe_max_sock_buff: using snd buffer of 416 kb Feb 27 15:22:39 [26842] INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 49 Feb 27 15:22:39 [26842] DBG:core:print_ip: tcpconn_new: new tcp connection to: 192.168.100.100 Feb 27 15:22:39 [26842] DBG:core:tcpconn_new: on port 34560, proto 6 Feb 27 15:22:39 [26842] DBG:proto_wss:tls_conn_init: entered: Creating a whole new ssl connection Feb 27 15:22:39 [26842] DBG:proto_wss:tls_conn_init: looking up socket based TLS server domain [10.10.10.10:443] Feb 27 15:22:39 [26842] DBG:tls_mgm:tls_find_server_domain: virtual TLS server domain not found, Using default TLS server domain settings Feb 27 15:22:39 [26842] DBG:proto_wss:tls_conn_init: found socket based TLS server domain [0.0.0.0:0] Feb 27 15:22:39 [26842] DBG:proto_wss:tls_conn_init: Setting in ACCEPT mode (server) Feb 27 15:22:39 [26842] DBG:core:tcpconn_add: hashes: 607, 660 Feb 27 15:22:39 [26842] DBG:core:handle_new_connect: new connection: 0x7fd6a55d8240 49 flags: 001c Feb 27 15:22:39 [26842] DBG:core:send2child: to tcp child 0 (26839), 0x7fd6a55d8240 rw 1 Feb 27 15:22:39 [26839] DBG:core:handle_io: We have received conn 0x7fd6a55d8240 with rw 1 on fd 5 Feb 27 15:22:39 [26839] DBG:core:io_watch_add: [TCP_worker] io_watch_add op (5 on 46) (0x563321968480, 5, 19, 0x7fd6a55d8240,1), fd_no=4/1024 Feb 27 15:22:39 [26839] DBG:proto_wss:tls_update_fd: New fd is 5 Feb 27 15:22:39 [26839] DBG:proto_wss:ws_server_handshake: Using the global ( per process ) buff Feb 27 15:22:39 [26839] DBG:proto_wss:tls_update_fd: New fd is 5 Feb 27 15:22:39 [26839] DBG:proto_wss:ws_server_handshake: ws_read end Feb 27 15:22:39 [26839] DBG:proto_wss:tls_update_fd: New fd is 5 Feb 27 15:22:39 [26839] ERROR:proto_wss:tls_accept: New TLS connection from 192.168.100.100:34560 failed to accept Feb 27 15:22:39 [26839] ERROR:proto_wss:wss_read_req: cannot fix read connection Feb 27 15:22:39 [26839] DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index 0 5 (0x563321968480, 5, 0, 0x10,0x3) fd_no=5 called Feb 27 15:22:39 [26839] DBG:core:tcpconn_release: releasing con 0x7fd6a55d8240, state -2, fd=-1, id=1151231636 Feb 27 15:22:39 [26839] DBG:core:tcpconn_release: extra_data 0x7fd6a55d8438 Feb 27 15:22:39 [26842] DBG:core:handle_tcp_worker: response= 7fd6a55d8240, -2 from tcp worker 26839 (0) Feb 27 15:22:39 [26842] DBG:core:tcpconn_destroy: destroying connection 0x7fd6a55d8240, flags 001c Feb 27 15:22:39 [26842] DBG:proto_wss:tls_conn_clean: entered Feb 27 15:22:39 [26842] DBG:proto_wss:tls_update_fd: New fd is 49 I have tried to test my installation with openssl client and I think it has an issue with the setup because there is an error message. ➜ openssl s_client -connect testserver.example.net:443 CONNECTED(00000005) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = testserver.example.net verify return:1 4499986028:error:14020410:SSL routines:CONNECT_CR_SESSION_TICKET:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.230.1/libressl-2.6/ssl/ssl_pkt.c:1205:SSL alert number 40 4499986028:error:140200E5:SSL routines:CONNECT_CR_SESSION_TICKET:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.230.1/libressl-2.6/ssl/ssl_pkt.c:585: --- Certificate chain 0 s:/CN=testserver.example.net i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 --- Server certificate -----BEGIN CERTIFICATE----- MIIFYjCCBEqgAwIBAgISAyIztk4mccb0A0k9XLOtFkGXMA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xOTAyMTIwOTU4MTRaFw0x OTA1MTMwOTU4MTRaMB8xHTAbBgNVBAMTFHNpcDMtdjIuYnVsdXRmb24ubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2DSkfcRZcjjhsyrnH6i/xmM2 7q9GfkPopmj8+RzJemdqSK7fSsGodSZznsYDn+b+u9AhYwr01WS0HPeag3kEMA+S Bn8cu1s/osa9Jipj4BnkPhU14T4/9x/Tvurt8v1BdS6uYLqFInV1LnGfTp7XhlRY uF+SRve0vxtXOPtokS68xvjVRrWI4UNR+S+neDvZqsDQQ6q2hcdQ1aRoEt0wbKO+ k4jwZRf52cKscD2jfEniXCDUbawYq6CstzPqfx9+DYYS4NqRVtEUWeBI6MgR54QI KorBHqv382rcf/cz0vFEccmuF6NFFZFM385hdlV9YMcCQUUpwWh3FSgWh2y65QID AQABo4ICazCCAmcwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMB BggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBQmc6fJQRbTaUerCJlz W6gbPd0o5TAfBgNVHSMEGDAWgBSoSmpjBH3duubRObemRWXv86jsoTBvBggrBgEF BQcBAQRjMGEwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwLmludC14My5sZXRzZW5j cnlwdC5vcmcwLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5sZXRzZW5j cnlwdC5vcmcvMB8GA1UdEQQYMBaCFHNpcDMtdjIuYnVsdXRmb24ubmV0MEwGA1Ud IARFMEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0 dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIIBBgYKKwYBBAHWeQIEAgSB9wSB9ADy AHcAdH7agzGtMxCRIZzOJU9CcMK//V5CIAjGNzV55hB7zFYAAAFo4Vt4PQAABAMA SDBGAiEAiKzASz3oQ1R8GCA77Hn7eBkLxncg4dBhAMQwobR3Oh4CIQD3r/+A9KpK MzzvjLrw6ltN4RJt/9GAksjY7XJoHi+fRQB3AGPy283oO8wszwtyhCdXazOkjWF3 j711pjixx2hUS9iNAAABaOFbeoUAAAQDAEgwRgIhAN+Jvz1CVK7dACu8SLV3NYWQ TpUIk3RlSnqbioXoLPeSAiEA/aRTstIBRApuPqi+9U2DdsIjBMPBEWvPC+Q6V95V tWYwDQYJKoZIhvcNAQELBQADggEBADJCRG8rFR5v3wWaSZZlzRCOxNw992PjpoyE WI9ba1NP4IAUq/ORc4eFKa6bnvhnlwGkKfivxviGJFZRBauf9ydqnbNSsSc0THEt FMOMJ+fEZ6MIROmbz1ElWx8vO2crgIBMaOBjJdNEjLiKDIkwF67g7580A6ZplmN9 tMUg/qQlgx/ABL7AAqy12zoGYdB5gf4y8escm/7S2OJeMDAK122Lkxi/PjzUheAb Zlrvxf862vd/ykdvcy8UjrJPTOt1CKlYuKgWIPR8Tb7BAIsIbAebXoqmvPN//Y72 VknQALQUXxpnTNLperhBibpfqOp2MLWwnDktDGxUQRjfba5jeaA= -----END CERTIFICATE----- subject=/CN=testserver.example.net issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 --- No client certificate CA names sent Server Temp Key: ECDH, X25519, 253 bits --- SSL handshake has read 3008 bytes and written 105 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: Session-ID-ctx: Master-Key: EA79ADD7422068E3C79258F309B1D0772B5F11F3DB995DBB869BB68AA154D2827D781A57517CF8841E58F3EB9F18D656 Start Time: 1551272932 Timeout : 7200 (sec) Verify return code: 0 (ok) --- Does anyone have an idea about the solution? Thanks in advance. -- Volkan Oransoy -------------- next part -------------- An HTML attachment was scrubbed... URL: From social at bohboh.info Wed Feb 27 10:27:37 2019 From: social at bohboh.info (Social Boh) Date: Wed, 27 Feb 2019 10:27:37 -0500 Subject: [OpenSIPS-Users] OpenSIPs Load_balancer cluster count Message-ID: Hello, I'm using a Cluster between two OpenSIPs 2.4 Servers with module Load_Balancer and a N number of Asterisk. I have noticed that when there is a lot of traffic, the calls count is not correct; always more than real. opensipsctl fifo lb_list = Wrong opensipsctl fifo get_statistics active_dialogs = OK How can i fix it? Regards -- --- I'm SoCIaL, MayBe From johan at democon.be Wed Feb 27 14:30:09 2019 From: johan at democon.be (johan de clercq) Date: Wed, 27 Feb 2019 20:30:09 +0100 Subject: [OpenSIPS-Users] opensips behind firewall. Message-ID: <006d01d4ced2$daa02790$8fe076b0$@democon.be> Hi I have the following situation: Phone: 10.2.1.2 -> fw ingress : 10.2.1.1 -> fw egress : 10.3.1.1 -> opensips 10.3.1.2 There is no sip alg on the firewall. I have no idea if this possible, but how do I need to set rtpengine flags so that rtpengine listens on 10.3.1.2 but announces 10.2.1.1 ? Of course, the opensips machine has only 1 interface. Johan De Clercq, Managing Director Democon bvba - Ooigemstraat 41 - 8780 Oostrozebeke Tel +3256980990 - GSM +32478720104 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 15602 bytes Desc: not available URL: From pat at voxtelesys.com Wed Feb 27 16:30:12 2019 From: pat at voxtelesys.com (Pat Burke) Date: Wed, 27 Feb 2019 15:30:12 -0600 Subject: [OpenSIPS-Users] SDP manipulation & rtpengine Message-ID: Hello: I am using trying to manipulate parts of the SDP body before calling rtpengine_offer / rtpengine_answer.  However, any changes made via textops functions such as subst_body, replace_body, replace_body_all, etc. do not seem to impact the SDP that is sent to rtpengine. In my particular case, rtpengine fails to parse the SDP because of an extra carriage return line feed sent in the SDP.  Is there a way to send rtpengine manipulated SDP, rather than just the SDP sent in the request? Use case: if (subst_body("/(^a=.*\r\n)\r\n/\1/g")) {   xlog("L_INFO", "bad SDP --- duplicate CRLF"); } rtpengine_offer(" ... options ... "); Regards, Pat Burke ______________________________________________________________________________________ Direct: (402) 403-5121   |   Cell: (402) 443-8929  |   Email: pat at voxtelesys.com 1801 23rd Avenue North   |  Suite 217    |  Fargo, North Dakota 58102   -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lokesh.Jadwani at ipc.com Wed Feb 27 16:52:24 2019 From: Lokesh.Jadwani at ipc.com (Jadwani, Lokesh) Date: Wed, 27 Feb 2019 21:52:24 +0000 Subject: [OpenSIPS-Users] opensips version2.4.4 tls_mgm Message-ID: Hello, I am trying to install opensips version 2.4.4 on RHEL 7.5. when I try to start opnsips, it is showing logs in syslog-ng ERROR:tls_mgm:mod_init: unable to set the memory allocation functions ERROR:tls_mgm:mod_init: NOTE: check if you are using openssl 1.0.1e-fips, (or other FIPS version of openssl, as this is known to be broken; if so, you need to upgrade or downgrade to a different openssl version! Below are my version details: opensips -V version: opensips 2.4.4 (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, F_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: a42226ccb main.c compiled on 15:11:28 Feb 27 2019 with gcc 4.4.7 openssl version -a OpenSSL 1.0.2k-fips 26 Jan 2017 built on: reproducible build, date unspecified platform: linux-x86_64 options: bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM OPENSSLDIR: "/etc/pki/tls" engines: rdrand dynamic Googled around, found many people found this issue but haven't found any working solution. Regards, Lokesh Jadwani DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail. E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurgan-rus at inbox.ru Wed Feb 27 23:54:10 2019 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Thu, 28 Feb 2019 07:54:10 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?opensips_behind_firewall=2E?= In-Reply-To: <006d01d4ced2$daa02790$8fe076b0$@democon.be> References: <006d01d4ced2$daa02790$8fe076b0$@democon.be> Message-ID: <1551329650.70949413@f558.i.mail.ru> Hello Johan, rtpengine itself has the ability to listen on one address but advertise another. This is from official documentation: "interface=10.65.76.2!192.0.2.4 means that 10.65.76.2 is the actual local address on the server, but outgoing SDP bodies should advertise 192.0.2.4 as the address that endpoints should talk to". Please refer to https://github.com/sipwise/rtpengine , section "Interface configuration". I hope this will help you. ----------------------------------------------- BR, Alexey http://alexeyka.zantsev.com/ From rwalias at gmail.com Thu Feb 28 02:16:00 2019 From: rwalias at gmail.com (Rocio Walias) Date: Thu, 28 Feb 2019 08:16:00 +0100 Subject: [OpenSIPS-Users] lb_list shows an incorrect load in load balancer Message-ID: Hello, I need a little help regarding a load balancer issue. I have two destinations (A.X.X.X and B.X.X.X) in the load balancer group. A.X.X.X is working fine but sometimes B.X.X.X is not responding in time and a 408 response is received. In that case I am doing a lb_next() and load balancer send it to A.X.X.X but in “opensips fifo lb_list“ is showing that B.X.X.X load is 1 and I think it must be 0 because in A.X.X.X load is 2 and there is only 2 dialogs. Destination:: sip:33 at A.X.X.X:5080 id=96 group=1 enabled=yes auto-reenable=on Resources:: Resource:: channel max=10 *load*=2 Destination:: sip:33 at B.X.X.X:5080 id=98 group=1 enabled=yes auto-reenable=on Resources:: Resource:: channel max=10 *load=*1 I’m trying to remove that “load=1” but if I use lb_count_call to undo : if (lb_is_destination(“B.X.X.X", "5080", "1","1")) { lb_count_call("B.X.X.X","5080","1","channel","1"); } This error happens: Feb 21 13:05:18 [11033] ERROR:load_balancer:lb_route: sequential call of LB - failed to remove from profile [lbXchannel]->[62] Is there any way to decrease the load of B.X.X.X or how can it not be considered in load count in a failure_route? I’m saving load data to statistics purpose and it doesn’t match with the number of dialogues. I’m using Opensips 2.4.2 Thank you very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johan at democon.be Thu Feb 28 02:28:03 2019 From: Johan at democon.be (Johan De Clercq) Date: Thu, 28 Feb 2019 08:28:03 +0100 Subject: [OpenSIPS-Users] opensips behind firewall. In-Reply-To: <1551329650.70949413@f558.i.mail.ru> References: <006d01d4ced2$daa02790$8fe076b0$@democon.be> <1551329650.70949413@f558.i.mail.ru> Message-ID: Thanks Alex. I will try this evening. On Thu, 28 Feb 2019, 05:56 Alexey Kazantsev via Users < users at lists.opensips.org wrote: > Hello Johan, > > rtpengine itself has the ability to listen on one address but advertise > another. > > This is from official documentation: > "interface=10.65.76.2!192.0.2.4 means that 10.65.76.2 is the actual local > address on the server, but outgoing SDP bodies should advertise 192.0.2.4 > as the address that endpoints should talk to". > > Please refer to https://github.com/sipwise/rtpengine , section "Interface > configuration". > I hope this will help you. > > ----------------------------------------------- > BR, Alexey > http://alexeyka.zantsev.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 wilhelm.lundgren at gmail.com Mon Feb 4 03:01:24 2019 From: wilhelm.lundgren at gmail.com (Wilhelm Lundgren) Date: Mon, 04 Feb 2019 08:01:24 -0000 Subject: [OpenSIPS-Users] sips: automatically downgraded to sip: In-Reply-To: <45b1b34c-65ac-b90c-10f9-cebc3de192bc@opensips.org> References: <45b1b34c-65ac-b90c-10f9-cebc3de192bc@opensips.org> Message-ID: Hi Bogdan and thanks for the answer. I was under the assumption that this logic was "hardcoded", but now i understand i need to setup the rules to enforce this. Best Regards Wilhelm On Mon, 4 Feb 2019 at 08:58, Bogdan-Andrei Iancu wrote: > Hi Wilhelm, > > Keep in mind that OPenSIPS is a routing engine that does what you tell it > to do. > > The OpenSIPS does the translation from TLS to UDP as the callee device is > registered via UDP. > > Now, how to handle a sips enforcement in the RURI is up to the logic in > the proxy - if allows it to switch to a non-secure protocol or if applies > constraints to stay with a secure protocol - but if you want this, you need > to script it in your opensips.cfg. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 2019 > https://www.opensips.org/events/Summit-2019Amsterdam/ > > On 01/16/2019 06:03 PM, Wilhelm Lundgren wrote: > > Hi, > > Im trying out some tls / sips things in my client. But im seeing something > strange in opensips. > I am using opensips 2.2.2, x64. > > Im registering my client with TLS and SIPS. Another client is registering > over UDP. I expected that when i send a SIP MESSAGE with sips: in request > and to / from tags etc, the UDP client should not receive the message. > However, opensips downgrades this message to normal sip and sends it. > > Have i missunderstood "sips:" feature or have i configed something wrong > or is it not supported? > > Best Regards > Wilhelm > > > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Mon Feb 25 17:26:49 2019 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Mon, 25 Feb 2019 22:26:49 +0000 Subject: [OpenSIPS-Users] Invalid parameter errors In-Reply-To: References: <3290d7c2-2577-d130-3411-702c153bf41a@opensips.org> Message-ID: <94664777-BBFA-4E49-A9FD-EBA12D45C3A6@genesys.com> Liviu, I think the offending lines appear to be these: if (route(is_null, $param($var(add_rlog_j)))) if (route(is_json, $param($var(add_rlog_j)))) These calls work most of the time, but there seem to be some cases where this parameter is not passed properly and causes the errors I am seeing. I have not been able to isolate the specific values of $param($var(add_rlog_j)) that cause the issue. I thought it may be when it is NULL, but that doesn’t appear to be the case. Ben Newlin From: Users on behalf of Ben Newlin Reply-To: OpenSIPS users mailling list Date: Friday, February 1, 2019 at 12:30 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Invalid parameter errors Liviu, You’re right, there are quite a lot of them. Almost all of our use of parameterized routes and json access is in a subset of code that performs our logging, and none of that changed when the errors began. Routes: route(is_null, $param(1)) route(is_null, $param(2)) route(is_json, $param(2)) route(is_null, $json(rlog/$param(1))) route(json_rlog, "thread_name", $pp); route(json_rlog, "level", $param(1)); route(json_rlog, "route", $param(2)); route(rlog_start, $param(1), $param(2)); route(is_null, $param(3)) route(json_rlog, "message", $param(3)); route(is_null, $json(rlog_msg)) route(json_rlog, "message", $var(rlog_msg)); route(rlog_v, $param(1)); route(json_rlog, "callID", $ci); route(json_rlog, "requestUri", $ru); route(json_rlog, "fromUri", $fu); route(json_rlog, "toUri", $tu); route(json_rlog, "sipStatus", $rs); route(json_rlog, "sipReason", $rr); route(json_rlog, "mflags", $mf); route(json_rlog, "conversation", $avp(cnv_id)); route(json_rlog, "callState", $avp(call_state)); route(json_rlog, "method", $rm); route(is_null, $json(rlog_msg)) route(is_null, $param($var(add_rlog_i))) route(is_null, $param($var(add_rlog_j))) route(is_json, $param($var(add_rlog_j))) route(is_null, $param(1)) route(is_null, $param($var(i)))) route(add_rlog_msg_data, "function", "t_relay", "retcode", $var(relay_rc)); route(add_rlog_msg_data, "sipStatus", $param(1), "sipReason", $param(2)); route(add_rlog_msg_data, "maxfwd", $hdr(Max-Forwards)); route(is_null, $param(1)) route(is_null, $param(1)) route(is_null, $param(1)) route(is_null, $var(ft_cache_val)) route(is_null, $param(2)) route(is_null, $var(ft_orgs)) route(add_rlog_msg_data, "feature", $param(1), "orgID", $param(2), "allow", $var(ft_allow)); route(add_rlog_msg_data, "state", $shv(state)); route(add_rlog_msg_data, "group", $var(group)); route(add_rlog_msg_data, "dir", $var(dir), "group", $var(group)); route(add_rlog_msg_data, "rr_params", $rr_params); route(add_rlog_msg_data, "rr_params", $rr_params); route(add_rlog_msg_data, "state", $shv(state)); route(add_rlog_msg_data, "domain", $hdr(x-special-header)); JSON: $json(rlog/$param(1)) = NULL; $json(rlog/$param(1)) := $param(2); route(is_null, $json(rlog/$param(1))) $json(rlog/$param(1)) = $(param(2){re.subst,/"/\\"/g}); $json(rlog/message) := $json(rlog_msg); $json(rlog/t) = $(time("%Y-%m-%dT%T."){s.select,1,"}) + $(Tsm{s.fill.left,0,6}) + "Z"; #" $json(rlog_msg/$param($var(add_rlog_i))) = ""; $json(rlog_msg/$param($var(add_rlog_i))) := $param($var(add_rlog_j)); $json(rlog_msg/$param($var(add_rlog_i))) = $(param($var(add_rlog_j)){re.subst,/"/\\"/g}); $json(rlog_msg/function) = $param(1); $json(rlog_msg/retcode) = $var(add_rlog_msg_retcode); $json(rlog_msg/params[]) = $(param($var(i)){re.subst,/"/\\"/g}); $json(rlog_msg/destUri) = $du; $json(rlog_msg/srcIp) = $si; $json(rlog_msg/srcPort) = $sp; $json(rlog_msg/replyCode) = $T_reply_code; $json(rlog_msg/protocol) = $(proto{s.tolower}); $json(rlog/errClass) = $(err.class{s.escape.common}); $json(rlog/errLevel) = $(err.level{s.escape.common}); $json(rlog/errInfo) = $(err.info{s.escape.common}); $json(rlog/errRcode) = $(err.rcode{s.escape.common}); $json(rlog/errRreason) = $(err.rreason{s.escape.common}); $json(rlog/msg) = $(mb{s.escape.common}); We have a few cases where we used parameterized parameter references, if that makes sense. I suspect it may be something related to that? For example, the only error line number that references a line where json access or variable assignment is actually being performed is here: $json(rlog_msg/$param($var(add_rlog_i))) = $(param($var(add_rlog_j)){re.subst,/"/\\"/g}); Ben Newlin From: Users on behalf of Liviu Chircu Reply-To: OpenSIPS users mailling list Date: Thursday, January 24, 2019 at 3:12 PM To: "users at lists.opensips.org" Subject: Re: [OpenSIPS-Users] Invalid parameter errors Hi Ben, We are actually dealing with two bugs here, which may or may not be related to one another. Bug #1: bad? variable during a route() call ------------------------------------------------------- For this one, can you enumerate all "route()" calls in your script which pass at least one variable, along with their full parameter call syntax? Example call: route(sequential_requests, $rm, $avp(myinfo)); Bug #2: bad "key variable" during a $json expansion ---------------------------------------------------------------------- For this one, can you enumerate all $json() variable appearances which include at least one parameterized key access? I realize there may be lots of these, but you may group them into "categories" and print out a few ones that might be relevant (i.e. their index may contain an INT-only variable, which is >wrong<). Example appearances: $json(http_body/$var(tag)) $json(http_body/users[0]/$avp(username)) Best regards, Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 24.01.2019 01:37, Ben Newlin wrote: Liviu, Thank you for the quick response. I do see 2 such errors shortly after startup: ERROR:core:pv_get_param: cannot get spec value ERROR:core:pv_get_param: cannot get spec value However, after that it just continues on with more of the same errors that keep scrolling. There is a variation of the scrolling errors that was I didn’t included before, in case it helps: ERROR:core:comp_scriptvar: cannot get left var value WARNING:core:do_action: error in expression at opensips.cfg:583 ERROR:json:expand_tag_list: Non string value in key ERROR:json:pv_set_json: Cannot expand variables in path ERROR:core:do_assign: setting PV failed ERROR:core:do_assign: error at opensips.cfg:346 ALERT:core:pv_get_param: BUG: invalid parameter type 1836017711 There aren’t any other non-repeating errors. I have picked up your commit and will try to gather more information from it, but this issue is primarily happening in our production environment so it may take a bit. Also, I haven’t completely verified this yet, but it seems that enabling TLS has made the errors stop somehow. Continuing to investigate that. Ben Newlin From: Users on behalf of Liviu Chircu Reply-To: OpenSIPS users mailling list Date: Tuesday, January 22, 2019 at 6:08 PM To: "users at lists.opensips.org" Subject: Re: [OpenSIPS-Users] Invalid parameter errors Hi, Ben! The strange "...type 1836017711" errors seem to be caused by a poorly handed error condition (a secondary bug), which is now fixed [1]. If this theory holds, you must have a "cannot get spec value" error (or slew of errors) in the earlier section of your OpenSIPS log (possibly right after restart or shortly after starting to process traffic). Could you please confirm/infirm the above? If true, are there any other relevant errors thrown around that initial "cannot get spec value" error message? Those error logs could be key to making progress in understanding the main bug. Best regards, [1]: https://github.com/OpenSIPS/opensips/commit/52ff74af8702a Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com On 22.01.2019 20:58, Ben Newlin wrote: Hi, Since upgrading to 2.4.4 we are seeing the following logs scrolling nearly continuously on our servers: ALERT:core:pv_get_param: BUG: invalid parameter type 1836017711 ERROR:core:comp_scriptvar: cannot get left var value WARNING:core:do_action: error in expression at opensips.cfg:583 ALERT:core:pv_get_param: BUG: invalid parameter type 1836017711 ERROR:core:comp_scriptvar: cannot get left var value WARNING:core:do_action: error in expression at opensips.cfg:583 ALERT:core:pv_get_param: BUG: invalid parameter type 1836017711 ERROR:core:comp_scriptvar: cannot get left var value ALERT:core:pv_get_param: BUG: invalid parameter type 1836017711 ERROR:core:comp_scriptvar: cannot get left var value WARNING:core:do_action: error in expression at opensips.cfg:439 It seems to be related to our use of the json module. We often pass json variable types as parameters to other routes and I believe the errors are caused by that. But it’s hard to say as there are a few different script lines referenced in the errors, but some of them point to return statements and other code sections that don’t really make sense. For example, line 583 referenced in the error above is: return(-1); Any ideas? Ben Newlin _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: