Bad Audio - Good Report

If I make a Lync call, and the audio I hear is terrible because there are gaps where I hear nothing while the other person is talking, but the Lync reports indicate everything was fine: short round trip, MOS 3.7 or better, minimal packet loss and jitter,etc.

What does that mean?  Are the Lync reports unreliable, or is there a gap in what they record?

April 17th, 2012 2:26am

do you receive a high value on the glitch rate of your Audio device? maybe the headset/Audio Driver cause issues
Free Windows Admin Tool Kit Click here and download it now
April 17th, 2012 11:18am

The call was made with a Polycom phone, so there is no glitch rate data.
April 17th, 2012 5:50pm

John,

Can you duplicate the call quality issues when using the Lync client as the end points?

Free Windows Admin Tool Kit Click here and download it now
April 17th, 2012 7:57pm

I can not duplicate call quality issues.  They happen infrequently enough that I can not reproduce them, but frequently enough to be a problem.
April 17th, 2012 11:43pm

Hi,John,

Which report did you look at for the audio quality?

There are many reports in Lync monitoring server,and not only one includes the audio quality,here are the description for them

Media Quality Summary Report   The Media Quality Summary Report provides overall quality data for different endpoint types, including Enterprise Voice peer-to-peer calls, Enterprise Voice conference calls, and calls that rely, at least in part, on the public switched telephone network (PSTN).

Server Performance Report   The Service Performance Report lists the servers that have experienced the most problems, based on measurements of such key quality metrics as degradation, packet loss, and jitter.

Location Report   The Location Report provides a list of network locations and a summary of the media quality of the calls that occur at each location. For purposes of this report, locations are based on IP subnets.

Device Report   This report provides a summary of devices that are used for Enterprise Voice calls and it includes the average media quality of the calls by device.

Call List Report   The Call List Report provides detailed information about phone calls made or received within your organization.

Call Detail Report   The Call Detail Report provides detailed information about phone calls made from or received within your organization.

In addition,here is a great blog taliking about improving the voice quality for your reference.

http://blogs.technet.com/b/nexthop/archive/2011/04/04/voice-quality-improvements-in-lync-server-2010.aspx 

Hope these useful!

B/R

Sharon

Free Windows Admin Tool Kit Click here and download it now
April 18th, 2012 10:51am

I am using the User Activity Report / Peer-to-Perr Session Detail Report.  It is the most useful report for when a user reports problems specific to their call.  I have never found anything in the other reports that improves on it.

April 18th, 2012 8:05pm

Can you paste the details from one session where the client reported there was an error. 
Free Windows Admin Tool Kit Click here and download it now
April 24th, 2012 10:09pm


    Peer-to-Peer Session Detail Report
                           
Session Information
     Pool FQDN:    LyncPool1.dom.abc.com    Front end:    SRV220.dom.abc.com
     Invite time:    4/16/2012 12:58:29 PM    Capture time:    4/16/2012 12:58:29 PM
     Response time:    4/16/2012 12:58:42 PM    End time:    4/16/2012 1:01:16 PM
     From user:    judy.smith@abc.com    To user:    5036661234;phone-context=Portland
     From user agent:    CPE/4.0.7577.4047 OCPhone/4.0.7577.4047 (Microsoft Lync 2010 Phone Edition)    To user agent:    RTCC/4.0.0.0 MediationServer
     Is From user internal    Yes    Is To user internal:    Yes
     Is From user integrated with desk phone:    Yes    Is To user integrated with desk phone:    No
     Session Priority    Unknown    Is retried session:    No
     Response code:    200    Diagnostic ID:    51004
Voip Information
     From phone number:    +15036009876    To phone number:    5036661234;phone-context=Portland
     From mediation server:         To mediation server:    srv220.dom.abc.com
     From gateway:         To gateway:    meg01.dom.abc.com
     Disconnected by:    judy.smith@abc.com        
    

Media Quality Report
                                         
 UC-Mediation Server Leg Information
     Caller PAI:    
