Reminds me how surprised I was when I found out that many IP phone installations use multi-cast strictly to distribute on-hold music to all phones, instead of the phones pulling files from a server or storing it locally.
1. Multicast is 1:N so one stream can be played on all phones. Pulling the files from a server would be N:N so your network bandwidth would be consumed unnecessarily due to all the phones streaming the same data. Also, the phones are going to have limited memory so storing music locally is not going to scale well (phone memory is a cost that gets multiplied by N phones).
2. Synchronization, especially for the elevator scenario: if the music outside the elevator door isn't synchronized to the music inside the elevator, it will be rather disconcerting.
BTW, I suspect the streaming audio you saw was "background music" that could be played from the phones speakers. "Ambiance audio" would tie in with #2 synchronization; having adjacent phones playing unsynchronized "ambiance audio" would also be jarring.
Music on hold will be inserted by the PBX (head end), not the individual phones. Inserting "music on hold" by the phone would mean that music would be sent by the PBX to the phone back to the PBX and then to the "on hold" line where having the PBX insert it involves only the link from the PBX to the "on hold" line.
Yeah, it's efficient and easy to update. Was just surprised since applications for multicast crossing subnet borders are fairly scarce, so I guess multicast routing got configured just for that, and is one of these things you don't see mentioned very often. Thanks for the details!
Not hold music - I don't know of a single PBX (IP or otherwise) where hold is accomplished in the phone - but many phone systems can do background music and paging, this would be a great use for multicast.
