MoH issue without transcoder

[voiphub01]

Friends,

I am facing issue with MoH using G.729 codec. Following is the simple installation scenario;

Two sites are there viz HQ and B1.

MoH server (CUCM), Transcoder (2811), couple of phones are in HQ Region and few phones are in B1 Region.

Region between HQ and B1 is restricted to using 8Kbps (G.729).

If I make normal call between HQ and B1 phones, G.729 codec is invoked as per region settings. This means that both of these phones support G.729 codec.

Now if HQ user puts B1 user on Hold, MoH Server doesn't play MoH to B1 user in G.729 (play only beeps using SCCP signaling) untill and unless I don't use MRG in HQ device pool.

If B1 user puts HQ user on hold, the MoH plays perfectly as region settings within HQ is set to use 64Kbps (G.711).

My question is since MoH server is capable of playing MoH in G.711, G.729 and Wideband, then why it's not playing MoH in G.729 directly.

Would appreciate your suggestion.

Regards,

Vipul

[Aaron Harrison · Accepted solution]

Hi

If you go into the Service Parameters in CCMAdmin, find the IP Voice Media Streaming app and click Advanced to show all settings.

Check what codecs are enabled - you can shift-click multiple ones. G729 is off by default.

Regards

Aaron

[voiphub01]

Aaron,

It's worked like a charm. I selected all available codec's and now CM can play MoH in G.729 without invoking transcoder. Thank you very much. I was searching for this configuration under Service Parameters -> Call Manager.

One more point if you can draw my attention is which MoH node should play MoH and which settings force to change this behavior.

PUB - 192.168.15.10

SUB - 192.168.15.11

Now with above configuration, both MoH servers are registered with SUB although I have observed that always PUB plays MoH to endpoints. How to control and decide which node will play the MoH?

Regards,

Vipul

[j.huizinga]

You control media resources using media resource groups and lists

[voiphub01]

Thanks for reading the question and reply.

In the current configuration, MRL is set to None in Device Pool and no trancoder is invoked. So just wanted to discover with the above configuration (screenshot in my last comment), what forcing only PUB to play MoH...

Regards,

Vipul

[Brandon Pierce]

So in this case, if you arn't using MRGLs and MRGs and the device pool is set to none it will pick the first resource it sees that is available in the "Null" or "None" list which in this case, is the pub.  You could create different Media resource groups and lists then apply them to device pools that pertain to certain sites, guaranteeing they use the resources for their location only.

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/8x/uc8x/media.html#wp1244627

[voiphub01]

Brandon/j.huizinga,

Cheers (+5). Default when no MRG was being used, it was using PUB and with proper MRG, I can use SUB now to play MoH. Perfect.

What I'm asking now is not exactly related to from where I have started this thread but I'm purposefully asking it here. Now I have observed that with proper MRG, SUB can stream MoH to terminal but it's blank. I can see RTP packet flowing from SUB to terminal but blank packets.

I then check SUB database through CM administration and found that the new file I uploaded from PUB is not available in SUB. This is definitely DB replication issue.

I checked then DB replication status which is good as shown below;

However I can also see one error on the same page;

What do you think the reason of this and should I perform complete DB replication.

Thanks for your time mates.

Regards,

Vipul

[Brandon Pierce]

Files uploaded to the Publisher will not replicate to the sub, this is working as designed.  Only static data and user facing data replicate.  This is the same as uploading firmware to just a Pub and expecting the Sub to get that firmware or device pack as well, it will not and must be uploaded at each node.

Supported Music On Hold Features

Music on hold supports the following features, which are listed by category. Feature categories include music on hold server characteristics, server scalability, server manageability, server redundancy, database scalability, and manageability.

Music On Hold Server Characteristics

• Servers stream music on hold from music on hold data source files that are stored on their disks.
• Servers may stream music on hold from an external audio source (for example, looping tape recorder, radio, or CD).
• Music on hold servers can use a single music on hold data source for all source streams and, hence, all connected streams. When multiple music on hold servers are involved, the local server of each music on hold server always stores the music on hold data source files. Cisco Unified Communications Manager does not support distribution of fixed-device (hardware) audio sources across music on hold servers within a media resource group.
• Music on hold data source files have a common filename across all music on hold servers.
• You must ensure that music on hold data source files are uploaded to each MoH server.
• Each audio source receives a feed from either a designated file or a designated fixed source (for example, radio or CD).
• A designated fixed source comprises a single device, which is either enabled or disabled.
• The audio driver on the local machine makes a single fixed source available to the music on hold server.
• Music on hold servers support the G.711 (a-law and mu-law), G.729a, and wideband codecs.
• Music on hold servers register with one primary Cisco Unified Communications Manager node.

[voiphub01]

Brandon,

Cheers (+5). Thanks to draw my attention on the subject. I will update the MoH file manually to SUB.

If you don't mind, I would like to ask other question with respect to your last post.

<<Music on hold servers register with one primary Cisco Unified Communications Manager node>>

What exactly this statement meant to say? If you see the screenshot I posted before, I have two nodes PUB and SUB. For both MoH servers, SUB is the primary server that I can control through device pool -> CM group.

I also have choice to register one MoH server to PUB and other to SUB. How exactly it's matter which MoH server is registered to which node as we can always use MRG to select the node responsible for playing MoH.

Have I been able to explain my doubt?

Regards,

Vipul

[Brandon Pierce]

I think you might be reading to much into that statement.  It just means that each CUCM server that has a MoH server can only register to the server in which it is on unless you otherwise specify.  Basically, you can't subscribe it twice to two different servers at the same time. I hope that makes sense.  If you go into the MoH server you can see the host option.  Usually it's greyed out from my experience as only one server (usually the pub) is managing the MoH servers.

[voiphub01]

Brandon/Nishant,

Untill now, it was not looking so simple to understand but as per your comments and I had a look at SRND too, what you are saying makes my understanding clear about distribution and usage of multiple MoH servers in a cluster.

Cheers (+5)

Regards

[Nishant Savalia]

Hi Vipul,

<<Music on hold servers register with one primary Cisco Unified Communications Managernode>> 

The above statement simply means that "MOH server will only register with the Primary node in the group (2nd node as a backup) that you have applied while configuring MOH server, similar to your phone or any end points registers with CUCM depending on your primary node in group".

<<How exactly it's matter which MoH server is registered to which node as we can always use MRG to select the node responsible for playing MoH>>

That's true, which node is responsible for playing MOH can be done by MRG but it matters in terms of messages or signalling that will be exchanged between the registered node and node responsible for playing MOH (similar to your phone registered with node originating the call and gateway registered with node is different).

Hope that it is little bit cleared now.

Thanks,

Nishant