<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Check out telemetry: <a href="https://blogs.cisco.com/developer/model-driven-telemetry-sandbox">https://blogs.cisco.com/developer/model-driven-telemetry-sandbox</a></div><div dir="ltr"><br></div><div dir="ltr">You can have the gateway stream data to the collector (such as Telegraf).</div><div dir="ltr"><br></div><div dir="ltr">This works great for streaming the number of channels in use for ISDN. There are probably similar models for SIP.</div><div dir="ltr"><br><blockquote type="cite">On Apr 17, 2023, at 11:14, Hunter Fuller <hf0002@uah.edu> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>The way Ryan describes is the same way we "back into" this information</span><br><span>for our SIP trunks which have a limited number of open calls from our</span><br><span>provider. We are polling the SNMP OIDs for dial-peer incoming and</span><br><span>outgoing calls using Telegraf which places the information in InfluxDB</span><br><span>where Grafana can use it.</span><br><span></span><br><span>Here is the resulting graph:</span><br><span>http://webpages.uah.edu/~hf0002/upload/firefox_wZ43xcw6O0.png</span><br><span></span><br><span>Here is our Telegraf config:</span><br><span></span><br><span>    [[inputs.snmp.table]]</span><br><span>        name = "dial-peers"</span><br><span>        inherit_tags = [ "hostname" ]</span><br><span>        index_as_tag = true</span><br><span></span><br><span>        [[inputs.snmp.table.field]]</span><br><span>            name = "cvCallVolPeerIncomingCalls"</span><br><span>            oid = "1.3.6.1.4.1.9.9.63.1.3.8.4.1.1"</span><br><span>            conversion = "int"</span><br><span></span><br><span>        [[inputs.snmp.table.field]]</span><br><span>            name = "cvCallVolPeerOutgoingCalls"</span><br><span>            oid = "1.3.6.1.4.1.9.9.63.1.3.8.4.1.2"</span><br><span>            conversion = "int"</span><br><span></span><br><span>--</span><br><span>Hunter Fuller (they)</span><br><span>Router Jockey</span><br><span>VBH M-1C</span><br><span>+1 256 824 5331</span><br><span></span><br><span>Office of Information Technology</span><br><span>The University of Alabama in Huntsville</span><br><span>Network Engineering</span><br><span></span><br><span>On Mon, Apr 17, 2023 at 10:52 AM Ryan Huff <ryanhuff@outlook.com> wrote:</span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>There isn’t any great “baked in” way to monitor aggregate usage, however, some things that might help:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Log the output of “debug vpm signal” to the syslog. If you’re time stamping the syslog entries then you could reasonably piece together the times the FXO port’s experience a fxols_onhook_ringing or fxols_proc_voice event.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Use some sort of a traffic grapher like Paessier (PRTG). These platforms tend to have a knack for being able to login to CLIs and execute command structures. If you can do that (one way or the other), frequently capture the output of "show voice port summary" which gives you a real-time / at-the-moment state of each FXO/S voice port</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Absent that, you'd likely be relegated to the above, in an "on demand / manual" way.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Thanks,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Ryan</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Thanks,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Ryan Huff</span><br></blockquote><blockquote type="cite"><span>________________________________</span><br></blockquote><blockquote type="cite"><span>From: cisco-voip <cisco-voip-bounces@puck.nether.net> on behalf of harbor235 <harbor235@gmail.com></span><br></blockquote><blockquote type="cite"><span>Sent: Monday, April 17, 2023 11:15:06 AM</span><br></blockquote><blockquote type="cite"><span>To: Cisco VOIP <cisco-voip@puck.nether.net></span><br></blockquote><blockquote type="cite"><span>Subject: [cisco-voip] FX0 pool exhuastion</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Hi,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I have a CISCO ISR4331 voice bundle (CME) setup with a 4FX0 using 4 analog lines. The number of phones and users have increased and would like to verify justification to add SIP trunks. If we are experiencing no free FX0 lines for inbound or outbound calls does a log message get generated to observe the need to augment the analog line pool or add a sip trunk? I would like an observable data point to justify adding more capacity?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>thanks in advance,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Mike</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>cisco-voip mailing list</span><br></blockquote><blockquote type="cite"><span>cisco-voip@puck.nether.net</span><br></blockquote><blockquote type="cite"><span>https://puck.nether.net/mailman/listinfo/cisco-voip</span><br></blockquote><span>_______________________________________________</span><br><span>cisco-voip mailing list</span><br><span>cisco-voip@puck.nether.net</span><br><span>https://puck.nether.net/mailman/listinfo/cisco-voip</span><br></div></blockquote></body></html>