sip:judy.smith@abc.com
    Callee PAI:    
sip:5036661234;phone-context=Portland@blount.com;user=phone
    
     Caller URI:    
sip:judy.smith@abc.com
    Callee URI:    
sip:+5036661234@blount.com;user=phone
    
     Caller endpoint:    OCPhone    Callee endpoint:    PDXSRV220    
     Caller user agent:    CPE/4.0.7577.4047 OCPhone/4.0.7577.4047 (Microsoft Lync 2010 Phone Edition)    Callee user agent:    RTCC/4.0.0.0 MediationServer/4.0.7577.183    
     Call start:    4/16/2012 12:58:42 PM    Duration:    00:02:34    
     Mediation Server bypass call    False    Media bypass warning flag         
     Caller OS:    WINCE 6.0    Callee OS:    Windows 6.1.7601 SP: 1.0 Type: 3 (Server) Suite: 0000000000000110 Arch: x64 WOW64: False    
     Caller CPU:    ARM    Callee CPU:    CPU Brand GenuineIntel Family 0x6 Model 0x2c EM64T MaxFunc 0xb MaxFuncExt 0x80000008    
     Caller CPU core number:    1    Callee CPU core number:    8    
     Caller CPU speed:         Callee CPU speed:    2.527 GHz    
     Caller CPU virtualization:    None    Callee CPU virtualization:    None    
     Media Line (Main Audio)    
          MediaLine Information
          Caller report received:    True    Callee report received:    True
          Connectivity    Direct    Transport    UDP
          Caller ICE warning flag    There were no failures or ICE was not used.    Callee ICE warning flag    There were no failures or ICE was not used.
          Applied bandwidth limit:    151 Kbps    Applied bandwidth source:    StaticMax
          Caller IP:    10.10.22.200    Callee IP:    10.10.0.160
          Caller subnet:    10.10.22.0    Callee subnet:    10.10.0.0
          Caller user site:    Main_Site
Callee user site:    Main_Site
          Caller region:    Main    Callee region:    Main
          Caller MAC address:         Callee MAC address:    F0-4D-A2-01-B0-87
          Caller connection type:    Wired    Callee connection type:    Wired
          Caller Basic Service Set Identifier (BSSID)         Callee Basic Service Set Identifier (BSSID)    
          Caller link speed:    10000 Kbps    Callee link speed:    1000000 Kbps
          Caller inside:    True    Callee inside:    True
          Caller VPN:    False    Callee VPN:    False
                                             
          Caller Device and Signal Metrics
          Capture device:    UCPhone
Capture device driver:    POLYCOM_CX600
          Render device:    UCPhone
Render device driver:    POLYCOM_CX600
          Send signal level:    -15 dBov    Receive signal level:    -18 dBov
          Send noise level:    -66 dBov    Receive noise level:    -90 dBov
          Echo return:         Initial signal level RMS:    112.092
                                             
          Callee Device and Signal Metrics
          Echo return:         Initial signal level RMS:    1597.953
                                             
                                             
          Caller Client Event
          Low network bandwidth time:    0.00 %    High network delay time:    0.00 %
          Poor network receive quality time:    0.00 %    Poor network send quality time:    0.00 %
                                             
          Callee Client Event
                                             
          Audio Stream (Callee -> Caller)
          Codec:    PCMU    Sample rate:    8000
          Audio FEC:    False    Bandwidth estimates:    8324 Kbps
          Packet utilization:    8118                   
          Avg. packet loss rate:    0.00 %    Max. packet loss rate:    0.00 %
          Avg. jitter:    1 ms    Max. jitter:    4 ms
          Avg. round trip:    6 ms    Max. round trip:    9 ms
          Burst duration:    0 ms    Burst gap duration:    161020 ms
          Burst density:    0.00 %    Burst gap density:    0.00 %
          Avg. concealed samples ratio:    0.00 %    Avg. stretched samples ratio:    0.00 %
          Avg. compressed samples ratio:    0.00 %                   
          Avg. network MOS:    3.70    Min. network MOS:    3.69
          Avg. network MOS degradation:    0.00    Max. network MOS degradation:    0.01
          NMOS degradation (jitter):    0.00 %    NMOS degradation (packet loss):    0.00 %
                                   
          Audio Stream (Caller -> Callee)
          Codec:    PCMU    Sample rate:    8000
          Audio FEC:    False    Bandwidth estimates:    6799 Kbps
          Packet utilization:    10208                   
          Avg. packet loss rate:    0.00 %    Max. packet loss rate:    0.00 %
          Avg. jitter:    1 ms    Max. jitter:    1 ms
          Avg. round trip:    5 ms    Max. round trip:    9 ms
          Burst duration:    0 ms    Burst gap duration:    202840 ms
          Burst density:    0.00 %    Burst gap density:    0.00 %
          Avg. concealed samples ratio:    0.00 %    Avg. stretched samples ratio:    1.00 %
          Avg. compressed samples ratio:    0.00 %                   
          Avg. network MOS:    3.71    Min. network MOS:    3.64
          Avg. network MOS degradation:    0.00    Max. network MOS degradation:    0.07
          NMOS degradation (jitter):    0.00 %    NMOS degradation (packet loss):    0.00 %
                                   
 Mediation Server-Gateway Leg Information
     Caller PAI:    
