OK how to explain this. This may be more difficult to figure out. We have a signaling server over at one of our other campuses that is hooked up to one of our main campuses. It is an IP enabled Option 61 hooked up thru a C6509. We also have a T1 that goes over to this campus. The problem is that on voice traffic every 3rd word on intermittent calls gets cut off. It can be inbound,outbound, 4 digit or 10. After awhile you can not continue and you have to hang up. Sometimes you have to wait like 10 min before it clears and you can call again. The back ups are done at night. I have thought of a few things like T1 traffic studies, sip channel study. I dont know where to start. Has anyone else had this happen? My boss changes the QOS but it is not remedied. It is not a specific time of day either that it happens. Any ideas?
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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
IP PHONE SERVICE CHOPPY
- Thread starter mhodges
- Start date
Other applications running on what?...the PC? or the phone?
~~~
[small]GHTROUT.com | CS1000 Programming and Feature Guides | Tek-Tips FAQs | Recent Replies[/small]
~~~
[small]GHTROUT.com | CS1000 Programming and Feature Guides | Tek-Tips FAQs | Recent Replies[/small]
- Thread starter
- #22
If the T1 is IP, then any network sniffer program, such as this
~~~
[small]GHTROUT.com | CS1000 Programming and Feature Guides | Tek-Tips FAQs | Recent Replies[/small]
~~~
[small]GHTROUT.com | CS1000 Programming and Feature Guides | Tek-Tips FAQs | Recent Replies[/small]
End-to-end voice quality is affected by latency, packet loss, and jitter. It is also affected by the number of digital<->IP translations and "echo cancellation" applied at various points.
The "Converging the Data Network with VoIP" NTP has a good writeup on "Proactive Voice Quality Management" and the metrics/alarms which can be gathered with respective to Quality of Service.
The "Converging the Data Network with VoIP" NTP has a good writeup on "Proactive Voice Quality Management" and the metrics/alarms which can be gathered with respective to Quality of Service.
Outstanding post gwebster - I think going by that book is the best route.
~~~
[small]GHTROUT.com | CS1000 Programming and Feature Guides | Tek-Tips FAQs | Recent Replies[/small]
~~~
[small]GHTROUT.com | CS1000 Programming and Feature Guides | Tek-Tips FAQs | Recent Replies[/small]
- Thread starter
- #26
OK we are back at it. The vendor did mention to my boss something about diff files.....dont know what that is. He was supposed to send him over something. I have a question. Like in TDM where there is static on a line, you set up a trunk ID number and press it when you hear static. I guess with IP you cant test like that uh? Thinking maybe there is a bad channel.....eh..... If the problem occurs I home my boss will be able to see an IP address. Thank You for all of your help.
- Thread starter
- #27
I don't think there is anything you can do yourself. Someone has to re-engineer the data network.
~~~
[small]GHTROUT.com | CS1000 Programming and Feature Guides | Tek-Tips FAQs | Recent Replies[/small]
~~~
[small]GHTROUT.com | CS1000 Programming and Feature Guides | Tek-Tips FAQs | Recent Replies[/small]
- Thread starter
- #29
You are probably correct. I used the tools you gave me I saw the problem I have reported it and I have to let the powers to be see if they can remedy the problem. If I hear of the fix in the next few days I will let you know. THANK YOU AGAIN,
Variation in the delay is known as "jitter". IP voice relies on having packets received at a given interval in order to reconstruct the voice. If they aren't received in time, then they are dropped. A "jitter buffer" helps to overcome some of this but huge variations in the delay end up being treated the same as lost packets. If you lose packets, you lose parts of the speech and it becomes "choppy" in your original description.
- Thread starter
- #31
OK fill in here. Did a T1 test with the Vendor last night. Tested all 4 ends. No issues. Today went back over to site at 10:50a, got the spike at 11:00a to 11:03a. We were on the call when the phone call went to BAD. So he captured the data, and now I guess he organizes bandwith and packets in some format to review. It only happens for 3 min then calls go back to normal at 11 & 4. This is probably as far as I will know. Thank you all for your expertise and input.
Diff files, or Diff Serv are setting in your Signalling Server. How do you access your media gw cards, or do you use ITG's? Either way, this setting Diff Serv is changed in TM or if you have OTM.
Open TM/OTM look under the IP related stuff and double click whichever card shows up. When opened it should give you a window with a few tabs to chose from. One tab will have things like site name, IP address etc. I forgot exactly which tab it is, but seem to remember the Diff Serv and another box are on the same tab.
Open TM/OTM look under the IP related stuff and double click whichever card shows up. When opened it should give you a window with a few tabs to chose from. One tab will have things like site name, IP address etc. I forgot exactly which tab it is, but seem to remember the Diff Serv and another box are on the same tab.
- Thread starter
- #33
Before I go on to another subject, need to let you know what the problem was here. You ready?
Our PC technicians have this software that goes out every 5 hours and does whatever the software does. (looks for errors etc. )
Well it was scheduled to take up the entire 1.544 mgs of bandwith. My boss was able to reduce how much they took up of the T1 by 1/3. We tested again today at 11:00 and the problem has gone.
I knew it was some application. Just trying to find the problem. Thank You all for helping me isolate this problem. I am glad it was not the NT all along. Thanks again,
Our PC technicians have this software that goes out every 5 hours and does whatever the software does. (looks for errors etc. )
Well it was scheduled to take up the entire 1.544 mgs of bandwith. My boss was able to reduce how much they took up of the T1 by 1/3. We tested again today at 11:00 and the problem has gone.
I knew it was some application. Just trying to find the problem. Thank You all for helping me isolate this problem. I am glad it was not the NT all along. Thanks again,
- Status
Similar threads
