no moh via firewalled intercluster trunk

[jsmckinlay]

Hi,

We have two networks each with CUCM (8.5 & 7) clusters that are connected together via a non-gatekeeper controlled intercluster trunk. A single firewall (asa 5550) sits between the two networks.

We use H323 inspection on the firewall and define the CUCM servers in each cluster so once call setup happens the rtp ports between the phones are setup automatically. All subnets and servers are routable on both networks and there is no NAT taking place.

Everything works great and we can make calls, hold / transfer / transcode and make calls fine in all scenrios. The only issue we have is that you do not get Music on Hold when the call is placed on hold, this happens in both directions. All phones and trunks have MOH sources as part of the MRGL's.

When logging on the firewall you see denys take place (the source being the call manager of the cluster that put the call on hold) of the RTP streams that should be the music. This causes the silence the other end.

Should the firewall inspection not pick this up and allocate the ports for the MOH stream to go through? we also have Skinny inspection on

Any thought's or comments would be most appreciated.

[Dennis Mink]

This is interesting (see below), it discusses similar issues with Telepresence and MOH. It looks like what cisco is saying that it potentially will not work.

In all the tests with SIP application layer protocol level inspection enabled, only one minor issue was observed. If a TelePresence call is initiated by the CTS endpoint on the opposite side of the firewall from the CUCM, and the call is subsequently put on hold by the CTS endpoint on the same side of the firewall as the CUCM, the SIP signaling between the CUCM and the CTS endpoint on the opposite side of the firewall does not allow the firewall to correctly set up the necessary RTP pinhole connections to allow music-on-hold (MOH) between the CUCM server and the CTS endpoint. Firewall syslog output indicated RTP traffic from the CUCM destined for UDP port 16384 of the CTS endpoint was blocked. No music-on-hold was heard on the CTS endpoint. This is considered to be a minor issue and was only observed because an ingress ACL on the interface with the higher security level was used to determine specific ports required for TelePresence deployments through the firewall. The default behavior of a firewall which allows all flows from an interface with a higher security level to an interface with a lower security level would normally allow this to work correctly.

The test with unequal security levels on the interfaces, one-sided NAT, and SIP application level protocol inspection disabled failed during the CTS endpoint reload test and is therefore not a recommended configuration to support TelePresence.

source:http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/tpfirewall.html

[sean_evershed · Accepted solution]

Hi,

Have you seen this ASA Configuration Guide for Call Manager?

http://docwiki.cisco.com/wiki/Cisco_ASA_Firewall_Configuration_for_Data_Center#Media_sources_in_data_center

A Multicast MOH ACL has been configured specifically for UDP ports 16384 to 32767.

[jsmckinlay]

This seems to be exacty the problem we are having, althought our setup is H323 not SIP, I'm guessing it should work so I guess we may have to raise a TAC case. I've not found any documentation to state what features are or are not supported on the H323 inspection so it's had to know if it's a bug or by design.