[OpenSIPS-Users] Failed to trigger pkg stats in logs
Hi,
We're experiencing a lot of messages like this:
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 42
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 43
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 45
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 42
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 43
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 45
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 42
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 43
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 45
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 42
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 43
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 45
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 42
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 43
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 45
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 42
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 43
Sep 21 03:18:09 ERROR:core:signal_pkg_status: failed to trigger pkg stats
for process 45
Here's a list of all processes:
opensips-cli -x mi get_statistics load:
{
"load:load-proc-1": 0,
"load:load1m-proc-1": 0,
"load:load10m-proc-1": 0,
"load:load-proc-2": 0,
"load:load1m-proc-2": 0,
"load:load10m-proc-2": 0,
"load:load-proc-3": 0,
"load:load1m-proc-3": 0,
"load:load10m-proc-3": 0,
"load:load-proc-4": 0,
"load:load1m-proc-4": 0,
"load:load10m-proc-4": 0,
"load:load-proc-5": 0,
"load:load1m-proc-5": 0,
"load:load10m-proc-5": 1,
"load:load-proc-6": 1,
"load:load1m-proc-6": 1,
"load:load10m-proc-6": 1,
"load:load-proc-7": 0,
"load:load1m-proc-7": 1,
"load:load10m-proc-7": 1,
"load:load-proc-8": 0,
"load:load1m-proc-8": 1,
"load:load10m-proc-8": 1,
"load:load-proc-9": 0,
"load:load1m-proc-9": 1,
"load:load10m-proc-9": 1,
"load:load-proc-10": 0,
"load:load1m-proc-10": 1,
"load:load10m-proc-10": 1,
"load:load-proc-11": 0,
"load:load1m-proc-11": 1,
"load:load10m-proc-11": 1,
"load:load-proc-12": 0,
"load:load1m-proc-12": 1,
"load:load10m-proc-12": 1,
"load:load-proc-13": 0,
"load:load1m-proc-13": 1,
"load:load10m-proc-13": 1,
"load:load-proc-14": 0,
"load:load1m-proc-14": 1,
"load:load10m-proc-14": 1,
"load:load-proc-15": 7,
"load:load1m-proc-15": 0,
"load:load10m-proc-15": 0,
"load:load-proc-16": 0,
"load:load1m-proc-16": 1,
"load:load10m-proc-16": 0,
"load:load-proc-17": 4,
"load:load1m-proc-17": 0,
"load:load10m-proc-17": 0,
"load:load-proc-18": 0,
"load:load1m-proc-18": 0,
"load:load10m-proc-18": 0,
"load:load-proc-19": 0,
"load:load1m-proc-19": 0,
"load:load10m-proc-19": 0,
"load:load-proc-20": 0,
"load:load1m-proc-20": 0,
"load:load10m-proc-20": 0,
"load:load-proc-21": 0,
"load:load1m-proc-21": 0,
"load:load10m-proc-21": 0,
"load:load-proc-22": 0,
"load:load1m-proc-22": 0,
"load:load10m-proc-22": 0,
"load:load-proc-23": 0,
"load:load1m-proc-23": 0,
"load:load10m-proc-23": 0,
"load:load-proc-24": 0,
"load:load1m-proc-24": 0,
"load:load10m-proc-24": 0,
"load:load-proc-25": 0,
"load:load1m-proc-25": 0,
"load:load10m-proc-25": 0,
"load:load-proc-26": 0,
"load:load1m-proc-26": 0,
"load:load10m-proc-26": 0,
"load:load-proc-27": 0,
"load:load1m-proc-27": 0,
"load:load10m-proc-27": 0,
"load:load-proc-28": 0,
"load:load1m-proc-28": 0,
"load:load10m-proc-28": 0,
"load:load-proc-29": 0,
"load:load1m-proc-29": 0,
"load:load10m-proc-29": 0,
"load:load-proc-30": 0,
"load:load1m-proc-30": 0,
"load:load10m-proc-30": 0,
"load:load-proc-31": 0,
"load:load1m-proc-31": 0,
"load:load10m-proc-31": 0,
"load:load-proc-32": 0,
"load:load1m-proc-32": 0,
"load:load10m-proc-32": 0,
"load:load-proc-33": 0,
"load:load1m-proc-33": 0,
"load:load10m-proc-33": 0,
"load:load-proc-34": 0,
"load:load1m-proc-34": 0,
"load:load10m-proc-34": 0,
"load:load-proc-35": 0,
"load:load1m-proc-35": 0,
"load:load10m-proc-35": 0,
"load:load-proc-36": 0,
"load:load1m-proc-36": 0,
"load:load10m-proc-36": 0,
"load:load-proc-37": 0,
"load:load1m-proc-37": 0,
"load:load10m-proc-37": 0,
Re: [OpenSIPS-Users] Push notification
On 15.09.2022 10:09, Sergey Pisanko wrote: Hello. I have read this article about push notification support according to rfc 8599 in Opensips 3.1 https://blog.opensips.org/2020/05/07/sip-push-notification-with-opensips-3-1-lts-rfc-8599-supportpart-i/ But I stay confused about one thing.It may be considered to be a "newbie question", but... What can be an "entity" (3rd party app/API) with help of which I can create a subscription for Message Service (for example Firebase) to get the needed "pn" parameters to be inserted into the register sip request? Hi Sergey, Usually, that "entity" is an application on the respective marketplace. For Firebase, it would be an Android App with a unique AppID on the Play Store, allowing you to request that PNs get sent for your ecosystem's devices (soft phones) on behalf of your AppID. For APNS, it would probably be a similar App Store App, with its own unique ID and a similar mechanism. Usually, the developer documentation for each platform should include guides on how to request the PNs using some REST calls, once you register your App and obtain your App ID. Hope this helps, -- Liviu Chircu www.twitter.com/liviuchircu | www.opensips-solutions.com OpenSIPS Summit 2022 Athens, Sep 27-30 | www.opensips.org/events ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips CP Permissions "RELOAD on SERVER" produces error
Hi, Is your opensips listening on the port? netstat -tlnp | grep opensips Do you see any errors in the opensips logs when running doing the reload ? Do you see any communication on the port when doing the reload? ngrep -qtd any port Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/14/22 6:42 PM, mtck01 wrote: Thank you, I managed to load the ‘permissions module’, and no more error, but nothing happens, just stuck on “Sending to json:127.0.0.1:/mi :” without error or successful confirmation. Regards, Martin ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] request uri in failure routes
Hi Richard, having in failure route the initial RURI is the expected behavior. The idea of failure route is to re-take the process of routing and adding new branches, totally independent of the branches you tried before (the new attempts should start from the same "msg" as the previous branches) Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 9/20/22 12:39 AM, Richard Revels wrote: It appears to me that if I set the request uri in a route block and then use t_relay(,"somedestination proxy") to send the call that when it hits the failure route (in opensips 3.2.8) the request uri has been set back to the original uri when the call came in to the proxy. Is this expected behaviour? Probably should start with is this my imagination but it seems to be the case. The scenario is that i set a request uri in the route block and a route header in the branch route and send the call through an outbound proxy and then in the failure route i change the route header and simply send straight to the domain in the request uri but that has since reverted so my INVITE comes back to my proxy on loopback. I can adjust my config but want to be sure i understand what is happening first. Richard Revels ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] request uri in failure routes
It appears to me that if I set the request uri in a route block and then use t_relay(,"somedestination proxy") to send the call that when it hits the failure route (in opensips 3.2.8) the request uri has been set back to the original uri when the call came in to the proxy. Is this expected behaviour? Probably should start with is this my imagination but it seems to be the case. The scenario is that i set a request uri in the route block and a route header in the branch route and send the call through an outbound proxy and then in the failure route i change the route header and simply send straight to the domain in the request uri but that has since reverted so my INVITE comes back to my proxy on loopback. I can adjust my config but want to be sure i understand what is happening first. Richard Revels ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
