[Freeswitch-dev] adding support for incoming streaming audio

[Mark D. Anderson]

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"