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.
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.
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.
You have reached the Cisco Logistics Support Center.. To Check Status of
your RMA, visit Product Returns & Replacements (RMA). Need help? Contact
us by Phone or Email. North Americas Phone: 1800 553 2447 Option 4
Email: email@example.com Europe Phone: +3...
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...