How to multicast audio to 50+ ip phones?

Version 1
    This document was generated from CDN thread

    Created by: James Scott Jr on 07-06-2010 07:13:24 PM
    I have a scenario where based on the application event, we will need to send an audio stream to one or X number of ip phones at once. What technology should I use to explore this capability?(JTAPI, AXL, ??)  I have read threads which discuss sending an CiscoIPPhoneExecute to the phone to have them open or close their multicast channel.  But I'm thinking there might be a more static way of achieving the multicast connect/disconnect for the phones. 
    Also, can I originate the audio stream from my server, or do I need to send a WAV file to Call Manager and have it broadcast it?

    Subject: RE: How to multicast audio to 50+ ip phones?
    Replied by: David Staudt on 07-06-2010 08:31:42 PM
    There are two audio paths you can use: audio via a regular call, or via the XML services API interface.  Most 'broadcast' type apps use the latter, as it doesn't require messing with CTI APIs, normally doesn't conflict with existing/ongoing phone activities and can use IP multicast.
    The core is sending a CiscoIPPhoneExecute request to the phone specifying an 'RTPMRx:' URI indicating the IP multicast channel to start listening to.  You can do this via CTI (TAPI/JTAPI) - e.g. using CiscoTerminal.sendData() - or by HTTP POSTing it to the phone's small onboard web server.  Once the phone successfully receives the command it will open that indicated IP/port for multicast listening - your app will need to transmit the IP multicast audio onto the network (note also the network must be configured for multicast - typically a somewhat challenging endeavor).
    Note, in order to HTTP POST to the phones, your app will need to know the phone IP addresses.  The Serviceabilit/Risport SOAP API may be helpful there.

    Subject: RE: How to multicast audio to 50+ ip phones?
    Replied by: James Scott Jr on 08-06-2010 02:23:55 PM
    Thanks for the response.  I'm familiar with CiscoTerminal.sendData(), CiscoIPPhoneExecute, JTAPI, and the XML Services APIs.  The notion of addressing each phone to start them listening on a multicast channel via  'RTPMRx:'; this is the thing I'm hoping to avoid.  Telling each phone to start then stop listening, works of course, but has some latency from the start of audio stream, to the last phone in the list being told to start listening.  But I'm hearing you, this is just how it's done.  
    I had thought of a scenario that would use available TFTP servers to hold the audio file, and tell the phones to PLAY: tftp://audiofile.  This would avoid latency issues, but at a cost of higher bandwidth.  Has such a thing been tried, or does it seem reasonable for small groups?
    Starting the stream; I think you indicated that XML Services could facilitate the origination of a stream.  If I understood you correctly, I can go find the methods to make that happen;  otherwise, I will need to create a typical audio source.
    Multicast Networking Issues:  I now this is not simple issue.  The implementation on 100% Cisco gear will be new for us.  Is there a Cisco reference you can point me to understand how multicast is done on Cisco?  I need to understand the scope of the effort, so I can advise others.  The importance of multicast for reducing network load is going to be critical for larger networks.

    Subject: RE: How to multicast audio to 50+ ip phones?
    Replied by: James Scott Jr on 08-06-2010 05:19:03 PM
    Ok, so re-reading your response I see that my app must originate the audio stream.  I now have all the answers I need, except for the Cisco Multicast reference docs or urls; if there are specific ones. 

    Subject: RE: How to multicast audio to 50+ ip phones?
    Replied by: David Staudt on 09-06-2010 12:04:20 AM
    Yep I think you have the general picture now.  Play: + TFTP may be
    somewhat easier to put together from an app perspective, but it does
    place management/performance load on the TFTP server for the cluster,
    and won't solve any bandwidth issues.
    This URL may be