Stream Multicast MOH from gateway notes

Cisco CUCM deployments can provide MoH / music on hold to callers that is streamed from the CUCM server(s) themselves.  If the devices you are putting on hold are far from the CUCM servers though and you don't want the music streams to cross lower bandwidth WAN links, one option you have is to stream the MoH from a voice gateway that is local to the devices on hold.

There are quite a few dependencies to make this work though. Below is a summary of the things I addressed today making it work at a new site.

In your CUCM, you need to enable multicast capabilities on the MoH source, the MoH server, and a Media Resource Group (MRG).

Audio Source with multi-cast enabled

MOH Server with multi-cast enabled

 

MRG with Multi-cast enabled

Note: You should configure multicast audio sources to increment on the IP address and not the port number (see server configuration above) because:

• IP phones placed on hold join multicast IP addresses, not port numbers
• Cisco IP phones have no concept of multicast port numbers. Therefore, if all the configured codecs for a particular audio stream transmit to the same multicast IP address (even on different port numbers), all streams will be sent to the IP phone even though only one stream is needed. This has the potential of saturating the network with unnecessary traffic because the IP phone is capable of receiving only a single MoH stream.
• IP network routers route multicast based on IP addresses, not port numbers 
• Routers have no concept of multicast port numbers. Thus, when it encounters multiple streams sent to the same multicast group address (even on different port numbers), the router forwards all streams of the multicast group. Because only one stream is needed, network bandwidth is over-utilized and network congestion can eventually result.

You then need to create and / or assign a MRGL to the trunk, device pool or other that includes the MRG configured above.

MRGL used by remote devices that includes multi-cast MRG from above

Note: You do NOT need to support multicast traffic generically across the network or across the WAN.  Because the phones and voice gateway used for streaming the MoH file were on the same subnet at the remote site, I only enabled support for multicast routing on the voice gateway itself.  The switch where the phones and voice gateway were connected at the remote site did not even have multicast routing enabled.

Now verify what multi-cast IP address your music will utilize.  It is not necessarily the IP address set in the MOH server you see above or even related to the number of the audio source in use. Rather it depends on what codec is being used and in what order the audio sources were added to your server.

Here's a great discussion on the topic: https://supportforums.cisco.com/document/68401/procedure-allocate-ip-address-and-port-srst-multicast-moh

On the MOH server where "Enable Multicast Audio Sources" is enabled, here's how I found the address I needed.

admin:
admin:run sql select m.mohaudiosourceid,m.multicastaddress,m.multicastport,c.name from mohservermulticastinfo as m,typemohcodec as c where m.tkmohcodec = c.enum
mohaudiosourceid multicastaddress multicastport name
================ ================ ============= ========
1                239.1.1.11       16384         711 ulaw
51               239.1.1.14       16384         711 ulaw
2                239.1.1.19       16384         711 ulaw
1                239.1.1.13       16384         729
51               239.1.1.16       16384         729
2                239.1.1.21       16384         729
1                239.1.1.18       16384         wideband
51               239.1.1.17       16384         wideband
2                239.1.1.22       16384         wideband
1                239.1.1.12       16384         711 alaw
51               239.1.1.15       16384         711 alaw
2                239.1.1.20       16384         711 alaw
admin:
admin:

Note, if here I want to use audio source 2 and the G.711 ulaw codec, I should then use multicast address 239.1.1.19 in my gateway config.

My gateway configuration then includes the following critical components:
!
ip multicast-routing distributed
!
call-manager-fallback
ip source-address 10.18.140.40 port 2000
moh enable-g711 "flash:/SampleAudioSource.ulaw.wav"
multicast moh 239.1.1.19 port 16384

Here my gateway's LAN IP address is 10.18.140.40 and I have chosen to stream Cisco's sample music from flash on the gateway.  If you are interested, here's my tips on how to download music from Cisco's music on hold servers to use elsewhere:
http://webmaxtor.blogspot.com/2012/09/cucm-download-moh-file-from-server-in.html  It's the technique I used get the sample music file off the server and on the gateway.

