Hi Folks,
I am a Forum Newbie and I hope I am in the right place.
With that said, I have an issue I could really use some help with.
I kinda inherited the responsibility for running and fixing our Asterisk system. We are running Asterisk 1.4.2 on a Dell Power Edge server, dual Processor and 4 gigs RAM with a 4 port PRI card installed. We have 4 lines coming into our company - one main # and the other three are hunt #s. The phones lines are plugged into the PRI Card and the server is on a T1/E1 line to Verizon.
I have one person ( our BOSS! ) who does a lot of traveling and uses his cell phone ( don’t know the service ) to enter our conference rooms. He complains that he gets bounced a lot and is very upset. He wanted to know many concurrent calls will our system handle and why does he get bounced. I could not give him a full explanation because I just don’t know. I am seeing that we also have 23 PRI Lines, so here is my question…
I have tested our system with 7 other people calling in from various locations and using cell phones, standard home phones, and interoffice phones ( SNOMs authenticating on our system ). They were all able to enter a Conf Room and hold a conversation. I am guessing my boss’s issue could be related to his cell service etc but I want to be certain and have a good explanation for him. For now, I would like to know with our set-up - how many concurrent calls can be handled by our system. I am guessing more than 10 ?? and how can I tell if he is being dropped by his cell carrier or is it our system.
Many times I am not monitoring Asterisk CLI when this happens.
I would really appreciate it if someone can give me a brief run-down.
Thank you all.
hi,
it would be helpful if you could see the /var/log/asterisk/message or full. if your /etc/asterisk/logger.conf has enabled the logging, you should find some hints as to why your boss could not join the conference.
regards,
derek
He used a slang term, “bumped”. I read it as the call disconnecting, rather than failing to establish, but clearer terminology would help.
Generally, if Asterisk overloads, you get poor audio quality, not dropped calls.
Thank you for replies -
Sorry for misinformation, but my boss was not very clear on this either. He claims that when he tried to enter a conference call in progress, that he could not enter the room - he called into our main number OK but when he dialed the conference room number he was to join, he never makes it in, he gets dropped from the call. He tried to redial in, and again he gets dropped.
He is suspecting that since he was maybe the 6th person to enter, that there were no more available lines for him to enter on. So that generated my question. Given our set up with 4 phone numbers coming in here and the 23 PRI lines - how many concurrent phone calls can we handle and how this affects how many people can participate in a conference call ?
You can have 23 remote people (assuming that your service provider is giving all 23, presumably T1, channels as both way, or all calls are in the appropriate direction. The number of calls at which the system will run out of CPU power is rather more difficult to determine, but the result is likely to be poor audio more than signalling problems.
It will depend on the nature of the traffic, whether you are monitoring for DTMF, whether you have software echo cancelling, etc.
Verbose console logs from around the point of failure are likely to be useful, although it is sometime easy to produce ones that are too long for people to want to look at.
Thank you david55.
I just wanted to assure my boss that we can handle the concurrent calls - I know for sure we rarely need more than 7 connections from past experience.
I could not tie down what day or time he had the issues as he was on travel and I was not monitoring the CLI logs at the time. The logs are huge and finding that one particular line or 2 would be a daunting job.
If I get advanced notice of a conf. call set-up I’ll be sure to open the command line and keep an eye on the call progress.
So - for now - let’s close this one.
Thank you again.