Call Hold Fails with CUBE 2800 with OCS 07 r2

a.morpeth · ‎09-14-2010

Hey,

We 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 as everything works perfectly through the Dialogic Gateway.

1. Has anyone seen this issue and is there 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 go this explianation from Dialogic on how this should work -

"To recap....When OCS places the call on hold, it will send a re-invite to the DMG with a=inactive, DMG will respond to the hold request with 200OK and no longer send audio it is receiving on the TDM side to the IP side (OCS client). It will send CN packets (silence). Additionally, OCS will no longer send RTP Audio to the DMG (it will send CN packets). To take the call off hold, OCS will send DMG a re-invite without a=inactive (and its media port contents) and then DMG will respond to that with 200OK and starts sending media to the IP endpoint that it receives from the TDM side."

Does the CUBE support the hold feature? Is there a setting I am missing?

Thanks!!!!

Andrew

Felipe Garrido · ‎09-21-2010

Can you provide the following information from the CUBE.

show version

show run

Also, can you collect the following debugs for a call placed on hold.

debug ccsip message

debug voip ccapi inout

Please note the calling and called party numbers.

-Felipe

Tommer Catlin · ‎09-21-2010

When a call is placed on hold, normally an MTP resource is required to have the audio terminate someplace on the network. The client is not sending or receiving any audio during the hold. Same with a transfer. An MTP source needs somewhere to temp park that call on the network to keep it alive.

Im not sure of your exact routing, but do you have CUBE---CUCM--MED servevr or are you going directly to/from the CUBE?

Also, how is your network card configured on the Mediation server? The RTP packets to/from Mediation and gateways is tricky. Typcially, I will set everything to one NIC card and test OCS voice features/funcations. The Pool and gateway share the same IP address on the same NIC card. if it works, then I can split it up two different cards.

Another item to check is your dial peers on the CUBE. Can you post a copy of how the dial peers are setup?

Steven Holl · ‎09-22-2010

When a call is placed on hold, normally an MTP resource is required to have the audio terminate someplace on the network.

You don't need an MTP in SIP-to-SIP CUBE environments. Supplementary services such as hold/transfer will still work. The call doens't need to be 'parked' on an MTP.

If you configure early offer forced and mid-call singaling passthru on CUBE, it should be able to handle midcall supplmentary services just fine.

Now, in an H323 to SIP CUBE, you often need MTP, but that's mostly because MTP is required to get FS out of CM for an outbound call, so that we can get EO out to the provider on the SIP leg.

We used to need MTP back a long time ago on H323 TDM gateways for supp services, but that restriction was removed a long time ago with the ability to support an ECS.

Really, (although there are probably minor exceptions) the only time you need an MTP these days should be for:

* Fast start out an H323 trunk

* On a SIP call with RTP-NTE if the downstream endpoint doesn't support RT-NTE. Most IP phones do support RTP-NTE and won't cause this to be invoked.

So get the information Felipe requested and we can see what is happening here.

a.morpeth · ‎09-22-2010

Thanks everyone for your great replies! I will go the info you require and post back.

Thanks,

Andrew