sip:+15036009876@SRV220.dom.abc.com;user=phone
    Callee PAI:    
sip:5036661234@meg01.dom.abc.com;user=phone
    
     Caller URI:    
sip:+15036009876@SRV220.dom.abc.com;user=phone
    Callee URI:    
sip:5036661234@meg01.dom.abc.com;user=phone
    
     Caller endpoint:    SRV220
Callee endpoint:    meg01.dom.abc.com
 
     Caller user agent:    RTCC/4.0.0.0 MediationServer/4.0.7577.183    Callee user agent:    PBX-IP Media Gateway/2.1    
     Call start:    4/16/2012 12:58:42 PM    Duration:    00:02:34    
     Mediation Server bypass call    False    Media bypass warning flag         
     Caller OS:    Windows 6.1.7601 SP: 1.0 Type: 3 (Server) Suite: 0000000000000110 Arch: x64 WOW64: False    Callee OS:         
     Caller CPU:    CPU Brand GenuineIntel Family 0x6 Model 0x2c EM64T MaxFunc 0xb MaxFuncExt 0x80000008    Callee CPU:         
     Caller CPU core number:    8    Callee CPU core number:         
     Caller CPU speed:    2.527 GHz    Callee CPU speed:         
     Caller CPU virtualization:    None    Callee CPU virtualization:         
     Media Line (Main Audio)    
          MediaLine Information
          Caller report received:    True    Callee report received:    False
          Connectivity    Direct    Transport    UDP
          Caller ICE warning flag    There were no failures or ICE was not used.    Callee ICE warning flag    
          Applied bandwidth limit:    151 Kbps    Applied bandwidth source:    StaticMax
          Caller IP:    10.10.0.160    Callee IP:    10.10.0.139
          Caller subnet:    10.10.0.0    Callee subnet:    
          Caller user site:    Main_Site    Callee user site:    
          Caller region:    Main    Callee region:    
          Caller MAC address:    F0-4D-A2-01-B0-87    Callee MAC address:    
          Caller connection type:    Wired    Callee connection type:    Wired
          Caller Basic Service Set Identifier (BSSID)         Callee Basic Service Set Identifier (BSSID)    
          Caller link speed:    1000000 Kbps    Callee link speed:    
          Caller inside:    True    Callee inside:    True
          Caller VPN:    False    Callee VPN:    False
                                             
          Caller Device and Signal Metrics
          Echo return:         Initial signal level RMS:    692.0392
                                             
          Callee Device and Signal Metrics
                                             
          Caller Mediation Server Metrics
          Received noise level:    -83 dBov    AGC signal:    -45 dBov
          AGC gain:    12 dB         
                                             
          Caller Client Event
                                             
          Callee Client Event
                                             
          Audio Stream (Caller -> Callee)
          Codec:    PCMU    Sample rate:    8000
          Audio FEC:    False    Bandwidth estimates:    0 Kbps
          Packet utilization:    5096                   
          Avg. packet loss rate:    0.00 %    Max. packet loss rate:    0.00 %
          Avg. jitter:    0 ms    Max. jitter:    2 ms
          Avg. round trip:    2 ms    Max. round trip:    3 ms
                                   
          Audio Stream (Callee -> Caller)
          Codec:    PCMU    Sample rate:    8000
          Packet utilization:    8118                   
          Avg. packet loss rate:    0.00 %    Max. packet loss rate:    0.00 %
          Avg. jitter:    0 ms    Max. jitter:    0 ms
          Burst duration:    0 ms    Burst gap duration:    161040 ms
          Burst density:    0.00 %    Burst gap density:    0.00 %
          Avg. concealed samples ratio:    0.00 %    Avg. stretched samples ratio:    0.00 %
          Avg. compressed samples ratio:    0.00 %                   
          Avg. network MOS:    3.71    Min. network MOS:    3.71
          Avg. network MOS degradation:    0.00    Max. network MOS degradation:    0.00
          NMOS degradation (jitter):    0.00 %    NMOS degradation (packet loss):    0.00 %

