[cisco-voip] CUCM - MOH Silence

Daniel Pagan dpagan at fidelus.com
Fri May 15 13:16:05 EDT 2015


Also… IPVMSapp traces might help if the issue is related to the MOH server’s inability to allocate the proper audio source file from the local filesystem. Not common in my experience but can happen. If set to detailed, you should see the StartMediaTransmission and StartMediaTransmissionACK being logged in the trace in addition to its ability or inability to allocate and play the selected MOH audio source file.

For example:

CMOHMgr::PlayStream PlayStream: asID=1,codec=0,file=/usr/local/cm/moh/ringback.ulaw.wav,userBuffer=4000,repeat=1

CMohPlayWav::Play (9,2,0) Play () I(0) (/usr/local/cm/moh/ringback.ulaw.wav)

Of course CUCM won’t get to this point if the issue resides at the signaling protocol and media setup aspect of the call. Regardless, hope this helps.

- Dan

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Daniel Pagan
Sent: Friday, May 15, 2015 12:50 PM
To: Anthony Holloway
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] CUCM - MOH Silence

Do you see a StartMediaTransmission being sent to your MOH server? Look for MohDControl for SCCP signals to the MOH server - one process instance is created per MOH server. But first, before sending the StartMediaTransmission signal to MohDControl, CCM will first attempt to get media information from the remote end, and I would first take a look at this call-leg and (at a high level) make sure the OLC/OLCack is exchanged with no issues. What signaling protocol is being used on the opposite call-leg? If that exchange fails then you won’t see a StartMediaTransmission to MohDControl. If you do see a StartMediaTransmission to MohDControl then is it ACK’ing that signal?

Just some quick thoughts. If you want, and if you can, feel free to forward a collection of SDI/SDL traces from all nodes covering this failure. I’ll take a few minutes to see what I can find.

Hope this helps.

- Dan

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Anthony Holloway
Sent: Friday, May 15, 2015 9:57 AM
To: Ryan Huff; Roger Wiklund
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] CUCM - MOH Silence

Thanks Ryan.  The region relationships is fine as the MOH is in a special MOH region which is 64kbps to every other region, including the one in question.  All traces indicate that the media caps are a match at g711ulaw.
On Thu, May 14, 2015 at 6:45 PM Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:
Another common source of this is codec mismatch.

So if your ingress region isn't related to the region that MoH is in with the G.711/G.722 bandwidth profile, you'll get this issue. If you get tone-on-hold then it is usally partition/css/tftp related but dead silence is usually codec related.

Thanks,

-r




________________________________
Date: Thu, 14 May 2015 23:13:40 +0200
From: roger.wiklund at gmail.com<mailto:roger.wiklund at gmail.com>
To: avholloway+cisco-voip at gmail.com<mailto:avholloway%2Bcisco-voip at gmail.com>
Subject: Re: [cisco-voip] CUCM - MOH Silence
CC: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>

Not sure about the trace but I would start with basic config check/troubleshooting.

Are you running unicast or multicast MOH?
Is the IP Voice Media Streaming App running on all nodes? (If yes try restarting the service)
Is the MOH resource in the MRG/MRGL?
Are all devices using that MRGL?
Is MOH selected for your codec? (System, Service Parameters, <server>, IP Voice Media Streaming App)
Have you uploaded a new MOH file? If so try with the default.

I would start there, or try basic ip-phone to ip-phone calls, exclude voice gateways etc and work my way forward.

On Thu, May 14, 2015 at 10:50 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:
All,

So, I'm a bit rusty this year on trace analysis and I need a second opinion.

From the below screenshot snippets out of TranslatorX, it would appear as though the MOH_3 gets selected, then an AuConnectRequest gets issued, and not but a few seconds later, I see an AuDisconnectRequest.  The caller experience is simply silence on the line while the call is connected (or not connected) to MOH.

If there was another key piece of information I could look for to help myself understand why it disconnected so quickly, what should I look for?  Thanks.

[Inline image 1]

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip


_______________________________________________ cisco-voip mailing list cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150515/95941a14/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 73223 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150515/95941a14/attachment.png>


More information about the cisco-voip mailing list