Is there a way to get a set of call statistics logs from a C series CODEC (running either TC5.x or above) to show thing like packet lost as seen and being reported to the CODEC during a call?
Call history is relatively sparse and although the event.all file shows certain packet loss issue WRT corrupt header as they arrive at the CODEC, I would like to see and overall packet count per call type of log - in a similar fashion to the media statistics as seen on the Call logs on the VCSs.
Cheers Nikita, yep should have said that I knew about that, what I was interested in was a log I could pull off after a call had finished so that I could marry it up to other logs from other devices (such as a VCS, MCU etc).
As soon as a call finishes, so the xstatus for the call disapears.
I am not sure about how you are looking into it from the VCS/MCU here, however to get a proper call capture you can try the commands during the call if it can be re-created.
Select “Telnet” and enter the System IP address in “Host Name”.
(Or select “SSH” and enter the System IP address in “Host Name” in order to establish SSH connection between systems.)
Select “Logging” and choose “All session output” and select location of saving file and file name at “Log file name” and save this at the desktop -
Log-in into the codec using putty via telnet/ssh and run these commands-
log ctx h323Packet debug 9
log ctx RTPStatistics debug 3
log output on
Make a call and keep running until you have recreated the problem
Hang up call
log ctx h323Packet debug off
log ctx RTPStatistics debug off
log output off
After this, you can check this log file and along with it, download the log.tar.gz file.
This should be great.
Obviously the packets as seen be the CODEC are based on a end to end call - i.e. from the MCU to the CODEC. The CODEC can figure out packets lost on inbound traffic as it simple a case of counting the RPT packet sequence, but for out bound traffic, the figure has to be reported back to the CODEC via the H.245 channel by the terminating dive upstream (i.e. an MCU or another endpoint). However, the MCU we use are outside of the organisations we manage and so the call traverses both a VCS-E and VCS-C to get to the CODEC. This means that we can also check the call history and the media stats from the VCSs to see flows in a particular leg of a call and network segment, i.e.:
MCU --> VCS-E --> || --> VCS-C --> CODEC
So, through a process of deduction you can determine the network segment an issue lies. In general we find issue are mainly between the VCS-E and VCS-C (i.e. across an network border), but if the CODEC reports a higher loss than is seen on the inbound flow at the VCS-C, then we can say they issue is likely to be on the internal network.
Seeing the stats from the endpoint, MCU and VCS, give a very good overview on where exacty a problem lies.
I like to see the raw logs after a call has dropped as well as during, so I hope this will help.
Hello Chris -
If the codec is running TC6.x software or above, you can check the web interface for diagnostic information for an active call.
Yep, know about this one too and for the TC6 + CODEC its great, but I was looking specifically for a log. Hopfully what Nikita has give above will do the job.