Ok so at midnight from my phone the brain, not super effective…
Here is what you are getting which is actually covered above in your posted change log.
So the output you sent me (representative):
The explanation of why it is this way is above also.
You have a PRI. You are thinking of it as analog channels which have a 1 to 1 mapping on channels. A call comes in on channel 1 it should be DAHDI/1
This isn’t the case with PRI.
PRI is like sip.
On sip you have a controller port 5060, on PRI you have a Data channel 24.
Both of these handle everything about the call except audio. All call setup and tear down happens here.
On sip you have RTP ports 10,000-20,000. Your calls audio happens here. This is only needed if the call requires an audio path. A big complaint is one way audio or no audio when users first setup because they didn’t configure their firewall or NAT correctly. The call is up but they can’t hear each other. This is because the actual call happens on 5060 which they usually poke a hole for but they didn’t poke the audio holes.
On PRI you have B channels. These channels are dumb. They don’t do anything but pass audio. A call on a PRI that doesn’t require audio doesn’t need a B channel. A PRI can hold up a call without audio releasing the B channel then assign it when audio is needed.
So the point of it all is this:
Don’t concern your self with how often a call is using B Channel foo. Take the entire span as a whole.
12:00 span 1, 5 calls
12:05 span 1, 2 calls
12:10 span 1, 8 calls
12:15 span 1, 4 calls
12 PM hour peak 10, average 8.
If my PRI allows 10 calls I may want to bump if I average 8 and am maxing out.
If it peaked at 8 and averaged 4 maybe 10 is ok.
You have to figure out how to analyze the data…