Pull a Wireshark capture before the ingate during an affected call. Pick an RTP stream and analyze the stream. It will allow you actually listen to the audio of the call before it enters your network. If the call quality is OK, pull the capture from the ingate. Then pull one from inside the network. Easiest way to figure out where the problem lies.
If you have a layer 3 switch, you can port mirror the port the phone is on so you can get all data going to the phone. To grab packets before your ingate, use a hub, not a switch to make sure you get all traffic. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Matt White Sent: Friday, July 29, 2011 2:35 PM To: [email protected] Subject: Re: [sipx-users] Poor Call Quality and Issues Transferring Calls On SipXecs 4.0.1-015823 >>> 07/29/11 2:20 PM >>> >> >>--Please enter your response above this line-- >> >> >>Can anyone tell me which logs we need to look at on this? >> If it were me I would run a packet capture (wireshark)....not look at logs. Logs and sipx-trace files are great for signaling issues (transfers, failed calls etc) but they do not log much at all about the RTP streams. So it simply wont log issues with latency in the voice. If you capture the traffic via wireshark you can then analyze the RTP stream. It will even select and mark packets where it thinks it causes voice issues. And I see your using an ingate which has a built-in packet capture feature which is a really nice. So you can capture packets at the ingate and see where the issue is at. Doing a capture at the switch level via a port monitor is good too, helps you determine if the issue is inside or outside the network. -M _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
<<attachment: Max DiOrio.vcf>>
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
