I'd like to have a streaming audio source (not just playing a local file) for users while they are parked or waiting for a conference to start. In digging into FS it seems there are several ways this might be approached. Of course this is based on only a superficial understanding of the FS internals. But I've come up with 6 (count them, 6) possibilities: 1) hack the "playback" application. Right now, the lookup of driver in switch-core.c is by file suffix (with no override in xml conf). Currently the only real format module is mod_sndfile. (The string constants for metadata like SWITCH_AUDIO_COL_STR_TITLE are conveniently set to be identical to the enum used by libsndfile.) It could be done by hacking mod_sndfile, or instead by making a new format driver, say "mod_url". libsndfile does not support mp3 (and won't), and is oriented around local files. So a mod_url driver would be better, with support for some suffixes like .pipe or .m3u or .mp3. It would need to do content-type sniffing in some cases. One issue is that it seems that mod_playback is blocking til completion. There is a timer in switch_ivr_play_file; it would be necessary to invert control there to allow the processing to proceed without the file ending. Pros: most useful; wherever a local file is used, a remote could be used instead. Cons: non-trivial amount of hacking. 2) Use an external process to convert streaming audio into sip. For example, using mjua or pjsua as sip clients, along with some command-line streaming audio client such as streamripper. Pros: no change to FS required Cons: lots of moving parts, and the SIP gateway utility will probably require some hacking. 3) implement a "mod_shout" as an endpoint for shoutcast/icecast protocol Pros: fits in well with FS architecture Cons: requires understanding FS internals concerning threading, buffering, etc. 4) implement a "mod_rtsp" as an endpoint. This would mean I'd have to be satisfied with supporting only rtsp streaming audio, not shoutcast/icecast streaming audio. Pros: In theory there wouldn't be much to do, since there is already RTSP support in the FS stack. Cons: requires underestanding FS internals *and* RTSP streaming audio 5) hack mod_conference to do stream-in just like record-out, as a thread. [I'm not sure why mod_conference does it that way, rather than at the core switch level (which *also* has session recording ability) -- isn't the point of a softswitch framework that it can allow for arbitrary combinations of modules? Shouldn't there be a way to supply an arbitrary channel as a member?] Pros: relatively easy to do by blindly copying the session record case. Cons: specific to conferencing, and makes mod_conference even bulkier. 6) implement mod_park with specific support for streaming audio [right now mod_park is just an empty stub.] Pros: standalone so easier to implement Cons: limits its usefulness to just that "application"