April 24th, 2012 11:15pm

Thanks! So this is what I see.  The burst gap duration numbers are 600% higher than anything I can find in my environment.  If I'm reading the description (below) clearly these are the amount of time packets were disgarded because they didnt make it in time.  Which means a ton of the audio would be estimated and either sound computery or silent (assuming there was silence before and after the out of order packets.)

 I've asked a friend to validate, but in the meantime can you mark your packets and ask the network team to prioritize them as voice?

Free Windows Admin Tool Kit Click here and download it now
April 25th, 2012 1:58am

Thanks! That's very helpful.

I'll look into it here to.

I am surprised that the report does not highlight that number with yellow or red, like it does some of the other metrics, like MOS and jitter, if it is really that bad!

April 25th, 2012 6:01pm

Based on some research I did, Duration is only relevant when combined with density.

Density = loss, so a long Duration with a Density(loss) of zero %, like my report shows, is a very good thing!


Free Windows Admin Tool Kit Click here and download it now
April 25th, 2012 7:19pm

I just had a call myself, where part of what I heard kept cutting-out.  It was from PSTN, to gateway, to Mediation server, to me.

The report for the leg Mediation server to me shows:

    Audio Stream (Caller -> Callee)

Codec: PCMU Sample rate: 8000
    Audio FEC: False Bandwidth estimates: 99012 Kbps
    Packet utilization: 5431         
    Avg. packet loss rate: 0.00 % Max. packet loss rate: 0.00 %
    Avg. jitter: 0 ms Max. jitter: 0 ms
    Avg. round trip: 2 ms Max. round trip: 31 ms
    Burst duration: 0 ms Burst gap duration: 100260 ms
    Burst density: 0.00 % Burst gap density: 0.00 %
    Avg. concealed samples ratio: 0.00 % Avg. stretched samples ratio: 0.00 %
    Avg. compressed samples ratio: 1.00 %         
    Avg. network MOS: 3.71 Min. network MOS: 3.71
    Avg. network MOS degradation: 0.00 Max. network MOS degradation: 0.00
    NMOS degradation (jitter): 0.00 % NMOS degradation (packet loss): 0.00 %
    Avg. listening MOS 3.88 Min. listening MOS 1.69
                
    Audio Stream (Callee -> Caller)
    Codec: PCMU Sample rate: 8000
    Audio FEC: True Bandwidth estimates: 77441 Kbps
    Packet utilization: 4227         
    Avg. packet loss rate: 0.00 % Max. packet loss rate: 0.00 %
    Avg. jitter: 2 ms Max. jitter: 7 ms
    Avg. round trip: 2 ms Max. round trip: 31 ms
    Burst duration: 0 ms Burst gap duration: 83160 ms
    Burst density: 0.00 % Burst gap density: 0.00 %
    Avg. concealed samples ratio: 0.00 % Avg. stretched samples ratio: 1.00 %
    Avg. compressed samples ratio: 2.00 %         
    Avg. network MOS: 3.66 Min. network MOS: 3.60
    Avg. network MOS degradation: 0.05 Max. network MOS degradation: 0.10
    NMOS degradation (jitter): 0.00 % NMOS degradation (packet loss): 0.00 %
    Avg. sending MOS 3.14 Min. sending MOS 2.07

