- FreeSWITCH-dev - FreeSWITCH Mailing Lists

Re: [Freeswitch-dev] RingBack with FreeSwitch
by Anthony Minessale 20 Mar '07

20 Mar '07

The most efficient choice would be a .wav with raw PCM or pure raw pcm captured into a file (.raw, .r8 or .r16) that matches the samplerate of your typical calls e.g. 8kz 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: Jurijs Cerepanovs <jury(a)ht-telecom.com> To: freeswitch-dev(a)lists.freeswitch.org Sent: Tuesday, March 20, 2007 4:52:09 AM Subject: Re: [Freeswitch-dev] RingBack with FreeSwitch Jurijs Cerepanovs wrote: so ringback is OK - big thx. Which will be the best wav format for it? > Michael Jerris wrote: > Yes - this can be true ;) > Thx. > >> There is already some custom ringback tone functionality (see >> http://wiki.freeswitch.org/wiki/Special:Search?search=ringback) Does >> this meet your needs? >> >> Mike >> >> >> >>> -----Original Message----- >>> From: freeswitch-dev-bounces(a)lists.freeswitch.org >>> >>> >> [mailto:freeswitch-dev- >> >> >>> bounces(a)lists.freeswitch.org] On Behalf Of Jurijs Cerepanovs >>> Sent: Monday, March 19, 2007 6:41 PM >>> To: freeswitch-dev(a)lists.freeswitch.org >>> Subject: [Freeswitch-dev] RingBack with FreeSwitch >>> >>> Good day for all. >>> >>> Question is that - can we create module that will intercept incoming >>> call - set it to waiting state and play any file with >>> session.streamFile(...) while in background initiates new session? >>> >>> _______________________________________________ >>> 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 >>> >>> >> _______________________________________________ >> 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 >> >> >> > > > _______________________________________________ > 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 > > _______________________________________________ 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 ____________________________________________________________________________________ No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail

3 2

RingBack with FreeSwitch
by Jurijs Cerepanovs 20 Mar '07

20 Mar '07

Good day for all. Question is that - can we create module that will intercept incoming call - set it to waiting state and play any file with session.streamFile(...) while in background initiates new session?

3 4

Re: [Freeswitch-dev] XML-RPC
by Anthony Minessale 19 Mar '07

19 Mar '07

Hi, It's necessary to pay attention to the modularity of the system and overall scoping concerns when making this type of decision. The XMLRPC is a loadable module loaded by the core at runtime. "show" is an API command registered by mod_commands.so Because of this, it is not possible to extend the knowledge of XMLRPC to the 'show' command because there is no guarantee either module will be loaded. So, it's the API interface that is designed with a [string-in / string-out] prototype and the XMLRPC is only providing an interface to the API interface of freeswitch. This independance is mandatory and a fundamental of my design principle and anything else must be abandoned despite how tempting because the API interface is called from other methods such as a direct http connection, an event socket or from a scripting language such as javascript. However, It is completely possible to add support to the show command to parse a special input param and deliver that string-out as XML for instance: "show channels as xml" "show channels as csv" Each API command must provide it's own complete interpretation of the input and decision about what to output and since the entire system only has one "show" command it is not very difficult to implement this and it would be happily accepted as a patch to mod_commands.c 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: Jonas Gauffin <jonas.gauffin(a)gmail.com> To: freeswitch-dev(a)lists.freeswitch.org Sent: Tuesday, March 6, 2007 4:08:42 AM Subject: Re: [Freeswitch-dev] XML-RPC Correction: <array> <data> <value><string>0983de41-2562-fa44-8c0c-a6e5747b2c17,2007-03-06</string></value> <value><dateTime.iso8601>20070306T10:42:01</dateTime.iso8601></value> <value><string>PortAudio/1234</string></value> </data> </array> You can also use the <struct> tag to be able to assign names to each value. More info: http://www.xmlrpc.com/spec/ On 3/6/07, Jonas Gauffin <jonas.gauffin(a)gmail.com> wrote: > 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 > _______________________________________________ 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 ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL

4 7

RTP stuff
by Anthony Minessale 10 Mar '07

10 Mar '07

ok the commits are in for the rtp. When something withholds audio from the channel (ie purposely not write) CNG frames (as now advertised in sdp will flow every 5th packet interval with the proper timestamp). timestamp values increment regardless of if a channel writes data so a gap will now be properly reflected with AAAC00000CAAAA if A means audio and C means cng frames and 0 means nothing. 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: Trixter aka Bret McDanel <trixter(a)0xdecafbad.com> To: freeswitch-dev(a)lists.freeswitch.org Sent: Friday, February 23, 2007 1:11:02 PM Subject: Re: [Freeswitch-dev] SNMP Discussion. On 2/23/07, janvb(a)caselaboratories.com <janvb(a)caselaboratories.com > wrote: First and doremost alarms. Any alarm raised by any module/application. And I would like a config option in FreeSWITCH where I could format how Alarms where printed out. Meaning that if I in the stack raise a LOS/LOF I want to see it in SNMP in a confugurable format. There should also be a filtering mechanisme where I in a module can raise an alarm with a alarm no etc, and in config decide what severity and processing this alarm will receive (Ignore, Log, SNMP, email etc). The issue is that many maintenance departments have big display boards where alarms with major or critical severity is shown. Some of this might already be in here? Jan Its my understanding that you would be given some data, baed on the OID you could tell what its related to. I dont understand how it would be configurable. Also, I think clarification is in order here. There are two basic methods for doing SNMP, traps where FreeSWITCH would send to some SNMP monitoring agent and gets, where a client would poll FreeSWITCH for information. It is my understanding that traps are not currently supported, although my futher understanding is that its desired they would be. To get alarms in realtime you would likely want traps to be sent, so that you can see them as they happen. Polling via a SNMP get would work but you dont always want to poll too frequently as it does cause some load however minor. As for logging, it would be on the SNMP module to decide what gets logged. There is an eventing system already within the core of FreeSWITCH that would enable a SNMP module to monitor certain things. This would be similar to how the CDR modules work, except on other events. It would be upto the other modules to push events they think are desirable, such as a red alarm on a pri line in mod_wanpipe. The SNMP module would (presumably by configuration file) see that event, decide its worthy to be sent out, and send it. It should not be configured for each module to say what to do with it, it should instead be on the event omnitor modules such as SNMP to decide if they want it. So, you could have a module that wants critical events, and would send an email, as well as an SNMP module that would fire a trap, and whatever else, and they can all see the events as they happen. This already exists, its a matter of getting the modules to react to the events that is missing. -- Trixter http://www.0xdecafbad.com Bret McDanel Belfast +44 28 9099 6461 US +1 516 687 5200 http://www.trxtel.com the VoIP provider that pays you! _______________________________________________ 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

3 3

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

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

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

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