Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

SV9500 IP Phone Trace Route 1

Status
Not open for further replies.

budbyrd

Vendor
Jul 28, 2011
1,628
1
2
38
US
We have a multi site SV9500 system that we are getting the packet loss beep warnings on some extensions. It is only happening at one of our remote locations.
Is there a command in the SV9500 that can help find where the packet loss is coming from? Our IT department is reporting no problems with bandwidth. They are asking me to find out if there is some sort of log file or trace that can help find where the problem is located.

Dermis and feline can be divorced by manifold methods.*
*(Disclaimer for all advise given)--'Version Dependent'
 
That is what I was thinking too. Our IT department wanted to see if there was something in the PBX that would help them not take the blame. When I worked on Avaya systems they had some limited diagnostics you could do but you usually end up needing to do a port mirror and a Wireshark trace.

Dermis and feline can be divorced by manifold methods.*
*(Disclaimer for all advise given)--'Version Dependent'
 
The phones store some kind of log in them but only NEC has the software to read them. Per them recently, it is not well documented how they read them.

There will not be a log in the PBX because the PBX is not involved in the RTP stream. That connection is Peer to peer, even if you are going from the Phone to the IP Pad card.

The beep is caused by the RTP traffic and is generated at the phone side. If the user isn't actually having an issue with audio you can turn the beep off in the phone menu. Not the admin menu but the user menu. I have done this system wide at a customers site. Note this is an indication they have something not quite correct about their network.





There are 10 kinds of people in the World.

Those that understand Binary and those that don't.
 
@DDL Thanks for the info. The users are reporting choppy audio and dropped calls on top of the beeping. I had looked through the admin menu and didn't find the RTP alarm setting but I do find it in the user settings on my phone Now I just need to check the other phone models. I know turning it off is just putting tape over the check engine light but it will make my boss happy not to have to listen to end users complain about the beeping.

[wink]

Dermis and feline can be divorced by manifold methods.*
*(Disclaimer for all advise given)--'Version Dependent'
 
For choppy audio make sure your location groups are set correctly. ALOCL and AIVCL if you have no data in those sections then that is an issue. Make sure the QOS values are set correctly in both of those commands. ALOCL at one time would have been set to a DSCP of 26 or 28 but now is standardized on 40. AIVCL would be QOS DSCP 46.

Do a test call on the IP Phone and look at DCON for that extension. Make sure the payload and codec are what you should be expecting. As SIP turnks have all standardized on 20ms payloads I have adopted that for within our networks. Primarily I stick with G.711 first and if necessary G.729 second.

If you have SiP trunks do you have an SBC between the MGSIP and your trunks?

Which takes us to the next question. Is the issue station to station within each site or only between each site?



There are 10 kinds of people in the World.

Those that understand Binary and those that don't.
 
The problem is mainly with external calls and calls to other sites. In the big picture I doubt it is a programming issue. The site has been up and running without issues for over eight years. The network it's self is outside the scope of my responsibilities so I am not going to be sticking my nose to far into that part.

Dermis and feline can be divorced by manifold methods.*
*(Disclaimer for all advise given)--'Version Dependent'
 
You are in an awkward situation because it is not in the interest of the IT department to fix this because they simply blame the telephone system and recommend replacing it with a pure VoIP system and that extends their domain. I had this happen a year or two ago with an SV9100 for a law firm, the system started having issues and the IT firm denied any issue but persuaded the CEO to replace it with a VoIP system which then had pretty much the same problems. They then blamed the carrier. I walked away from it at that point! Oh and the CEO gave me the old system which is currently in my lab and hasn't missed a beat since I put it in there!
 
This site uses a remote gateway. This is a system with about 4000 end points. We have over 1000 DIDs. At this site it is a flat network. What I don't know is what changed in the network. I do know it is a network issue. I just really was looking for a way and method to push it back to the network team. I think I have that. I really do appreciate all the input.

Dermis and feline can be divorced by manifold methods.*
*(Disclaimer for all advise given)--'Version Dependent'
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top