cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1842
Views
0
Helpful
8
Replies

MeetingPlace 8.5.2. After mute all (#8 1) some users cannot hear the conference.

e.blandini
Level 1
Level 1

Hello,

I have a question for you. During the conference if I put all in mute using the combination #8 1, correctly all partecipants going in mute. If I repeat the procedure #8 1 to put in mute all another partecipant that is joined to the conference later, some users cannot hears the conference.

Any idea?

1 Accepted Solution

Accepted Solutions

Hi Enzo,

I assume you reproduced the issue and had Debug Wave Recording.

If you extract the infocap log file, you should find a folder autolog/. In that folder as described in DWR documentation, for each participant in the specific meeting, you should have 5 audio files:

Example:

• dwr000_zaharije.lab.pst_c749_ep_072610_115605.p00.wav

• dwr000_zaharije.lab.pst_c749_ep_072610_115605.p01.wav

• dwr000_zaharije.lab.pst_c749_ep_072610_115605.p02.wav

• dwr000_zaharije.lab.pst_c749_ep_072610_115605.p03.wav

• dwr000_zaharije.lab.pst_c749_ep_072610_115605.p98.wav

As described in the documentation, each of these files represents the different part of audio processing. you can compare the incoming audio file (p00) with the outgoing audio file p98 for each participant and see if there are participants that have nothing played in the outgoing file (keep in mind that outgoing audio file for the person talking want include that persons audio)

If you don't identify any 'no audio' issues for any of the files, then the issue is not seen on MeetingPlace but somewhere else.

Also, in the infocap logs, in /logs directory in CCASIP log file you can trace the signaling for SIP messages for the affected caller (person reporting the audio was lost) and see if there are any issues with negotiation/renegotiation, loss of RTP stream or something. If something is observed, you might need to enable packet capturing on the switchport connecting to the MP App server, reproduce the issue and all the steps with DWR and collect infocap logs and packet captures and open a TAC case for further troubleshooting.

Unfortunately, this is not an issue that is easy to troubleshoot via this forum. I hope you understand.

-Dejan

View solution in original post

8 Replies 8

dpetrovi
Cisco Employee
Cisco Employee

Hi,

Can you provide the exact version of MeetingPlace you are running as well as if you are running in Express or Hardware Media Mode/

Thank you.

-Dejan

Hi Dejan,

i'm using MP 8.5.2 with express media mode in audio only deployment.

thanks

Enzo

Hi Enzo,

I am not aware of any defect that could cause this behavior. However, we can do two things.

1. Since 8.5.2 version is a base MP8.5 version, I would advise you to upgrade your system to MP8.6. Here you can find all the defects that were resolved since 8.5.2:

http://www.cisco.com/en/US/docs/voice_ip_comm/meetingplace/8_6/english/releasenotes/mp86rn.html#wp301291

I don't say that the issue you are seeing is caused by any of the defects listed, but it would be beneficial to bring the system to the latest version level. That way, if the issue is still there, you can reach out to TAC for further investigation.

2. If you don't want to upgrade just yet, you can first try to reproduce the issue and collect Debug Wave Recording of the issue, so we can review it and investigate further.

Here are more details about Debug Wave Recording feature on MP8.5 Express Media mode.

Any audio quality issue (in this case loss of audio) requires either capturing sniffer traces or running a Debug Wave Recording  (DWR) by the participant when the issue is happening. In this specific scenario, Debug Wave Recording would be much easier to do (but for smaller conferences), as it can be initiated by the end user and can be initiated when the issue is happening. If we have DWR initiated and the issue is recorded, then taking the System Information Capture (Infocap) logs for the entire duration of the affected meeting would also collect those recordings and provided us with the way to analyze the audio and investigate if the audio was lost for a participant in the meeting, or there is something else there.

Here are more details about Debug Wave Recording and how to initiate it.

In MP8.5 in Express Media Mode we can use Debug Wave Recording (DWR) tool at the time of the issue.

In order to do this, we will need to do the following.

If you are in the meeting and end users are experiencing loss of audio issue, initiate Debug Wave Recording (DWR). If there are up to 5 people in the conference, only 1 end user needs to initiate DWR by entering the following DTMF sequence: 1 3 7 9 5 0. After command is accepted, short beep will be played only for the endpoint from which DWR has been initiated. If there are more than 5 people in the conference, each end user you want to collect the recording for will have to initiate DWR by entering the 1 3 7 9 5 0 DTMF sequence.

When DWR is initiated, continue conversing for 30 seconds in order to record the issue (static, garbled audio, echo, no audio, etc.). Once the issue is clearly reproduced, you can either hang up or continue with the conference and DWR will stop automatically after 30 seconds. Then you need to wait for the meeting to end and collect infocap logs (Administration Center > Services > Logs > System Information Capture) for the entire time of the meeting (from 5min before the meeting was started to 5 min after the meeting ended). Infocap logs should contain recording files as well, so we should be able to analyze them. With the logs, collect the meeting number, time of the issue, and possibly a caller that experienced the issue (username, or ANI of the phone used)

Here are all the details about Debug Wave Recording:

Debug Wave Recording


6 Tracking and Recording AQ issues
The best and safest way to track audio quality problem is to record the problem, and to distribute it to the experts. Debug Wave Recording [DWR] is a new feature developed in MP8.5 for recording wave audio files for debugging purposes.
Audio files are recorded using most important points from decoding, mixing, and encoding process.
Streams to be recorded are:
• after decoding of the packet and PLC (this point represent input signal, in case there is lost packet, Packet Loss Concealment algorithm will be used to make up for missing data)
• after processing point 1 after Line Echo Cancellation LEC and Noise Cancellation NC modules
• after processing point 2, main recording, before mixing and after Automatic Gain Control AGC
• after mixing, conference recording
• before encoding, before sending (this point represent output signal)

DWR is designed to record wave files for short amount of time [10-60s], default is 30s. Only one DWR for single endpoint/conference can be started at the time.

6.1 How DWR system works?
DWR can be started from endpoint by pressing DTMF command combination.
When DWR is initiated by entering DTMF stream command:
• (Up to 5 calls in the conf.) recordings will be started for all participants in the conference
• (More than 5 calls in the conf.) recording will be started only for single channel which has initiated the recordings

6.1.1 File names and location
File name format is:
• dwrAAA_BBBB...B_cXXX_epYYYY_date_time.pZZ.wav
Description of the fields:
• AAA - unique session ID for particular DWR
• BBBB...B - up to 16 chars for host name
• XXX - conference ID
• YYYY - endpoint ID, for mixer recording this will be empty string
• data - format MMDDYY
• time - format hhmmss, 24 hours representation
• ZZ - stream ID

  • 98 //recording point, conference slice, output      from mixer
  • 00 //recording point, main point before entering      mixer
  • 01 //recording point, after decoding RTP packet
  • 02 //recording point, after first level of      processing
  • 03 //recording point, before encoding packet for      endpoint

Example:
• dwr000_zaharije.lab.pst_c749_ep_072610_115605.p01.wav

Location of the files:
• /mpx-record/conf/dwr/


6.1.2 DWR and infocap
Infocap script will pull automatically DWR recordings from proposed time period set by infocap cli command. All DWR files will be copied to folder autolog/ inside the infocap main folder. There are no links to recording inside infocap HTML pages.


6.1.3 Amount of recorded DWR kept in history
Session ID is number used for controlling total numbers of files from growing out of limits.
Session ID is set to be from 0 to 99.
History could keep up to 100 DWRs. For 101st DWR overwrite will occur.


6.1.4 System constraints
It is tested that system will work stable if:
• total number of simultaneous recorded files is less than 400
• total number of conferences available for simultaneous recording is 10


6.2 DWR Usage
DWR can be started from endpoint by pressing DTMF (only RFC2833 standard) stream command "1 3 7 9 5 0".
After command is accepted short beep will be played only for endpoint from which DWR has been initiated.

I hope this will help you.

-Dejan

Hi Dejan,

Thank you very much for your help.

At the moment I cannot upgrade the solution to the version 8.6, so I'm going to reproduce the issue and collect Debug Wave Recording.

I'll post the results tomorrow.

Best regards

Enzo

Hi Dejan,

I have took the logs from MP. Please, could you help me to verify them? What should I check?

Best regards

Enzo

Hi Enzo,

I assume you reproduced the issue and had Debug Wave Recording.

If you extract the infocap log file, you should find a folder autolog/. In that folder as described in DWR documentation, for each participant in the specific meeting, you should have 5 audio files:

Example:

• dwr000_zaharije.lab.pst_c749_ep_072610_115605.p00.wav

• dwr000_zaharije.lab.pst_c749_ep_072610_115605.p01.wav

• dwr000_zaharije.lab.pst_c749_ep_072610_115605.p02.wav

• dwr000_zaharije.lab.pst_c749_ep_072610_115605.p03.wav

• dwr000_zaharije.lab.pst_c749_ep_072610_115605.p98.wav

As described in the documentation, each of these files represents the different part of audio processing. you can compare the incoming audio file (p00) with the outgoing audio file p98 for each participant and see if there are participants that have nothing played in the outgoing file (keep in mind that outgoing audio file for the person talking want include that persons audio)

If you don't identify any 'no audio' issues for any of the files, then the issue is not seen on MeetingPlace but somewhere else.

Also, in the infocap logs, in /logs directory in CCASIP log file you can trace the signaling for SIP messages for the affected caller (person reporting the audio was lost) and see if there are any issues with negotiation/renegotiation, loss of RTP stream or something. If something is observed, you might need to enable packet capturing on the switchport connecting to the MP App server, reproduce the issue and all the steps with DWR and collect infocap logs and packet captures and open a TAC case for further troubleshooting.

Unfortunately, this is not an issue that is easy to troubleshoot via this forum. I hope you understand.

-Dejan

Hi Dejan,

thank you very much for your help. Now I know what I must check and I can open a case to the TAC.

Have a nice day

Enzo

Thank you, Enzo. Enjoy your day as well.

-Dejan