What I don't understand is why the Min listening and sending MOS are so low, with no other inidcators I can see that there is something wrong.
April 25th, 2012 11:34pm

Yes, I'm at a loss as well. It seems odd that with that many packets disgarded you wouldnt get a bad call red highlight.  Anyway, I've reached out to an associate at Microsoft who is doing a little research on what they expect the call quality to be like with a value as high as yours.  I'll let you know what they respond.
Free Windows Admin Tool Kit Click here and download it now
April 26th, 2012 2:31am

My source just confirmed that the higher the burst gap duration the better. The closer that number is to the duration of the call the better.

We can assume that the call degredation is occuring before the call gets to the mediation server ?  Can you get these details for the other half of the

April 26th, 2012 2:46am

I am seeing the same issue on Polycom CX600 phones.  random "echo"
Free Windows Admin Tool Kit Click here and download it now
April 27th, 2012 9:35pm

By 'other half of call', I assume you mean the report for gateway to mediation server, which is just as good, if not better:

Burst density

The fraction of RTP (Real-Time Transport Protocol) data packets within burst periods since the beginning of reception that were either lost or discarded. A burst period is a period in which a high proportion of packets are either lost or discarded due to late arrival. Burst density is used in the call detail report.

Audio Stream (Callee -> Caller)
    Codec: PCMU Sample rate: 8000
    Audio FEC: False Bandwidth estimates: 0 Kbps
    Packet utilization: 4445        
    Avg. packet loss rate: 0.00 % Max. packet loss rate: 0.00 %
    Avg. jitter: 0 ms Max. jitter: 0 ms
    Avg. round trip: 2 ms Max. round trip: 3 ms
               
    Audio Stream (Caller -> Callee)
    Codec: PCMU Sample rate: 8000
    Packet utilization: 5485        
    Avg. packet loss rate: 0.00 % Max. packet loss rate: 0.00 %
    Avg. jitter: 0 ms Max. jitter: 0 ms
    Burst duration: 0 ms Burst gap duration: 108380 ms
    Burst density: 0.00 % Burst gap density: 0.00 %
    Avg. concealed samples ratio: 0.00 % Avg. stretched samples ratio: 0.00 %
    Avg. compressed samples ratio: 0.00 %        
    Avg. network MOS: 3.71 Min. network MOS: 3.71
    Avg. network MOS degradation: 0.00 Max. network MOS degradation: 0.00
    NMOS degradation (jitter): 0.00 %

NMOS degradation (packet loss): 0.00%

April 27th, 2012 9:50pm

That and the gateway to that device as your logs show the call on your end was perfect.  You can use wireshark or netmon to capture and listen to all the packets on the mediation server to check the audio quality there and compare it what youre hearing on the Lync endpoint. 

Free Windows Admin Tool Kit Click here and download it now
April 30th, 2012 11:31pm

Can you provide more information on how to capture the audio?  I have tried both Wireshark and Netmon, but with all the media traffic encrypted, I have never gotten it to work as advertised.
May 8th, 2012 5:40pm

Sadly or luckily for me, the sip trunk between cisco and the mediation server is not tls so I simply have to capture it.  I've read a couple articles on how to decrypt tls traffic which might help you http://blog.schertz.name/2010/10/lync2010-client-tls-only/.

