Call statistics log for C series CODECs

[Chris Swinney]

Hi All,

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.

Many thanks

Chris

[Nikita Shrivastava]

Hi,

You can check the xstatus captured during call.

[Chris Swinney]

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.

Chris

[Nikita Shrivastava]

Hi Chris,

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.

Start Putty

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-

Xstatus

Xconfig

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

Xstatus

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.

[Chris Swinney]

Hi Nikita,

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.

Many thanks

[Patrick Sparkman]

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.

http:///web/status/Diagnostics

[Chris Swinney]

Hi Patrick,

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.

Chris