If all goes as planned, when a caller is put on hold you can see evidence of it being streamed from the gateway via the "show ccm-manager music-on-hold" command.
!
! with no calls on hold
! 
my-router#
my-router#show ccm-manager music-on-hold
Current active multicast sessions : 0
my-router#
!
! with one call on hold
!
my-router#
my-router#show ccm-manager music-on-hold
Current active multicast sessions : 1
 Multicast       RTP port   Packets       Call   Codec    Incoming
 Address         number     in/out        id              Interface
===================================================================
239.1.1.19        16384   0/0              25939 g711ulaw            
my-router#

UCCX 11 Notes

11.5(1)SU1 essentially forces you to stop using Internet Explorer Compatibility View.  Read the release notes and make sure you aren't forcing intranet sites to be view in compatibility mode via Microsoft GPO before the upgrade.

Seeing a FATAL message when rebooting may be recoverable.  A bug CSCvb21486 Reboot of node may result in FATAL error was hit after deploying UCCX 11.5(1) with ES01 but Cisco has it associated with CUCM.  It appears to be related to the automatic VMware tools installation gone wrong.  You'll need to grab a recovery disk and bravery as my damaged file seemed to be on the wrong partition.  It looks like this:

Back up your custom Finesse desktop XML seperate from your DRS backups.  Document or take visual snapshots of your team resources.  Bug CSCvc94563 UCCX: Finesse Team Resource Configuration Lost (there seem to be multiple bugs along this line) will disassociate your team related configurations from your teams and make your custom Finesse desktop XML disappear.

If you are using Prime Collaboration Deployment to execute upgrades, note bug CSCuu34496 L2 upgrade status shows as running instead of complete from OS adminpage.  Your standard L2 upgrade may finish without issue but never report so.  You can see in the install_log upgrade_install.sh|release_upgrade_lock: Releasing lock (pid: 15496)| and in the upgrade_monitor log upgrade finished.  Prime is not intelligent enough to figure this out and your tasks will stall indefinitely.  You should check in on the process soem time after your time completion estimate.

Calling Search Space for Redirect on your triggers by default is set to Default.  This means that UCCX will route calls through the application and script called by the trigger with the caller's CSS, not the trigger's CSS.  If your caller is not capable of reaching the agents or other destinations defined in the application and script directly your call will be rejected.  This is typically not an issue but where you might have PLARs set up with very restricted CSSs, sending the PLAR to a UCCX trigger may fail.  This can be modified per trigger on at least UCCX 8.5 and beyond.  See bug CSCso91760 at  https://bst.cloudapps.cisco.com/bugsearch/bug/ 20CSCso91760 for more redirect information.  See http://webmaxtor.blogspot.com/2011/05/cucm-ring-down-phone.html regarding basic SCCP PLAR setup.

The official Cisco install guide indicates the server hostname is case sensitive and must be lower case.  I suspect this is to alleviate issues with installing signed certificates later with all lower case SANs.

When modifying "Finesse Layout XML" it appears restarting TomCat or Finesse services is no longer required.  Users seem to have to log out and back in to see changes though.

If you are deploying UCCX 11.0 you should plan to hit bug CSCux33949.  Your default Finesse gadgets will all be broken.  At this time the fix requires TAC gaining root access, providing some new JAR files and restarting the UCCX Engine.  Budget time to have this fixed early in your implementation plan.

RTMT cannot be used to show telephony data on versions 11 or 11.5 per bug CSCuy72411.  We won't be able to use it to check triggers, call control groups and CTI ports until who knows when.

UCCX Editor is not compatible with Windows 8 or 8.1.

The Team Performance gadget served by /desktop/gadgets/TeamPerformance.jsp is not resizable in version 11.0.  The rumor is it will be in 11.5.

As of version 10.0, UCCX Finesse supervisor and agent desktop still shows all queues and all logged in agents.  See http://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/118823-technote-uccx-00.html for guidelines regarding modifications.

You can test and / or verify Finesse IPPA with URLs:
http://yourUCCXserver:8082/fippa/SEPphoneMAC
http://yourUCCXserver:8082/fippa/SEPphoneMAC/login?password=UserPassword&extension=UserDN&id=UserID