Can some please explain how OCS deals with a call hold request? RRS feed

  • Question

  • Hey,

    I have a CISCO CUBE and a Dialogic Gateway both connected to 2 different mediation servers.

    PSTN Calls through Dialogic can be placed on hold.

    PSTN calls through CUBE fail with error message "Call cannot be placed on hold.  Your speaker and microphone have been muted."

    I am of the opinion that the CUBE is at fault probably becasue it doesnt follow the OCS standards correctly. Our telco is telling us that its an OCS limitation and there is nothing they can do about it.

    1. Does anyone have a fix?

    2. Can someone please explain the background goings on when a call is placed on hold. Is it OCS putting the call on hold or the gateway? Does the gateway need to respond somehow to a hold request by OCS? I need so technical info here so I can go back to the telco and explain why it is not OCS.




    Tuesday, September 14, 2010 3:36 AM

All replies


    I can give you details.

    Mediation server uses 'standard' SIP messages to setup, control & end calls.  There can be minor variations between companies & PBX's in the definition of 'standard' - hence you find most things work, but some things don't - hence your problem.

    Anyway - during a phone conversation there is a two way RTP media steam between the end points.  This is the conversation.  This will continue UNLESS a further instruction is sent from EITHER party.

    Mediation server (or the other end) sends out a SIP 'Invite' message containing the SDP command

    This places the call on-hold (or should do).

    The call will remain on-hold until either party sends a SIP '200-OK' message containing the SDP command

    This will take the call off-hold, (or should do).



    Paul Adams

    Tuesday, September 14, 2010 3:41 PM
  • Thanks very much for that explanation. So I now understand that both devices are involved in a hold request. So when this is successful it is OCS that is placing the call on hold but it is also infoming the gateway of this so the line is kept active?

    Our telco has put in a Cisco CUBE to deliver SIP Trunks and they tell us that somehow the hold request is reaching thier Broadsoft switch where it fails. This broadsoft switch is all they way back at the Telco's premises, and I would have thought that the hold request would stop at the CUBE Gateway. Why would the Telco need to receive the hold request! I feel like they dont know what they are talking about! I am trying to get them to look at the CUBE more closely, however they have made this outright statement and don't want to spend anymore time on it.

    Any thoughts?




    Tuesday, September 14, 2010 9:36 PM
  • Thoughts...

    In a SIP phone call, there are two end points but there might be 2,3,4,5, etc servers or PBX's in-between.  All the servers / PBX's in the call flow need SIP instructions to establish, control and end the call.

    If you have SIP trunks to a Telco, then yes, the Telco receives SIP messages, which includes the on-hold 'triggers', because your Telco is the last SIP point before your calls are converted from SIP to be connected to the PSTN.


    Without trying to be a smart a**, if the Telco put in the Cisco cube and the problem is with thier switch back at thier location - is this not 100% thier problem to deal with?  This can be the issue with VoIP solutions.  It all 'seems' to work on paper but there an be issues in the real world.


    Continuing the thoughts thing...

    Is this a demo or test bed?

    Why do you not connect the Mediation server directly to your Telco SIP trunks?  MS don't shout about it, but Mediation server 'talks' to other PBX's using standard SIP commands.  I've tried a few, it actually works pretty good.  You might be able to go direct.  One company already offers 100% compatable OCS trunks.

    I see you have 2 mediation servers.  Did you know the new OCS 2010 (linc?) connects to multiple PBX's or SIP servsr - you do not need multiple Mediation servers - AND the mediation server is on the same server as the Front end server (if you have a small installation).  I believe if you purchased OCS 2007 R2 recently, MS will give you a free upgrade to 2010 when is reaches RTM (need to double check that, but I'm sure I read that somewhere).


    Does the babbling help?  :-)


    Paul Adams

    Tuesday, September 14, 2010 11:25 PM
  • Hey Paul,

    Haha yes the babbling is perfect. Thanks again for a great explanation. So sounds like it is a limitation with their service which they have already acknowledged. My understanding was incorrect in thinking that the SIP messages should NOT reach the Telco's switch.

    We are using this is a test bed at this stage but want to move our PABX number block over to the SIP trunks. The hold issue is slowing us down. Currently our provider doesn't support direct connect to mediation server. They say that MS only supports TCP while they support UDP. The Cisco CUBE is doing the conversion for us.

    We are really looking forward to OCS 2010. We are a small company and will appreciate the consolidation it will bring. Hoping it is released soon!! Have your heard any hints to its release date?


    Tuesday, September 14, 2010 11:37 PM
  • Arhhh - the old UDP / TCP issue.   I use Asterisk as my gateway out from OCS.

    OCS 2010 or Lync to use it's correct name - was released for public trial yesterday.

    Trial for 180 days.  Download Windows 2008 Server R2 if needed as well.


    May I suggest if this is a learning experience for you anyway - grab the 2010 version and learn that.

    I don't know any details on it being released for manufactouring, but if it's gone to public trials I would imagine it is very close to being released as a final product.


    Paul Adams

    Wednesday, September 15, 2010 3:55 AM
  • Thanks again Paul!

    Been holding my breath for 2010 RC or RTM for a while now. We plan to move as soon as it is in RTM. I did here 2010 supports UDP transport which is a good thing. Plus the consolidation will do us nicely. I really do hope that the telephony options/config are now in one central place! Its so frustrating changing between running command lines, MMC snap in's and web based config tools!! Makes me want to pull my hair out!


    Wednesday, September 15, 2010 4:19 AM
  • although this may seem like a biased opinion (considering i work for the company), NET can actually aggregate both the PSTN and the SIP TRUNKs from your Telco, and provide you with a single element to:

    1. Provide you with a single certified device, as opposed to running 2 different devices (one certified, and the other not); where the single device is capable of handling PSTN to SIP, and SIP to SIP traffic (including UDP to TCP translations)

    2. allow you to get the right experience out of your OCS Enterprise Voice environment, seeing we are certified for OCS Voice. i.e. resolve your onhold issue, for starters.

    3. provide you with the ability to automatically re-route calls over the PSTN trunks if/when the SIP trunks may be OOS. i.e. fallback routing to PSTN.

    Again, dont mean to be giving off the perception i am simply promoting our products. Just providing some food for thought.

    Hope it helps.


    Wednesday, September 15, 2010 7:02 AM
  • Please deploy Cisco IOS 15.1(2)T or newer on your CUBE voice gateway.  You will need to use the new IP address trusted list feature in CUBE on 15.1(2)T to help prevent toll fraud- alternately you can do: voice service voip, no ip address trusted list.

    Ensure you have the following two commands on your dial-peer facing OCS Mediation server:

    dial-peer voice 20 voip
     voice-class sip early-offer forced
     voice-class sip block 183 sdp present

    Here is a sample dial-peer:

    dial-peer voice 20 voip
     description Inbound Dialing - 5591234567
     translation-profile outgoing addplus
     destination-pattern 5591234567
     session protocol sipv2
     session target ipv4:
     session transport tcp
     voice-class sip early-offer forced
     voice-class sip block 183 sdp present
     dtmf-relay rtp-nte
     codec g711ulaw
     ip qos dscp cs3 signaling
     no vad

    • Proposed as answer by Paul Madden Wednesday, March 9, 2011 3:24 AM
    Monday, October 4, 2010 7:58 PM
  • Andrew

    Have you resolved your HOLD issue? we are using LYNC 2010 and moved from Asterisk to an EPYGI Quadro which is used only to as a TCP to UDP gateway. In Australia we are yet to find a provider that is OCS ready.


    But if you have found a solution could you please share that, and was it dealt with at OCS level.?



    Monday, January 24, 2011 3:18 PM
  • Hey Oussama,

    Tell me about it! We have the same problem here in New Zealand. We currently use Telstra but still have the hold issue. This is something that they cannot fix until they upgrade their switch which will hopefully happen in the next few months. It it my understanding that Telstra Australia has just had this upgrade so it may be worth talking to them.

    Microsoft is also in the process of certifying vendors here so I am sure the same thing will be happening in OZ. Microsoft maybe able to help you further.

    I have also tested SIP trunks provided by smaller companies which have worked well, however they are delivered over broadband and occasionally we would get slow call setup and quality issues. In the end we deiced to stick with Telstra as call quality is perfect and the service very reliable. Our staff have learnt to live with the hold issue for now. It really only affects reception who cant announce calls or handle more than one call at a time. Also the attendant console cant be used due to the way it deals with calls.

    Hope this helps. Let me know if I can help you further.




    Monday, January 24, 2011 8:12 PM
  • For what it's worth...if someone was smart enough, there might be a solution...

    A long time ago, (galaxy far, far away, etc...) -  to get Asterisk to talk to OCS, OpenSER was used.  Initally, there was problems that on-hold wouldn't work.  That was fixed.  In the thread below is details on how this was done, including a full OpenSER config file.  I used this solution & it did work.


    It maybe possiple to put an OpenSER server between LYNC and your provider.  Customise the OpenSER config (OpenSER has been renamed but I cannot remember the new name), to intercept whatever the provider is sending as the 'on-hold' & send the correct LYNC on-hold message which is detailed in my first post at the beginning of this thread.

    This is beyond my ability, but there are some skilled people out there who do some impressive things with OpenSER


    Paul Adams


    Monday, January 24, 2011 10:54 PM
  • Thanks Guys,

    It is somewhat frustating, we used an EPYGI Quatro which did an excellent job except for the HOLD issue, on the other hand when we move back to the Asterisk we get delay issues and the best way to describe this is as follows:

    When making an external call from an extension, unless you keep making a noise  (scratch the mouth peice), you do not hear of the status of the call or when the party has answered. It feels as if the call is muted from the other side untill some noise like breathing or blowing on the phone to keep it alive sort of.

    Sorry I know of no other way to technicalyexplain this.

    Any Ideas??




    Tuesday, January 25, 2011 3:16 AM
  • Can the other end hear you?  Sounds like a one way audio issue, which in my dealings with Asterisk means you need to add the lines


    to the definition of your Mediation server in your asterisk sip.conf file



    PauL Adams

    Tuesday, January 25, 2011 4:59 AM