locked
Troubles placing PSTN calls on hold RRS feed

  • Question

  • We recently began having issues placing calls on hold and transferring to the Parking Lot.  I sent a call trace to our gateway manufacture and they say the gateway is working as it is supposed to, and our SIP trunk provider says the same thing about the SIP trunk.  Both are saying Lync is the issue.

    Our setup looks like this:

    Windstream SIP trunk >> Audiocodes Mediant 1000 Gateway >> Lync 2010 Standard Edition >> Polycom CX600

    All Lync-to-Lync calls can be placed on hold and transferred to the parking lot just fine, but when a call is made to, or received from, the SIP trunk, we can not place those calls on hold.  I'm not aware of any changes in our Lync or AudioCodes gateway configuration and Windstream is telling me that everything is working fine on their end.

    When a call is placed on hold from a Polycom CX600, the phone reports "Hold Unsuccessful" and the Mic Mute button illuminates.  As far as we can tell, there is no way to get connected back to the call other than to transfer the call to another phone.  If we press the Mic Mute button, there is still audio.  The PSTN caller does hear hold music during this time.

    When  a call is placed on hold from the Lync client, it also reports that the call could not be placed on hold, but the PSTN caller does not hear hold music in that case.

    I have placed a scrubbed trace file from our AudioCodes gateway here:
    https://drive.google.com/file/d/0B_NQ__cZSk8wUkxaOGJseWZGNVU/edit?usp=sharing

    Our trunk is configured as follows in Lync:

    Identity                            : Service:PstnGateway:CDOL-PSTN-GW.CDOL.int
    OutboundTranslationRulesList        : {Description=;Pattern=\+1((402((21[79])|(
                                          32[35678])|(3(04|09|10|14|18))|(41[3679])
                                          |(42[0139])|(43[0245678])|(46[4567])|(47[
                                          012345679])|(48[0134689])|(4(00|05|40|41|
                                          50|58))|(61[037])|(79[012456789])|(8(02|0
                                          5|53|58))|((202|261|499|525|540|560|570|5
                                          80|601|665|730|742|770|817|820|840|875|89
                                          0|904|937|975))|(78))));Translation=$1;Na
                                          me=No-Prefix Local, Description=;Pattern=
                                          ^\+91((531(3\d))|(402(21[79]|30[49]|31[04
                                          8]|32[35678]|40[05]|41[3679]|42[0139]|43[
                                          ^139]|44[01]|45[08]|46[4567]|47[^8]|48[^2
                                          57]|61[037]|79[^3]|80[25]|85[38]|90[34]|2
                                          02|261|499|525|540|560|570|580|601|665|73
                                          0|742|770|817|820|840|875|890|937|975|78\
                                          d)));Translation=$1;Name=9-Prefix Local,
                                          Description=;Pattern=^\+(1\d{10})$;Transl
                                          ation=$1;Name=No-Prefix National, Descrip
                                          tion=;Pattern=^\+9(1\d{10})$;Translation=
                                          $1;Name=9-Prefix National...}
    SipResponseCodeTranslationRulesList : {}
    Description                         :
    ConcentratedTopology                : True
    EnableBypass                        : False
    EnableMobileTrunkSupport            : False
    EnableReferSupport                  : False
    EnableSessionTimer                  : True
    EnableSignalBoost                   : False
    MaxEarlyDialogs                     : 20
    RemovePlusFromUri                   : False
    RTCPActiveCalls                     : False
    RTCPCallsOnHold                     : False
    SRTPMode                            : Optional
    EnablePIDFLOSupport                 : False

    Any help or suggestions would be greatly appreciated!

    Jason

    Monday, November 11, 2013 6:18 PM

All replies

  • Jason,

    Try these two options... 

    - To change the security setting on AudioCodes  (Voip->Media->Media Security->Media Security Behavior). The current setting should be Mandatory so change this setting from Mandatory to Preferable -

    - Play with Refer Support setting in Lync control panel 

    Sunday, November 17, 2013 9:54 AM
  • Thanks for the reply Hemat.  Our Media Security was configured to Mandatory, as you said.  I changed this to Preferable and made a test call.  Unfortunately, the Hold was still unsuccessful.

    Then I went to the Lync Control Panel and enabled Refer support.  I waited about 10 minutes and made another test call.  Hold was still unsuccessful. 

    After making these settings changes, is there anything I need to do to make sure they are active, such as restarting a service?

    Thanks!
    Jason

    Monday, November 18, 2013 2:58 PM
  • Refer following call flow for call hold

    http://www.in2eps.com/fo-sip/tk-fo-sip-service-01.html

     

    Take S4, Mediation Server logs from Mediation Server  use snooper tool to analyze the logs.

    Check if you are getting 200 Ok back (from Audiocodes GW/Sip Trunk Provider) for the INVITE sent out for hold.

    -Santosh

        

    Tuesday, December 24, 2013 1:52 AM
  • Hi Jason, your Mediant 1000 hass Firmware 6.40.037.009

    This Firmware has a lot off problems, also to hold a call sometimes. Please update to the latest firmware like 6.60.254.005 or at least 6.40A.068.003


    regards Holger Technical Specialist UC




    Wednesday, December 25, 2013 10:14 AM
  • I recently turned up EV at my company and have the exact same problem. Were you ever able to resolve the issue?

    I am using Lync 2013, Mediant 1000, HP 4120 Lync edition phone.

    Wednesday, December 3, 2014 2:35 PM
  • Yes, we did get our issue resolved. I looked back through my notes and found that I worked with AudioCodes, Microsoft, and Windstream (our SIP provider) on the issue. Nothing was changed on the AudioCodes side or Lync side, so I'm assuming our SIP provided made a change on their side (even though they claimed they didn't. Anyways, through troubleshooting with Microsoft and AudioCodes we found that Lync was sending out a SIP INVITE message with a=inactive which AudioCodes properly passed on to Windstream. The Windstream side responded with a 200 OK SIP Messages but the SDP we received back from them did not have a=inactive in it. 

    Once the issue was finally resolved, we confirmed that we were receiving the a=inactive in the 200 OK back from the provider.

    AudioCodes did tell me that if the SIP provider couldn't fix the issue, they could probably resolve it with the 6.6 firmware (we were only on 6.4 at the time).  Your best bet is to start with your SIP provider, however, if you are not seeing the a=inactive in the 200OK message back from them when you place the call on hold.

    Jason

    • Proposed as answer by Holger Bunkradt Saturday, December 13, 2014 11:26 PM
    Wednesday, December 3, 2014 2:56 PM