There was also a twitter post by a member of the lync community detailing how to do it, but i cant find the post.  But it referenced the same tool in the post linked above. Basically you capture the traffic, locate the key, then us the key against the udp stream.

Free Windows Admin Tool Kit Click here and download it now
May 9th, 2012 7:34pm

Did you ever find an answer?   I'm having the same problem with AAstra 6725IP phones.
March 8th, 2013 1:36am

No.  No answer yet.
Free Windows Admin Tool Kit Click here and download it now
March 8th, 2013 11:33pm

in your client policy do you happen to have the EnableClientMusicOnHold option set to true?
March 25th, 2013 4:04pm

EnableClientMusicOnHold=True
Free Windows Admin Tool Kit Click here and download it now
March 25th, 2013 5:20pm

On friday we had one of our remote users calling from his cell phone and we were able to consistently recreate the issue.  What we found,  after several test scenarios, was that the issue never happened on the software client.  We also noticed that for some reason the software client wasn't playing the hold music.  In order to make things equal between the software client and phone edition, we turned off that option and the distortion went away.  We are still testing this theory and I have submitted our findings to the microsoft support tech we have been working with on this issue but had no reply.
March 25th, 2013 6:20pm

We are still having the issue, even on calls that aren't put on hold.
Free Windows Admin Tool Kit Click here and download it now
March 28th, 2013 12:31am

Would you be interested in comparing notes?  So far the outsourced help from Microsoft has been rather useless.  The had me turn off TCP offloading on the FE servers but that didn't help.
March 28th, 2013 6:55pm

Would you be interested in comparing notes?  So far the outsourced help from Microsoft has been rather useless.  The had me turn off TCP offloading on the FE servers but that didn't help.

Sure.

Yes, I have been told the "turn off TCP offloading" too.

I had some similar experiences recently, but I do not know they are related:

I was on an audio conference, using a vendor's bridge.  Several of my co-workers were on the same call.  I heard the moderator breaking up, and so did my co-workers.  I was using Lync software client.  When I dropped off the call, it suddenly got better for them.  When I re-joined, it got worse again, but not as bad as before.  The call reports showed no issues.

Later that week, I was on another audio conference, using a vendor's bridge.  It sounded fine to me, but the moderator complained my connection was causing background noise.  I did notice that, even when I was not talking, the vendor's web-based conference interface showed my phone connection as transmitting.  I switched from the software client, to my Polycom CX600, and it solved that problem.  I related this story to a co-worker, who has much more experience with end-users experience, and he said my experience is not unusual when using the software client and an inexpensive USB headset.

Free Windows Admin Tool Kit Click here and download it now
March 28th, 2013 9:53pm

I have a few questions... What kind of gateway are you using?  Are your Lync servers physical of virtual?  Lync Standard or Enterprise edition?
April 1st, 2013 7:03pm

Physical Lync Enterprise Edition.

The gateways are Dialogic DMG2060

Free Windows Admin Tool Kit Click here and download it now
April 4th, 2013 3:37am

I have the same issue here: good call report, but bad audio randomly.

The only parameter that is really different between a good and a bad call is AGC Signal.

A bad call has AGC Signal -73 dBov and a good call has AGC Signal -28 dBov.

When looking in the tables of QOE (http://technet.microsoft.com/en-us/library/gg398064.aspx), you can see that the RxAGCSignalLevel should be between -30 and -18 dBov.

I'm still looking for a solution to this problem.
@John Crouch: can you confirm the same behavior in bad and good calls? I saw in your post earlier that AGC Signal was -45 dBov.

April 15th, 2013 2:59pm

Thanks for the AGC info.

Yes, it was -45.  I do some more checking of call logs, and see if that is typical or not for here.

Free Windows Admin Tool Kit Click here and download it now
April 16th, 2013 10:15pm

John,

I came accross a similar issue when using the DMG, I found disabling the Line Echo Cencellation solved the problem.

This can be located under DSP Settings.

I believe the microphone on the handsets may have been a too sensititve and as such the DMG was treating it as noise.

June 28th, 2013 5:11pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics