locked
Feedback/noise for Lync user only on PSTN calls using Cisco ISR gateway RRS feed

  • Question

  • Very strange one here.  I have a client with a Cisco 2901 ISR acting as a gateway for Lync.  Single site, single Standard edition server.  On all PSTN calls, regardless of originating direction, Lync users experience, what I can only describe as "reverse comfort noise".  Anytime audio is generated from the Lync side of the call, a "white noise" is heard by the Lync user, and only the Lync user.  Remote callers do not hear the noise, nor does it occur when the remote caller is speaking.  This noise is not present when no one is speaking.  Further, internal Lync calls are crystal clear.  

    I have also tested an Xlite client registering directly to the Cisco ISR, and during a PSTN call there is no noise.  The issue only occurs when Lync is in a PSTN call using the ISR.  VAD is disabled on the ISR, and I have verified it is not in use during calls.  I have recorded a Lync-to-PSTN call on the Lync server (wireshark) and on the router (PCM dump).  On the server capture, the noise is present on audio packets arriving from the gateway.  It is not present for audio packets leaving Lync going to the gateway.  On the router capture, the noise is not present in either direction.  

    My only conclusion at this point is that the ISR is introducing something in the output stream to Lync via echo-cancellation or other mechanism.  Since this is not present when using a directly-registered SIP client, the Lync-ISR SIP trunk is the only place I can see it possibly being controlled.

    Anyone using ISR gateways with Lync - does this sound familiar?  I am almost to the point of pulling the ISR and putting in another gateway.


    Kevin Clark

    Sunday, July 8, 2012 9:14 PM

Answers

  • Did you ensure when you enabled it that you set the client encryption to supported?

    Without doing this the path to the gateway still flows through the mediation server. If you can take the mediation server out of the picture in the media path it only leaves you with a client issue.


    http://voipnorm.blogspot.com/

    Monday, July 9, 2012 3:38 PM

All replies

  • Hi,Kevin,

    I am not experts on Cisco equipments,per my research,Cisco 2901 ISR should support comfort-noise feature,would you please check the config file for Cisco 2901 ISR to see if you have enable CNG(Comfort noise generation) for it?

    Also please make sure you have the latest firmware for your Cisco ISR and Lync server has been fully patched.

    B/R

    Sharon


    Sharon Shen

    TechNet Community Support

    ************************************************************************************************************************

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question.

    Monday, July 9, 2012 9:58 AM
  • http://voipnorm.blogspot.com/2011/05/important-settings-to-know-when.html

    You have two options for comfort noise on the ISR. Turn it off or make sure that its supporting the correct RFP by changing the RTP payload setting. See below for both.

    Option 1

    dial-peer voice 1999 voip
    tone ringback alert-no-PI
    description TO Lync
    destination-pattern 55555
    session protocol sipv2
    session target
    ipv4:192.168.1.250:5068
    session transport tcp
    dtmf-relay rtp-nte
    codec g711ulaw
    fax protocol none
    no vad

    Option 2

    dial-peer voice 1999 voip
    tone ringback alert-no-PI
    description TO Lync
    destination-pattern 55555
    session protocol sipv2
    session target
    ipv4:192.168.1.250:5068
    session transport tcp
    dtmf-relay rtp-nte
    codec g711ulaw
    fax protocol none
    rtp payload-type comfort-noise 13

    Cheers

    Chris


    http://voipnorm.blogspot.com/

    Monday, July 9, 2012 3:21 PM
  • Thanks Sharon.  I have validated comfort noise is enabled on the PSTN ports (FXO), and have tested with it both enabled and disabled with no change in behavior.  I have also tried both the documented supported IOS version (15.1.3T) as well as the latest MR track version (15.1.4). 

    Kevin Clark

    Monday, July 9, 2012 3:26 PM
  • Thanks Chris.  I actually have been very thankful for your blog and the guidance you've provided.  Couldn't have completed the initial deployment without your help!  I have tried both options as documented on your site, but the issue persists.  Initially I was concerned that perhaps calls where hitting the default dial peer (where VAD is enabled by default) instead of my defined dial peers, but I have confirmed that is not the case.  I have confirmed that VAD is not in use during a call as well.  

    I have been fighting this for a few weeks now, and will likely try another gateway option, as this is increasingly business-impacting.  


    Kevin Clark

    Monday, July 9, 2012 3:30 PM
  • Do you have media bypass enabled?

    Cheers

    Chris


    http://voipnorm.blogspot.com/

    Monday, July 9, 2012 3:32 PM
  • Yes, I have MB enabled now.  Was originally disabled, but enabled as part of our testing/troubleshooting.  No change in behavior.

    Kevin Clark

    Monday, July 9, 2012 3:36 PM
  • Did you ensure when you enabled it that you set the client encryption to supported?

    Without doing this the path to the gateway still flows through the mediation server. If you can take the mediation server out of the picture in the media path it only leaves you with a client issue.


    http://voipnorm.blogspot.com/

    Monday, July 9, 2012 3:38 PM
  • Hmmm...I did not.  Is this command you're referring to?:  set-csmediaconfiguration –identity global –encryptionlevel supportencryption.

    Kevin Clark

    Monday, July 9, 2012 3:46 PM
  • That's the one. Without this the client still sends media through the mediation server because the client cant negotiate encryption with a gateway that doesn't support it.

    Cheers

    Chris


    http://voipnorm.blogspot.com/

    Monday, July 9, 2012 3:48 PM
  • I implemented the command above, and am happy to report that so far, the call quality has noticeably improved.  While the noise is still present, it is much less intrusive and more of a background sound now.  Users report that call clarity is significantly better.  I'm still curious why the issue is present at all, and will know more once we have a full day's use of the system.  

    Thanks again Chris for your guidance!


    Kevin Clark


    Monday, July 9, 2012 6:45 PM