<div dir="ltr">Hi Michael,<div><br></div><div>can you please provide the version you have installed on the system of the following packages?</div><div>* ngcp-rest-api</div><div>* ngcp-panel</div><div><br></div><div>Thank you</div><div><br></div><div>Marco</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jul 23, 2026 at 12:18\u202fPM Ml Ml via Spce-user <<a href="mailto:spce-user@lists.sipwise.com">spce-user@lists.sipwise.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
We're running Sipwise mr13.5.1 and use GET<br>
/api/subscriberregistrations/ (the classic v1-style URL, we are not<br>
calling /api/v2/... explicitly) for external monitoring (Nagios) to<br>
track how many SIP<br>
subscribers are currently registered system-wide.<br>
<br>
Until recently this worked for mr6.5.1 by reading the total_count<br>
field from an unfiltered/lightly-paginated request, which reflected<br>
the true total independent of the "rows" pagination parameter. At some<br>
point this<br>
changed:<br>
<br>
total_count now simply echoes back the requested "rows" value instead<br>
of the real total:<br>
- ?page=1&rows=1 -> total_count: 1<br>
- ?page=1&rows=100 -> total_count: 100<br>
- ?page=1&rows=1000 -> the request itself never completes; it times<br>
out server-side after ~60s with no response at all.<br>
<br>
We noticed from the mr13.5.1 changelog that several endpoints have<br>
been migrated to a new "API v2" backend while keeping their original<br>
v1-style URL. We don't know whether /api/subscriberregistrations/<br>
received the same treatment, but the symptom (total_count now equals<br>
whatever<br>
"rows" was requested, and large requests time out) looks exactly like<br>
the kind of regression that backend swap could cause. Can anyone<br>
confirm whether this endpoint was migrated, and if so, whether this<br>
is a known issue?<br>
<br>
We tried working around it by requesting larger row counts to force<br>
total_count up to the true value, but any request above roughly<br>
500-1000 rows for this endpoint reliably times out, so that isn't<br>
viable<br>
at our scale (~6k active subscribers).<br>
<br>
So, two questions for the list:<br>
1. Is the total_count regression on GET /api/subscriberregistrations/<br>
a known issue, and is a fix planned/available?<br>
2. What is the currently recommended way, via API, to get an accurate<br>
count of currently active/registered SIP subscribers?<br>
<br>
Thanks,<br>
Michael<br>
<br>
-- <br>
Spce-user mailing list<br>
<a href="mailto:Spce-user@lists.sipwise.com" target="_blank">Spce-user@lists.sipwise.com</a><br>
<a href="http://lists.sipwise.com/mailman/listinfo/spce-user_lists.sipwise.com" rel="noreferrer" target="_blank">http://lists.sipwise.com/mailman/listinfo/spce-user_lists.sipwise.com</a><br>
</blockquote></div>