I have always been under the impression that when enabling Multicast MOH from the CUCM and enabling the 'increment by port' that it starts at whatever port number you enter and then creates 4 new ports for every source that are based on the audio source number as an index.
So, for example if you are on source (1) and you started at port 16384 (the default) that the 4 streams would be at 16384, 16386, 16388, and 16990. And based on that the mathmatical formula for calculating the first port (g711ulaw port) in the sequence would be...
x+((y-1)*8), where x is the starting port number and y is the audio source number index.
So, in in the previous example that would be 16384+((1-1)*8) or 16384.
for audio source 5 it would be 16384+((5-1)*8) or 16416.
I am working on a 6.1.2 deployment where it seems like this is not true. It seems like rather than using the audio source number as the index it is incrementing these based on order of entry. So if audio source number 5 was created immediately after source 1 then it takes over the next 4 ports or 16392, 16394, 16396, and 16398. Then, if you create source 2 later it falls numerically behind source 5 in the ports used. This behavior, if true, makes it hard to predict where the Multicast ports are used. The reason this is important to me is that I am using the MMOH on flash procedure to source MMOH locally at remote sites from flash rather than across a non-multicast emabled WAN. You can only enable one port per site, and if you're wrong you get MOH silence.
thanks for your help,
Has anyone observed this or can help me explain/fix?
Re: MOH audio source, port numbers and multicasting
184.108.40.206. The Internet Assigned Numbers Authority (IANA), however, assigns addresses in the range 220.127.116.11 to 18.104.22.168 for public multicast applications. Cisco strongly discourages using public multicast addresses for music on hold. Instead, Cisco recommends that you configure multicast MoH audio sources to use IP addresses in the range 22.214.171.124 to 126.96.36.199, which is reserved for administratively controlled applications on private networks.
Furthermore, you should configure multicast audio sources to increment on the IP address and not the port number, for the following reasons:
â¢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.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...