×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

SV9500 IP Phone Trace Route

SV9500 IP Phone Trace Route

SV9500 IP Phone Trace Route

(OP)
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'

RE: SV9500 IP Phone Trace Route

You will want to set up a Wireshark trace.

RE: SV9500 IP Phone Trace Route

(OP)
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'

RE: SV9500 IP Phone Trace Route

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.

RE: SV9500 IP Phone Trace Route

(OP)
@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'

RE: SV9500 IP Phone Trace Route

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.

RE: SV9500 IP Phone Trace Route

(OP)
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'

RE: SV9500 IP Phone Trace Route

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!

RE: SV9500 IP Phone Trace Route

Are they on a VLAN or flat network?

RE: SV9500 IP Phone Trace Route

(OP)
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'

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login


Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close