locked
Polycom cx600, 700 quality problems vs good quality on PC with USB headset on same WAN RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Datacenter:  45Mbps MPLS with a dedicated 2Mbps SIP trunking directly to split out mediation server, 2 EE FEs, 1 Edge

    Branch: 6Mbps MPLS WAN to Datacenter.  3 test EV Lync users with laptops and usb headsets and DIDs from datacenter SIP trunk.  2 polycom phones cx600 and 700 signed in with same users, not tethered, just straight IP.  DHCP setup correctly, phones sign in fine and peer to peer calls on the LAN work great.  WAN is not saturated with traffic (monitored with stealthwatch).

    Issue:  Any PSTN calls to or from users that come into the datacenter SIP trunk are answered by the EV test users in the branch site and:

    1. IF the call is answered on the laptop with a usb headset, the quality is fine, and reminds fine testing a full 5min call.  Tested with CAC w/ BW policies and also with no BW policies on the branch subnet.
    2. IF the call is answered with a Polycom cx600 or 700 (which has the latest firmware) the phones quickly spit out "Poor network conditions are causing audio quality...." and the quality is aweful.

    All the tests were fair as whatever PSTN number we used to call the laptop users, we also used to call the polycom phones.  I'm not sure what to make of it, and any suggestions would be great.

    -Chad

    Thursday, May 31, 2012 8:20 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote
    QoS priority was finally enabled and the issues have gone away.  Still odd that a WAN line less than 30% used had issues with the polycom phones, and the pc client worked great.  Nonetheless it appears the g711/722 codec is more sensitive to this and the router QoS adjustments fixed the issue.

    -Chad

    • Marked as answer by philldogger Monday, June 4, 2012 8:46 PM
    Monday, June 4, 2012 8:45 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    One other note, the polycom always receives the audio fine....ie...the PSTN caller's voice comes out fine on the polycom phone, but when the polycom user talks back the PSTN user only hears a robotic, poor quality audio.

    I'm going to run more tests that dont have to do with PSTN users and just peer to peer calls over the WAN to another WAN site using polycom endpoints to see how it fairs as well.

    -Chad

    Friday, June 1, 2012 3:25 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Did some further tests with cx600,700 just doing a conference call over the WAN to the FE server.  Same problems...the polycom phone can hear audio from Lync (who are using laptops/headsets) but when the polycom user talks the lync users with headsets hear garbage.  Not sure if it matters but we use inband provisioning for audio ports:

    Set-CsConferencingConfiguration -ClientAudioPort 20000 -ClientAudioPortRange 40 and i can see the phones are using these ports correctly outbound.

    Still the same results with laptop/headset users...everything works fine and WAN is not saturated.  Should note we do not have QoS yet for these audio ports and we will eventually, but the tests should succeed on some level especially when the WAN is not saturated.  I think something else is going on with outbound audio from the polycom phones since inbound always sounds fine on the phones.

    -Chad

    Friday, June 1, 2012 7:33 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Update:  Did a peer to peer call across the WAN to a Lync/laptop/headset user using my polycom phone.  It worked fine, meaning the RTAudio codec works....but the G.711 PSTN calls and G.722 conference calls are the problem.  When using those codecs across the WAN the issue arises.  Any suggestions?

    -Chad

    Friday, June 1, 2012 7:52 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Call Information - polycom phone call to FE server conference

    Caller PAI:
       

    sip:cphillips@wabtec.com

       

    Callee PAI:
       

    sip:cphillips@wabtec.com;gruu;opaque=app:conf:audio-video:id:9VVJL6G4

       

    Caller URI:
       

    sip:cphillips@wabtec.com

       

    Callee URI:
       

    sip:cphillips@wabtec.com;gruu;opaque=app:conf:audio-video:id:9VVJL6G4

       

    Caller endpoint:

    OCPhone

    Callee endpoint:

    WCSSRV0198

    Caller user agent:

    CPE/4.0.7577.4066 OCPhone/4.0.7577.4066 (Microsoft Lync   2010 Phone Edition)

    Callee user agent:

    RTCC/4.0.0.0 AV-MCU/4.0.7577.183

    Call start:

    6/1/2012 4:10:52 PM

    Duration:

    00:03:46

    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:

    12

    Caller CPU speed:

    Callee CPU speed:

    3.066 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

    Bandwidth policy restriction decreases the Bandwidth.

    Applied bandwidth limit:

    151 Kbps

    Applied bandwidth source:

    StaticMax

    Caller IP:

    172.22.5.238

    Callee IP:

    10.0.22.8

    Caller subnet:

    172.22.4.0

    Callee subnet:

    10.0.20.0

    Caller user site:

    MPL.MotivePower

    Callee user site:

    WCS.Datacenter

    Caller region:

    WabtecGlobal

    Callee region:

    WabtecGlobal

    Caller MAC address:

    Callee MAC address:

    00-17-A4-77-00-6A

    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:

    2000000 Kbps

    Caller inside:

    True

    Callee inside:

    True

    Caller VPN:

    False

    Callee VPN:

    False

    Caller Device and Signal Metrics

    Capture device:

    UCPhone

    Capture device driver:

    UCPhone FM Audio Driver

    Render device:

    UCPhone

    Render device driver:

    UCPhone FM Audio Driver

    Send signal level:

    -9 dBov

    Receive signal level:

    -23 dBov

    Send noise level:

    -58 dBov

    Receive noise level:

    -90 dBov

    Echo return:

    Initial signal level RMS:

    0

    Callee Device and Signal Metrics

    Echo return:

    Initial signal level RMS:

    71.68922

    Caller Client Event

    Voice switch time:

    Low SNR time:

    0.00 %

    Low network bandwidth time:

    0.00 %

    High network delay time:

    0.00 %

    Poor network receive quality time:

    0.00 %

    Poor network send quality time:

    93.00 %

    Callee Client Event

    Audio Stream (Caller -> Callee)

    Codec:

    SIREN

    Sample rate:

    16000

    Audio FEC:

    True

    Bandwidth estimates:

    1460 Kbps

    Packet utilization:

    4581

    Avg. packet loss rate:

    65.71 %

    Max. packet loss rate:

    85.77 %

    Avg. jitter:

    4 ms

    Max. jitter:

    12 ms

    Avg. round trip:

    249 ms

    Max. round trip:

    460 ms

    Burst duration:

    4298 ms

    Burst gap duration:

    836 ms

    Burst density:

    69.10 %

    Burst gap density:

    0.00 %

    Avg. concealed samples ratio:

    71.00 %

    Avg. stretched samples ratio:

    2.00 %

    Avg. compressed samples ratio:

    4.00 %

    Avg. network MOS:

    1.50

    Min. network MOS:

    1.50

    Avg. network MOS degradation:

    2.25

    Max. network MOS degradation:

    2.25

    NMOS degradation (jitter):

    5.00 %

    NMOS degradation (packet loss):

    94.00 %

    Audio Stream (Callee -> Caller)

    Codec:

    SIREN

    Sample rate:

    16000

    Audio FEC:

    False

    Bandwidth estimates:

    4215 Kbps

    Packet utilization:

    2192

    Avg. packet loss rate:

    0.28 %

    Max. packet loss rate:

    2.14 %

    Avg. jitter:

    9 ms

    Max. jitter:

    15 ms

    Avg. round trip:

    174 ms

    Max. round trip:

    174 ms

    Burst duration:

    310 ms

    Burst gap duration:

    13113 ms

    Burst density:

    19.35 %

    Burst gap density:

    0.00 %

    Avg. concealed samples ratio:

    5.00 %

    Avg. stretched samples ratio:

    5.00 %

    Avg. compressed samples ratio:

    11.00 %

    Avg. network MOS:

    4.12

    Min. network MOS:

    4.01

    Avg. network MOS degradation:

    0.17

    Max. network MOS degradation:

    0.28

    NMOS degradation (jitter):

    0.00 %

    NMOS degradation (packet loss):

    0.00 %

    -Chad


    Friday, June 1, 2012 8:26 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    QoS priority was finally enabled and the issues have gone away.  Still odd that a WAN line less than 30% used had issues with the polycom phones, and the pc client worked great.  Nonetheless it appears the g711/722 codec is more sensitive to this and the router QoS adjustments fixed the issue.

    -Chad

    • Marked as answer by philldogger Monday, June 4, 2012 8:46 PM
    Monday, June 4, 2012 8:45 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    This issue was most likely caused by the fact that by default the Windows Lync client does not use QoS tagging, but all Lync Phone Edition clients do. 

    Lync Server stamps media traffic with DSCP 40 for all LPE devices by default and often times network QoS is configured for other DSCP values (e.g. 46 EF) and this packets tagged with other values may actually be de-prioritized versus the untagged traffic coming from the Windows desktop clients.

    See this article for more details: http://blog.schertz.name/2011/08/lync-qos-behavior/

    Jeff Schertz | Microsoft Solutions Architect - Polycom | Lync MVP


    Tuesday, June 5, 2012 11:49 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Hey Jeff, you may be right, however we don't use diffserv for qos, just ports and IPs and different priority queues.  Also it was only issue with SIREN on the phones as rtaudio calls were fine.  Needless to say once we put the audio port range in a higher queue it all works.

    -Chad


    Tuesday, June 5, 2012 2:01 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Correction, even with QoS we still have about a 75ms avg round trip, meaning all our calls from the branch site are using SIREN instead of g711/722.  I was mistaken in alienating these two codecs as the issue, when the whole time only SIREN is being used for conference calls.  Either cu3 or 4 changed the ms requirement to be >25ms in order to use g722.  Unfortunately even with WAN QoS in place we cannot seem to get that low.  Any other branch site deployments experience the same?  Maybe another reason to deploy Std ed FE server at the branch.

    -Chad


    Tuesday, June 5, 2012 6:49 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I've seen the same quality issues with our Polycom CX600's where the mediation server/gateway are on the same LAN. I've set the device configuration to use DSCP 0 just like PC clients but it seems to have had no effect. Not exactly sure where to go on this one other than dive into the world of QoS. And then I'm not sure whether to go the DSCP or port range route.
    Friday, June 8, 2012 5:35 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Start with some QoE reports from your monitoring server, also check with your network group if they are doing Diffserv for QoS already.  If this is on your local LAN and you have a gateway, are you using media bypass, and if so what is the call quality for PSTN calls made with the cx600?  Lastly see if your local switches are using LLDP for assigning phones to different VLANs.  This may or may not pertain to your issue, but there is another post about setting the VLAN ID to high for polycom Lync phones to use: http://social.technet.microsoft.com/Forums/en-US/ocsvoice/thread/c4a10ffd-0ec6-49a2-86e0-0de060062218

    As far as choosing to go DSCP or just port range route...that's really up to your network group and how they do WAN QoS today....you just have to join the ride as Lync accomodates both.  Our MPLS network doesn't use diffserv so no tagging stuff for me via GPOs....just inband provisioning and giving the network guys the audio port range to plug into a QoS queue for me.

    -Chad

    Friday, June 8, 2012 8:56 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Start with some QoE reports from your monitoring server, also check with your network group if they are doing Diffserv for QoS already.  If this is on your local LAN and you have a gateway, are you using media bypass, and if so what is the call quality for PSTN calls made with the cx600?  Lastly see if your local switches are using LLDP for assigning phones to different VLANs.  This may or may not pertain to your issue, but there is another post about setting the VLAN ID to high for polycom Lync phones to use: http://social.technet.microsoft.com/Forums/en-US/ocsvoice/thread/c4a10ffd-0ec6-49a2-86e0-0de060062218

    For example, here is a call that entered from the PSTN to a Polycom CX600 at the same site as the gateway/mediation server (but different VLAN) and a QoE report shows 'Poor network send quality time: 21.00%'. I'm not seeing anything highlighted in yellow or red in the audio stream info, the codec is PCMA and media bypass is enabled. We are not using LLDP and we do not have any phones in VLAN's higher than 512. I'm gonna make a lot of test calls today and see if I can notice a trend.
    Tuesday, June 19, 2012 4:42 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Since you don't use LLDP I'm assuming you are using DHCP option 43 to put the cx600 in a diff vlan? (or maybe its just simple vlan ports)  If so, for troubleshooting, remove that and get your phones on your data vlan to test.  Do this to isolate the issue to something networking and not the phone.  You may need to soft reset your polycom phones.  See how testing goes on that vlan your softphone users use.

    -Chad

    Wednesday, June 20, 2012 4:00 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Nope, it's simply a port untagged for that VLAN with the phone plugged in.. And it isn't necessarily a VOIP only VLAN, there are many workstations and even servers on it. I'm still working on trying to replicate the issue but it seems so random. If I can do that I'll move the phone to the same VLAN as the gateway/mediation server and go from there. I'm not a huge networking guy but I don't see how a simple VLAN hop would cause quality problems.
    Wednesday, June 20, 2012 7:14 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    hard to say, it could be layer 3 vlan routing has some bottlenecks on switch/routers.  But yeah the same vlan test should help in the troubleshooting steps to isolate the issue.

    -Chad

    Wednesday, June 20, 2012 7:19 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I can’t find a suitable place to inquire about polycom cx600. Polycom cx600 prompts “Poor network conditions are causing audio quality issues”. Based on what standard is this error prompt thrown?
    Wednesday, December 18, 2019 8:42 AM