Re: [Freeswitch-users] Mod_limit stuck when hitting limit value
Hi, not too hard :p but it's just a bad habit when I write in my native language (french). I guess that this spelling is not too common for english speaker. I'll do my best next time to write it correctly. @tamas you are right, we could use limit_hash the same way as limit when not specifying the /rate @Mathieu did you suggest limit_hash is more scalable than limit? But I don't understand why limit_hash is not suitable for data replication (DB lookup for limit and memory for limit_hash??), even if I don't know how to do it with limit. regards. Raymond Chandler wrote: Tamas wrote: My guess is: pbm = problem :) sure, but is it really that hard to spell all the way out? -Ray ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
[Freeswitch-users] sip redirect contact variable no more available in SVN 12638
Hi, running SVN r12638, I don't have access anymore to these 2 variables after a SIP 302 message, using info application: variable_sip_redirect_contact_user_0 variable_sip_redirect_contact_host_0 It was okay with SVN r12611. regards, rod ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
[Freeswitch-users] Windows-compatible FXO PCI card?
Hello For SOHO users, getting a second, Linux-based computer just to run a small voice server is overkill, so I'm thinking of selling an application based on the Windows version of Freeswitch. Instead of the Sangoma USB connector, I'd really prefer to sell them a PCI card, because it's less messy, and there's less chance of them disconnecting the hardware. I don't know of FXO PCI cards to connect an XP/Vista host to a phone line. Does someone know of such a thing? Thank you. ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Problem dialing out via E1
Not sure if I can give access to the system externally. I know our security policy doesn't allow for stuff like that though. I'll pop on to the IRC channel - thanks for the help so far, I'm really keen to get this working after tinkering for well over a week with it! Mark. -Original Message- From: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 16 March 2009 17:16 To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Problem dialing out via E1 Any chance you can give one of us access to this system? Best thing to do would be to join #openzap on irc.freenode.net. -MC (IRC: mercutioviz) On Mon, Mar 16, 2009 at 9:53 AM, Mark Tabron mark.tab...@rnid-typetalk.org.uk wrote: Quick update on this. We've had the Euro ISDN line checked by BT and it all checks out ok - engineers were able to originate and make calls into the equipment on the end of the line our comms room. So, it looks like either Wanpipe / FS can't use the circuit but do report it as being up. Changed all the usual stuff like patch cables so I'm really at a dead end as to what this could be. Any ideas? Pastebin debug output is in my reply below. -Original Message- From: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Mark Tabron Sent: 13 March 2009 14:16 To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Problem dialing out via E1 I've not used Asterisk or Yate before. I've picked this project up from another colleague who is on long term leave, but I know he did look at Asterisk before deciding FS was more suited to our requirements (replacement PBX for an ageing Meridian). Thanks for the reply and pointers towards debugging. I've uploaded our output as directed from Openzap dumps plus the complete FS debug that appears when placing an outside call. Hopefully it can help to provide a possible answer! http://pastebin.freeswitch.org/7751 Will setup an IRC client and see if I can log onto the channel. Thanks again! -Original Message- From: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 12 March 2009 16:50 To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Problem dialing out via E1 My first post to the list. I'm a bit of a newb to FreeSwitch (and linux) so apologies if some of my terminology isn't quite correct. Welcome to FS! Just out of curiosity, have you ever used Asterisk or YATE? Recently had a 9 channel ISDN30 (euro - q931) installed by BT (UK). We've hooked it up to our FreeSwitch setup with a Sangoma A101 card. Light on the card is green and wanrouter is installed and up in TDM_API mode, with the connection status showing as connected. Configured Openzap for 9 b and 1 d channel as described in Freeswitch Wiki. Then created a diaplan to fire off any calls preceded by 9 to the next available openzap channel. Looks good so far... The problem I have is when I initiate an external call (using 9xxx) from an extension I can see Freeswitch allocating the call to the next available channel but then the just sits there and times out after 1 minute. With the cause stated as ORIGINATOR_CANCEL (guessing this is the time out) okay, some debugging info will be useful. Please read this wiki page first: http://wiki.freeswitch.org/wiki/Reporting_Bugs It has lots of useful information for how to gather log information, how to use the pastebin, etc. Specifically for this issue you'll need to use the pastebin because there will be so much information. Here are some pointers: To see what's happening with openzap you'll need to use the oz list and oz dump 1 at the command line (CLI). You'll also need to turn on debugging so that PRI messages show up. You'll need to capture the output on the CLI and put it into the pastebin. (http://pastebin.freeswitch.org). Welcome to the wonderful world of telephony debugging! -MC P.S. - We have a few IRC channels where you can join to get more real-time support: #freeswitch and #openzap on irc.freenode.net. (More details are in the wiki page I mentioned above.) ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org Save paper - don't print this email unless you need to. NOTICE from RNID Typetalk This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the addressee. If you are not the addressee, please note that any
Re: [Freeswitch-users] Windows-compatible FXO PCI card?
On Tue, Mar 17, 2009 at 2:02 PM, Gilles codecompl...@free.fr wrote: I don't know of FXO PCI cards to connect an XP/Vista host to a phone line. Does someone know of such a thing? Sangoma makes a low cost 4FXO, 1FXS. http://sangoma.com/products_and_solutions/hardware/analog_telephony/b600.html -- wasim h. baig | principal consultant | convergence pk | +92 300 8508070 | peace be upon you ... ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Freeswitch and Kamailio (OpenSer) Integration
Yes it is possible but there is no documentation on how to do it. You will have to learn SIP and understand what you are doing. Forwarding the call to FS for nat may cause issue as FS will then not have direct connection to the phone and may not be able to always detect it is behind NAT. Have a look at SIP PATH Extension as it is what you need to force traffic back to KAM from FS. Regards, Thomas On 6 Mar 2009, at 08:51, Ramu wrote: Hi All, I would like to setup freswitch and kamailio as follows: Kamailio acts as Proxy and Registrator Freeswitch acts as a SBC and MediaServer (voicemail) Users will be reigstered to Kamailio Kamailio forwards calls to FS to NAT FS sends back INVITE to Kamailio Kamailio will dial-out user. Bob calls Alice Bob ==INVITE == Kamailio ==INVITE== FS ==INVITE== Kamailio ==INVITE == Alice How can I achieve this scenario? Can you please direct me to any documentation which is available? Thanks, Ramu ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Problem dialing out via E1
Another update - this time (part) good news! Decided to run wancfg_tdmapi again, using the same settings as we always did, and we can now make external calls. I suspect that whatever BT did yesterday kicked the circuit back into life. However placing an external call into FS isn't as successful, looks like it can't assign a channel and terminates the call. -Original Message- From: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Mark Tabron Sent: 17 March 2009 09:31 To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Problem dialing out via E1 Not sure if I can give access to the system externally. I know our security policy doesn't allow for stuff like that though. I'll pop on to the IRC channel - thanks for the help so far, I'm really keen to get this working after tinkering for well over a week with it! Mark. -Original Message- From: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 16 March 2009 17:16 To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Problem dialing out via E1 Any chance you can give one of us access to this system? Best thing to do would be to join #openzap on irc.freenode.net. -MC (IRC: mercutioviz) On Mon, Mar 16, 2009 at 9:53 AM, Mark Tabron mark.tab...@rnid-typetalk.org.uk wrote: Quick update on this. We've had the Euro ISDN line checked by BT and it all checks out ok - engineers were able to originate and make calls into the equipment on the end of the line our comms room. So, it looks like either Wanpipe / FS can't use the circuit but do report it as being up. Changed all the usual stuff like patch cables so I'm really at a dead end as to what this could be. Any ideas? Pastebin debug output is in my reply below. -Original Message- From: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Mark Tabron Sent: 13 March 2009 14:16 To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Problem dialing out via E1 I've not used Asterisk or Yate before. I've picked this project up from another colleague who is on long term leave, but I know he did look at Asterisk before deciding FS was more suited to our requirements (replacement PBX for an ageing Meridian). Thanks for the reply and pointers towards debugging. I've uploaded our output as directed from Openzap dumps plus the complete FS debug that appears when placing an outside call. Hopefully it can help to provide a possible answer! http://pastebin.freeswitch.org/7751 Will setup an IRC client and see if I can log onto the channel. Thanks again! -Original Message- From: freeswitch-users-boun...@lists.freeswitch.org [mailto:freeswitch-users-boun...@lists.freeswitch.org] On Behalf Of Michael Collins Sent: 12 March 2009 16:50 To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Problem dialing out via E1 My first post to the list. I'm a bit of a newb to FreeSwitch (and linux) so apologies if some of my terminology isn't quite correct. Welcome to FS! Just out of curiosity, have you ever used Asterisk or YATE? Recently had a 9 channel ISDN30 (euro - q931) installed by BT (UK). We've hooked it up to our FreeSwitch setup with a Sangoma A101 card. Light on the card is green and wanrouter is installed and up in TDM_API mode, with the connection status showing as connected. Configured Openzap for 9 b and 1 d channel as described in Freeswitch Wiki. Then created a diaplan to fire off any calls preceded by 9 to the next available openzap channel. Looks good so far... The problem I have is when I initiate an external call (using 9xxx) from an extension I can see Freeswitch allocating the call to the next available channel but then the just sits there and times out after 1 minute. With the cause stated as ORIGINATOR_CANCEL (guessing this is the time out) okay, some debugging info will be useful. Please read this wiki page first: http://wiki.freeswitch.org/wiki/Reporting_Bugs It has lots of useful information for how to gather log information, how to use the pastebin, etc. Specifically for this issue you'll need to use the pastebin because there will be so much information. Here are some pointers: To see what's happening with openzap you'll need to use the oz list and oz dump 1 at the command line (CLI). You'll also need to turn on debugging so that PRI messages show up. You'll need to capture the output on the CLI and put it into the pastebin. (http://pastebin.freeswitch.org). Welcome to the wonderful world of telephony debugging! -MC P.S. - We have a few IRC channels where you can join to get more real-time support: #freeswitch and #openzap on irc.freenode.net. (More details are in the wiki page I
Re: [Freeswitch-users] SIP registration fails when using hostname in sip_profile ?
Thanks. It seems that it comes from my sip provider. when using my_host as my hostname, reg fails when using my_host.com as my hostname, reg succeeds (my_host.com does not exist as a domain internet) when using ip address, reg succeeds. Tested with version 1.0.3 Is it a way to force the IP address to be used in SIP header instead of hostname ? Thanks Ludovic Brian West a crit: This would be one thing to look at your DNS name isn't resolving correctly.. you might consider using dynamic DNS and you can then set the them to "host:myhost.dyndns.org" /b On Mar 16, 2009, at 12:55 PM, ludovic wrote: 2009-03-16 18:29:42 [DEBUG] sofia.c:206 sofia_event_callback() event [nua_r_invite] status [503][DNS Error] session: sofia/external/ 0123456789 2009-03-16 18:29:42 [DEBUG] sofia.c:206 sofia_event_callback() event [nua_i_state] status [503][DNS Error] session: sofia/external/ 0123456789 ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org -- Ludovic Fouquet RD Engineer Tel.: + 33 (0)1 43 34 63 38 Fax: + 33 (0)1 46 91 03 71 Web: www.bewan.com ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] echo cancellation on PRI cards
Wasim Baig wrote: 2009/3/17 Anthony Knight tntkni...@gmail.com mailto:tntkni...@gmail.com I'm thinking about doing a project that would use FreeSWITCH as an IVR, with callers being routed in by both ISDN PRI, and also SIP trunks, with occasional bridge calls between callers. I'm wondering in what use cases hardware echo cancellation on the PRI cards is needed. When there is Echo being generated from the far end, usually in a bridged call. If you application is just an IVR, with no far end connectivity, then you shouldn't need an echo can. If you are bridging calls, then at some point you may need it, depending on what else is in the loop. This is VERY VERY WRONG. IVRs badly need echo cancellation. Without it they give very poor reliability detecting DTMF while the prompts are playing. If the system uses voice recognition, its reliability will be even worse. And does hardware echo cancellation work with OpenZap/FreeSWITCH? Yes, it really has nothing to do with the software then, its handled by the card and its hardware driver. In Sangoma's case, by Wanpipe. It looks like all the major cards (Sangoma, Digium, etc..) use Octasic Echo cancellation add-on cards. Is there any difference between brands? Sangoma has 1024 tap Octasic Echo Cans. Very nice they are indeed. Any recommendations on PRI boards and whether I need to pay for echo cancellation are appreciated Unashamedly, Sangoma's. 100% of the cases where our customers have used Sangoma A10Xd vs A10X, they've been much happier with the quality on the line. Its a tad bit more $, but well worth it (especially in places with bad copper). If you use Sangoma make sure everything is up to date. People have had a lot of DTMF detection trouble with some revisions of the driver, or on board firmware, or possibly both. Clearly DTMF trouble would be pretty bad for an IVR. I didn't manage to trace which were the offending versions, but the current stuff is apparently OK. Steve ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] SIP registration fails when using hostname in sip_profile ?
What I provided you was an example. I don't think you understood what I was talking about. In the settings for ext-sip-ip and ext-rtp-ip you'll have to use something like host:yourdyndnshostname.blah.tld Then set the sip-ip and rtp-ip to what ever is auto detected. /b On Mar 17, 2009, at 6:22 AM, ludovic wrote: Thanks. It seems that it comes from my sip provider. when using my_host as my hostname, reg fails when using my_host.com as my hostname, reg succeeds (my_host.com does not exist as a domain internet) when using ip address, reg succeeds. Tested with version 1.0.3 Is it a way to force the IP address to be used in SIP header instead of hostname ? Thanks Ludovic ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
[Freeswitch-users] Fifo feature request -- no caller disconnect after agent hangup
I apologize if this is a double post to -dev. I'm not sure why I don't see my message appearing, so I'm going to try again in the -user list (first timer posting here ;). I have a situation where it would be useful for a caller not to be hungup, after finishing the fifo in execution (when the agent disconnects the call or the agent hangs-up). The caller is automatically hungup, in this situation. It would be preferable if the caller channel went further along the dial plan. I thought I might get lucky implementing this setting with hangup_after_bridge to false, but fifo does not utilize this variable. I tried looking thru the mod_fifo.c source, but my c skills are minimal. I also tried executing fifo in a lua app and setting setAutoHangup(false), but that also did not work. Any chance this could be done as a feature enhancement? Thanks. --matt ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
[Freeswitch-users] enable anonymous incomming calls
Hi all I'm freswitch newbie and have a simple question. How can enable anonymous inbound calls ? I would like to use freeswitch to accept incomming calls from sipbroker DIDs Any hint ? Thank in advance for all freeswitch team !! roberto -- Ing. Roberto Pereyra ContenidosOnline http://www.contenidosonline.com.ar The best dedicated servers - LiquidWeb http://www.liquidweb.com/?RID=contenid ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
[Freeswitch-users] [OpenZap] problem with TE220P
Hi, I have problem with Digium TE220P. Everything works, i can call talk, but everytime i have CRIT message: 2009-03-14 17:50:30 [CRIT] ozmod_isdn.c:904 zap_isdn_931_34() Received CALL PROCEEDING message for channel 0 When FS start show me ERR message: 2009-03-14 17:44:06 [ERR] Span:0 Q.921() Received UA frame in invalid state This is my config: cat zaptel.conf span=1,1,0,ccs,hdb3,crc4 bchan=1-15,17-31 dchan=16 span = 2,0,0,ccs,hdb3,crc4 bchan = 32-46,48-62 dchan = 47 loadzone = ru defaultzone=ru cat openzap.conf [span zt] name = OpenZAP number = 1 trunk_type = E1 b-channel = 1-15 d-channel = 16 b-channel = 17-31 [span zt] name = OpenZAP number = 2 trunk_type = E1 b-channel = 32-46 d-channel = 47 b-channel = 48-62 cat openzap.conf.xml configuration name=openzap.conf description=OpenZAP Configuration settings param name=debug value=0/ /settings pri_spans span id=1 param name=q921loglevel value=debug/ param name=q931loglevel value=debug/ param name=mode value=user/ param name=dialect value=q931/ param name=dialplan value=XML/ param name=context value=default/ /span span id=2 param name=q921loglevel value=debug/ param name=q931loglevel value=debug/ param name=mode value=user/ param name=dialect value=q931/ param name=dialplan value=XML/ param name=context value=default/ /span /pri_spans /configuration and FS start LOGS: 2009-03-14 17:44:06 [NOTICE] zap_io.c:2612 zap_global_init() Modules configured: 1 2009-03-14 17:44:06 [NOTICE] ozmod_zt.c:922 zt_init() Using Zaptel control device 2009-03-14 17:44:06 [INFO] zap_io.c:2433 zap_load_module() Loading IO from /usr/local/freeswitch/mod/ozmod_zt.so [zt] 2009-03-14 17:44:06 [INFO] zap_io.c:2233 load_config() auto-loaded 'zt' 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 1 as OpenZAP device 1:1 fd:38 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 2 as OpenZAP device 1:2 fd:39 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 3 as OpenZAP device 1:3 fd:40 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 4 as OpenZAP device 1:4 fd:41 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 5 as OpenZAP device 1:5 fd:42 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 6 as OpenZAP device 1:6 fd:43 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 7 as OpenZAP device 1:7 fd:44 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 8 as OpenZAP device 1:8 fd:45 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 9 as OpenZAP device 1:9 fd:46 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 10 as OpenZAP device 1:10 fd:47 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 11 as OpenZAP device 1:11 fd:48 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 12 as OpenZAP device 1:12 fd:49 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 13 as OpenZAP device 1:13 fd:50 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 14 as OpenZAP device 1:14 fd:51 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 15 as OpenZAP device 1:15 fd:52 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 16 as OpenZAP device 1:16 fd:53 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 17 as OpenZAP device 1:17 fd:54 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 18 as OpenZAP device 1:18 fd:55 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 19 as OpenZAP device 1:19 fd:56 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 20 as OpenZAP device 1:20 fd:57 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 21 as OpenZAP device 1:21 fd:58 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 22 as OpenZAP device 1:22 fd:59 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 23 as OpenZAP device 1:23 fd:60 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device
[Freeswitch-users] Fifo feature request -- no caller disconnect after agent hangup
I apologize if this is a double post to -dev. I'm not sure why I don't see my message appearing, so I'm going to try again in the -user list (first timer posting here ;). I have a situation where it would be useful for a caller not to be hungup, after finishing the fifo in execution (when the agent disconnects the call or the agent hangs-up). The caller is automatically hungup, in this situation. It would be preferable if the caller channel went further along the dial plan. I thought I might get lucky implementing this setting with hangup_after_bridge to false, but fifo does not utilize this variable. I tried looking thru the mod_fifo.c source, but my c skills are minimal. I also tried executing fifo in a lua app and setting setAutoHangup(false), but that also did not work. Any chance this could be done as a feature enhancement? Thanks. --matt ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] enable anonymous incomming calls
at default config, in conf/sip_profiles/external.xml
param name=sip-port value=$${external_sip_port}/
param name=dialplan value=XML/
param name=context value=public/
where $${external_sip_port} is a variable you can find in conf/
vars.xml, normally it's 5080, make sure sipbroker route calls to that
port, and then you can make a dialplan in
conf/dialplan/public.xml
turn on verbose log in console by
fs console loglevel debug
you can see the process when FS hit the dialplan
On Mar 17, 2009, at 8:26 PM, Roberto Pereyra wrote:
Hi all
I'm freswitch newbie and have a simple question.
How can enable anonymous inbound calls ? I would like to use
freeswitch to accept incomming calls from sipbroker DIDs
Any hint ?
Thank in advance for all freeswitch team !!
roberto
--
Ing. Roberto Pereyra
ContenidosOnline
http://www.contenidosonline.com.ar
The best dedicated servers - LiquidWeb
http://www.liquidweb.com/?RID=contenid
___
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
___
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Re: [Freeswitch-users] echo cancellation on PRI cards
Steve Underwood wrote: When there is Echo being generated from the far end, usually in a bridged call. If you application is just an IVR, with no far end connectivity, then you shouldn't need an echo can. If you are bridging calls, then at some point you may need it, depending on what else is in the loop. This is VERY VERY WRONG. IVRs badly need echo cancellation. Without it they give very poor reliability detecting DTMF while the prompts are playing. If the system uses voice recognition, its reliability will be even worse. With respect, this is at best half true. DTMF detection has always worked just fine without echo cancellation - the Dialogic, Aculab and Rhetorex cards which I used in the late 1990s managed it perfectly well; if the DTMF detection code in * and FS can't, then maybe that's something for its author to look at ;-) ASR - yes, maybe, but LH's ASR1500 used to work perfectly well on the same hardware above back in the day. I'd be interested to see results of testing an ASR engine in with echo; unfortunately, most vendors appear to prohibit the publication of test results in their licensing. --Dave ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] enable anonymous incomming calls
Thanks a lot dujinfang !!
roberto
2009/3/17 dujinfang dujinf...@gmail.com:
at default config, in conf/sip_profiles/external.xml
param name=sip-port value=$${external_sip_port}/
param name=dialplan value=XML/
param name=context value=public/
where $${external_sip_port} is a variable you can find in conf/
vars.xml, normally it's 5080, make sure sipbroker route calls to that
port, and then you can make a dialplan in
conf/dialplan/public.xml
turn on verbose log in console by
fs console loglevel debug
you can see the process when FS hit the dialplan
On Mar 17, 2009, at 8:26 PM, Roberto Pereyra wrote:
Hi all
I'm freswitch newbie and have a simple question.
How can enable anonymous inbound calls ? I would like to use
freeswitch to accept incomming calls from sipbroker DIDs
Any hint ?
Thank in advance for all freeswitch team !!
roberto
--
Ing. Roberto Pereyra
ContenidosOnline
http://www.contenidosonline.com.ar
The best dedicated servers - LiquidWeb
http://www.liquidweb.com/?RID=contenid
___
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
___
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
--
The best dedicated servers - LiquidWeb
http://www.liquidweb.com/?RID=contenid
___
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Re: [Freeswitch-users] bridge to gateway overwrites effective caller id with username
Hi!
Is this not possible with registration at a gateway or is there a other
reason why i didn't get any responses on this question?
Regards
Christian
On Wed, 11 Mar 2009 18:07:42 +0100
Christian Benke be...@inqnet.at wrote:
Hi!
I've recently started to configure a freeswitch for our new office pbx
and so far i like it very much(Coming from asteriskopenser with 2
years experience at a ITSP. Openser was nice but i didn't like
asterisk for several reasons, so i searched for a more stable and
cleaner alternative. Freeswitch looks _very_ promising and i'd wished
i could use it for more difficult demands than a simple
office-pbx ;-)).
So far i had little trouble(Though our installation doesn't require
much), for PSTN-calls i'm using a SIP-Trunk provided by our ISP.
The only issue i have not resolved yet is setting the outgoing
DID(head-number + extension, e.g. +4312345678 + 100).
The relevant part of the default.xml looks like this atm(where
+4312345678 is our head-phone-number without the extensions,
${caller_id_number} is a 3-digit extension, e.g.: 100):
anti-action application=set
data=effective_caller_id_number=+4312345678${caller_id_number}/
anti-action application=bridge
data=sofia/gateway/sip.myisp.at/${destination_number}/
I'd expect with this dialplan the effective_caller_id would be in the
From:-section of the INVITE, but it seems after the bridge it is
overwritten with the gateway-username i've defined in the
gateway-configuration in sip_profiles/external/.
So instead of:
From: Desk Phone
sip:+4312345678...@sip.myisp.at;transport=udp;tag=U6yQUSta2c2Xg.
i get:
From: Desk Phone
sip:p00.my...@sip.myisp.at;transport=udp;tag=U6yQUSta2c2Xg.
in the INVITE towards the sip-trunk.
I may not have grasped yet how proper debugging with freeswitch works,
however, in the console the last action i see, before the bridge to
sofia/external is created, is the setting of the effective-caller-id,
as expected(Do you want to see the whole output?).
I guess i don't necessarily need to register with the provider, as
they have configured the trunk for my ip-adress and i have theirs in
the ACL(inbound calls work flawless with the head-number+extension),
so maybe the registration is the reason why freeswitch does that
automatically?
It's probably a little issue, but i don't have the overview yet to
understand how this happens, maybe someone can point me to the right
place?
Cheers
Christian
___
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Re: [Freeswitch-users] bridge to gateway overwrites effective caller id with username
Try export instead of set
/b
On Mar 17, 2009, at 10:23 AM, Christian Benke wrote:
anti-action application=set
data=effective_caller_id_number=+4312345678${caller_id_number}/
___
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Re: [Freeswitch-users] bridge to gateway overwrites effective caller id with username
gateways have their username in the from section, callerid is sent out
as remote-party-id or p-asserted-identity.
if you want the from part to have the user you need to set the caller-
id-in-from param to true
Math
On 11-Mar-09, at 1:07 PM, Christian Benke wrote:
Hi!
I've recently started to configure a freeswitch for our new office pbx
and so far i like it very much(Coming from asteriskopenser with 2
years experience at a ITSP. Openser was nice but i didn't like
asterisk
for several reasons, so i searched for a more stable and cleaner
alternative. Freeswitch looks _very_ promising and i'd wished i could
use it for more difficult demands than a simple office-pbx ;-)).
So far i had little trouble(Though our installation doesn't require
much), for PSTN-calls i'm using a SIP-Trunk provided by our ISP.
The only issue i have not resolved yet is setting the outgoing
DID(head-number + extension, e.g. +4312345678 + 100).
The relevant part of the default.xml looks like this atm(where
+4312345678 is our head-phone-number without the extensions,
${caller_id_number} is a 3-digit extension, e.g.: 100):
anti-action application=set
data=effective_caller_id_number=+4312345678${caller_id_number}/
anti-action application=bridge
data=sofia/gateway/sip.myisp.at/${destination_number}/
I'd expect with this dialplan the effective_caller_id would be in the
From:-section of the INVITE, but it seems after the bridge it is
overwritten with the gateway-username i've defined in the
gateway-configuration in sip_profiles/external/.
So instead of:
From: Desk Phone
sip:+4312345678...@sip.myisp.at;transport=udp;tag=U6yQUSta2c2Xg.
i get:
From: Desk Phone
sip:p00.my...@sip.myisp.at;transport=udp;tag=U6yQUSta2c2Xg.
in the INVITE towards the sip-trunk.
I may not have grasped yet how proper debugging with freeswitch works,
however, in the console the last action i see, before the bridge to
sofia/external is created, is the setting of the effective-caller-
id, as
expected(Do you want to see the whole output?).
I guess i don't necessarily need to register with the provider, as
they
have configured the trunk for my ip-adress and i have theirs in
the ACL(inbound calls work flawless with the head-number+extension),
so
maybe the registration is the reason why freeswitch does that
automatically?
It's probably a little issue, but i don't have the overview yet to
understand how this happens, maybe someone can point me to the right
place?
Cheers
Christian
___
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
___
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Re: [Freeswitch-users] echo cancellation on PRI cards
David Knell wrote: Steve Underwood wrote: When there is Echo being generated from the far end, usually in a bridged call. If you application is just an IVR, with no far end connectivity, then you shouldn't need an echo can. If you are bridging calls, then at some point you may need it, depending on what else is in the loop. This is VERY VERY WRONG. IVRs badly need echo cancellation. Without it they give very poor reliability detecting DTMF while the prompts are playing. If the system uses voice recognition, its reliability will be even worse. With respect, this is at best half true. DTMF detection has always worked just fine without echo cancellation - the Dialogic, Aculab and Rhetorex cards which I used in the late 1990s managed it perfectly well; if the DTMF detection code in * and FS can't, then maybe that's something for its author to look at ;-) Try reading the Dialogic and Aculab documentation. Those cards used quite a bit of their DSP capability to remove the spillback of outgoing voice into their DTMF receivers. You'll find the DTMF detector in spandsp (not necessarily the ones in * or FS, which have been altered a bit) is superior to either Dialogic or Aculab's. ASR - yes, maybe, but LH's ASR1500 used to work perfectly well on the same hardware above back in the day. I'd be interested to see results of testing an ASR engine in with echo; unfortunately, most vendors appear to prohibit the publication of test results in their licensing. LH used to work fine with the J series Dialogic cards. The Dialogic documents go into considerable details about the echo cancellation arrangements to make that happen. Regards, Steve ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] bridge to gateway overwrites effective caller id with username
Maybe it can help by following this thread
http://lists.freeswitch.org/pipermail/freeswitch-users/2009-March/012083.html
On Mar 17, 2009, at 11:23 PM, Christian Benke wrote:
Hi!
Is this not possible with registration at a gateway or is there a
other
reason why i didn't get any responses on this question?
Regards
Christian
On Wed, 11 Mar 2009 18:07:42 +0100
Christian Benke be...@inqnet.at wrote:
Hi!
I've recently started to configure a freeswitch for our new office
pbx
and so far i like it very much(Coming from asteriskopenser with 2
years experience at a ITSP. Openser was nice but i didn't like
asterisk for several reasons, so i searched for a more stable and
cleaner alternative. Freeswitch looks _very_ promising and i'd wished
i could use it for more difficult demands than a simple
office-pbx ;-)).
So far i had little trouble(Though our installation doesn't require
much), for PSTN-calls i'm using a SIP-Trunk provided by our ISP.
The only issue i have not resolved yet is setting the outgoing
DID(head-number + extension, e.g. +4312345678 + 100).
The relevant part of the default.xml looks like this atm(where
+4312345678 is our head-phone-number without the extensions,
${caller_id_number} is a 3-digit extension, e.g.: 100):
anti-action application=set
data=effective_caller_id_number=+4312345678${caller_id_number}/
anti-action application=bridge
data=sofia/gateway/sip.myisp.at/${destination_number}/
I'd expect with this dialplan the effective_caller_id would be in the
From:-section of the INVITE, but it seems after the bridge it is
overwritten with the gateway-username i've defined in the
gateway-configuration in sip_profiles/external/.
So instead of:
From: Desk Phone
sip:+4312345678...@sip.myisp.at;transport=udp;tag=U6yQUSta2c2Xg.
i get:
From: Desk Phone
sip:p00.my...@sip.myisp.at;transport=udp;tag=U6yQUSta2c2Xg.
in the INVITE towards the sip-trunk.
I may not have grasped yet how proper debugging with freeswitch
works,
however, in the console the last action i see, before the bridge to
sofia/external is created, is the setting of the effective-caller-id,
as expected(Do you want to see the whole output?).
I guess i don't necessarily need to register with the provider, as
they have configured the trunk for my ip-adress and i have theirs in
the ACL(inbound calls work flawless with the head-number+extension),
so maybe the registration is the reason why freeswitch does that
automatically?
It's probably a little issue, but i don't have the overview yet to
understand how this happens, maybe someone can point me to the right
place?
Cheers
Christian
___
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
___
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Re: [Freeswitch-users] Problem dialing out via E1
On Tue, Mar 17, 2009 at 4:24 AM, Mark Tabron mark.tab...@rnid-typetalk.org.uk wrote: Another update - this time (part) good news! Decided to run wancfg_tdmapi again, using the same settings as we always did, and we can now make external calls. I suspect that whatever BT did yesterday kicked the circuit back into life. Good. I can't tell you how many times I've spoken to a telco when there's a problem and the circuit magically comes back to life. They frequently claim, We didn't do anything. I think that's a euphemism for we did a reset and prayed. However placing an external call into FS isn't as successful, looks like it can't assign a channel and terminates the call. Be sure that you have some routing mechanism in your public.xml file. Do you have a whole block of DID numbers? Anyway, pastebin your public.xml and a debug trace of an incoming call, including what phone number the caller dialed, and we'll take a look. -MC ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Possible memory / cpu leak
Thanks for the tip Brian. Here's a link to the valgrind output : http://cfowl.postinbox.com/vg.log Chris. ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Possible memory / cpu leak
You're not leaking... I wouldn't call 737 bytes a leak. /b On Mar 17, 2009, at 10:49 AM, Chris Fowler wrote: Thanks for the tip Brian. Here's a link to the valgrind output : http://cfowl.postinbox.com/vg.log Chris. ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Fifo feature request -- no caller disconnect after agent hangup
there is a patch in jira that will implement this feature about to be added 2009/3/17 Matthew Fong mattdf...@gmail.com I apologize if this is a double post to -dev. I'm not sure why I don't see my message appearing, so I'm going to try again in the -user list (first timer posting here ;). I have a situation where it would be useful for a caller not to be hungup, after finishing the fifo in execution (when the agent disconnects the call or the agent hangs-up). The caller is automatically hungup, in this situation. It would be preferable if the caller channel went further along the dial plan. I thought I might get lucky implementing this setting with hangup_after_bridge to false, but fifo does not utilize this variable. I tried looking thru the mod_fifo.c source, but my c skills are minimal. I also tried executing fifo in a lua app and setting setAutoHangup(false), but that also did not work. Any chance this could be done as a feature enhancement? Thanks. --matt ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_miness...@hotmail.com msn%3aanthony_miness...@hotmail.com GTALK/JABBER/PAYPAL:anthony.miness...@gmail.compaypal%3aanthony.miness...@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:8...@conference.freeswitch.org sip%3a...@conference.freeswitch.org iax:gu...@conference.freeswitch.org/888 googletalk:conf+...@conference.freeswitch.orggoogletalk%3aconf%2b...@conference.freeswitch.org pstn:213-799-1400 ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Possible memory / cpu leak
The crash on shutdown was an issue in mod_spidermonkey that was accidentally added if you update again it's gone. please run the valgrind command again then make several calls that fall in line with your normal usage pattern so the program can get an accurate trace of the memory usage. On Tue, Mar 17, 2009 at 10:49 AM, Chris Fowler ch...@fowler.cc wrote: Thanks for the tip Brian. Here's a link to the valgrind output : http://cfowl.postinbox.com/vg.log Chris. ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_miness...@hotmail.com msn%3aanthony_miness...@hotmail.com GTALK/JABBER/PAYPAL:anthony.miness...@gmail.compaypal%3aanthony.miness...@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:8...@conference.freeswitch.org sip%3a...@conference.freeswitch.org iax:gu...@conference.freeswitch.org/888 googletalk:conf+...@conference.freeswitch.orggoogletalk%3aconf%2b...@conference.freeswitch.org pstn:213-799-1400 ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] echo cancellation on PRI cards
Thanks for the feedback. I have plenty of experience with IVRs and Dialogic cards (starting with D121/LSI120s and SS96s under DOS in the 90's all the way up to Intel's DM/Vs) and didn't ever have a problem with DTMF collection with ISDN PRI lines except occasionally with wireless and cell phones (Bad line quality). These new cards are so much cheaper than the Dialogic cards were, I should just buy the version with the cancellers. Tony On Tue, Mar 17, 2009 at 11:36 AM, Steve Underwood ste...@coppice.orgwrote: David Knell wrote: Steve Underwood wrote: When there is Echo being generated from the far end, usually in a bridged call. If you application is just an IVR, with no far end connectivity, then you shouldn't need an echo can. If you are bridging calls, then at some point you may need it, depending on what else is in the loop. This is VERY VERY WRONG. IVRs badly need echo cancellation. Without it they give very poor reliability detecting DTMF while the prompts are playing. If the system uses voice recognition, its reliability will be even worse. With respect, this is at best half true. DTMF detection has always worked just fine without echo cancellation - the Dialogic, Aculab and Rhetorex cards which I used in the late 1990s managed it perfectly well; if the DTMF detection code in * and FS can't, then maybe that's something for its author to look at ;-) Try reading the Dialogic and Aculab documentation. Those cards used quite a bit of their DSP capability to remove the spillback of outgoing voice into their DTMF receivers. You'll find the DTMF detector in spandsp (not necessarily the ones in * or FS, which have been altered a bit) is superior to either Dialogic or Aculab's. ASR - yes, maybe, but LH's ASR1500 used to work perfectly well on the same hardware above back in the day. I'd be interested to see results of testing an ASR engine in with echo; unfortunately, most vendors appear to prohibit the publication of test results in their licensing. LH used to work fine with the J series Dialogic cards. The Dialogic documents go into considerable details about the echo cancellation arrangements to make that happen. Regards, Steve ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
[Freeswitch-users] Digium TE220P problem.
Hi, I have problem with Digium TE220P. Everything works, i can call talk, but everytime i have CRIT message: 2009-03-14 17:50:30 [CRIT] ozmod_isdn.c:904 zap_isdn_931_34() Received CALL PROCEEDING message for channel 0 When FS start show me ERR message: 2009-03-14 17:44:06 [ERR] Span:0 Q.921() Received UA frame in invalid state This is my config: cat zaptel.conf span=1,1,0,ccs,hdb3,crc4 bchan=1-15,17-31 dchan=16 span = 2,0,0,ccs,hdb3,crc4 bchan = 32-46,48-62 dchan = 47 loadzone = ru defaultzone=ru cat openzap.conf [span zt] name = OpenZAP number = 1 trunk_type = E1 b-channel = 1-15 d-channel = 16 b-channel = 17-31 [span zt] name = OpenZAP number = 2 trunk_type = E1 b-channel = 32-46 d-channel = 47 b-channel = 48-62 cat openzap.conf.xml configuration name=openzap.conf description=OpenZAP Configuration settings param name=debug value=0/ /settings pri_spans span id=1 param name=q921loglevel value=debug/ param name=q931loglevel value=debug/ param name=mode value=user/ param name=dialect value=q931/ param name=dialplan value=XML/ param name=context value=default/ /span span id=2 param name=q921loglevel value=debug/ param name=q931loglevel value=debug/ param name=mode value=user/ param name=dialect value=q931/ param name=dialplan value=XML/ param name=context value=default/ /span /pri_spans /configuration and FS start LOGS: 2009-03-14 17:44:06 [NOTICE] zap_io.c:2612 zap_global_init() Modules configured: 1 2009-03-14 17:44:06 [NOTICE] ozmod_zt.c:922 zt_init() Using Zaptel control device 2009-03-14 17:44:06 [INFO] zap_io.c:2433 zap_load_module() Loading IO from /usr/local/freeswitch/mod/ozmod_zt.so [zt] 2009-03-14 17:44:06 [INFO] zap_io.c:2233 load_config() auto-loaded 'zt' 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 1 as OpenZAP device 1:1 fd:38 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 2 as OpenZAP device 1:2 fd:39 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 3 as OpenZAP device 1:3 fd:40 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 4 as OpenZAP device 1:4 fd:41 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 5 as OpenZAP device 1:5 fd:42 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 6 as OpenZAP device 1:6 fd:43 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 7 as OpenZAP device 1:7 fd:44 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 8 as OpenZAP device 1:8 fd:45 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 9 as OpenZAP device 1:9 fd:46 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 10 as OpenZAP device 1:10 fd:47 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 11 as OpenZAP device 1:11 fd:48 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 12 as OpenZAP device 1:12 fd:49 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 13 as OpenZAP device 1:13 fd:50 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 14 as OpenZAP device 1:14 fd:51 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 15 as OpenZAP device 1:15 fd:52 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 16 as OpenZAP device 1:16 fd:53 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 17 as OpenZAP device 1:17 fd:54 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 18 as OpenZAP device 1:18 fd:55 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 19 as OpenZAP device 1:19 fd:56 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 20 as OpenZAP device 1:20 fd:57 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 21 as OpenZAP device 1:21 fd:58 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 22 as OpenZAP device 1:22 fd:59 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel channel 23 as OpenZAP device 1:23 fd:60 2009-03-14 17:44:06 [INFO] ozmod_zt.c:299 zt_open_range() configuring device /dev/zap/channel
Re: [Freeswitch-users] bridge to gateway overwrites effective caller id with username
wow, now that was fast :-) Cheers for all replies, setting the caller-id-in-from-parameter was sufficient! regards Christian ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] echo cancellation on PRI cards
Anthony Knight wrote: Thanks for the feedback. I have plenty of experience with IVRs and Dialogic cards (starting with D121/LSI120s and SS96s under DOS in the 90's all the way up to Intel's DM/Vs) and didn't ever have a problem with DTMF collection with ISDN PRI lines except occasionally with wireless and cell phones (Bad line quality). You have my deepest sympathy. :-) Steve ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] [OpenZap] problem with TE220P
any idea how i can fix this error ? I believe this is a harmless warning. However, you might try to use ozmod_libpri, which uses the libpri PRI stack instead of the built-in OpenZAP PRI stack. More info here: http://wiki.freeswitch.org/wiki/OpenZAP#OpenZAP_Installation -MC ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] echo cancellation on PRI cards
Steve Underwood wrote: David Knell wrote: Steve Underwood wrote: When there is Echo being generated from the far end, usually in a bridged call. If you application is just an IVR, with no far end connectivity, then you shouldn't need an echo can. If you are bridging calls, then at some point you may need it, depending on what else is in the loop. This is VERY VERY WRONG. IVRs badly need echo cancellation. Without it they give very poor reliability detecting DTMF while the prompts are playing. If the system uses voice recognition, its reliability will be even worse. With respect, this is at best half true. DTMF detection has always worked just fine without echo cancellation - the Dialogic, Aculab and Rhetorex cards which I used in the late 1990s managed it perfectly well; if the DTMF detection code in * and FS can't, then maybe that's something for its author to look at ;-) Try reading the Dialogic and Aculab documentation. Those cards used quite a bit of their DSP capability to remove the spillback of outgoing voice into their DTMF receivers. You'll find the DTMF detector in spandsp (not necessarily the ones in * or FS, which have been altered a bit) is superior to either Dialogic or Aculab's. The first bit of that's a tad patronising, isn't it, and, in the case of the decade-old Aculab cards which which I'm most familiar, is also untrue. As for the second, do you have any test results to back that up? I'm more curious than setting out for an argument.. ASR - yes, maybe, but LH's ASR1500 used to work perfectly well on the same hardware above back in the day. I'd be interested to see results of testing an ASR engine in with echo; unfortunately, most vendors appear to prohibit the publication of test results in their licensing. LH used to work fine with the J series Dialogic cards. The Dialogic documents go into considerable details about the echo cancellation arrangements to make that happen. You've missed the point I was trying to make. It used to work fine with no echo cancellation at all. --Dave ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] SIP registration fails when using hostname in sip_profile ?
I checked, I don't see sw1.freephonie.net in the logs trying to resolve it... and the SRV records are all correct as are the naptr records which is shocking ;) /b On Mar 17, 2009, at 1:16 PM, ludovic wrote: I understood the example. What I mean is that my DNS issue comes from sofia-sip and my sip provider (freephonie.net) name resolution which fails when calling whereas it is well resolved during the registration process. Here is a trace : 2009-03-17 18:47:28 [NOTICE] switch_channel.c:538 switch_channel_set_name() New Channel sofia/external/0123456789 [ae9c2108-131b-11de-8a2f-1fafbaa54120] nua: nh_create_handle: entering ; nua: nua_handle_bind: entering nua: nua_invite: entering nua: nua_stack_set_params: entering soa_clone(static::0x100abd98, 0x100a8738, 0x100c6748) called soa_set_params(static::0x100b4728, ...) called soa_set_params(static::0x100b4728, ...) called soa_set_user_sdp(static::0x100b4728, (nil), 0x10106364, -1) called soa_set_capability_sdp(static::0x100b4728, (nil), 0x10106364, -1) called su_localinfo: if lo with index 1 su_localinfo: if lan1 with index 18 su_localinfo: if ppp1 with index 23 nta_leg_tcreate(0x100c7f30) nua(0x100c6748): adding session usage soa_init_offer_answer(static::0x100b4728) called soa_generate_offer(static::0x100b4728, 0) called soa_static_offer_answer_action(0x100b4728, soa_generate_offer): called soa_static(0x100b4728, soa_generate_offer): generating local description su_localinfo: if lo with index 1 su_localinfo: if lan1 with index 18 su_localinfo: if ppp1 with index 23 soa_static(0x100b4728, soa_generate_offer): upgrade with local description soa_sdp_mode_set(0x7dbfd850, (nil), ): called soa_static(0x100b4728, soa_generate_offer): storing local description soa_get_local_sdp(static::0x100b4728, [(nil)], [0x7dbff980], [0x7dbff984]) called nta: selecting scheme sip sres_cache_get(0x100abfc0, NAPTR, freephonie.net.) called rr found in cache: freephonie.net. 35 sres_cache_get(0x100abfc0, NAPTR, freephonie.net.) returned 1 entries nta: for freephonie.net query freephonie.net NAPTR (cached) nta: freephonie.net. IN NAPTR 100 100 s SIP+D2U _sip_udp.freephonie.net. sres_cache_get(0x100abfc0, SRV, _sip_udp.freephonie.net.) called rr found in cache: _sip_udp.freephonie.net. 33 sres_cache_get(0x100abfc0, SRV, _sip_udp.freephonie.net.) returned 1 entries nta: for freephonie.net query _sip_udp.freephonie.net. SRV (cached) nta: timer set to 32000 ms nua(0x100c6748): call state changed: init - calling, sent offer soa_get_local_sdp(static::0x100b4728, [0x7dbff988], [0x7dbff98c], [(nil)]) called nua: nua_application_event: entering nua(0x100c6748): call state changed: calling - init nua(0x100c6748): removing session usage soa_destroy(static::0x100b4728) called ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] echo cancellation on PRI cards
David Knell wrote: Steve Underwood wrote: David Knell wrote: Steve Underwood wrote: When there is Echo being generated from the far end, usually in a bridged call. If you application is just an IVR, with no far end connectivity, then you shouldn't need an echo can. If you are bridging calls, then at some point you may need it, depending on what else is in the loop. This is VERY VERY WRONG. IVRs badly need echo cancellation. Without it they give very poor reliability detecting DTMF while the prompts are playing. If the system uses voice recognition, its reliability will be even worse. With respect, this is at best half true. DTMF detection has always worked just fine without echo cancellation - the Dialogic, Aculab and Rhetorex cards which I used in the late 1990s managed it perfectly well; if the DTMF detection code in * and FS can't, then maybe that's something for its author to look at ;-) Try reading the Dialogic and Aculab documentation. Those cards used quite a bit of their DSP capability to remove the spillback of outgoing voice into their DTMF receivers. You'll find the DTMF detector in spandsp (not necessarily the ones in * or FS, which have been altered a bit) is superior to either Dialogic or Aculab's. The first bit of that's a tad patronising, isn't it, You are the one who started out being offensive. and, in the case of the decade-old Aculab cards which which I'm most familiar, is also untrue. I can't find too much about the old cards on the web now, but I found http://www.amdevcomm.com/voice-mail-products/voice-mail-components/dialogic/dti_sc.html which is pretty much a copy and paste from the old Dialogic web pages, and you'll see it says Cut through : Local echo cancellation permits 100% detection with a 4.5 dB return loss line. The Aculabs did the same thing for sure. They just couldn't work without cancellation. There were some very early Dialogic cards, using DTMF receiver chips and OKI ADPCM chips, and had no general purpose DSPs. They performed really badly because of the lack of cancellation, and were quickly replaced with cards that put the OKI ADPCM, DTMF anf echo cancellation algorithms into a Motorola 56k DSP chips. As for the second, do you have any test results to back that up? I'm more curious than setting out for an argument.. ASR - yes, maybe, but LH's ASR1500 used to work perfectly well on the same hardware above back in the day. I'd be interested to see results of testing an ASR engine in with echo; unfortunately, most vendors appear to prohibit the publication of test results in their licensing. LH used to work fine with the J series Dialogic cards. The Dialogic documents go into considerable details about the echo cancellation arrangements to make that happen. You've missed the point I was trying to make. It used to work fine with no echo cancellation at all. I think you've missed the point. These things don't work by pixey dust. They work by engineering. If you have any old J or JCT cards around record the signal from the far end. You'll find only the tiniest trace of the outgoing signal mixed in with it. How do you think that happens? Steve ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
[Freeswitch-users] Nibblebill - DB Error while updating cash!
Hi All, I have installed nibblebill and* it is able to bill the calls.* However, it is giving following error in FreeSwitch server. 2009-03-17 23:17:19 [DEBUG] mod_nibblebill.c:283 bill_event() Doing update query [UPDATE accounts SET cash=cash-0.045767 WHERE id=1] 2009-03-17 23:17:19 [CRIT] mod_nibblebill.c:286 bill_event() DB Error while updating cash! Thanks Jayaprakash ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
[Freeswitch-users] DTMF detection during bridge
Hi, Is there any easy way to get in FS the same behavior as when using the d flag with asterisk's Dial command? I need FS to jump to a different extension if the caller presses a digit while waiting for the called party to answer. *...d*: intercepts any dtmf while waiting for the call to be answered and returns that value on the spot. This allows you to dial a 1-digit exit extension while waiting for the call to be answered... Thanks, Cristian ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
[Freeswitch-users] Newbie question: Why can't I dial?
Hello, everyone. I am new to Freeswitch, and telephony in general. I am trying to set up a Freeswitch system at work for a project, and I have hit a wall. I have a dedicated LD T1 from Qwest and a Sangoma A104 card. I believe I have openzap correctly installed in wanpipe mode. I am trying to bridge an incoming SIP call from an IP phone to an openzap channel without success. The Freeswitch log shows that dialing takes place, but the call never completes. The call log is here: http://pastebin.freeswitch.org/7805 The dialplan xml, openzap.conf, and openzap.conf.xml are here: http://pastebin.freeswitch.org/7806 Any help greatly appreciated. --Mark ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Newbie question: Why can't I dial?
On Tue, Mar 17, 2009 at 3:35 PM, Mark Thomas mtho...@themarketbuilder.com wrote: Hello, everyone. I am new to Freeswitch, and telephony in general. I am trying to set up a Freeswitch system at work for a project, and I have hit a wall. I have a dedicated LD T1 from Qwest and a Sangoma A104 card. I believe I have openzap correctly installed in wanpipe mode. I am trying to bridge an incoming SIP call from an IP phone to an openzap channel without success. The Freeswitch log shows that dialing takes place, but the call never completes. The call log is here: http://pastebin.freeswitch.org/7805 The dialplan xml, openzap.conf, and openzap.conf.xml are here: http://pastebin.freeswitch.org/7806 Any help greatly appreciated. Actually I found two things you need to change in the dialplan. What's happening is that you are telling openzap to dial out span 1, lowest channel number, but you don't actually give it a phone number to dial. Here's the current dialplan: extension name=outgoing-pri condition field=destination_number expression=^.+$ action application=bridge data=openzap/1/a/ /condition first, your expression is a bit dangerous. second, it doesn't actually capture the dialed number. I recommend that you do something like this: condition field=destination_number expression=^9(\d+)$ Note the leading nine, the \d+ and the parentheses. Essentially this regex says: Match any string of digits that begins with a 9 and has at least one additional digit. The parens will put the value of (\d+) into the variable $1. Your bridge then would be this: action application=bridge data=openzap/1/a/$1/ Now, reload your dialplan (press F6 or type reloadxml at the CLI) and dial out with a leading 9: 95551212 will send 5551212 to the telco. Try it and report back! -MC (IRC: mercutioviz) --Mark ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] echo cancellation on PRI cards
Steve Underwood wrote: [whopping big snip] The first bit of that's a tad patronising, isn't it, You are the one who started out being offensive. I'm sorry if you find disagreement offensive; you might not wish to read beyond this point if so. and, in the case of the decade-old Aculab cards which which I'm most familiar, is also untrue. I can't find too much about the old cards on the web now, but I found http://www.amdevcomm.com/voice-mail-products/voice-mail-components/dialogic/dti_sc.html which is pretty much a copy and paste from the old Dialogic web pages, and you'll see it says Cut through : Local echo cancellation permits 100% detection with a 4.5 dB return loss line. The Aculabs did the same thing for sure. They just couldn't work without cancellation. There were some very early Dialogic cards, using DTMF receiver chips and OKI ADPCM chips, and had no general purpose DSPs. They performed really badly because of the lack of cancellation, and were quickly replaced with cards that put the OKI ADPCM, DTMF anf echo cancellation algorithms into a Motorola 56k DSP chips. The same document, under the bit which you've quoted, says: (E-1) Digital trunks use separate transmit and receive paths to network. Performance dependent on far end handset's match to local analog loop. - i.e. the card does no echo cancellation. Aculab didn't even offer echo cancellation on Prosody for years and, when they did, it consumed prodigious amounts of DSP. Nonetheless, the DTMF detection worked perfectly well, even across 120 channels per 40MHz SHARC - there's just no way that those DSPs had enough horsepower to do echo cancellation across that many channels. An Asterisk box with an el-cheapo quad E1 card in that I use for TDM-SIP gatewaying detects DTMF perfectly well with no echo cancellation. You just don't need echo cancellation to achieve perfectly acceptable DTMF detection. ASR - yes, maybe, but surely only in the case where the application requires barge-in; even then, I'd be interested to see some test results, particuarly where the outbound prompt is killed the moment the ASR reports start of speech. I'm afraid that your original bald claim - that IVRs badly need echo cancellation is simply wrong, misleading and irresponsible: those believing it will end up spending large sums of money on technology which they probably do not need. --Dave ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] echo cancellation on PRI cards
I'm afraid that your original bald claim - that IVRs badly need echo cancellation is simply wrong, misleading and irresponsible: those believing it will end up spending large sums of money on technology which they probably do not need. Anybody with years, perhaps decades, of DSP programming experience plus testing in the real world - and all over the world - has my vote of confidence. Furthermore, when this person writes spandsp, makes it open source, and freely answers questions about it on public fora, I am inclined not only to believe him but to trust his judgment. Bottom line: thousands of people have chosen to heed Steve's advice. He is well-respected in many technical communities. His reputation is as solid as it gets. Do what Steve says is about the safest bet you will ever make in this business. -MC ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] Nibblebill - DB Error while updating cash!
Hi there, The updates to the DB are working, but the error is still being thrown. I will try and fix this tonight. Diego also reported the same issue last week, I just haven't gotten around to it. My apologies. The bug is filed, I'll close it out when it's fixed. - Darren _ From: JayaPrakash [mailto:jp.man...@gmail.com] Sent: Tuesday, March 17, 2009 1:48 PM To: freeswitch-users@lists.freeswitch.org Subject: [Freeswitch-users] Nibblebill - DB Error while updating cash! Hi All, I have installed nibblebill and it is able to bill the calls. However, it is giving following error in FreeSwitch server. 2009-03-17 23:17:19 [DEBUG] mod_nibblebill.c:283 bill_event() Doing update query [UPDATE accounts SET cash=cash-0.045767 WHERE id=1] 2009-03-17 23:17:19 [CRIT] mod_nibblebill.c:286 bill_event() DB Error while updating cash! Thanks Jayaprakash ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
[Freeswitch-users] TLS support in Debian build
I've just tried enabling TLS support, and the SIP profiles with TLS enabled in them won't load. According to the wiki, this is typically the result of missing headers during the build process, with TLS having not been included. However, on my Debian system, I have header files under /usr/include/openssl, which come from the libssl-dev package. Thus, SSL/TLS should have been compiled into FreeSWITCH unless there's something amiss with the Debian build process. Suggestions for tracking this down are welcome. There's no urgency: this is just for experimental purposes, after all. ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] TLS support in Debian build
if you installed the ssl devel stuff AFTER you configured you'll need to reconfigure. /b On Mar 17, 2009, at 8:46 PM, Jason White wrote: I've just tried enabling TLS support, and the SIP profiles with TLS enabled in them won't load. According to the wiki, this is typically the result of missing headers during the build process, with TLS having not been included. However, on my Debian system, I have header files under /usr/include/ openssl, which come from the libssl-dev package. Thus, SSL/TLS should have been compiled into FreeSWITCH unless there's something amiss with the Debian build process. Suggestions for tracking this down are welcome. There's no urgency: this is just for experimental purposes, after all. ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] echo cancellation on PRI cards
Steve Underwood wrote: David Knell wrote: Steve Underwood wrote: [whopping big snip] The first bit of that's a tad patronising, isn't it, You are the one who started out being offensive. I'm sorry if you find disagreement offensive; you might not wish to read beyond this point if so. and, in the case of the decade-old Aculab cards which which I'm most familiar, is also untrue. I can't find too much about the old cards on the web now, but I found http://www.amdevcomm.com/voice-mail-products/voice-mail-components/dialogic/dti_sc.html which is pretty much a copy and paste from the old Dialogic web pages, and you'll see it says Cut through : Local echo cancellation permits 100% detection with a 4.5 dB return loss line. The Aculabs did the same thing for sure. They just couldn't work without cancellation. There were some very early Dialogic cards, using DTMF receiver chips and OKI ADPCM chips, and had no general purpose DSPs. They performed really badly because of the lack of cancellation, and were quickly replaced with cards that put the OKI ADPCM, DTMF anf echo cancellation algorithms into a Motorola 56k DSP chips. The same document, under the bit which you've quoted, says: (E-1) Digital trunks use separate transmit and receive paths to network. Performance dependent on far end handset's match to local analog loop. - i.e. the card does no echo cancellation. Your messages are starting to looked deranged. Why would they only apply echo cancellation to T1s? Its a bizarre idea, and you must realise its wrong. Are you so desperate to support a wrong answer you'll clutch at straws? :-\ More insults. Answer me this: if there were echo cancellation in use, why would DTMF detection performance depend on the far-end handset's match to the loop? And the follow-up question (which you've already pretty much asked) - if the card doesn't echo cancel for E1s, why would it for T1s? As an aside, I'm not convinced that the document's not talking about return loss on the T1 line itself, the implication being that the T1 is being carried on a single pair, which makes the first sentence about E1s make a bit more sense. But that's just a guess. Aculab didn't even offer echo cancellation on Prosody for years and, when they did, it consumed prodigious amounts of DSP. Nonetheless, the DTMF detection worked perfectly well, even across 120 channels per 40MHz SHARC - there's just no way that those DSPs had enough horsepower to do echo cancellation across that manychannels. This page http://www.aculab.com/support/pdf_documents/v6_solaris/ting/pubdoc/an-dtmf-det-issues.html seems to support what you say. It also implies DTMF detection sucks unless you echo cancel. The statement If the outgoing signal is a tone of some sort (e.g. a 'beep'), ensure that its frequency is below 600Hz is telling you to keep your outgoing signal in the same frequency range as dial-tone where the dial-tone filter on the DTMF receiver will obviate the need for an echo canceller. They are freely admitting exactly what I have said. If you want a normal IVR with cut-through to work you better turn that echo canceller on. My only experience with Aculab was fitting a box designed by other people into a system. That one definitely echo cancelled, as it worked as well as the Dialogic based boxes we developed ourselves. That only holds true if your premise - that you need echo cancellation for good DTMF detection - is correct, which I don't believe it is. An Asterisk box with an el-cheapo quad E1 card in that I use for TDM-SIP gatewaying detects DTMF perfectly well with no echo cancellation. You must have very low standards for works well. Nothing like a good old ad hominem attack. Beats reasoned argument any day. You just don't need echo cancellation to achieve perfectly acceptable DTMF detection. Well, not if you expect people to wait for silence before entering DTMF, but who would tolerate that these days? Cut through has been de rigeur since the late 80s. Oh, for pity's sake, you get perfectly good cut through without echo cancellation. Humour me and draw a quick mental picture of the spectrum of a random bit of speech at -20dBm; now add tones at -10dBm and -7dBm. They stick out like a pair of sore thumbs. I'm sure it's quite possible to come up with a pathological case - e.g. cut-through against a 1kHz milliwatt tone, but that sort of thing just doesn't happen in real- life IVR applications. ASR - yes, maybe, but surely only in the case where the application requires barge-in; even then, I'd be interested to see some test results, particuarly where the outbound prompt is killed the moment the ASR reports start of speech. Doesn't any sane system expect barge in to be nearly as reliable as waiting for silence? Who would tolerate something that doesn't? It has been a standard expectation
Re: [Freeswitch-users] TLS support in Debian build
Brian West br...@freeswitch.org wrote: if you installed the ssl devel stuff AFTER you configured you'll need to reconfigure. I'm reasonably sure it was installed already, unless it was pulled in recently by a package upgrade. The configure script needs to look in /usr/include/openssl for the headers. I'll have a look at config.log and try to work out what it looked for and why it didn't find it. ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Re: [Freeswitch-users] echo cancellation on PRI cards
Sharing my humble experience: in Brazil we usually need echo cancellation to have reliable DTMF detection _and_ voice quality over E1 lines (be it on MFC/R2 - r2d - or ISDN PRI lines), either for sip/tdm gateway devices or IVR applications. Usually there's no need for echo cancellation on links from some Telcos, in some specific places. But we need it in the majority of cases, even when my box is just a gateway between legacy pbxes. This represents just a subset of the available E1s in the world and it's just a practical experience, but it's a fact for me. If I don't have a card with echo cancellation, I don't offer reliability to my customer; I've done that in the past and didn't work out. I'm not theoretically discussing anything, just sharing what I've been through in the last 4 or 5 years. 2009/3/17 David Knell d...@3c.co.uk Steve Underwood wrote: David Knell wrote: Steve Underwood wrote: [whopping big snip] The first bit of that's a tad patronising, isn't it, You are the one who started out being offensive. I'm sorry if you find disagreement offensive; you might not wish to read beyond this point if so. and, in the case of the decade-old Aculab cards which which I'm most familiar, is also untrue. I can't find too much about the old cards on the web now, but I found http://www.amdevcomm.com/voice-mail-products/voice-mail-components/dialogic/dti_sc.html which is pretty much a copy and paste from the old Dialogic web pages, and you'll see it says Cut through : Local echo cancellation permits 100% detection with a 4.5 dB return loss line. The Aculabs did the same thing for sure. They just couldn't work without cancellation. There were some very early Dialogic cards, using DTMF receiver chips and OKI ADPCM chips, and had no general purpose DSPs. They performed really badly because of the lack of cancellation, and were quickly replaced with cards that put the OKI ADPCM, DTMF anf echo cancellation algorithms into a Motorola 56k DSP chips. The same document, under the bit which you've quoted, says: (E-1) Digital trunks use separate transmit and receive paths to network. Performance dependent on far end handset's match to local analog loop. - i.e. the card does no echo cancellation. Your messages are starting to looked deranged. Why would they only apply echo cancellation to T1s? Its a bizarre idea, and you must realise its wrong. Are you so desperate to support a wrong answer you'll clutch at straws? :-\ More insults. Answer me this: if there were echo cancellation in use, why would DTMF detection performance depend on the far-end handset's match to the loop? And the follow-up question (which you've already pretty much asked) - if the card doesn't echo cancel for E1s, why would it for T1s? As an aside, I'm not convinced that the document's not talking about return loss on the T1 line itself, the implication being that the T1 is being carried on a single pair, which makes the first sentence about E1s make a bit more sense. But that's just a guess. Aculab didn't even offer echo cancellation on Prosody for years and, when they did, it consumed prodigious amounts of DSP. Nonetheless, the DTMF detection worked perfectly well, even across 120 channels per 40MHz SHARC - there's just no way that those DSPs had enough horsepower to do echo cancellation across that manychannels. This page http://www.aculab.com/support/pdf_documents/v6_solaris/ting/pubdoc/an-dtmf-det-issues.html seems to support what you say. It also implies DTMF detection sucks unless you echo cancel. The statement If the outgoing signal is a tone of some sort (e.g. a 'beep'), ensure that its frequency is below 600Hz is telling you to keep your outgoing signal in the same frequency range as dial-tone where the dial-tone filter on the DTMF receiver will obviate the need for an echo canceller. They are freely admitting exactly what I have said. If you want a normal IVR with cut-through to work you better turn that echo canceller on. My only experience with Aculab was fitting a box designed by other people into a system. That one definitely echo cancelled, as it worked as well as the Dialogic based boxes we developed ourselves. That only holds true if your premise - that you need echo cancellation for good DTMF detection - is correct, which I don't believe it is. An Asterisk box with an el-cheapo quad E1 card in that I use for TDM-SIP gatewaying detects DTMF perfectly well with no echo cancellation. You must have very low standards for works well. Nothing like a good old ad hominem attack. Beats reasoned argument any day. You just don't need echo cancellation to achieve perfectly acceptable DTMF detection. Well, not if you expect people to wait for silence before entering DTMF, but who would tolerate that these days? Cut through has been de rigeur since the late 80s. Oh, for pity's sake, you get
Re: [Freeswitch-users] Fifo feature request -- no caller disconnect after agent hangup
Hi Anthony, thanks for the reply. I've searched thru jira, and didn't find anything when searching for fifo that was recently updated or related, except http://jira.freeswitch.org/browse/MODAPP-189 and I'm not sure if this does what I need. Was this what you were referring to? Thanks. --matt 2009/3/17 Anthony Minessale anthony.miness...@gmail.com there is a patch in jira that will implement this feature about to be added 2009/3/17 Matthew Fong mattdf...@gmail.com I apologize if this is a double post to -dev. I'm not sure why I don't see my message appearing, so I'm going to try again in the -user list (first timer posting here ;). I have a situation where it would be useful for a caller not to be hungup, after finishing the fifo in execution (when the agent disconnects the call or the agent hangs-up). The caller is automatically hungup, in this situation. It would be preferable if the caller channel went further along the dial plan. I thought I might get lucky implementing this setting with hangup_after_bridge to false, but fifo does not utilize this variable. I tried looking thru the mod_fifo.c source, but my c skills are minimal. I also tried executing fifo in a lua app and setting setAutoHangup(false), but that also did not work. Any chance this could be done as a feature enhancement? Thanks. --matt ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_miness...@hotmail.com msn%3aanthony_miness...@hotmail.com GTALK/JABBER/PAYPAL:anthony.miness...@gmail.compaypal%3aanthony.miness...@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:8...@conference.freeswitch.org sip%3a...@conference.freeswitch.org iax:gu...@conference.freeswitch.org/888 googletalk:conf+...@conference.freeswitch.orggoogletalk%3aconf%2b...@conference.freeswitch.org pstn:213-799-1400 ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
