From adjolin at gmail.com Wed Jul 1 04:33:10 2020 From: adjolin at gmail.com (Vic Jolin) Date: Wed, 1 Jul 2020 12:33:10 +0800 Subject: [OpenSIPS-Users] Carrier ID for accounting Message-ID: Hi, I was trying to put the carrier id in the acc extra fields but Im getting Jul 1 04:00:16 Opensip opensips: #011$acc_extra(carrierid) = $avp(carrier_id); Jul 1 04:00:16 Opensip opensips: #011^~~~~~~~~~~~~~~~~~~~~~ Jul 1 04:00:16 Opensip opensips: Jul 1 04:00:16 Opensip opensips: #011do_accounting("db"); Jul 1 04:00:16 Opensip opensips: ERROR:core:parse_opensips_cfg: bad config file (1 errors) Jul 1 04:00:16 Opensip opensips: ERROR:core:main: failed to parse config file (null) Jul 1 04:00:16 Opensip opensips: NOTICE:core:main: Exiting.... I have this in the config modparam("acc", "extra_fields", "db: callerid->callerid; ani->ani; prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; acctid->acctid; carrierid=$avp(carrier_id);") Also, I would like to put the IP address of the gateway that last tried to make the call, either missed or not, but sometimes I am also getting the IP address of the originating call where should I put this? $acc_extra(dst_ip) = $rd; -------------- next part -------------- An HTML attachment was scrubbed... URL: From williamj at exetel.com.au Wed Jul 1 06:25:48 2020 From: williamj at exetel.com.au (William Jin) Date: Wed, 1 Jul 2020 06:25:48 +0000 Subject: [OpenSIPS-Users] Usrloc can't be sync after upgrade to 2.4.8 Message-ID: Hi, We were using opensips 2.4.6 from apt repo, and we upgraded to 2.4.8 today. However, after the upgrade, the usrloc-contact-repl can not be synced between the 2 nodes within 1 cluster. Even we issue the ul_cluster_sync command. opensipsctl fifo clusterer_list_cap Cluster:: 1 Capability:: usrloc-contact-repl State=not synced And we found the below log INFO:usrloc:receive_binary_packets: discarding , ver 1: need ver 2 Is there anything I missed? where should I change the version to 2? -- Regards, William Jin -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Wed Jul 1 06:30:18 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 1 Jul 2020 09:30:18 +0300 Subject: [OpenSIPS-Users] Carrier ID for accounting In-Reply-To: References: Message-ID: Hi, Vic! The acc extra_fields syntax is not ok - just use `carrierid` if the field has the same name with the column table. Please check the documentation[1] for more details. [1] https://opensips.org/docs/modules/3.1.x/acc.html#param_extra_fields Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 7/1/20 7:33 AM, Vic Jolin wrote: > Hi, > > I was trying to put the carrier id in the acc extra fields but Im getting > > Jul  1 04:00:16 Opensip opensips: #011$acc_extra(carrierid) = > $avp(carrier_id); > Jul  1 04:00:16 Opensip opensips: #011^~~~~~~~~~~~~~~~~~~~~~ > Jul  1 04:00:16 Opensip opensips: > Jul  1 04:00:16 Opensip opensips: #011do_accounting("db"); > Jul  1 04:00:16 Opensip opensips: ERROR:core:parse_opensips_cfg: bad > config file (1 errors) > Jul  1 04:00:16 Opensip opensips: ERROR:core:main: failed to parse > config file (null) > Jul  1 04:00:16 Opensip opensips: NOTICE:core:main: Exiting.... > > I have this in the config > > modparam("acc", "extra_fields", "db: callerid->callerid; ani->ani; > prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; acctid->acctid; > carrierid=$avp(carrier_id);") > > Also, I would like to put the IP address of the gateway that last tried > to make the call, either missed or not, but sometimes I am also getting > the IP address of the originating call > > where should I put this? > > $acc_extra(dst_ip) = $rd; > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From razvan at opensips.org Wed Jul 1 06:31:50 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Wed, 1 Jul 2020 09:31:50 +0300 Subject: [OpenSIPS-Users] do_routing with failover to shorter prefix In-Reply-To: References: Message-ID: <6842c863-dfc7-6d1e-dfec-436841a97f9d@opensips.org> Hi, Vic! You should use the `F` flag for the do_routing() call. Please check documentation[1] for more details. [1] https://opensips.org/docs/modules/3.1.x/drouting#func_do_routing Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 6/25/20 5:59 PM, Ben Newlin wrote: > Yes, our configuration calls do_routing multiple times for different > failover cases. You may want to verify this but I believe that the > additional calls will append to the relevant AVPs used by the module, so > if you haven’t routed to all destinations, you may need to clear out the > AVPs prior to calling it again. I’m not positive on that part though; it > may overwrite existing values. > > We created a little helper route to do this: > > route[clear_dr_avps] > > { > >   avp_delete("$avp(dr_ruri)/g"); > >   avp_delete("$avp(dr_gw_id)/g"); > >   avp_delete("$avp(dr_gw_prfx)/g"); > >   avp_delete("$avp(dr_rule_id)/g"); > >   avp_delete("$avp(dr_rule_prfx)/g"); > >   avp_delete("$avp(dr_carr_id)/g"); > > } > > Ben Newlin > > *From: *Users on behalf of Vic Jolin > > *Reply-To: *OpenSIPS users mailling list > *Date: *Thursday, June 25, 2020 at 10:49 AM > *To: *"users at lists.opensips.org" > *Subject: *[OpenSIPS-Users] do_routing with failover to shorter prefix > > Hi, > > So I have this in my opensips.cfg > > if ( !do_routing($(avp(drgID){s.int > }),,,,,$var(gw_attributes)) ) { > send_reply(404,"No Route found"); > exit; > } > > And I know that do_routing will match on the longer prefix on dr_rules > table first. > > My question is > > Now after failing on all the routes, can we still do another do_routing > with shorter prefix matching? > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From liviu at opensips.org Wed Jul 1 06:39:49 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 1 Jul 2020 09:39:49 +0300 Subject: [OpenSIPS-Users] Usrloc can't be sync after upgrade to 2.4.8 In-Reply-To: References: Message-ID: <9f263e21-3f40-266e-c250-8fb59cc4d730@opensips.org> On 01.07.2020 09:25, William Jin wrote: > opensipsctl fifo clusterer_list_cap > Cluster:: 1 > Capability:: usrloc-contact-repl State=not synced > > And we found the below log > INFO:usrloc:receive_binary_packets: discarding , ver 1: need ver 2 > > Is there anything I missed? where should I change the version to 2? Hey, William! This change in the sync protocol version was introduced roughly 1 year ago in 2.4.7, because we had to add more information to the sync packet in order to fix some usrloc bug. Thus, the new and previous versions became incompatible, so we signified this via a new version, so a 2.4.7 instance doesn't crash when receiving data from a 2.4.6 one, and vice-versa. TL;DR: just upgrade both nodes to 2.4.8 and start from an empty list of bindings.  Things will get back to normal within 1 hour.  If this is not tolerable on your platform, try to dump the UDP contacts with MI "ul_dump" [1] before restarting the active node, then re-register them manually with the "ul_add" [2] command that and some Python scripting logic, for example. Best regards, [1]: https://opensips.org/docs/modules/2.4.x/usrloc.html#mi_ul_dump [2]: https://opensips.org/docs/modules/2.4.x/usrloc.html#mi_ul_add -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From adjolin at gmail.com Wed Jul 1 06:39:51 2020 From: adjolin at gmail.com (Vic Jolin) Date: Wed, 1 Jul 2020 14:39:51 +0800 Subject: [OpenSIPS-Users] Carrier ID for accounting In-Reply-To: References: Message-ID: Can you please give an example of how to use it? On Wed, Jul 1, 2020 at 2:33 PM Răzvan Crainea wrote: > Hi, Vic! > > The acc extra_fields syntax is not ok - just use `carrierid` if the > field has the same name with the column table. Please check the > documentation[1] for more details. > > [1] https://opensips.org/docs/modules/3.1.x/acc.html#param_extra_fields > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 7/1/20 7:33 AM, Vic Jolin wrote: > > Hi, > > > > I was trying to put the carrier id in the acc extra fields but Im getting > > > > Jul 1 04:00:16 Opensip opensips: #011$acc_extra(carrierid) = > > $avp(carrier_id); > > Jul 1 04:00:16 Opensip opensips: #011^~~~~~~~~~~~~~~~~~~~~~ > > Jul 1 04:00:16 Opensip opensips: > > Jul 1 04:00:16 Opensip opensips: #011do_accounting("db"); > > Jul 1 04:00:16 Opensip opensips: ERROR:core:parse_opensips_cfg: bad > > config file (1 errors) > > Jul 1 04:00:16 Opensip opensips: ERROR:core:main: failed to parse > > config file (null) > > Jul 1 04:00:16 Opensip opensips: NOTICE:core:main: Exiting.... > > > > I have this in the config > > > > modparam("acc", "extra_fields", "db: callerid->callerid; ani->ani; > > prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; acctid->acctid; > > carrierid=$avp(carrier_id);") > > > > Also, I would like to put the IP address of the gateway that last tried > > to make the call, either missed or not, but sometimes I am also getting > > the IP address of the originating call > > > > where should I put this? > > > > $acc_extra(dst_ip) = $rd; > > > > _______________________________________________ > > 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: From liviu at opensips.org Wed Jul 1 06:48:10 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 1 Jul 2020 09:48:10 +0300 Subject: [OpenSIPS-Users] Usrloc can't be sync after upgrade to 2.4.8 In-Reply-To: <9f263e21-3f40-266e-c250-8fb59cc4d730@opensips.org> References: <9f263e21-3f40-266e-c250-8fb59cc4d730@opensips.org> Message-ID: <70aa79e3-5c4d-8efc-8d11-ff491125619d@opensips.org> On 01.07.2020 09:39, Liviu Chircu wrote: > then re-register them manually with the "ul_add" [2] command that and > some Python scripting logic, for example. Sorry, I meant bash, not Python.  Not that I have anything against Python, but the former script (basically a simple loop) is much quicker to write in order to achieve your purpose. -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com From williamj at exetel.com.au Thu Jul 2 01:24:34 2020 From: williamj at exetel.com.au (William Jin) Date: Thu, 2 Jul 2020 01:24:34 +0000 Subject: [OpenSIPS-Users] Usrloc can't be sync after upgrade to 2.4.8 In-Reply-To: <70aa79e3-5c4d-8efc-8d11-ff491125619d@opensips.org> References: <9f263e21-3f40-266e-c250-8fb59cc4d730@opensips.org>, <70aa79e3-5c4d-8efc-8d11-ff491125619d@opensips.org> Message-ID: Hi, Thanks for the info. I have upgraded both nodes to latest 2.4.8, and restarted opensips on both nodes so it should start from empty. The error "INFO:usrloc:receive_binary_packets: discarding , ver 1: need ver 2" is gone. However, the 2nd node usrloc is still not synced with 1st node(seed), even manually issue the command opensipsctl fifo ul_cluster_sync. my config: (on both node) # ----- usrloc params ----- modparam("usrloc", "cluster_mode", "full-sharing") modparam("usrloc", "nat_bflag", "NAT") modparam("usrloc", "location_cluster", 1) modparam("usrloc", "restart_persistency", "sync-from-cluster") The clusterer table: id | cluster_id | node_id | url | state | no_ping_retries | priority | sip_addr | description | flags ----+------------+---------+--------------------+-------+-----------------+----------+----------+-------------+------- 2 | 1 | 2 | bin:10.2.2.16:5566 | 1 | 3 | 50 | | node2 | 1 | 1 | 1 | bin:10.2.2.15:5566 | 1 | 3 | 50 | | node1 | seed >From node1 log: Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:handle_internal_msg: Node [2] is UP Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:handle_sync_request: Received sync request for capability 'dialog-dlg-repl' from node 2, cluster 1 Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:send_sync_repl: Sent all sync packets for capability 'dialog-dlg-repl' to node 2, cluster 1 Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:handle_sync_request: Received sync request for capability 'usrloc-contact-repl' from node 2, cluster 1 Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:msg_send: send() to 10.2.2.16:5566 for proto bin/7 failed Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:msg_send_retry: msg_send() to node [2] failed Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:cl_sync_chunk_start: Failed to send sync packet ... Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:cl_sync_chunk_start: Failed to send sync packet Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:send_sync_repl: Failed to send sync packet, rc=-1 Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:send_sync_repl: Failed to send sync end message Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:handle_internal_msg: Node [2] is UP Node2 log: Jul 2 10:55:56 /usr/sbin/opensips[13782]: INFO:clusterer:handle_internal_msg: Node [1] is UP Jul 2 10:55:56 /usr/sbin/opensips[13782]: INFO:clusterer:send_sync_req: Sent sync request for capability 'dialog-dlg-repl' to node 1, cluster 1 Jul 2 10:55:56 /usr/sbin/opensips[13782]: INFO:clusterer:send_sync_req: Sent sync request for capability 'usrloc-contact-repl' to node 1, cluster 1 Jul 2 10:55:56 /usr/sbin/opensips[13782]: INFO:clusterer:handle_sync_packet: Received all sync packets for capability 'dialog-dlg-repl' in cluster 1 Jul 2 10:55:56 /usr/sbin/opensips[13793]: INFO:core:probe_max_sock_buff: using snd buffer of 512 kb Jul 2 10:55:56 /usr/sbin/opensips[13793]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 184 we have around 30,000 end devices(UDP), and I found the https://github.com/OpenSIPS/opensips/issues/1976, not sure if it's related Any idea? Do I need to increase the ping_timeout and give it a try? -- Regards, William Jin ________________________________ From: Users on behalf of Liviu Chircu Sent: Wednesday, 1 July 2020 4:48 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Usrloc can't be sync after upgrade to 2.4.8 On 01.07.2020 09:39, Liviu Chircu wrote: > then re-register them manually with the "ul_add" [2] command that and > some Python scripting logic, for example. Sorry, I meant bash, not Python. Not that I have anything against Python, but the former script (basically a simple loop) is much quicker to write in order to achieve your purpose. -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.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 adjolin at gmail.com Thu Jul 2 03:04:53 2020 From: adjolin at gmail.com (Vic Jolin) Date: Thu, 2 Jul 2020 11:04:53 +0800 Subject: [OpenSIPS-Users] Carrier ID for accounting In-Reply-To: References: Message-ID: Where can I get the carrier attributes? On Wed, Jul 1, 2020 at 2:33 PM Răzvan Crainea wrote: > Hi, Vic! > > The acc extra_fields syntax is not ok - just use `carrierid` if the > field has the same name with the column table. Please check the > documentation[1] for more details. > > [1] https://opensips.org/docs/modules/3.1.x/acc.html#param_extra_fields > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 7/1/20 7:33 AM, Vic Jolin wrote: > > Hi, > > > > I was trying to put the carrier id in the acc extra fields but Im getting > > > > Jul 1 04:00:16 Opensip opensips: #011$acc_extra(carrierid) = > > $avp(carrier_id); > > Jul 1 04:00:16 Opensip opensips: #011^~~~~~~~~~~~~~~~~~~~~~ > > Jul 1 04:00:16 Opensip opensips: > > Jul 1 04:00:16 Opensip opensips: #011do_accounting("db"); > > Jul 1 04:00:16 Opensip opensips: ERROR:core:parse_opensips_cfg: bad > > config file (1 errors) > > Jul 1 04:00:16 Opensip opensips: ERROR:core:main: failed to parse > > config file (null) > > Jul 1 04:00:16 Opensip opensips: NOTICE:core:main: Exiting.... > > > > I have this in the config > > > > modparam("acc", "extra_fields", "db: callerid->callerid; ani->ani; > > prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; acctid->acctid; > > carrierid=$avp(carrier_id);") > > > > Also, I would like to put the IP address of the gateway that last tried > > to make the call, either missed or not, but sometimes I am also getting > > the IP address of the originating call > > > > where should I put this? > > > > $acc_extra(dst_ip) = $rd; > > > > _______________________________________________ > > 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: From williamj at exetel.com.au Thu Jul 2 04:24:44 2020 From: williamj at exetel.com.au (William Jin) Date: Thu, 2 Jul 2020 04:24:44 +0000 Subject: [OpenSIPS-Users] Usrloc can't be sync after upgrade to 2.4.8 In-Reply-To: References: <9f263e21-3f40-266e-c250-8fb59cc4d730@opensips.org>, <70aa79e3-5c4d-8efc-8d11-ff491125619d@opensips.org>, Message-ID: Found some extra error logs that might be related to this. checking how we can fix this /usr/sbin/opensips[1983]: ERROR:proto_bin:add_write_chunk: We have reached the limit of max async postponed chunks /usr/sbin/opensips[1983]: ERROR:proto_bin:proto_bin_send: failed to send /usr/sbin/opensips[1983]: ERROR:clusterer:msg_send: send() to 10.2.2.16:5566 for proto bin/7 failed -- Regards, William Jin ________________________________ From: William Jin Sent: Thursday, 2 July 2020 11:24 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Usrloc can't be sync after upgrade to 2.4.8 Hi, Thanks for the info. I have upgraded both nodes to latest 2.4.8, and restarted opensips on both nodes so it should start from empty. The error "INFO:usrloc:receive_binary_packets: discarding , ver 1: need ver 2" is gone. However, the 2nd node usrloc is still not synced with 1st node(seed), even manually issue the command opensipsctl fifo ul_cluster_sync. my config: (on both node) # ----- usrloc params ----- modparam("usrloc", "cluster_mode", "full-sharing") modparam("usrloc", "nat_bflag", "NAT") modparam("usrloc", "location_cluster", 1) modparam("usrloc", "restart_persistency", "sync-from-cluster") The clusterer table: id | cluster_id | node_id | url | state | no_ping_retries | priority | sip_addr | description | flags ----+------------+---------+--------------------+-------+-----------------+----------+----------+-------------+------- 2 | 1 | 2 | bin:10.2.2.16:5566 | 1 | 3 | 50 | | node2 | 1 | 1 | 1 | bin:10.2.2.15:5566 | 1 | 3 | 50 | | node1 | seed >From node1 log: Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:handle_internal_msg: Node [2] is UP Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:handle_sync_request: Received sync request for capability 'dialog-dlg-repl' from node 2, cluster 1 Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:send_sync_repl: Sent all sync packets for capability 'dialog-dlg-repl' to node 2, cluster 1 Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:handle_sync_request: Received sync request for capability 'usrloc-contact-repl' from node 2, cluster 1 Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:msg_send: send() to 10.2.2.16:5566 for proto bin/7 failed Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:msg_send_retry: msg_send() to node [2] failed Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:cl_sync_chunk_start: Failed to send sync packet ... Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:cl_sync_chunk_start: Failed to send sync packet Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:send_sync_repl: Failed to send sync packet, rc=-1 Jul 2 10:55:56 /usr/sbin/opensips[1983]: ERROR:clusterer:send_sync_repl: Failed to send sync end message Jul 2 10:55:56 /usr/sbin/opensips[1983]: INFO:clusterer:handle_internal_msg: Node [2] is UP Node2 log: Jul 2 10:55:56 /usr/sbin/opensips[13782]: INFO:clusterer:handle_internal_msg: Node [1] is UP Jul 2 10:55:56 /usr/sbin/opensips[13782]: INFO:clusterer:send_sync_req: Sent sync request for capability 'dialog-dlg-repl' to node 1, cluster 1 Jul 2 10:55:56 /usr/sbin/opensips[13782]: INFO:clusterer:send_sync_req: Sent sync request for capability 'usrloc-contact-repl' to node 1, cluster 1 Jul 2 10:55:56 /usr/sbin/opensips[13782]: INFO:clusterer:handle_sync_packet: Received all sync packets for capability 'dialog-dlg-repl' in cluster 1 Jul 2 10:55:56 /usr/sbin/opensips[13793]: INFO:core:probe_max_sock_buff: using snd buffer of 512 kb Jul 2 10:55:56 /usr/sbin/opensips[13793]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 184 we have around 30,000 end devices(UDP), and I found the https://github.com/OpenSIPS/opensips/issues/1976, not sure if it's related Any idea? Do I need to increase the ping_timeout and give it a try? -- Regards, William Jin ________________________________ From: Users on behalf of Liviu Chircu Sent: Wednesday, 1 July 2020 4:48 PM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] Usrloc can't be sync after upgrade to 2.4.8 On 01.07.2020 09:39, Liviu Chircu wrote: > then re-register them manually with the "ul_add" [2] command that and > some Python scripting logic, for example. Sorry, I meant bash, not Python. Not that I have anything against Python, but the former script (basically a simple loop) is much quicker to write in order to achieve your purpose. -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.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 mark at markmiranda.com Thu Jul 2 16:11:16 2020 From: mark at markmiranda.com (Mark Miranda) Date: Thu, 2 Jul 2020 11:11:16 -0500 Subject: [OpenSIPS-Users] OpenSIPS as Teams SBC RTP->SRTP Question In-Reply-To: <000401d6158d$543156e0$fc9404a0$@smartvox.co.uk> References: <000401d6158d$543156e0$fc9404a0$@smartvox.co.uk> Message-ID: Hi John, Thanks for the references. I am still struggling with this though. The response I am getting from Teams is either SdpParsingError or BackToBackSessionTerminated and I cannot determine why. Do you happen to have a working example? Thanks! Mark > On Apr 18, 2020, at 9:26 AM, John Quick wrote: > > I have written a couple of articles which, between them, should help you > with this question. > The first article looks at WebRTC <--> SIP using rtpengine: > https://kb.smartvox.co.uk/opensips/webrtc-using-opensips-and-rtpengine/ > The other one discusses how you configure OpenSIPS 2.2.x for TLS: > https://kb.smartvox.co.uk/opensips/using-tls-in-opensips-v2-2-x/ > ..in the third paragraph it mentions about SRTP-RTP transcoding with a cross > reference to the first article and with a note about how to adjust the > parameters sent to rtpengine so they will work for SRTP (SAVP) instead of > WebRTC (SAVPF). So together it should provide you with the examples and > explanations you seek. > > I have been working on setting up a Teams SBC over the last 2 weeks. I have > it working with calls in both directions and it is using rtpengine exactly > as described in my two articles. > Have you read the blog/knowledgebase article on the opensips web site about > Teams SBC? > https://blog.opensips.org/2019/09/16/opensips-as-ms-teams-sbc/ > > John Quick > Smartvox Limited > Web: www.smartvox.co.uk > > >>> I see that there is an rtpengine module for OpenSIPS but I could not find > a good example of how this could be used to encrypt the RTP packets as it > passes to teams? >>> >>> Anyone have a working example of this? Or even better, something already > working with Teams? > From adjolin at gmail.com Thu Jul 2 16:13:29 2020 From: adjolin at gmail.com (Vic Jolin) Date: Fri, 3 Jul 2020 00:13:29 +0800 Subject: [OpenSIPS-Users] Carrier ID and Rule ID not populating flatstore Message-ID: Hello, I have this for drouting loadmodule "drouting.so" modparam("drouting", "rule_prefix_avp", '$avp(dr_prefix)') modparam("drouting", "carrier_id_avp", '$avp(carrier_id)') modparam("drouting", "gw_id_avp", '$avp(gw_id)') modparam("drouting", "ruri_avp", '$avp(dr_ruri)') modparam("drouting", "gw_priprefix_avp", '$avp(gw_priprefix)') modparam("drouting", "rule_id_avp", '$avp(rule_id)') and for acc modparam("acc", "extra_fields", "db: callerid->callerid; ani->ani; prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; acctid->acctid; carrierid->$avp(carrier_id); ruleid->$avp(rule_id)") modparam("acc", "db_url", "flatstore:/var/log/acc") Can anyone tell me why on the flatstore files the carrierid, and ruleid is empty? -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Fri Jul 3 07:57:29 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Fri, 3 Jul 2020 10:57:29 +0300 Subject: [OpenSIPS-Users] Carrier ID and Rule ID not populating flatstore In-Reply-To: References: Message-ID: Hi, Vic! You are not using the correct provisioning in the extra fields. Please double check the ACC module documentation[1], where it states that for the db engine, the log_name represents the column in the acc table where that value ends up. According to your specifications, you want to dump the carrierid in the $avp(carrier_id) table; luckily for the flatstore engine the column is not relevant, as it is nowhere used. If you want to get the carrierid and ruleid values in the flatstore, you have to explicitly set the corresponding tags in your script: $acc_extra(carrierid) = $avp(carrier_id); $acc_extra(ruleid) = $avp(rule_id); Make sure to do that after you call do_routing(). [1] https://opensips.org/docs/modules/3.1.x/acc.html#ACC-extra-id Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 7/2/20 7:13 PM, Vic Jolin wrote: > Hello, > > I have this for drouting > loadmodule "drouting.so" > modparam("drouting", "rule_prefix_avp", '$avp(dr_prefix)') > modparam("drouting", "carrier_id_avp", '$avp(carrier_id)') > modparam("drouting", "gw_id_avp", '$avp(gw_id)') > modparam("drouting", "ruri_avp", '$avp(dr_ruri)') > modparam("drouting", "gw_priprefix_avp", '$avp(gw_priprefix)') > modparam("drouting", "rule_id_avp", '$avp(rule_id)') > > and for acc > > modparam("acc", "extra_fields", "db: callerid->callerid; ani->ani; > prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; acctid->acctid; > carrierid->$avp(carrier_id); ruleid->$avp(rule_id)") > modparam("acc", "db_url", "flatstore:/var/log/acc") > > Can anyone tell me why on the flatstore files the carrierid, and ruleid > is empty? > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From Chris.Johnson at froneri.com Fri Jul 3 11:48:34 2020 From: Chris.Johnson at froneri.com (Chris Johnson) Date: Fri, 3 Jul 2020 11:48:34 +0000 Subject: [OpenSIPS-Users] Opensips MS Teams lost BYE In-Reply-To: References: Message-ID: Hi, I am wondering if someone can please help us? We are struggling to get the BYE packet to go back to MS Teams when the call is initiated by Teams. Our setup is as follows: MS Teams < --- > SBC External 64.x.x.x < --- > SBC Internal 10.11.250.3 < --- > FreePBX (internal only) 10.11.250.1 < --- > SIP Provider < --- > Mobile (external number) Now we are getting calls routed both ways with audio. The problem when the MS Teams calls the Mobile and the Mobile ends the call, the BYE doesn't go back to MS Teams and FreePBX looks like it tries to send the BYE to the external IP address of the SBC, instead of via the internal then external. This is what happens the mobile ends the call and the BYE packet is routed as follows: Mobile --- > SIP Provider --- > FreePBX 10.11.250.1 ---> SBC External 64.x.x.x ---> LOST How do we get the BYE packet to route correctly back through the SBC and onto MS? Thanks Chris Here is our script if that helps: /* comment the next line to enable the auto discovery of local aliases based on reverse DNS on IPs */ auto_aliases=no alias=tls:sbc01.froneri.com:5061 alias=udp:sbc01.froneri.com:5060 alias=tcp:sbc01.froneri.com:5060 #alias=tls:62.54.11.4:5061 listen=udp:10.11.250.3:5060 #as 62.54.11.41 listen=tcp:10.11.250.3:5060 #as 62.54.11.41 listen=tls:10.11.250.3:5061 #as 62.54.11.41 # listen=hep_tcp:10.11.250.3:9060 #advertised_address=62.54.11.4 advertised_address=sbc01.froneri.com #### NAT module loadmodule "nathelper.so" modparam("nathelper", "natping_interval", 10) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_bflag", "SIP_PING_FLAG") modparam("nathelper", "sipping_from", "sip:pinger at 62.54.11.4") #CUSTOMIZE ME modparam("nathelper", "received_avp", "$avp(received_nh)") ####### Routing Logic ######## # main request routing logic route{ #sip_trace("tid"); force_rport(); if (nat_uac_test("23")) { if (is_method("REGISTER")) { fix_nated_register(); setbflag(NAT); } else { fix_nated_contact(); setflag(NAT); } } if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(is_method("OPTIONS")) { # xlog("L_INFO", "[MS TEAMS] OPTIONS In\n"); set_advertised_address("62.54.11.41"); set_advertised_port("5061"); sl_send_reply("200", "OK"); exit; } # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) sip_trace("tid"); t_relay(); exit; } # absorb retransmissions, but do not create transaction t_check_trans(); if (has_totag()) { sip_trace("tid"); # handle hop-by-hop ACK (no routing required) if ( is_method("ACK") && t_check_trans() ) { xlog("[INFO] has totag & transaction id ACK pass straight out RURI=$ruri, SI=$si, M=$rm\n"); t_relay(); exit; } # sequential request within a dialog should # take the path determined by record-routing if(is_method("INVITE") && !check_source_address("0")) { xlog("[INFO] In dialog Method=$rm, RURI=$ruri, SI=$si ,DU=$du\n"); xlog("[ROUTE] t_relay Route SIP Message \n$mb\n"); t_relay(); } if ( !loose_route() ) { # we do record-routing for all our traffic, so we should not # receive any sequential requests without Route hdr. sl_send_reply("404", "Not here"); exit; } # route it out to whatever destination was set by loose_route() # in $du (destination URI). #xlog("[INFO] sequential requests Route SIP Message \n$mb\n"); xlog("[INFO] has totag RURI=$ruri, SI=$si, M=$rm\n"); route(relay); exit; } # record routing if (is_method("INVITE") && ! has_totag() && check_source_address("0")) { xlog("[ROUTE] Incoming call from PBX to MS TEAMS: RURI=$ruri, SI=$si, M=$rm\n"); sip_trace("tid"); strip(1); do_routing("1"); #prefix("+49"); record_route_preset("sbc01.froneri.com:5061;transport=tls;r2=on", "10.11.250.3:5060;r2=on"); #record_route_preset("sbc01.froneri.com:5061;transport=tls"); #add_rr_param(";r2=on"); route(relay); } else if (is_method("INVITE") && ! has_totag() && !check_source_address("0")) { sip_trace("tid"); create_dialog(); t_on_reply("handle_nat"); #record_route_preset("10.11.250.3:5060;r2=on", "sbc01.froneri.com:5061;transport=tls;r2=on"); record_route(); xlog("[ROUTE] Incoming call from MS TEAMS to PBX: RURI=$ruri, SI=$si, M=$rm\n"); rewritehostport("10.11.250.1:5060"); force_send_socket(udp:10.11.250.3:5060); route(relay); } if (check_route_param("nat=yes")){ setflag(NAT); #route it out to whatever destination was set by loose_route() #in $du (destination URI). record_route(); route(relay); } record_route(); route(relay); } route[relay] { if (isflagset(NAT)) { add_rr_param(";nat=yes"); } xlog("[ON ROUTE] route[relay]: Method=$rm, RURI=$ruri, SI=$si, M=$rm\n"); if (is_method("INVITE") && ! has_totag() ) { t_newtran(); t_on_reply("handle_nat"); t_on_failure("missed_call"); # if we have an application/sdp on our body, so we execute # the rtpproxy_offer if(has_body("application/sdp")){ xlog("[RTPPROXY] route[relay] we have sdp on this message\n$rm\n"); rtpproxy_offer("co", "62.54.11.4"); } } if(is_method("ACK") && has_body("application/sdp")){ xlog("[RTPPROXY] onreply_route[handle_nat] ACK rtpproxy_answer\n"); rtpproxy_answer("co", "62.54.11.4"); } xlog("[INFO] Method=$rm, RURI=$ruri, SI=$si ,DU=$du\n"); if (!t_relay()) { send_reply("500","Internal Error"); } exit; } branch_route[per_branch_ops] { xlog("[INFO] New branch at $ru\n"); } onreply_route[handle_nat] { xlog("[INFO] onreply_route[handle_nat]: RR=$rr, RS=$rs, SI=$si\n$mb\n"); # we receive a reply, we need to check about application/sdp # on our body, if we have, we answer that if(is_method("ACK") && has_body("application/sdp")){ xlog("[RTPPROXY] onreply_route[handle_nat] ACK rtpproxy_answer\n"); rtpproxy_answer("co", "62.54.11.4"); } if (nat_uac_test("1")){ xlog("[INFO] nat_uac_test=1: RR=$rr, RS=$rs, SI=$si\n$mb\n"); fix_nated_contact(); } if ( isflagset(NAT) && has_body("application/sdp") ){ xlog("[INFO] isflagset[NAT] && has_body sdp RR=$rr, RS=$rs, SI=$si\n$mb\n"); rtpproxy_answer("co", "62.54.11.4"); xlog("incoming reply\n"); } } failure_route[missed_call] { if (t_was_cancelled()) { exit; } } local_route { $var(dst) = "pstnhub.microsoft.com"; if (is_method("OPTIONS") && ($(ru{s.index, $var(dst)}) != NULL)){ set_advertised_address("62.54.11.41"); set_advertised_port("5061"); append_hf("Contact: \r\n"); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From adjolin at gmail.com Fri Jul 3 11:53:57 2020 From: adjolin at gmail.com (Vic Jolin) Date: Fri, 3 Jul 2020 19:53:57 +0800 Subject: [OpenSIPS-Users] Carrier ID and Rule ID not populating flatstore In-Reply-To: References: Message-ID: Thank you for your response. Can I do this on the route or on failure route? On Fri, Jul 3, 2020, 4:00 PM Răzvan Crainea, wrote: > Hi, Vic! > > You are not using the correct provisioning in the extra fields. Please > double check the ACC module documentation[1], where it states that for > the db engine, the log_name represents the column in the acc table where > that value ends up. > According to your specifications, you want to dump the carrierid in the > $avp(carrier_id) table; luckily for the flatstore engine the column is > not relevant, as it is nowhere used. > > If you want to get the carrierid and ruleid values in the flatstore, you > have to explicitly set the corresponding tags in your script: > > $acc_extra(carrierid) = $avp(carrier_id); > $acc_extra(ruleid) = $avp(rule_id); > > Make sure to do that after you call do_routing(). > > [1] https://opensips.org/docs/modules/3.1.x/acc.html#ACC-extra-id > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 7/2/20 7:13 PM, Vic Jolin wrote: > > Hello, > > > > I have this for drouting > > loadmodule "drouting.so" > > modparam("drouting", "rule_prefix_avp", '$avp(dr_prefix)') > > modparam("drouting", "carrier_id_avp", '$avp(carrier_id)') > > modparam("drouting", "gw_id_avp", '$avp(gw_id)') > > modparam("drouting", "ruri_avp", '$avp(dr_ruri)') > > modparam("drouting", "gw_priprefix_avp", '$avp(gw_priprefix)') > > modparam("drouting", "rule_id_avp", '$avp(rule_id)') > > > > and for acc > > > > modparam("acc", "extra_fields", "db: callerid->callerid; ani->ani; > > prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; acctid->acctid; > > carrierid->$avp(carrier_id); ruleid->$avp(rule_id)") > > modparam("acc", "db_url", "flatstore:/var/log/acc") > > > > Can anyone tell me why on the flatstore files the carrierid, and ruleid > > is empty? > > > > _______________________________________________ > > 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: From Chris.Johnson at froneri.com Fri Jul 3 14:07:03 2020 From: Chris.Johnson at froneri.com (Chris Johnson) Date: Fri, 3 Jul 2020 14:07:03 +0000 Subject: [OpenSIPS-Users] FW: Opensips MS Teams lost BYE In-Reply-To: References: Message-ID: Hi, Just letting you all know that I've managed to get the PBX to send the BYE to the SBC and it is now forwarding on to MS (although MS are not sending a reply but we have opened a case for this). What I did was to comment out the advertised_address to stop advertising the sbc01.froneri.com address globally, then only advertised it on the TLS listener: alias=tls:sbc01.froneri.com:5061 #alias=udp:sbc01.froneri.com:5060 #alias=tcp:sbc01.froneri.com:5060 listen=udp:10.11.250.3:5060 listen=tcp:10.11.250.3:5060 listen=tls:10.11.250.3:5061 as sbc01.froneri.com:5061 #advertised_address=sbc01.froneri.com Cheers Chris From: Chris Johnson Sent: 03 July 2020 12:49 To: users at lists.opensips.org Subject: Opensips MS Teams lost BYE Hi, I am wondering if someone can please help us? We are struggling to get the BYE packet to go back to MS Teams when the call is initiated by Teams. Our setup is as follows: MS Teams < --- > SBC External 64.x.x.x < --- > SBC Internal 10.11.250.3 < --- > FreePBX (internal only) 10.11.250.1 < --- > SIP Provider < --- > Mobile (external number) Now we are getting calls routed both ways with audio. The problem when the MS Teams calls the Mobile and the Mobile ends the call, the BYE doesn't go back to MS Teams and FreePBX looks like it tries to send the BYE to the external IP address of the SBC, instead of via the internal then external. This is what happens the mobile ends the call and the BYE packet is routed as follows: Mobile --- > SIP Provider --- > FreePBX 10.11.250.1 ---> SBC External 64.x.x.x ---> LOST How do we get the BYE packet to route correctly back through the SBC and onto MS? Thanks Chris Here is our script if that helps: /* comment the next line to enable the auto discovery of local aliases based on reverse DNS on IPs */ auto_aliases=no alias=tls:sbc01.froneri.com:5061 alias=udp:sbc01.froneri.com:5060 alias=tcp:sbc01.froneri.com:5060 #alias=tls:62.54.11.4:5061 listen=udp:10.11.250.3:5060 #as 62.54.11.41 listen=tcp:10.11.250.3:5060 #as 62.54.11.41 listen=tls:10.11.250.3:5061 #as 62.54.11.41 # listen=hep_tcp:10.11.250.3:9060 #advertised_address=62.54.11.4 advertised_address=sbc01.froneri.com #### NAT module loadmodule "nathelper.so" modparam("nathelper", "natping_interval", 10) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_bflag", "SIP_PING_FLAG") modparam("nathelper", "sipping_from", "sip:pinger at 62.54.11.4") #CUSTOMIZE ME modparam("nathelper", "received_avp", "$avp(received_nh)") ####### Routing Logic ######## # main request routing logic route{ #sip_trace("tid"); force_rport(); if (nat_uac_test("23")) { if (is_method("REGISTER")) { fix_nated_register(); setbflag(NAT); } else { fix_nated_contact(); setflag(NAT); } } if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(is_method("OPTIONS")) { # xlog("L_INFO", "[MS TEAMS] OPTIONS In\n"); set_advertised_address("62.54.11.41"); set_advertised_port("5061"); sl_send_reply("200", "OK"); exit; } # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) sip_trace("tid"); t_relay(); exit; } # absorb retransmissions, but do not create transaction t_check_trans(); if (has_totag()) { sip_trace("tid"); # handle hop-by-hop ACK (no routing required) if ( is_method("ACK") && t_check_trans() ) { xlog("[INFO] has totag & transaction id ACK pass straight out RURI=$ruri, SI=$si, M=$rm\n"); t_relay(); exit; } # sequential request within a dialog should # take the path determined by record-routing if(is_method("INVITE") && !check_source_address("0")) { xlog("[INFO] In dialog Method=$rm, RURI=$ruri, SI=$si ,DU=$du\n"); xlog("[ROUTE] t_relay Route SIP Message \n$mb\n"); t_relay(); } if ( !loose_route() ) { # we do record-routing for all our traffic, so we should not # receive any sequential requests without Route hdr. sl_send_reply("404", "Not here"); exit; } # route it out to whatever destination was set by loose_route() # in $du (destination URI). #xlog("[INFO] sequential requests Route SIP Message \n$mb\n"); xlog("[INFO] has totag RURI=$ruri, SI=$si, M=$rm\n"); route(relay); exit; } # record routing if (is_method("INVITE") && ! has_totag() && check_source_address("0")) { xlog("[ROUTE] Incoming call from PBX to MS TEAMS: RURI=$ruri, SI=$si, M=$rm\n"); sip_trace("tid"); strip(1); do_routing("1"); #prefix("+49"); record_route_preset("sbc01.froneri.com:5061;transport=tls;r2=on", "10.11.250.3:5060;r2=on"); #record_route_preset("sbc01.froneri.com:5061;transport=tls"); #add_rr_param(";r2=on"); route(relay); } else if (is_method("INVITE") && ! has_totag() && !check_source_address("0")) { sip_trace("tid"); create_dialog(); t_on_reply("handle_nat"); #record_route_preset("10.11.250.3:5060;r2=on", "sbc01.froneri.com:5061;transport=tls;r2=on"); record_route(); xlog("[ROUTE] Incoming call from MS TEAMS to PBX: RURI=$ruri, SI=$si, M=$rm\n"); rewritehostport("10.11.250.1:5060"); force_send_socket(udp:10.11.250.3:5060); route(relay); } if (check_route_param("nat=yes")){ setflag(NAT); #route it out to whatever destination was set by loose_route() #in $du (destination URI). record_route(); route(relay); } record_route(); route(relay); } route[relay] { if (isflagset(NAT)) { add_rr_param(";nat=yes"); } xlog("[ON ROUTE] route[relay]: Method=$rm, RURI=$ruri, SI=$si, M=$rm\n"); if (is_method("INVITE") && ! has_totag() ) { t_newtran(); t_on_reply("handle_nat"); t_on_failure("missed_call"); # if we have an application/sdp on our body, so we execute # the rtpproxy_offer if(has_body("application/sdp")){ xlog("[RTPPROXY] route[relay] we have sdp on this message\n$rm\n"); rtpproxy_offer("co", "62.54.11.4"); } } if(is_method("ACK") && has_body("application/sdp")){ xlog("[RTPPROXY] onreply_route[handle_nat] ACK rtpproxy_answer\n"); rtpproxy_answer("co", "62.54.11.4"); } xlog("[INFO] Method=$rm, RURI=$ruri, SI=$si ,DU=$du\n"); if (!t_relay()) { send_reply("500","Internal Error"); } exit; } branch_route[per_branch_ops] { xlog("[INFO] New branch at $ru\n"); } onreply_route[handle_nat] { xlog("[INFO] onreply_route[handle_nat]: RR=$rr, RS=$rs, SI=$si\n$mb\n"); # we receive a reply, we need to check about application/sdp # on our body, if we have, we answer that if(is_method("ACK") && has_body("application/sdp")){ xlog("[RTPPROXY] onreply_route[handle_nat] ACK rtpproxy_answer\n"); rtpproxy_answer("co", "62.54.11.4"); } if (nat_uac_test("1")){ xlog("[INFO] nat_uac_test=1: RR=$rr, RS=$rs, SI=$si\n$mb\n"); fix_nated_contact(); } if ( isflagset(NAT) && has_body("application/sdp") ){ xlog("[INFO] isflagset[NAT] && has_body sdp RR=$rr, RS=$rs, SI=$si\n$mb\n"); rtpproxy_answer("co", "62.54.11.4"); xlog("incoming reply\n"); } } failure_route[missed_call] { if (t_was_cancelled()) { exit; } } local_route { $var(dst) = "pstnhub.microsoft.com"; if (is_method("OPTIONS") && ($(ru{s.index, $var(dst)}) != NULL)){ set_advertised_address("62.54.11.41"); set_advertised_port("5061"); append_hf("Contact: \r\n"); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.dyck at telus.net Sat Jul 4 03:06:16 2020 From: rob.dyck at telus.net (Robert Dyck) Date: Fri, 03 Jul 2020 20:06:16 -0700 Subject: [OpenSIPS-Users] Rtpengine configuration problem Message-ID: <4366901.e99z0qppnp@blacky.mylan> While configuring my script for rtpengine I got a rather confusing result. The test involved a UA tethered to a phone with only IPV4 availble. The test was a call to a UA registered with an IPV6 address. The call was answered successfully but there was no media. A sniffer at the rtpengine host ( also opensips ) revealed the following -- continuous binding request, no media wireless IPV4 -> rtpengine in port -> rtpengine out port -> IPV6 -> AB:CD:: The destination address was obviously bogus. Since the address was so short on a hunce I converted it to decimal. It turns out that the binding request was being sent to the NAT's public IPV4 address but as an IPV6 packet. The signalling looked. Is this a misconfiguration? Rtpengine is configured in bridging mode with an IPV4 address and an IPV6 address. INVTEe -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.dyck at telus.net Sat Jul 4 17:15:11 2020 From: rob.dyck at telus.net (Robert Dyck) Date: Sat, 04 Jul 2020 10:15:11 -0700 Subject: [OpenSIPS-Users] Rtpengine configuration problem In-Reply-To: <4366901.e99z0qppnp@blacky.mylan> References: <4366901.e99z0qppnp@blacky.mylan> Message-ID: <7647022.jRhZ6ZUK3Y@blacky.mylan> Answering my own question, it appears that rtpengine reverses the logic of rtpproxy with regard to the media source address. It trusts the "c" ( connection ) address that the UA puts there. In this case the UA had learned what its public address was. Rtpengine trusts this instead using the source address. Now that the binding request is going to the UA I have to find where the binding response is going. On Friday, July 3, 2020 8:06:16 P.M. PDT Robert Dyck wrote: While configuring my script for rtpengine I got a rather confusing result. The test involved a UA tethered to a phone with only IPV4 availble. The test was a call to a UA registered with an IPV6 address. The call was answered successfully but there was no media. A sniffer at the rtpengine host ( also opensips ) revealed the following -- continuous binding request, no media wireless IPV4 -> rtpengine in port -> rtpengine out port -> IPV6 -> AB:CD:: The destination address was obviously bogus. Since the address was so short on a hunce I converted it to decimal. It turns out that the binding request was being sent to the NAT's public IPV4 address but as an IPV6 packet. The signalling looked. Is this a misconfiguration? Rtpengine is configured in bridging mode with an IPV4 address and an IPV6 address. INVTEe -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.dyck at telus.net Sat Jul 4 19:34:37 2020 From: rob.dyck at telus.net (Robert Dyck) Date: Sat, 04 Jul 2020 12:34:37 -0700 Subject: [OpenSIPS-Users] SDES and DTLS mutually exclusive Message-ID: <6358933.2l3rmUXbR5@blacky.mylan> I have run into an issue with rtpengine and the ICE=force option. To quote the rtpengine README With `force`, ICE attributes are first stripped, then new attributes are When using the force option where I think it will be appropriate I found it also adds crypto attributes. I believe this invokes SDES security. If the setup attribute is also present ( DTLS security ) the call fails with bad description. SDES=off does not prevent this behaviour. The error message from the UA says there cannot be both. a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:/ msDyiV8x6qpcH4m1iEmxo8aqAAhhkGctQbxvkNy a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:JgDv7fMfKd1GQcFq9Jn0tMf1C5DE0VaRDe6Js8D6 a=crypto:3 AES_192_CM_HMAC_SHA1_80 inline:CiCkAETMov/tbVsqykp7j3/ PB7aUfQjv+nozBQuOUMBnJlrm8bU a=crypto:4 AES_192_CM_HMAC_SHA1_32 inline: 6ktVsgwfiGg4US2BLWuV3XpCt0fvkiuFgcEr8n83KDln8w9ar+c a=crypto:5 AES_256_CM_HMAC_SHA1_80 inline:l1pr/ 67vqwthDdnRoSaTbGvRPBNP7uHIhjfeG8InuqWQZjLkumU5MVKz2mAujw a=crypto:6 AES_256_CM_HMAC_SHA1_32 inline:V+K2bK8Zahr9KX7zswVwM2cpZ+/ g8hMD4a5PmJzncH8WgDnCH/xLH0CFRwYKgg a=crypto:7 F8_128_HMAC_SHA1_80 inline:Z00dhmeQwuttjeRawylGKannT7KbBZhDExDxETNo a=crypto:8 F8_128_HMAC_SHA1_32 inline:R5Vqt9WQ1wU76GcS7CvDosgbWHRYLV7CRnGre+uV a=crypto:9 NULL_HMAC_SHA1_80 inline:TP2aKDSKe8G9E7kd+w7XpOhcItzd0xmBN3g06WC1 a=crypto:10 NULL_HMAC_SHA1_32 inline:xKFUEuwLpexe84KKCulBSThMx75T74U7/K7qJbKi a=setup:actpass -------------- next part -------------- An HTML attachment was scrubbed... URL: From xaled at web.de Sat Jul 4 20:37:42 2020 From: xaled at web.de (xaled at web.de) Date: Sat, 4 Jul 2020 22:37:42 +0200 Subject: [OpenSIPS-Users] multi domain TLS in opensips 3.1 Message-ID: <076a01d65242$f7632f40$e6298dc0$@web.de> Hi, I'm trying to get multi domain TLS with MS Teams going and kind of stuck at the beginning. According to MS Teams interconnect tutorial tls_handshake_timeout shall be set to 300. Setting this parameter independent from TLS domain gives an error that parameter is not found. #modparam("tls_mgm", "tls_handshake_timeout", "300") # generic TLS server domain, if the client does not provide SNI modparam("tls_mgm", "server_domain", "test") modparam("tls_mgm", "match_ip_address", "[test]*") modparam("tls_mgm", "match_sip_domain", "[test]none") modparam("tls_mgm", "certificate", "[test]/etc/ssl/private/test.crt") modparam("tls_mgm", "private_key", "[test]/etc/ssl/private/test.key") modparam("tls_mgm", "ca_list", "[test]/etc/ssl/private/test-ca.pem") modparam("tls_mgm", "tls_method", "[test]TLSv1-") modparam("tls_mgm", "verify_cert", "[test]0") modparam("tls_mgm", "require_cert", "[test]0") # MS Teams TLS config modparam("tls_mgm", "server_domain", "test_dom") modparam("tls_mgm", "match_ip_address", "[test_dom]*") modparam("tls_mgm", "match_sip_domain", "[test_dom]sip4teams.test.com") #modparam("tls_mgm", "tls_handshake_timeout", [test_dom]300) modparam("tls_mgm", "certificate", "[test_dom]/etc/ssl/private/test.crt") modparam("tls_mgm", "private_key", "[test_dom]/etc/ssl/private/test.key") modparam("tls_mgm", "ca_list", "[test_dom]/etc/ssl/private/test-ca.pem") modparam("tls_mgm", "tls_method", "[test_dom]TLSv1_2") modparam("tls_mgm", "verify_cert", "[test_dom]1") modparam("tls_mgm", "require_cert", "[test_dom]1") Jul 4 22:17:34 sip4teams opensips: INFO:tls_mgm:mod_load: openssl version: OpenSSL 1.1.1d 10 Sep 2019 Jul 4 22:17:34 sip4teams opensips: ERROR:core:set_mod_param_regex: parameter not found in module Jul 4 22:17:34 sip4teams opensips: Traceback (last included file at the bottom): Jul 4 22:17:34 sip4teams opensips: 0. /etc/opensips/opensips.cfg Jul 4 22:17:34 sip4teams opensips: CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:61:21-22: Parameter not found in module - can't set Jul 4 22:17:34 sip4teams opensips: #set global tls parameters Jul 4 22:17:34 sip4teams opensips: Jul 4 22:17:34 sip4teams opensips: modparam("tls_mgm", "tls_handshake_timeout", 300) Jul 4 22:17:34 sip4teams opensips: ^~ Jul 4 22:17:34 sip4teams opensips: From adrian.fretwell at topgreen.co.uk Sun Jul 5 19:48:43 2020 From: adrian.fretwell at topgreen.co.uk (Adrian Fretwell) Date: Sun, 5 Jul 2020 20:48:43 +0100 Subject: [OpenSIPS-Users] May I ask for some help with MI interface please Message-ID: Hello, I'm having trouble with any MI command that has parameters over UDP MI_DATAGRAM. Below are a couple of captured packets: U 2020/07/05 20:24:55.472104 185.222.222.247:34176 -> 185.222.222.247:9061 #3 {"jsonrpc":"2.0","method":"get_statistics","id":"1075","params":["dialog:","tm:"]} U 2020/07/05 20:24:55.472233 185.222.222.247:9061 -> 185.222.222.247:34176 #4 {"jsonrpc":"2.0","error":{"code":-32602,"message":"Invalid params"},"id":"1075"} The request is identical to the example given in https://opensips.org/docs/modules/3.0.x/mi_datagram.html But as you can see I get an invalid params error  (dialog and tm modules are both loaded). A command without params is fine, see below: U 2020/07/05 20:24:23.650924 185.222.222.247:48846 -> 185.222.222.247:9061 #1 {"jsonrpc":"2.0","method":"which","id":"1065"} U 2020/07/05 20:24:23.651093 185.222.222.247:9061 -> 185.222.222.247:48846 #2 {"jsonrpc":"2.0","result":["get_statistics","list_statistics","reset_statistics","uptime","version","pwd","arg","which","ps","kill","log_level","xlog_level","shm_check","cache_store","cache_fetch","cache_remove","event_subscribe","events_list","subscribers_list","list_tcp_conns","mem_pkg_dump","mem_shm_dump","mem_rpm_dump","reload_routes","help","list_blacklists","t_uac_dlg","t_uac_cancel","t_hash","t_reply","dlg_list","dlg_list_ctx","dlg_end_dlg","dlg_db_sync","dlg_restore_db","dlg_cluster_sync","profile_get_size","profile_list_dlgs","profile_get_values","list_all_profiles","profile_end_dlgs","dlg_push_var","dlg_send_sequential","ul_rm","ul_rm_contact","ul_dump","ul_flush","ul_add","ul_show_contact","ul_sync","ul_cluster_sync","nh_enable_ping","refreshWatchers","refresh_watchers","cleanup","pres_expose","pres_phtable_list","subs_phtable_list","pua_publish","pua_subscribe","rls_update_subscriptions","tcp_trace"],"id":"1065"} Most of the documentation for the modules still shows the old non JSON way of communicating.  Can someone point me in the right direction please. Kind regards, Adrian Fretwell Sibthorpe Nottinghamshire UK. -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Mon Jul 6 07:25:44 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 6 Jul 2020 10:25:44 +0300 Subject: [OpenSIPS-Users] SDES and DTLS mutually exclusive In-Reply-To: <6358933.2l3rmUXbR5@blacky.mylan> References: <6358933.2l3rmUXbR5@blacky.mylan> Message-ID: <6361f39c-eb8f-932e-41fd-fcc802f7c7da@opensips.org> You should use the SDES-off flag to rtoengine. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 7/4/20 10:34 PM, Robert Dyck wrote: > I have run into an issue with rtpengine and the ICE=force option. > > To quote the rtpengine README > > With `force`, ICE attributes are first stripped, then new attributes are >        generated and inserted, which leaves the media proxy as the only > ICE candidate. > > When using the force option where I think it will be appropriate I found > it also adds crypto attributes. I believe this invokes SDES security. If > the setup attribute is also present ( DTLS security ) the call fails > with bad description. SDES=off does not prevent this behaviour. The > error message from the UA says there cannot be both. > > a=crypto:1 AES_CM_128_HMAC_SHA1_80 > inline:/msDyiV8x6qpcH4m1iEmxo8aqAAhhkGctQbxvkNy > > a=crypto:2 AES_CM_128_HMAC_SHA1_32 > inline:JgDv7fMfKd1GQcFq9Jn0tMf1C5DE0VaRDe6Js8D6 > > a=crypto:3 AES_192_CM_HMAC_SHA1_80 > inline:CiCkAETMov/tbVsqykp7j3/PB7aUfQjv+nozBQuOUMBnJlrm8bU > > a=crypto:4 AES_192_CM_HMAC_SHA1_32 > inline:6ktVsgwfiGg4US2BLWuV3XpCt0fvkiuFgcEr8n83KDln8w9ar+c > > a=crypto:5 AES_256_CM_HMAC_SHA1_80 > inline:l1pr/67vqwthDdnRoSaTbGvRPBNP7uHIhjfeG8InuqWQZjLkumU5MVKz2mAujw > > a=crypto:6 AES_256_CM_HMAC_SHA1_32 > inline:V+K2bK8Zahr9KX7zswVwM2cpZ+/g8hMD4a5PmJzncH8WgDnCH/xLH0CFRwYKgg > > a=crypto:7 F8_128_HMAC_SHA1_80 > inline:Z00dhmeQwuttjeRawylGKannT7KbBZhDExDxETNo > > a=crypto:8 F8_128_HMAC_SHA1_32 > inline:R5Vqt9WQ1wU76GcS7CvDosgbWHRYLV7CRnGre+uV > > a=crypto:9 NULL_HMAC_SHA1_80 inline:TP2aKDSKe8G9E7kd+w7XpOhcItzd0xmBN3g06WC1 > > a=crypto:10 NULL_HMAC_SHA1_32 > inline:xKFUEuwLpexe84KKCulBSThMx75T74U7/K7qJbKi > > a=setup:actpass > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From razvan at opensips.org Mon Jul 6 07:29:27 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 6 Jul 2020 10:29:27 +0300 Subject: [OpenSIPS-Users] multi domain TLS in opensips 3.1 In-Reply-To: <076a01d65242$f7632f40$e6298dc0$@web.de> References: <076a01d65242$f7632f40$e6298dc0$@web.de> Message-ID: <6a84bbf5-937e-143d-1d33-52f404888313@opensips.org> In OpenSIPS 3.1, the tls_handshake_timeout is no longer specified in the tls_module, but in each module that uses tls[1]. Therefore, most likely, you are looking at this parameter[2]. [1] https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0#toc15 [2] https://opensips.org/docs/modules/3.1.x/proto_tls.html#param_tls_handshake_timeout Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 7/4/20 11:37 PM, xaled at web.de wrote: > Hi, > > I'm trying to get multi domain TLS with MS Teams going and kind of stuck at the beginning. > According to MS Teams interconnect tutorial tls_handshake_timeout shall be set to 300. Setting this parameter independent from TLS domain gives an error that parameter is not found. > > #modparam("tls_mgm", "tls_handshake_timeout", "300") > > # generic TLS server domain, if the client does not provide SNI > modparam("tls_mgm", "server_domain", "test") > modparam("tls_mgm", "match_ip_address", "[test]*") > modparam("tls_mgm", "match_sip_domain", "[test]none") > modparam("tls_mgm", "certificate", "[test]/etc/ssl/private/test.crt") > modparam("tls_mgm", "private_key", "[test]/etc/ssl/private/test.key") > modparam("tls_mgm", "ca_list", "[test]/etc/ssl/private/test-ca.pem") > modparam("tls_mgm", "tls_method", "[test]TLSv1-") > modparam("tls_mgm", "verify_cert", "[test]0") > modparam("tls_mgm", "require_cert", "[test]0") > > > # MS Teams TLS config > modparam("tls_mgm", "server_domain", "test_dom") > modparam("tls_mgm", "match_ip_address", "[test_dom]*") > modparam("tls_mgm", "match_sip_domain", "[test_dom]sip4teams.test.com") > #modparam("tls_mgm", "tls_handshake_timeout", [test_dom]300) > modparam("tls_mgm", "certificate", "[test_dom]/etc/ssl/private/test.crt") > modparam("tls_mgm", "private_key", "[test_dom]/etc/ssl/private/test.key") > modparam("tls_mgm", "ca_list", "[test_dom]/etc/ssl/private/test-ca.pem") > modparam("tls_mgm", "tls_method", "[test_dom]TLSv1_2") > modparam("tls_mgm", "verify_cert", "[test_dom]1") > modparam("tls_mgm", "require_cert", "[test_dom]1") > > Jul 4 22:17:34 sip4teams opensips: INFO:tls_mgm:mod_load: openssl version: OpenSSL 1.1.1d 10 Sep 2019 > Jul 4 22:17:34 sip4teams opensips: ERROR:core:set_mod_param_regex: parameter not found in module > Jul 4 22:17:34 sip4teams opensips: Traceback (last included file at the bottom): > Jul 4 22:17:34 sip4teams opensips: 0. /etc/opensips/opensips.cfg > Jul 4 22:17:34 sip4teams opensips: CRITICAL:core:yyerror: parse error in /etc/opensips/opensips.cfg:61:21-22: Parameter ke_timeout> not found in module - can't set > Jul 4 22:17:34 sip4teams opensips: #set global tls parameters > Jul 4 22:17:34 sip4teams opensips: > Jul 4 22:17:34 sip4teams opensips: modparam("tls_mgm", "tls_handshake_timeout", 300) > Jul 4 22:17:34 sip4teams opensips: ^~ > Jul 4 22:17:34 sip4teams opensips: > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From john.quick at smartvox.co.uk Mon Jul 6 08:46:52 2020 From: john.quick at smartvox.co.uk (John Quick) Date: Mon, 6 Jul 2020 09:46:52 +0100 Subject: [OpenSIPS-Users] FW: Opensips MS Teams lost BYE Message-ID: <000201d65371$ff2ae760$fd80b620$@smartvox.co.uk> Chris, You must not call fix_nated_contact() for any SIP requests or SIP responses coming from MS Teams. If you do, it will cause exactly the problems you describe for loose-routed sequential requests such as BYE. Just to explain: fix_nated_contact() should only be used when the messages come via a NAT router. It must not be used for messages coming from a Proxy (assuming the Proxy adds a Record-Route header, as happens with Teams), even though both cases may appear to need fixing when you use nat_uac_test(). John Quick Smartvox Limited Web: www.smartvox.co.uk > I've managed to get the PBX to send the BYE to the SBC and it is now forwarding on to MS (although MS are not sending a reply but we have opened a case for this). > We are struggling to get the BYE packet to go back to MS Teams when the call is initiated by Teams. From adrian.fretwell at topgreen.co.uk Mon Jul 6 11:52:28 2020 From: adrian.fretwell at topgreen.co.uk (Adrian Fretwell) Date: Mon, 6 Jul 2020 12:52:28 +0100 Subject: [OpenSIPS-Users] May I ask for some help with MI interface please In-Reply-To: References: Message-ID: <83bb8cd1-4dcc-0058-d8cc-f89f4ea42a24@topgreen.co.uk> For the benefit of anyone else struggling with this, I eventually worked out that the example in the documentation should read: {"jsonrpc":"2.0","method":"get_statistics","id":"1065", "params":[["dialog:", "tm:"]]} This sets the list of statistics as an array in the params array (note the extra []). It's such a simple thing, but it has taken me 8 hours of trial and error to work out what was wrong. Kind regards, Adrian Fretwell Sibthorpe Nottinghamshire UK. On 05/07/2020 20:48, Adrian Fretwell wrote: > > Hello, > > I'm having trouble with any MI command that has parameters over UDP > MI_DATAGRAM. > > Below are a couple of captured packets: > > U 2020/07/05 20:24:55.472104 185.222.222.247:34176 -> > 185.222.222.247:9061 #3 > {"jsonrpc":"2.0","method":"get_statistics","id":"1075","params":["dialog:","tm:"]} > > > U 2020/07/05 20:24:55.472233 185.222.222.247:9061 -> > 185.222.222.247:34176 #4 > {"jsonrpc":"2.0","error":{"code":-32602,"message":"Invalid > params"},"id":"1075"} > > The request is identical to the example given in > https://opensips.org/docs/modules/3.0.x/mi_datagram.html But as you > can see I get an invalid params error  (dialog and tm modules are both > loaded). > > A command without params is fine, see below: > > > U 2020/07/05 20:24:23.650924 185.222.222.247:48846 -> > 185.222.222.247:9061 #1 > {"jsonrpc":"2.0","method":"which","id":"1065"} > > U 2020/07/05 20:24:23.651093 185.222.222.247:9061 -> > 185.222.222.247:48846 #2 > {"jsonrpc":"2.0","result":["get_statistics","list_statistics","reset_statistics","uptime","version","pwd","arg","which","ps","kill","log_level","xlog_level","shm_check","cache_store","cache_fetch","cache_remove","event_subscribe","events_list","subscribers_list","list_tcp_conns","mem_pkg_dump","mem_shm_dump","mem_rpm_dump","reload_routes","help","list_blacklists","t_uac_dlg","t_uac_cancel","t_hash","t_reply","dlg_list","dlg_list_ctx","dlg_end_dlg","dlg_db_sync","dlg_restore_db","dlg_cluster_sync","profile_get_size","profile_list_dlgs","profile_get_values","list_all_profiles","profile_end_dlgs","dlg_push_var","dlg_send_sequential","ul_rm","ul_rm_contact","ul_dump","ul_flush","ul_add","ul_show_contact","ul_sync","ul_cluster_sync","nh_enable_ping","refreshWatchers","refresh_watchers","cleanup","pres_expose","pres_phtable_list","subs_phtable_list","pua_publish","pua_subscribe","rls_update_subscriptions","tcp_trace"],"id":"1065"} > > Most of the documentation for the modules still shows the old non JSON > way of communicating.  Can someone point me in the right direction please. > > > Kind regards, > > Adrian Fretwell > > Sibthorpe > Nottinghamshire > UK. > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Mon Jul 6 12:08:44 2020 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 6 Jul 2020 15:08:44 +0300 Subject: [OpenSIPS-Users] May I ask for some help with MI interface please In-Reply-To: <83bb8cd1-4dcc-0058-d8cc-f89f4ea42a24@topgreen.co.uk> References: <83bb8cd1-4dcc-0058-d8cc-f89f4ea42a24@topgreen.co.uk> Message-ID: <2c2bd98f-f0d6-6288-49ec-ffc17045f597@opensips.org> On 7/6/20 2:52 PM, Adrian Fretwell wrote: > > For the benefit of anyone else struggling with this, I eventually > worked out that the example in the documentation should read: > > {"jsonrpc":"2.0","method":"get_statistics","id":"1065", > "params":[["dialog:", "tm:"]]} > > This sets the list of statistics as an array in the params array (note > the extra []). > > It's such a simple thing, but it has taken me 8 hours of trial and > error to work out what was wrong. > Hey, Adrian! Thank you for the report - this is now fixed [1] on 3.0+. [1]: https://github.com/OpenSIPS/opensips/commit/3b0d2d15 -- Liviu Chircu OpenSIPS Developer http://www.opensips-solutions.com From rob.dyck at telus.net Mon Jul 6 14:44:53 2020 From: rob.dyck at telus.net (Robert Dyck) Date: Mon, 06 Jul 2020 07:44:53 -0700 Subject: [OpenSIPS-Users] SDES and DTLS mutually exclusive In-Reply-To: <6361f39c-eb8f-932e-41fd-fcc802f7c7da@opensips.org> References: <6358933.2l3rmUXbR5@blacky.mylan> <6361f39c-eb8f-932e-41fd-fcc802f7c7da@opensips.org> Message-ID: <61935000.3F2A3RajZp@blacky.mylan> Perhaps you misinterpreted my wording. I actually tired SDES=off but crypto attributes were still inserted.. It is a bit strange that ICE=force should arbitrarily add the crypto. On Monday, July 6, 2020 12:25:44 A.M. PDT Răzvan Crainea wrote: > You should use the SDES-off flag to rtoengine. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 7/4/20 10:34 PM, Robert Dyck wrote: > > I have run into an issue with rtpengine and the ICE=force option. > > > > To quote the rtpengine README > > > > With `force`, ICE attributes are first stripped, then new attributes are > > > > generated and inserted, which leaves the media proxy as the only > > > > ICE candidate. > > > > When using the force option where I think it will be appropriate I found > > it also adds crypto attributes. I believe this invokes SDES security. If > > the setup attribute is also present ( DTLS security ) the call fails > > with bad description. SDES=off does not prevent this behaviour. The > > error message from the UA says there cannot be both. > > > > a=crypto:1 AES_CM_128_HMAC_SHA1_80 > > inline:/msDyiV8x6qpcH4m1iEmxo8aqAAhhkGctQbxvkNy > > > > a=crypto:2 AES_CM_128_HMAC_SHA1_32 > > inline:JgDv7fMfKd1GQcFq9Jn0tMf1C5DE0VaRDe6Js8D6 > > > > a=crypto:3 AES_192_CM_HMAC_SHA1_80 > > inline:CiCkAETMov/tbVsqykp7j3/PB7aUfQjv+nozBQuOUMBnJlrm8bU > > > > a=crypto:4 AES_192_CM_HMAC_SHA1_32 > > inline:6ktVsgwfiGg4US2BLWuV3XpCt0fvkiuFgcEr8n83KDln8w9ar+c > > > > a=crypto:5 AES_256_CM_HMAC_SHA1_80 > > inline:l1pr/67vqwthDdnRoSaTbGvRPBNP7uHIhjfeG8InuqWQZjLkumU5MVKz2mAujw > > > > a=crypto:6 AES_256_CM_HMAC_SHA1_32 > > inline:V+K2bK8Zahr9KX7zswVwM2cpZ+/g8hMD4a5PmJzncH8WgDnCH/xLH0CFRwYKgg > > > > a=crypto:7 F8_128_HMAC_SHA1_80 > > inline:Z00dhmeQwuttjeRawylGKannT7KbBZhDExDxETNo > > > > a=crypto:8 F8_128_HMAC_SHA1_32 > > inline:R5Vqt9WQ1wU76GcS7CvDosgbWHRYLV7CRnGre+uV > > > > a=crypto:9 NULL_HMAC_SHA1_80 > > inline:TP2aKDSKe8G9E7kd+w7XpOhcItzd0xmBN3g06WC1 > > > > a=crypto:10 NULL_HMAC_SHA1_32 > > inline:xKFUEuwLpexe84KKCulBSThMx75T74U7/K7qJbKi > > > > a=setup:actpass > > > > > > _______________________________________________ > > 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 osas at voipembedded.com Mon Jul 6 15:20:24 2020 From: osas at voipembedded.com (Ovidiu Sas) Date: Mon, 6 Jul 2020 11:20:24 -0400 Subject: [OpenSIPS-Users] SDES and DTLS mutually exclusive In-Reply-To: <61935000.3F2A3RajZp@blacky.mylan> References: <6358933.2l3rmUXbR5@blacky.mylan> <6361f39c-eb8f-932e-41fd-fcc802f7c7da@opensips.org> <61935000.3F2A3RajZp@blacky.mylan> Message-ID: According to the documentation, the prefix for sdes flags is ‘SDES-‘ (dash not equal). -ovidiu On Mon, Jul 6, 2020 at 10:45 Robert Dyck wrote: > Perhaps you misinterpreted my wording. I actually tired SDES=off but > crypto > attributes were still inserted.. > > It is a bit strange that ICE=force should arbitrarily add the crypto. > > On Monday, July 6, 2020 12:25:44 A.M. PDT Răzvan Crainea wrote: > > You should use the SDES-off flag to rtoengine. > > > > Best regards, > > > > Răzvan Crainea > > OpenSIPS Core Developer > > http://www.opensips-solutions.com > > > > On 7/4/20 10:34 PM, Robert Dyck wrote: > > > I have run into an issue with rtpengine and the ICE=force option. > > > > > > To quote the rtpengine README > > > > > > With `force`, ICE attributes are first stripped, then new attributes > are > > > > > > generated and inserted, which leaves the media proxy as the > only > > > > > > ICE candidate. > > > > > > When using the force option where I think it will be appropriate I > found > > > it also adds crypto attributes. I believe this invokes SDES security. > If > > > the setup attribute is also present ( DTLS security ) the call fails > > > with bad description. SDES=off does not prevent this behaviour. The > > > error message from the UA says there cannot be both. > > > > > > a=crypto:1 AES_CM_128_HMAC_SHA1_80 > > > inline:/msDyiV8x6qpcH4m1iEmxo8aqAAhhkGctQbxvkNy > > > > > > a=crypto:2 AES_CM_128_HMAC_SHA1_32 > > > inline:JgDv7fMfKd1GQcFq9Jn0tMf1C5DE0VaRDe6Js8D6 > > > > > > a=crypto:3 AES_192_CM_HMAC_SHA1_80 > > > inline:CiCkAETMov/tbVsqykp7j3/PB7aUfQjv+nozBQuOUMBnJlrm8bU > > > > > > a=crypto:4 AES_192_CM_HMAC_SHA1_32 > > > inline:6ktVsgwfiGg4US2BLWuV3XpCt0fvkiuFgcEr8n83KDln8w9ar+c > > > > > > a=crypto:5 AES_256_CM_HMAC_SHA1_80 > > > inline:l1pr/67vqwthDdnRoSaTbGvRPBNP7uHIhjfeG8InuqWQZjLkumU5MVKz2mAujw > > > > > > a=crypto:6 AES_256_CM_HMAC_SHA1_32 > > > inline:V+K2bK8Zahr9KX7zswVwM2cpZ+/g8hMD4a5PmJzncH8WgDnCH/xLH0CFRwYKgg > > > > > > a=crypto:7 F8_128_HMAC_SHA1_80 > > > inline:Z00dhmeQwuttjeRawylGKannT7KbBZhDExDxETNo > > > > > > a=crypto:8 F8_128_HMAC_SHA1_32 > > > inline:R5Vqt9WQ1wU76GcS7CvDosgbWHRYLV7CRnGre+uV > > > > > > a=crypto:9 NULL_HMAC_SHA1_80 > > > inline:TP2aKDSKe8G9E7kd+w7XpOhcItzd0xmBN3g06WC1 > > > > > > a=crypto:10 NULL_HMAC_SHA1_32 > > > inline:xKFUEuwLpexe84KKCulBSThMx75T74U7/K7qJbKi > > > > > > a=setup:actpass > > > > > > > > > _______________________________________________ > > > 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 > > > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- VoIP Embedded, Inc. http://www.voipembedded.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.dyck at telus.net Mon Jul 6 17:03:44 2020 From: rob.dyck at telus.net (Robert Dyck) Date: Mon, 06 Jul 2020 10:03:44 -0700 Subject: [OpenSIPS-Users] SDES and DTLS mutually exclusive In-Reply-To: References: <6358933.2l3rmUXbR5@blacky.mylan> <61935000.3F2A3RajZp@blacky.mylan> Message-ID: <4183670.07ICAnoMbH@blacky.mylan> Doh One tiny line. Indeed it eliminates the crypto. It would seem that invalid flags are simply ignored. On Monday, July 6, 2020 8:20:24 A.M. PDT Ovidiu Sas wrote: According to the documentation, the prefix for sdes flags is ‘SDES-‘ (dash not equal). -ovidiu On Mon, Jul 6, 2020 at 10:45 Robert Dyck wrote: Perhaps you misinterpreted my wording. I actually tired SDES=off but crypto attributes were still inserted.. It is a bit strange that ICE=force should arbitrarily add the crypto. On Monday, July 6, 2020 12:25:44 A.M. PDT Răzvan Crainea wrote:> You should use the SDES- off flag to rtoengine.> > Best regards,> > Răzvan Crainea> OpenSIPS Core Developer> http:// www.opensips-solutions.com[2] Users at lists.opensips.org[3] http://lists.opensips.org/cgi-bin/mailman/listinfo/users[4] Users at lists.opensips.org[3] http://lists.opensips.org/cgi-bin/mailman/listinfo/users[4] Users at lists.opensips.org[3] http://lists.opensips.org/cgi-bin/mailman/listinfo/users[4] -- VoIP Embedded, Inc. http://www.voipembedded.com[5] -------- [1] mailto:rob.dyck at telus.net [2] http://www.opensips-solutions.com [3] mailto:Users at lists.opensips.org [4] http://lists.opensips.org/cgi-bin/mailman/listinfo/users [5] http://www.voipembedded.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.fretwell at topgreen.co.uk Mon Jul 6 19:47:25 2020 From: adrian.fretwell at topgreen.co.uk (Adrian Fretwell) Date: Mon, 6 Jul 2020 20:47:25 +0100 Subject: [OpenSIPS-Users] How should we represent empty parameters in MI Datagram JSON Message-ID: <6072b3ac-038b-43bb-95bb-d9a7745b4a67@topgreen.co.uk> Hello, What is the correct way to specify empty parameters in an MI call using JSON? For example this call to pua_publish has two unused parameters; ETag and extra_headers, in the old way they were represented by a dot, but if I try that now I get an invalid etag message: Pua_publish:             - body type if body of a type different from default event content-type or .                      - ETag that publish should match or . if no ETag      - extra headers to be added to the request or .        - may not be present in case of update for expire Example: :pua_publish:fifo_reply sip:system at 192.168.2.132 3600 presence application/pidf+xml . . From greg at switchtel.co.za Mon Jul 6 22:45:56 2020 From: greg at switchtel.co.za (Gregory Massel) Date: Tue, 7 Jul 2020 00:45:56 +0200 Subject: [OpenSIPS-Users] TLS handshake failure Message-ID: <5b5a70bc-6660-de3d-cae7-5b30023352a1@switchtel.co.za> Hello As of five days ago, my OpenSIPS 'SBC' for Microsoft Teams has started failing outbound Teams calls (with no changes to the config and after everything was working for many weeks prior). In the direction where OpenSIPS sends the INVITE to Microsoft, everything still works normally. It's only problematic in the direction where Microsoft sends the INVITE to OpenSIPS. In my logs, I can see it accepts the first TLS connection, however after the INVITE is received, Microsoft tries to establish another TLS connection from the same IP and that fails during the TLS handshake. Jul 7 00:10:02 msteams /usr/sbin/opensips[26344]: INFO:core:probe_max_sock_buff: using snd buffer of 416 kb Jul 7 00:10:02 msteams /usr/sbin/opensips[26344]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 178 Jul 7 00:10:02 msteams /usr/sbin/opensips[26326]: NOTICE:tls_mgm:verify_callback: depth = 2, verify success Jul 7 00:10:02 msteams /usr/sbin/opensips[26326]: NOTICE:tls_mgm:verify_callback: depth = 1, verify success Jul 7 00:10:02 msteams /usr/sbin/opensips[26326]: NOTICE:tls_mgm:verify_callback: depth = 0, verify success Jul 7 00:10:02 msteams /usr/sbin/opensips[26326]: INFO:proto_tls:tls_accept: New TLS connection from 52.114.76.76:2560 accepted Jul 7 00:10:02 msteams /usr/sbin/opensips[26326]: INFO:proto_tls:tls_dump_cert_info: tls_accept: client TLS certificate subject: /CN=sip.pstnhub.microsoft.com, issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft IT/CN=Microsoft IT TLS CA 4 Jul 7 00:10:02 msteams /usr/sbin/opensips[26326]: INFO:proto_tls:tls_dump_cert_info: tls_accept: local TLS server certificate subject: /CN=msteams.switchtel.co.za, issuer: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 Jul 7 00:10:02 msteams /usr/sbin/opensips[26326]: Call from sip:+27105000470 at sip.pstnhub.microsoft.com:5061;user=phone to sip:+27875500000 at samsip1.switchtel.co.za, Socket tls:52.114.76.76:2560 to tls:196.216.192.19:5061, Contact-URI=sip:api-du-b-usea.pstnhub.microsoft.com:443;x-i=346158ef-e50e-4a58-9f08-af7e7813acef;x-c=720af6d686d05fba9a27b237dd0a5ecb/d/8/222b0a8fe57c4584ab717a05b7f0b93f, Teams_Domain=msteams.switchtel.co.za The logs above show the connection from 52.114.76.76:2560 was successful, client and server certificates verified, and the INVITE packet was received from Microsoft. The logs below show the connection from 52.114.76.76:2561 and 52.114.76.76:2562, just two seconds later, with TLS handshake failure. The 2 second gap is the time it takes to send the "200 OK"; that is transmitting via the initial connection, however, it seems that Microsoft thinks the first connection is dead and attempts to reconnect. Jul 7 00:10:04 msteams /usr/sbin/opensips[26344]: INFO:core:probe_max_sock_buff: using snd buffer of 416 kb Jul 7 00:10:04 msteams /usr/sbin/opensips[26344]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 179 Jul 7 00:10:04 msteams /usr/sbin/opensips[26328]: ERROR:proto_tls:tls_accept: New TLS connection from 52.114.76.76:2561 failed to accept Jul 7 00:10:04 msteams /usr/sbin/opensips[26328]: ERROR:proto_tls:tls_read_req: failed to do pre-tls reading Jul 7 00:10:04 msteams /usr/sbin/opensips[26344]: INFO:core:probe_max_sock_buff: using snd buffer of 416 kb Jul 7 00:10:04 msteams /usr/sbin/opensips[26344]: INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 179 Jul 7 00:10:04 msteams /usr/sbin/opensips[26328]: ERROR:proto_tls:tls_accept: New TLS connection from 52.114.76.76:2562 failed to accept Jul 7 00:10:04 msteams /usr/sbin/opensips[26328]: ERROR:proto_tls:tls_read_req: failed to do pre-tls reading If I take a TShark sample, the first connection gets "Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message" while the second and third connections seem to lack this part of the TLS handshake: 22 9.027531791 52.114.76.76 â 196.216.192.19 TLSv1.2 2370 Client Hello 23 9.027555818 196.216.192.19 â 52.114.76.76 TCP 54 5061 â 7106 [ACK] Seq=1 Ack=2317 Win=63232 Len=0 24 9.030106811 196.216.192.19 â 52.114.76.76 TLSv1.2 2934 Server Hello, Certificate 25 9.030278247 196.216.192.19 â 52.114.76.76 TLSv1.2 230 Server Key Exchange, Certificate Request, Server Hello Done 26 9.223719073 52.114.76.76 â 196.216.192.19 TCP 60 7106 â 5061 [ACK] Seq=2317 Ack=3057 Win=525568 Len=0 27 9.226831508 52.114.76.76 â 196.216.192.19 TLSv1.2 3823 Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message 28 9.226854910 196.216.192.19 â 52.114.76.76 TCP 54 5061 â 7106 [ACK] Seq=3057 Ack=6086 Win=62080 Len=0 29 9.228225293 196.216.192.19 â 52.114.76.76 TLSv1.2 2248 New Session Ticket, Change Cipher Spec, Encrypted Handshake Message 30 9.421672079 52.114.76.76 â 196.216.192.19 TCP 60 7106 â 5061 [ACK] Seq=6086 Ack=5251 Win=525568 Len=0 31 9.423493322 52.114.76.76 â 196.216.192.19 TLSv1.2 2092 Application Data 32 9.423517425 196.216.192.19 â 52.114.76.76 TCP 54 5061 â 7106 [ACK] Seq=5251 Ack=8124 Win=63232 Len=0 33 9.424490692 196.216.192.19 â 52.114.76.76 TLSv1.2 478 Application Data 34 9.583038834 196.216.192.19 â 52.114.76.76 TLSv1.2 931 Application Data 35 9.661329748 52.114.76.76 â 196.216.192.19 TCP 60 7106 â 5061 [ACK] Seq=8124 Ack=5675 Win=525056 Len=0 36 9.817636273 52.114.76.76 â 196.216.192.19 TCP 60 7106 â 5061 [ACK] Seq=8124 Ack=6552 Win=524288 Len=0 37 9.994327854 52.114.132.46 â 196.216.192.19 TLSv1.2 99 Application Data 38 9.994448210 196.216.192.19 â 52.114.132.46 TLSv1.2 85 Application Data 39 9.994468209 196.216.192.19 â 52.114.132.46 TLSv1.2 116 Application Data, Application Data 40 9.994631776 196.216.192.19 â 52.114.132.46 TLSv1.2 85 Application Data 41 10.251655099 52.114.132.46 â 196.216.192.19 TCP 60 8768 â 5061 [ACK] Seq=46 Ack=94 Win=2051 Len=0 42 10.294541880 52.114.132.46 â 196.216.192.19 TCP 60 8768 â 5061 [ACK] Seq=46 Ack=125 Win=2051 Len=0 43 10.585625776 196.216.192.19 â 52.114.76.76 TLSv1.2 1377 Application Data 44 10.779516806 52.114.76.76 â 196.216.192.19 TCP 66 7107 â 5061 [SYN] Seq=0 Win=64240 Len=0 MSS=1440 WS=256 SACK_PERM=1 45 10.779555363 196.216.192.19 â 52.114.76.76 TCP 66 5061 â 7107 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 SACK_PERM=1 WS=128 46 10.833193731 52.114.76.76 â 196.216.192.19 TCP 60 7106 â 5061 [ACK] Seq=8124 Ack=7875 Win=525568 Len=0 47 10.971578923 52.114.76.76 â 196.216.192.19 TCP 60 7107 â 5061 [ACK] Seq=1 Ack=1 Win=525568 Len=0 48 10.971928866 52.114.76.76 â 196.216.192.19 TLSv1.2 210 Client Hello 49 10.971952878 196.216.192.19 â 52.114.76.76 TCP 54 5061 â 7107 [ACK] Seq=1 Ack=157 Win=64128 Len=0 50 10.974370873 196.216.192.19 â 52.114.76.76 TLSv1.2 2934 Server Hello, Certificate 51 10.974542533 196.216.192.19 â 52.114.76.76 TLSv1.2 226 Server Key Exchange, Certificate Request, Server Hello Done 52 11.086085952 196.216.192.19 â 52.114.76.76 TLSv1.2 1377 Application Data 53 11.166263352 52.114.76.76 â 196.216.192.19 TCP 60 7107 â 5061 [ACK] Seq=157 Ack=3053 Win=525568 Len=0 54 11.166844774 52.114.76.76 â 196.216.192.19 TCP 60 7107 â 5061 [FIN, ACK] Seq=157 Ack=3053 Win=525568 Len=0 55 11.167276748 196.216.192.19 â 52.114.76.76 TCP 54 5061 â 7107 [FIN, ACK] Seq=3053 Ack=158 Win=64128 Len=0 56 11.170033533 52.114.76.76 â 196.216.192.19 TCP 66 7108 â 5061 [SYN] Seq=0 Win=64240 Len=0 MSS=1440 WS=256 SACK_PERM=1 57 11.170072225 196.216.192.19 â 52.114.76.76 TCP 66 5061 â 7108 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460 SACK_PERM=1 WS=128 58 11.333176171 52.114.76.76 â 196.216.192.19 TCP 60 7106 â 5061 [ACK] Seq=8124 Ack=9198 Win=524032 Len=0 59 11.359073241 52.114.76.76 â 196.216.192.19 TCP 60 7107 â 5061 [ACK] Seq=158 Ack=3054 Win=525568 Len=0 60 11.363647189 52.114.76.76 â 196.216.192.19 TCP 60 7108 â 5061 [ACK] Seq=1 Ack=1 Win=525568 Len=0 My config includes: tcp_connection_lifetime=600 tcp_connect_timeout=3000 modparam("proto_tls", "tls_max_msg_chunks", 8) modparam("tls_mgm", "tls_send_timeout", 2000) modparam("tls_mgm", "tls_handshake_timeout", 3000) These are fairly generous time-outs aimed to compensate for slow response from Microsoft and the fact that their SIP proxy is on a different continent to mine, with approximately 180ms round-trip time in latency (typical submarine cable latency from South Africa to Europe). It doesn't appear to be certificate-related, as the first connection verifies the certificates in both directions and connections are to/from the same IP addresses. The second and third connections appear to be attempts to re-establish a connection after something goes wrong with the initial connection. Microsoft is logging "Server Time-out - TLS misconfiguration on the SBC". I'm at a bit of a loss as to why the TLS connection - in one direction only - is suddenly becoming problematic and why OpenSIPS fails to accept re-connections from the same host that, two seconds prior, it was happy to accept a connection from. Any help would be most appreciated! Thanks Kind Regards Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexei.vasilyev at gmail.com Tue Jul 7 06:15:12 2020 From: alexei.vasilyev at gmail.com (Alexey Vasilyev) Date: Mon, 6 Jul 2020 23:15:12 -0700 (MST) Subject: [OpenSIPS-Users] TLS handshake failure In-Reply-To: <5b5a70bc-6660-de3d-cae7-5b30023352a1@switchtel.co.za> References: <5b5a70bc-6660-de3d-cae7-5b30023352a1@switchtel.co.za> Message-ID: <1594102512971-0.post@n2.nabble.com> Hi Gregory, Starting from 01.07.2020 Microsoft requires Route headers with SBC_FQDN in SIP replies too. Instead of simple record_route() for SIP request from MS servers OpenSIPS should add FQDN. I've updated the article. Check it. https://blog.opensips.org/2019/09/16/opensips-as-ms-teams-sbc/ ----- --- Alexey Vasilyev -- Sent from: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html From greg at switchtel.co.za Tue Jul 7 08:33:13 2020 From: greg at switchtel.co.za (Gregory Massel) Date: Tue, 7 Jul 2020 10:33:13 +0200 Subject: [OpenSIPS-Users] TLS handshake failure In-Reply-To: <1594102512971-0.post@n2.nabble.com> References: <5b5a70bc-6660-de3d-cae7-5b30023352a1@switchtel.co.za> <1594102512971-0.post@n2.nabble.com> Message-ID: <256f21b9-3d3c-0b25-4ebc-d69a63fa48f9@switchtel.co.za> Thank you Alexey. Your suggestions solved the problem! On 2020-07-07 8:15 am, Alexey Vasilyev wrote: > Hi Gregory, > > Starting from 01.07.2020 Microsoft requires Route headers with SBC_FQDN in > SIP replies too. Instead of simple record_route() for SIP request from MS > servers OpenSIPS should add FQDN. > > I've updated the article. Check it. > https://blog.opensips.org/2019/09/16/opensips-as-ms-teams-sbc/ > > > > ----- > --- > Alexey Vasilyev > -- > Sent from: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From Johan at democon.be Tue Jul 7 08:54:51 2020 From: Johan at democon.be (Johan De Clercq) Date: Tue, 7 Jul 2020 10:54:51 +0200 Subject: [OpenSIPS-Users] TLS handshake failure In-Reply-To: <256f21b9-3d3c-0b25-4ebc-d69a63fa48f9@switchtel.co.za> References: <5b5a70bc-6660-de3d-cae7-5b30023352a1@switchtel.co.za> <1594102512971-0.post@n2.nabble.com> <256f21b9-3d3c-0b25-4ebc-d69a63fa48f9@switchtel.co.za> Message-ID: Which means that in b2b implemenation, you need to change contact header to include fqdn. wkr, Op di 7 jul. 2020 om 10:36 schreef Gregory Massel : > Thank you Alexey. > > Your suggestions solved the problem! > > On 2020-07-07 8:15 am, Alexey Vasilyev wrote: > > Hi Gregory, > > > > Starting from 01.07.2020 Microsoft requires Route headers with SBC_FQDN > in > > SIP replies too. Instead of simple record_route() for SIP request from MS > > servers OpenSIPS should add FQDN. > > > > I've updated the article. Check it. > > https://blog.opensips.org/2019/09/16/opensips-as-ms-teams-sbc/ > > > > > > > > ----- > > --- > > Alexey Vasilyev > > -- > > Sent from: > http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html > > > > _______________________________________________ > > 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: From voip.security at protonmail.com Wed Jul 8 00:18:09 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Wed, 08 Jul 2020 00:18:09 +0000 Subject: [OpenSIPS-Users] OpenSIPS - Log Facility partial working Message-ID: Hey guys, We configured the opensips server to send the logs to log facility 1 (opensips.log), it's working fine but at the same time it's also writing logs to log facility0 (syslog). opensips.cfg -- log_level=3 log_stderror=no log_facility=LOG_LOCAL1 log_name="osips-1" rsyslog.conf - LOCAL1.* /var/log/opensips.log opensips -v version: opensips 2.4.7 (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: 0f7cd0a7d main.c compiled on 07:56:19 Feb 25 2020 with gcc 6.3.0 Any help or suggestions will be highly appreciated. Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From atuxnull at gmail.com Wed Jul 8 07:39:55 2020 From: atuxnull at gmail.com (John Tuxies) Date: Wed, 8 Jul 2020 10:39:55 +0300 Subject: [OpenSIPS-Users] Opensips & media server Message-ID: For some time now i am using an Asterisk server to register all the internal members of the office for services. I would like to experiment with Opensips and add in front an Opensips server with control panel. So in total it will be an Opensips server and 2-3 Asterisk servers to distribute the load of media services. The overall idea is Opensips to get all the registrations on port 5060, allow users to talk to each other and once I followed the guide of http://www.powerpbx.org/content/opensips-v30-debian-v10-mariadb-apache-v1 and Opensips is up and running and managed to created a few users (extensions 3000-3500) to register on it. They have payload and call seems to be fine and the system load is really low! That's a good thing. I would like to connect the Opensips with Asterisk and i would like some help please. i bought the book Building telephony systems with Opensips 2nd edition and i have seen a few things about the configuration of the opensips but i did not manage to add in the game the Asterisk(s) servers. Struggling with it for some time, without getting any further and i would like to ask for some help please. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vma at sip.solutions Wed Jul 8 08:43:52 2020 From: vma at sip.solutions (Valli A. Vallimamod - SIP Solutions) Date: Wed, 8 Jul 2020 10:43:52 +0200 Subject: [OpenSIPS-Users] OpenSIPS - Log Facility partial working In-Reply-To: References: Message-ID: Hi, You need to put the following in your rsyslog.conf: LOCAL1.* /var/log/opensips.log & stop Hope this helps. Best Regards, -- Valli A. Vallimamod SIP Solutions vma at sip.solutions linkedin.com/in/vallimamod . > On 8 Jul 2020, at 02:18, Sharad Kumar via Users wrote: > > Hey guys, > > We configured the opensips server to send the logs to log facility 1 (opensips.log), it's working fine but at the same time it's also writing logs to log facility0 (syslog). > > opensips.cfg -- > log_level=3 > log_stderror=no > log_facility=LOG_LOCAL1 > log_name="osips-1" > > > rsyslog.conf - > LOCAL1.* /var/log/opensips.log > > opensips -v > > > version: opensips 2.4.7 (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: 0f7cd0a7d > main.c compiled on 07:56:19 Feb 25 2020 with gcc 6.3.0 > > Any help or suggestions will be highly appreciated. > > Thank you > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users Best Regards, -- Valli A. Vallimamod SIP Solutions vma at sip.solutions linkedin.com/in/vallimamod . From volga629 at networklab.ca Wed Jul 8 11:01:42 2020 From: volga629 at networklab.ca (Slava Bendersky) Date: Wed, 8 Jul 2020 07:01:42 -0400 (EDT) Subject: [OpenSIPS-Users] nat helper ping Message-ID: <682907117.15587.1594206102027.JavaMail.zimbra@skillsearch.ca> Hello Everyone, Based on this conversation [ https://groups.google.com/forum/#!topic/jssip/1D3n2_MJrf8 | https://groups.google.com/forum/#!topic/jssip/1D3n2_MJrf8 ] Opensips is not set user name portion in request uri for NAT helper OPTIONS packet. I found RFC for proxy layer that user name portion is not required, but I can't find any information about UA. Is possible clarify what behavior should be for UA. volga629 -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Wed Jul 8 11:02:15 2020 From: spanda at 3clogic.com (Sasmita Panda) Date: Wed, 8 Jul 2020 16:32:15 +0530 Subject: [OpenSIPS-Users] Regarding opensips 3.0.0 logging . Message-ID: Hi , I am using below version of opensips . version: opensips 3.0.0-beta (x86_64/linux) flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, CC_O0, 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. svn revision: 3651:3664M main.c compiled on 12:08:17 Jul 15 2019 with gcc 5.4.0 *I am running my config with log_level=3 , but in a single day it creates a 16GB log file . * WARNING:core:timer_ticker: timer task already scheduled 464275150 ms ago (now 464305720 ms), delaying execution WARNING:core:timer_ticker: timer task already scheduled 464275150 ms ago (now 464305720 ms), delaying execution WARNING:core:timer_ticker: timer task already scheduled 464275150 ms ago (now 464305720 ms), delaying execution WARNING:core:timer_ticker: timer task already scheduled 464275150 ms ago (now 464305720 ms), skipping execution *Continuously this message is getting printed . Is this a crash or what . Please help . * *Thanks & Regards* *Sasmita Panda* *Senior Network Testing and Software Engineer* *3CLogic , ph:07827611765* -------------- next part -------------- An HTML attachment was scrubbed... URL: From chandan.pr at webshar.org Wed Jul 8 13:58:36 2020 From: chandan.pr at webshar.org (Chandan PR) Date: Wed, 8 Jul 2020 19:28:36 +0530 Subject: [OpenSIPS-Users] Load Balancer Hooks Message-ID: Hi, Is it possible to add hooks to notify an endpoint - when a particular destination is disabled (via lb_disable()) - when a particular destination is enabled after a successful probing This is needed for us to slow down the requests to OpenSips when few destinations are down. Without this feedback loop, we won't be knowing if we need to limit the number of calls we need to send. We are currently on Opensips 1.9. -- Regards, Chandan Ravishankar -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Wed Jul 8 14:03:59 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Wed, 8 Jul 2020 14:03:59 +0000 Subject: [OpenSIPS-Users] Load Balancer Hooks In-Reply-To: References: Message-ID: I don’t know if there is anything in 1.9, which is quite old, but in 2.0+ there is an event that you can subscribe to. https://opensips.org/docs/modules/2.4.x/load_balancer.html#event_E_LOAD_BALANCER_STATUS Ben Newlin From: Users on behalf of Chandan PR Reply-To: OpenSIPS users mailling list Date: Wednesday, July 8, 2020 at 10:00 AM To: OpenSIPS users mailling list Cc: Naveen Kumar Subject: [OpenSIPS-Users] Load Balancer Hooks Hi, Is it possible to add hooks to notify an endpoint * when a particular destination is disabled (via lb_disable()) * when a particular destination is enabled after a successful probing This is needed for us to slow down the requests to OpenSips when few destinations are down. Without this feedback loop, we won't be knowing if we need to limit the number of calls we need to send. We are currently on Opensips 1.9. -- Regards, Chandan Ravishankar -------------- next part -------------- An HTML attachment was scrubbed... URL: From chandan.pr at webshar.org Wed Jul 8 14:09:41 2020 From: chandan.pr at webshar.org (Chandan PR) Date: Wed, 8 Jul 2020 19:39:41 +0530 Subject: [OpenSIPS-Users] Load Balancer Hooks In-Reply-To: References: Message-ID: Thanks for the info, Ben. Let me have a look. On Wed, Jul 8, 2020 at 7:34 PM Ben Newlin wrote: > I don’t know if there is anything in 1.9, which is quite old, but in 2.0+ > there is an event that you can subscribe to. > > > > > https://opensips.org/docs/modules/2.4.x/load_balancer.html#event_E_LOAD_BALANCER_STATUS > > > > Ben Newlin > > > > *From: *Users on behalf of Chandan PR < > chandan.pr at webshar.org> > *Reply-To: *OpenSIPS users mailling list > *Date: *Wednesday, July 8, 2020 at 10:00 AM > *To: *OpenSIPS users mailling list > *Cc: *Naveen Kumar > *Subject: *[OpenSIPS-Users] Load Balancer Hooks > > > > Hi, > > > > Is it possible to add hooks to notify an endpoint > > - when a particular destination is disabled (via lb_disable()) > - when a particular destination is enabled after a successful probing > > This is needed for us to slow down the requests to OpenSips when few > destinations are down. Without this feedback loop, we won't be knowing if > we need to limit the number of calls we need to send. > > > > We are currently on Opensips 1.9. > > -- > > > > Regards, > > Chandan Ravishankar > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Regards, Chandan Ravishankar -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladp at opensips.org Wed Jul 8 14:28:14 2020 From: vladp at opensips.org (Vlad Patrascu) Date: Wed, 8 Jul 2020 17:28:14 +0300 Subject: [OpenSIPS-Users] How should we represent empty parameters in MI Datagram JSON In-Reply-To: <6072b3ac-038b-43bb-95bb-d9a7745b4a67@topgreen.co.uk> References: <6072b3ac-038b-43bb-95bb-d9a7745b4a67@topgreen.co.uk> Message-ID: Hi Adrian, In the cases (like 'pua_publish') where there are multiple optional parameters that cannot be simply identified by position in the array, the 'params' member in the JSON-RPC request should be an Object with named parameters. As such, you should have: "params": {     "presentity_uri": "sip:system at 192.168.2.132",     "expires": 3600,     [...] } Regards, On 06.07.2020 22:47, Adrian Fretwell wrote: > > Hello, > > What is the correct way to specify empty parameters in an MI call > using JSON? > > For example this call to pua_publish has two unused parameters; ETag > and extra_headers, in the old way they were represented by a dot, but > if I try that now I get an invalid etag message: > > Pua_publish: > > >   >   >         - body type if body of a type different from > default event content-type or . >                      - ETag that publish should match or . if no > ETag >      - extra headers to be added to the request or . >        - may not be present in case of update for expire > > Example: > > :pua_publish:fifo_reply > sip:system at 192.168.2.132 > 3600 > presence > application/pidf+xml > . > . > xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model'... etc. > > Would someone point me in the right direction please. > > > Kind regards, > > Adrian Fretwell > Sibthorpe > Nottinghamshire > UK. > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Vlad Patrascu OpenSIPS Developer http://www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.fretwell at topgreen.co.uk Wed Jul 8 14:42:04 2020 From: adrian.fretwell at topgreen.co.uk (Adrian Fretwell) Date: Wed, 8 Jul 2020 15:42:04 +0100 Subject: [OpenSIPS-Users] How should we represent empty parameters in MI Datagram JSON In-Reply-To: References: <6072b3ac-038b-43bb-95bb-d9a7745b4a67@topgreen.co.uk> Message-ID: <962f7f49-33ce-7050-b664-30674aa493d9@topgreen.co.uk> Vlad, Thank you , that makes sense, and seems so obvious now you have said it!  Switch from positional to named parameters.  Works perfectly. Kind regards, Adrian Fretwell Sibthorpe Nottinghamshire UK. On 08/07/2020 15:28, Vlad Patrascu wrote: > Hi Adrian, > > In the cases (like 'pua_publish') where there are multiple optional > parameters that cannot be simply identified by position in the array, > the 'params' member in the JSON-RPC request should be an Object with > named parameters. > > As such, you should have: > > "params": { > >     "presentity_uri": "sip:system at 192.168.2.132", > >     "expires": 3600, > >     [...] > > } > > Regards, > > On 06.07.2020 22:47, Adrian Fretwell wrote: >> >> Hello, >> >> What is the correct way to specify empty parameters in an MI call >> using JSON? >> >> For example this call to pua_publish has two unused parameters; ETag >> and extra_headers, in the old way they were represented by a dot, but >> if I try that now I get an invalid etag message: >> >> Pua_publish: >> >> >>   >>   >>         - body type if body of a type different from >> default event content-type or . >>                      - ETag that publish should match or . if >> no ETag >>      - extra headers to be added to the request or . >>        - may not be present in case of update for expire >> >> Example: >> >> :pua_publish:fifo_reply >> sip:system at 192.168.2.132 >> 3600 >> presence >> application/pidf+xml >> . >> . >> > xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model'... etc. >> >> Would someone point me in the right direction please. >> >> >> Kind regards, >> >> Adrian Fretwell >> Sibthorpe >> Nottinghamshire >> UK. >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- > Vlad Patrascu > OpenSIPS Developer > http://www.opensips-solutions.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Jul 8 15:39:19 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 8 Jul 2020 18:39:19 +0300 Subject: [OpenSIPS-Users] Modules not inheriting db_default_url In-Reply-To: References: <0e2386b3-5a29-b2c1-40c9-b5ada9c9b1e5@opensips.org> Message-ID: <57936223-f32b-b8ea-a466-4ef213794a2c@opensips.org> On 08.04.2020 14:15, Mark Farmer wrote: > Hi Liviu > > That sounds good to me. Do you need me to do anything in order to get > this implemented? > > Mark. > Hey, Mark! The remaining 'db_default_url' inheritance issues are now fixed on latest OpenSIPS '3.1' and 'master' branches, per [1]. If you could give it a test and let me know if you spot any issues around this topic, that would be awesome! Thank you, [1]: https://github.com/OpenSIPS/opensips/issues/2117#issuecomment-655592712 -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com From xaled at web.de Thu Jul 9 00:26:48 2020 From: xaled at web.de (xaled at web.de) Date: Thu, 9 Jul 2020 02:26:48 +0200 Subject: [OpenSIPS-Users] multi domain TLS in opensips 3.1 Message-ID: <08e701d65587$a2b560b0$e8202210$@web.de> Thank you Răzvan, that solved it! In OpenSIPS 3.1, the tls_handshake_timeout is no longer specified in the tls_module, but in each module that uses tls[1]. Therefore, most likely, you are looking at this parameter[2]. [1] https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0#toc15 [2] https://opensips.org/docs/modules/3.1.x/proto_tls.html#param_tls_handshake_timeout Best regards, From xaled at web.de Thu Jul 9 00:34:38 2020 From: xaled at web.de (xaled at web.de) Date: Thu, 9 Jul 2020 02:34:38 +0200 Subject: [OpenSIPS-Users] Multidomain TLS with opensips 3.1 part 2 Message-ID: <08f101d65588$ba9357e0$2fba07a0$@web.de> Hi, I got server and client tls config working in opensips.cfg and now trying to get it running with mysql DB. I tried to use the latest opensips-cp (I know that 3.1 is not officially supported) to import client certificate data that I created using opensips-cli and getting a segfault. Maybe I should try importing client cert from cli? What would be the correct way to import certificate in to mysql from linux shell? 9 02:29:30 test /usr/sbin/opensips[8551]: INFO:tls_mgm:init_tls_dom: Processing TLS domain 'test-cli' Jul 9 02:29:30 test /usr/sbin/opensips[8551]: DBG:tls_mgm:init_tls_dom: no DH params file for tls domain 'test-cli' defined, using default '(null)' Jul 9 02:29:30 test /usr/sbin/opensips[8551]: NOTICE:tls_mgm:init_tls_dom: No EC curve defined Jul 9 02:29:30 test /usr/sbin/opensips[8551]: DBG:tls_mgm:init_tls_dom: cipher list null ... setting default Jul 9 02:29:30 test /usr/sbin/opensips[8551]: INFO:tls_mgm:get_ssl_ctx_verify_mode: server verification activated. Jul 9 02:29:30 test /usr/sbin/opensips[8551]: NOTICE:tls_mgm:init_tls_dom: no CA dir for tls 'test-cli' defined, using default '/etc/pki/CA/' Jul 9 02:29:30 test /usr/sbin/opensips[8551]: NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none Jul 9 02:29:30 test /usr/sbin/opensips[8551]: DBG:core:count_module_procs: modules require 2 extra processes Jul 9 02:29:30 test /usr/sbin/opensips[8551]: CRITICAL:core:sig_usr: segfault in attendant (starter) process! Thanks, Xaled -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Jul 9 09:35:16 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 9 Jul 2020 12:35:16 +0300 Subject: [OpenSIPS-Users] [OpenSIPS 3.1] Stable Release Date Message-ID: <2171a0f0-6513-2647-1c70-894630958e5c@opensips.org> Hello everyone, On 27th of May we had the beta release for OpenSIPS 3.1 . There was a lot of extra testing, many reports, a lot of feedback. All these translated in many fixes that made 3.1 more and more stable by the day. So, we are almost there :) - heads up, the *OpenSIPS 3.1 LTS stable release is **scheduled for 22th of July* ! You still have time to fill reports (if the case), to bring your personal contribution to the value of the 3.1 release. Otherwise, sit tight , the 3.1 stable is coming ! Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From xaled at web.de Thu Jul 9 09:48:12 2020 From: xaled at web.de (xaled at web.de) Date: Thu, 9 Jul 2020 11:48:12 +0200 Subject: [OpenSIPS-Users] [OpenSIPS 3.1] Stable Release Date Message-ID: <092301d655d6$1007fe90$3017fbb0$@web.de> Hi Bogdan, Great news! Will 3.1 Release also include updated control panel or will it come later? Thanks, Xaled Hello everyone, On 27th of May we had the beta release for OpenSIPS 3.1 . There was a lot of extra testing, many reports, a lot of feedback. All these translated in many fixes that made 3.1 more and more stable by the day. So, we are almost there :) - heads up, the *OpenSIPS 3.1 LTS stable release is **scheduled for 22th of July* ! You still have time to fill reports (if the case), to bring your personal contribution to the value of the 3.1 release. Otherwise, sit tight , the 3.1 stable is coming ! Best regards, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com From fed at ddpp.net Thu Jul 9 16:38:44 2020 From: fed at ddpp.net (Kiselev Fedor) Date: Thu, 9 Jul 2020 19:38:44 +0300 Subject: [OpenSIPS-Users] create_dialog with P or p flag and TCP reconnection Message-ID: Hi All, Could you advice me how to use create_dailog with P or p flags if TCP session is reconnected ? Opensips is pinging callee/caller and doesn't know if new REGISTER via a TCP connection has arrived and already saved in location table. How to force dailog to get to know that new TCP connection is available for pinging ? Thank you! From adjolin at gmail.com Thu Jul 9 18:57:13 2020 From: adjolin at gmail.com (Vic Jolin) Date: Fri, 10 Jul 2020 02:57:13 +0800 Subject: [OpenSIPS-Users] changing callerids Message-ID: Hi, Are there other ways of "changing" callerids for a certain call aside from uac_replace_from? And what is the correct way of doing this? I have uac_replace_from("$avp(650)", ""); I find it giving errors when I try to update the uri with sip:$avp(650)@ipadddress:poprt -------------- next part -------------- An HTML attachment was scrubbed... URL: From voip.security at protonmail.com Fri Jul 10 00:49:12 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Fri, 10 Jul 2020 00:49:12 +0000 Subject: [OpenSIPS-Users] OpenSIPS - Log Facility partial working In-Reply-To: References: Message-ID: Now it's working as expected. Thanks for helping. From voip.security at protonmail.com Fri Jul 10 00:56:06 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Fri, 10 Jul 2020 00:56:06 +0000 Subject: [OpenSIPS-Users] Make opensips register to VoIP Provider as a trunk with auth Message-ID: Hey guys, I was just curious that can we make OpenSIPS to register as a SIP endpoint to VoIP provider like Twillio. We already using IP based auth in OpenSIPS to accept calls but one of our VOIP Provider wants our OpenSIPS SBC to register with them as a SIP trunk to get calls. Does anyone got make OpenSIPS register to provider before using AUTH or Registrar module ? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From osas at voipembedded.com Fri Jul 10 04:19:07 2020 From: osas at voipembedded.com (Ovidiu Sas) Date: Fri, 10 Jul 2020 00:19:07 -0400 Subject: [OpenSIPS-Users] Make opensips register to VoIP Provider as a trunk with auth In-Reply-To: References: Message-ID: Take a look at the uac_registrant module. Regards, Ovidiu Sas On Thu, Jul 9, 2020 at 20:57 Sharad Kumar via Users < users at lists.opensips.org> wrote: > Hey guys, > > I was just curious that can we make OpenSIPS to register as a SIP endpoint > to VoIP provider like Twillio. We already using IP based auth in OpenSIPS > to accept calls but one of our VOIP Provider wants our OpenSIPS SBC to > register with them as a SIP trunk to get calls. > Does anyone got make OpenSIPS register to provider before using AUTH or > Registrar module ? > > Thank you > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- VoIP Embedded, Inc. http://www.voipembedded.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From diptesh.patel at ecosmob.com Fri Jul 10 05:12:13 2020 From: diptesh.patel at ecosmob.com (Diptesh Patel) Date: Fri, 10 Jul 2020 10:42:13 +0530 Subject: [OpenSIPS-Users] changing callerids In-Reply-To: References: Message-ID: Hello Vic, Can you tell me from which route are you trying this function? It only allows on request route, branch route and failure route. I think you misunderstood how to use the exported function, let me guide you. It will not update only the user part of the 'from' uri but works on uri. So you need to create a custom string like below to fulfill your requirements and the first argument is for display part not for uri part. $avp(fromuri) = "sip:" + *$avp(650)* + "@" + $fd; It should be called only once at initial requests and the subsequent requests(if you loaded the dialog module and created module or used forced_dialog in the uri module) and responses(using tm module) will be automatically updated your 'from uri'. Refer the below example which helps you to guide how you can use this function in different use cases. *$avp(display) = "Jolin";* *$avp(fromuri) = "sip:+18736352333 at myopensipsdomain.com "* *REPLACE BOTH display name and uri* *uac_replace_from("$avp(display)","$avp(fromuri)");* *e.g. received From: "Vic" >;tag=ca4a1348* * sent From: "Jolin" >;tag=ca4a1348* REPLACE ONLY display name *uac_replace_from("$avp(display)","");* *e.g. received From: "Vic" >;tag=ca4a1348* * sent From: "Jolin" ;tag=ca4a1348* *REPLACE ONLY uri WITHOUT TOUCHING display name* *uac_replace_from( ,"$avp(fromuri)");* *e.g. received From: "Vic" >;tag=ca4a1348* * sent From: "Vic" >;tag=ca4a1348* REMOVE display and REPLACE uri *uac_replace_from("","$avp(fromuri)");* *e.g. received From: "Vic" >;tag=ca4a1348* * sent From: >;tag=ca4a1348* For more information you can read the uri module documentation here. *NOTE:* If you're using *3.X.X* version then avoid double quotes for avp variables. *e.g. **uac_replace_from($avp(display),$avp(fromuri));* Thanks & Regards *Diptesh Patel* Software Developer Ecosmob Technologies Ltd, Ahmedabad Mo:*+919898962659* On Fri, Jul 10, 2020 at 12:29 AM Vic Jolin wrote: > Hi, > > Are there other ways of "changing" callerids for a certain call aside from > uac_replace_from? > > And what is the correct way of doing this? > > I have uac_replace_from("$avp(650)", ""); > > I find it giving errors when I try to update the uri with > > sip:$avp(650)@ipadddress:poprt > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.  -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Fri Jul 10 06:47:41 2020 From: johan at democon.be (Johan De Clercq) Date: Fri, 10 Jul 2020 06:47:41 +0000 Subject: [OpenSIPS-Users] Make opensips register to VoIP Provider as a trunk with auth In-Reply-To: References: Message-ID: You need registrar and you need to put your credentials in the registrar table. Outlook voor iOS downloaden ________________________________ Van: Users namens Sharad Kumar via Users Verzonden: Friday, July 10, 2020 2:56:06 AM Aan: users at lists.opensips.org Onderwerp: [OpenSIPS-Users] Make opensips register to VoIP Provider as a trunk with auth Hey guys, I was just curious that can we make OpenSIPS to register as a SIP endpoint to VoIP provider like Twillio. We already using IP based auth in OpenSIPS to accept calls but one of our VOIP Provider wants our OpenSIPS SBC to register with them as a SIP trunk to get calls. Does anyone got make OpenSIPS register to provider before using AUTH or Registrar module ? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From latcom at gmail.com Fri Jul 10 07:04:15 2020 From: latcom at gmail.com (=?utf-8?Q?Maksims_De=C5=86isovs?=) Date: Fri, 10 Jul 2020 10:04:15 +0300 Subject: [OpenSIPS-Users] PUBLISH from External service Message-ID: Good day, community. I have a scheme: A – O – C, where A – hardware phone with BLF buttons O – opensips C – external server Working scenario: A sends subscribe (for some number, for example 123456789 at opensips) events to opensips. C sends publish events to O about number 123456789 status (busy, available, etc) O sends notify events to A about 123456789 number status. What should I use for this scenario? The same scenario is described in https://opensips.org/docs/modules/2.4.x/presence_callinfo.html, but what should I use for “External publishing”? Will be glad to receive any response for this :) Thanks! From diptesh.patel at ecosmob.com Fri Jul 10 13:28:50 2020 From: diptesh.patel at ecosmob.com (Diptesh Patel) Date: Fri, 10 Jul 2020 18:58:50 +0530 Subject: [OpenSIPS-Users] siprec module does response re-invite from a siprec server. Message-ID: Hello, I am using opensips 2.4.7 and opensips is working as a siprec client with rtpproxy. It is working fine but it does not respond to any re-invite from siprec server as a refresher after a few seconds and the siprec server rejects the call with BYE due to timeout and recording stops there. Is there any configuration required for that? Thanks & Regards *Diptesh Patel* Software Developer Ecosmob Technologies Ltd, Ahmedabad Mo:*+919898962659* -- *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.  -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Fri Jul 10 15:33:24 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Fri, 10 Jul 2020 18:33:24 +0300 Subject: [OpenSIPS-Users] siprec module does response re-invite from a siprec server. In-Reply-To: References: Message-ID: Hi, Diptesh! Unfortunately reinvites from the SIPREC servers are not supported by the module right now. Please open a feature request for this. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 7/10/20 4:28 PM, Diptesh Patel wrote: > Hello, > > I am using opensips 2.4.7 and opensips is working as a siprec client > with rtpproxy. It is working fine but it does not respond to any > re-invite from siprec server as a refresher after a few seconds and the > siprec server rejects the call with BYE due to timeout and recording > stops there. Is there any configuration required for that? > > Thanks & Regards > *Diptesh Patel* > Software Developer > Ecosmob Technologies Ltd, > Ahmedabad > Mo:*+919898962659* > > *Disclaimer* > In addition to generic Disclaimer which you have agreed on our website, > any views or opinions presented in this email are solely those of the > originator and do not necessarily represent those of the Company or its > sister concerns. Any liability (in negligence, contract or otherwise) > arising from any third party taking any action, or refraining from > taking any action on the basis of any of the information contained in > this email is hereby excluded. > > *Confidentiality* > This communication (including any attachment/s) is intended only for the > use of the addressee(s) and contains information that is PRIVILEGED AND > CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or > copying of this communication is prohibited. Please inform originator if > you have received it in error. > > *Caution for viruses, malware etc.* > This communication, including any attachments, may not be free of > viruses, trojans, similar or new contaminants/malware, interceptions or > interference, and may not be compatible with your systems. You shall > carry out virus/malware scanning on your own before opening any > attachment to this e-mail. The sender of this e-mail and Company > including its sister concerns shall not be liable for any damage that > may incur to you as a result of viruses, incompleteness of this message, > a delay in receipt of this message or any other computer problems. > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From diptesh.patel at ecosmob.com Fri Jul 10 15:59:36 2020 From: diptesh.patel at ecosmob.com (Diptesh Patel) Date: Fri, 10 Jul 2020 21:29:36 +0530 Subject: [OpenSIPS-Users] siprec module does response re-invite from a siprec server. In-Reply-To: References: Message-ID: Hello Razvan, Thanks for your prompt response. I opened a feature request. https://github.com/OpenSIPS/opensips/issues/2167 Thanks & Regards *Diptesh Patel* Software Developer Ecosmob Technologies Ltd, Ahmedabad Mo:*+919898962659* On Fri, Jul 10, 2020 at 9:05 PM Răzvan Crainea wrote: > Hi, Diptesh! > > Unfortunately reinvites from the SIPREC servers are not supported by the > module right now. Please open a feature request for this. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 7/10/20 4:28 PM, Diptesh Patel wrote: > > Hello, > > > > I am using opensips 2.4.7 and opensips is working as a siprec client > > with rtpproxy. It is working fine but it does not respond to any > > re-invite from siprec server as a refresher after a few seconds and the > > siprec server rejects the call with BYE due to timeout and recording > > stops there. Is there any configuration required for that? > > > > Thanks & Regards > > *Diptesh Patel* > > Software Developer > > Ecosmob Technologies Ltd, > > Ahmedabad > > Mo:*+919898962659* > > > > *Disclaimer* > > In addition to generic Disclaimer which you have agreed on our website, > > any views or opinions presented in this email are solely those of the > > originator and do not necessarily represent those of the Company or its > > sister concerns. Any liability (in negligence, contract or otherwise) > > arising from any third party taking any action, or refraining from > > taking any action on the basis of any of the information contained in > > this email is hereby excluded. > > > > *Confidentiality* > > This communication (including any attachment/s) is intended only for the > > use of the addressee(s) and contains information that is PRIVILEGED AND > > CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or > > copying of this communication is prohibited. Please inform originator if > > you have received it in error. > > > > *Caution for viruses, malware etc.* > > This communication, including any attachments, may not be free of > > viruses, trojans, similar or new contaminants/malware, interceptions or > > interference, and may not be compatible with your systems. You shall > > carry out virus/malware scanning on your own before opening any > > attachment to this e-mail. The sender of this e-mail and Company > > including its sister concerns shall not be liable for any damage that > > may incur to you as a result of viruses, incompleteness of this message, > > a delay in receipt of this message or any other computer problems. > > > > _______________________________________________ > > 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 > -- *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.  -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensips at jfive.net Fri Jul 10 20:02:47 2020 From: opensips at jfive.net (James) Date: Fri, 10 Jul 2020 20:02:47 +0000 Subject: [OpenSIPS-Users] Opensips 2.4.8 SEGFAULT Message-ID: Hello! I am having an issue with opensips crashing. I have reviewed the guide on how to generate a core dump. My current problem is when I try to use gdb. Here is what I am doing: gdb /usr/sbin/opensips core.opensips.993.b6ac8a71177a49cd8238e22ba265c6e9.16129.1594410164000000.lz4 GNU gdb (GDB) Red Hat Enterprise Linux 8.2-11.el8 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/sbin/opensips...Reading symbols from .gnu_debugdata for /usr/sbin/opensips...(no debugging symbols found)...done. (no debugging symbols found)...done. "/var/lib/systemd/coredump/core.opensips.993.b6ac8a71177a49cd8238e22ba265c6e9.16129.1594410164000000.lz4" is not a core dump: file format not recognized Missing separate debuginfos, use: yum debuginfo-install opensips-2.4.8-1.el8.x86_64 I am running Centos 8. I installed opensips using the RPM from the opensips download site. The dump file is generated from systemd. I added the -w flag the service to put the dump file in the opensips directory but that did not change the location of the dump file. Here is the information from the crash in the logs. /usr/sbin/opensips[16129]: CRITICAL:core:sig_usr: segfault in process pid: 16129, id: 7 kernel: opensips[16129]: segfault at 0 ip 00000000004c4363 sp 00007ffcdf449470 error 6 in opensips[400000+212000] kernel: Code: c4 28 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 00 48 c1 e8 03 89 c2 e9 8c fb ff ff 0f 1f 44 00 00 48 89 c2 <48> 89 37 48 c1 ea 03 48 c1 e2 04 48 01 ea 48 8b 4a 58 48 83 e9 01 systemd[1]: Started Process Core Dump (PID 16147/UID 0). Opensips info version: opensips 2.4.8 (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. main.c compiled on 19:27:39 Jun 30 2020 with gcc 8 My opensips start command /usr/sbin/opensips -P /run/opensips/opensips.pid -f /etc/opensips/opensips.cfg -m 20480 -M 5120 -w /etc/opensips/dump What am I missing in order to get a gdb core dump? Thanks, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensips at jfive.net Sat Jul 11 01:10:39 2020 From: opensips at jfive.net (James) Date: Sat, 11 Jul 2020 01:10:39 +0000 Subject: [OpenSIPS-Users] Opensips 2.4.8 SEGFAULT In-Reply-To: References: Message-ID: <261ee76a64450a126ee27e6085bc10b6@jfive.net> I made a little more progress. This is what I have now. Message: Process 18626 (opensips) of user 993 dumped core. Stack trace of thread 18626: #0 0x00007fe49e05b9e0 t_should_relay_response (tm.so) #1 0x00007fe49e05daa3 relay_reply (tm.so) #2 0x00007fe49e060905 reply_received (tm.so) #3 0x000000000044a4f8 forward_reply (opensips) #4 0x0000000000434248 receive_msg (opensips) #5 0x000000000055c5e6 udp_read_req (opensips) #6 0x00000000005413bf udp_start_processes (opensips) #7 0x0000000000417fb5 main (opensips) #8 0x00007feade6fa873 __libc_start_main (libc.so.6) #9 0x000000000041882e _start (opensips) (gdb) bt full #0 0x00007fe49e05b9e0 in t_should_relay_response () from /usr/lib64/opensips/modules/tm.so No symbol table info available. #1 0x00007fe49e05daa3 in relay_reply () from /usr/lib64/opensips/modules/tm.so No symbol table info available. #2 0x00007fe49e060905 in reply_received () from /usr/lib64/opensips/modules/tm.so No symbol table info available. #3 0x000000000044a4f8 in forward_reply () No symbol table info available. #4 0x0000000000434248 in receive_msg () No symbol table info available. #5 0x000000000055c5e6 in udp_read_req () No symbol table info available. #6 0x00000000005413bf in udp_start_processes () No symbol table info available. #7 0x0000000000417fb5 in main () No symbol table info available. I am using force_send_socket(udp:1.2.3.4:5060) with mhomed=1. Would this be an issue? July 10, 2020 1:02 PM, "James via Users" )> wrote: Hello! I am having an issue with opensips crashing. I have reviewed the guide on how to generate a core dump. My current problem is when I try to use gdb. Here is what I am doing: gdb /usr/sbin/opensips core.opensips.993.b6ac8a71177a49cd8238e22ba265c6e9.16129.1594410164000000.lz4 GNU gdb (GDB) Red Hat Enterprise Linux 8.2-11.el8 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/sbin/opensips...Reading symbols from .gnu_debugdata for /usr/sbin/opensips...(no debugging symbols found)...done. (no debugging symbols found)...done. "/var/lib/systemd/coredump/core.opensips.993.b6ac8a71177a49cd8238e22ba265c6e9.16129.1594410164000000.lz4" is not a core dump: file format not recognized Missing separate debuginfos, use: yum debuginfo-install opensips-2.4.8-1.el8.x86_64 I am running Centos 8. I installed opensips using the RPM from the opensips download site. The dump file is generated from systemd. I added the -w flag the service to put the dump file in the opensips directory but that did not change the location of the dump file. Here is the information from the crash in the logs. /usr/sbin/opensips[16129]: CRITICAL:core:sig_usr: segfault in process pid: 16129, id: 7 kernel: opensips[16129]: segfault at 0 ip 00000000004c4363 sp 00007ffcdf449470 error 6 in opensips[400000+212000] kernel: Code: c4 28 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 00 48 c1 e8 03 89 c2 e9 8c fb ff ff 0f 1f 44 00 00 48 89 c2 <48> 89 37 48 c1 ea 03 48 c1 e2 04 48 01 ea 48 8b 4a 58 48 83 e9 01 systemd[1]: Started Process Core Dump (PID 16147/UID 0). Opensips info version: opensips 2.4.8 (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. main.c compiled on 19:27:39 Jun 30 2020 with gcc 8 My opensips start command /usr/sbin/opensips -P /run/opensips/opensips.pid -f /etc/opensips/opensips.cfg -m 20480 -M 5120 -w /etc/opensips/dump What am I missing in order to get a gdb core dump? Thanks, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From venefax at gmail.com Sat Jul 11 04:27:51 2020 From: venefax at gmail.com (Saint Michael) Date: Sat, 11 Jul 2020 00:27:51 -0400 Subject: [OpenSIPS-Users] function append_hf may be wrong Message-ID: I call this: append_hf("Identity:\r\n$avp(signature)\r\n"); and the outbound INVITE is wrong, since the header must be located before the "Content-Type: application/sdp. X-: 381." in fact, the 381 are wrong because my new header itself is way over 500 characters. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces, timer. Content-Type: application/sdp. X-: 381. Identity:. eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1IjoiaHR0cHM6Ly9jci5jY2lkLm5ldXN0YXIuYml6L2NjaWQvYXV0aG4vdjIvY2VydHMvMTExMTguMTAwMzIifQ.eyJhdHRlc3QiOiJDIiwiZGVzdCI6eyJ0biI6WyIxNjMxNzkxODM3OCJdfSwiaWF0IjoxNTk0NDQxMTY1LCJvcmlnIjp7InRuIjoiNjM2NTY2NjY2NiJ9LCJvcmlnaWQiOiIxMjNlNDU2Ny1lODliLTEyZDMtYTQ1Ni00MjY2NTU0NDAwMDAifQ.5U7fmN7whQVdmRmU0yOmDFZenUZtX0_mnKvQRB0yUe1i0NUdnTUqa8pHF4VxBdinDTSoOX1_I9mKR3A1x9DXzw;info=< https://ccccc>;alg="ES256";ppt="shaken". . v=0. -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensips at jfive.net Sat Jul 11 08:44:58 2020 From: opensips at jfive.net (James) Date: Sat, 11 Jul 2020 08:44:58 +0000 Subject: [OpenSIPS-Users] Opensips 2.4.8 SEGFAULT In-Reply-To: <261ee76a64450a126ee27e6085bc10b6@jfive.net> References: <261ee76a64450a126ee27e6085bc10b6@jfive.net> Message-ID: <2fbe5a654436b58b36ea1115b43b2a8d@jfive.net> I removed my force_send_socket() and I am now getting a different problem. Stack trace of thread 20347: #0 0x00000000004c4363 fm_malloc (opensips) #1 0x00007fcffdb945e8 alter_mediaip.isra.22.constprop.39 (rtpproxy.so) #2 0x00007fcffdba52e4 force_rtp_proxy_body (rtpproxy.so) #3 0x00007fcffdba6768 force_rtp_proxy (rtpproxy.so) #4 0x00007fcffdba7e0b rtpproxy_offer5_f (rtpproxy.so) #5 0x00000000004284bc do_action (opensips) #6 0x000000000042f310 run_action_list (opensips) #7 0x000000000042d3f8 do_action (opensips) #8 0x000000000042f310 run_action_list (opensips) #9 0x000000000042d3f8 do_action (opensips) #10 0x000000000042f310 run_action_list (opensips) #11 0x000000000042f39c run_actions (opensips) #12 0x000000000042c0dc do_action (opensips) #13 0x000000000042f310 run_action_list (opensips) #14 0x000000000042d3f8 do_action (opensips) #15 0x000000000042f310 run_action_list (opensips) #16 0x000000000042f5db run_top_route (opensips) #17 0x00000000004351b9 receive_msg (opensips) #18 0x000000000055c5e6 udp_read_req (opensips) #19 0x00000000005413bf udp_start_processes (opensips) #20 0x0000000000417fb5 main (opensips) #21 0x00007fd63fdac873 __libc_start_main (libc.so.6) #22 0x000000000041882e _start (opensips) (gdb) bt full #0 0x00000000004c4363 in fm_malloc () No symbol table info available. #1 0x00007fcffdb945e8 in alter_mediaip.isra.22.constprop () from /usr/lib64/opensips/modules/rtpproxy.so No symbol table info available. #2 0x00007fcffdba52e4 in force_rtp_proxy_body () from /usr/lib64/opensips/modules/rtpproxy.so No symbol table info available. #3 0x00007fcffdba6768 in force_rtp_proxy () from /usr/lib64/opensips/modules/rtpproxy.so No symbol table info available. #4 0x00007fcffdba7e0b in rtpproxy_offer5_f () from /usr/lib64/opensips/modules/rtpproxy.so No symbol table info available. #5 0x00000000004284bc in do_action () No symbol table info available. #6 0x000000000042f310 in run_action_list () No symbol table info available. #7 0x000000000042d3f8 in do_action () No symbol table info available. #8 0x000000000042f310 in run_action_list () No symbol table info available. #9 0x000000000042d3f8 in do_action () No symbol table info available. #10 0x000000000042f310 in run_action_list () No symbol table info available. #11 0x000000000042f39c in run_actions () No symbol table info available. #12 0x000000000042c0dc in do_action () No symbol table info available. #13 0x000000000042f310 in run_action_list () No symbol table info available. #14 0x000000000042d3f8 in do_action () No symbol table info available. #15 0x000000000042f310 in run_action_list () No symbol table info available. #16 0x000000000042f5db in run_top_route () No symbol table info available. #17 0x00000000004351b9 in receive_msg () No symbol table info available. #18 0x000000000055c5e6 in udp_read_req () No symbol table info available. #19 0x00000000005413bf in udp_start_processes () No symbol table info available. #20 0x0000000000417fb5 in main () No symbol table info available. July 10, 2020 6:10 PM, "James" )> wrote: I made a little more progress. This is what I have now. Message: Process 18626 (opensips) of user 993 dumped core. Stack trace of thread 18626: #0 0x00007fe49e05b9e0 t_should_relay_response (tm.so) #1 0x00007fe49e05daa3 relay_reply (tm.so) #2 0x00007fe49e060905 reply_received (tm.so) #3 0x000000000044a4f8 forward_reply (opensips) #4 0x0000000000434248 receive_msg (opensips) #5 0x000000000055c5e6 udp_read_req (opensips) #6 0x00000000005413bf udp_start_processes (opensips) #7 0x0000000000417fb5 main (opensips) #8 0x00007feade6fa873 __libc_start_main (libc.so.6) #9 0x000000000041882e _start (opensips) (gdb) bt full #0 0x00007fe49e05b9e0 in t_should_relay_response () from /usr/lib64/opensips/modules/tm.so No symbol table info available. #1 0x00007fe49e05daa3 in relay_reply () from /usr/lib64/opensips/modules/tm.so No symbol table info available. #2 0x00007fe49e060905 in reply_received () from /usr/lib64/opensips/modules/tm.so No symbol table info available. #3 0x000000000044a4f8 in forward_reply () No symbol table info available. #4 0x0000000000434248 in receive_msg () No symbol table info available. #5 0x000000000055c5e6 in udp_read_req () No symbol table info available. #6 0x00000000005413bf in udp_start_processes () No symbol table info available. #7 0x0000000000417fb5 in main () No symbol table info available. I am using force_send_socket(udp:1.2.3.4:5060) with mhomed=1. Would this be an issue? July 10, 2020 1:02 PM, "James via Users" )> wrote: Hello! I am having an issue with opensips crashing. I have reviewed the guide on how to generate a core dump. My current problem is when I try to use gdb. Here is what I am doing: gdb /usr/sbin/opensips core.opensips.993.b6ac8a71177a49cd8238e22ba265c6e9.16129.1594410164000000.lz4 GNU gdb (GDB) Red Hat Enterprise Linux 8.2-11.el8 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/sbin/opensips...Reading symbols from .gnu_debugdata for /usr/sbin/opensips...(no debugging symbols found)...done. (no debugging symbols found)...done. "/var/lib/systemd/coredump/core.opensips.993.b6ac8a71177a49cd8238e22ba265c6e9.16129.1594410164000000.lz4" is not a core dump: file format not recognized Missing separate debuginfos, use: yum debuginfo-install opensips-2.4.8-1.el8.x86_64 I am running Centos 8. I installed opensips using the RPM from the opensips download site. The dump file is generated from systemd. I added the -w flag the service to put the dump file in the opensips directory but that did not change the location of the dump file. Here is the information from the crash in the logs. /usr/sbin/opensips[16129]: CRITICAL:core:sig_usr: segfault in process pid: 16129, id: 7 kernel: opensips[16129]: segfault at 0 ip 00000000004c4363 sp 00007ffcdf449470 error 6 in opensips[400000+212000] kernel: Code: c4 28 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 00 48 c1 e8 03 89 c2 e9 8c fb ff ff 0f 1f 44 00 00 48 89 c2 <48> 89 37 48 c1 ea 03 48 c1 e2 04 48 01 ea 48 8b 4a 58 48 83 e9 01 systemd[1]: Started Process Core Dump (PID 16147/UID 0). Opensips info version: opensips 2.4.8 (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. main.c compiled on 19:27:39 Jun 30 2020 with gcc 8 My opensips start command /usr/sbin/opensips -P /run/opensips/opensips.pid -f /etc/opensips/opensips.cfg -m 20480 -M 5120 -w /etc/opensips/dump What am I missing in order to get a gdb core dump? Thanks, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From chandan.pr at webshar.org Sat Jul 11 12:04:51 2020 From: chandan.pr at webshar.org (Chandan PR) Date: Sat, 11 Jul 2020 17:34:51 +0530 Subject: [OpenSIPS-Users] OpenSips FIFO command - frequency advise Message-ID: Hi, As part of the load balancer script, we are publishing some custom statistics per destination (which can help us in identifying nodes that may go bad). We are planning to use the output of opensipsctl fifo get_statistics dynamic: command as a feedback loop to the call publisher. Any advice on the frequency considerations we should have for running fifo commands? Can we afford to run this every minute without much impact on the performance? Wanted to start on a good frequency for running load tests to understand the impact. Thanks in advance. -- Regards, Chandan Ravishankar -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at switchtel.co.za Mon Jul 13 01:59:36 2020 From: greg at switchtel.co.za (Gregory Massel) Date: Mon, 13 Jul 2020 03:59:36 +0200 Subject: [OpenSIPS-Users] OpenSIPS NOTIFY for MWI on Asterisk PUBLISH? Message-ID: <2fdd0f02-a303-06d2-af07-85f6fa123f7c@switchtel.co.za> Hello I'm wondering whether it is possible to bulk publish MWI information from Asterisk to OpenSIPS and have OpenSIPS generate NOTIFY messages? I've set up Asterisk with PJSIP as follows: [opensips-mwi] type=outbound-publish server_uri=sip:asterisk-mwi at opensips:5060 event=asterisk-mwi [opensips-mwi] type=asterisk-publication mailboxstate_publish=opensips-mwi device_state=no mailbox_state=yes Now it's generating numerous SIP requests such as the following: PUBLISH sip:asterisk-mwi at opensips:5060 SIP/2.0 Via: SIP/2.0/UDP 1.2.3.4:5060;rport;branch=z9hG4bKPj00450957-4e0c-408e-bdc2-3a4560613253 From: ;tag=d13b162a-6b45-418e-9443-66944b5cc88e To: Call-ID: 761d94e5-1d41-4bfd-9354-66651e1692bd CSeq: 17836 PUBLISH Event: asterisk-mwi Expires: 3600 Max-Forwards: 70 User-Agent: Asterisk Content-Type: application/json Content-Length: 93 {"type":"mailboxstate","uniqueid":"201 at test","old":0,"new":0,"eid":"90:b1:1c:0d:12:84"} However, I'm struggling to transform these on OpenSIPS. I've used the json.so module to interpret the body and sipmsgops.so to remove and the old body and add a newly constructed body with an application/simple-message-summary structure. I've managed to get the packet looking almost right, however, one major issue remains: No matter what I do, I cannot modify the request method from PUBLISH to NOTIFY. Using subst("/PUBLISH/NOTIFY/") from textops.so, it succeeds in modifying the CSeq header, but it cannot change the request method. Is it possible to modify the request method? If not, is there some other way that I can generate completely new MWI NOTIFY packets? Note that presence is working 100%; that's not an issue. It's strictly MWI that's a problem. Documentation on presence_mwi.so seems to be extremely limited. It's unclear what it actually does. It's not really an option to have a separate PJSIP endpoint definition in Asterisk for each mailbox as Asterisk/PJSIP struggles to reload with tens of thousands of endpoints. Things work reasonably up until roughly 12,000 endpoints, but beyond that reloads get slow. I don't forsee this being any better with realtime, as sorcery would still have to load all the endpoints into cache and merge the changes. Having a single (OpenSIPS) endpoint in Asterisk and publishing the voicemail status should allow for far greater scale. Any help would be greatly appreciated. Regards Gregory Massel -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Mon Jul 13 05:52:45 2020 From: spanda at 3clogic.com (Sasmita Panda) Date: Mon, 13 Jul 2020 11:22:45 +0530 Subject: [OpenSIPS-Users] Regarding opensips 3.0.0 logging . In-Reply-To: References: Message-ID: Is there any update on this ? Please let me know . I am blocked . *Thanks & Regards* *Sasmita Panda* *Senior Network Testing and Software Engineer* *3CLogic , ph:07827611765* On Wed, Jul 8, 2020 at 4:32 PM Sasmita Panda wrote: > Hi , > > I am using below version of opensips . > version: opensips 3.0.0-beta (x86_64/linux) > flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, > Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, CC_O0, 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. > svn revision: 3651:3664M > main.c compiled on 12:08:17 Jul 15 2019 with gcc 5.4.0 > > *I am running my config with log_level=3 , but in a single day it creates > a 16GB log file . * > > > WARNING:core:timer_ticker: timer task already > scheduled 464275150 ms ago (now 464305720 ms), delaying execution > WARNING:core:timer_ticker: timer task already scheduled > 464275150 ms ago (now 464305720 ms), delaying execution > WARNING:core:timer_ticker: timer task already scheduled > 464275150 ms ago (now 464305720 ms), delaying execution > WARNING:core:timer_ticker: timer task already scheduled > 464275150 ms ago (now 464305720 ms), skipping execution > > *Continuously this message is getting printed . Is this a crash or what . > Please help . * > > *Thanks & Regards* > *Sasmita Panda* > *Senior Network Testing and Software Engineer* > *3CLogic , ph:07827611765* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmaruzz at gmail.com Mon Jul 13 07:36:23 2020 From: gmaruzz at gmail.com (Giovanni Maruzzelli) Date: Mon, 13 Jul 2020 09:36:23 +0200 Subject: [OpenSIPS-Users] Regarding opensips 3.0.0 logging . In-Reply-To: References: Message-ID: maybe you want to use latest released 3.0.3 ? you are using: opensips 3.0.0-beta On Mon, Jul 13, 2020 at 7:55 AM Sasmita Panda wrote: > Is there any update on this ? Please let me know . I am blocked . > > > *Thanks & Regards* > *Sasmita Panda* > *Senior Network Testing and Software Engineer* > *3CLogic , ph:07827611765* > > > On Wed, Jul 8, 2020 at 4:32 PM Sasmita Panda wrote: > >> Hi , >> >> I am using below version of opensips . >> version: opensips 3.0.0-beta (x86_64/linux) >> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >> Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, CC_O0, 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. >> svn revision: 3651:3664M >> main.c compiled on 12:08:17 Jul 15 2019 with gcc 5.4.0 >> >> *I am running my config with log_level=3 , but in a single day it creates >> a 16GB log file . * >> >> >> WARNING:core:timer_ticker: timer task already >> scheduled 464275150 ms ago (now 464305720 ms), delaying execution >> WARNING:core:timer_ticker: timer task already scheduled >> 464275150 ms ago (now 464305720 ms), delaying execution >> WARNING:core:timer_ticker: timer task already scheduled >> 464275150 ms ago (now 464305720 ms), delaying execution >> WARNING:core:timer_ticker: timer task already scheduled >> 464275150 ms ago (now 464305720 ms), skipping execution >> >> *Continuously this message is getting printed . Is this a crash or what >> . Please help . * >> >> *Thanks & Regards* >> *Sasmita Panda* >> *Senior Network Testing and Software Engineer* >> *3CLogic , ph:07827611765* >> > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Sincerely, Giovanni Maruzzelli OpenTelecom.IT cell: +39 347 266 56 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Mon Jul 13 07:46:35 2020 From: spanda at 3clogic.com (Sasmita Panda) Date: Mon, 13 Jul 2020 13:16:35 +0530 Subject: [OpenSIPS-Users] Regarding opensips 3.0.0 logging . In-Reply-To: References: Message-ID: You mean . The waring message getting printed in the logs will be fixed after upgrade ? If so , then I will do for sure . *Thanks & Regards* *Sasmita Panda* *Senior Network Testing and Software Engineer* *3CLogic , ph:07827611765* On Mon, Jul 13, 2020 at 1:08 PM Giovanni Maruzzelli wrote: > maybe you want to use latest released 3.0.3 ? > > you are using: opensips 3.0.0-beta > > > On Mon, Jul 13, 2020 at 7:55 AM Sasmita Panda wrote: > >> Is there any update on this ? Please let me know . I am blocked . >> >> >> *Thanks & Regards* >> *Sasmita Panda* >> *Senior Network Testing and Software Engineer* >> *3CLogic , ph:07827611765* >> >> >> On Wed, Jul 8, 2020 at 4:32 PM Sasmita Panda wrote: >> >>> Hi , >>> >>> I am using below version of opensips . >>> version: opensips 3.0.0-beta (x86_64/linux) >>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, >>> Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, CC_O0, 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. >>> svn revision: 3651:3664M >>> main.c compiled on 12:08:17 Jul 15 2019 with gcc 5.4.0 >>> >>> *I am running my config with log_level=3 , but in a single day it >>> creates a 16GB log file . * >>> >>> >>> WARNING:core:timer_ticker: timer task already >>> scheduled 464275150 ms ago (now 464305720 ms), delaying execution >>> WARNING:core:timer_ticker: timer task already scheduled >>> 464275150 ms ago (now 464305720 ms), delaying execution >>> WARNING:core:timer_ticker: timer task already scheduled >>> 464275150 ms ago (now 464305720 ms), delaying execution >>> WARNING:core:timer_ticker: timer task already scheduled >>> 464275150 ms ago (now 464305720 ms), skipping execution >>> >>> *Continuously this message is getting printed . Is this a crash or what >>> . Please help . * >>> >>> *Thanks & Regards* >>> *Sasmita Panda* >>> *Senior Network Testing and Software Engineer* >>> *3CLogic , ph:07827611765* >>> >> _______________________________________________ >> Users mailing list >> Users at lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > -- > Sincerely, > > Giovanni Maruzzelli > OpenTelecom.IT > cell: +39 347 266 56 18 > > _______________________________________________ > 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 rembgrets at gmail.com Mon Jul 13 13:02:36 2020 From: rembgrets at gmail.com (ryan embgrets) Date: Mon, 13 Jul 2020 18:02:36 +0500 Subject: [OpenSIPS-Users] How to delay a branch Message-ID: Greetings, I am using mid-registrar module to bind multiple devices to a single AOR. I would like to put some delay between different branches while sending them out. So, I set a branch flag on those registrations before calling the save function, and then try to use async sleep in the branch route after lookup. But I see sleep applies on the whole call(all branches are sent with delay) no matter if it was called on a single branch. *Method1: * branch_route[REG_BRANCH] { xlog("INFO:[$ci] -> for $fU with flags $bf with $ru and $du \n"); if (isbflagset(delay)){ xlog("INFO:[$ci] -> sleep was deducted on this call \n"); async( sleep(7), after_sleep ); } } route[after_sleep] { xlog("delay branch\n"); } *Method2: * I tried to send delay branches to invalid destination, so I can use failure_route to route them back to the correct destination. branch_route[REG_BRANCH] { xlog("INFO:[$ci] -> for $fU with flags $bf with $ru and $du \n"); if (isbflagset(delay)){ xlog("INFO:[$ci] -> sleep was deducted on this call \n"); cache_store("local","$ci","$du",1200); $du = "sip:192.168.20.20"; t_on_failure("after_sleep"); } } failure_route[after_sleep] { cache_store("local","$ci","$var(dst)"); $du = $var(dst); t_relay(); exit; } But failure_routes gets executed for the whole transaction instead of getting executed for a single branch. Do we have any t_on_failure_branch route ? I am really blocked here, any hint guys? Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From babak.freeswitch at gmail.com Tue Jul 14 07:27:37 2020 From: babak.freeswitch at gmail.com (Babak Yakhchali) Date: Tue, 14 Jul 2020 11:57:37 +0430 Subject: [OpenSIPS-Users] Handling multiple re invites from freeswitch Message-ID: Hi I'm testing re-invites from a freeswitch server with this scenario: client1,client2 <=> opensips (rtpproxy) <=> freeswitch [image: arch.jpg] freeswitch is used to announce some mid call sound file. At start freeswitch is not in the rtp path and rtp goes through rtpproxy to clients. After 7 seconds freeswitch sends re-invites to come to the rtp session and play the sound file and after playback sends re-invites to leave the rtp path. All sip signalling is done correctly and the sound file is played successfully, but after that no rtp is sent from rtpproxy to clients. I'm using rtpproxy on invites like this: if (has_body("application/sdp")) { if(has_totag()){ rtpproxy_unforce(); } rtpproxy_offer("ronf", "x.x.x.x"); } and on reply route: rtpproxy_answer("ronf", " x.x.x.x"); Can rtpproxy handle such a scenario? Should I do anything special because there is some kind of loopback in rtpproxy? opensips version is 2.4 git branch rtpproxy version is 2.2.alpha.61e74c0 thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: arch.jpg Type: image/jpeg Size: 12805 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: arch.svg Type: image/svg+xml Size: 12793 bytes Desc: not available URL: From mark at allenclan.co.uk Tue Jul 14 15:11:02 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Tue, 14 Jul 2020 16:11:02 +0100 Subject: [OpenSIPS-Users] SIP to WebRTC via OpenSIPS mid-registrar fails: forced proto 6 not matching sips uri Message-ID: I'm new to OpenSIPS and I've hit a problem I can't find a way past We have a test setup with an OpenSIPS mid-registrar in front of an Asterisk PBX. Mid-registrar is currently in mode 1 (registration throttling). We have SIP and WebRTC endpoints that we want to use. *Current state is:* REGISTER: WebRTC webphone (Mizutech) -> OpenSIPS Mid-registrar -> Asterisk = success REGISTER: SIP softphone (LinPhone) -> OpenSIPS Mid-registrar -> Asterisk = success INVITE: SIP softphone -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP softphone = success, call connects with audio both ways INVITE: WebRTC webphone -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP softphone = success, call connects with audio both ways INVITE: SIP softphone -> OpenSIPS -> Asterisk -> OpenSIPS -> WebRTC webphone = *fails with "**476 Unresolvable destination"* *syslog messages:* ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri CRITICAL:core:mk_proxy: could not resolve hostname: "4xp44jxl0qq0.invalid" ERROR:tm:uri2proxy: bad host name in URI ERROR:tm:t_forward_nonack: failure to add branches Following past reports that I've found with a similar error, *fix_nated_contact()* is run on INVITE messages just before rtpengine flags are set and the *t_relay()* command, but it doesn't appear to make any difference. If I change the *t_relay()* to *t_relay(0x04,)* to disable DNS Failover, I still see the same errors in the log file. I've also checked the record in the OpenSIPS DB "location" table and it seems to me that it has the correct *contact_id* and *contact* info for the destination... contact_id: 2004383309156582802 contact: sips:11001 at 4xp44jxl0qq0.invalid;rtcweb-breaker=yes;transport=wss I'm stuck on where I can go from here - any help very much appreciated! thx Mark *Setup: * OpenSIPS 3.0.2 on Debian Buster RTPEngine Version: 8.4.0.0+0~mr8.4.0.0 *INVITE*: 2020/07/14 14:22:06.176544 192.168.50.185:5060 -> 192.168.50.69:5060 INVITE sip:11001 at 192.168.50.69:5060;ctid=2004383309156582802 SIP/2.0 Via: SIP/2.0/UDP 192.168.50.185:5060 ;rport;branch=z9hG4bKPj3e87a449-f4cc-4128-abbe-95706a1a44a0 From: "11002" ;tag=1c03916d-d086-479a-b984-ff5bbbf3aba8 To: Contact: Call-ID: d1524788-cac2-4bea-a905-4e17ba006688 CSeq: 24456 INVITE Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER Supported: 100rel, timer, replaces, norefersub Session-Expires: 1800 Min-SE: 90 P-Asserted-Identity: "11002" Max-Forwards: 70 User-Agent: FPBX-15.0.16.63(16.9.0) Content-Type: application/sdp Content-Length: 411 v=0 o=- 263255642 263255642 IN IP4 192.168.50.185 s=Asterisk c=IN IP4 192.168.50.185 t=0 0 m=audio 10292 RTP/AVPF 9 107 8 0 3 111 101 a=rtpmap:9 G722/8000 a=rtpmap:107 opus/48000/2 a=fmtp:107 useinbandfec=1 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:111 G726-32/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=maxptime:20 a=sendrecv a=rtcp-mux -------------- next part -------------- An HTML attachment was scrubbed... URL: From staskobzar at gmail.com Tue Jul 14 15:21:02 2020 From: staskobzar at gmail.com (Stas Kobzar) Date: Tue, 14 Jul 2020 11:21:02 -0400 Subject: [OpenSIPS-Users] SIP to WebRTC via OpenSIPS mid-registrar fails: forced proto 6 not matching sips uri In-Reply-To: References: Message-ID: Hello Mark, I had a similar challenge. Using "path" module on both opensips helps to overcome this problem. https://opensips.org/docs/modules/3.2.x/path.html In your mid-registerer you need to enable path support. See "save" function params p0 and v. in your webrtc opensips use path module and function add_path_received On Tue, Jul 14, 2020 at 11:14 AM Mark Allen wrote: > > I'm new to OpenSIPS and I've hit a problem I can't find a way past > > We have a test setup with an OpenSIPS mid-registrar in front of an Asterisk PBX. Mid-registrar is currently in mode 1 (registration throttling). We have SIP and WebRTC endpoints that we want to use. > > Current state is: > > REGISTER: WebRTC webphone (Mizutech) -> OpenSIPS Mid-registrar -> Asterisk = success > REGISTER: SIP softphone (LinPhone) -> OpenSIPS Mid-registrar -> Asterisk = success > > INVITE: SIP softphone -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP softphone = success, call connects with audio both ways > INVITE: WebRTC webphone -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP softphone = success, call connects with audio both ways > INVITE: SIP softphone -> OpenSIPS -> Asterisk -> OpenSIPS -> WebRTC webphone = fails with "476 Unresolvable destination" > > syslog messages: > ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri > CRITICAL:core:mk_proxy: could not resolve hostname: "4xp44jxl0qq0.invalid" > ERROR:tm:uri2proxy: bad host name in URI > ERROR:tm:t_forward_nonack: failure to add branches > > > Following past reports that I've found with a similar error, fix_nated_contact() is run on INVITE messages just before rtpengine flags are set and the t_relay() command, but it doesn't appear to make any difference. If I change the t_relay() to t_relay(0x04,) to disable DNS Failover, I still see the same errors in the log file. I've also checked the record in the OpenSIPS DB "location" table and it seems to me that it has the correct contact_id and contact info for the destination... > > contact_id: 2004383309156582802 > contact: sips:11001 at 4xp44jxl0qq0.invalid;rtcweb-breaker=yes;transport=wss > > I'm stuck on where I can go from here - any help very much appreciated! > > thx > > Mark > > > Setup: > OpenSIPS 3.0.2 on Debian Buster > RTPEngine Version: 8.4.0.0+0~mr8.4.0.0 > > INVITE: > 2020/07/14 14:22:06.176544 192.168.50.185:5060 -> 192.168.50.69:5060 > INVITE sip:11001 at 192.168.50.69:5060;ctid=2004383309156582802 SIP/2.0 > Via: SIP/2.0/UDP 192.168.50.185:5060;rport;branch=z9hG4bKPj3e87a449-f4cc-4128-abbe-95706a1a44a0 > From: "11002" ;tag=1c03916d-d086-479a-b984-ff5bbbf3aba8 > To: > Contact: > Call-ID: d1524788-cac2-4bea-a905-4e17ba006688 > CSeq: 24456 INVITE > Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER > Supported: 100rel, timer, replaces, norefersub > Session-Expires: 1800 > Min-SE: 90 > P-Asserted-Identity: "11002" > Max-Forwards: 70 > User-Agent: FPBX-15.0.16.63(16.9.0) > Content-Type: application/sdp > Content-Length: 411 > > v=0 > o=- 263255642 263255642 IN IP4 192.168.50.185 > s=Asterisk > c=IN IP4 192.168.50.185 > t=0 0 > m=audio 10292 RTP/AVPF 9 107 8 0 3 111 101 > a=rtpmap:9 G722/8000 > a=rtpmap:107 opus/48000/2 > a=fmtp:107 useinbandfec=1 > a=rtpmap:8 PCMA/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:3 GSM/8000 > a=rtpmap:111 G726-32/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-16 > a=ptime:20 > a=maxptime:20 > a=sendrecv > a=rtcp-mux > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From mark at allenclan.co.uk Tue Jul 14 15:46:06 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Tue, 14 Jul 2020 16:46:06 +0100 Subject: [OpenSIPS-Users] SIP to WebRTC via OpenSIPS mid-registrar fails: forced proto 6 not matching sips uri In-Reply-To: References: Message-ID: Thanks Stas - I'll have a look at that. For clarification, we only have one OpenSIPS server acting as mid-registrar. Endpoints register through it to extensions on Asterisk, and Asterisk acts as B2BUA for calls from one extension to another. We've got a lot of additional functionality linked to the Asterisk server so our main need for OpenSIPS is to reduce unnecessary load (e.g. re-REGISTER from mobile devices). On Tue, 14 Jul 2020 at 16:23, Stas Kobzar wrote: > Hello Mark, > > I had a similar challenge. Using "path" module on both opensips helps > to overcome this problem. > https://opensips.org/docs/modules/3.2.x/path.html > > In your mid-registerer you need to enable path support. See "save" > function params p0 and v. > in your webrtc opensips use path module and function add_path_received > > On Tue, Jul 14, 2020 at 11:14 AM Mark Allen wrote: > > > > I'm new to OpenSIPS and I've hit a problem I can't find a way past > > > > We have a test setup with an OpenSIPS mid-registrar in front of an > Asterisk PBX. Mid-registrar is currently in mode 1 (registration > throttling). We have SIP and WebRTC endpoints that we want to use. > > > > Current state is: > > > > REGISTER: WebRTC webphone (Mizutech) -> OpenSIPS Mid-registrar -> > Asterisk = success > > REGISTER: SIP softphone (LinPhone) -> OpenSIPS Mid-registrar -> > Asterisk = success > > > > INVITE: SIP softphone -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP > softphone = success, call connects with audio both ways > > INVITE: WebRTC webphone -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP > softphone = success, call connects with audio both ways > > INVITE: SIP softphone -> OpenSIPS -> Asterisk -> OpenSIPS -> > WebRTC webphone = fails with "476 Unresolvable destination" > > > > syslog messages: > > ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri > > CRITICAL:core:mk_proxy: could not resolve hostname: > "4xp44jxl0qq0.invalid" > > ERROR:tm:uri2proxy: bad host name in URI ;rtcweb-breaker=yes;transport=wss> > > ERROR:tm:t_forward_nonack: failure to add branches > > > > > > Following past reports that I've found with a similar error, > fix_nated_contact() is run on INVITE messages just before rtpengine flags > are set and the t_relay() command, but it doesn't appear to make any > difference. If I change the t_relay() to t_relay(0x04,) to disable DNS > Failover, I still see the same errors in the log file. I've also checked > the record in the OpenSIPS DB "location" table and it seems to me that it > has the correct contact_id and contact info for the destination... > > > > contact_id: 2004383309156582802 > > contact: sips:11001 at 4xp44jxl0qq0.invalid > ;rtcweb-breaker=yes;transport=wss > > > > I'm stuck on where I can go from here - any help very much appreciated! > > > > thx > > > > Mark > > > > > > Setup: > > OpenSIPS 3.0.2 on Debian Buster > > RTPEngine Version: 8.4.0.0+0~mr8.4.0.0 > > > > INVITE: > > 2020/07/14 14:22:06.176544 192.168.50.185:5060 -> 192.168.50.69:5060 > > INVITE sip:11001 at 192.168.50.69:5060;ctid=2004383309156582802 SIP/2.0 > > Via: SIP/2.0/UDP 192.168.50.185:5060 > ;rport;branch=z9hG4bKPj3e87a449-f4cc-4128-abbe-95706a1a44a0 > > From: "11002" >;tag=1c03916d-d086-479a-b984-ff5bbbf3aba8 > > To: > > Contact: > > Call-ID: d1524788-cac2-4bea-a905-4e17ba006688 > > CSeq: 24456 INVITE > > Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, > CANCEL, UPDATE, PRACK, MESSAGE, REFER > > Supported: 100rel, timer, replaces, norefersub > > Session-Expires: 1800 > > Min-SE: 90 > > P-Asserted-Identity: "11002" > > Max-Forwards: 70 > > User-Agent: FPBX-15.0.16.63(16.9.0) > > Content-Type: application/sdp > > Content-Length: 411 > > > > v=0 > > o=- 263255642 263255642 IN IP4 192.168.50.185 > > s=Asterisk > > c=IN IP4 192.168.50.185 > > t=0 0 > > m=audio 10292 RTP/AVPF 9 107 8 0 3 111 101 > > a=rtpmap:9 G722/8000 > > a=rtpmap:107 opus/48000/2 > > a=fmtp:107 useinbandfec=1 > > a=rtpmap:8 PCMA/8000 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:3 GSM/8000 > > a=rtpmap:111 G726-32/8000 > > a=rtpmap:101 telephone-event/8000 > > a=fmtp:101 0-16 > > a=ptime:20 > > a=maxptime:20 > > a=sendrecv > > a=rtcp-mux > > > > > > _______________________________________________ > > 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: From staskobzar at gmail.com Tue Jul 14 16:12:02 2020 From: staskobzar at gmail.com (Stas Kobzar) Date: Tue, 14 Jul 2020 12:12:02 -0400 Subject: [OpenSIPS-Users] SIP to WebRTC via OpenSIPS mid-registrar fails: forced proto 6 not matching sips uri In-Reply-To: References: Message-ID: I see, Mark. It is true, in my case, I splitted webrtc to other opensips (newer version) as our platform was too old. I still think path module function should help: https://opensips.org/docs/modules/3.1.x/path.html#func_add_path_received Good luck On Tue, Jul 14, 2020 at 11:48 AM Mark Allen wrote: > > Thanks Stas - I'll have a look at that. > > For clarification, we only have one OpenSIPS server acting as mid-registrar. Endpoints register through it to extensions on Asterisk, and Asterisk acts as B2BUA for calls from one extension to another. We've got a lot of additional functionality linked to the Asterisk server so our main need for OpenSIPS is to reduce unnecessary load (e.g. re-REGISTER from mobile devices). > > On Tue, 14 Jul 2020 at 16:23, Stas Kobzar wrote: >> >> Hello Mark, >> >> I had a similar challenge. Using "path" module on both opensips helps >> to overcome this problem. >> https://opensips.org/docs/modules/3.2.x/path.html >> >> In your mid-registerer you need to enable path support. See "save" >> function params p0 and v. >> in your webrtc opensips use path module and function add_path_received >> >> On Tue, Jul 14, 2020 at 11:14 AM Mark Allen wrote: >> > >> > I'm new to OpenSIPS and I've hit a problem I can't find a way past >> > >> > We have a test setup with an OpenSIPS mid-registrar in front of an Asterisk PBX. Mid-registrar is currently in mode 1 (registration throttling). We have SIP and WebRTC endpoints that we want to use. >> > >> > Current state is: >> > >> > REGISTER: WebRTC webphone (Mizutech) -> OpenSIPS Mid-registrar -> Asterisk = success >> > REGISTER: SIP softphone (LinPhone) -> OpenSIPS Mid-registrar -> Asterisk = success >> > >> > INVITE: SIP softphone -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP softphone = success, call connects with audio both ways >> > INVITE: WebRTC webphone -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP softphone = success, call connects with audio both ways >> > INVITE: SIP softphone -> OpenSIPS -> Asterisk -> OpenSIPS -> WebRTC webphone = fails with "476 Unresolvable destination" >> > >> > syslog messages: >> > ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri >> > CRITICAL:core:mk_proxy: could not resolve hostname: "4xp44jxl0qq0.invalid" >> > ERROR:tm:uri2proxy: bad host name in URI >> > ERROR:tm:t_forward_nonack: failure to add branches >> > >> > >> > Following past reports that I've found with a similar error, fix_nated_contact() is run on INVITE messages just before rtpengine flags are set and the t_relay() command, but it doesn't appear to make any difference. If I change the t_relay() to t_relay(0x04,) to disable DNS Failover, I still see the same errors in the log file. I've also checked the record in the OpenSIPS DB "location" table and it seems to me that it has the correct contact_id and contact info for the destination... >> > >> > contact_id: 2004383309156582802 >> > contact: sips:11001 at 4xp44jxl0qq0.invalid;rtcweb-breaker=yes;transport=wss >> > >> > I'm stuck on where I can go from here - any help very much appreciated! >> > >> > thx >> > >> > Mark >> > >> > >> > Setup: >> > OpenSIPS 3.0.2 on Debian Buster >> > RTPEngine Version: 8.4.0.0+0~mr8.4.0.0 >> > >> > INVITE: >> > 2020/07/14 14:22:06.176544 192.168.50.185:5060 -> 192.168.50.69:5060 >> > INVITE sip:11001 at 192.168.50.69:5060;ctid=2004383309156582802 SIP/2.0 >> > Via: SIP/2.0/UDP 192.168.50.185:5060;rport;branch=z9hG4bKPj3e87a449-f4cc-4128-abbe-95706a1a44a0 >> > From: "11002" ;tag=1c03916d-d086-479a-b984-ff5bbbf3aba8 >> > To: >> > Contact: >> > Call-ID: d1524788-cac2-4bea-a905-4e17ba006688 >> > CSeq: 24456 INVITE >> > Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER >> > Supported: 100rel, timer, replaces, norefersub >> > Session-Expires: 1800 >> > Min-SE: 90 >> > P-Asserted-Identity: "11002" >> > Max-Forwards: 70 >> > User-Agent: FPBX-15.0.16.63(16.9.0) >> > Content-Type: application/sdp >> > Content-Length: 411 >> > >> > v=0 >> > o=- 263255642 263255642 IN IP4 192.168.50.185 >> > s=Asterisk >> > c=IN IP4 192.168.50.185 >> > t=0 0 >> > m=audio 10292 RTP/AVPF 9 107 8 0 3 111 101 >> > a=rtpmap:9 G722/8000 >> > a=rtpmap:107 opus/48000/2 >> > a=fmtp:107 useinbandfec=1 >> > a=rtpmap:8 PCMA/8000 >> > a=rtpmap:0 PCMU/8000 >> > a=rtpmap:3 GSM/8000 >> > a=rtpmap:111 G726-32/8000 >> > a=rtpmap:101 telephone-event/8000 >> > a=fmtp:101 0-16 >> > a=ptime:20 >> > a=maxptime:20 >> > a=sendrecv >> > a=rtcp-mux >> > >> > >> > _______________________________________________ >> > 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 > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From adjolin at gmail.com Tue Jul 14 16:18:40 2020 From: adjolin at gmail.com (Vic Jolin) Date: Wed, 15 Jul 2020 00:18:40 +0800 Subject: [OpenSIPS-Users] Carrier ID and Rule ID not populating flatstore In-Reply-To: References: Message-ID: Can I also do this from the failure route? I noticed that it is not properly showing the carrier ID where the call really went to, on our CDRs right now it shows it went to carrier C, but when checking our carrier CDRs the call went to carrier A, On Fri, Jul 3, 2020 at 4:00 PM Răzvan Crainea wrote: > Hi, Vic! > > You are not using the correct provisioning in the extra fields. Please > double check the ACC module documentation[1], where it states that for > the db engine, the log_name represents the column in the acc table where > that value ends up. > According to your specifications, you want to dump the carrierid in the > $avp(carrier_id) table; luckily for the flatstore engine the column is > not relevant, as it is nowhere used. > > If you want to get the carrierid and ruleid values in the flatstore, you > have to explicitly set the corresponding tags in your script: > > $acc_extra(carrierid) = $avp(carrier_id); > $acc_extra(ruleid) = $avp(rule_id); > > Make sure to do that after you call do_routing(). > > [1] https://opensips.org/docs/modules/3.1.x/acc.html#ACC-extra-id > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 7/2/20 7:13 PM, Vic Jolin wrote: > > Hello, > > > > I have this for drouting > > loadmodule "drouting.so" > > modparam("drouting", "rule_prefix_avp", '$avp(dr_prefix)') > > modparam("drouting", "carrier_id_avp", '$avp(carrier_id)') > > modparam("drouting", "gw_id_avp", '$avp(gw_id)') > > modparam("drouting", "ruri_avp", '$avp(dr_ruri)') > > modparam("drouting", "gw_priprefix_avp", '$avp(gw_priprefix)') > > modparam("drouting", "rule_id_avp", '$avp(rule_id)') > > > > and for acc > > > > modparam("acc", "extra_fields", "db: callerid->callerid; ani->ani; > > prefix->prefix; src_ip->src_ip; dst_ip->dst_ip; acctid->acctid; > > carrierid->$avp(carrier_id); ruleid->$avp(rule_id)") > > modparam("acc", "db_url", "flatstore:/var/log/acc") > > > > Can anyone tell me why on the flatstore files the carrierid, and ruleid > > is empty? > > > > _______________________________________________ > > 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: From bill.m.barman at gmail.com Wed Jul 15 10:38:12 2020 From: bill.m.barman at gmail.com (Billy Barman) Date: Wed, 15 Jul 2020 11:38:12 +0100 Subject: [OpenSIPS-Users] OpenSIPS legacy repos Message-ID: Hi, Is there an official (or not) repo which contains old RPM builds of OpenSIPS? We have a legacy environment which currently runs on 2.1.5 and I'd rather avoid building from source if possible. Thanks in advance Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From voip.security at protonmail.com Wed Jul 15 22:50:24 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Wed, 15 Jul 2020 22:50:24 +0000 Subject: [OpenSIPS-Users] OpenSIPS legacy repos Message-ID: <1da92c26-6fa4-b6c4-30d6-98446022cf30@protonmail.com> Hi Bill, I don't about the rpm builds but you can access all the OpenSIPS source code packages from here -> https://opensips.org/pub/opensips/ And this is for 2.1.5 https://opensips.org/pub/opensips/2.1.5/ You can compile it and can use it. From spanda at 3clogic.com Thu Jul 16 11:10:15 2020 From: spanda at 3clogic.com (Sasmita Panda) Date: Thu, 16 Jul 2020 16:40:15 +0530 Subject: [OpenSIPS-Users] How to pass a variable in sethostport function . Message-ID: Hi , I have parse a header and saved the value in a variable . something like "$var(y)" has the value "domain.i3clogic.com:5507" . If I am printing this variable then I am getting this value . But when I am trying to pass this in sethostport("$var(y)") . inside this function I am not getting the value of this variable . What should I do for this ? *Thanks & Regards* *Sasmita Panda* *Senior Network Testing and Software Engineer* *3CLogic , ph:07827611765* -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Thu Jul 16 13:03:38 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Thu, 16 Jul 2020 14:03:38 +0100 Subject: [OpenSIPS-Users] Documentation error? Message-ID: Not sure where to report this, so apologies if it's in the wrong place. The tutorial for Web Sockets with 3.0 looks to be wrong when running 3.0.2. Example script is full of obsolete commands, modules and variables - not very helpful. Will this be rectified on release of 3.1 Stable? https://opensips.org/Documentation/Tutorials-WebSocket-3-0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Thu Jul 16 16:08:42 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 16 Jul 2020 19:08:42 +0300 Subject: [OpenSIPS-Users] OpenSIPS Summit 2020 Distributed is set! Message-ID: Bye-Bye Amsterdam, welcome Online – the "OpenSIPS Summit 2020" becomes the "OpenSIPS Summit Distributed 2020", a free, live and interactive online event. 5th - 11th of September - are you ready to join us? https://blog.opensips.org/2020/07/16/opensips-summit-2020-distributed/ See you over the Internet, -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ From opensips at jfive.net Thu Jul 16 17:30:46 2020 From: opensips at jfive.net (James) Date: Thu, 16 Jul 2020 17:30:46 +0000 Subject: [OpenSIPS-Users] Opensips 2.4.8 SEGFAULT In-Reply-To: <2fbe5a654436b58b36ea1115b43b2a8d@jfive.net> References: <2fbe5a654436b58b36ea1115b43b2a8d@jfive.net> <261ee76a64450a126ee27e6085bc10b6@jfive.net> Message-ID: <03d44115cd0ce0540431e2557500013c@jfive.net> I complied opensips 2.4.8 from git and I now have the correct output for my core dump.... I hope! https://pastebin.com/rFbptVrW version: opensips 2.4.8 (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: 1e891b5e3 main.c compiled on 23:02:38 Jul 14 2020 with gcc 8 I am running Centos 8 Thanks, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From sobomax at sippysoft.com Thu Jul 16 23:12:51 2020 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Thu, 16 Jul 2020 16:12:51 -0700 Subject: [OpenSIPS-Users] [OpenSIPS-Devel] OpenSIPS Summit 2020 Distributed is set! In-Reply-To: References: Message-ID: Thumbs up! Let's get distributed. :) -Max On Thu., Jul. 16, 2020, 9:09 a.m. Bogdan-Andrei Iancu, wrote: > > Bye-Bye Amsterdam, welcome Online – the "OpenSIPS Summit 2020" becomes > the "OpenSIPS Summit Distributed 2020", a free, live and interactive > online event. > > 5th - 11th of September - are you ready to join us? > > https://blog.opensips.org/2020/07/16/opensips-summit-2020-distributed/ > > > See you over the Internet, > > -- > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 2020 online > https://www.opensips.org/events/Summit-2020Distributed/ > > > _______________________________________________ > Devel mailing list > Devel at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pasan_5 at yahoo.com Fri Jul 17 02:29:16 2020 From: pasan_5 at yahoo.com (Pasan Meemaduma) Date: Fri, 17 Jul 2020 02:29:16 +0000 (UTC) Subject: [OpenSIPS-Users] ms teams outgoing calls fails References: <1586399170.3000023.1594952956212.ref@mail.yahoo.com> Message-ID: <1586399170.3000023.1594952956212@mail.yahoo.com> Hi Guys, Set up msteams client  <--> msteams sbc <--> opensips <--> asterisk  <--> pstn I recently ran in to an issue with handling outgoing calls to msteams, call fails as msteams unable to send ACK after 200 OK reply. below is the debug log I got from opensips as per logs it seems like opensips unable to accept the connection back from msteams sbc to read ACK. Jul 16 13:55:38 msteams-sbc opensips[28748]: Jul 16 13:55:38 [28764] ERROR:proto_tls:tls_accept: New TLS connection from 52.114.14.70:5248 failed to accept Jul 16 13:55:38 msteams-sbc opensips[28748]: Jul 16 13:55:38 [28764] ERROR:proto_tls:tls_read_req: failed to do pre-tls reading There's no other error other than above. Any clue as to what could be wrong ? incoming calls toward teams works fine. Thanks Regards,Pasan Jul 16 13:55:37 msteams-sbc opensips[28748]: Jul 16 13:55:37 [28763] DBG:tm:insert_timer_unsafe: [2]: 0x7f6b6be7b0b0 (55) Jul 16 13:55:37 msteams-sbc opensips[28748]: Jul 16 13:55:37 [28763] DBG:core:tcp_conn_get: con found in state 0 Jul 16 13:55:37 msteams-sbc opensips[28748]: Jul 16 13:55:37 [28763] DBG:core:tcp_conn_get: tcp connection found (0x7f6b6be79a28), acquiring fd Jul 16 13:55:37 msteams-sbc opensips[28748]: Jul 16 13:55:37 [28763] DBG:core:tcp_conn_get: c= 0x7f6b6be79a28, n=16, Usock=56 Jul 16 13:55:37 msteams-sbc opensips[28748]: Jul 16 13:55:37 [28766] DBG:core:handle_worker: read response= 7f6b6be79a28, 1, fd -1 from 12 (28763) Jul 16 13:55:37 msteams-sbc opensips[28748]: Jul 16 13:55:37 [28763] DBG:core:tcp_conn_get: after receive_fd: c= 0x7f6b6be79a28 n=8 fd=63 Jul 16 13:55:37 msteams-sbc opensips[28748]: Jul 16 13:55:37 [28763] DBG:proto_tls:proto_tls_send: sending via fd 63... Jul 16 13:55:37 msteams-sbc opensips[28748]: Jul 16 13:55:37 [28763] DBG:proto_tls:tls_update_fd: New fd is 63 Jul 16 13:55:37 msteams-sbc opensips[28748]: Jul 16 13:55:37 [28763] DBG:proto_tls:tls_write: write was successful (1113 bytes) Jul 16 13:55:37 msteams-sbc opensips[28748]: Jul 16 13:55:37 [28763] DBG:proto_tls:proto_tls_send: after write: c= 0x7f6b6be79a28 n=1113 fd=63 Jul 16 13:55:37 msteams-sbc opensips[28748]: Jul 16 13:55:37 [28763] DBG:proto_tls:proto_tls_send: buf= Jul 16 13:55:37 msteams-sbc opensips[28748]: SIP/2.0 200 OK Jul 16 13:55:37 msteams-sbc opensips[28748]: Via: SIP/2.0/TLS 52.114.14.70:5061;rport=5888;received=52.114.14.70;branch=z9hG4bK642d4611 Jul 16 13:55:37 msteams-sbc opensips[28748]: Record-Route: Jul 16 13:55:37 msteams-sbc opensips[28748]: Record-Route: Jul 16 13:55:37 msteams-sbc opensips[28748]: From: Pasan Meemaduma;tag=87bcce1e760c4752b396766bedd72f73 Jul 16 13:55:37 msteams-sbc opensips[28748]: To: ;tag=as3b49d4e8 Jul 16 13:55:37 msteams-sbc opensips[28748]: Call-ID: 8696a372ea105ccf99693a5189831870 Jul 16 13:55:37 msteams-sbc opensips[28748]: CSeq: 1 INVITE Jul 16 13:55:37 msteams-sbc opensips[28748]: Server: Asterisk PBX 13.32.0 Jul 16 13:55:37 msteams-sbc opensips[28748]: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Jul 16 13:55:37 msteams-sbc opensips[28748]: Supported: replaces Jul 16 13:55:37 msteams-sbc opensips[28748]: Contact: Jul 16 13:55:37 msteams-sbc opensips[28748]: Content-Type: application/sdp Jul 16 13:55:37 msteams-sbc opensips[28748]: Content-Length: 327 Jul 16 13:55:37 msteams-sbc opensips[28748]: #015 Jul 16 13:55:37 msteams-sbc opensips[28748]: v=0 Jul 16 13:55:37 msteams-sbc opensips[28748]: o=root 1092739735 1092739735 IN IP4 175.103.19.67 Jul 16 13:55:37 msteams-sbc opensips[28748]: s=Asterisk PBX 13.32.0 Jul 16 13:55:37 msteams-sbc opensips[28748]: c=IN IP4 175.103.19.67 Jul 16 13:55:37 msteams-sbc opensips[28748]: t=0 0 Jul 16 13:55:37 msteams-sbc opensips[28748]: m=audio 17398 RTP/SAVP 8 101 Jul 16 13:55:37 msteams-sbc opensips[28748]: a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:qiRc8pQTLEPOxR+Yov731H1YTSgkrDvolTefqIVo Jul 16 13:55:37 msteams-sbc opensips[28748]: a=rtpmap:8 PCMA/8000 Jul 16 13:55:37 msteams-sbc opensips[28748]: a=rtpmap:101 telephone-event/8000 Jul 16 13:55:37 msteams-sbc opensips[28748]: a=fmtp:101 0-16 Jul 16 13:55:37 msteams-sbc opensips[28748]: a=maxptime:150 Jul 16 13:55:37 msteams-sbc opensips[28748]: a=sendrecv Jul 16 13:55:38 msteams-sbc opensips[28748]: Jul 16 13:55:38 [28764] DBG:proto_tls:tls_update_fd: New fd is 64 Jul 16 13:55:38 msteams-sbc opensips[28748]: Jul 16 13:55:38 [28764] DBG:proto_tls:tls_update_fd: New fd is 64 Jul 16 13:55:38 msteams-sbc opensips[28748]: Jul 16 13:55:38 [28764] DBG:proto_tls:tcp_handle_req: We didn't manage to read a full request Jul 16 13:55:38 msteams-sbc opensips[28748]: Jul 16 13:55:38 [28764] DBG:proto_tls:tls_read_req: tls_read_req end Jul 16 13:55:38 msteams-sbc opensips[28748]: Jul 16 13:55:38 [28764] DBG:proto_tls:tls_read_req: Using the per connection buff Jul 16 13:55:38 msteams-sbc opensips[28748]: Jul 16 13:55:38 [28764] DBG:proto_tls:tls_update_fd: New fd is 64 Jul 16 13:55:38 msteams-sbc opensips[28748]: Jul 16 13:55:38 [28764] ERROR:proto_tls:tls_accept: New TLS connection from 52.114.14.70:5249 failed to accept Jul 16 13:55:38 msteams-sbc opensips[28748]: Jul 16 13:55:38 [28764] ERROR:proto_tls:tls_read_req: failed to do pre-tls reading Jul 16 13:55:38 msteams-sbc opensips[28748]: Jul 16 13:55:38 [28764] DBG:core:io_watch_del: [TCP_worker] io_watch_del op on index 5 64 (0x55e1c28b8580, 64, 5, 0x10,0x3) fd_no=10 called          Distinguishing What && How ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From volga629 at networklab.ca Fri Jul 17 02:40:05 2020 From: volga629 at networklab.ca (Slava Bendersky) Date: Thu, 16 Jul 2020 22:40:05 -0400 (EDT) Subject: [OpenSIPS-Users] negative ACK Message-ID: <1825869696.4450.1594953605157.JavaMail.zimbra@skillsearch.ca> Hello Everyone, What possible reason that port portion is ignored here in loose route with ACK method. That latest 3.1-dev Also I wonder if possible maintain aliases domains in database. I set an alias Aliases: wss: gk5ix.doctor.lan:8443 Jul 16 22:37:07 [263361] NOTICE:core:main: config file ok, exiting... Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:parse_to_param: tag=cqbimfskge Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:_parse_to: end of header reached, state=29 Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:_parse_to: display={}, ruri={sip:64050 at gk5ix.doctor.lan:8443} Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:get_hdr_field: [50]; uri=[sip:64050 at gk5ix.doctor.lan:8443] Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:get_hdr_field: to body [] Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:get_hdr_field: cseq : <6492> Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:get_hdr_field: content_length=0 Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:get_hdr_field: found end of header Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:sipmsgops:has_totag: totag found Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:parse_headers: flags=200 Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:rr:is_preloaded: No Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:grep_sock_info_ext: checking if host==us: 16==11 && [gk5ix.doctor.lan] == [10.142.0.15] Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:grep_sock_info_ext: checking if port 5060 matches port 5060 Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:grep_sock_info_ext: checking if host==us: 16==11 && [gk5ix.doctor.lan] == [10.142.0.15] Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:grep_sock_info_ext: checking if port 5060 matches port 5060 Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: WARNING:rr:after_strict: no socket found to match RR [1][gk5ix.doctor.lan:5060] Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:rr:after_strict: Next hop: 'sip:104.196.55.209:8443;transport=wss;lr;ftag=vdi4gq47qa064.90d9c317' is loose rout er Any help thank you. volga629 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexei.vasilyev at gmail.com Fri Jul 17 05:55:09 2020 From: alexei.vasilyev at gmail.com (Alexey Vasilyev) Date: Thu, 16 Jul 2020 22:55:09 -0700 (MST) Subject: [OpenSIPS-Users] ms teams outgoing calls fails In-Reply-To: <1586399170.3000023.1594952956212@mail.yahoo.com> References: <1586399170.3000023.1594952956212@mail.yahoo.com> Message-ID: <1594965309211-0.post@n2.nabble.com> Hi Pasan, This was explained here: http://opensips-open-sip-server.1449251.n2.nabble.com/TLS-handshake-failure-td7619394.html ----- --- Alexey Vasilyev -- Sent from: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html From alexei.vasilyev at gmail.com Fri Jul 17 06:05:58 2020 From: alexei.vasilyev at gmail.com (Alexey Vasilyev) Date: Thu, 16 Jul 2020 23:05:58 -0700 (MST) Subject: [OpenSIPS-Users] SIP to WebRTC via OpenSIPS mid-registrar fails: forced proto 6 not matching sips uri In-Reply-To: References: Message-ID: <1594965958635-0.post@n2.nabble.com> Hi Mark, try this: if (nat_uac_test("123")) { if (is_method("REGISTER")) { fix_nated_register(); } else { fix_nated_contact(); } } ----- --- Alexey Vasilyev -- Sent from: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html From mark at allenclan.co.uk Fri Jul 17 07:19:00 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Fri, 17 Jul 2020 08:19:00 +0100 Subject: [OpenSIPS-Users] SIP to WebRTC via OpenSIPS mid-registrar fails: forced proto 6 not matching sips uri In-Reply-To: <1594965958635-0.post@n2.nabble.com> References: <1594965958635-0.post@n2.nabble.com> Message-ID: Hi Alexey - thanks for responding. I've seen past reports where NAT was causing this type of problem. I tried your suggestion but, along with other tests such as forcing fix_nated_register() or fix_nated_contact() on all messages, and after trying Stas' suggestion, it still doesn't work for me. I believe that I've followed the tutorials correctly but, as per another post of mine, there are issues with the 3.0 tutorial scripts being out of date - so maybe the problem lies somewhere in how I've tried to fix the script errors for 3.0.2? It's very frustrating because I can look at the "location" table in MySQL and see the information being correctly stored, it just appears that for some reason when it looks up and retrieves the information it doesn't recognise that the destination retrieved is a WebSocket and so tries to treat it as a FQDN - or at least that's what it seems to be saying to me. cheers, Mark On Fri, 17 Jul 2020 at 07:07, Alexey Vasilyev wrote: > Hi Mark, > > try this: > > if (nat_uac_test("123")) { > if (is_method("REGISTER")) { > fix_nated_register(); > } else { > fix_nated_contact(); > } > } > > > > ----- > --- > Alexey Vasilyev > -- > Sent from: > http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html > > _______________________________________________ > 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 pasan_5 at yahoo.com Fri Jul 17 07:16:08 2020 From: pasan_5 at yahoo.com (Pasan Meemaduma) Date: Fri, 17 Jul 2020 07:16:08 +0000 (UTC) Subject: [OpenSIPS-Users] ms teams outgoing calls fails In-Reply-To: <1594965309211-0.post@n2.nabble.com> References: <1586399170.3000023.1594952956212@mail.yahoo.com> <1594965309211-0.post@n2.nabble.com> Message-ID: <1849041925.3057651.1594970168953@mail.yahoo.com> Hi Alexey, Thanks for the prompt reply. your are a legend as always :). Sorry for not digging into old emails. The searches I did, didn't come with above posts. Thank you again. Regards,Pasan            Distinguishing What && How ! On Friday, 17 July 2020, 11:27:16 am GMT+5:30, Alexey Vasilyev wrote: Hi Pasan, This was explained here: http://opensips-open-sip-server.1449251.n2.nabble.com/TLS-handshake-failure-td7619394.html ----- --- Alexey Vasilyev -- Sent from: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html _______________________________________________ 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 Fri Jul 17 10:40:05 2020 From: xaled at web.de (xaled at web.de) Date: Fri, 17 Jul 2020 12:40:05 +0200 Subject: [OpenSIPS-Users] Segfault bei TLS certificates in MySQL DB Message-ID: <057901d65c26$a2a8c350$e7fa49f0$@web.de> Hi, I got server and client tls config working in opensips.cfg and now trying to get it running with mysql DB. I tried to use the latest opensips-cp (I know that 3.1 is not officially supported) to import client certificate data that I created using opensips-cli and getting a segfault. I can see the imported certificate using MySQL cli. Maybe I should try importing client cert from cli? What would be the correct way to import certificate in to OpenSIPS mysql table from linux shell? 9 02:29:30 test /usr/sbin/opensips[8551]: INFO:tls_mgm:init_tls_dom: Processing TLS domain 'test-cli' Jul 9 02:29:30 test /usr/sbin/opensips[8551]: DBG:tls_mgm:init_tls_dom: no DH params file for tls domain 'test-cli' defined, using default '(null)' Jul 9 02:29:30 test /usr/sbin/opensips[8551]: NOTICE:tls_mgm:init_tls_dom: No EC curve defined Jul 9 02:29:30 test /usr/sbin/opensips[8551]: DBG:tls_mgm:init_tls_dom: cipher list null ... setting default Jul 9 02:29:30 test /usr/sbin/opensips[8551]: INFO:tls_mgm:get_ssl_ctx_verify_mode: server verification activated. Jul 9 02:29:30 test /usr/sbin/opensips[8551]: NOTICE:tls_mgm:init_tls_dom: no CA dir for tls 'test-cli' defined, using default '/etc/pki/CA/' Jul 9 02:29:30 test /usr/sbin/opensips[8551]: NOTICE:tls_mgm:init_tls_dom: no crl for tls, using none Jul 9 02:29:30 test /usr/sbin/opensips[8551]: DBG:core:count_module_procs: modules require 2 extra processes Jul 9 02:29:30 test /usr/sbin/opensips[8551]: CRITICAL:core:sig_usr: segfault in attendant (starter) process! Thanks, Xaled -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Fri Jul 17 11:18:32 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Fri, 17 Jul 2020 14:18:32 +0300 Subject: [OpenSIPS-Users] Documentation error? In-Reply-To: References: Message-ID: Hi, Mark! Actually that's just a dangling page, generated by our scripts for "creating" a new version. Did you get to that page through a link or something? As the Index page[1] doesn't reference it. TBH we weren't planning of updating the tutorial, since nothing major has changed, there are only some syntactic changes (according to my analysis). I do agree an updated version would be better, but due to lack of resources, this hasn't reached our priority list. Nevertheless, that is a wiki page, and any contribution is more than welcome. [1] https://www.opensips.org/Documentation/Tutorials#toc9 Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 7/16/20 4:03 PM, Mark Allen wrote: > Not sure where to report this, so apologies if it's in the wrong place. > > The tutorial for Web Sockets with 3.0 looks to be wrong when running > 3.0.2. Example script is full of obsolete commands, modules and > variables - not very helpful. Will this be rectified on release of 3.1 > Stable? > > https://opensips.org/Documentation/Tutorials-WebSocket-3-0 > > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From volga629 at networklab.ca Fri Jul 17 12:43:02 2020 From: volga629 at networklab.ca (Slava Bendersky) Date: Fri, 17 Jul 2020 08:43:02 -0400 (EDT) Subject: [OpenSIPS-Users] negative ACK In-Reply-To: References: <1825869696.4450.1594953605157.JavaMail.zimbra@skillsearch.ca> Message-ID: <1616917633.5166.1594989782830.JavaMail.zimbra@skillsearch.ca> Hello Johan, That google cloud but I am suspect some sort of NAT problem. I can register and place call, but loose route causing some routing issue. volga629 From: "johan" To: "volga629" Sent: Friday, July 17, 2020 4:21:47 AM Subject: Fwd: [OpenSIPS-Users] negative ACK Is there a reason why you don't use a normal listener ? And please run netstat -tulpn as I believe that port 8443 is closed. wkr, -------- Forwarded Message -------- Subject: [OpenSIPS-Users] negative ACK Date: Thu, 16 Jul 2020 22:40:05 -0400 (EDT) From: Slava Bendersky via Users [ mailto:users at lists.opensips.org | ] Reply-To: Slava Bendersky [ mailto:volga629 at networklab.ca | ] , OpenSIPS users mailling list [ mailto:users at lists.opensips.org | ] To: OpenSIPS users mailling list [ mailto:users at lists.opensips.org | ] Hello Everyone, What possible reason that port portion is ignored here in loose route with ACK method. That latest 3.1-dev Also I wonder if possible maintain aliases domains in database. I set an alias Aliases: wss: gk5ix.doctor.lan:8443 Jul 16 22:37:07 [263361] NOTICE:core:main: config file ok, exiting... Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:parse_to_param: tag=cqbimfskge Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:_parse_to: end of header reached, state=29 Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:_parse_to: display={}, ruri={ sip:64050 at gk5ix.doctor.lan:8443} Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:get_hdr_field: [50]; uri=[sip:64050 at gk5ix.doctor.lan:8443] Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:get_hdr_field: to body [] Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:get_hdr_field: cseq : <6492> Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:get_hdr_field: content_length=0 Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:get_hdr_field: found end of header Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:sipmsgops:has_totag: totag found Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:parse_headers: flags=200 Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:rr:is_preloaded: No Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:grep_sock_info_ext: checking if host==us: 16==11 && [gk5ix.doctor.lan] == [10.142.0.15] Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:grep_sock_info_ext: checking if port 5060 matches port 5060 Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:grep_sock_info_ext: checking if host==us: 16==11 && [gk5ix.doctor.lan] == [10.142.0.15] Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:core:grep_sock_info_ext: checking if port 5060 matches port 5060 Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: WARNING:rr:after_strict: no socket found to match RR [1][gk5ix.doctor.lan:5060] Jul 16 22:22:45 dev1-opensips /usr/sbin/opensips[263213]: DBG:rr:after_strict: Next hop: 'sip:104.196.55.209:8443;transport=wss;lr;ftag=vdi4gq47qa064.90d9c317' is loose rout er Any help thank you. volga629 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Fri Jul 17 12:55:48 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Fri, 17 Jul 2020 13:55:48 +0100 Subject: [OpenSIPS-Users] Documentation error? In-Reply-To: References: Message-ID: Hi Răzvan - thanks for that info. >From memory, I believe that I tried using the sample script and got errors so then went to see if I could find a version of the tutorial for 3.0. As for updating the wiki, I'm still finding my way around OpenSIPS and haven't got it working properly yet. However, once I'm up to speed, if I get a chance I'll suggest an update. Cheers, Mark On Fri, 17 Jul 2020 at 12:21, Răzvan Crainea wrote: > Hi, Mark! > > Actually that's just a dangling page, generated by our scripts for > "creating" a new version. Did you get to that page through a link or > something? As the Index page[1] doesn't reference it. > TBH we weren't planning of updating the tutorial, since nothing major > has changed, there are only some syntactic changes (according to my > analysis). I do agree an updated version would be better, but due to > lack of resources, this hasn't reached our priority list. > Nevertheless, that is a wiki page, and any contribution is more than > welcome. > > [1] https://www.opensips.org/Documentation/Tutorials#toc9 > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 7/16/20 4:03 PM, Mark Allen wrote: > > Not sure where to report this, so apologies if it's in the wrong place. > > > > The tutorial for Web Sockets with 3.0 looks to be wrong when running > > 3.0.2. Example script is full of obsolete commands, modules and > > variables - not very helpful. Will this be rectified on release of 3.1 > > Stable? > > > > https://opensips.org/Documentation/Tutorials-WebSocket-3-0 > > > > > > > > _______________________________________________ > > 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: From farmorg at gmail.com Fri Jul 17 13:39:31 2020 From: farmorg at gmail.com (Mark Farmer) Date: Fri, 17 Jul 2020 14:39:31 +0100 Subject: [OpenSIPS-Users] Dynamic Routing Stats Message-ID: Hi everyone I have been asked to look into getting Nagios to monitor active calls on specific Dynamic Routing gateways. Looking at the drouting() docs I don't see any exported statistics. Is there a way to do this please? Many thanks Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From solarmon at one-n.co.uk Fri Jul 17 15:49:19 2020 From: solarmon at one-n.co.uk (solarmon) Date: Fri, 17 Jul 2020 16:49:19 +0100 Subject: [OpenSIPS-Users] siptrace - dual HEP destinations Message-ID: Hi, I was able to get siptrace sent to a single HEP server. Now I would like to be able to send to a secondary server as an additional destination. I thought I could just create additional hep_id and trace_id entries and run sip_trace() twice, but this didn't work and only the second HEP server received traffic. The config I used for proto_hep was: loadmodule "proto_hep.so" modparam("proto_hep", "hep_id", "[homer]:9060;transport=tcp;version=3;") modparam("proto_hep", "hep_id", "[homer2]:9060;transport=tcp;version=3;") The config I used for siptrace was: loadmodule "siptrace.so" modparam("siptrace", "trace_on", 1) modparam("siptrace", "trace_id", "[traceid]uri=hep:homer") modparam("siptrace", "trace_id", "[traceid2]uri=hep:homer2") And the sip_trace() call used were: sip_trace("traceid","T","sip"); # stateful mode - in/out transaction sip_trace("traceid2","T","sip"); # stateful mode - in/out transaction It is possible/probable that I have a misundertanding of how these variables/tokens in the brackets work. Please can somebody provide, or point me to, an example of how this multiple HEP server destinations could be achieved, assuming it can be done Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrsanvicente at gmail.com Fri Jul 17 19:18:16 2020 From: mrsanvicente at gmail.com (Mario San Vicente) Date: Fri, 17 Jul 2020 14:18:16 -0500 Subject: [OpenSIPS-Users] rtpengine aborting loop when reinvite is sent Message-ID: Hello Everyone, I have a scenario, where opensips is working with rtpengine . Call connects fine with audio. I have enabled reinvite pinging to keep the call alive ; when the reinvite is sent to both legs of the calls i get error messages and NO AUDIO. The reinvite has full SPD body. some config related: modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:2123") modparam("dialog", "reinvite_ping_interval", 60) record_route(); create_dialog("rR"); intermitent LOGS, until server is reboot: rtpengine[21823]: ERR: Too many packets in UDP receive queue (more than 50), aborting loop. Dropped packets possible rtpengine[21823]: WARNING: More than 30 duplicate packets detected, dropping packet to avoid potential loop Any idea what might be wrong? thanks you in advance! -- Mario San Vicente Cheers! -------------- next part -------------- An HTML attachment was scrubbed... URL: From abalashov at evaristesys.com Fri Jul 17 19:32:03 2020 From: abalashov at evaristesys.com (Alex Balashov) Date: Fri, 17 Jul 2020 15:32:03 -0400 Subject: [OpenSIPS-Users] rtpengine aborting loop when reinvite is sent In-Reply-To: References: Message-ID: This happens when an SDP body that has already been passed to RTPEngine, and already adulterated by RTPEngine, is passed to it yet again. Newer versions of RTPEngine have a loop protection feature to deal with it. It involves injecting an unregistered a=rtpengine attribute into the SDP, to say “I was already here”. Most common cause on in-dialog requests (e.g. reinvites) is that next hop is set to proxy itself due to RFC 2543 endpoint behaviour. So, the proxy forwards the reinvite to itself and, unsurprisingly, invokes RTPEngine again. Many times this can be fixed on the endpoint. — Sent from mobile, with due apologies for brevity and errors. > On Jul 17, 2020, at 3:19 PM, Mario San Vicente wrote: > >  > Hello Everyone, > > I have a scenario, where opensips is working with rtpengine . Call connects fine with audio. > > I have enabled reinvite pinging to keep the call alive ; when the reinvite is sent to both legs of the calls i get error messages and NO AUDIO. The reinvite has full SPD body. > > some config related: > > modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:2123") > modparam("dialog", "reinvite_ping_interval", 60) > record_route(); > create_dialog("rR"); > > intermitent LOGS, until server is reboot: > > rtpengine[21823]: ERR: Too many packets in UDP receive queue (more than 50), aborting loop. Dropped packets possible > rtpengine[21823]: WARNING: More than 30 duplicate packets detected, dropping packet to avoid potential loop > > Any idea what might be wrong? > > thanks you in advance! > > -- > Mario San Vicente > Cheers! > _______________________________________________ > 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 mrsanvicente at gmail.com Fri Jul 17 21:06:51 2020 From: mrsanvicente at gmail.com (Mario San Vicente) Date: Fri, 17 Jul 2020 16:06:51 -0500 Subject: [OpenSIPS-Users] rtpengine aborting loop when reinvite is sent In-Reply-To: References: Message-ID: Thanks for your explanation Alex, Actually i compiled the latest..git clone https://github.com/sipwise/rtpengine.git But still i dont have a clue on how to solve it, any advise? Thank you Mario On Fri, Jul 17, 2020 at 2:34 PM Alex Balashov wrote: > This happens when an SDP body that has already been passed to RTPEngine, > and already adulterated by RTPEngine, is passed to it yet again. > > Newer versions of RTPEngine have a loop protection feature to deal with > it. It involves injecting an unregistered a=rtpengine attribute into the > SDP, to say “I was already here”. > > Most common cause on in-dialog requests (e.g. reinvites) is that next hop > is set to proxy itself due to RFC 2543 endpoint behaviour. So, the proxy > forwards the reinvite to itself and, unsurprisingly, invokes RTPEngine > again. Many times this can be fixed on the endpoint. > > — > Sent from mobile, with due apologies for brevity and errors. > > On Jul 17, 2020, at 3:19 PM, Mario San Vicente > wrote: > >  > Hello Everyone, > > I have a scenario, where opensips is working with rtpengine . Call > connects fine with audio. > > I have enabled reinvite pinging to keep the call alive ; when the reinvite > is sent to both legs of the calls i get error messages and NO AUDIO. The > reinvite has full SPD body. > > some config related: > > modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:2123") > modparam("dialog", "reinvite_ping_interval", 60) > record_route(); > create_dialog("rR"); > > intermitent LOGS, until server is reboot: > > rtpengine[21823]: ERR: Too many packets in UDP receive queue (more than > 50), aborting loop. Dropped packets possible > rtpengine[21823]: WARNING: More than 30 duplicate packets detected, > dropping packet to avoid potential loop > > Any idea what might be wrong? > > thanks you in advance! > > -- > Mario San Vicente > Cheers! > _______________________________________________ > 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 > -- Mario San Vicente Cheers! -------------- next part -------------- An HTML attachment was scrubbed... URL: From abalashov at evaristesys.com Fri Jul 17 21:11:37 2020 From: abalashov at evaristesys.com (Alex Balashov) Date: Fri, 17 Jul 2020 17:11:37 -0400 Subject: [OpenSIPS-Users] rtpengine aborting loop when reinvite is sent In-Reply-To: References: Message-ID: I think one angle on the problem is to identify why RTPEngine is being invoked twice for the same SDP (most likely the same SIP message). That's best done by looking at the content of the reinvite itself. Focus especially on the Request URI and the Route header. I am not sure if the RTPEngine control module in OpenSIPS supports the loop-protect option, or whether specific module support for any command is required in order to use it. -- Alex On 7/17/20 5:06 PM, Mario San Vicente wrote: > Thanks for your explanation Alex, > > Actually i compiled the latest..git clone > https://github.com/sipwise/rtpengine.git > > But still i dont have a clue on how to solve it, any advise? > > Thank you > Mario > > On Fri, Jul 17, 2020 at 2:34 PM Alex Balashov > wrote: > > This happens when an SDP body that has already been passed to > RTPEngine, and already adulterated by RTPEngine, is passed to it yet > again. > > Newer versions of RTPEngine have a loop protection feature to deal > with it. It involves injecting an unregistered a=rtpengine attribute > into the SDP, to say “I was already here”. > > Most common cause on in-dialog requests (e.g. reinvites) is that > next hop is set to proxy itself due to RFC 2543 endpoint behaviour. > So, the proxy forwards the reinvite to itself and, unsurprisingly, > invokes RTPEngine again. Many times this can be fixed on the endpoint. > > — > Sent from mobile, with due apologies for brevity and errors. > >> On Jul 17, 2020, at 3:19 PM, Mario San Vicente >> > wrote: >> >>  >> Hello Everyone, >> >> I have a scenario, where opensips is working with rtpengine . Call >> connects fine with audio. >> >> I have enabled reinvite pinging to keep the call alive ; when the >> reinvite is sent to both legs of the calls i get  error messages >> and NO AUDIO.  The reinvite has full SPD body. >> >> some config related: >> >> modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:2123 >> ") >> modparam("dialog", "reinvite_ping_interval", 60) >> record_route(); >>  create_dialog("rR"); >> >> intermitent LOGS, until server is reboot: >> >>  rtpengine[21823]: ERR: Too many packets in UDP receive queue >> (more than 50), aborting loop. Dropped packets possible >>  rtpengine[21823]: WARNING: More than 30 duplicate packets >> detected, dropping packet to avoid potential loop >> >> Any idea what might be wrong? >> >> thanks you in advance! >> >> -- >> Mario San Vicente >> Cheers! >> _______________________________________________ >> 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 > > > > -- > Mario San Vicente > Cheers! > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ From mrsanvicente at gmail.com Sat Jul 18 04:17:13 2020 From: mrsanvicente at gmail.com (Mario San Vicente) Date: Fri, 17 Jul 2020 23:17:13 -0500 Subject: [OpenSIPS-Users] rtpengine aborting loop when reinvite is sent In-Reply-To: References: Message-ID: Hello Alex, I tried the flag loop-protect and it works. I get the following message on the logs: rtpengine[22968]: INFO: [fd72c95927567a5b]: Ignoring message as SDP has already been processed by us Thanks for your inputs! Regards On Fri, Jul 17, 2020 at 4:15 PM Alex Balashov wrote: > I think one angle on the problem is to identify why RTPEngine is being > invoked twice for the same SDP (most likely the same SIP message). > That's best done by looking at the content of the reinvite itself. Focus > especially on the Request URI and the Route header. > > I am not sure if the RTPEngine control module in OpenSIPS supports the > loop-protect option, or whether specific module support for any command > is required in order to use it. > > -- Alex > > On 7/17/20 5:06 PM, Mario San Vicente wrote: > > Thanks for your explanation Alex, > > > > Actually i compiled the latest..git clone > > https://github.com/sipwise/rtpengine.git > > > > But still i dont have a clue on how to solve it, any advise? > > > > Thank you > > Mario > > > > On Fri, Jul 17, 2020 at 2:34 PM Alex Balashov > > wrote: > > > > This happens when an SDP body that has already been passed to > > RTPEngine, and already adulterated by RTPEngine, is passed to it yet > > again. > > > > Newer versions of RTPEngine have a loop protection feature to deal > > with it. It involves injecting an unregistered a=rtpengine attribute > > into the SDP, to say “I was already here”. > > > > Most common cause on in-dialog requests (e.g. reinvites) is that > > next hop is set to proxy itself due to RFC 2543 endpoint behaviour. > > So, the proxy forwards the reinvite to itself and, unsurprisingly, > > invokes RTPEngine again. Many times this can be fixed on the > endpoint. > > > > — > > Sent from mobile, with due apologies for brevity and errors. > > > >> On Jul 17, 2020, at 3:19 PM, Mario San Vicente > >> > wrote: > >> > >>  > >> Hello Everyone, > >> > >> I have a scenario, where opensips is working with rtpengine . Call > >> connects fine with audio. > >> > >> I have enabled reinvite pinging to keep the call alive ; when the > >> reinvite is sent to both legs of the calls i get error messages > >> and NO AUDIO. The reinvite has full SPD body. > >> > >> some config related: > >> > >> modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:2123 > >> ") > >> modparam("dialog", "reinvite_ping_interval", 60) > >> record_route(); > >> create_dialog("rR"); > >> > >> intermitent LOGS, until server is reboot: > >> > >> rtpengine[21823]: ERR: Too many packets in UDP receive queue > >> (more than 50), aborting loop. Dropped packets possible > >> rtpengine[21823]: WARNING: More than 30 duplicate packets > >> detected, dropping packet to avoid potential loop > >> > >> Any idea what might be wrong? > >> > >> thanks you in advance! > >> > >> -- > >> Mario San Vicente > >> Cheers! > >> _______________________________________________ > >> 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 > > > > > > > > -- > > Mario San Vicente > > Cheers! > > > > _______________________________________________ > > Users mailing list > > Users at lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > -- > Alex Balashov | Principal | Evariste Systems LLC > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Mario San Vicente Cheers! -------------- next part -------------- An HTML attachment was scrubbed... URL: From sobomax at sippysoft.com Sat Jul 18 04:46:18 2020 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Fri, 17 Jul 2020 21:46:18 -0700 Subject: [OpenSIPS-Users] SIP Chronicles #7, Featuring Ken Rice Message-ID: Hey, OpenSource folks this is just a friendly reminder. If you liked any of our first 6 episodes of SIP Chronicles, please consider putting some time aside this Saturday at 4:30 UTC to see Ken Rice talking about FreeSWITCH, OpenSIPS and other projects that he is working on. https://youtu.be/176gzKQOoSQ See you soon! -Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From rembgrets at gmail.com Sun Jul 19 10:32:41 2020 From: rembgrets at gmail.com (ryan embgrets) Date: Sun, 19 Jul 2020 15:32:41 +0500 Subject: [OpenSIPS-Users] Userblacklist module with mongodb Message-ID: Greeting, I am just wondering if someone has been using mongodb for the user blacklist module or even if it is compatible with mongo? I have below configurations, loadmodule "db_cachedb.so" loadmodule "cachedb_mongodb.so" modparam("db_cachedb","cachedb_url","mongodb:globalblacklist://opensips:opensipsrw at localhost /opensips.globalblacklist") loadmodule "userblacklist.so" modparam("userblacklist", "db_url", "cachedb://mongodb:globalblacklist") But it does not seem to work, and gives below error ERROR:userblacklist:db_reload_source: got invalid result type from query. Any suggestions? Ryan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From solarmon at one-n.co.uk Mon Jul 20 08:52:11 2020 From: solarmon at one-n.co.uk (solarmon) Date: Mon, 20 Jul 2020 09:52:11 +0100 Subject: [OpenSIPS-Users] siptrace - dual HEP destinations In-Reply-To: References: Message-ID: Hi, So I RTFM'd on the siptrace module ( https://opensips.org/html/docs/modules/2.4.x/siptrace) and realised that I had to use the key pair format to define multiple destinations. So now my config is: loadmodule "proto_hep.so" modparam("proto_hep", "hep_id", "[homer_1]:9060;transport=udp;version=3;") modparam("proto_hep", "hep_id", "[homer_2]:9060;transport=udp;version=3;") loadmodule "siptrace.so" modparam("siptrace", "trace_on", 1) modparam("siptrace", "trace_id", "[traceid]uri=hep:homer_1;uri=homer_2") And the sip_trace() call used is: sip_trace("traceid","T","sip"); # stateful mode - in/out transaction However, it seems that the HEP traffic is only ever sent to the second/last uri defined. I can swap the uri's and the HEP traffic will only ever go to the second/last uri defined. So I know that HEP traffic can get each to the destinations - in terms of routing and access control. Why is siptrace not sending to both HEP destinations at the same time? On Fri, 17 Jul 2020 at 16:49, solarmon wrote: > Hi, > > I was able to get siptrace sent to a single HEP server. Now I would like > to be able to send to a secondary server as an additional destination. > > I thought I could just create additional hep_id and trace_id entries and > run sip_trace() twice, but this didn't work and only the second HEP server > received traffic. > > The config I used for proto_hep was: > > loadmodule "proto_hep.so" > modparam("proto_hep", "hep_id", "[homer] #1>:9060;transport=tcp;version=3;") > modparam("proto_hep", "hep_id", "[homer2] #2>:9060;transport=tcp;version=3;") > > The config I used for siptrace was: > > loadmodule "siptrace.so" > modparam("siptrace", "trace_on", 1) > modparam("siptrace", "trace_id", "[traceid]uri=hep:homer") > modparam("siptrace", "trace_id", "[traceid2]uri=hep:homer2") > > And the sip_trace() call used were: > > sip_trace("traceid","T","sip"); # stateful mode - in/out > transaction > sip_trace("traceid2","T","sip"); # stateful mode - in/out > transaction > > It is possible/probable that I have a misundertanding of how these > variables/tokens in the brackets work. > > Please can somebody provide, or point me to, an example of how this > multiple HEP server destinations could be achieved, assuming it can be done > > > Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From solarmon at one-n.co.uk Mon Jul 20 09:25:32 2020 From: solarmon at one-n.co.uk (solarmon) Date: Mon, 20 Jul 2020 10:25:32 +0100 Subject: [OpenSIPS-Users] siptrace - dual HEP destinations In-Reply-To: References: Message-ID: Hi, I think I have resolved the issue. I reverted my config slightly to having multiple trace_id entries: loadmodule "proto_hep.so" modparam("proto_hep", "hep_id", "[homer_1]:9060;transport=udp;version=3;") modparam("proto_hep", "hep_id", "[homer_2]:9060;transport=udp;version=3;") loadmodule "siptrace.so" modparam("siptrace", "trace_on", 1) modparam("siptrace", "trace_id", "[traceid]uri=hep:homer_1") modparam("siptrace", "trace_id", "[traceid]uri=hep:homer_2") And the sip_trace() call used is: sip_trace("traceid","T","sip"); # stateful mode - in/out transaction With this configuration, the HEP traffic is sent to both destinations! I think the difference compared to my OP was that I was using TCP for the first hep_id Homer server - even though the OP showed I had it for both, my actual config only had TCP for the first entry. A previous mailing list email (and subsequent github ticket) from me about getting Homer 7 to work resulted in showing that it was only worked with UDP, and not with TCP. On Mon, 20 Jul 2020 at 09:52, solarmon wrote: > Hi, > > So I RTFM'd on the siptrace module ( > https://opensips.org/html/docs/modules/2.4.x/siptrace) and realised that > I had to use the key pair format to define multiple destinations. > > So now my config is: > > > loadmodule "proto_hep.so" > modparam("proto_hep", "hep_id", "[homer_1] #1>:9060;transport=udp;version=3;") > modparam("proto_hep", "hep_id", "[homer_2] #2>:9060;transport=udp;version=3;") > > loadmodule "siptrace.so" > modparam("siptrace", "trace_on", 1) > modparam("siptrace", "trace_id", "[traceid]uri=hep:homer_1;uri=homer_2") > > And the sip_trace() call used is: > > sip_trace("traceid","T","sip"); # stateful mode - in/out > transaction > > > However, it seems that the HEP traffic is only ever sent to the > second/last uri defined. I can swap the uri's and the HEP traffic will only > ever go to the second/last uri defined. > > So I know that HEP traffic can get each to the destinations - in terms of > routing and access control. > > Why is siptrace not sending to both HEP destinations at the same time? > > On Fri, 17 Jul 2020 at 16:49, solarmon wrote: > >> Hi, >> >> I was able to get siptrace sent to a single HEP server. Now I would like >> to be able to send to a secondary server as an additional destination. >> >> I thought I could just create additional hep_id and trace_id entries and >> run sip_trace() twice, but this didn't work and only the second HEP server >> received traffic. >> >> The config I used for proto_hep was: >> >> loadmodule "proto_hep.so" >> modparam("proto_hep", "hep_id", "[homer]> #1>:9060;transport=tcp;version=3;") >> modparam("proto_hep", "hep_id", "[homer2]> #2>:9060;transport=tcp;version=3;") >> >> The config I used for siptrace was: >> >> loadmodule "siptrace.so" >> modparam("siptrace", "trace_on", 1) >> modparam("siptrace", "trace_id", "[traceid]uri=hep:homer") >> modparam("siptrace", "trace_id", "[traceid2]uri=hep:homer2") >> >> And the sip_trace() call used were: >> >> sip_trace("traceid","T","sip"); # stateful mode - in/out >> transaction >> sip_trace("traceid2","T","sip"); # stateful mode - in/out >> transaction >> >> It is possible/probable that I have a misundertanding of how these >> variables/tokens in the brackets work. >> >> Please can somebody provide, or point me to, an example of how this >> multiple HEP server destinations could be achieved, assuming it can be done >> >> >> Thank you. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Mon Jul 20 10:43:05 2020 From: spanda at 3clogic.com (Sasmita Panda) Date: Mon, 20 Jul 2020 16:13:05 +0530 Subject: [OpenSIPS-Users] How to pass a variable in sethostport function . In-Reply-To: References: Message-ID: Any help on this . *Thanks & Regards* *Sasmita Panda* *Senior Network Testing and Software Engineer* *3CLogic , ph:07827611765* On Thu, Jul 16, 2020 at 4:40 PM Sasmita Panda wrote: > Hi , > > I have parse a header and saved the value in a variable . > something like "$var(y)" has the value "domain.i3clogic.com:5507" . > > If I am printing this variable then I am getting this value . But when I > am trying to pass this in sethostport("$var(y)") . inside this function I > am not getting the value of this variable . > > What should I do for this ? > > *Thanks & Regards* > *Sasmita Panda* > *Senior Network Testing and Software Engineer* > *3CLogic , ph:07827611765* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Mon Jul 20 10:52:45 2020 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 20 Jul 2020 13:52:45 +0300 Subject: [OpenSIPS-Users] How to pass a variable in sethostport function . In-Reply-To: References: Message-ID: <6b9d3940-0ecb-81f7-02a3-c033eb79474e@opensips.org> On 20.07.2020 13:43, Sasmita Panda wrote: > Any help on this . > > > */Thanks & Regards/* > /Sasmita Panda/ > /Senior Network Testing and Software Engineer/ > /3CLogic , ph:07827611765/ > > > On Thu, Jul 16, 2020 at 4:40 PM Sasmita Panda > wrote: > > Hi , > > I have parse a header and saved the value in a variable . > something like "$var(y)" has the value  "domain.i3clogic.com:5507 > " . > Hi, What OpenSIPS are you using?  I don't think this will work with 3.0 or under, if I remember correctly.  If you want to call sethostport($var(y)), you must upgrade to 3.1. Regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Mon Jul 20 10:56:58 2020 From: spanda at 3clogic.com (Sasmita Panda) Date: Mon, 20 Jul 2020 16:26:58 +0530 Subject: [OpenSIPS-Users] How to pass a variable in sethostport function . In-Reply-To: <6b9d3940-0ecb-81f7-02a3-c033eb79474e@opensips.org> References: <6b9d3940-0ecb-81f7-02a3-c033eb79474e@opensips.org> Message-ID: I am using opensips-2.2 . If it wont take any variable that means this function will take only fix value which must be a "domain:port "or "IP:port " . Am I right ? Is there any way I can fill this dynamically while processing the INVITE ? *Thanks & Regards* *Sasmita Panda* *Senior Network Testing and Software Engineer* *3CLogic , ph:07827611765* On Mon, Jul 20, 2020 at 4:22 PM Liviu Chircu wrote: > On 20.07.2020 13:43, Sasmita Panda wrote: > > Any help on this . > > > *Thanks & Regards* > *Sasmita Panda* > *Senior Network Testing and Software Engineer* > *3CLogic , ph:07827611765* > > > On Thu, Jul 16, 2020 at 4:40 PM Sasmita Panda wrote: > >> Hi , >> >> I have parse a header and saved the value in a variable . >> something like "$var(y)" has the value "domain.i3clogic.com:5507" . >> > Hi, > > What OpenSIPS are you using? I don't think this will work with 3.0 or > under, if I remember correctly. If you want to call sethostport($var(y)), > you must upgrade to 3.1. > > Regards, > > -- > Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Mon Jul 20 10:59:50 2020 From: liviu at opensips.org (Liviu Chircu) Date: Mon, 20 Jul 2020 13:59:50 +0300 Subject: [OpenSIPS-Users] How to pass a variable in sethostport function . In-Reply-To: References: <6b9d3940-0ecb-81f7-02a3-c033eb79474e@opensips.org> Message-ID: <36f03aa5-0935-94c9-95cf-d1a0d9292a51@opensips.org> On 20.07.2020 13:56, Sasmita Panda wrote: > I am using opensips-2.2 . If it wont take any variable that means this > function will take only fix value which must be a "domain:port "or > "IP:port " . Am I right ? Yes. > > Is there any way I can fill this dynamically while processing the INVITE ? Try to use the "$rd" [1] and "$rp" [2] variables.  You should be able to obtain the same effect. Cheers, [1]: https://opensips.org/Documentation/Script-CoreVar-3-2#toc69 [2]: https://opensips.org/Documentation/Script-CoreVar-3-2#toc74 -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com From kurgan-rus at inbox.ru Tue Jul 21 06:54:45 2020 From: kurgan-rus at inbox.ru (=?UTF-8?B?QWxleGV5IEthemFudHNldg==?=) Date: Tue, 21 Jul 2020 09:54:45 +0300 Subject: [OpenSIPS-Users] =?utf-8?q?Opensips_=26_media_server?= In-Reply-To: <1AFBBDF5-6DCF-4EF4-984E-2348FBEEE1B6@stratusvideo.com> References: <5e4ca211-dbef-ada8-b19b-ce4bc56bd69c@opensips.org> <1AFBBDF5-6DCF-4EF4-984E-2348FBEEE1B6@stratusvideo.com> Message-ID: <1595314485.957809889@f401.i.mail.ru> Hello, So what is the question? -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Tue Jul 21 08:23:37 2020 From: callum.guy at x-on.co.uk (Callum Guy) Date: Tue, 21 Jul 2020 09:23:37 +0100 Subject: [OpenSIPS-Users] Opensips & media server In-Reply-To: <1595314485.957809889@f401.i.mail.ru> References: <5e4ca211-dbef-ada8-b19b-ce4bc56bd69c@opensips.org> <1AFBBDF5-6DCF-4EF4-984E-2348FBEEE1B6@stratusvideo.com> <1595314485.957809889@f401.i.mail.ru> Message-ID: It is not questions I seek, but answers to the great mystery. On Tue, 21 Jul 2020 at 07:57, Alexey Kazantsev via Users < users at lists.opensips.org> wrote: > Hello, > So what is the question? > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- *0333 332 0000  |  x-on.co.uk   |   **      **  |  Coronavirus * THE ITSPA AWARDS 2020 AND Best ITSP - Mid Market, Best Software and Best Vertical Solution are trade marks of the Internet Telephony Services Providers' Association, used under licence. X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnkiniston at gmail.com Tue Jul 21 19:34:28 2020 From: johnkiniston at gmail.com (John Kiniston) Date: Tue, 21 Jul 2020 12:34:28 -0700 Subject: [OpenSIPS-Users] do_routing not populating variables Message-ID: Running 2.4 I'm not sure if I'm calling do_routing right, I'm using it in a test. if(!do_routing("1","","","$avp(rule_attrs_pvar)","$avp(gw_attrs_pvar)","$avp(carrier_attrs_pvar)")){ I log what I get back but nothing is populated. xlog("L_INFO"," return codes $avp(rule_attrs_pvar) $avp(gw_attrs_pvar) $avp(carrier_attrs_pvar)"); -- A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects. ---Heinlein -------------- next part -------------- An HTML attachment was scrubbed... URL: From y.kirsanov at gmail.com Wed Jul 22 05:13:14 2020 From: y.kirsanov at gmail.com (Yury Kirsanov) Date: Wed, 22 Jul 2020 15:13:14 +1000 Subject: [OpenSIPS-Users] Periodic updates route Message-ID: Hi, Is there a way to execute some routing block during an established call? For example, I define some route on initial INVITE, set time of refresh for it and then every XXX seconds that route is executed only for that call? I know about timer routes but they're global. What I'm trying to achieve is to send live updates for example to REST server (or anywhere else, maybe to MySQL) during the call and analyze the server's response, so I could close that call if the remote server says so after XXX seconds of active call. Thanks! Regards, Yury. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spanda at 3clogic.com Wed Jul 22 08:51:36 2020 From: spanda at 3clogic.com (Sasmita Panda) Date: Wed, 22 Jul 2020 14:21:36 +0530 Subject: [OpenSIPS-Users] Need help regarding dp_translate in opensips 2.2 . Message-ID: Hi All , in opensips 1.11 I was using dp_translate function as below and its working fine . $avp(src) = $rd; xlog("request domain,$avp(src)"); dp_translate("5", "$avp(src)/$avp(trl)"); $avp(grp)=$(avp(trl){s.int}); In opensips -2.2 i am using the same but its no working . The error is as below . *WARNING:core:do_assign: no value in right expression at /usr/etc/opensips/opensips_carrier.cfg:318* *line 318 refer to *$avp(grp)=$(avp(trl){s.int}); line . What I am doing wrong . Please help me . *Thanks & Regards* *Sasmita Panda* *Senior Network Testing and Software Engineer* *3CLogic , ph:07827611765* -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Jul 22 11:44:52 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 22 Jul 2020 14:44:52 +0300 Subject: [OpenSIPS-Users] OpenSIPS 3.1.0 LTS goes stable Message-ID: <41891636-73a8-76c3-6100-3d130d0a076d@opensips.org> OpenSIPS 3.1.0 LTS goes from beta to stable *It got stable!* There was a month and a half of work, of testing, of reporting and of fixing, but we did it! The OpenSIPS 3.1 release passed all the tests and exams and now it is labelled as stable LTS release, the flagship of the OpenSIPS project. Download it now *The 3.1 philosophy* The 3.1 release focused on *complex call crafting*, basically on increasing OpenSIPS's ability to create and handle complex calling scenarios where multiple SIP calls are mixed and able to interact. Some key features: * Call API via WebSockets * Inter-call media/RTP exchange * Push Notification support * DTMF handling * STIR & SHAKEN support * DFKS support * Quality based routing Read more on 3.1 Download and enjoy it as it's freshly baked for you! Any questions? do not hesitate to contact us ! ------------------------------------------------------------------------ -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From inder.itpro at gmail.com Wed Jul 22 20:39:10 2020 From: inder.itpro at gmail.com (inder sharma) Date: Thu, 23 Jul 2020 02:09:10 +0530 Subject: [OpenSIPS-Users] Segfault Crash siptrace Message-ID: Hello Team Opensips service crashes when we get a symbol/special character in RURI.It stopped crashing after disabling the siptrace module. version: opensips 2.4.6 (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: edef893c5 main.c compiled on 16:46:10 Dec 27 2019 with gcc 6.3.0 ERROR:core:_parse_to: unexpected char ["] in status 6: <<> . ERROR:core:get_hdr_field: bad to header ERROR:core:parse_from_header: bad msg or missing FROM header ERROR:siptrace:sip_trace: cannot parse FROM header ERROR:siptrace:sip_trace_w: sip trace failed! ERROR:core:_parse_to: unexpected char ["] in status 6: <<> . ERROR:core:get_hdr_field: bad to header ERROR:uri:has_totag: To parsing failed ERROR:core:_parse_to: unexpected char ["] in status 6: <<> . ERROR:core:get_hdr_field: bad to header ERROR:uri:has_totag: To parsing failed opensips[8202]: segfault at 20 ip 00007f7e2b038170 sp 00007ffda97bcd50 error 4 in siptrace.so[7f7e2b035000+1d000] ERROR:core:_parse_to: unexpected char ["] in status 6: <<> . ERROR:core:get_hdr_field: bad to header ERROR:uri:has_totag: To parsing failed CRITICAL:core:sig_usr: segfault in process pid: 8202, id: 12 -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.quick at smartvox.co.uk Thu Jul 23 08:18:30 2020 From: john.quick at smartvox.co.uk (John Quick) Date: Thu, 23 Jul 2020 09:18:30 +0100 Subject: [OpenSIPS-Users] Segfault Crash siptrace Message-ID: <000601d660c9$d9caae00$8d600a00$@smartvox.co.uk> Hello Inder, I think there are bugs in the sip_trace module in v2.4.6 My application would not start when the sip_trace module was enabled, using v2.4.6 This problem was fixed when I tried v2.4.7, but you should upgrade to 2.4.8 now. John Quick Smartvox Limited Web: www.smartvox.co.uk From bogdan at opensips.org Thu Jul 23 11:29:45 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 23 Jul 2020 14:29:45 +0300 Subject: [OpenSIPS-Users] OpenSIPS Summit 2020 Distributed is set! In-Reply-To: References: Message-ID: <3300a042-699f-089c-98ac-31042af6016f@opensips.org> Hello all, As a quick update here. The *free registration is now open*, so not miss the chance for winning some OpenSIPS prizes! Register and you will be part of the raffle. https://www.opensips.org/events/Summit-2020Distributed/#pricing Also we are working to provide an OpenSIPS 3.1 specific training, around *4 hours online training* in the next day after the summit (this is not part of the free registration). The training will cover *Call API, Push Notification or Media Exchange labs* - again, this is work in progress, but next week will announce it and open registrations for it also ;) Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ On 7/16/20 7:08 PM, Bogdan-Andrei Iancu wrote: > > Bye-Bye Amsterdam, welcome Online – the "OpenSIPS Summit 2020" becomes > the "OpenSIPS Summit Distributed 2020", a free, live and interactive > online event. > > 5th - 11th of September - are you ready to join us? > > https://blog.opensips.org/2020/07/16/opensips-summit-2020-distributed/ > > > See you over the Internet, > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Thu Jul 23 13:17:09 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Thu, 23 Jul 2020 14:17:09 +0100 Subject: [OpenSIPS-Users] SIP to WebRTC via OpenSIPS mid-registrar fails: forced proto 6 not matching sips uri In-Reply-To: References: Message-ID: [SOLVED] Thanks Stas. Your workaround did solve the problem and I see that with 3.1 path support is baked into mid-registrar module as options to mid_registrar_save(). Once we added in the path module functionality, at first it didn't work. Looking at sngrep traces we could see that the path information was appended on the inbound route from OpenSIPS to Asterisk, but when Asterisk made the call to the outbound destination it failed to include it as route info. This was resolved by setting supportpath="yes" in sip.conf and worked with CHAN_SIP. We tried to get it working with PJSIP without any joy but it's not a priority for us at the moment so we'll have to investigate the cause later. Thanks for your help Stas, and thanks also to the others who took the time to reply. cheers, Mark On Tue, 14 Jul 2020 at 16:23, Stas Kobzar wrote: > Hello Mark, > > I had a similar challenge. Using "path" module on both opensips helps > to overcome this problem. > https://opensips.org/docs/modules/3.2.x/path.html > > In your mid-registerer you need to enable path support. See "save" > function params p0 and v. > in your webrtc opensips use path module and function add_path_received > > On Tue, Jul 14, 2020 at 11:14 AM Mark Allen wrote: > > > > I'm new to OpenSIPS and I've hit a problem I can't find a way past > > > > We have a test setup with an OpenSIPS mid-registrar in front of an > Asterisk PBX. Mid-registrar is currently in mode 1 (registration > throttling). We have SIP and WebRTC endpoints that we want to use. > > > > Current state is: > > > > REGISTER: WebRTC webphone (Mizutech) -> OpenSIPS Mid-registrar -> > Asterisk = success > > REGISTER: SIP softphone (LinPhone) -> OpenSIPS Mid-registrar -> > Asterisk = success > > > > INVITE: SIP softphone -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP > softphone = success, call connects with audio both ways > > INVITE: WebRTC webphone -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP > softphone = success, call connects with audio both ways > > INVITE: SIP softphone -> OpenSIPS -> Asterisk -> OpenSIPS -> > WebRTC webphone = fails with "476 Unresolvable destination" > > > > syslog messages: > > ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri > > CRITICAL:core:mk_proxy: could not resolve hostname: > "4xp44jxl0qq0.invalid" > > ERROR:tm:uri2proxy: bad host name in URI ;rtcweb-breaker=yes;transport=wss> > > ERROR:tm:t_forward_nonack: failure to add branches > > > > > > Following past reports that I've found with a similar error, > fix_nated_contact() is run on INVITE messages just before rtpengine flags > are set and the t_relay() command, but it doesn't appear to make any > difference. If I change the t_relay() to t_relay(0x04,) to disable DNS > Failover, I still see the same errors in the log file. I've also checked > the record in the OpenSIPS DB "location" table and it seems to me that it > has the correct contact_id and contact info for the destination... > > > > contact_id: 2004383309156582802 > > contact: sips:11001 at 4xp44jxl0qq0.invalid > ;rtcweb-breaker=yes;transport=wss > > > > I'm stuck on where I can go from here - any help very much appreciated! > > > > thx > > > > Mark > > > > > > Setup: > > OpenSIPS 3.0.2 on Debian Buster > > RTPEngine Version: 8.4.0.0+0~mr8.4.0.0 > > > > INVITE: > > 2020/07/14 14:22:06.176544 192.168.50.185:5060 -> 192.168.50.69:5060 > > INVITE sip:11001 at 192.168.50.69:5060;ctid=2004383309156582802 SIP/2.0 > > Via: SIP/2.0/UDP 192.168.50.185:5060 > ;rport;branch=z9hG4bKPj3e87a449-f4cc-4128-abbe-95706a1a44a0 > > From: "11002" >;tag=1c03916d-d086-479a-b984-ff5bbbf3aba8 > > To: > > Contact: > > Call-ID: d1524788-cac2-4bea-a905-4e17ba006688 > > CSeq: 24456 INVITE > > Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, > CANCEL, UPDATE, PRACK, MESSAGE, REFER > > Supported: 100rel, timer, replaces, norefersub > > Session-Expires: 1800 > > Min-SE: 90 > > P-Asserted-Identity: "11002" > > Max-Forwards: 70 > > User-Agent: FPBX-15.0.16.63(16.9.0) > > Content-Type: application/sdp > > Content-Length: 411 > > > > v=0 > > o=- 263255642 263255642 IN IP4 192.168.50.185 > > s=Asterisk > > c=IN IP4 192.168.50.185 > > t=0 0 > > m=audio 10292 RTP/AVPF 9 107 8 0 3 111 101 > > a=rtpmap:9 G722/8000 > > a=rtpmap:107 opus/48000/2 > > a=fmtp:107 useinbandfec=1 > > a=rtpmap:8 PCMA/8000 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:3 GSM/8000 > > a=rtpmap:111 G726-32/8000 > > a=rtpmap:101 telephone-event/8000 > > a=fmtp:101 0-16 > > a=ptime:20 > > a=maxptime:20 > > a=sendrecv > > a=rtcp-mux > > > > > > _______________________________________________ > > 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: From inder.itpro at gmail.com Thu Jul 23 13:43:34 2020 From: inder.itpro at gmail.com (inder sharma) Date: Thu, 23 Jul 2020 19:13:34 +0530 Subject: [OpenSIPS-Users] Segfault Crash siptrace In-Reply-To: References: Message-ID: It's working now after upgrading opensips 2.4.8. Thanks John. On Thu, Jul 23, 2020 at 2:09 AM inder sharma wrote: > Hello Team > > Opensips service crashes when we get a symbol/special character in RURI.It > stopped crashing after disabling the siptrace module. > > version: opensips 2.4.6 (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: edef893c5 > main.c compiled on 16:46:10 Dec 27 2019 with gcc 6.3.0 > > ERROR:core:_parse_to: unexpected char ["] in status 6: <<> . > ERROR:core:get_hdr_field: bad to header > ERROR:core:parse_from_header: bad msg or missing FROM header > ERROR:siptrace:sip_trace: cannot parse FROM header > ERROR:siptrace:sip_trace_w: sip trace failed! > ERROR:core:_parse_to: unexpected char ["] in status 6: <<> . > ERROR:core:get_hdr_field: bad to header > ERROR:uri:has_totag: To parsing failed > ERROR:core:_parse_to: unexpected char ["] in status 6: <<> . > ERROR:core:get_hdr_field: bad to header > ERROR:uri:has_totag: To parsing failed > opensips[8202]: segfault at 20 ip 00007f7e2b038170 sp 00007ffda97bcd50 > error 4 in siptrace.so[7f7e2b035000+1d000] > ERROR:core:_parse_to: unexpected char ["] in status 6: <<> . > ERROR:core:get_hdr_field: bad to header > ERROR:uri:has_totag: To parsing failed > CRITICAL:core:sig_usr: segfault in process pid: 8202, id: 12 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staskobzar at gmail.com Thu Jul 23 14:03:10 2020 From: staskobzar at gmail.com (Stas Kobzar) Date: Thu, 23 Jul 2020 10:03:10 -0400 Subject: [OpenSIPS-Users] SIP to WebRTC via OpenSIPS mid-registrar fails: forced proto 6 not matching sips uri In-Reply-To: References: Message-ID: Hi Mark, Glad it helped. I actually did not know about chan_sip option supportpath because I was using additional opensips for wws to webrtc. Thanks for the details. Good luck On Thu, Jul 23, 2020 at 9:19 AM Mark Allen wrote: > > [SOLVED] > > Thanks Stas. Your workaround did solve the problem and I see that with 3.1 path support is baked into mid-registrar module as options to mid_registrar_save(). > > Once we added in the path module functionality, at first it didn't work. Looking at sngrep traces we could see that the path information was appended on the inbound route from OpenSIPS to Asterisk, but when Asterisk made the call to the outbound destination it failed to include it as route info. This was resolved by setting supportpath="yes" in sip.conf and worked with CHAN_SIP. We tried to get it working with PJSIP without any joy but it's not a priority for us at the moment so we'll have to investigate the cause later. > > Thanks for your help Stas, and thanks also to the others who took the time to reply. > > cheers, > > Mark > > > On Tue, 14 Jul 2020 at 16:23, Stas Kobzar wrote: >> >> Hello Mark, >> >> I had a similar challenge. Using "path" module on both opensips helps >> to overcome this problem. >> https://opensips.org/docs/modules/3.2.x/path.html >> >> In your mid-registerer you need to enable path support. See "save" >> function params p0 and v. >> in your webrtc opensips use path module and function add_path_received >> >> On Tue, Jul 14, 2020 at 11:14 AM Mark Allen wrote: >> > >> > I'm new to OpenSIPS and I've hit a problem I can't find a way past >> > >> > We have a test setup with an OpenSIPS mid-registrar in front of an Asterisk PBX. Mid-registrar is currently in mode 1 (registration throttling). We have SIP and WebRTC endpoints that we want to use. >> > >> > Current state is: >> > >> > REGISTER: WebRTC webphone (Mizutech) -> OpenSIPS Mid-registrar -> Asterisk = success >> > REGISTER: SIP softphone (LinPhone) -> OpenSIPS Mid-registrar -> Asterisk = success >> > >> > INVITE: SIP softphone -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP softphone = success, call connects with audio both ways >> > INVITE: WebRTC webphone -> OpenSIPS -> Asterisk -> OpenSIPS -> SIP softphone = success, call connects with audio both ways >> > INVITE: SIP softphone -> OpenSIPS -> Asterisk -> OpenSIPS -> WebRTC webphone = fails with "476 Unresolvable destination" >> > >> > syslog messages: >> > ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri >> > CRITICAL:core:mk_proxy: could not resolve hostname: "4xp44jxl0qq0.invalid" >> > ERROR:tm:uri2proxy: bad host name in URI >> > ERROR:tm:t_forward_nonack: failure to add branches >> > >> > >> > Following past reports that I've found with a similar error, fix_nated_contact() is run on INVITE messages just before rtpengine flags are set and the t_relay() command, but it doesn't appear to make any difference. If I change the t_relay() to t_relay(0x04,) to disable DNS Failover, I still see the same errors in the log file. I've also checked the record in the OpenSIPS DB "location" table and it seems to me that it has the correct contact_id and contact info for the destination... >> > >> > contact_id: 2004383309156582802 >> > contact: sips:11001 at 4xp44jxl0qq0.invalid;rtcweb-breaker=yes;transport=wss >> > >> > I'm stuck on where I can go from here - any help very much appreciated! >> > >> > thx >> > >> > Mark >> > >> > >> > Setup: >> > OpenSIPS 3.0.2 on Debian Buster >> > RTPEngine Version: 8.4.0.0+0~mr8.4.0.0 >> > >> > INVITE: >> > 2020/07/14 14:22:06.176544 192.168.50.185:5060 -> 192.168.50.69:5060 >> > INVITE sip:11001 at 192.168.50.69:5060;ctid=2004383309156582802 SIP/2.0 >> > Via: SIP/2.0/UDP 192.168.50.185:5060;rport;branch=z9hG4bKPj3e87a449-f4cc-4128-abbe-95706a1a44a0 >> > From: "11002" ;tag=1c03916d-d086-479a-b984-ff5bbbf3aba8 >> > To: >> > Contact: >> > Call-ID: d1524788-cac2-4bea-a905-4e17ba006688 >> > CSeq: 24456 INVITE >> > Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER >> > Supported: 100rel, timer, replaces, norefersub >> > Session-Expires: 1800 >> > Min-SE: 90 >> > P-Asserted-Identity: "11002" >> > Max-Forwards: 70 >> > User-Agent: FPBX-15.0.16.63(16.9.0) >> > Content-Type: application/sdp >> > Content-Length: 411 >> > >> > v=0 >> > o=- 263255642 263255642 IN IP4 192.168.50.185 >> > s=Asterisk >> > c=IN IP4 192.168.50.185 >> > t=0 0 >> > m=audio 10292 RTP/AVPF 9 107 8 0 3 111 101 >> > a=rtpmap:9 G722/8000 >> > a=rtpmap:107 opus/48000/2 >> > a=fmtp:107 useinbandfec=1 >> > a=rtpmap:8 PCMA/8000 >> > a=rtpmap:0 PCMU/8000 >> > a=rtpmap:3 GSM/8000 >> > a=rtpmap:111 G726-32/8000 >> > a=rtpmap:101 telephone-event/8000 >> > a=fmtp:101 0-16 >> > a=ptime:20 >> > a=maxptime:20 >> > a=sendrecv >> > a=rtcp-mux >> > >> > >> > _______________________________________________ >> > 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 > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From liviu at opensips.org Fri Jul 24 10:12:05 2020 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 24 Jul 2020 13:12:05 +0300 Subject: [OpenSIPS-Users] How to delay a branch In-Reply-To: References: Message-ID: <87e9478f-c64e-b9ca-333b-9d17340a6415@opensips.org> On 13.07.2020 16:02, ryan embgrets wrote: > > So, I set a branch flag on those registrations before calling the save > function, and then try to use async sleep in the branch route after > lookup. > > But I see sleep applies on the whole call(all branches are sent with > delay) no matter if it was called on a single branch. Hey, Ryan! Did you solve your problem in the meantime?  I think you are confusing parallel forking with serial forking.  Implicitly, the OpenSIPS request branching engine performs **parallel** forking.  In other words, no matter how you prepare your branches (be it using append_branch(), lookup(), mid_registrar_lookup(), etc.), they will all be sent out concurrently, hence the effect you are noticing ("the sleep applies on the whole call"). To change the behavior to a **serial** forking one, try calling serialize_branches() [1] after building your branch set.  IIRC, there's a caveat in there, which also requires you to call next_branches() afterwards.  Just read the docs carefully and you should be fine. Best regards, [1]: https://opensips.org/Documentation/Script-CoreFunctions-3-2#toc44 -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events From rembgrets at gmail.com Fri Jul 24 12:15:27 2020 From: rembgrets at gmail.com (ryan embgrets) Date: Fri, 24 Jul 2020 17:15:27 +0500 Subject: [OpenSIPS-Users] How to delay a branch In-Reply-To: <87e9478f-c64e-b9ca-333b-9d17340a6415@opensips.org> References: <87e9478f-c64e-b9ca-333b-9d17340a6415@opensips.org> Message-ID: Hi, Thanks for coming back to me on this query. I did not want to do serial forking. Let me try to explain my query in better detail. So, i have desktop phones and mobile phones registered to same AOR, what i wanted to do was, If we have mobile phone devices registered we send invites to them instantly but desktop devices need to be rung after some delay from phone devices. But if no phone device was registered, we simply do parallel forking to desktop devices. Ryan. On Fri, 24 Jul 2020 at 15:14, Liviu Chircu wrote: > On 13.07.2020 16:02, ryan embgrets wrote: > > > > So, I set a branch flag on those registrations before calling the save > > function, and then try to use async sleep in the branch route after > > lookup. > > > > But I see sleep applies on the whole call(all branches are sent with > > delay) no matter if it was called on a single branch. > > Hey, Ryan! > > Did you solve your problem in the meantime? I think you are confusing > parallel forking with serial forking. Implicitly, the OpenSIPS request > branching engine performs **parallel** forking. In other words, no > matter how you prepare your branches (be it using append_branch(), > lookup(), mid_registrar_lookup(), etc.), they will all be sent out > concurrently, hence the effect you are noticing ("the sleep applies on > the whole call"). > > To change the behavior to a **serial** forking one, try calling > serialize_branches() [1] after building your branch set. IIRC, there's > a caveat in there, which also requires you to call next_branches() > afterwards. Just read the docs carefully and you should be fine. > > Best regards, > > [1]: https://opensips.org/Documentation/Script-CoreFunctions-3-2#toc44 > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > OpenSIPS Summit 2020 Distributed > 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 Ben.Newlin at genesys.com Fri Jul 24 13:25:14 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Fri, 24 Jul 2020 13:25:14 +0000 Subject: [OpenSIPS-Users] How to delay a branch In-Reply-To: References: <87e9478f-c64e-b9ca-333b-9d17340a6415@opensips.org> Message-ID: <2C667559-800D-42AD-9E3D-4E94D33AE70D@genesys.com> I think the issue here is that the sleep function pauses the OpenSIPS process in which it is running; it doesn’t matter what type of route you call it in, the whole process will sleep. Since all message processing, and all branch routes, are running in the same process then sleeping that process will delay everything. Even asynchronous sleep is performed by suspending all message processing for that message, not individual branches. Ben Newlin From: Users on behalf of ryan embgrets Reply-To: OpenSIPS users mailling list Date: Friday, July 24, 2020 at 8:16 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] How to delay a branch Hi, Thanks for coming back to me on this query. I did not want to do serial forking. Let me try to explain my query in better detail. So, i have desktop phones and mobile phones registered to same AOR, what i wanted to do was, If we have mobile phone devices registered we send invites to them instantly but desktop devices need to be rung after some delay from phone devices. But if no phone device was registered, we simply do parallel forking to desktop devices. Ryan. On Fri, 24 Jul 2020 at 15:14, Liviu Chircu > wrote: On 13.07.2020 16:02, ryan embgrets wrote: > > So, I set a branch flag on those registrations before calling the save > function, and then try to use async sleep in the branch route after > lookup. > > But I see sleep applies on the whole call(all branches are sent with > delay) no matter if it was called on a single branch. Hey, Ryan! Did you solve your problem in the meantime? I think you are confusing parallel forking with serial forking. Implicitly, the OpenSIPS request branching engine performs **parallel** forking. In other words, no matter how you prepare your branches (be it using append_branch(), lookup(), mid_registrar_lookup(), etc.), they will all be sent out concurrently, hence the effect you are noticing ("the sleep applies on the whole call"). To change the behavior to a **serial** forking one, try calling serialize_branches() [1] after building your branch set. IIRC, there's a caveat in there, which also requires you to call next_branches() afterwards. Just read the docs carefully and you should be fine. Best regards, [1]: https://opensips.org/Documentation/Script-CoreFunctions-3-2#toc44 -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed 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 liviu at opensips.org Fri Jul 24 13:49:27 2020 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 24 Jul 2020 16:49:27 +0300 Subject: [OpenSIPS-Users] How to delay a branch In-Reply-To: <2C667559-800D-42AD-9E3D-4E94D33AE70D@genesys.com> References: <87e9478f-c64e-b9ca-333b-9d17340a6415@opensips.org> <2C667559-800D-42AD-9E3D-4E94D33AE70D@genesys.com> Message-ID: <32b213df-e84a-3cfc-098e-2b01c7e62ca2@opensips.org> On 24.07.2020 16:25, Ben Newlin wrote: > > I think the issue here is that the sleep function pauses the OpenSIPS > process in which it is running; it doesn’t matter what type of route > you call it in, the whole process will sleep. Since all message > processing, and all branch routes, are running in the same process > then sleeping that process will delay everything. > > Even asynchronous sleep is performed by suspending all message > processing for that message, not individual branches. > Spot on, Ben!  All branches are forked out by the same process: if you pause it, you pause the forking of the remaining branches in the set... which somehow leads me to believe that doing an async(sleep) after t_relay()'ing the last mobile phone branch _should work_, at least in theory... such that after the sleep is completed, the remaining branches in the set will be forked out. Now, the tricky part is making sure that the mobile phone branches are always ahead of the desk phone ones, so they parallel fork first.  I do not see an easy solution to this, nor are there any handy script functions to help you do this... you will have to "swap" the branch data around using the $branch properties and other variables (e.g. $ru, $du, $socket_out) until you obtain the desired effect. Curious to hear other opinions as well :) Best regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed -------------- next part -------------- An HTML attachment was scrubbed... URL: From chandan.pr at webshar.org Fri Jul 24 13:53:13 2020 From: chandan.pr at webshar.org (Chandan PR) Date: Fri, 24 Jul 2020 19:23:13 +0530 Subject: [OpenSIPS-Users] OpenSips Load balancer. - Overcome limitations of Call Driven Load Balancing Message-ID: Hello Everyone, Currently, we are using Open Sips Load balancer in Call Driven load balancing . Our scenario is as below: *D* - Total Destinations configured at OpenSips *P* - No of Ports/Sessions Each Destination can handle concurrently *C* - Total Capacity = D*P We have a Call Loader which loads calls to OpenSips at C and as when the result comes further calls get loaded. For some reason, if any destination is not in the right state and sends error responses without accepting calls, this introduces a drain scenario. In the drain scenario where all new calls are given to the faulty destination as it has more availability. We are currently handling this by 1. Running the loader at 80% of C 2. Disabling the destination in Opensips if 75% of the calls fail for the particular destination (Attached loadbalancer.cfg file). But even in this case, it is possible that may call error out as the destination is free and calls are loaded. We would like to avoid this scenario to the max possible extent by limiting the number of calls we send to this particular destination. Couple of options I see are as below: 1. Wait for a brief period before sending the response to loader when the error happens 2. Make OpenSips aware of the destination capacity and adjust ports accordingly - Write a custom script to poll destination capacity and use MI functions to adjust accordingly - Or is there any possibility to integrate similar to FreeSwitch driven routing Are there any other possibilities of adjusting the OpenSips capacity dynamically or make it limit the calls sent to the particular destination? -- Regards, Chandan Ravishankar -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: loadbalancer.cfg Type: application/octet-stream Size: 6644 bytes Desc: not available URL: From johan at democon.be Fri Jul 24 13:53:50 2020 From: johan at democon.be (johan) Date: Fri, 24 Jul 2020 15:53:50 +0200 Subject: [OpenSIPS-Users] opensips-cp for 3.1 Message-ID: <532aabf7-828f-4bd2-a1c7-8fa6a0faa277@democon.be>    Hi, is it okay to use opensips-cp 3.0 for opensips 3.1 ? wkr, From ffshoh at gmail.com Fri Jul 24 14:10:32 2020 From: ffshoh at gmail.com (Jon Abrams) Date: Fri, 24 Jul 2020 09:10:32 -0500 Subject: [OpenSIPS-Users] OpenSips Load balancer. - Overcome limitations of Call Driven Load Balancing In-Reply-To: References: Message-ID: Hi Chandan, There may be something else purpose built for this, but you can use the dialog profiles to track and limit the port usage: set_dlg_profile("outcarrier","$avp(out_carrier_id)"); if ($avp(out_max_call_limit) > 0) { set_dlg_profile("profile","$avp(out_qos_profile_id)"); if (get_profile_size("profile","$avp(out_qos_profile_id)","$var(out_gw_count)")) { if ($var(out_gw_count)>$avp(out_max_call_limit)) { xlog("LIMIT: Call $ci - Max call limit hit by $avp(src_addr) on QosProfile $avp(out_qos_profile_id) to gw $avp(out_gw_id)\n"); return(-1); } } } On Fri, Jul 24, 2020 at 8:55 AM Chandan PR wrote: > > Hello Everyone, > > Currently, we are using Open Sips Load balancer in Call Driven load balancing. > > Our scenario is as below: > > D - Total Destinations configured at OpenSips > P - No of Ports/Sessions Each Destination can handle concurrently > C - Total Capacity = D*P > > We have a Call Loader which loads calls to OpenSips at C and as when the result comes further calls get loaded. > For some reason, if any destination is not in the right state and sends error responses without accepting calls, this introduces a drain scenario. > In the drain scenario where all new calls are given to the faulty destination as it has more availability. > > We are currently handling this by > > Running the loader at 80% of C > Disabling the destination in Opensips if 75% of the calls fail for the particular destination (Attached loadbalancer.cfg file). > > > But even in this case, it is possible that may call error out as the destination is free and calls are loaded. > > We would like to avoid this scenario to the max possible extent by limiting the number of calls we send to this particular destination. > > Couple of options I see are as below: > > Wait for a brief period before sending the response to loader when the error happens > Make OpenSips aware of the destination capacity and adjust ports accordingly > > Write a custom script to poll destination capacity and use MI functions to adjust accordingly > Or is there any possibility to integrate similar to FreeSwitch driven routing > > Are there any other possibilities of adjusting the OpenSips capacity dynamically or make it limit the calls sent to the particular destination? > > -- > > Regards, > Chandan Ravishankar > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From mark at markmiranda.com Fri Jul 24 20:20:47 2020 From: mark at markmiranda.com (Mark Miranda) Date: Fri, 24 Jul 2020 15:20:47 -0500 Subject: [OpenSIPS-Users] Opensips MS Teams lost BYE In-Reply-To: <000201d65371$ff2ae760$fd80b620$@smartvox.co.uk> References: <000201d65371$ff2ae760$fd80b620$@smartvox.co.uk> Message-ID: <004F21BD-2B66-49E6-B8C4-966231D02993@markmiranda.com> I have basically the same problem where the BYE packet does not seem to be routing properly, however I am not using any of the nat functions. > On Jul 6, 2020, at 3:46 AM, John Quick wrote: > > Chris, > > You must not call fix_nated_contact() for any SIP requests or SIP responses > coming from MS Teams. > If you do, it will cause exactly the problems you describe for loose-routed > sequential requests such as BYE. > > Just to explain: fix_nated_contact() should only be used when the messages > come via a NAT router. It must not be used for messages coming from a Proxy > (assuming the Proxy adds a Record-Route header, as happens with Teams), even > though both cases may appear to need fixing when you use nat_uac_test(). > > John Quick > Smartvox Limited > Web: www.smartvox.co.uk > >> I've managed to get the PBX to send the BYE to the SBC and it is now > forwarding on to MS (although MS are not sending a reply but we have opened > a case for this). > >> We are struggling to get the BYE packet to go back to MS Teams when the > call is initiated by Teams. > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From chandan.pr at webshar.org Sat Jul 25 05:16:26 2020 From: chandan.pr at webshar.org (Chandan PR) Date: Sat, 25 Jul 2020 10:46:26 +0530 Subject: [OpenSIPS-Users] OpenSips Load balancer. - Overcome limitations of Call Driven Load Balancing In-Reply-To: References: Message-ID: Thanks for the response Jon. Let me have a look at it. On Fri, Jul 24, 2020 at 7:42 PM Jon Abrams wrote: > Hi Chandan, > > There may be something else purpose built for this, but you can use > the dialog profiles to track and limit the port usage: > > set_dlg_profile("outcarrier","$avp(out_carrier_id)"); > > if ($avp(out_max_call_limit) > 0) > { > set_dlg_profile("profile","$avp(out_qos_profile_id)"); > if > (get_profile_size("profile","$avp(out_qos_profile_id)","$var(out_gw_count)")) > { > if ($var(out_gw_count)>$avp(out_max_call_limit)) > { > xlog("LIMIT: Call $ci - Max call limit hit by > $avp(src_addr) on QosProfile $avp(out_qos_profile_id) to gw > $avp(out_gw_id)\n"); > return(-1); > } > } > } > > On Fri, Jul 24, 2020 at 8:55 AM Chandan PR wrote: > > > > Hello Everyone, > > > > Currently, we are using Open Sips Load balancer in Call Driven load > balancing. > > > > Our scenario is as below: > > > > D - Total Destinations configured at OpenSips > > P - No of Ports/Sessions Each Destination can handle concurrently > > C - Total Capacity = D*P > > > > We have a Call Loader which loads calls to OpenSips at C and as when the > result comes further calls get loaded. > > For some reason, if any destination is not in the right state and sends > error responses without accepting calls, this introduces a drain scenario. > > In the drain scenario where all new calls are given to the faulty > destination as it has more availability. > > > > We are currently handling this by > > > > Running the loader at 80% of C > > Disabling the destination in Opensips if 75% of the calls fail for the > particular destination (Attached loadbalancer.cfg file). > > > > > > But even in this case, it is possible that may call error out as the > destination is free and calls are loaded. > > > > We would like to avoid this scenario to the max possible extent by > limiting the number of calls we send to this particular destination. > > > > Couple of options I see are as below: > > > > Wait for a brief period before sending the response to loader when the > error happens > > Make OpenSips aware of the destination capacity and adjust ports > accordingly > > > > Write a custom script to poll destination capacity and use MI functions > to adjust accordingly > > Or is there any possibility to integrate similar to FreeSwitch driven > routing > > > > Are there any other possibilities of adjusting the OpenSips capacity > dynamically or make it limit the calls sent to the particular destination? > > > > -- > > > > Regards, > > Chandan Ravishankar > > _______________________________________________ > > 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, Chandan Ravishankar -------------- next part -------------- An HTML attachment was scrubbed... URL: From voip.security at protonmail.com Sat Jul 25 16:21:13 2020 From: voip.security at protonmail.com (Sharad Kumar) Date: Sat, 25 Jul 2020 16:21:13 +0000 Subject: [OpenSIPS-Users] opensips-cp for 3.1 Message-ID: Hi Johan, Absolutely, You can use opensips-cp 3.0 for opensips 3.1 From johan at democon.be Sat Jul 25 16:58:24 2020 From: johan at democon.be (Johan De Clercq) Date: Sat, 25 Jul 2020 16:58:24 +0000 Subject: [OpenSIPS-Users] opensips-cp for 3.1 In-Reply-To: References: Message-ID: Thanks sharad Outlook voor iOS downloaden ________________________________ Van: Users namens Sharad Kumar via Users Verzonden: Saturday, July 25, 2020 6:21:13 PM Aan: users at lists.opensips.org Onderwerp: Re: [OpenSIPS-Users] opensips-cp for 3.1 Hi Johan, Absolutely, You can use opensips-cp 3.0 for opensips 3.1 _______________________________________________ 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 razvan at opensips.org Mon Jul 27 07:19:23 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 27 Jul 2020 10:19:23 +0300 Subject: [OpenSIPS-Users] Opensips 2.4.8 SEGFAULT In-Reply-To: <03d44115cd0ce0540431e2557500013c@jfive.net> References: <2fbe5a654436b58b36ea1115b43b2a8d@jfive.net> <261ee76a64450a126ee27e6085bc10b6@jfive.net> <03d44115cd0ce0540431e2557500013c@jfive.net> Message-ID: Hi, James! Please compile your sources with memory debugging [1] (QM_MALLOC) to gather more information. [1] https://www.opensips.org/Documentation/TroubleShooting-OutOfMem Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 7/16/20 8:30 PM, James via Users wrote: > I complied opensips 2.4.8 from git and I now have the correct output for > my core dump.... I hope! > > > > https://pastebin.com/rFbptVrW > > > > version: opensips 2.4.8 (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: 1e891b5e3 > main.c compiled on 23:02:38 Jul 14 2020 with gcc 8 > > > I am running Centos 8 > > > Thanks, > > James > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From razvan at opensips.org Mon Jul 27 07:20:55 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 27 Jul 2020 10:20:55 +0300 Subject: [OpenSIPS-Users] Dynamic Routing Stats In-Reply-To: References: Message-ID: <216120bc-a397-4118-aa7f-9c0bd9a3f3e6@opensips.org> Hi, Mark! Unfortunately the drouting module does not export any statistics. You can however use the statistics module[1] and define your own statistics, that you have to manually update them from the script according to your needs. [1] https://opensips.org/docs/modules/3.1.x/statistics.html Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 7/17/20 4:39 PM, Mark Farmer wrote: > Hi everyone > > I have been asked to look into getting Nagios to monitor active calls on > specific Dynamic Routing gateways. > > Looking at the drouting() docs I don't see any exported statistics. > Is there a way to do this please? > > Many thanks > Mark. > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From razvan at opensips.org Mon Jul 27 07:25:44 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 27 Jul 2020 10:25:44 +0300 Subject: [OpenSIPS-Users] do_routing not populating variables In-Reply-To: References: Message-ID: Hi, John! According to your snippet, you're logging the attributes when do_routing fails - well, if do_routing fails, it means that id didn't find any rule, gateway or carrier that is able to handle the call, therefore it is normal that all of them are NULL. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 7/21/20 10:34 PM, John Kiniston wrote: > Running 2.4 > > I'm not sure if I'm calling do_routing right, I'm using it in a test. > > if(!do_routing("1","","","$avp(rule_attrs_pvar)","$avp(gw_attrs_pvar)","$avp(carrier_attrs_pvar)")){ > I log what I get back but nothing is populated. > xlog("L_INFO"," return codes $avp(rule_attrs_pvar) $avp(gw_attrs_pvar) > $avp(carrier_attrs_pvar)"); > -- > A human being should be able to change a diaper, plan an invasion, > butcher a hog, conn a ship, design a building, write a sonnet, balance > accounts, build a wall, set a bone, comfort the dying, take orders, give > orders, cooperate, act alone, solve equations, analyze a new problem, > pitch manure, program a computer, cook a tasty meal, fight efficiently, > die gallantly. Specialization is for insects. > ---Heinlein > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From razvan at opensips.org Mon Jul 27 07:27:07 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 27 Jul 2020 10:27:07 +0300 Subject: [OpenSIPS-Users] Need help regarding dp_translate in opensips 2.2 . In-Reply-To: References: Message-ID: Hi, Sasmita! You should only check the `$avp(trl)` value if `dp_translate` succeeeds. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 7/22/20 11:51 AM, Sasmita Panda wrote: > Hi All , > in opensips 1.11 I was using dp_translate function as below and its > working fine . > > $avp(src) = $rd; > xlog("request domain,$avp(src)"); > dp_translate("5", "$avp(src)/$avp(trl)"); > $avp(grp)=$(avp(trl){s.int }); > > In opensips -2.2 i am using the same but its no working . The error is > as below . > > *WARNING:core:do_assign: no value in right expression at > /usr/etc/opensips/opensips_carrier.cfg:318* > * > * > *line 318 refer to *$avp(grp)=$(avp(trl){s.int });  line . > > What I am doing wrong . Please help me . > > */Thanks & Regards/* > /Sasmita Panda/ > /Senior Network Testing and Software Engineer/ > /3CLogic , ph:07827611765/ > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From razvan at opensips.org Mon Jul 27 07:29:04 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 27 Jul 2020 10:29:04 +0300 Subject: [OpenSIPS-Users] opensips-cp for 3.1 In-Reply-To: <532aabf7-828f-4bd2-a1c7-8fa6a0faa277@democon.be> References: <532aabf7-828f-4bd2-a1c7-8fa6a0faa277@democon.be> Message-ID: <4e8c85db-0b56-6673-e7fb-86660b9369d2@opensips.org> Hi, Johan! We haven't got a chance to tune OpenSIPS CP for 3.1, although we need to do this ASAP. Nevertheless, there were no major changes between 3.0 and 3.1, therefore you should be able to use 3.1. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 7/24/20 4:53 PM, johan wrote: > >    Hi, > > > is it okay to use opensips-cp 3.0 for opensips 3.1 ? > > > wkr, > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users From Johan at democon.be Mon Jul 27 07:43:15 2020 From: Johan at democon.be (Johan De Clercq) Date: Mon, 27 Jul 2020 09:43:15 +0200 Subject: [OpenSIPS-Users] opensips-cp for 3.1 In-Reply-To: <4e8c85db-0b56-6673-e7fb-86660b9369d2@opensips.org> References: <532aabf7-828f-4bd2-a1c7-8fa6a0faa277@democon.be> <4e8c85db-0b56-6673-e7fb-86660b9369d2@opensips.org> Message-ID: thanks Razvan, btw, I will be starting on push notifications also. Op ma 27 jul. 2020 om 09:32 schreef Răzvan Crainea : > Hi, Johan! > > We haven't got a chance to tune OpenSIPS CP for 3.1, although we need to > do this ASAP. > Nevertheless, there were no major changes between 3.0 and 3.1, therefore > you should be able to use 3.1. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 7/24/20 4:53 PM, johan wrote: > > > > Hi, > > > > > > is it okay to use opensips-cp 3.0 for opensips 3.1 ? > > > > > > wkr, > > > > > > _______________________________________________ > > 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: From Johan at democon.be Mon Jul 27 07:44:50 2020 From: Johan at democon.be (Johan De Clercq) Date: Mon, 27 Jul 2020 09:44:50 +0200 Subject: [OpenSIPS-Users] bugs on smpp. Message-ID: Hi, a few months ago, volga629 and myself added bugs and a feature request for proto_smpp. Now, after 30 days these issues are closed. Is there any chance that these can be picked up ? wkr, -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan at opensips.org Mon Jul 27 08:36:48 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Mon, 27 Jul 2020 11:36:48 +0300 Subject: [OpenSIPS-Users] bugs on smpp. In-Reply-To: References: Message-ID: Hi, Johan! Unfortunately we are not using those features in proto_smpp, and it is very hard for me to create a testing environment for something that I don't fully understand how it works. That's why those issues have been put back. Nevertheless, they shouldn't be closed - this seems like a stale bot issue. If possible, please re-open the tickets, so we can keep track of them. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 7/27/20 10:44 AM, Johan De Clercq wrote: > Hi, > > a few months ago, volga629 and myself added bugs and a feature request > for proto_smpp. > Now, after 30 days these issues are closed. > > Is there any chance that these can be picked up ? > > wkr, > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From rembgrets at gmail.com Mon Jul 27 09:14:10 2020 From: rembgrets at gmail.com (ryan embgrets) Date: Mon, 27 Jul 2020 14:14:10 +0500 Subject: [OpenSIPS-Users] Userblacklist module with mongodb In-Reply-To: References: Message-ID: Any pointer? I am using mongo for other modules and don't want to keep separate database(mysql) for this module only Ryan. On Sun, 19 Jul 2020 at 15:32, ryan embgrets wrote: > Greeting, > > I am just wondering if someone has been using mongodb for the user > blacklist module or even if it is compatible with mongo? > > I have below configurations, > > loadmodule "db_cachedb.so" > loadmodule "cachedb_mongodb.so" > > modparam("db_cachedb","cachedb_url","mongodb:globalblacklist://opensips:opensipsrw at localhost > /opensips.globalblacklist") > > loadmodule "userblacklist.so" > modparam("userblacklist", "db_url", "cachedb://mongodb:globalblacklist") > > But it does not seem to work, and gives below error > > ERROR:userblacklist:db_reload_source: got invalid result type from query. > > Any suggestions? > > Ryan. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rembgrets at gmail.com Mon Jul 27 09:18:58 2020 From: rembgrets at gmail.com (ryan embgrets) Date: Mon, 27 Jul 2020 14:18:58 +0500 Subject: [OpenSIPS-Users] How to delay a branch In-Reply-To: <32b213df-e84a-3cfc-098e-2b01c7e62ca2@opensips.org> References: <87e9478f-c64e-b9ca-333b-9d17340a6415@opensips.org> <2C667559-800D-42AD-9E3D-4E94D33AE70D@genesys.com> <32b213df-e84a-3cfc-098e-2b01c7e62ca2@opensips.org> Message-ID: Thanks everyone for your valuable feedback. I think we can send the branches to be delayed back to opensips and in this way, it would be a new call in opensips so we can easily handle it with extra configs. Anyways, we changed the business logic a bit(send to phones only if registered) and were able to handle them using branch params. Ryan. On Fri, 24 Jul 2020 at 18:51, Liviu Chircu wrote: > On 24.07.2020 16:25, Ben Newlin wrote: > > I think the issue here is that the sleep function pauses the OpenSIPS > process in which it is running; it doesn’t matter what type of route you > call it in, the whole process will sleep. Since all message processing, and > all branch routes, are running in the same process then sleeping that > process will delay everything. > > > > Even asynchronous sleep is performed by suspending all message processing > for that message, not individual branches. > > Spot on, Ben! All branches are forked out by the same process: if you > pause it, you pause the forking of the remaining branches in the set... > which somehow leads me to believe that doing an async(sleep) after > t_relay()'ing the last mobile phone branch _should work_, at least in > theory... such that after the sleep is completed, the remaining branches in > the set will be forked out. > > Now, the tricky part is making sure that the mobile phone branches are > always ahead of the desk phone ones, so they parallel fork first. I do not > see an easy solution to this, nor are there any handy script functions to > help you do this... you will have to "swap" the branch data around using > the $branch properties and other variables (e.g. $ru, $du, $socket_out) > until you obtain the desired effect. > > Curious to hear other opinions as well :) > > Best regards, > > -- > Liviu Chircuwww.twitter.com/liviuchircu | www.opensips-solutions.com > OpenSIPS Summit 2020 Distributed > www.opensips.org/events/Summit-2020Distributed > > _______________________________________________ > 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 Chris.Johnson at froneri.com Mon Jul 27 09:28:07 2020 From: Chris.Johnson at froneri.com (Chris Johnson) Date: Mon, 27 Jul 2020 09:28:07 +0000 Subject: [OpenSIPS-Users] Opensips MS Teams lost BYE In-Reply-To: <004F21BD-2B66-49E6-B8C4-966231D02993@markmiranda.com> References: <000201d65371$ff2ae760$fd80b620$@smartvox.co.uk> <004F21BD-2B66-49E6-B8C4-966231D02993@markmiranda.com> Message-ID: We were only able to remove one of the fix_nated_contact lines before it broke more than it did fix. We're currently seeking support from Opensips directly to get it all working correctly. From: Mark Miranda Sent: 24 July 2020 21:21 To: john.quick at smartvox.co.uk; OpenSIPS users mailling list Cc: Chris Johnson Subject: Re: [OpenSIPS-Users] Opensips MS Teams lost BYE CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. I have basically the same problem where the BYE packet does not seem to be routing properly, however I am not using any of the nat functions. > On Jul 6, 2020, at 3:46 AM, John Quick > wrote: > > Chris, > > You must not call fix_nated_contact() for any SIP requests or SIP responses > coming from MS Teams. > If you do, it will cause exactly the problems you describe for loose-routed > sequential requests such as BYE. > > Just to explain: fix_nated_contact() should only be used when the messages > come via a NAT router. It must not be used for messages coming from a Proxy > (assuming the Proxy adds a Record-Route header, as happens with Teams), even > though both cases may appear to need fixing when you use nat_uac_test(). > > John Quick > Smartvox Limited > Web: www.smartvox.co.uk > >> I've managed to get the PBX to send the BYE to the SBC and it is now > forwarding on to MS (although MS are not sending a reply but we have opened > a case for this). > >> We are struggling to get the BYE packet to go back to MS Teams when the > call is initiated by Teams. > > > _______________________________________________ > 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 Mon Jul 27 10:32:34 2020 From: Johan at democon.be (Johan De Clercq) Date: Mon, 27 Jul 2020 12:32:34 +0200 Subject: [OpenSIPS-Users] Opensips MS Teams lost BYE In-Reply-To: References: <000201d65371$ff2ae760$fd80b620$@smartvox.co.uk> <004F21BD-2B66-49E6-B8C4-966231D02993@markmiranda.com> Message-ID: i dont see how you can handle moh and attended transfer with opensips only. On Mon, Jul 27, 2020, 11:31 Chris Johnson wrote: > We were only able to remove one of the fix_nated_contact lines before it > broke more than it did fix. > > > > We’re currently seeking support from Opensips directly to get it all > working correctly. > > > > *From:* Mark Miranda > *Sent:* 24 July 2020 21:21 > *To:* john.quick at smartvox.co.uk; OpenSIPS users mailling list < > users at lists.opensips.org> > *Cc:* Chris Johnson > *Subject:* Re: [OpenSIPS-Users] Opensips MS Teams lost BYE > > > > CAUTION: This email originated from outside of the organisation. Do not > click links or open attachments unless you recognise the sender and know > the content is safe. > > I have basically the same problem where the BYE packet does not seem to be > routing properly, however I am not using any of the nat functions. > > > On Jul 6, 2020, at 3:46 AM, John Quick > wrote: > > > > Chris, > > > > You must not call fix_nated_contact() for any SIP requests or SIP > responses > > coming from MS Teams. > > If you do, it will cause exactly the problems you describe for > loose-routed > > sequential requests such as BYE. > > > > Just to explain: fix_nated_contact() should only be used when the > messages > > come via a NAT router. It must not be used for messages coming from a > Proxy > > (assuming the Proxy adds a Record-Route header, as happens with Teams), > even > > though both cases may appear to need fixing when you use nat_uac_test(). > > > > John Quick > > Smartvox Limited > > Web: www.smartvox.co.uk > > > >> I've managed to get the PBX to send the BYE to the SBC and it is now > > forwarding on to MS (although MS are not sending a reply but we have > opened > > a case for this). > > > >> We are struggling to get the BYE packet to go back to MS Teams when the > > call is initiated by Teams. > > > > > > _______________________________________________ > > 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: From john.quick at smartvox.co.uk Mon Jul 27 11:54:57 2020 From: john.quick at smartvox.co.uk (John Quick) Date: Mon, 27 Jul 2020 12:54:57 +0100 Subject: [OpenSIPS-Users] Opensips MS Teams lost BYE Message-ID: <000b01d6640c$bfd79490$3f86bdb0$@smartvox.co.uk> Chris, it is not about removing lines from the script. It is about not executing those lines when they are inappropriate. i.e. "for any SIP requests or SIP responses coming from MS Teams" Mark, there are several gotchas that I know of with Teams, but I cannot guess which might apply in your case unless you are able to supply more details. Is your problem with calls from Teams? Which end is hanging up first and generating the BYE? Has a loose routed SIP request already got through okay in that direction - e.g. ACK? Did you leave the call connected for at least 30 seconds to make sure the call setup worked? Here are some of the gotchas I know about that are not fully covered in the blog: *The double RR headers using FQDN mentioned in the blog must be added to initial INVITE requests to and from the Teams Proxy - calls in *both* directions *Version 2.4.7 of OpenSIPS (and some v3 releases) have a bug that means RR parameters are not always added - e.g. "r2=on" *Do not send RR headers to Teams with ";lr=on" as can happen if you have a Kamailio Proxy in the path. It must just be ";lr" *Don't call fix_nated_contact for any SIP request or response coming from MS Teams *Don't let any downstream Proxy call fix_nated_contact for those requests either *If you want an easy life, remove REFER from the Allow header in INVITE's to Teams and in 200 OK responses being returned to it I used the siptrace module to capture the SIP packets passing between my SBC and the Teams Proxy because I had no luck with sngrep decrypting the TLS even when I pointed it to the certificate key. You need to be able to inspect those packets to make sure the headers look correct, the ports and protocols are as expected, etc. In the case of BYE not getting a response, you could check exactly what is in the Via headers within the BYE. John Quick Smartvox Limited Web: www.smartvox.co.uk From chandan.pr at webshar.org Mon Jul 27 12:33:15 2020 From: chandan.pr at webshar.org (Chandan PR) Date: Mon, 27 Jul 2020 18:03:15 +0530 Subject: [OpenSIPS-Users] OpenSips Load balancer. - Overcome limitations of Call Driven Load Balancing In-Reply-To: References: Message-ID: Hi Jon, and All While I was thinking through this approach, one question popped up in my thought. Since we run on a full load most of the hours, even if we limit the number of calls to the faulty destination, it is very much possible that call drain can happen as the faulty destination errors out immediately. The only option to make sure the faulty destination doesn't get any calls is by disabling it right.. Let me know what you think. On Fri, Jul 24, 2020 at 7:42 PM Jon Abrams wrote: > Hi Chandan, > > There may be something else purpose built for this, but you can use > the dialog profiles to track and limit the port usage: > > set_dlg_profile("outcarrier","$avp(out_carrier_id)"); > > if ($avp(out_max_call_limit) > 0) > { > set_dlg_profile("profile","$avp(out_qos_profile_id)"); > if > (get_profile_size("profile","$avp(out_qos_profile_id)","$var(out_gw_count)")) > { > if ($var(out_gw_count)>$avp(out_max_call_limit)) > { > xlog("LIMIT: Call $ci - Max call limit hit by > $avp(src_addr) on QosProfile $avp(out_qos_profile_id) to gw > $avp(out_gw_id)\n"); > return(-1); > } > } > } > > On Fri, Jul 24, 2020 at 8:55 AM Chandan PR wrote: > > > > Hello Everyone, > > > > Currently, we are using Open Sips Load balancer in Call Driven load > balancing. > > > > Our scenario is as below: > > > > D - Total Destinations configured at OpenSips > > P - No of Ports/Sessions Each Destination can handle concurrently > > C - Total Capacity = D*P > > > > We have a Call Loader which loads calls to OpenSips at C and as when the > result comes further calls get loaded. > > For some reason, if any destination is not in the right state and sends > error responses without accepting calls, this introduces a drain scenario. > > In the drain scenario where all new calls are given to the faulty > destination as it has more availability. > > > > We are currently handling this by > > > > Running the loader at 80% of C > > Disabling the destination in Opensips if 75% of the calls fail for the > particular destination (Attached loadbalancer.cfg file). > > > > > > But even in this case, it is possible that may call error out as the > destination is free and calls are loaded. > > > > We would like to avoid this scenario to the max possible extent by > limiting the number of calls we send to this particular destination. > > > > Couple of options I see are as below: > > > > Wait for a brief period before sending the response to loader when the > error happens > > Make OpenSips aware of the destination capacity and adjust ports > accordingly > > > > Write a custom script to poll destination capacity and use MI functions > to adjust accordingly > > Or is there any possibility to integrate similar to FreeSwitch driven > routing > > > > Are there any other possibilities of adjusting the OpenSips capacity > dynamically or make it limit the calls sent to the particular destination? > > > > -- > > > > Regards, > > Chandan Ravishankar > > _______________________________________________ > > 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, Chandan Ravishankar -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Tue Jul 28 07:54:57 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Tue, 28 Jul 2020 08:54:57 +0100 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - DB version table error Message-ID: Getting version table errors on startup after move to 3.1... ERROR:core:db_check_table_version: invalid version 10 for table dialog found, expected 11 Version 3.1 is built from 3.1 branch on GitHub. I think I've followed the documentation correctly but OpenSIPS 3.1 is not starting and I'm seeing this error. On our test setup I've tried both... opensips-cli -x database migrate 3.0_to_3.1 opensips opensips_3_1 and opensips-cli -x database create opensips-3_1 Using DB opensips-3_1, a 'SELECT * FROM version;' gives the following... after database migration: +------------------+---------------+ | table_name | table_version | +------------------+---------------+ | acc | 7 | | address | 5 | | clusterer | 4 | | dbaliases | 2 | | dialog | 10 | | dialplan | 5 | | dispatcher | 8 | | domain | 3 | | dr_carriers | 2 | | dr_gateways | 6 | | dr_groups | 2 | | dr_partitions | 1 | | dr_rules | 3 | | grp | 3 | | load_balancer | 2 | | location | 1013 | | missed_calls | 5 | | re_grp | 2 | | rtpengine | 1 | | rtpproxy_sockets | 0 | | silo | 6 | | speed_dial | 3 | | subscriber | 7 | | tls_mgm | 3 | | uri | 2 | | usr_preferences | 3 | +------------------+---------------+ after database creation: +------------------+---------------+ | table_name | table_version | +------------------+---------------+ | acc | 7 | | address | 5 | | clusterer | 4 | | dbaliases | 2 | | dialog | 10 | | dialplan | 5 | | dispatcher | 8 | | domain | 3 | | dr_carriers | 2 | | dr_gateways | 6 | | dr_groups | 2 | | dr_partitions | 1 | | dr_rules | 3 | | grp | 3 | | load_balancer | 2 | | location | 1013 | | missed_calls | 5 | | re_grp | 2 | | rtpengine | 1 | | rtpproxy_sockets | 0 | | silo | 6 | | speed_dial | 3 | | subscriber | 7 | | tls_mgm | 3 | | uri | 2 | | usr_preferences | 3 | +------------------+---------------+ What am I missing???? Documentation used: https://github.com/OpenSIPS/opensips/blob/master/INSTALL https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Tue Jul 28 08:00:55 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Tue, 28 Jul 2020 09:00:55 +0100 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - DB version table error In-Reply-To: References: Message-ID: Presumably, there's somewhere that I should be telling opensips-cli that I want it to use the 3.1 schema? On Tue, 28 Jul 2020 at 08:54, Mark Allen wrote: > Getting version table errors on startup after move to 3.1... > > ERROR:core:db_check_table_version: invalid version 10 for table dialog > found, expected 11 > > Version 3.1 is built from 3.1 branch on GitHub. I think I've followed the > documentation correctly but OpenSIPS 3.1 is not starting and I'm seeing > this error. On our test setup I've tried both... > > opensips-cli -x database migrate 3.0_to_3.1 opensips opensips_3_1 > > and > > opensips-cli -x database create opensips-3_1 > > > Using DB opensips-3_1, a 'SELECT * FROM version;' gives the following... > > after database migration: > +------------------+---------------+ > | table_name | table_version | > +------------------+---------------+ > | acc | 7 | > | address | 5 | > | clusterer | 4 | > | dbaliases | 2 | > | dialog | 10 | > | dialplan | 5 | > | dispatcher | 8 | > | domain | 3 | > | dr_carriers | 2 | > | dr_gateways | 6 | > | dr_groups | 2 | > | dr_partitions | 1 | > | dr_rules | 3 | > | grp | 3 | > | load_balancer | 2 | > | location | 1013 | > | missed_calls | 5 | > | re_grp | 2 | > | rtpengine | 1 | > | rtpproxy_sockets | 0 | > | silo | 6 | > | speed_dial | 3 | > | subscriber | 7 | > | tls_mgm | 3 | > | uri | 2 | > | usr_preferences | 3 | > +------------------+---------------+ > > after database creation: > +------------------+---------------+ > | table_name | table_version | > +------------------+---------------+ > | acc | 7 | > | address | 5 | > | clusterer | 4 | > | dbaliases | 2 | > | dialog | 10 | > | dialplan | 5 | > | dispatcher | 8 | > | domain | 3 | > | dr_carriers | 2 | > | dr_gateways | 6 | > | dr_groups | 2 | > | dr_partitions | 1 | > | dr_rules | 3 | > | grp | 3 | > | load_balancer | 2 | > | location | 1013 | > | missed_calls | 5 | > | re_grp | 2 | > | rtpengine | 1 | > | rtpproxy_sockets | 0 | > | silo | 6 | > | speed_dial | 3 | > | subscriber | 7 | > | tls_mgm | 3 | > | uri | 2 | > | usr_preferences | 3 | > +------------------+---------------+ > > What am I missing???? > > Documentation used: > https://github.com/OpenSIPS/opensips/blob/master/INSTALL > https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Tue Jul 28 08:10:26 2020 From: liviu at opensips.org (Liviu Chircu) Date: Tue, 28 Jul 2020 11:10:26 +0300 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - DB version table error In-Reply-To: References: Message-ID: On 28.07.2020 11:00, Mark Allen wrote: > Presumably, there's somewhere that I should be telling opensips-cli > that I want it to use the 3.1 schema? Hey, Mark! That seems to be the problem, indeed.  I assume you haven't yet installed the 3.1 opensips-mysql-module package, so the CLI can find the new schema under /usr/local/share/opensips/mysql. Alternatively, if you have a 3.1 source tree, just force the "database_schema_path" CLI argument [1] and it should pick up the new tables. Hope this helps, [1]: https://github.com/OpenSIPS/opensips-cli/blob/master/docs/modules/database.md#database-migration-mysql-only -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed From mark at allenclan.co.uk Tue Jul 28 08:13:14 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Tue, 28 Jul 2020 09:13:14 +0100 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - DB version table error In-Reply-To: References: Message-ID: [SOLVED] Scratch that. I answered my own question. I realised that I had missed the document https://github.com/OpenSIPS/opensips-cli/blob/master/docs/modules/database.md I ran the command... opensips-cli -o database_schema_path=~/src/opensips-3.1/scripts \ -x database migrate 3.0_to_3.1 opensips opensips_mig_3_1 ...which seems to have upgraded to the correct version On Tue, 28 Jul 2020 at 09:00, Mark Allen wrote: > Presumably, there's somewhere that I should be telling opensips-cli that I > want it to use the 3.1 schema? > > On Tue, 28 Jul 2020 at 08:54, Mark Allen wrote: > >> Getting version table errors on startup after move to 3.1... >> >> ERROR:core:db_check_table_version: invalid version 10 for table >> dialog found, expected 11 >> >> Version 3.1 is built from 3.1 branch on GitHub. I think I've followed the >> documentation correctly but OpenSIPS 3.1 is not starting and I'm seeing >> this error. On our test setup I've tried both... >> >> opensips-cli -x database migrate 3.0_to_3.1 opensips opensips_3_1 >> >> and >> >> opensips-cli -x database create opensips-3_1 >> >> >> Using DB opensips-3_1, a 'SELECT * FROM version;' gives the following... >> >> after database migration: >> +------------------+---------------+ >> | table_name | table_version | >> +------------------+---------------+ >> | acc | 7 | >> | address | 5 | >> | clusterer | 4 | >> | dbaliases | 2 | >> | dialog | 10 | >> | dialplan | 5 | >> | dispatcher | 8 | >> | domain | 3 | >> | dr_carriers | 2 | >> | dr_gateways | 6 | >> | dr_groups | 2 | >> | dr_partitions | 1 | >> | dr_rules | 3 | >> | grp | 3 | >> | load_balancer | 2 | >> | location | 1013 | >> | missed_calls | 5 | >> | re_grp | 2 | >> | rtpengine | 1 | >> | rtpproxy_sockets | 0 | >> | silo | 6 | >> | speed_dial | 3 | >> | subscriber | 7 | >> | tls_mgm | 3 | >> | uri | 2 | >> | usr_preferences | 3 | >> +------------------+---------------+ >> >> after database creation: >> +------------------+---------------+ >> | table_name | table_version | >> +------------------+---------------+ >> | acc | 7 | >> | address | 5 | >> | clusterer | 4 | >> | dbaliases | 2 | >> | dialog | 10 | >> | dialplan | 5 | >> | dispatcher | 8 | >> | domain | 3 | >> | dr_carriers | 2 | >> | dr_gateways | 6 | >> | dr_groups | 2 | >> | dr_partitions | 1 | >> | dr_rules | 3 | >> | grp | 3 | >> | load_balancer | 2 | >> | location | 1013 | >> | missed_calls | 5 | >> | re_grp | 2 | >> | rtpengine | 1 | >> | rtpproxy_sockets | 0 | >> | silo | 6 | >> | speed_dial | 3 | >> | subscriber | 7 | >> | tls_mgm | 3 | >> | uri | 2 | >> | usr_preferences | 3 | >> +------------------+---------------+ >> >> What am I missing???? >> >> Documentation used: >> https://github.com/OpenSIPS/opensips/blob/master/INSTALL >> https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Tue Jul 28 08:15:52 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Tue, 28 Jul 2020 09:15:52 +0100 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - DB version table error In-Reply-To: References: Message-ID: Thanks Liviu. That worked. On Tue, 28 Jul 2020 at 09:12, Liviu Chircu wrote: > On 28.07.2020 11:00, Mark Allen wrote: > > Presumably, there's somewhere that I should be telling opensips-cli > > that I want it to use the 3.1 schema? > > Hey, Mark! > > That seems to be the problem, indeed. I assume you haven't yet > installed the 3.1 opensips-mysql-module package, so the CLI can find the > new schema under /usr/local/share/opensips/mysql. Alternatively, if you > have a 3.1 source tree, just force the "database_schema_path" CLI > argument [1] and it should pick up the new tables. > > Hope this helps, > > [1]: > > https://github.com/OpenSIPS/opensips-cli/blob/master/docs/modules/database.md#database-migration-mysql-only > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > OpenSIPS Summit 2020 Distributed > www.opensips.org/events/Summit-2020Distributed > > > _______________________________________________ > 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 grantbagdasarian at gmail.com Tue Jul 28 08:50:26 2020 From: grantbagdasarian at gmail.com (Grant Bagdasarian) Date: Tue, 28 Jul 2020 10:50:26 +0200 Subject: [OpenSIPS-Users] t_new_request from event_route and timer_route Message-ID: Hi, OpenSips doesn't allow the t_new_request function to be used from event_route, or timer_route, but the following does work: event_route[E_SOME_EVENT] { route(SEND_REQUEST); } timer_route[some_timer, 10] { route(SEND_REQUEST); } route[SEND_REQUEST] { t_new_request(); } Is there a reason for this? Why not just allow t_new_request from both event_route and timer_route directly. From mark at allenclan.co.uk Tue Jul 28 13:56:57 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Tue, 28 Jul 2020 14:56:57 +0100 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - raise_event() crashes OpenSIPS with segmentation fault Message-ID: We're upgrading from 3.0 to 3.1. Everything seems ok except we get a weird error. We subscribe a dynamic event... startup_route { subscribe_event("E_WFC_REGISTERED", "udp:127.0.0.1:8888"); } which we can see works from /var/log/syslog... event_datagram:mod_init: initializing module ... core:evi_publish_event: Registered event 8b 46 08 48 85 c0 74 0b 48 83 78 18 00 0f 84 a5 02 00 00 e8 34 INFO:core:handle_sigs: child process 10525 exited by a signal 11 INFO:core:handle_sigs: core was generated INFO:core:handle_sigs: terminating due to SIGCHLD If I comment out the raise_event() line - OpenSIPS seems fine and doesn't crash when passing through this code. Running gdb to get core file backtrace we see... Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid -f /etc/opensips/opensips.cfg'. Program terminated with signal SIGSEGV, Segmentation fault. #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id at entry=0, extra_param_k=extra_param_k at entry=0x0, extra_param_v=extra_param_v at entry=0x0) at evi/evi_transport.c:159 159 if (params->first && !params->first->name.s) { (gdb) bt full #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id at entry=0, extra_param_k=extra_param_k at entry=0x0, extra_param_v=extra_param_v at entry=0x0) at evi/evi_transport.c:159 param = param_obj = 0x0 tmp = ret_obj = 0x7f9323135fe0 payload = 0x0 __FUNCTION__ = "evi_build_payload" #1 0x00007f931b7d934f in datagram_raise (msg=, ev_name=, sock=0x7f931f5c54c8, params=) at event_datagram.c:315 ret = buf = __FUNCTION__ = "datagram_raise" #2 0x000055cef82148fb in evi_raise_event_msg (msg=msg at entry=0x7f9323134890, id=id at entry=20, params=params at entry=0x0) at evi/event_interface.c:208 subs = 0x7f931f5c55a8 prev = now = 1595943308 flags = 1073741838 pflags = 0 ret = 0 __FUNCTION__ = "evi_raise_event_msg" #3 0x000055cef8216afb in evi_raise_script_event (msg=0x7f9323134890, id=20, _a=, _v=) at evi/event_interface.c:430 vals = attrs = v_avp = a_avp = err = val = {n = 587654904, s = {s = 0x7f932306e6f8 "\002", len = -133061172}} attr = {n = 0, s = {s = 0x0, len = -133445686}} at = params = 0x0 __FUNCTION__ = "evi_raise_script_event" #4 0x000055cef8068c5f in w_raise_event (msg=, ev_id=, attrs_avp=, vals_avp=) at core_cmds.c:1204 __FUNCTION__ = "w_raise_event" #5 0x000055cef8086199 in do_action (a=0x7f932304d020, msg=0x7f9323134890) at action.c:972 ret = v = i = len = cmatch = aitem = adefault = spec = val = {rs = {s = 0x7f932304c748 "\002", len = 0}, ri = -129751552, flags = 21966} start = {tv_sec = 94347416839552, tv_usec = 140269924432168} end_time = cmd = 0x55cef832c550 acmd = cmdp = {0x14, 0x7f932304cf88, 0x0, 0x2, 0x7f9323134890, 0x55cef80bb253 , 0x1, 0xc} tmp_vals = {{rs = {s = 0x400000000 , len = 587509104}, ri = 18, flags = 0}, {rs = {s = 0x7f9323134890 "\001", len = 587509104}, ri = 588466320, flags = 32659}, {rs = {s = 0x55cef8442600 <_oser_err_info> "", len = -133061748}, ri = -131568035, flags = 21966}, {rs = {s = 0x3 , len = 587512256}, ri = 3, flags = 0}, {rs = {s = 0x7ffcdf4d3790 "\220H\023#\223\177", len = 587509104}, ri = -131568035, flags = 21966}, {rs = {s = 0x3 , len = 0}, ri = 587655824, flags = 32659}, {rs = {s = 0x0, len = 588466320}, ri = 0, flags = 0}, {rs = {s = 0x55cef80baba7 "A\211\304D\213\005\277\355'", len = 593194504}, ri = 2, flags = 0}} sval = {s = 0x7ffcdf4d3730 "]n(\370\316U", len = 587515424} __FUNCTION__ = "do_action" (full backtrace is available) Build is taken from 3.1 branch on GitHub Server is running Debian 10 (Buster) -------------- next part -------------- An HTML attachment was scrubbed... URL: From staskobzar at gmail.com Tue Jul 28 14:19:20 2020 From: staskobzar at gmail.com (Stas Kobzar) Date: Tue, 28 Jul 2020 10:19:20 -0400 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - raise_event() crashes OpenSIPS with segmentation fault In-Reply-To: References: Message-ID: Hi Allen, Did you try with two parameters: name, value? *$avp(keys) = "registered";* $avp(values) = "true"; xlog("Raised E_WFC_REGISTERED $avp(values)"); raise_event("E_WFC_REGISTERED", *$avp(keys)*, $avp(values)); I know they are said to be optional in the documentation but probably it is optional for two. Either no params or if you pass parameters, you have to pass both. On Tue, Jul 28, 2020 at 9:59 AM Mark Allen wrote: > We're upgrading from 3.0 to 3.1. Everything seems ok except we get a weird > error. We subscribe a dynamic event... > > startup_route { > subscribe_event("E_WFC_REGISTERED", "udp:127.0.0.1:8888"); > } > > which we can see works from /var/log/syslog... > > event_datagram:mod_init: initializing module ... > core:evi_publish_event: Registered event > and in the script we invoke it with... > > if(is_method("REGISTER")) { > $avp(values) = "true"; > xlog("Raised E_WFC_REGISTERED $avp(values)"); > raise_event("E_WFC_REGISTERED",$avp(values)); > > When a phone registers, raise_event() is triggered and OpenSIPS crashes > with a segmentation fault - shown in /var/log/syslog... > > Raised E_WFC_REGISTERED true > CRITICAL:core:sig_usr: segfault in process pid: 10525, id: 8 > segfault at 8 ip 000055cef821313f sp 00007ffcdf4d3410 error 4 in > opensips[55cef801a000+264000] > kernel: [197593.785622] Code: 0e 00 4c 89 ef e8 1b 70 fc ff 49 63 74 > 24 08 49 8b 3c 24 e8 51 a1 fc ff 48 89 c2 48 8d 35 8f 0d 07 00 4c 89 ef e8 > fb 6f fc ff <49> 8b 46 08 48 85 c0 74 0b 48 83 78 18 00 0f 84 a5 02 00 00 > e8 34 > INFO:core:handle_sigs: child process 10525 exited by a signal 11 > INFO:core:handle_sigs: core was generated > INFO:core:handle_sigs: terminating due to SIGCHLD > > If I comment out the raise_event() line - OpenSIPS seems fine and doesn't > crash when passing through this code. > > > > Running gdb to get core file backtrace we see... > > Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid -f > /etc/opensips/opensips.cfg'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id at entry=0, > extra_param_k=extra_param_k at entry=0x0, > extra_param_v=extra_param_v at entry=0x0) at evi/evi_transport.c:159 > 159 if (params->first && !params->first->name.s) { > (gdb) bt full > #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id at entry=0, > extra_param_k=extra_param_k at entry=0x0, > extra_param_v=extra_param_v at entry=0x0) at evi/evi_transport.c:159 > param = > param_obj = 0x0 > tmp = > ret_obj = 0x7f9323135fe0 > payload = 0x0 > __FUNCTION__ = "evi_build_payload" > #1 0x00007f931b7d934f in datagram_raise (msg=, > ev_name=, sock=0x7f931f5c54c8, params=) > at event_datagram.c:315 > ret = > buf = > __FUNCTION__ = "datagram_raise" > #2 0x000055cef82148fb in evi_raise_event_msg (msg=msg at entry=0x7f9323134890, > id=id at entry=20, params=params at entry=0x0) > at evi/event_interface.c:208 > subs = 0x7f931f5c55a8 > prev = > now = 1595943308 > flags = 1073741838 > pflags = 0 > ret = 0 > __FUNCTION__ = "evi_raise_event_msg" > #3 0x000055cef8216afb in evi_raise_script_event (msg=0x7f9323134890, > id=20, _a=, _v=) > at evi/event_interface.c:430 > vals = > attrs = > v_avp = > a_avp = > err = > val = {n = 587654904, s = {s = 0x7f932306e6f8 "\002", len = > -133061172}} > attr = {n = 0, s = {s = 0x0, len = -133445686}} > at = > params = 0x0 > __FUNCTION__ = "evi_raise_script_event" > #4 0x000055cef8068c5f in w_raise_event (msg=, > ev_id=, attrs_avp=, > vals_avp=) at core_cmds.c:1204 > __FUNCTION__ = "w_raise_event" > #5 0x000055cef8086199 in do_action (a=0x7f932304d020, msg=0x7f9323134890) > at action.c:972 > ret = > v = > i = > len = > cmatch = > aitem = > adefault = > spec = > val = {rs = {s = 0x7f932304c748 "\002", len = 0}, ri = -129751552, > flags = 21966} > start = {tv_sec = 94347416839552, tv_usec = 140269924432168} > end_time = > cmd = 0x55cef832c550 > acmd = > cmdp = {0x14, 0x7f932304cf88, 0x0, 0x2, 0x7f9323134890, > 0x55cef80bb253 , 0x1, 0xc} > tmp_vals = {{rs = {s = 0x400000000 address 0x400000000>, len = 587509104}, ri = 18, flags = 0}, {rs = {s = > 0x7f9323134890 "\001", len = 587509104}, ri = 588466320, flags = 32659}, > {rs = {s = 0x55cef8442600 <_oser_err_info> "", len = -133061748}, ri = > -131568035, flags = 21966}, {rs = {s = 0x3 address 0x3>, len = 587512256}, ri = 3, flags = 0}, {rs = {s = > 0x7ffcdf4d3790 "\220H\023#\223\177", len = 587509104}, ri = -131568035, > flags = 21966}, {rs = {s = 0x3 0x3>, len = 0}, ri = 587655824, flags = 32659}, {rs = {s = 0x0, len = > 588466320}, ri = 0, flags = 0}, {rs = {s = 0x55cef80baba7 > "A\211\304D\213\005\277\355'", len = 593194504}, ri = 2, flags = 0}} > sval = {s = 0x7ffcdf4d3730 "]n(\370\316U", len = 587515424} > __FUNCTION__ = "do_action" > > (full backtrace is available) > > Build is taken from 3.1 branch on GitHub > Server is running Debian 10 (Buster) > > > _______________________________________________ > 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 mrsanvicente at gmail.com Tue Jul 28 14:34:26 2020 From: mrsanvicente at gmail.com (Mario San Vicente) Date: Tue, 28 Jul 2020 09:34:26 -0500 Subject: [OpenSIPS-Users] Opensips + rtpengine benchmark Message-ID: Hello Everyone, Looking to have a rock solid cluster. i have been working for opensips for long time and it is very stable. But this time i plan to run it with rtpengine. Would you recommend having a cluster on two bare metal servers? Or have two Virtual machines as cluster on a bigger server? And how much CPUs / RAM, would you recommend for around 8,000 simultaneous calls? Thanks for your inputs. -- Mario San Vicente Cheers! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at allenclan.co.uk Tue Jul 28 14:42:29 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Tue, 28 Jul 2020 15:42:29 +0100 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - raise_event() crashes OpenSIPS with segmentation fault In-Reply-To: References: Message-ID: [SOLVED] Hi Stas - good call! It's a change in behaviour from 3.0. In 3.0 documentation says... The next two parameters should be AVPs and they are optional. If only one is present, it should contain the values attached to the event. In 3.1 it removes mention of the behaviour if only one AVP is present, but it's not obvious and perhaps it could be documented in the https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0 guide? Also, perhaps 3.1 should handle it better if parameter is missing rather than giving a segfault (something for 3.2?) Once again I'm indebted to you for your help thanks very much & all the best Mark On Tue, 28 Jul 2020 at 15:22, Stas Kobzar wrote: > Hi Allen, > > Did you try with two parameters: name, value? > > *$avp(keys) = "registered";* > $avp(values) = "true"; > xlog("Raised E_WFC_REGISTERED $avp(values)"); > raise_event("E_WFC_REGISTERED", *$avp(keys)*, $avp(values)); > > I know they are said to be optional in the documentation but probably it > is optional for two. Either no params or if you pass parameters, you have > to pass both. > > > On Tue, Jul 28, 2020 at 9:59 AM Mark Allen wrote: > >> We're upgrading from 3.0 to 3.1. Everything seems ok except we get a >> weird error. We subscribe a dynamic event... >> >> startup_route { >> subscribe_event("E_WFC_REGISTERED", "udp:127.0.0.1:8888"); >> } >> >> which we can see works from /var/log/syslog... >> >> event_datagram:mod_init: initializing module ... >> core:evi_publish_event: Registered event > >> and in the script we invoke it with... >> >> if(is_method("REGISTER")) { >> $avp(values) = "true"; >> xlog("Raised E_WFC_REGISTERED $avp(values)"); >> raise_event("E_WFC_REGISTERED",$avp(values)); >> >> When a phone registers, raise_event() is triggered and OpenSIPS crashes >> with a segmentation fault - shown in /var/log/syslog... >> >> Raised E_WFC_REGISTERED true >> CRITICAL:core:sig_usr: segfault in process pid: 10525, id: 8 >> segfault at 8 ip 000055cef821313f sp 00007ffcdf4d3410 error 4 in >> opensips[55cef801a000+264000] >> kernel: [197593.785622] Code: 0e 00 4c 89 ef e8 1b 70 fc ff 49 63 74 >> 24 08 49 8b 3c 24 e8 51 a1 fc ff 48 89 c2 48 8d 35 8f 0d 07 00 4c 89 ef e8 >> fb 6f fc ff <49> 8b 46 08 48 85 c0 74 0b 48 83 78 18 00 0f 84 a5 02 00 00 >> e8 34 >> INFO:core:handle_sigs: child process 10525 exited by a signal 11 >> INFO:core:handle_sigs: core was generated >> INFO:core:handle_sigs: terminating due to SIGCHLD >> >> If I comment out the raise_event() line - OpenSIPS seems fine and >> doesn't crash when passing through this code. >> >> >> >> Running gdb to get core file backtrace we see... >> >> Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid >> -f /etc/opensips/opensips.cfg'. >> Program terminated with signal SIGSEGV, Segmentation fault. >> #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id at entry=0, >> extra_param_k=extra_param_k at entry=0x0, >> extra_param_v=extra_param_v at entry=0x0) at evi/evi_transport.c:159 >> 159 if (params->first && !params->first->name.s) { >> (gdb) bt full >> #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id at entry=0, >> extra_param_k=extra_param_k at entry=0x0, >> extra_param_v=extra_param_v at entry=0x0) at evi/evi_transport.c:159 >> param = >> param_obj = 0x0 >> tmp = >> ret_obj = 0x7f9323135fe0 >> payload = 0x0 >> __FUNCTION__ = "evi_build_payload" >> #1 0x00007f931b7d934f in datagram_raise (msg=, >> ev_name=, sock=0x7f931f5c54c8, params=) >> at event_datagram.c:315 >> ret = >> buf = >> __FUNCTION__ = "datagram_raise" >> #2 0x000055cef82148fb in evi_raise_event_msg (msg=msg at entry=0x7f9323134890, >> id=id at entry=20, params=params at entry=0x0) >> at evi/event_interface.c:208 >> subs = 0x7f931f5c55a8 >> prev = >> now = 1595943308 >> flags = 1073741838 >> pflags = 0 >> ret = 0 >> __FUNCTION__ = "evi_raise_event_msg" >> #3 0x000055cef8216afb in evi_raise_script_event (msg=0x7f9323134890, >> id=20, _a=, _v=) >> at evi/event_interface.c:430 >> vals = >> attrs = >> v_avp = >> a_avp = >> err = >> val = {n = 587654904, s = {s = 0x7f932306e6f8 "\002", len = >> -133061172}} >> attr = {n = 0, s = {s = 0x0, len = -133445686}} >> at = >> params = 0x0 >> __FUNCTION__ = "evi_raise_script_event" >> #4 0x000055cef8068c5f in w_raise_event (msg=, >> ev_id=, attrs_avp=, >> vals_avp=) at core_cmds.c:1204 >> __FUNCTION__ = "w_raise_event" >> #5 0x000055cef8086199 in do_action (a=0x7f932304d020, >> msg=0x7f9323134890) at action.c:972 >> ret = >> v = >> i = >> len = >> cmatch = >> aitem = >> adefault = >> spec = >> val = {rs = {s = 0x7f932304c748 "\002", len = 0}, ri = >> -129751552, flags = 21966} >> start = {tv_sec = 94347416839552, tv_usec = 140269924432168} >> end_time = >> cmd = 0x55cef832c550 >> acmd = >> cmdp = {0x14, 0x7f932304cf88, 0x0, 0x2, 0x7f9323134890, >> 0x55cef80bb253 , 0x1, 0xc} >> tmp_vals = {{rs = {s = 0x400000000 > at address 0x400000000>, len = 587509104}, ri = 18, flags = 0}, {rs = {s = >> 0x7f9323134890 "\001", len = 587509104}, ri = 588466320, flags = 32659}, >> {rs = {s = 0x55cef8442600 <_oser_err_info> "", len = -133061748}, ri = >> -131568035, flags = 21966}, {rs = {s = 0x3 > address 0x3>, len = 587512256}, ri = 3, flags = 0}, {rs = {s = >> 0x7ffcdf4d3790 "\220H\023#\223\177", len = 587509104}, ri = -131568035, >> flags = 21966}, {rs = {s = 0x3 > 0x3>, len = 0}, ri = 587655824, flags = 32659}, {rs = {s = 0x0, len = >> 588466320}, ri = 0, flags = 0}, {rs = {s = 0x55cef80baba7 >> "A\211\304D\213\005\277\355'", len = 593194504}, ri = 2, flags = 0}} >> sval = {s = 0x7ffcdf4d3730 "]n(\370\316U", len = 587515424} >> __FUNCTION__ = "do_action" >> >> (full backtrace is available) >> >> Build is taken from 3.1 branch on GitHub >> Server is running Debian 10 (Buster) >> >> >> _______________________________________________ >> 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: From staskobzar at gmail.com Tue Jul 28 14:47:12 2020 From: staskobzar at gmail.com (Stas Kobzar) Date: Tue, 28 Jul 2020 10:47:12 -0400 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - raise_event() crashes OpenSIPS with segmentation fault In-Reply-To: References: Message-ID: Glad it helped. You are welcome, Allen On Tue, Jul 28, 2020 at 10:45 AM Mark Allen wrote: > [SOLVED] > > Hi Stas - good call! It's a change in behaviour from 3.0. > > In 3.0 documentation says... > > The next two parameters should be AVPs and they are optional. If only > one is present, it should contain the values attached to the event. > > In 3.1 it removes mention of the behaviour if only one AVP is present, but > it's not obvious and perhaps it could be documented in the > https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0 guide? > Also, perhaps 3.1 should handle it better if parameter is missing rather > than giving a segfault (something for 3.2?) > > Once again I'm indebted to you for your help > > thanks very much & all the best > > Mark > > > > > > On Tue, 28 Jul 2020 at 15:22, Stas Kobzar wrote: > >> Hi Allen, >> >> Did you try with two parameters: name, value? >> >> *$avp(keys) = "registered";* >> $avp(values) = "true"; >> xlog("Raised E_WFC_REGISTERED $avp(values)"); >> raise_event("E_WFC_REGISTERED", *$avp(keys)*, $avp(values)); >> >> I know they are said to be optional in the documentation but probably it >> is optional for two. Either no params or if you pass parameters, you have >> to pass both. >> >> >> On Tue, Jul 28, 2020 at 9:59 AM Mark Allen wrote: >> >>> We're upgrading from 3.0 to 3.1. Everything seems ok except we get a >>> weird error. We subscribe a dynamic event... >>> >>> startup_route { >>> subscribe_event("E_WFC_REGISTERED", "udp:127.0.0.1:8888"); >>> } >>> >>> which we can see works from /var/log/syslog... >>> >>> event_datagram:mod_init: initializing module ... >>> core:evi_publish_event: Registered event >> >>> and in the script we invoke it with... >>> >>> if(is_method("REGISTER")) { >>> $avp(values) = "true"; >>> xlog("Raised E_WFC_REGISTERED $avp(values)"); >>> raise_event("E_WFC_REGISTERED",$avp(values)); >>> >>> When a phone registers, raise_event() is triggered and OpenSIPS crashes >>> with a segmentation fault - shown in /var/log/syslog... >>> >>> Raised E_WFC_REGISTERED true >>> CRITICAL:core:sig_usr: segfault in process pid: 10525, id: 8 >>> segfault at 8 ip 000055cef821313f sp 00007ffcdf4d3410 error 4 in >>> opensips[55cef801a000+264000] >>> kernel: [197593.785622] Code: 0e 00 4c 89 ef e8 1b 70 fc ff 49 63 74 >>> 24 08 49 8b 3c 24 e8 51 a1 fc ff 48 89 c2 48 8d 35 8f 0d 07 00 4c 89 ef e8 >>> fb 6f fc ff <49> 8b 46 08 48 85 c0 74 0b 48 83 78 18 00 0f 84 a5 02 00 00 >>> e8 34 >>> INFO:core:handle_sigs: child process 10525 exited by a signal 11 >>> INFO:core:handle_sigs: core was generated >>> INFO:core:handle_sigs: terminating due to SIGCHLD >>> >>> If I comment out the raise_event() line - OpenSIPS seems fine and >>> doesn't crash when passing through this code. >>> >>> >>> >>> Running gdb to get core file backtrace we see... >>> >>> Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid >>> -f /etc/opensips/opensips.cfg'. >>> Program terminated with signal SIGSEGV, Segmentation fault. >>> #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id at entry=0, >>> extra_param_k=extra_param_k at entry=0x0, >>> extra_param_v=extra_param_v at entry=0x0) at evi/evi_transport.c:159 >>> 159 if (params->first && !params->first->name.s) { >>> (gdb) bt full >>> #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id at entry=0, >>> extra_param_k=extra_param_k at entry=0x0, >>> extra_param_v=extra_param_v at entry=0x0) at evi/evi_transport.c:159 >>> param = >>> param_obj = 0x0 >>> tmp = >>> ret_obj = 0x7f9323135fe0 >>> payload = 0x0 >>> __FUNCTION__ = "evi_build_payload" >>> #1 0x00007f931b7d934f in datagram_raise (msg=, >>> ev_name=, sock=0x7f931f5c54c8, params=) >>> at event_datagram.c:315 >>> ret = >>> buf = >>> __FUNCTION__ = "datagram_raise" >>> #2 0x000055cef82148fb in evi_raise_event_msg (msg=msg at entry=0x7f9323134890, >>> id=id at entry=20, params=params at entry=0x0) >>> at evi/event_interface.c:208 >>> subs = 0x7f931f5c55a8 >>> prev = >>> now = 1595943308 >>> flags = 1073741838 >>> pflags = 0 >>> ret = 0 >>> __FUNCTION__ = "evi_raise_event_msg" >>> #3 0x000055cef8216afb in evi_raise_script_event (msg=0x7f9323134890, >>> id=20, _a=, _v=) >>> at evi/event_interface.c:430 >>> vals = >>> attrs = >>> v_avp = >>> a_avp = >>> err = >>> val = {n = 587654904, s = {s = 0x7f932306e6f8 "\002", len = >>> -133061172}} >>> attr = {n = 0, s = {s = 0x0, len = -133445686}} >>> at = >>> params = 0x0 >>> __FUNCTION__ = "evi_raise_script_event" >>> #4 0x000055cef8068c5f in w_raise_event (msg=, >>> ev_id=, attrs_avp=, >>> vals_avp=) at core_cmds.c:1204 >>> __FUNCTION__ = "w_raise_event" >>> #5 0x000055cef8086199 in do_action (a=0x7f932304d020, >>> msg=0x7f9323134890) at action.c:972 >>> ret = >>> v = >>> i = >>> len = >>> cmatch = >>> aitem = >>> adefault = >>> spec = >>> val = {rs = {s = 0x7f932304c748 "\002", len = 0}, ri = >>> -129751552, flags = 21966} >>> start = {tv_sec = 94347416839552, tv_usec = 140269924432168} >>> end_time = >>> cmd = 0x55cef832c550 >>> acmd = >>> cmdp = {0x14, 0x7f932304cf88, 0x0, 0x2, 0x7f9323134890, >>> 0x55cef80bb253 , 0x1, 0xc} >>> tmp_vals = {{rs = {s = 0x400000000 >> at address 0x400000000>, len = 587509104}, ri = 18, flags = 0}, {rs = {s = >>> 0x7f9323134890 "\001", len = 587509104}, ri = 588466320, flags = 32659}, >>> {rs = {s = 0x55cef8442600 <_oser_err_info> "", len = -133061748}, ri = >>> -131568035, flags = 21966}, {rs = {s = 0x3 >> address 0x3>, len = 587512256}, ri = 3, flags = 0}, {rs = {s = >>> 0x7ffcdf4d3790 "\220H\023#\223\177", len = 587509104}, ri = -131568035, >>> flags = 21966}, {rs = {s = 0x3 >> 0x3>, len = 0}, ri = 587655824, flags = 32659}, {rs = {s = 0x0, len = >>> 588466320}, ri = 0, flags = 0}, {rs = {s = 0x55cef80baba7 >>> "A\211\304D\213\005\277\355'", len = 593194504}, ri = 2, flags = 0}} >>> sval = {s = 0x7ffcdf4d3730 "]n(\370\316U", len = 587515424} >>> __FUNCTION__ = "do_action" >>> >>> (full backtrace is available) >>> >>> Build is taken from 3.1 branch on GitHub >>> Server is running Debian 10 (Buster) >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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 staskobzar at gmail.com Tue Jul 28 14:48:27 2020 From: staskobzar at gmail.com (Stas Kobzar) Date: Tue, 28 Jul 2020 10:48:27 -0400 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - raise_event() crashes OpenSIPS with segmentation fault In-Reply-To: References: Message-ID: I mean, you are welcome, Mark :) sorry On Tue, Jul 28, 2020 at 10:45 AM Mark Allen wrote: > [SOLVED] > > Hi Stas - good call! It's a change in behaviour from 3.0. > > In 3.0 documentation says... > > The next two parameters should be AVPs and they are optional. If only > one is present, it should contain the values attached to the event. > > In 3.1 it removes mention of the behaviour if only one AVP is present, but > it's not obvious and perhaps it could be documented in the > https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0 guide? > Also, perhaps 3.1 should handle it better if parameter is missing rather > than giving a segfault (something for 3.2?) > > Once again I'm indebted to you for your help > > thanks very much & all the best > > Mark > > > > > > On Tue, 28 Jul 2020 at 15:22, Stas Kobzar wrote: > >> Hi Allen, >> >> Did you try with two parameters: name, value? >> >> *$avp(keys) = "registered";* >> $avp(values) = "true"; >> xlog("Raised E_WFC_REGISTERED $avp(values)"); >> raise_event("E_WFC_REGISTERED", *$avp(keys)*, $avp(values)); >> >> I know they are said to be optional in the documentation but probably it >> is optional for two. Either no params or if you pass parameters, you have >> to pass both. >> >> >> On Tue, Jul 28, 2020 at 9:59 AM Mark Allen wrote: >> >>> We're upgrading from 3.0 to 3.1. Everything seems ok except we get a >>> weird error. We subscribe a dynamic event... >>> >>> startup_route { >>> subscribe_event("E_WFC_REGISTERED", "udp:127.0.0.1:8888"); >>> } >>> >>> which we can see works from /var/log/syslog... >>> >>> event_datagram:mod_init: initializing module ... >>> core:evi_publish_event: Registered event >> >>> and in the script we invoke it with... >>> >>> if(is_method("REGISTER")) { >>> $avp(values) = "true"; >>> xlog("Raised E_WFC_REGISTERED $avp(values)"); >>> raise_event("E_WFC_REGISTERED",$avp(values)); >>> >>> When a phone registers, raise_event() is triggered and OpenSIPS crashes >>> with a segmentation fault - shown in /var/log/syslog... >>> >>> Raised E_WFC_REGISTERED true >>> CRITICAL:core:sig_usr: segfault in process pid: 10525, id: 8 >>> segfault at 8 ip 000055cef821313f sp 00007ffcdf4d3410 error 4 in >>> opensips[55cef801a000+264000] >>> kernel: [197593.785622] Code: 0e 00 4c 89 ef e8 1b 70 fc ff 49 63 74 >>> 24 08 49 8b 3c 24 e8 51 a1 fc ff 48 89 c2 48 8d 35 8f 0d 07 00 4c 89 ef e8 >>> fb 6f fc ff <49> 8b 46 08 48 85 c0 74 0b 48 83 78 18 00 0f 84 a5 02 00 00 >>> e8 34 >>> INFO:core:handle_sigs: child process 10525 exited by a signal 11 >>> INFO:core:handle_sigs: core was generated >>> INFO:core:handle_sigs: terminating due to SIGCHLD >>> >>> If I comment out the raise_event() line - OpenSIPS seems fine and >>> doesn't crash when passing through this code. >>> >>> >>> >>> Running gdb to get core file backtrace we see... >>> >>> Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid >>> -f /etc/opensips/opensips.cfg'. >>> Program terminated with signal SIGSEGV, Segmentation fault. >>> #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id at entry=0, >>> extra_param_k=extra_param_k at entry=0x0, >>> extra_param_v=extra_param_v at entry=0x0) at evi/evi_transport.c:159 >>> 159 if (params->first && !params->first->name.s) { >>> (gdb) bt full >>> #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id at entry=0, >>> extra_param_k=extra_param_k at entry=0x0, >>> extra_param_v=extra_param_v at entry=0x0) at evi/evi_transport.c:159 >>> param = >>> param_obj = 0x0 >>> tmp = >>> ret_obj = 0x7f9323135fe0 >>> payload = 0x0 >>> __FUNCTION__ = "evi_build_payload" >>> #1 0x00007f931b7d934f in datagram_raise (msg=, >>> ev_name=, sock=0x7f931f5c54c8, params=) >>> at event_datagram.c:315 >>> ret = >>> buf = >>> __FUNCTION__ = "datagram_raise" >>> #2 0x000055cef82148fb in evi_raise_event_msg (msg=msg at entry=0x7f9323134890, >>> id=id at entry=20, params=params at entry=0x0) >>> at evi/event_interface.c:208 >>> subs = 0x7f931f5c55a8 >>> prev = >>> now = 1595943308 >>> flags = 1073741838 >>> pflags = 0 >>> ret = 0 >>> __FUNCTION__ = "evi_raise_event_msg" >>> #3 0x000055cef8216afb in evi_raise_script_event (msg=0x7f9323134890, >>> id=20, _a=, _v=) >>> at evi/event_interface.c:430 >>> vals = >>> attrs = >>> v_avp = >>> a_avp = >>> err = >>> val = {n = 587654904, s = {s = 0x7f932306e6f8 "\002", len = >>> -133061172}} >>> attr = {n = 0, s = {s = 0x0, len = -133445686}} >>> at = >>> params = 0x0 >>> __FUNCTION__ = "evi_raise_script_event" >>> #4 0x000055cef8068c5f in w_raise_event (msg=, >>> ev_id=, attrs_avp=, >>> vals_avp=) at core_cmds.c:1204 >>> __FUNCTION__ = "w_raise_event" >>> #5 0x000055cef8086199 in do_action (a=0x7f932304d020, >>> msg=0x7f9323134890) at action.c:972 >>> ret = >>> v = >>> i = >>> len = >>> cmatch = >>> aitem = >>> adefault = >>> spec = >>> val = {rs = {s = 0x7f932304c748 "\002", len = 0}, ri = >>> -129751552, flags = 21966} >>> start = {tv_sec = 94347416839552, tv_usec = 140269924432168} >>> end_time = >>> cmd = 0x55cef832c550 >>> acmd = >>> cmdp = {0x14, 0x7f932304cf88, 0x0, 0x2, 0x7f9323134890, >>> 0x55cef80bb253 , 0x1, 0xc} >>> tmp_vals = {{rs = {s = 0x400000000 >> at address 0x400000000>, len = 587509104}, ri = 18, flags = 0}, {rs = {s = >>> 0x7f9323134890 "\001", len = 587509104}, ri = 588466320, flags = 32659}, >>> {rs = {s = 0x55cef8442600 <_oser_err_info> "", len = -133061748}, ri = >>> -131568035, flags = 21966}, {rs = {s = 0x3 >> address 0x3>, len = 587512256}, ri = 3, flags = 0}, {rs = {s = >>> 0x7ffcdf4d3790 "\220H\023#\223\177", len = 587509104}, ri = -131568035, >>> flags = 21966}, {rs = {s = 0x3 >> 0x3>, len = 0}, ri = 587655824, flags = 32659}, {rs = {s = 0x0, len = >>> 588466320}, ri = 0, flags = 0}, {rs = {s = 0x55cef80baba7 >>> "A\211\304D\213\005\277\355'", len = 593194504}, ri = 2, flags = 0}} >>> sval = {s = 0x7ffcdf4d3730 "]n(\370\316U", len = 587515424} >>> __FUNCTION__ = "do_action" >>> >>> (full backtrace is available) >>> >>> Build is taken from 3.1 branch on GitHub >>> Server is running Debian 10 (Buster) >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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 mark at allenclan.co.uk Tue Jul 28 15:32:16 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Tue, 28 Jul 2020 16:32:16 +0100 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - raise_event() crashes OpenSIPS with segmentation fault In-Reply-To: References: Message-ID: :) On Tue, 28 Jul 2020 at 15:50, Stas Kobzar wrote: > I mean, you are welcome, Mark :) sorry > > On Tue, Jul 28, 2020 at 10:45 AM Mark Allen wrote: > >> [SOLVED] >> >> Hi Stas - good call! It's a change in behaviour from 3.0. >> >> In 3.0 documentation says... >> >> The next two parameters should be AVPs and they are optional. If only >> one is present, it should contain the values attached to the event. >> >> In 3.1 it removes mention of the behaviour if only one AVP is present, >> but it's not obvious and perhaps it could be documented in the >> https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0 guide? >> Also, perhaps 3.1 should handle it better if parameter is missing rather >> than giving a segfault (something for 3.2?) >> >> Once again I'm indebted to you for your help >> >> thanks very much & all the best >> >> Mark >> >> >> >> >> >> On Tue, 28 Jul 2020 at 15:22, Stas Kobzar wrote: >> >>> Hi Allen, >>> >>> Did you try with two parameters: name, value? >>> >>> *$avp(keys) = "registered";* >>> $avp(values) = "true"; >>> xlog("Raised E_WFC_REGISTERED $avp(values)"); >>> raise_event("E_WFC_REGISTERED", *$avp(keys)*, $avp(values)); >>> >>> I know they are said to be optional in the documentation but probably it >>> is optional for two. Either no params or if you pass parameters, you have >>> to pass both. >>> >>> >>> On Tue, Jul 28, 2020 at 9:59 AM Mark Allen wrote: >>> >>>> We're upgrading from 3.0 to 3.1. Everything seems ok except we get a >>>> weird error. We subscribe a dynamic event... >>>> >>>> startup_route { >>>> subscribe_event("E_WFC_REGISTERED", "udp:127.0.0.1:8888"); >>>> } >>>> >>>> which we can see works from /var/log/syslog... >>>> >>>> event_datagram:mod_init: initializing module ... >>>> core:evi_publish_event: Registered event >>> >>>> and in the script we invoke it with... >>>> >>>> if(is_method("REGISTER")) { >>>> $avp(values) = "true"; >>>> xlog("Raised E_WFC_REGISTERED $avp(values)"); >>>> raise_event("E_WFC_REGISTERED",$avp(values)); >>>> >>>> When a phone registers, raise_event() is triggered and OpenSIPS crashes >>>> with a segmentation fault - shown in /var/log/syslog... >>>> >>>> Raised E_WFC_REGISTERED true >>>> CRITICAL:core:sig_usr: segfault in process pid: 10525, id: 8 >>>> segfault at 8 ip 000055cef821313f sp 00007ffcdf4d3410 error 4 in >>>> opensips[55cef801a000+264000] >>>> kernel: [197593.785622] Code: 0e 00 4c 89 ef e8 1b 70 fc ff 49 63 >>>> 74 24 08 49 8b 3c 24 e8 51 a1 fc ff 48 89 c2 48 8d 35 8f 0d 07 00 4c 89 ef >>>> e8 fb 6f fc ff <49> 8b 46 08 48 85 c0 74 0b 48 83 78 18 00 0f 84 a5 02 00 >>>> 00 e8 34 >>>> INFO:core:handle_sigs: child process 10525 exited by a signal 11 >>>> INFO:core:handle_sigs: core was generated >>>> INFO:core:handle_sigs: terminating due to SIGCHLD >>>> >>>> If I comment out the raise_event() line - OpenSIPS seems fine and >>>> doesn't crash when passing through this code. >>>> >>>> >>>> >>>> Running gdb to get core file backtrace we see... >>>> >>>> Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid >>>> -f /etc/opensips/opensips.cfg'. >>>> Program terminated with signal SIGSEGV, Segmentation fault. >>>> #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id at entry=0, >>>> extra_param_k=extra_param_k at entry=0x0, >>>> extra_param_v=extra_param_v at entry=0x0) at evi/evi_transport.c:159 >>>> 159 if (params->first && !params->first->name.s) { >>>> (gdb) bt full >>>> #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id at entry=0, >>>> extra_param_k=extra_param_k at entry=0x0, >>>> extra_param_v=extra_param_v at entry=0x0) at evi/evi_transport.c:159 >>>> param = >>>> param_obj = 0x0 >>>> tmp = >>>> ret_obj = 0x7f9323135fe0 >>>> payload = 0x0 >>>> __FUNCTION__ = "evi_build_payload" >>>> #1 0x00007f931b7d934f in datagram_raise (msg=, >>>> ev_name=, sock=0x7f931f5c54c8, params=) >>>> at event_datagram.c:315 >>>> ret = >>>> buf = >>>> __FUNCTION__ = "datagram_raise" >>>> #2 0x000055cef82148fb in evi_raise_event_msg (msg=msg at entry=0x7f9323134890, >>>> id=id at entry=20, params=params at entry=0x0) >>>> at evi/event_interface.c:208 >>>> subs = 0x7f931f5c55a8 >>>> prev = >>>> now = 1595943308 >>>> flags = 1073741838 >>>> pflags = 0 >>>> ret = 0 >>>> __FUNCTION__ = "evi_raise_event_msg" >>>> #3 0x000055cef8216afb in evi_raise_script_event (msg=0x7f9323134890, >>>> id=20, _a=, _v=) >>>> at evi/event_interface.c:430 >>>> vals = >>>> attrs = >>>> v_avp = >>>> a_avp = >>>> err = >>>> val = {n = 587654904, s = {s = 0x7f932306e6f8 "\002", len = >>>> -133061172}} >>>> attr = {n = 0, s = {s = 0x0, len = -133445686}} >>>> at = >>>> params = 0x0 >>>> __FUNCTION__ = "evi_raise_script_event" >>>> #4 0x000055cef8068c5f in w_raise_event (msg=, >>>> ev_id=, attrs_avp=, >>>> vals_avp=) at core_cmds.c:1204 >>>> __FUNCTION__ = "w_raise_event" >>>> #5 0x000055cef8086199 in do_action (a=0x7f932304d020, >>>> msg=0x7f9323134890) at action.c:972 >>>> ret = >>>> v = >>>> i = >>>> len = >>>> cmatch = >>>> aitem = >>>> adefault = >>>> spec = >>>> val = {rs = {s = 0x7f932304c748 "\002", len = 0}, ri = >>>> -129751552, flags = 21966} >>>> start = {tv_sec = 94347416839552, tv_usec = 140269924432168} >>>> end_time = >>>> cmd = 0x55cef832c550 >>>> acmd = >>>> cmdp = {0x14, 0x7f932304cf88, 0x0, 0x2, 0x7f9323134890, >>>> 0x55cef80bb253 , 0x1, 0xc} >>>> tmp_vals = {{rs = {s = 0x400000000 >>> at address 0x400000000>, len = 587509104}, ri = 18, flags = 0}, {rs = {s = >>>> 0x7f9323134890 "\001", len = 587509104}, ri = 588466320, flags = 32659}, >>>> {rs = {s = 0x55cef8442600 <_oser_err_info> "", len = -133061748}, ri = >>>> -131568035, flags = 21966}, {rs = {s = 0x3 >>> address 0x3>, len = 587512256}, ri = 3, flags = 0}, {rs = {s = >>>> 0x7ffcdf4d3790 "\220H\023#\223\177", len = 587509104}, ri = -131568035, >>>> flags = 21966}, {rs = {s = 0x3 >>> 0x3>, len = 0}, ri = 587655824, flags = 32659}, {rs = {s = 0x0, len = >>>> 588466320}, ri = 0, flags = 0}, {rs = {s = 0x55cef80baba7 >>>> "A\211\304D\213\005\277\355'", len = 593194504}, ri = 2, flags = 0}} >>>> sval = {s = 0x7ffcdf4d3730 "]n(\370\316U", len = 587515424} >>>> __FUNCTION__ = "do_action" >>>> >>>> (full backtrace is available) >>>> >>>> Build is taken from 3.1 branch on GitHub >>>> Server is running Debian 10 (Buster) >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> _______________________________________________ >> 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: From adjolin at gmail.com Tue Jul 28 19:09:15 2020 From: adjolin at gmail.com (Vic Jolin) Date: Wed, 29 Jul 2020 03:09:15 +0800 Subject: [OpenSIPS-Users] How to get the routing rule and gateway list only Message-ID: Hi, So I have a LRN number from a lrn dipping service and so I set $rU = $avp(reply); and then I have if ( !do_routing(1,"F",,,$var(gw_attributes)) ) { my question is, the LRN number is being dialed instead of the orig dialed number, is it proper to just get the routing rules and carriers when doing routing and then still set orig number to be dialed? What is the proper way to do this? What we want is to determine the routes using the LRN number, but still dial the orig phone. thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladp at opensips.org Tue Jul 28 20:37:51 2020 From: vladp at opensips.org (Vlad Patrascu) Date: Tue, 28 Jul 2020 23:37:51 +0300 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - raise_event() crashes OpenSIPS with segmentation fault In-Reply-To: References: Message-ID: <786fc5b1-f3e6-6700-41ed-10a7a639a1d6@opensips.org> Hi Mark, thanks for the report! I have pushed a fix for the crash. I've also updated the documentation to be more clear about how raise_event() should be used and the changes from 3.0. Basically, you don't have to necessarily pass both AVP parameters in 3.1, but if you want to pass only the attribute values for the event you should do: raise_event("E_WFC_REGISTERED", , $avp(values)); That is because the event attribute values can now only be passed through the corresponding parameter(which is the last one). The way you did it initially was equivalent to passing only the event attribute names which in 3.1 results in an event with no attributes at all. This in turn was unfortunately causing a crash. Regards, -- Vlad Patrascu OpenSIPS Developer http://www.opensips-solutions.com On 28.07.2020 17:42, Mark Allen wrote: > [SOLVED] > > Hi Stas - good call! It's a change in behaviour from 3.0. > > In 3.0 documentation says... > >     The next two parameters should be AVPs and they are optional. If > only one is present, it should contain the values attached to the event. > > In 3.1 it removes mention of the behaviour if only one AVP is present, > but it's not obvious and perhaps it could be documented in the > https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0 guide? > Also, perhaps 3.1 should handle it better if parameter is missing > rather than giving a segfault (something for 3.2?) > > Once again I'm indebted to you for your help > > thanks very much & all the best > > Mark > > > > > On Tue, 28 Jul 2020 at 15:22, Stas Kobzar > wrote: > > Hi Allen, > > Did you try with two parameters: name, value? > > *$avp(keys) = "registered";* >        $avp(values) = "true"; >         xlog("Raised E_WFC_REGISTERED $avp(values)"); >         raise_event("E_WFC_REGISTERED", *$avp(keys)*, $avp(values)); > > I know they are said to be optional in the documentation but > probably it is optional for two. Either no params or if you pass > parameters, you have to pass both. > > > On Tue, Jul 28, 2020 at 9:59 AM Mark Allen > wrote: > > We're upgrading from 3.0 to 3.1. Everything seems ok except we > get a weird error. We subscribe a dynamic event... > >     startup_route { >       subscribe_event("E_WFC_REGISTERED", "udp:127.0.0.1:8888 > "); >     } > > which we can see works from /var/log/syslog... >     event_datagram:mod_init: initializing module ... >     core:evi_publish_event: Registered event > and in the script we invoke it with... > > if(is_method("REGISTER")) { >         $avp(values) = "true"; >         xlog("Raised E_WFC_REGISTERED $avp(values)"); > raise_event("E_WFC_REGISTERED",$avp(values)); > > When a phone registers, raise_event() is triggered and > OpenSIPS crashes with a segmentation fault - shown in > /var/log/syslog... > >     Raised E_WFC_REGISTERED true >     CRITICAL:core:sig_usr: segfault in process pid: 10525, id: 8 >     segfault at 8 ip 000055cef821313f sp 00007ffcdf4d3410 > error 4 in opensips[55cef801a000+264000] >     kernel: [197593.785622] Code: 0e 00 4c 89 ef e8 1b 70 fc > ff 49 63 74 24 08 49 8b 3c 24 e8 51 a1 fc ff 48 89 c2 48 8d 35 > 8f 0d 07 00 4c 89 ef e8 fb 6f fc ff <49> 8b 46 08 48 85 c0 74 > 0b 48 83 78 18 00 0f 84 a5 02 00 00 e8 34 >     INFO:core:handle_sigs: child process 10525 exited by a > signal 11 >     INFO:core:handle_sigs: core was generated >     INFO:core:handle_sigs: terminating due to SIGCHLD > > If I comment out the raise_event() line - OpenSIPS seems fine > and doesn't crash when passing through this code. > > > > Running gdb to get core file backtrace we see... > > Core was generated by `/usr/sbin/opensips -P > /run/opensips/opensips.pid -f /etc/opensips/opensips.cfg'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0  evi_build_payload (params=0x0, method=0x7f931f5b6f08, > id=id at entry=0, extra_param_k=extra_param_k at entry=0x0, >     extra_param_v=extra_param_v at entry=0x0) at > evi/evi_transport.c:159 > 159             if (params->first && !params->first->name.s) { > (gdb) bt full > #0  evi_build_payload (params=0x0, method=0x7f931f5b6f08, > id=id at entry=0, extra_param_k=extra_param_k at entry=0x0, >     extra_param_v=extra_param_v at entry=0x0) at > evi/evi_transport.c:159 >         param = >         param_obj = 0x0 >         tmp = >         ret_obj = 0x7f9323135fe0 >         payload = 0x0 >         __FUNCTION__ = "evi_build_payload" > #1  0x00007f931b7d934f in datagram_raise (msg=, > ev_name=, sock=0x7f931f5c54c8, > params=) >     at event_datagram.c:315 >         ret = >         buf = >         __FUNCTION__ = "datagram_raise" > #2  0x000055cef82148fb in evi_raise_event_msg > (msg=msg at entry=0x7f9323134890, id=id at entry=20, > params=params at entry=0x0) >     at evi/event_interface.c:208 >         subs = 0x7f931f5c55a8 >         prev = >         now = 1595943308 >         flags = 1073741838 >         pflags = 0 >         ret = 0 >         __FUNCTION__ = "evi_raise_event_msg" > #3  0x000055cef8216afb in evi_raise_script_event > (msg=0x7f9323134890, id=20, _a=, _v= out>) >     at evi/event_interface.c:430 >         vals = >         attrs = >         v_avp = >         a_avp = >         err = >         val = {n = 587654904, s = {s = 0x7f932306e6f8 "\002", > len = -133061172}} >         attr = {n = 0, s = {s = 0x0, len = -133445686}} >         at = >         params = 0x0 >         __FUNCTION__ = "evi_raise_script_event" > #4  0x000055cef8068c5f in w_raise_event (msg=, > ev_id=, attrs_avp=, >     vals_avp=) at core_cmds.c:1204 >         __FUNCTION__ = "w_raise_event" > #5  0x000055cef8086199 in do_action (a=0x7f932304d020, > msg=0x7f9323134890) at action.c:972 >         ret = >         v = >         i = >         len = >         cmatch = >         aitem = >         adefault = >         spec = >         val = {rs = {s = 0x7f932304c748 "\002", len = 0}, ri = > -129751552, flags = 21966} >         start = {tv_sec = 94347416839552, tv_usec = > 140269924432168} >         end_time = >         cmd = 0x55cef832c550 >         acmd = >         cmdp = {0x14, 0x7f932304cf88, 0x0, 0x2, > 0x7f9323134890, 0x55cef80bb253 , 0x1, 0xc} >         tmp_vals = {{rs = {s = 0x400000000 access memory at address 0x400000000>, len = 587509104}, ri = > 18, flags = 0}, {rs = {s = 0x7f9323134890 "\001", len = > 587509104}, ri = 588466320, flags = 32659}, {rs = {s = > 0x55cef8442600 <_oser_err_info> "", len = -133061748}, ri = > -131568035, flags = 21966}, {rs = {s = 0x3 access memory at address 0x3>, len = 587512256}, ri = 3, flags > = 0}, {rs = {s = 0x7ffcdf4d3790 "\220H\023#\223\177", len = > 587509104}, ri = -131568035, flags = 21966}, {rs = {s = 0x3 > , len = 0}, ri = > 587655824, flags = 32659}, {rs = {s = 0x0, len = 588466320}, > ri = 0, flags = 0}, {rs = {s = 0x55cef80baba7 > "A\211\304D\213\005\277\355'", len = 593194504}, ri = 2, flags > = 0}} >         sval = {s = 0x7ffcdf4d3730 "]n(\370\316U", len = > 587515424} >         __FUNCTION__ = "do_action" > (full backtrace is available) > > Build is taken from 3.1 branch on GitHub > Server is running Debian 10 (Buster) > > > _______________________________________________ > 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 > > > _______________________________________________ > 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 mark at allenclan.co.uk Tue Jul 28 22:16:32 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Tue, 28 Jul 2020 23:16:32 +0100 Subject: [OpenSIPS-Users] OpenSIPS 3.1 - raise_event() crashes OpenSIPS with segmentation fault In-Reply-To: <786fc5b1-f3e6-6700-41ed-10a7a639a1d6@opensips.org> References: <786fc5b1-f3e6-6700-41ed-10a7a639a1d6@opensips.org> Message-ID: Hi Vlad - thanks for that, it's very helpful All the best Mark On Tue, 28 Jul 2020 at 21:40, Vlad Patrascu wrote: > Hi Mark, > > thanks for the report! I have pushed a fix for the crash. > > I've also updated the documentation to be more clear about how > raise_event() should be used and the changes from 3.0. Basically, you don't > have to necessarily pass both AVP parameters in 3.1, but if you want to > pass only the attribute values for the event you should do: > > raise_event("E_WFC_REGISTERED", , $avp(values)); > > That is because the event attribute values can now only be passed through > the corresponding parameter(which is the last one). The way you did it > initially was equivalent to passing only the event attribute names which in > 3.1 results in an event with no attributes at all. This in turn was > unfortunately causing a crash. > > Regards, > > -- > Vlad Patrascu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 28.07.2020 17:42, Mark Allen wrote: > > [SOLVED] > > Hi Stas - good call! It's a change in behaviour from 3.0. > > In 3.0 documentation says... > > The next two parameters should be AVPs and they are optional. If only > one is present, it should contain the values attached to the event. > > In 3.1 it removes mention of the behaviour if only one AVP is present, but > it's not obvious and perhaps it could be documented in the > https://www.opensips.org/Documentation/Migration-3-0-0-to-3-1-0 guide? > Also, perhaps 3.1 should handle it better if parameter is missing rather > than giving a segfault (something for 3.2?) > > Once again I'm indebted to you for your help > > thanks very much & all the best > > Mark > > > > > > On Tue, 28 Jul 2020 at 15:22, Stas Kobzar wrote: > >> Hi Allen, >> >> Did you try with two parameters: name, value? >> >> *$avp(keys) = "registered";* >> $avp(values) = "true"; >> xlog("Raised E_WFC_REGISTERED $avp(values)"); >> raise_event("E_WFC_REGISTERED", *$avp(keys)*, $avp(values)); >> >> I know they are said to be optional in the documentation but probably it >> is optional for two. Either no params or if you pass parameters, you have >> to pass both. >> >> >> On Tue, Jul 28, 2020 at 9:59 AM Mark Allen wrote: >> >>> We're upgrading from 3.0 to 3.1. Everything seems ok except we get a >>> weird error. We subscribe a dynamic event... >>> >>> startup_route { >>> subscribe_event("E_WFC_REGISTERED", "udp:127.0.0.1:8888"); >>> } >>> >>> which we can see works from /var/log/syslog... >>> >>> event_datagram:mod_init: initializing module ... >>> core:evi_publish_event: Registered event >> >>> and in the script we invoke it with... >>> >>> if(is_method("REGISTER")) { >>> $avp(values) = "true"; >>> xlog("Raised E_WFC_REGISTERED $avp(values)"); >>> raise_event("E_WFC_REGISTERED",$avp(values)); >>> >>> When a phone registers, raise_event() is triggered and OpenSIPS crashes >>> with a segmentation fault - shown in /var/log/syslog... >>> >>> Raised E_WFC_REGISTERED true >>> CRITICAL:core:sig_usr: segfault in process pid: 10525, id: 8 >>> segfault at 8 ip 000055cef821313f sp 00007ffcdf4d3410 error 4 in >>> opensips[55cef801a000+264000] >>> kernel: [197593.785622] Code: 0e 00 4c 89 ef e8 1b 70 fc ff 49 63 74 >>> 24 08 49 8b 3c 24 e8 51 a1 fc ff 48 89 c2 48 8d 35 8f 0d 07 00 4c 89 ef e8 >>> fb 6f fc ff <49> 8b 46 08 48 85 c0 74 0b 48 83 78 18 00 0f 84 a5 02 00 00 >>> e8 34 >>> INFO:core:handle_sigs: child process 10525 exited by a signal 11 >>> INFO:core:handle_sigs: core was generated >>> INFO:core:handle_sigs: terminating due to SIGCHLD >>> >>> If I comment out the raise_event() line - OpenSIPS seems fine and >>> doesn't crash when passing through this code. >>> >>> >>> >>> Running gdb to get core file backtrace we see... >>> >>> Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid >>> -f /etc/opensips/opensips.cfg'. >>> Program terminated with signal SIGSEGV, Segmentation fault. >>> #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id at entry=0, >>> extra_param_k=extra_param_k at entry=0x0, >>> extra_param_v=extra_param_v at entry=0x0) at evi/evi_transport.c:159 >>> 159 if (params->first && !params->first->name.s) { >>> (gdb) bt full >>> #0 evi_build_payload (params=0x0, method=0x7f931f5b6f08, id=id at entry=0, >>> extra_param_k=extra_param_k at entry=0x0, >>> extra_param_v=extra_param_v at entry=0x0) at evi/evi_transport.c:159 >>> param = >>> param_obj = 0x0 >>> tmp = >>> ret_obj = 0x7f9323135fe0 >>> payload = 0x0 >>> __FUNCTION__ = "evi_build_payload" >>> #1 0x00007f931b7d934f in datagram_raise (msg=, >>> ev_name=, sock=0x7f931f5c54c8, params=) >>> at event_datagram.c:315 >>> ret = >>> buf = >>> __FUNCTION__ = "datagram_raise" >>> #2 0x000055cef82148fb in evi_raise_event_msg (msg=msg at entry=0x7f9323134890, >>> id=id at entry=20, params=params at entry=0x0) >>> at evi/event_interface.c:208 >>> subs = 0x7f931f5c55a8 >>> prev = >>> now = 1595943308 >>> flags = 1073741838 >>> pflags = 0 >>> ret = 0 >>> __FUNCTION__ = "evi_raise_event_msg" >>> #3 0x000055cef8216afb in evi_raise_script_event (msg=0x7f9323134890, >>> id=20, _a=, _v=) >>> at evi/event_interface.c:430 >>> vals = >>> attrs = >>> v_avp = >>> a_avp = >>> err = >>> val = {n = 587654904, s = {s = 0x7f932306e6f8 "\002", len = >>> -133061172}} >>> attr = {n = 0, s = {s = 0x0, len = -133445686}} >>> at = >>> params = 0x0 >>> __FUNCTION__ = "evi_raise_script_event" >>> #4 0x000055cef8068c5f in w_raise_event (msg=, >>> ev_id=, attrs_avp=, >>> vals_avp=) at core_cmds.c:1204 >>> __FUNCTION__ = "w_raise_event" >>> #5 0x000055cef8086199 in do_action (a=0x7f932304d020, >>> msg=0x7f9323134890) at action.c:972 >>> ret = >>> v = >>> i = >>> len = >>> cmatch = >>> aitem = >>> adefault = >>> spec = >>> val = {rs = {s = 0x7f932304c748 "\002", len = 0}, ri = >>> -129751552, flags = 21966} >>> start = {tv_sec = 94347416839552, tv_usec = 140269924432168} >>> end_time = >>> cmd = 0x55cef832c550 >>> acmd = >>> cmdp = {0x14, 0x7f932304cf88, 0x0, 0x2, 0x7f9323134890, >>> 0x55cef80bb253 , 0x1, 0xc} >>> tmp_vals = {{rs = {s = 0x400000000 >> at address 0x400000000>, len = 587509104}, ri = 18, flags = 0}, {rs = {s = >>> 0x7f9323134890 "\001", len = 587509104}, ri = 588466320, flags = 32659}, >>> {rs = {s = 0x55cef8442600 <_oser_err_info> "", len = -133061748}, ri = >>> -131568035, flags = 21966}, {rs = {s = 0x3 >> address 0x3>, len = 587512256}, ri = 3, flags = 0}, {rs = {s = >>> 0x7ffcdf4d3790 "\220H\023#\223\177", len = 587509104}, ri = -131568035, >>> flags = 21966}, {rs = {s = 0x3 >> 0x3>, len = 0}, ri = 587655824, flags = 32659}, {rs = {s = 0x0, len = >>> 588466320}, ri = 0, flags = 0}, {rs = {s = 0x55cef80baba7 >>> "A\211\304D\213\005\277\355'", len = 593194504}, ri = 2, flags = 0}} >>> sval = {s = 0x7ffcdf4d3730 "]n(\370\316U", len = 587515424} >>> __FUNCTION__ = "do_action" >>> >>> (full backtrace is available) >>> >>> Build is taken from 3.1 branch on GitHub >>> Server is running Debian 10 (Buster) >>> >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > Users mailing listUsers at lists.opensips.orghttp://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: From liviu at opensips.org Wed Jul 29 10:19:19 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 29 Jul 2020 13:19:19 +0300 Subject: [OpenSIPS-Users] Userblacklist module with mongodb In-Reply-To: References: Message-ID: <586e5ffe-322f-8c0c-0ec1-7b313a563528@opensips.org> On 27.07.2020 12:14, ryan embgrets wrote: > Any pointer? > > I am using mongo for other modules and don't want to keep separate > database(mysql) for this module only > > Ryan. Hey, Ryan! Could you please apply the following patch within an OpenSIPS source code tree, then rebuild and see if it makes userblacklist happy?  I expect it to apply on any OpenSIPS version, really. git apply <(base64 -d < References: <216120bc-a397-4118-aa7f-9c0bd9a3f3e6@opensips.org> Message-ID: Thanks Razvan. I will look into using that. Is it possible to add such stats to drouting? I'm guessing it would be useful to others too. Feature request? Best regards Mark. On Mon, 27 Jul 2020 at 08:23, Răzvan Crainea wrote: > Hi, Mark! > > Unfortunately the drouting module does not export any statistics. You > can however use the statistics module[1] and define your own statistics, > that you have to manually update them from the script according to your > needs. > > [1] https://opensips.org/docs/modules/3.1.x/statistics.html > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 7/17/20 4:39 PM, Mark Farmer wrote: > > Hi everyone > > > > I have been asked to look into getting Nagios to monitor active calls on > > specific Dynamic Routing gateways. > > > > Looking at the drouting() docs I don't see any exported statistics. > > Is there a way to do this please? > > > > Many thanks > > Mark. > > > > > > _______________________________________________ > > 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 > -- Mark Farmer farmorg at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From barnyritchley at hotmail.com Wed Jul 29 12:44:12 2020 From: barnyritchley at hotmail.com (Barnaby Ritchley) Date: Wed, 29 Jul 2020 13:44:12 +0100 Subject: [OpenSIPS-Users] re.subst usage Message-ID: Hi List, Using below in route: $var(reg) = "/\+?\d{5}([1-9]\d+)/\1/g"; $var(to_user) = $(rU{re.subst,$var(reg)}); With $rU of 12345441234567890 we would expect $var(to_user) to be 441234567890 (stripping off the first 5 digits) however $var(to_user) returns 12345441234567890 What am I doing wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From liviu at opensips.org Wed Jul 29 13:14:05 2020 From: liviu at opensips.org (Liviu Chircu) Date: Wed, 29 Jul 2020 16:14:05 +0300 Subject: [OpenSIPS-Users] re.subst usage In-Reply-To: References: Message-ID: <89632ab3-831a-1c36-7cdc-0810fe4b87bc@opensips.org> On 29.07.2020 15:44, Barnaby Ritchley wrote: > With $rU of 12345441234567890 we would expect $var(to_user) to be > 441234567890 (stripping off the first 5 digits) however > $var(to_user) returns 12345441234567890 > What am I doing wrong? > Hey Barnaby, I would guess that the PCRE library does not support the "\d" literal, which also seems to be confirmed by this site [1].  The "/\+?[0-9]{5}([1-9][0-9]+)/\1/g" regexp should remove your tech prefix as expected. BR, [1]: https://www.regular-expressions.info/shorthand.html -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ben.Newlin at genesys.com Wed Jul 29 13:25:58 2020 From: Ben.Newlin at genesys.com (Ben Newlin) Date: Wed, 29 Jul 2020 13:25:58 +0000 Subject: [OpenSIPS-Users] re.subst usage In-Reply-To: <89632ab3-831a-1c36-7cdc-0810fe4b87bc@opensips.org> References: <89632ab3-831a-1c36-7cdc-0810fe4b87bc@opensips.org> Message-ID: Also, if you know the length of the prefix you could just s.substr. https://www.opensips.org/Documentation/Script-Tran-3-1#s.substr Ben Newlin From: Users on behalf of Liviu Chircu Reply-To: OpenSIPS users mailling list Date: Wednesday, July 29, 2020 at 9:15 AM To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] re.subst usage On 29.07.2020 15:44, Barnaby Ritchley wrote: With $rU of 12345441234567890 we would expect $var(to_user) to be 441234567890 (stripping off the first 5 digits) however $var(to_user) returns 12345441234567890 What am I doing wrong? Hey Barnaby, I would guess that the PCRE library does not support the "\d" literal, which also seems to be confirmed by this site [1]. The "/\+?[0-9]{5}([1-9][0-9]+)/\1/g" regexp should remove your tech prefix as expected. BR, [1]: https://www.regular-expressions.info/shorthand.html -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed -------------- next part -------------- An HTML attachment was scrubbed... URL: From barnyritchley at hotmail.com Wed Jul 29 13:27:17 2020 From: barnyritchley at hotmail.com (Barnaby Ritchley) Date: Wed, 29 Jul 2020 14:27:17 +0100 Subject: [OpenSIPS-Users] re.subst usage In-Reply-To: <89632ab3-831a-1c36-7cdc-0810fe4b87bc@opensips.org> References: <89632ab3-831a-1c36-7cdc-0810fe4b87bc@opensips.org> Message-ID: Hi Liviu, Thats perfect - didn’t even think of that! [0-9] instead of \d works great. Thanks again! > On 29 Jul 2020, at 14:14, Liviu Chircu wrote: > > I would guess that the PCRE library does not support the "\d" literal, which also seems to be confirmed by this site [1]. The "/\+?[0-9]{5}([1-9][0-9]+)/\1/g" regexp should remove your tech prefix as expected. > > BR, > > [1]: https://www.regular-expressions.info/shorthand.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Wed Jul 29 17:47:10 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Wed, 29 Jul 2020 20:47:10 +0300 Subject: [OpenSIPS-Users] OpenSIPS Summit 2020 Distributed is set! In-Reply-To: <3300a042-699f-089c-98ac-31042af6016f@opensips.org> References: <3300a042-699f-089c-98ac-31042af6016f@opensips.org> Message-ID: <83d55822-5b19-26bf-357f-9ecb546e9d1e@opensips.org> Hello all, Here is the #UPDATE2 ! WE worked out all the details and we will have an OpenSIPS 3.1 training during the Summit 2020. We do not like to break the patterns ;). The training will be of course online and it will take place on Tuesday 15th of September (due timing consideration we ruled out the idea of having the training in the same days with the conference and also we do not like Mondays - this is how we ended up with Tuesday). The training will be a 4-5 hours session with theoretical and practical labs covering the Call API and Media Exchanging with OpenSIPS 3.1. See the description of the training here [1]. For the people who already registered for the Free Conference of the Summit, no worries, you can retake the registration process [2] using the same email address, and your existing registration will get updated. [1] https://www.opensips.org/events/Summit-2020Distributed/index.html#schedules (see Tuesday 15th) [2] https://www.opensips.org/events/Summit-2020Distributed/index.html#pricing Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ On 7/23/20 2:29 PM, Bogdan-Andrei Iancu wrote: > Hello all, > > As a quick update here. The *free registration is now open*, so not > miss the chance for winning some OpenSIPS prizes! Register and you > will be part of the raffle. > > https://www.opensips.org/events/Summit-2020Distributed/#pricing > > Also we are working to provide an OpenSIPS 3.1 specific training, > around *4 hours online training* in the next day after the summit > (this is not part of the free registration). The training will cover > *Call API, Push Notification or Media Exchange labs* - again, this is > work in progress, but next week will announce it and open > registrations for it also ;) > > Best regards, > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 2020 online > https://www.opensips.org/events/Summit-2020Distributed/ > On 7/16/20 7:08 PM, Bogdan-Andrei Iancu wrote: >> >> Bye-Bye Amsterdam, welcome Online – the "OpenSIPS Summit 2020" >> becomes the "OpenSIPS Summit Distributed 2020", a free, live and >> interactive online event. >> >> 5th - 11th of September - are you ready to join us? >> >> https://blog.opensips.org/2020/07/16/opensips-summit-2020-distributed/ >> >> >> See you over the Internet, >> > > > _______________________________________________ > 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 rembgrets at gmail.com Wed Jul 29 21:17:18 2020 From: rembgrets at gmail.com (ryan embgrets) Date: Wed, 29 Jul 2020 14:17:18 -0700 Subject: [OpenSIPS-Users] Userblacklist module with mongodb In-Reply-To: <586e5ffe-322f-8c0c-0ec1-7b313a563528@opensips.org> References: <586e5ffe-322f-8c0c-0ec1-7b313a563528@opensips.org> Message-ID: Hi, I can gladly confirm that the above patch works like charm. :) Thank you very much. Would this be available in the next releases of 3.0.x or 3.1.x ? Ryan. On Wed, 29 Jul 2020 at 03:21, Liviu Chircu wrote: > On 27.07.2020 12:14, ryan embgrets wrote: > > Any pointer? > > > > I am using mongo for other modules and don't want to keep separate > > database(mysql) for this module only > > > > Ryan. > > Hey, Ryan! > > Could you please apply the following patch within an OpenSIPS source > code tree, then rebuild and see if it makes userblacklist happy? I > expect it to apply on any OpenSIPS version, really. > > git apply <(base64 -d < > ZGlmZiAtLWdpdCBhL21vZHVsZXMvdXNlcmJsYWNrbGlzdC9kYi5jIGIvbW9kdWxlcy91c2VyYmxh > > Y2tsaXN0L2RiLmMKaW5kZXggYzg0OGMzNDczLi4yNjI0YzM2OWYgMTAwNjQ0Ci0tLSBhL21vZHVs > > ZXMvdXNlcmJsYWNrbGlzdC9kYi5jCisrKyBiL21vZHVsZXMvdXNlcmJsYWNrbGlzdC9kYi5jCkBA > > IC0xMDcsNyArMTA3LDcgQEAgaW50IGRiX2J1aWxkX3VzZXJibF90cmVlKGNvbnN0IHN0ciAqdXNl > > cm5hbWUsIGNvbnN0IHN0ciAqZG9tYWluLCBjb25zdCBzdHIgKnRhYmwKIAlpZiAoUkVTX0NPTF9O > > KHJlcykgPiAxKSB7CiAJCWZvcihpID0gMDsgaSA8IFJFU19ST1dfTihyZXMpOyBpKyspIHsKIAkJ > > CWlmICgoIVJFU19ST1dTKHJlcylbaV0udmFsdWVzWzBdLm51bCkgJiYgKCFSRVNfUk9XUyhyZXMp > > W2ldLnZhbHVlc1sxXS5udWwpKSB7Ci0JCQkJaWYgKChSRVNfUk9XUyhyZXMpW2ldLnZhbHVlc1sw > > XS50eXBlID09IERCX1NUUklORykgJiYKKwkJCQlpZiAoKFJFU19ST1dTKHJlcylbaV0udmFsdWVz > > WzBdLnR5cGUgPT0gREJfU1RSSU5HIHx8IFJFU19ST1dTKHJlcylbaV0udmFsdWVzWzBdLnR5cGUg > > PT0gREJfU1RSKSAmJgogCQkJCQkoUkVTX1JPV1MocmVzKVtpXS52YWx1ZXNbMV0udHlwZSA9PSBE > > Ql9JTlQpKSB7CiAKIAkJCQkJLyogTE1fREJHKCJpbnNlcnQgaW50byB0cmVlIHByZWZpeCAlcywg > > d2hpdGVsaXN0ICVkIiwKQEAgLTE1NCw3ICsxNTQsNyBAQCBpbnQgZGJfcmVsb2FkX3NvdXJjZShj > > b25zdCBzdHIgKnRhYmxlLCBzdHJ1Y3QgZHRfbm9kZV90ICpyb290KQogCWlmIChSRVNfQ09MX04o > > cmVzKSA+IDEpIHsKIAkJZm9yKGkgPSAwOyBpIDwgUkVTX1JPV19OKHJlcyk7IGkrKykgewogCQkJ > > aWYgKCghUkVTX1JPV1MocmVzKVtpXS52YWx1ZXNbMF0ubnVsKSAmJiAoIVJFU19ST1dTKHJlcylb > > aV0udmFsdWVzWzFdLm51bCkpIHsKLQkJCQlpZiAoKFJFU19ST1dTKHJlcylbaV0udmFsdWVzWzBd > > LnR5cGUgPT0gREJfU1RSSU5HKSAmJgorCQkJCWlmICgoUkVTX1JPV1MocmVzKVtpXS52YWx1ZXNb > > MF0udHlwZSA9PSBEQl9TVFJJTkcgfHwgUkVTX1JPV1MocmVzKVtpXS52YWx1ZXNbMF0udHlwZSA9 > > PSBEQl9TVFIpICYmCiAJCQkJCShSRVNfUk9XUyhyZXMpW2ldLnZhbHVlc1sxXS50eXBlID09IERC > > X0lOVCkpIHsKIAogCQkJCQkvKiBMTV9EQkcoImluc2VydCBpbnRvIHRyZWUgcHJlZml4ICVzLCB3 > aGl0ZWxpc3QgJWQiLAo= > EOF > ) > > Cheers, > > -- > Liviu Chircu > www.twitter.com/liviuchircu | www.opensips-solutions.com > > OpenSIPS Summit 2020 Distributed > www.opensips.org/events/Summit-2020Distributed > > > _______________________________________________ > 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 razvan at opensips.org Thu Jul 30 07:09:37 2020 From: razvan at opensips.org (=?UTF-8?Q?R=c4=83zvan_Crainea?=) Date: Thu, 30 Jul 2020 10:09:37 +0300 Subject: [OpenSIPS-Users] Dynamic Routing Stats In-Reply-To: References: <216120bc-a397-4118-aa7f-9c0bd9a3f3e6@opensips.org> Message-ID: <89a92021-7cc2-4c5f-fdd0-b4ecf3a3cf39@opensips.org> Hi, Mark! The main issue is that the drouting module is not aware of what gateways are being used, when they are used & stuff. Therefore is very complicated to build these statistics from the code, as it is highly dependent of the way they are used in the script. Furthermore, even if one would find a way of making this work, it would be a lot more complicated than simply coding it in the script. Therefore I don't see this being coded any time soon. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 7/29/20 1:59 PM, Mark Farmer wrote: > Thanks Razvan. I will look into using that. > > Is it possible to add such stats to drouting? I'm guessing it would be > useful to others too. > Feature request? > > Best regards > Mark. > > > > On Mon, 27 Jul 2020 at 08:23, Răzvan Crainea > wrote: > > Hi, Mark! > > Unfortunately the drouting module does not export any statistics. You > can however use the statistics module[1] and define your own > statistics, > that you have to manually update them from the script according to your > needs. > > [1] https://opensips.org/docs/modules/3.1.x/statistics.html > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 7/17/20 4:39 PM, Mark Farmer wrote: > > Hi everyone > > > > I have been asked to look into getting Nagios to monitor active > calls on > > specific Dynamic Routing gateways. > > > > Looking at the drouting() docs I don't see any exported statistics. > > Is there a way to do this please? > > > > Many thanks > > Mark. > > > > > > _______________________________________________ > > 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 > > > > -- > Mark Farmer > farmorg at gmail.com > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > From bogdan at opensips.org Thu Jul 30 08:00:58 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 30 Jul 2020 11:00:58 +0300 Subject: [OpenSIPS-Users] Dynamic Routing Stats In-Reply-To: <89a92021-7cc2-4c5f-fdd0-b4ecf3a3cf39@opensips.org> References: <216120bc-a397-4118-aa7f-9c0bd9a3f3e6@opensips.org> <89a92021-7cc2-4c5f-fdd0-b4ecf3a3cf39@opensips.org> Message-ID: <5d4c75b5-a0ff-0308-cd11-6fcc23802863@opensips.org> Hi all, An option is to use dialog profiles at script level - each time you route a call to a specific GW (you can get its ID after do_routing()), just add the call into a corresponding dialog profile. And you can use the dialog MI cmds to fetch the status of the profiles. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ On 7/30/20 10:09 AM, Răzvan Crainea wrote: > Hi, Mark! > > The main issue is that the drouting module is not aware of what > gateways are being used, when they are used & stuff. Therefore is very > complicated to build these statistics from the code, as it is highly > dependent of the way they are used in the script. Furthermore, even if > one would find a way of making this work, it would be a lot more > complicated than simply coding it in the script. Therefore I don't see > this being coded any time soon. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 7/29/20 1:59 PM, Mark Farmer wrote: >> Thanks Razvan. I will look into using that. >> >> Is it possible to add such stats to drouting? I'm guessing it would >> be useful to others too. >> Feature request? >> >> Best regards >> Mark. >> >> >> >> On Mon, 27 Jul 2020 at 08:23, Răzvan Crainea > > wrote: >> >>     Hi, Mark! >> >>     Unfortunately the drouting module does not export any statistics. >> You >>     can however use the statistics module[1] and define your own >>     statistics, >>     that you have to manually update them from the script according >> to your >>     needs. >> >>     [1] https://opensips.org/docs/modules/3.1.x/statistics.html >> >>     Best regards, >> >>     Răzvan Crainea >>     OpenSIPS Core Developer >>     http://www.opensips-solutions.com >> >>     On 7/17/20 4:39 PM, Mark Farmer wrote: >>      > Hi everyone >>      > >>      > I have been asked to look into getting Nagios to monitor active >>     calls on >>      > specific Dynamic Routing gateways. >>      > >>      > Looking at the drouting() docs I don't see any exported >> statistics. >>      > Is there a way to do this please? >>      > >>      > Many thanks >>      > Mark. >>      > >>      > >>      > _______________________________________________ >>      > 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 >> >> >> >> -- >> Mark Farmer >> farmorg at gmail.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 mark at allenclan.co.uk Thu Jul 30 08:16:23 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Thu, 30 Jul 2020 09:16:23 +0100 Subject: [OpenSIPS-Users] 3.1 - Mid_Registrar - AOR throttling with WebRTC failing Message-ID: We are working on a test setup, hoping to move to a production system in mid-August. We want to use mid-registrar AOR throttling. Users will connect through OpenSIPS using a combination of SIP and WebRTC endpoints, registering to an extension on an Asterisk main-registrar... +----------+ ---> | | +----------+ ---> | OpenSIPS | ---> | Asterisk | ---> | | +----------+ +----------+ Multiple SIP phones (hardware or softphones) registering via an OpenSIPS 3.1 mid_registration AOR is working fine. A call to the extension number on Asterisk results in all mid-registered SIP extensions ringing and when one answers, the other devices register a missed call. So far, so good. With 3.0 - we had a problem with WebRTC "phones" (even when just using mid_registrar in "mirroring" mode). Webphone could register and call other phones without a problem. However, calls to the WebPhone failed - there was a problem with the WebSocket addressing giving "476 Unresolvable destination" when the call originates from the main registrar - e.g. one extension calling another. The /var/log/syslog entry said... ERROR:core:sip_resolvehost: forced proto 6 not matching sips uri CRITICAL:core:mk_proxy: could not resolve hostname: "4xp44jxl0qq0.invalid" ERROR:tm:uri2proxy: bad host name in URI ERROR:tm:t_forward_nonack: failure to add branches Stas Kobar gave me a way to resolve this - http://lists.opensips.org/pipermail/users/2020-July/043443.html As we were using 3.0, I used the "path" module and "add_path_received()" to handle this for WebRTC. This worked for a single device registered to an address. However, as far as I could see, using "path" effectively bypassed the "contact" address held in the OpenSIPS "location" table so it didn't work for AOR throttling. I was hoping that, with mid_registrar on 3.1 baking in path support, I could just use "mid_registrar_save('location','p0v')" to store the WebRTC destination path in the "location" table. Then, with a call to the WebRTC endpoint from the main registrar, "mid_registrar_lookup('location')" would use the stored path from the "location" table to send traffic on to the WebRTC phone and it would work fine with AOR throttling. However, that's not happening, and looking at the "location" table, no path seems to be being stored. If I register a WebRTC "phone" first, the path is included on the registration SIP message sent from OpenSIPS to Asterisk. If I then register additional SIP phones on OpenSIPS, AOR throttling works, because, when the call originates from Asterisk it includes the "route" HF that points to the WebRTC destination. However, if a SIP phone registers first, Asterisk doesn't get the WebRTC path, so calls fail to reach the WebRTC destination because it tries to use the first registered SIP phone's path. So - 2 questions really... 1 - Can I use AOR throttling with WebRTC (I can't guarantee that the WebRTC endpoint will be the first to register or that there will only be one WebRTC endpoint) 2 - If the answer to 1 is yes, what am I doing wrong? Relevant code snippets... loadmodule "mid_registrar.so" modparam("mid_registrar", "mode", 2) /* 0 = mirror / 1 = ct / 2 = AoR */ modparam("mid_registrar", "outgoing_expires", 3600) add_path_received(); $avp(returncode) = mid_registrar_save("location","p0v"); switch ($avp(returncode)) { case 1: route(resolve_registrar); $ru = "sip:" + $avp(main_registrar) + ":5060"; t_on_failure("1"); t_relay(); break; case 2: break; default: } if (!mid_registrar_lookup("location")) { t_reply(404, "Not Found"); exit; } NB - route(resolve_registrar) sets the variable $avp(main_registrar) to the IP address of the Asterisk server -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmorg at gmail.com Thu Jul 30 08:20:04 2020 From: farmorg at gmail.com (Mark Farmer) Date: Thu, 30 Jul 2020 09:20:04 +0100 Subject: [OpenSIPS-Users] Dynamic Routing Stats In-Reply-To: <5d4c75b5-a0ff-0308-cd11-6fcc23802863@opensips.org> References: <216120bc-a397-4118-aa7f-9c0bd9a3f3e6@opensips.org> <89a92021-7cc2-4c5f-fdd0-b4ecf3a3cf39@opensips.org> <5d4c75b5-a0ff-0308-cd11-6fcc23802863@opensips.org> Message-ID: Thanks both. Understand the drouting() issue. I like the dialog profiles idea, that sounds much easier than updating stats in the correct places. Is that done using set_dlg_profile() ? Regards Mark. On Thu, 30 Jul 2020 at 09:03, Bogdan-Andrei Iancu wrote: > Hi all, > > An option is to use dialog profiles at script level - each time you > route a call to a specific GW (you can get its ID after do_routing()), > just add the call into a corresponding dialog profile. And you can use > the dialog MI cmds to fetch the status of the profiles. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 2020 online > https://www.opensips.org/events/Summit-2020Distributed/ > > On 7/30/20 10:09 AM, Răzvan Crainea wrote: > > Hi, Mark! > > > > The main issue is that the drouting module is not aware of what > > gateways are being used, when they are used & stuff. Therefore is very > > complicated to build these statistics from the code, as it is highly > > dependent of the way they are used in the script. Furthermore, even if > > one would find a way of making this work, it would be a lot more > > complicated than simply coding it in the script. Therefore I don't see > > this being coded any time soon. > > > > Best regards, > > > > Răzvan Crainea > > OpenSIPS Core Developer > > http://www.opensips-solutions.com > > > > On 7/29/20 1:59 PM, Mark Farmer wrote: > >> Thanks Razvan. I will look into using that. > >> > >> Is it possible to add such stats to drouting? I'm guessing it would > >> be useful to others too. > >> Feature request? > >> > >> Best regards > >> Mark. > >> > >> > >> > >> On Mon, 27 Jul 2020 at 08:23, Răzvan Crainea >> > wrote: > >> > >> Hi, Mark! > >> > >> Unfortunately the drouting module does not export any statistics. > >> You > >> can however use the statistics module[1] and define your own > >> statistics, > >> that you have to manually update them from the script according > >> to your > >> needs. > >> > >> [1] https://opensips.org/docs/modules/3.1.x/statistics.html > >> > >> Best regards, > >> > >> Răzvan Crainea > >> OpenSIPS Core Developer > >> http://www.opensips-solutions.com > >> > >> On 7/17/20 4:39 PM, Mark Farmer wrote: > >> > Hi everyone > >> > > >> > I have been asked to look into getting Nagios to monitor active > >> calls on > >> > specific Dynamic Routing gateways. > >> > > >> > Looking at the drouting() docs I don't see any exported > >> statistics. > >> > Is there a way to do this please? > >> > > >> > Many thanks > >> > Mark. > >> > > >> > > >> > _______________________________________________ > >> > 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 > >> > >> > >> > >> -- > >> Mark Farmer > >> farmorg at gmail.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 > > > _______________________________________________ > 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 liviu at opensips.org Thu Jul 30 10:57:12 2020 From: liviu at opensips.org (Liviu Chircu) Date: Thu, 30 Jul 2020 13:57:12 +0300 Subject: [OpenSIPS-Users] Userblacklist module with mongodb In-Reply-To: References: <586e5ffe-322f-8c0c-0ec1-7b313a563528@opensips.org> Message-ID: <8a2af2f0-d832-1055-eb47-a9589c8d7f1c@opensips.org> On 30.07.2020 00:17, ryan embgrets wrote: > Hi, > I can gladly confirm that the above patch works like charm. :) Thank > you very much. > Would this be available in the next releases of 3.0.x or 3.1.x ? > > Ryan. Awesome!  I just pushed this fix to all supported branches, thanks!  If you want to install via packages, I suggest using the nightly ones, so you don't have to wait until the upcoming minor release. Best regards, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed From bogdan at opensips.org Thu Jul 30 11:11:45 2020 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Thu, 30 Jul 2020 14:11:45 +0300 Subject: [OpenSIPS-Users] Dynamic Routing Stats In-Reply-To: References: <216120bc-a397-4118-aa7f-9c0bd9a3f3e6@opensips.org> <89a92021-7cc2-4c5f-fdd0-b4ecf3a3cf39@opensips.org> <5d4c75b5-a0ff-0308-cd11-6fcc23802863@opensips.org> Message-ID: <4bd0fb91-8a9d-7e0d-47fb-753b8ae57b21@opensips.org> YEs, use set_dlg_profile() with a profile with values, where the values are the IDs of the GWs. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 2020 online https://www.opensips.org/events/Summit-2020Distributed/ On 7/30/20 11:20 AM, Mark Farmer wrote: > Thanks both. Understand the drouting() issue. > > I like the dialog profiles idea, that sounds much easier than updating > stats in the correct places. Is that done using set_dlg_profile() ? > > Regards > Mark. > > > On Thu, 30 Jul 2020 at 09:03, Bogdan-Andrei Iancu > wrote: > > Hi all, > > An option is to use dialog profiles at script level - each time you > route a call to a specific GW (you can get its ID after > do_routing()), > just add the call into a corresponding dialog profile. And you can > use > the dialog MI cmds to fetch the status of the profiles. > > Regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS Summit 2020 online > https://www.opensips.org/events/Summit-2020Distributed/ > > On 7/30/20 10:09 AM, Răzvan Crainea wrote: > > Hi, Mark! > > > > The main issue is that the drouting module is not aware of what > > gateways are being used, when they are used & stuff. Therefore > is very > > complicated to build these statistics from the code, as it is > highly > > dependent of the way they are used in the script. Furthermore, > even if > > one would find a way of making this work, it would be a lot more > > complicated than simply coding it in the script. Therefore I > don't see > > this being coded any time soon. > > > > Best regards, > > > > Răzvan Crainea > > OpenSIPS Core Developer > > http://www.opensips-solutions.com > > > > On 7/29/20 1:59 PM, Mark Farmer wrote: > >> Thanks Razvan. I will look into using that. > >> > >> Is it possible to add such stats to drouting? I'm guessing it > would > >> be useful to others too. > >> Feature request? > >> > >> Best regards > >> Mark. > >> > >> > >> > >> On Mon, 27 Jul 2020 at 08:23, Răzvan Crainea > > >> >> wrote: > >> > >>     Hi, Mark! > >> > >>     Unfortunately the drouting module does not export any > statistics. > >> You > >>     can however use the statistics module[1] and define your own > >>     statistics, > >>     that you have to manually update them from the script > according > >> to your > >>     needs. > >> > >>     [1] https://opensips.org/docs/modules/3.1.x/statistics.html > >> > >>     Best regards, > >> > >>     Răzvan Crainea > >>     OpenSIPS Core Developer > >> http://www.opensips-solutions.com > >> > >>     On 7/17/20 4:39 PM, Mark Farmer wrote: > >>      > Hi everyone > >>      > > >>      > I have been asked to look into getting Nagios to monitor > active > >>     calls on > >>      > specific Dynamic Routing gateways. > >>      > > >>      > Looking at the drouting() docs I don't see any exported > >> statistics. > >>      > Is there a way to do this please? > >>      > > >>      > Many thanks > >>      > Mark. > >>      > > >>      > > >>      > _______________________________________________ > >>      > 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 > >> > >> > >> > >> -- > >> Mark Farmer > >> farmorg at gmail.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 > > > _______________________________________________ > Users mailing list > Users at lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > -- > Mark Farmer > farmorg at gmail.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 mark at allenclan.co.uk Thu Jul 30 15:24:05 2020 From: mark at allenclan.co.uk (Mark Allen) Date: Thu, 30 Jul 2020 16:24:05 +0100 Subject: [OpenSIPS-Users] 3.1 - access Path and Via values from REGISTER Message-ID: Seeking to find a workaround for the problem I'm having with WebRTC and AOR throttling (http://lists.opensips.org/pipermail/users/2020-July/043542.html) I want to access the values of the "Via" and "Path" headers that are being passed to the registrar. Using sngrep on the OpenSIPS server I can see the REGISTER includes Path and Via headers. If I try to access them with $(hdr(Path)[0]) or $(hdr(Via)[0]) I get nothing, but I can access the values of all the other headers without any problem - e.g. $(hdr(Authorization)[0]). What am I missing or is there another way to get the info used in the Via and particularly in creating the Path header values??? add_path_received(); xlog("!!!!!!!!!!!! $(hdr(Path)[0]) !!!!!!!!!!"); $avp(attr) = $(hdr(Path)[0]); mid_registrar_save("location","p0v"); The code gives an "attr" value in the "location" table of "NULL" /var/log/syslog shows: Jul 30 16:13:17 /usr/sbin/opensips[27423]: !!!!!!!!!!!! !!!!!!!!!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan at democon.be Fri Jul 31 08:56:21 2020 From: johan at democon.be (johan) Date: Fri, 31 Jul 2020 10:56:21 +0200 Subject: [OpenSIPS-Users] push notification. Message-ID: <49333495-abb6-b5c7-4cff-34c50cf03a93@democon.be> Does somebody has a registration pcap packet of an iphone with push notification enabled ? wkr, From johan at democon.be Fri Jul 31 09:09:24 2020 From: johan at democon.be (johan) Date: Fri, 31 Jul 2020 11:09:24 +0200 Subject: [OpenSIPS-Users] push notification. In-Reply-To: <49333495-abb6-b5c7-4cff-34c50cf03a93@democon.be> References: <49333495-abb6-b5c7-4cff-34c50cf03a93@democon.be> Message-ID: Read as : what extra headers do I need in a register message to make this work for a softphone on apple / android ? On 31/07/2020 10:56, johan wrote: > Does somebody has a registration pcap packet of an iphone with push > notification enabled ? > > wkr, > From johan at democon.be Fri Jul 31 09:54:53 2020 From: johan at democon.be (johan) Date: Fri, 31 Jul 2020 11:54:53 +0200 Subject: [OpenSIPS-Users] tutorial on tls. Message-ID: <40cbdf1a-a938-147f-3c91-2ab2f5792994@democon.be> somewhere on the opensips website there is a tutorial that covers in detail how to generate certificates with openssl. Can somebody please provide me the url ? I can't find it back anymore. Th anks and best regards, Johan. From tpaivaa at gmail.com Fri Jul 31 09:59:55 2020 From: tpaivaa at gmail.com (Tomi Hakkarainen) Date: Fri, 31 Jul 2020 12:59:55 +0300 Subject: [OpenSIPS-Users] tutorial on tls. In-Reply-To: <40cbdf1a-a938-147f-3c91-2ab2f5792994@democon.be> References: <40cbdf1a-a938-147f-3c91-2ab2f5792994@democon.be> Message-ID: <194A05C3-7BAA-4DA2-9412-EA1A7FF1C058@gmail.com> this one? https://www.opensips.org/Documentation/Tutorials-TLS-2-1 On 31. Jul 2020, at 12.57, johan wrote: somewhere on the opensips website there is a tutorial that covers in detail how to generate certificates with openssl. Can somebody please provide me the url ? I can't find it back anymore. Th anks and best regards, Johan. _______________________________________________ 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 Fri Jul 31 10:06:03 2020 From: johan at democon.be (johan) Date: Fri, 31 Jul 2020 12:06:03 +0200 Subject: [OpenSIPS-Users] tutorial on tls. In-Reply-To: <194A05C3-7BAA-4DA2-9412-EA1A7FF1C058@gmail.com> References: <40cbdf1a-a938-147f-3c91-2ab2f5792994@democon.be> <194A05C3-7BAA-4DA2-9412-EA1A7FF1C058@gmail.com> Message-ID: No, there was somewhere a tutorial or app note on the website with the openssl commands. That's the one that I am looking for. On 31/07/2020 11:59, Tomi Hakkarainen wrote: > this one? > > https://www.opensips.org/Documentation/Tutorials-TLS-2-1 > > > On 31. Jul 2020, at 12.57, johan wrote: > > somewhere on the opensips website there is a tutorial that covers in > detail how to generate certificates with openssl. > > Can somebody please provide me the url ? I can't find it back anymore. > > > Th anks and best regards, Johan. > > > _______________________________________________ > 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: From johan at democon.be Fri Jul 31 10:18:27 2020 From: johan at democon.be (johan) Date: Fri, 31 Jul 2020 12:18:27 +0200 Subject: [OpenSIPS-Users] tutorial on tls. In-Reply-To: References: <40cbdf1a-a938-147f-3c91-2ab2f5792994@democon.be> <194A05C3-7BAA-4DA2-9412-EA1A7FF1C058@gmail.com> Message-ID: Furhtermore, I think that this document was written by Razvan. Razvan, does it ring a bell ? On 31/07/2020 12:06, johan wrote: > > No, there was somewhere a tutorial or app note on the website with the > openssl commands. > > That's the one that I am looking for. > > On 31/07/2020 11:59, Tomi Hakkarainen wrote: >> this one? >> >> https://www.opensips.org/Documentation/Tutorials-TLS-2-1 >> >> >> On 31. Jul 2020, at 12.57, johan wrote: >> >> somewhere on the opensips website there is a tutorial that covers in >> detail how to generate certificates with openssl. >> >> Can somebody please provide me the url ? I can't find it back anymore. >> >> >> Th anks and best regards, Johan. >> >> >> _______________________________________________ >> 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: From liviu at opensips.org Fri Jul 31 13:51:25 2020 From: liviu at opensips.org (Liviu Chircu) Date: Fri, 31 Jul 2020 16:51:25 +0300 Subject: [OpenSIPS-Users] tutorial on tls. In-Reply-To: <40cbdf1a-a938-147f-3c91-2ab2f5792994@democon.be> References: <40cbdf1a-a938-147f-3c91-2ab2f5792994@democon.be> Message-ID: On 31.07.2020 12:54, johan wrote: > somewhere on the opensips website there is a tutorial that covers in > detail how to generate certificates with openssl. > > Can somebody please provide me the url ? I can't find it back anymore. Why use something old when you can just "opensips-cli" [1] your way out of this? Best regards, [1]: https://github.com/OpenSIPS/opensips-cli/blob/master/docs/modules/tls.md#opensips-cli---tls-module -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2020 Distributed www.opensips.org/events/Summit-2020Distributed From barnyritchley at hotmail.com Fri Jul 31 19:43:54 2020 From: barnyritchley at hotmail.com (Barny Ritchley) Date: Fri, 31 Jul 2020 19:43:54 +0000 Subject: [OpenSIPS-Users] re.subst usage In-Reply-To: References: <89632ab3-831a-1c36-7cdc-0810fe4b87bc@opensips.org>, Message-ID: Hi Ben I couldn’t use that unfortunately as there is an optional + that may or not be present. Barny On 29 Jul 2020, at 14:28, Ben Newlin wrote:  Also, if you know the length of the prefix you could just s.substr. https://www.opensips.org/Documentation/Script-Tran-3-1#s.substr -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.m.barman at gmail.com Mon Jul 13 20:34:58 2020 From: bill.m.barman at gmail.com (Billy Barman) Date: Mon, 13 Jul 2020 20:34:58 -0000 Subject: [OpenSIPS-Users] OpenSIPS legacy repos Message-ID: Hi, Is there an official (or not) repo which contains old RPM builds of OpenSIPS? We have a legacy environment which currently runs on 2.1.5 and I'd rather avoid building from source if possible. Thanks in advance Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: