March 2007 - freeswitch-dev@lists.freeswitch.org

Re: [Freeswitch-dev] adding support for incoming streaming audio
by Anthony Minessale 10 Mar '07

10 Mar '07

The idea for the bugs is so you can stream audio to the channel while it's doing something else. As for the file format thing, I do think that can be adapted to handle streaming audio too so I am going to add a little framework code so you could express file playback in url form such as wav:///tmp/file.wav which is silly yet valid but gives way to: shoutcast://mystream.com/foo.stream Look for that in the next commit. a shoutcast type module could stand to benifit from a common streaming framework that registers as an application, a file format and a media bug. Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com JABBER:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 ----- Original Message ---- From: "mda(a)discerning.com" <mda(a)discerning.com> To: freeswitch-dev(a)lists.freeswitch.org Sent: Friday, March 9, 2007 5:12:49 PM Subject: Re: [Freeswitch-dev] adding support for incoming streaming audio On Fri, 9 Mar 2007 11:35:15 -0800 (PST), "Anthony Minessale" <anthmct(a)yahoo.com> said: > The proper approach for this would be to use the media_bugs which are > used to record the session have have been recently enhanced to displace > the actual audio with audio you can replace. hmmm, I can see this for the case where someone might want to just sniff the frames (like recording) or if it wants to do arbitrary signal manipulation (such as noise cleanup or whatever). (perhaps a more evocative name would be better, like "filter" or "interceptor"?) but this case seems very similar in theory to what it would be to mux audio in a conference, or bridge to a hardware endpoint -- something the core should be able to do without me having to write all the by-frame signal muxing? > each streaming protocol can implement it's own mod > say "mod_shoutcast" and have an application or api command interface > hook to attach itself to the channel. but for example that isn't what mod_iax does, yet an IAX call can participate in a conference as a member, right? And so can dingaling. so why would mod_shoutcast be different? far be it to be to argue architecture with the architect :), but i'm still at a loss as to how/why this should be a "media bug" entity instead of a "file" entity or an "endpoint" entity. -mda > > media bugs is a concept where you can latch a struct and a callback onto > a channel. Your callback will be called continuously when audio is read > or > written to a channel and you can choose on setup if you want it to be > called > on read/write with muxed audio from both sides of a call or on write > giving > you a chance to replace the audio. > > http://www.freeswitch.org/docs/group__mb1.html > > If you look in switch_ivr.c in switch_ivr_record_file > http://fisheye.freeswitch.org/browse/FreeSWITCH/trunk/src/switch_ivr.c?r=44… > > You can see this is how it's possible to record from the background. > > If you look at mod_ivrtest.c (basically a scratch pad to test code) > http://fisheye.freeswitch.org/browse/FreeSWITCH/trunk/src/mod/applications/… > > the bugtest function shows how to set the channel up to run a bug > that gives you a chance to replace the frames as they are supposed to be > written to the channel so you could attach your shoutcast socket and > whenever > audio was to be written to the channel you could replace the frame with > one > from your stream so the caller would hear the stream instead of silence > or whatever the channel was really writing etc. > > > When a bug is active on a channel it forces trancoding even when it's not > necessary for a bridge so you can always get the audio as raw SLIN which > is > the only common audio format you can work with when combining media. > > > > > > > > Anthony Minessale II > > FreeSWITCH http://www.freeswitch.org/ > ClueCon http://www.cluecon.com/ > > AIM: anthm > MSN:anthony_minessale@hotmail.com > JABBER:anthony.minessale@gmail.com > IRC: irc.freenode.net #freeswitch > > FreeSWITCH Developer Conference > sip:888@conference.freeswitch.org > iax:guest@conference.freeswitch.org/888 > googletalk:conf+888@conference.freeswitch.org > pstn:213-799-1400 > > > ----- Original Message ---- > From: Mark D. Anderson <mda(a)discerning.com> > To: freeswitch-dev(a)lists.freeswitch.org > Sent: Thursday, March 8, 2007 5:04:50 PM > Subject: [Freeswitch-dev] adding support for incoming streaming audio > > 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" > > _______________________________________________ > Freeswitch-dev mailing list > Freeswitch-dev(a)lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > > > > > > > > > ____________________________________________________________________________________ > Expecting? Get great news right away with email Auto-Check. > Try the Yahoo! Mail Beta. > http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org ____________________________________________________________________________________ We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265

1 0

Re: [Freeswitch-dev] adding support for incoming streaming audio
by Anthony Minessale 09 Mar '07

09 Mar '07

The proper approach for this would be to use the media_bugs which are used to record the session have have been recently enhanced to displace the actual audio with audio you can replace. each streaming protocol can implement it's own mod say "mod_shoutcast" and have an application or api command interface hook to attach itself to the channel. media bugs is a concept where you can latch a struct and a callback onto a channel. Your callback will be called continuously when audio is read or written to a channel and you can choose on setup if you want it to be called on read/write with muxed audio from both sides of a call or on write giving you a chance to replace the audio. http://www.freeswitch.org/docs/group__mb1.html If you look in switch_ivr.c in switch_ivr_record_file http://fisheye.freeswitch.org/browse/FreeSWITCH/trunk/src/switch_ivr.c?r=44… You can see this is how it's possible to record from the background. If you look at mod_ivrtest.c (basically a scratch pad to test code) http://fisheye.freeswitch.org/browse/FreeSWITCH/trunk/src/mod/applications/… the bugtest function shows how to set the channel up to run a bug that gives you a chance to replace the frames as they are supposed to be written to the channel so you could attach your shoutcast socket and whenever audio was to be written to the channel you could replace the frame with one from your stream so the caller would hear the stream instead of silence or whatever the channel was really writing etc. When a bug is active on a channel it forces trancoding even when it's not necessary for a bridge so you can always get the audio as raw SLIN which is the only common audio format you can work with when combining media. Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com JABBER:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 ----- Original Message ---- From: Mark D. Anderson <mda(a)discerning.com> To: freeswitch-dev(a)lists.freeswitch.org Sent: Thursday, March 8, 2007 5:04:50 PM Subject: [Freeswitch-dev] adding support for incoming streaming audio 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" _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org ____________________________________________________________________________________ Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html

2 1

[Freeswitch-dev] adding support for incoming streaming audio
by Mark D. Anderson 08 Mar '07

08 Mar '07

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"

1 0

Re: [Freeswitch-dev] working theory regarding hang on originate from event_socket
by Anthony Minessale 08 Mar '07

08 Mar '07

there was a bug which is fixed now please update to latest svn Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com JABBER:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org pstn:213-799-1400 ----- Original Message ---- From: David Nicol <davidnicol(a)gmail.com> To: freeswitch-dev(a)lists.freeswitch.org Sent: Wednesday, March 7, 2007 5:30:44 PM Subject: [Freeswitch-dev] working theory regarding hang on originate from event_socket apparently the recent revisions to the sofia code have changed something so that there is no longer an immediate api/response following the originate command. It appears that the api/response does come, eventually, as if I wait long enough it comes, followed by a stack of events pertaining to the originated call. -- "Big discoveries are protected by public incredulity." -- Marshall McLuhan _______________________________________________ Freeswitch-dev mailing list Freeswitch-dev(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org ____________________________________________________________________________________ Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html

1 0

[Freeswitch-dev] working theory regarding hang on originate from event_socket
by David Nicol 07 Mar '07

07 Mar '07

apparently the recent revisions to the sofia code have changed something so that there is no longer an immediate api/response following the originate command. It appears that the api/response does come, eventually, as if I wait long enough it comes, followed by a stack of events pertaining to the originated call. -- "Big discoveries are protected by public incredulity." -- Marshall McLuhan

2 1

[Freeswitch-dev] XML-RPC
by Jonas Gauffin 06 Mar '07

06 Mar '07

Hello I've played around with the XML-RPC implementation and I have some suggestions. The output of all commands are now simple text strings. That makes the result parsing quite hard for applications that would like to use the interface (and it's really telnet commands wrapped into a xmlrpc body). For instance, take the "show channels" result. It currently looks like this (have removed the xml rpc body): uuid,created,name,state,cid_name,cid_num,ip_addr,dest,application,application_data,read_codec,read_rate,write_codec,write_rate 0983de41-2562-fa44-8c0c-a6e5747b2c17,2007-03-06 10:42:01,PortAudio/1234,CS_EXECUTE,FreeSwitch,5555551212,,1234,bridge,sofia… 37138427-cdb7-324c-b200-7123c063d473,2007-03-06 10:42:02,sofia/mydomain.com/1234@conference.freeswitch.org,CS_LOOPBACK,Free… 2 total. That should have been wrapped into xml instead: <channels count="2"> <channel> <uuid>0983de41-2562-fa44-8c0c-a6e5747b2c17,2007-03-06</uuid> <created>2007-03-06 10:42:01</created> <name>PortAudio/1234</name> [... and all other information ...] </channel> </channels> Same goes for all other commands implemented in XML-RPC. Best regards, Jonas

1 1

[Freeswitch-dev] EventSocket
by Jonas Gauffin 05 Mar '07

05 Mar '07

Hello Is it possible to subscribe on events for specific extensions (user-agents) only? Monitoring events for all extensions seems inefficient if I only need to monitor 30 of let's say 300 extensions. //Jonas

1 0

[Freeswitch-dev] Extending the user directory
by Jonas Gauffin 05 Mar '07

05 Mar '07

Hello Is it possible to extend freeswitch to read the user directory from an external source? I dont mind making a module for this, as long as I get an API specification. Best regards, Jonas

1 0

[Freeswitch-dev] run problem
by cret cret 05 Mar '07

05 Mar '07

Please help me. I compiled, changed the dial plan and freeswitch.xml and when i try to run i get: Cannot Initilize [Cannot Open log directory or XML Root!] What can i do? Thanks --------------------------------- LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com

1 0

Re: [Freeswitch-dev] FreeSwitch broken in SVN
by Michael Jerris 04 Mar '07

04 Mar '07

Bug is now in jira as: http://jira.freeswitch.org/browse/MODLANG-4 If anyone wants to take a try at a patch to fix this, feel free to upload something to the bug, otherwise I will try to get this resolved. Mike ________________________________ From: Nikolay Kolev [mailto:me@nikolay.com] Sent: Sunday, March 04, 2007 12:59 PM To: Michael Jerris Subject: RE: [Freeswitch-dev] FreeSwitch broken in SVN Probably you need to create a separate space for language-related bugs. I put it in the core (FSCORE-20): http://jira.freeswitch.org/browse/FSCORE-20 Nikolay ________________________________ From: freeswitch-dev-bounces(a)lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Michael Jerris Sent: Sunday, March 04, 2007 9:37 AM To: freeswitch-dev(a)lists.freeswitch.org Subject: Re: [Freeswitch-dev] FreeSwitch broken in SVN It looks like some changes to the core api were not updated in the swig wrappers we use for the language modules. Can someone please post a bug for this on jira.freeswitch.org. If you can put up a patch to fix this as well, that would be even better. Thanks Mike ________________________________ From: freeswitch-dev-bounces(a)lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Nikolay Kolev Sent: Sunday, March 04, 2007 12:01 PM To: freeswitch-dev(a)lists.freeswitch.org Subject: [Freeswitch-dev] FreeSwitch broken in SVN switch_swig.c:67: error: too many arguments to function `switch_core_destroy'

1 0