Networking
--
Questions
--
Followers
Top Experts
VOIP interruptions, spurious noises, malfunctioning.
I'm dealing with performance issues with a VOIP phone system.
The VOIP service provider provides a dedicated internet connection for VOIP and the "PBX" is externally provided by the VSP.
Since the PBX is external, even internal extension-to-extension VOIP calls cause external traffic.
We provide a dedicated VOIP firewall in the form of an RV320 followed by cascaded SG300 switches - configured with a VOIP VLAN with QoS set up.
We provide a dedicated internet connection and firewall for site data - independent of VOIP traffic.
There are 3 sites, each one with separate internet connections, firewalls, etc.
The largest site has about 20 phones and 25 workstations.
The smallest site has about 6 phones and 10 workstations
The middle site has about 9 phones10 workstations.
Data traffic is modest.
I believe the VOIP system is working overall as intended so the "problems" are a matter of service quality I'd say.
Problems are intermittent and include:
- audio is heard at one end and not the other.
- a very loud "screeching noise" is heard at one end or the other and can be audible at one or both ends. Â This is reported to be rather high-pitched and not like loud TV white noise.
- some incoming calls don't arrive on site and go directly to voice mail.
Overall, it's reasonable to say: "while the system seems to "work", service is unacceptable".
Since the 3 sites are each independent of the other re: VOIP, if all sites behave similarly (re: problems) then one might conclude that the problems are likely "external" and with the VSP. Â Yet, the type of internet feed, the VOIP firewall model, the internal switch models are also common.
It may be that the largest site is more affected with problems than the smaller 2 sites. Â That's a little hard to say.
Some thoughts:
- We could hire an expert in VOIP problems and SG300 switch QoS to assess our switch configurations and related network architecture. Â But, going from *no* particular QoS settings to VOIP- favoring priority settings seems to have not had much effect if any.
- We could figure out a way to measure things in order to determine what part of the overall VOIP system is responsible for the problems (thus WHO?). Â
- We are willing to tackle internal problems but don't know now what more to do. Â It would be good to be able to to conclusively determine who needs to tackle the problems ( us or the VSP or both?). Â
- We have limited confidence in the VSP's ability or motivation to address these issues. Â Often, the suggestions from the VSP are that we should instrument this and that. Â This is, in part, understandable. Â But motivation seems low. Â Is that normal?
Any recommendations on any of this?
The VOIP service provider provides a dedicated internet connection for VOIP and the "PBX" is externally provided by the VSP.
Since the PBX is external, even internal extension-to-extension VOIP calls cause external traffic.
We provide a dedicated VOIP firewall in the form of an RV320 followed by cascaded SG300 switches - configured with a VOIP VLAN with QoS set up.
We provide a dedicated internet connection and firewall for site data - independent of VOIP traffic.
There are 3 sites, each one with separate internet connections, firewalls, etc.
The largest site has about 20 phones and 25 workstations.
The smallest site has about 6 phones and 10 workstations
The middle site has about 9 phones10 workstations.
Data traffic is modest.
I believe the VOIP system is working overall as intended so the "problems" are a matter of service quality I'd say.
Problems are intermittent and include:
- audio is heard at one end and not the other.
- a very loud "screeching noise" is heard at one end or the other and can be audible at one or both ends. Â This is reported to be rather high-pitched and not like loud TV white noise.
- some incoming calls don't arrive on site and go directly to voice mail.
Overall, it's reasonable to say: "while the system seems to "work", service is unacceptable".
Since the 3 sites are each independent of the other re: VOIP, if all sites behave similarly (re: problems) then one might conclude that the problems are likely "external" and with the VSP. Â Yet, the type of internet feed, the VOIP firewall model, the internal switch models are also common.
It may be that the largest site is more affected with problems than the smaller 2 sites. Â That's a little hard to say.
Some thoughts:
- We could hire an expert in VOIP problems and SG300 switch QoS to assess our switch configurations and related network architecture. Â But, going from *no* particular QoS settings to VOIP- favoring priority settings seems to have not had much effect if any.
- We could figure out a way to measure things in order to determine what part of the overall VOIP system is responsible for the problems (thus WHO?). Â
- We are willing to tackle internal problems but don't know now what more to do. Â It would be good to be able to to conclusively determine who needs to tackle the problems ( us or the VSP or both?). Â
- We have limited confidence in the VSP's ability or motivation to address these issues. Â Often, the suggestions from the VSP are that we should instrument this and that. Â This is, in part, understandable. Â But motivation seems low. Â Is that normal?
Any recommendations on any of this?
Zero AI Policy
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
It gets trickier when the PBX is in the cloud, partly because the vendor now has much more flexibility to blame things on your side.
One approach I've taken in this scenario is making a VLAN for the phones, then reserve bandwidth for it. I'm not 100% sure your Cisco routers can do it.
Also, who is the VSP? It is possible that you have a pretty crappy one.
One approach I've taken in this scenario is making a VLAN for the phones, then reserve bandwidth for it. I'm not 100% sure your Cisco routers can do it.
Also, who is the VSP? It is possible that you have a pretty crappy one.
If blame needs to be dropped somewhere try to isolate all VOIP traffic without mixing it to other traffic. Â (Separate VLAN, no trunking the VLAN with others to core switches etc. etc.). So separated switch interconnect for VOIP may help.
Network recordings (SIP &Â RTP) of traffic might help analysis (depending on causes, .. )
wrt. SIP traffic to see what messaging does and does not arrive. (Start /Tear down session)
wrt. RTP if it is a regular stream from both sides. Â There should not be any irregular gaps or sudden bursts of packets. (the screatches might easily be caused by this).
For internal comparison measure between router &Â phone. Â ( capture on both ports ).
For external measurement try to measure on WAN.
Besides these recordings: collect a log of when good conversations and failed conversations occurred. Then you can quickly select relevant parts in earlier packet logging.
One sided conversations hint at NAT problems. Those should be visible to in such traces.
Some VSP's operate on small margins spending 1 hour on a customers problem might need months of phone conversations to compensate.
So if there is a quick fix it will be taken if it takes to long they might rather have you take your business elsewhere.
Some food for thought:   You can fairly easy make  an on-prem PBX (Fusion PBX f.e., 3CX)  that will at least take some of the issues (internal conversations) from the equation.
(Also you can have the "internal" calls  between sites taken care of without payment to some 3rd party).
Network recordings (SIP &Â RTP) of traffic might help analysis (depending on causes, .. )
wrt. SIP traffic to see what messaging does and does not arrive. (Start /Tear down session)
wrt. RTP if it is a regular stream from both sides. Â There should not be any irregular gaps or sudden bursts of packets. (the screatches might easily be caused by this).
For internal comparison measure between router &Â phone. Â ( capture on both ports ).
For external measurement try to measure on WAN.
Besides these recordings: collect a log of when good conversations and failed conversations occurred. Then you can quickly select relevant parts in earlier packet logging.
One sided conversations hint at NAT problems. Those should be visible to in such traces.
Some VSP's operate on small margins spending 1 hour on a customers problem might need months of phone conversations to compensate.
So if there is a quick fix it will be taken if it takes to long they might rather have you take your business elsewhere.
Some food for thought:   You can fairly easy make  an on-prem PBX (Fusion PBX f.e., 3CX)  that will at least take some of the issues (internal conversations) from the equation.
(Also you can have the "internal" calls  between sites taken care of without payment to some 3rd party).
noci: Â Thank you for some very interesting ideas!
I'm not a VOIP expert so I'm not sure just how far I can go with recording traffic. Â I'm sure that I can record it but not at all sure that I can analyze it.
Capturing "bad" events means capturing all the traffic - as bad events are unpredictable.
As far as switches, VLANs and trunks:
The largest site has a central LAN switch where the VOIP LAN enters.
There are 2 types of downstream connections:
1) immediate trunked ports on the central SG300 switch for phones/computers.
2) LAG trunked ports downstream to cascaded SG300 switches.
3) trunked ports downstream of the cascaded SG300 switches for phones/computers.
I don't think this is important but just to be complete: at some "desks" there are multiple computers, network printers. Â So those are supported with a DGS-1100-08 switch that is VLAN capable.
The LAGs between the SG300 switches are made up of 3 cables and ports each. Â We could use one of those cables entirely for VOIP and then either use the remaining 2 cables in a LAG for data or have no LAG and just use one cable for data - leaving the 3rd cable as an unused spare. Â
The smaller sites have no LAGs but the downstream (single) cables are trunked. Â
So, a typical smaller site has:
VOIP firewall to:
Central SG300 switch VOIP VLAN port.
Trunked ports to downstream SG300 switches that have phone/computer combinations on trunked ports.
In one case there is a 3rd downstream layer with SG300 switch on a trunked port.
Phone/computer combinations downstream from the 3rd switch.
(Except for the central switch, these are all 10-port SG300 switches)
I'm not a VOIP expert so I'm not sure just how far I can go with recording traffic. Â I'm sure that I can record it but not at all sure that I can analyze it.
Capturing "bad" events means capturing all the traffic - as bad events are unpredictable.
As far as switches, VLANs and trunks:
The largest site has a central LAN switch where the VOIP LAN enters.
There are 2 types of downstream connections:
1) immediate trunked ports on the central SG300 switch for phones/computers.
2) LAG trunked ports downstream to cascaded SG300 switches.
3) trunked ports downstream of the cascaded SG300 switches for phones/computers.
I don't think this is important but just to be complete: at some "desks" there are multiple computers, network printers. Â So those are supported with a DGS-1100-08 switch that is VLAN capable.
The LAGs between the SG300 switches are made up of 3 cables and ports each. Â We could use one of those cables entirely for VOIP and then either use the remaining 2 cables in a LAG for data or have no LAG and just use one cable for data - leaving the 3rd cable as an unused spare. Â
The smaller sites have no LAGs but the downstream (single) cables are trunked. Â
So, a typical smaller site has:
VOIP firewall to:
Central SG300 switch VOIP VLAN port.
Trunked ports to downstream SG300 switches that have phone/computer combinations on trunked ports.
In one case there is a 3rd downstream layer with SG300 switch on a trunked port.
Phone/computer combinations downstream from the 3rd switch.
(Except for the central switch, these are all 10-port SG300 switches)
EARN REWARDS FOR ASKING, ANSWERING, AND MORE.
Earn free swag for participating on the platform.
Wireshark has some VOIP tools on ( one of the submenu's is named "telephony" ) so there is help there.
SIP &Â RTP sub menu's. have extra info if you have a recording.
SIP &Â RTP sub menu's. have extra info if you have a recording.
noci: Â Yes, I've used those tools just a bit. Â Still not an expert on VOIP. Â Well, I could *become* an expert but there's not the personal nor customer bandwidth to justify that. Â As I mentioned at the beginning, a VOIP / SG300 expert might be the right approach.
masnrock: the VSP is Silver Star Telecom in Vancouver, WA.
masnrock: the VSP is Silver Star Telecom in Vancouver, WA.
ASKER CERTIFIED SOLUTION
membership
Log in or create a free account to see answer.
Signing up is free and takes 30 seconds. No credit card required.
AnreLovius: Â Thank you!
I don't see how the "call" can be between the endpoints no matter what. Â
I pretty sure the phones themselves aren't smart enough to do that and there is NO other equipment on site. Â But I suppose it's possible.
We've experienced the following:
- one-way transmission as you've addressed
- bursts of what I would call white noise without interruption of the audio that I could tell
- bursts of very loud screeching and I can't say if the audio was disrupted or not on these cases. Â I have somewhat confirmed that this isn't the same as the white noise bursts. Â
So, I can do a Wireshark capture at the VOIP firewall interface to presumably see all the VOIP traffic.
I can use the Wireshark VOIP analysis tools.
I can capture a ton of "normal" data this way and hope to capture an "event".
I'm pretty sure that I won't know what I'm looking at......
Even so, if this might help us know what's wrong with our network - that would be helpful.
And, if it's not our network, knowing that would be helpful also (I hope).
Thanks for your comment about one-way transmission and QoS. Â From what you said in further explanation suggests that not only won't QoS fix it but that it's not anything internal to our network that we could address, right?
Then too, this is happening at 3 sites that are internally independent.
The only common element is the local communications service provider where fiber-based internet service for VOIP is being used - with fiber internet service to each site.
I don't see how the "call" can be between the endpoints no matter what. Â
I pretty sure the phones themselves aren't smart enough to do that and there is NO other equipment on site. Â But I suppose it's possible.
We've experienced the following:
- one-way transmission as you've addressed
- bursts of what I would call white noise without interruption of the audio that I could tell
- bursts of very loud screeching and I can't say if the audio was disrupted or not on these cases. Â I have somewhat confirmed that this isn't the same as the white noise bursts. Â
More about this reported: Â When the call is inside to outside then the outside caller is the only one to hear the screeching. Â When the call is extension to extension then it apparently can be heard at both ends.
- interrupted audio in short segments with no noises (I was using a cell phone but have never experience this on the cell phone).So, I can do a Wireshark capture at the VOIP firewall interface to presumably see all the VOIP traffic.
I can use the Wireshark VOIP analysis tools.
I can capture a ton of "normal" data this way and hope to capture an "event".
I'm pretty sure that I won't know what I'm looking at......
Even so, if this might help us know what's wrong with our network - that would be helpful.
And, if it's not our network, knowing that would be helpful also (I hope).
Thanks for your comment about one-way transmission and QoS. Â From what you said in further explanation suggests that not only won't QoS fix it but that it's not anything internal to our network that we could address, right?
Then too, this is happening at 3 sites that are internally independent.
The only common element is the local communications service provider where fiber-based internet service for VOIP is being used - with fiber internet service to each site.
Get a FREE t-shirt when you ask your first question.
We believe in human intelligence. Our moderation policy strictly prohibits the use of LLM content in our Q&A threads.
SOLUTION
membership
Log in or create a free account to see answer.
Signing up is free and takes 30 seconds. No credit card required.
noci: Â Thank you!
Re: white noise:
I doubt that white noise of the intensity I heard would be intentional. Â Also I doubt it would be so intermittent.
But that's *interesting"!
Yes, I have experience with Wireshark and the file handling. Â Thanks.
At our end, the only firewall for VOIP (dedicated) is the simple RV320. Â No other data traverses this router. Â SIP Alg is disabled at the request of the VSP - which agrees with what you've said. Â That the system mostly just *works* is an indicator that things are set up correctly at least to a point. Â If QoS isn't going to help then I'm rather stuck as to what *we* can do to our network.
I have not encountered, on our side, anything mentioning RTP nor portrange beyond port settings prescribed for the firewall by the VSP. Â I find in many of these cases that they say we have to have certain ports open when they mean we need to have some of those ports *outgoing* open - which they are by default anyway. Â In those cases, no ports need to be opened and certainly not *incoming* as would be the connotation or blind adherence to the "spec's" provided.
If there are things that you've described that we have to somehow further pay attention to and accomodate, I haven't been told anything about it.  So, I suspect that we are at the mercy of the VSP in that regard   (?).
Said another way, I'm at a loss to know what else we might do or to pursue. Â So, if I've not translated some of what you're telling me then a bit of coaching may still be needed. Â :-o
Re: white noise:
I doubt that white noise of the intensity I heard would be intentional. Â Also I doubt it would be so intermittent.
But that's *interesting"!
Yes, I have experience with Wireshark and the file handling. Â Thanks.
At our end, the only firewall for VOIP (dedicated) is the simple RV320. Â No other data traverses this router. Â SIP Alg is disabled at the request of the VSP - which agrees with what you've said. Â That the system mostly just *works* is an indicator that things are set up correctly at least to a point. Â If QoS isn't going to help then I'm rather stuck as to what *we* can do to our network.
I have not encountered, on our side, anything mentioning RTP nor portrange beyond port settings prescribed for the firewall by the VSP. Â I find in many of these cases that they say we have to have certain ports open when they mean we need to have some of those ports *outgoing* open - which they are by default anyway. Â In those cases, no ports need to be opened and certainly not *incoming* as would be the connotation or blind adherence to the "spec's" provided.
If there are things that you've described that we have to somehow further pay attention to and accomodate, I haven't been told anything about it.  So, I suspect that we are at the mercy of the VSP in that regard   (?).
Said another way, I'm at a loss to know what else we might do or to pursue. Â So, if I've not translated some of what you're telling me then a bit of coaching may still be needed. Â :-o
Eh yes as the PBX is "in-the-cloud" Â your VSP has to tell your what &Â how to setup.
(capabilities of PBX determine what is needed).
Comfort noise should be low-key as a background noise. Â Not a loud hisss. (real silence make people wonder if things still work as we are used to some static discharge on long lines from the POTS days ;-) ).
(capabilities of PBX determine what is needed).
Comfort noise should be low-key as a background noise. Â Not a loud hisss. (real silence make people wonder if things still work as we are used to some static discharge on long lines from the POTS days ;-) ).
Networking
--
Questions
--
Followers
Top Experts
Networking is the process of connecting computing devices, peripherals and terminals together through a system that uses wiring, cabling or radio waves that enable their users to communicate, share information and interact over distances. Often associated are issues regarding operating systems, hardware and equipment, cloud and virtual networking, protocols, architecture, storage and management.