Re: [Freeswitch-users] Choosing a Codec.
On 12/23/2009 11:29 AM, David Knell wrote: On the other hand, a u-law WAV turned into L16 and then back to u-law to be sent down the line shouldn't suffer any alteration at all - if it does, the there's something wrong with the translation. The quality dropping over time is almost certainly down to something else. Vinuth -can you get a recording to compare with the original? A linear-ulaw-linear-ulaw-linear-ulaw chain *should* only loose quality on the first cycle. However: - Many ulaw implementation are buggy, because they are based on the same broken Sun code. People are gradually waking up and fixing this. The broken implementations can loose considerable quality on each cycle. - Anywhere people fiddle with gains, you will loose quality on each cycle. 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] Codecs and things
On 12/23/2009 04:55 AM, Ahmed Naji wrote: Hello people, Can someone please clear the following ambiguities with codecs: 1. Are we definitively able to run pass-through codecs (e.g. G.729) in Proxy Media mode, or does FS need to be running in bypass-media ? the Wiki is not clear in this regard 2. When an A-leg has negotiated a pass-through media codec, can the B-leg be transcoded into a non-pass-through codec, and vice-versa ? think A-leg incoming with a G.729 codec, and target for B-leg needs to be setup with a GSM-codec, say 3. Where in the developer's set of documentation are codecs discussed ? I would like to start porting some code of mine for G.729a/b/ab form a ti DSP platform to FS. FS lacking full G.729 support is proving quite a hindrance, and there is no clear direction from the dev community as to when the same will be available. Incidentally, any news on this effort ? where are we with code, and what's an ETA for a Beta ? 4. On the same lines as (3) above, there is a codec dev template in the source tree. Again, where can I find documentation relating to this ? the template has hardly any docs at all. Best regards and warm wishes for a Merry Christmas and a great New Year to one and all. The G.729 codec for FS is in testing, and should be out so. If you really want to implement your own, TI DSP code is unlikely to be a good starting point. I assume that code is fixed point. You really need a floating point codec to get any decent speed on a PC. Pentiums and Athlons lack saturating arithmetic (MMX actually has partial saturating arithmetic, but it isn't much use for anything but image processing), so a fixed point implementation ends up very slow. 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] Which ATAs to chose for modem connections?
On 12/14/2009 08:05 PM, Peter P GMX wrote: We currently use Patton gateways SN4116 for attaching fax and modem equipment to our Freeswitch system. Freeswitch is in bypass-media-mode, so media flow goes the following way: Modem/Fax = Patton_SN4116 = Patton_SN46XX =PSTN/ISDN However modem connections are not very reliable. We exchanged the SN4118 against a Fritzbox ATA and the situation improves. However Fritzboxes do not deliver the number of ports we need. What is your experience? Which ATA is the best choice for modem connections? Best regards Peter Your improvement is probably more due to luck than engineering. Turning off any dynamic jitter buffering, and making sure you use only A-law or u-law, will reduce the failures. the only thing that will give reliable results for modems is a managed, absolutely lossless, packet path, and terminal equipment which does doesn't slip data samples to allow for mismatched sampling clocks. Good luck finding those. 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] What are the solutions for G729 support ?
On 12/14/2009 11:19 PM, Anthony Minessale wrote: Software G729 will be available by the end of the month. As for, G723 we are not currently working on it. There is a legit option for G.723.1 - the Digium TC400B card. Its supported by Freeswitch, thanks to Moises. On Mon, Dec 14, 2009 at 6:45 AM, Oscav os...@hotmail.fr mailto:os...@hotmail.fr wrote: Hi, What are the solutions to support the G729/G723 codec within FreeSwitch ? 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] Hardware echo cancellation.
On 11/19/2009 11:54 PM, David Knell wrote: Hi Brian, It just doesn't belong in user space or kernel space in the machine for true performance you should do it in hardware... I'm pretty sure the poor box would die if you tried it on 32 E1's at the same time. Disagree somewhat. The challenge that echo cancellers further from the hardware face is having some idea of the size of the buffers between the canceller and the wire; provided that this is known, or is small in comparison to the canceller's tail length, it can, in principle, go anywhere. All other things being equal, the right place for a software EC is in user space: can be done in a cross-platform way, can use FPU/MMX/SSE without guilt and voodoo, etc. And there is no reason why the same algorithm would perform differently if implemented in hardware or on the host CPU. And the OP only needed four E1s.. The audio path between kernel and user space is not stable with any current PC based telephony system. At some point in the day the odd chunk of data is lost here and there, whether you use asterisk, callweaver, yate or FS, with dahdi or sangoma. This is the key problem for user space echo cancellation. When the path hiccups, the EC goes crazy, and howls. So far kernel space EC has been the only way to keep the path length rock solid. There is an Intel development platform which tries to do EC with OSLEC in user space. That's the only delivered system I know that tries to do this. Its very quirky. 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] Hardware echo cancellation.
On 11/20/2009 05:15 AM, David Knell wrote: On Fri, 2009-11-20 at 00:15 +0800, Steve Underwood wrote: The audio path between kernel and user space is not stable with any current PC based telephony system. At some point in the day the odd chunk of data is lost here and there, whether you use asterisk, callweaver, yate or FS, with dahdi or sangoma. This is the key problem for user space echo cancellation. When the path hiccups, the EC goes crazy, and howls. So far kernel space EC has been the only way to keep the path length rock solid. Why do you think this is? Getting data from kernel space to user space isn't something which it's difficult to do reliably: the disk system manages it. Even if data is being lost, buffer overruns can be dealt with by using bigger buffers, or timestamping blocks of data on their way in so that missing blocks can be detected. Disk isn't audio. Audio is real time, and real time constraints are a harsh mistress. Big buffers are out of the question, due to latency. Some mitigation could be provided if you can detect where missing chunks occur and their exact size. Right now, the I/O schemes do not provide for that, and incorporating support would be tough. You'd need some out of band indication, like an ioctl or something, which would lead to more user space/kernel space exchanges, further increasing the problem. 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] Build FS without spandsp or libtiff
On 11/18/2009 04:19 AM, Kristian Kielhofner wrote: Ah yes, using spandsp instead of libvoipcodecs. I'm not going to question the wisdom of that move but it appears that spandsp (as-is) doesn't cross compile properly (make_at_dictionary is built using the cross compiler and can't run on the host). Once that error is fixed (I hacked it for now) it still bombs as shown here: http://pastebin.freeswitch.org/11149 spandsp + libtiff are almost certainly *much* larger than libvoipcodecs but if that means that I can also build mod_fax I guess it's worth it ;). On Tue, Nov 17, 2009 at 2:37 PM, Brian Westbr...@freeswitch.org wrote: OH you need spandsp for VoipCodecs. No way around that one. /b Over time more and more of spandsp will be used by Freeswitch, so its most certainly an integral part of FS going forward. In a few months it might be possible to not use libTIFF, depending how things go with some developments. spandsp builds OK for many cross compile setups. make_at_dictionary and make_modem_filters should be built using the host compiler, not the target compiler. This seems to work in the places I've tried it. The problem in your pastebin log seems to be a broken C99 environment, and not a spandsp problem. 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] wav files compression
On 10/04/2009 01:07 AM, Diego Viola wrote: Why is not recommended? Square peg. Round hole. On Sat, Oct 3, 2009 at 2:52 PM, Brian West br...@freeswitch.org mailto:br...@freeswitch.org wrote: MP3 is NOT recommend and if WAV files are too large you can mosey on down to the local Best Buy and snag 1.5TB of disk for like $119 dollars. Disk is cheap. /b On Oct 3, 2009, at 1:44 AM, Keith Wood wrote: I am working on an implementation for managing thousands of IVR within an organization. Right now, I am storing all audio files in wav format, but it quickly become unmanagable because the size of these wav files ( 8 bits mono ) quickly consuming a lot of the disk space. Is there anyway I can store those audio files and still have high quality audio for IVR? I know mp3 is smaller but freeswitch does not support it. any ideas? keith 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] wav files compression
On 10/04/2009 02:17 AM, Diego Viola wrote: I see, does Ogg/Vorbis have the same problem? Yep. Anything designed for general purpose audio is going to be a poor choice when you want to achieve compact storage of narrowband voice. Diego On Sat, Oct 3, 2009 at 5:47 PM, Steve Underwood ste...@coppice.org mailto:ste...@coppice.org wrote: On 10/04/2009 01:07 AM, Diego Viola wrote: Why is not recommended? Square peg. Round hole. On Sat, Oct 3, 2009 at 2:52 PM, Brian West br...@freeswitch.org mailto:br...@freeswitch.org mailto:br...@freeswitch.org mailto:br...@freeswitch.org wrote: MP3 is NOT recommend and if WAV files are too large you can mosey on down to the local Best Buy and snag 1.5TB of disk for like $119 dollars. Disk is cheap. /b On Oct 3, 2009, at 1:44 AM, Keith Wood wrote: I am working on an implementation for managing thousands of IVR within an organization. Right now, I am storing all audio files in wav format, but it quickly become unmanagable because the size of these wav files ( 8 bits mono ) quickly consuming a lot of the disk space. Is there anyway I can store those audio files and still have high quality audio for IVR? I know mp3 is smaller but freeswitch does not support it. any ideas? 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] SILK speech codec, Celt, FreeSWITCH
On 09/29/2009 09:05 AM, Jason White wrote: Brian Westbr...@freeswitch.org wrote: SILK will NEVER take off if they don't stop jerking developers around. I have a silk binary but its 32bit only... You CAN NOT link a 32bit .a file into a 64bit .so just won't work. And I emailed about this fact and I got brushed off .. it takes only a few seconds to compile a 64bit version yet they seem to not be interested. The submission to the IETF changes this situation in that, subject to patent issues, someone could write their own implementation. CELT will win this battle. Its Open it works NOW. I hope Celt succeeds; I like its audio quality. Its early days for the IETF work, but its possible SILK and CELT might merge into one codec. The authors are certainly on amicable terms right now. The snag with IETF stuff is it moves like molasses, so its hard to say whether anything will happen on a sane timescale. 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] SILK speech codec, Celt, FreeSWITCH
On 09/29/2009 09:31 AM, Brian West wrote: I'm not one that usually likes to sit around waiting on stuff... but I waited on SILK and was let down. /b On Sep 28, 2009, at 8:22 PM, Steve Underwood wrote: Its early days for the IETF work, but its possible SILK and CELT might merge into one codec. The authors are certainly on amicable terms right now. The snag with IETF stuff is it moves like molasses, so its hard to say whether anything will happen on a sane timescale. Steve Well, if they aim to keep to their original plan, ahead of anything interesting the IETF might do, they are starting to look a little tardy. 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] faxrx error 13 Unexpected message received
On 09/17/2009 12:08 AM, Travis Stutsman wrote: In my attempts to receive a fax from a PSTN fax machine, the transaction fails with error code 13 Unexpected message received. Verbose logging is on for mod_fax. Here is an exerpt: # 2009-09-15 10:41:39.215123 [DEBUG] mod_fax.c:137 FLOW T.30 Rx: CFR with final frame tag 2009-09-15 10:41:39.215123 [DEBUG] mod_fax.c:137 FLOW T.30 Rx: ff 13 84 2009-09-15 10:41:39.215123 [DEBUG] mod_fax.c:137 FLOW T.30 In state 12 2009-09-15 10:41:39.215123 [DEBUG] mod_fax.c:137 FLOW T.30 Unexpected CFR received in state 12 .. == 2009-09-15 10:41:41.402707 [DEBUG] mod_fax.c:180 Fax processing not successful - result (13) Unexpected message received. 2009-09-15 10:41:41.402707 [DEBUG] mod_fax.c:185 Remote station id: ** 2009-09-15 10:41:41.402707 [DEBUG] mod_fax.c:186 Local station id: SpanDSP Fax Ident 2009-09-15 10:41:41.402707 [DEBUG] mod_fax.c:187 Pages transferred: 0 2009-09-15 10:41:41.402707 [DEBUG] mod_fax.c:189 Total fax pages: 0 2009-09-15 10:41:41.402707 [DEBUG] mod_fax.c:190 Image resolution: 8031x3850 2009-09-15 10:41:41.402707 [DEBUG] mod_fax.c:191 Transfer Rate: 14400 2009-09-15 10:41:41.402707 [DEBUG] mod_fax.c:193 ECM status on 2009-09-15 10:41:41.402707 [DEBUG] mod_fax.c:194 remote country: 2009-09-15 10:41:41.402707 [DEBUG] mod_fax.c:195 remote vendor: 2009-09-15 10:41:41.402707 [DEBUG] mod_fax.c:196 remote model: 2009-09-15 10:41:41.402707 [DEBUG] mod_fax.c:198 == # I have successfully received a fax from faxzero.com on this installation, as have I successfully sent a fax from freeswitch to the PSTN fax machine in question. I've been digging, but there doesn't seem to be a whole lot of information on faxing. I guess I could use a bit of direction. Any input is much appreciated. You seem to have chopped out all the interesting parts of that log. A full log might say something interesting. 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] faxrx error 13 Unexpected message received
Hi Travis, That's a pretty weird call. It looks like you have a long delayed echo. See below. On 09/17/2009 01:21 AM, Travis Stutsman wrote: Alrighty. Here is mod_fax from beginning to end. # 2009-09-15 10:41:26.433382 [DEBUG] mod_fax.c:591 Raw read codec activation Success L16 2 2009-09-15 10:41:26.433382 [DEBUG] mod_fax.c:607 Raw write codec activation Success L16 2009-09-15 10:41:26.433382 [DEBUG] switch_channel.c:182 sofia/external/***...@**.***.**.*** receive message [AUDIO_SYNC] 2009-09-15 10:41:26.464633 [DEBUG] switch_core_io.c:232 sofia/external/***...@**.***.**.*** receive message [TRANSCODING_NECESSARY] 2009-09-15 10:41:27.589676 [DEBUG] mod_fax.c:137 FLOW T.30 HDLC signal status is Carrier up (-2) in state 1 2009-09-15 10:41:27.761558 [DEBUG] mod_fax.c:137 FLOW T.30 HDLC signal status is Carrier down (-1) in state 1 2009-09-15 10:41:27.792809 [DEBUG] mod_fax.c:137 FLOW T.30 HDLC signal status is Carrier up (-2) in state 1 2009-09-15 10:41:27.870937 [DEBUG] mod_fax.c:137 FLOW T.30 HDLC signal status is Abort (-8) in state 1 2009-09-15 10:41:28.308454 [DEBUG] mod_fax.c:137 FLOW T.30 HDLC signal status is Abort (-8) in state 1 2009-09-15 10:41:28.355331 [DEBUG] mod_fax.c:137 FLOW T.30 HDLC signal status is Abort (-8) in state 1 2009-09-15 10:41:28.370956 [DEBUG] mod_fax.c:137 FLOW T.30 HDLC signal status is Abort (-8) in state 1 2009-09-15 10:41:28.824099 [DEBUG] mod_fax.c:137 FLOW T.30 HDLC signal status is Abort (-8) in state 1 2009-09-15 10:41:29.27231 [DEBUG] mod_fax.c:137 FLOW T.30 HDLC signal status is Abort (-8) in state 1 2009-09-15 10:41:29.261615 [DEBUG] mod_fax.c:137 FLOW T.30 HDLC signal status is Abort (-8) in state 1 2009-09-15 10:41:29.511625 [DEBUG] mod_fax.c:137 FLOW T.30 Send complete in phase T30_PHASE_A_CED, state 1 2009-09-15 10:41:29.511625 [DEBUG] mod_fax.c:137 FLOW T.30 Starting answer mode 2009-09-15 10:41:29.511625 [DEBUG] mod_fax.c:137 FLOW T.30 Changing from phase T30_PHASE_A_CED to T30_PHASE_B_TX 2009-09-15 10:41:29.511625 [DEBUG] mod_fax.c:137 FLOW FAX Set rx type 0 2009-09-15 10:41:29.511625 [DEBUG] mod_fax.c:137 FLOW FAX Set tx type 4 2009-09-15 10:41:29.511625 [DEBUG] mod_fax.c:137 FLOW T.30 Start T2 2009-09-15 10:41:29.511625 [DEBUG] mod_fax.c:137 FLOW T.30 Changing from state 1 to 17 2009-09-15 10:41:29.511625 [DEBUG] mod_fax.c:137 FLOW T.30 Sending ident 'SpanDSP Fax Ident' 2009-09-15 10:41:29.511625 [DEBUG] mod_fax.c:137 FLOW T.30 Tx: CSI without final frame tag 2009-09-15 10:41:29.511625 [DEBUG] mod_fax.c:137 FLOW T.30 Tx: ff 03 40 74 6e 65 64 49 20 78 61 46 20 50 53 44 6e 61 70 53 20 20 20 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 Send complete in phase T30_PHASE_B_TX, state 17 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 DIS: 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 ...0= Store and forward Internet fax (T.37): Not set 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 .0..= Real-time Internet fax (T.38): Not set 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 0...= 3G mobile network: Not set 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 ..0. = V.8 capabilities: Not set 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 .0.. = Preferred octets: 256 octets 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 ...0= Ready to transmit a fax document (polling): Not set 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 ..1.= Can receive fax: Set 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 ..10 11..= Supported data signalling rates: V.27 ter, V.29, and V.17 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 .1.. = R8x7.7lines/mm and/or 200x200pels/25.4mm: Set 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 1... = 2-D coding: Set 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 ..10= Recording width: 215mm +- 1%, 255mm +- 1% and 303mm +- 1% 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 10..= Recording length: Unlimited 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 .111 = Receiver's minimum scan line time: 0ms at 3.85 l/mm; T7.7 = T3.85 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 1... = Extension indicator: Set 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 ..0.= Compressed/uncompressed mode: Compressed 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 .1..= Error correction mode (ECM): ECM 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 .1.. = T.6 coding: Set 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 1... = Extension indicator: Set 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137 FLOW T.30 ...0= Field not valid supported: Not set 2009-09-15 10:41:31.89811 [DEBUG] mod_fax.c:137
[Freeswitch-users] T.38 with V.34 support
Hi, Does anyone have access to a system that supports T.38 FAXing at V.34 rates. These things seem to be as rare as bugless software. 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] FreeSWITCH HA + Loadbalancing
This sounds like so many redundancy projects that will probably offer nothing in the real world. On 08/30/2009 05:52 AM, Pete Mueller wrote: I guess I should also mention that Xen is a side-project. When considering this issue for an existing production systems, we chose to put as much HA into hardware as we can. We are not concerned with FS crashing, as so far we've never seen that happen (except when our module caused it :) So for each of our systems: - We have dual NIC cards (onboad NIC + PCI card) both bridged together in case one fails NICs hardly ever fail. Its the wiring which is the vulnerable area. How independent can you make the two wiring paths, when they come from the same box? - We have redundant power supplies. Even with a good UPS, power fails more often than a high quality power supply. Just how independent are the two power sources feeding your two power supplies? Do you have two completely independent UPS sets? Do you have spacially diverse wiring from them? - We use Mirrored Solid State Disks for local storage (far better MTBF than HDD, a lot faster too) My experience so far is that SSD reliability is very poor, with entire drives disappearing, rather than just getting the odd bad sector. I guess to balance this, hard disk drive reliability seems to have plummeted in the last year or so, after several good years. - All but OS and speed-critical data is stored on a NAS device NAS == more wiring. More wiring == more vulnerabilities. Are you sure your setup is a win? NAS tends to help keep the data secure, but it isn't good for reliable access to that data. - We have redundant DBs with Memcache infront for speed At the same time we chose to use COTS hardware (SuperMicro chassis/MoBo) rather than the big-boys like IBM or Dell. This kept the overall cost per machine low. Initially some were concerned that not having a name like IBM on our servers would be concerning to some potential clients. The solution was to pay a company to deisgn and build a custom face plate for the SuperMicro boxes. Which oddly looks more impressive to clients that a rack full of IBM faceplates. It was suprisingly low cost for the faceplates too. Some years ago we made an entire custom chassis for off the shelf boards. The quotes for fabricating that in small numbers were all over the place, but we ended with a good quality chassis at low cost. Most off the shelf rack mount enclosures are really pricy, so it isn't that hard to match their price with a custom build. We ended up with a better design (at least for our purposes) that cost us no more. It can really make your stuff stand out. A simple respray of the front panel can achieve a distinctive look at low cost too. :-) For scalability, OpenSIPS was our choice. There's a very nice tutorial on their website on how to configure Load Balancing. 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] mod_fax not working
Hi Mathieu,
On 08/28/2009 05:15 PM, Mathieu Parent wrote:
Hi,
I just started testing Freeswitch, this works well. This is powerfull
and easy to administrate.
I just have one problem and one request. The request is BOUNTY-5: IMAP
integration of voicemail (I will try to propose a patch if this is
within my competencies)
The problem is with mod_fax not receiving any fax.
Relevant extension is:
extension name=fax2mail
condition field=destination_number expression=^(9998)$
action application=set data=fax_verbose=true/
action application=set data=fax_disable_v17=false/
action application=set data=fax_use_ecm=true/
action application=answer /
action application=playback data=silence_stream://2000/
action application=rxfax data=/tmp/${uuid}.rxfax.tiff/
action application=hangup/
/condition
/extension
Test case is a 1-page fax coming from a Minolta printer connected to a
Cisco VG248 (via RJ11). The VG248 port is registred on a Cisco Call
Manager communicating with FS via a SIP trunk.
Log is attached:
- first try from 11:04:05 to 11:04:31
- 2nd try from 11:04:57 to 11:05:22
- 3rd try from 11:05:48 to 11:06:08
Do you need more information?
Regards
Mathieu Parent
The log shows the same thing happening every time. A bad CRC from the
far end, followed by a good DCS frame followed by what seems to be
rubbish. I think I'd need an audio log from one of these calls to figure
out any more.
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] Better results from mod_vmd
On 08/20/2009 05:22 AM, Michael Collins wrote: There is no noise on those 3 beeps. In fact, for something that's been through ulaw/alaw compression those beeps are very clean. They are quite short, though. Heck yeah they're short! Steve, in your experience is there a practical way to detect a beep that short without chewing up system resources or having lots of false positives? -MC The tone samples I just looked at are about 130ms long. The problem is the detector is trying to be a very open ended detector of anything narrowband enough to be a single tone, and of any duration beyond some small minimum. Its difficult to make such a thing voice immune unless you can also count on a very large signal to noise ratio. With a digital trunk you can probably rely on a large SNR, but what happens when people use analogue lines? There is a reason why DTMF detectors try hard to work down to about 10dB SNR. :-) 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] Better results from mod_vmd
On 08/18/2009 05:15 AM, Eric des Courtis wrote: Matt, Okay the good news is vmd should be able to handle these cases. The bad news is for whatever reason they are not getting detected at the moment. vmd-not-panasonic-home-ans.wav is a sine at ~1400Hz you can change MAX_FREQ to 1450 and play with MIN_AMPL if that still doesn't help. The following seem to use the same beep: vmd-not-tmobile.wav is a sine at ~750Hz but has a bit of noise vmd-not-sprint.wav is a sine at ~750Hz but has a bit of noise vmd-not-sprint.wav is a sine at ~750Hz but has a bit of noise You can try to play with these values: POINTS 32 VALID 22 MAX_CHIRP 22 If that doesn't work let me know I will try to improve the algorithm to detect the providers. There is no noise on those 3 beeps. In fact, for something that's been through ulaw/alaw compression those beeps are very clean. They are quite short, though. 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] FS beats Aculab Prosody S on subjective test on lay users for conference quality
David Knell wrote: On Thu, 2009-07-30 at 09:21 +0800, Steve Underwood wrote: High quality conferencing is a difficult task, and still a research topic. No two conferencing systems perform alike. The interesting thing about this and other reports is that the conferencing in Freeswitch is not very clever right now, yet people are already saying it beats various other offerings, including long time commercial offerings. It may well be that a simplistic implementation (noise gate, add them all up) is all that's required for dealing with small groups or, more generally, groups of any size which have a small number of active speakers at any one time: it's predictable and unlikely to introduce unpleasant side effects. This is one of those situations where when you've experienced something better you make that your baseline for acceptability. I would consider a noise gate horribly crude, and VAD as the minimum for acceptable performance. If you've only used a noise gate you get used to it. If you're not sufficiently versed in the art you may well think nothing better is even possible. The fact that even the simple scheme, with noise gating, in Freeswitch is getting high praise, is pretty damning of mature commercial products. 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] voip-voip echo cancel possible
Kristian Kielhofner wrote: While it might not be feasible it may be possible (and I don't see why not). There are many, many commercial devices that claim to do this. Then again there are just as many devices that claim to do everything and anything... People tell me commercial offerings claim to do this, but nobody ever points me at an example. There are two key issues that stop EC over VoIP working. 1. There is no way you will ever get EC to work over a low bit rate codec. Even if you use nothing but G.711 on your local hop, you have no idea what transcoding may occur downstream. So, in the general case it won't work however you configure your setup. 2. EC is an adaptive process, requiring is a stable loop length. As soon as a jitter buffer somewhere makes an adjustment the EC's tunning will blow up. If you are lucky it might eventually retune, but in the meantime the pain in your ear could be quite severe. :-) 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] FS beats Aculab Prosody S on subjective test on lay users for conference quality
David Knell wrote: Hi Fernando, Greetings from Rio..! It'd be interesting to understand more about these results - roughly speaking, two conferencing systems using the same codecs, etc., ought to perform pretty much identically, particularly with just a few callers. I'd be interested to see a network packet dump of a conference on each of the machines, if you're able to make one available. High quality conferencing is a difficult task, and still a research topic. No two conferencing systems perform alike. The interesting thing about this and other reports is that the conferencing in Freeswitch is not very clever right now, yet people are already saying it beats various other offerings, including long time commercial offerings. 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] freeswitch on blackfin
mark morreny wrote: Hi, Have anyone tried getting freeswitch to work on uclinux/blackfin platform? Is there any info out there on how that can be done? Thanks for any info. Look in the mailing list archive. This question comes up regularly. 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] Dialogic cards
Being now a mashup of several CTI companies, there are now a number of disparate things called Dialogic cards. Some, like the cards previously known as Prince. er, Eicon are perfectly supportable. The old Dialogic cards, like the D300 series, are not duplex to and from the host. They are only duplex across the mezzanine bus. There's nothing you can do with them. Steve Anthony Minessale wrote: Dialogic is coming to ClueCon this year (this aug 4th) and they are sponsoring the conference. I can discuss the possibility of supporting their cards at that time. On Sun, Jul 12, 2009 at 11:07 PM, Tim Uckun timuc...@gmail.com mailto:timuc...@gmail.com wrote: We have some older dialogic cards (D300 series E1 cards) and I am wondering if freeswitch can support these cards. Thanks. ___ 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] Dialogic cards
Tim Uckun wrote: We have some older dialogic cards (D300 series E1 cards) and I am wondering if freeswitch can support these cards. Oh, I like the easy questions. No. It lacks the hardware features to do anything useful with Freeswitch, or Asterisk, or Callweaver, or Yate, or anything else that expects to do two way telephony through the host CPU. 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] Language Handling: call for assistance
Michael Collins wrote:
On Thu, Jul 2, 2009 at 3:01 AM, Igor Neves i...@3gnt.net
mailto:i...@3gnt.net wrote:
Hi,
Michael Collins wrote:
Hello all!
There's been some discussion lately on how to handle multiple
languages, specifically with the *say* application. We would like
some input from the community on how to handle multiple languages
and sound files. Anthony notes that the say application needs to
build the path to the sound files by using the ${sound_prefix}
and ${lang} variables. Some have asked about countries or
language variants, like European Portugese vs. Brazilian
Portugese. These are good questions.
What it's the problem about Portuguese VS Brazilian?
Can't we just use PT_pt and PT_br in ${lang}, just like a lot
of others softwares do?
What about ${sound_prefix} = ${lang}, since ${lang} should always
be unique, and you make the path's automatically language organized?
This is reasonable to me, but it would be nice to have a consensus,
just to be sure.
From the community we need input. If you have experience with
multiple languages in a telephony environment then please give us
your suggestions. How would you like to see the say application
handle various languages and dialects? Please give us your
helpful suggestions.
Thanks,
Michael
Sorry if I miss understood something.
Cheers,
Believe, the moment we put this into place we will have someone
purporting to be an expert offering a completely new solution. That's
why we asked for input now, before Tony spends a lot of time working
on it.
-MC
The PT_pt format is for written languages, rather than spoken languages.
There is often a difference.
The SSML 1.1 spec references http://www.ietf.org/rfc/bcp/bcp47.txt as a
definition of how to identify a language and accent for speech. I'm not
clear if its really works, though.
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] Language Handling: call for assistance
Raul Fragoso wrote:
On Fri, 2009-07-03 at 01:29 +0800, Steve Underwood wrote:
Michael Collins wrote:
On Thu, Jul 2, 2009 at 3:01 AM, Igor Neves i...@3gnt.net
mailto:i...@3gnt.net wrote:
Hi,
Michael Collins wrote:
Hello all!
There's been some discussion lately on how to handle multiple
languages, specifically with the *say* application. We would like
some input from the community on how to handle multiple languages
and sound files. Anthony notes that the say application needs to
build the path to the sound files by using the ${sound_prefix}
and ${lang} variables. Some have asked about countries or
language variants, like European Portugese vs. Brazilian
Portugese. These are good questions.
What it's the problem about Portuguese VS Brazilian?
Can't we just use PT_pt and PT_br in ${lang}, just like a lot
of others softwares do?
What about ${sound_prefix} = ${lang}, since ${lang} should always
be unique, and you make the path's automatically language organized?
This is reasonable to me, but it would be nice to have a consensus,
just to be sure.
From the community we need input. If you have experience with
multiple languages in a telephony environment then please give us
your suggestions. How would you like to see the say application
handle various languages and dialects? Please give us your
helpful suggestions.
Thanks,
Michael
Sorry if I miss understood something.
Cheers,
Believe, the moment we put this into place we will have someone
purporting to be an expert offering a completely new solution. That's
why we asked for input now, before Tony spends a lot of time working
on it.
-MC
The PT_pt format is for written languages, rather than spoken languages.
There is often a difference.
The SSML 1.1 spec references http://www.ietf.org/rfc/bcp/bcp47.txt as a
definition of how to identify a language and accent for speech. I'm not
clear if its really works, though.
Steve
I think that would be overkill. The usual way of using i.e. pt-br (two
letters for the main language, dash and then two more letters for the
dialect/variation) would be enough.
If by the usual way you mean the standard 2 + 2 letter codes we are
used to on computers, that just doesn't work. As I said before, those
are for written languages, not spoken languages. There are no standard
codes for many spoken languages. For example, the standard codes for
Chinese are zh_cn for mainland China, zh_tw for Taiwan, zh_hk for Hong
Kong. However, in GuangDong you will probably want to offer Cantonese as
well as Mandarin voice prompts, so you will want a zh_gd, or something,
which you won't find among the standard 2 + 2 letter codes. That's why
the SSML people had a hard time coming up with a language scheme, and
SSML 1.0 didn't even reference one. The more you look around the world,
the most complex the issue of language variants becomes. If you don't
face that at the beginning it just gets messier later on.
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] Is there any license G729?
Edmar Cruz wrote: So what codec supports mobile phones? The main codecs used by mobile phones are: GSM FRThe original GSM code, largely replaced by later codecs (some VoIP stuff uses this) GSM HRThe half rate codec for GSM GSM EFR A later improved full rate codec that largely replaced GSM FR on GSM networks AMR-NBThe current start of the art narrowband codec for GSM and UMTS networks AMR-WBThe wide band codec for UMTS, though most networks seem to block it EVRCThe main codec for the CDMA networks Each of these codecs sounds pretty respectable, and G.729 sounds pretty respectable. However, if you transcode from one to another the result can be pretty bad. 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] Is there any license G729?
Nyamul Hassan wrote: Hi, I just noted Micheal Collins mention Enjoy lower quality G.729 calls. By lower quality do you mean G.729 in TC400B is lower in quality compared to software compression? Or is that comparing G.729 with G.711? I think he is just saddened by the way people tolerant crappy quality, and how slow the takeup of wideband voice has been. The TC400B doesn't do G.729. It does G.729A, which is significantly lower in quality. However, G.729A is what almost all equipment that vaguely says G.729 actually implements. Its lousy, but few people care. The TC400B works as well or as badly as anything else. 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] Is there any license G729?
Brian West wrote: Cellphones have really lowered everyones expectations of what quality is. I think if each of us in the US could stab our Cellphone providers in the neck and get away with it.. I know I would... YES ATT I'm talking about your sorry excuse for service The 3G cellular standards have wideband features (that's what AMR-WB was developed for), but few (maybe no) operators enable them. I assume all UMTS phones actually support wideband, but unless the network is prepared to accept negotiation for it, phone support isn't much use. The networks would rather push proven flops like video calls. 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] Is there any license G729?
Video calls are a really really bad idea. People who think otherwise really haven't thought about it at all. They are available here, and people desperately don't want them to be. Brian West wrote: Video calls would be great if any network would actually SUPPORT IT! (speaking US only) /b On Jun 29, 2009, at 12:11 PM, Steve Underwood wrote: The 3G cellular standards have wideband features (that's what AMR-WB was developed for), but few (maybe no) operators enable them. I assume all UMTS phones actually support wideband, but unless the network is prepared to accept negotiation for it, phone support isn't much use. The networks would rather push proven flops like video calls. Steve 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] Open source Java based inbound event socket library available
paul.degt wrote: Yes, that's one of the reasons. Another point is that GPL v.3 is defined more clearly from legal perspective, at least from our legal adviser point of view. While the legal status of MPL is widely considered to be vague, is GPL 3 any better? GPL 2 is pretty sound, and has stood the test of time. However a number of large companies have banned their employees from working on anything involving GPL 3 code, because of legal uncertainties, especially with regard to patents. 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] MPL and licensing
David Sugar wrote: There are no legal uncertainties with respect to patents in GPL v3. You cannot assert them in code you license under it. There was ambiguities in GPL v2 in this respect which some companies liked. I prefer to deal with honest companies rather than those that are anti-social or might choose legal ambush later, so any that feel they cannot accept the greater legal certainty of GPL v3 in this respect are probably companies that I would not choose to have any kind of relationship with anyway ;). If that is true, why are there some notes on the FSF web site trying to clarify what is not well stated about patents in GPL3 itself? You are fooling yourself if you think lawyers are generally comfortable with GPL3. I'm talking about lawyers who were perfectly happy with GPL2. I know of some cases where large companies have paid outsourced developers to contribute to open source projects, specifically so there are no possible legal ramifications related to their own patent portfolio. That's a really messed up licence. 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] Web page thoughts
Anthony Minessale wrote: One important thing is that if we go around following everything everybody else says we become a follower in our field. I have had numerous people tell me what to do in the code, what to name things, what to eat for breakfast. Plain and simple, I will choose what to put on our website, when to put it there and what it says. You are welcome to your own opinion. I have no problem with it. If you say something I like we may even listen. Feel free to comment on anything else you find when browsing our community. BUT, If you have no sense of humor, you will not make it far in the open source telecom industry. If you want a more professional looking site, we do have some guys in suits on our FreeSWITCH Solutions site. http://www.freeswitchsolutions.com/ The main reason www.freeswitchsolutions.com http://www.freeswitchsolutions.com/ looks more professional that www.freeswitch.org is not the content of the pictures but their size. The pictures at the top of the www.freeswitch.org are too big and in your face. They completely dominate the screen when it appears. 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] Can Freeswitch + LAMP run on 128MB RAM?
Fred-145 wrote: Hello Atcom's IP01 unit (www.atcom.cn) can be expanded to have 128MB RAM and 1GB NAND flash. Before I go ahead and check, would someone know if a minimal Linux + LAMP server* + Freeswitch can run OK with this amount of memory? Thank you. * I think I'll trade MySQL with Firebird, to avoid buying a license for my commercial application I don't know any free telephony project which will build and run on an IP01, except the ones which have specifically been adapted for the Blackfin. If you look at www.rowetel.com or www.astfin.org you will find versions of Asterisk which have been adapted for the IP01. Nobody has yet adapted Freeswitch for the Blackfin, and they probably won't. The Blackfin lacks an MMU and cannot run Linux - it runs uCLinux, which is a cut down Linux for machines of this type. It is quite troublesome to get memory management to behave sanely on a machine without an MMU. The Asterisk adaptions for the Blackfin have problems with this too, but if you don't let the memory become too fragmented they work OK. The lack of floating point hardware in the Blackfin, and a number of other embedded processors, can also cause performance issues. The core functions of Freeswitch work reasonably well with emulated floating point, but some things, like the FAX engine, are really too slow to be very practical until more of the code is adapted to provide a fixed point version. 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] g729 support
Mindaugas Kezys wrote: If you live in patent-free country, you can try this: http://github.com/Deepwalker/fs_itu_g729/tree/master You live in Antarctica? :-\ 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] Cool names for my VoIP company
Peter P GMX wrote: Just a side notice about how to name a company. If you use a descriptive name e.g. GlobalSIP as sugested before, it may be difficult to register this name later on as a brand name when your company becomes successful. At least here in Europe it is not possible to register a brand name when the name itself describes the business or the techique used. Thats the reason why big companies nowadays use these strange names like There have been some high profile renamings in Europe, where the original name was too descriptive to trademark. For example, you couldn't trademark a name like Windows for a windowing system... oh, wait.. e.g. ABALA, which seem to not make any sense at all at a first glance. But these names can eaysily be registered as brand names. Not really. The names are getting weirder as the range of available weird name.com options shrinks. 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] POS modems
Hi, If anyone is interested in the low speed modems needed for POS applications (V.22, V.22bis, V.22bisFC and V.29FC) please contact me. I had some spare time while travelling, and finally got the V.22bis code I started a long time ago into a start where its basically functional. I'm now looking for input about exactly what application software expects from these modems, so I can plan the remainder of the code. 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] Is RFC 4733 supported ?
Michael Jerris wrote: rfc 4733 attempts (and fails miserably) to clarify rfc2833. It doesn't really change anything of any real substnace. Our handling of these packets tries very hard to be strict in what we send and loose in what we accept and we tend to interoperate pretty well with most endpoints. That being said, there are some very broken endpoints out there (such as sonus) that require special hacks, some are automatic, some require settings. All that being said, we should be very compliant with both 2833 and 4733, although you will generally see references in settings refer to 2833. RFC4733 largely tries to clarify RFC2833 for the DTMF features. However, for most other signal it is very incompatible with RFC2833. 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] How to call multi gateways for failover with early media?
Brian West wrote: Say you call billy, mary and ken at the same time. Billy's address provides early media (ringing) you are to give the first one to respond with media to the caller... but if by chance Mary's phone provider is having a problem and they give congestion 20 seconds later and actually answer the call to do this cuz you know how stupid telco's are... now you are to give the caller the congestion tone... So you had prefect ringing.. then congestion... I think we have all be there, heard that! Er, that's not stupidity. If the regulations allow them to answer at this point, they will. It generates revenue. Its a disaster for a lot of services which need to know if the call was answered to tell what to do next, but it ain't done through stupidity. We are the stupid suckers who pay. 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] How to call multi gateways for failover with early media?
Kristian Kielhofner wrote: On Sun, Apr 5, 2009 at 11:12 PM, David Knell d...@3c.co.uk wrote: Ah, well, that's where you're trying to change the way that things have been done for some decades. Ringback has historically been generated close to the called party, which is why you hear different ringback if you call people in different countries. What's wrong with that? Isn't that what we are all doing (or trying to do), to some extent? International dialing very well may use different ringbacks but: 1) How important is this, really? 2) How much more complicated is adding at least the real potential for 180? The actual ringback tone may not be important, but many other supervisory indications may occur at that point, either as tones or as voice announcements. E.g. call a cellphone that has problems - out of range, out of service, etc - and you will probably get a voice announcement telling you want's up. 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] echo cancellation on PRI cards
Fadil Berisha wrote: Sure you can get reliable DTMF detection on 70%-80% of call paths with no echo cancellation, Fair enough. You say sure you can get reliable DTMF detection on 70%-80% of call paths with no echo cancellation. OK, you forgot to mention that this is achievable with text-book algorithms and that exist advanced algorithms with reliability close to 100%. From my point of view , no need further arguing this issue and this thread for me is closed. Could you enlighten us as to these advanced algorithms that beat conventional statistics? You keep referring to mystical adaptive algorithms on the OSLEC mailing list, but you never give any details there, either. 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] freeswitch as a session border controller
Anthony Minessale wrote: I'm really starting to feel like we're playing musical threads here. Just avoid playing them through low bit rate codecs. :-) 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] echo cancellation on PRI cards
Fadil Berisha wrote: That's a simplification. Simple IVR (record, replay, collect DTMF) probably doesn't need EC; Dave Collect DTMF does not need EC. I take out your word probably because no need for any dilemma. Interaction between DTMF detector an EC *when EC exist* is different question and deserve separate thread. Although I am confirming your statement,// I can not say I am voting for you, simple because this is not political forum to express believing to one or other leader or authority. Receiving DTMF reliably needs a signal to noise ratio of about 10dB if the noise is Gaussian. The statistics of voice mean you need the DTMF to be more like 15dB above voice. Most hybrids are only required to have a return loss of better than 12dB. They can be *much* better, but don't count on it, especially at the phone's hybrid. You have multiple hybrids in the path (usually 2 or 4). Let's take the better case with only 2 sitting between the outgoing exchange card and the far end phone. Put 10km of copper between the exchange the phone (typical copper planning limit) and you probably have 15dB of attenuation on the line. Now your DTMF is actually below the level of the voice prompt for much of the time. Think that will work with an echo canceller? Sure you can get reliable DTMF detection on 70%-80% of call paths with no echo cancellation, but if you want reliability with close to 100% of phone lines, you need echo cancellation to remove the voice prompt from the signal received at the IVR. Dialogic, NMS, and the others didn't put EC on their cards for nothing. The only reason the normal connection of a phone to a line card gets reliable detection of the first dialed digit in the presence of a dialing tone is that the DTMF detector heavily filters that dialing tone. Forget the political forum crap. If you want to refute what I just said, try to back up your argument with some actual engineering. 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] PCMU fallback for T.38
Gabriel Kuri wrote: once the FAX tone is detected on the PSTN side, FS receives a T.38 re-INVITE from the provider and FS sends back a 488/Not Acceptable (proxy_media=false). at that point the provider than attempts fallback to PCMU with another reINVITE ... This part is interesting, and the subject of a discussion we had recently. A number of systems try that second re-invite after a 488, but the SIP specs say the call is pretty much dead after the 488 message is exchanged. Are they just hoping that maybe the other end will be non-compliant enough to keep the call alive, and recover its media mode, or haven't they read the specs? 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] echo cancellation on PRI cards
OK, one last go and I give up. Lets look at the documentation for Dialogic springware. This is the DSP package that loads in their cards or runs on the host in HMP applications. It does things like DTMF generation and detection for all Dialogic cards except the DM3 series. The documentation says: *PerfectDigit DTMF Signaling* • DSP-based DTMF (touchtone) detection algorithm optimized for lowest talk-off and play-off susceptibility in the industry. The system will not easily be fooled by mistaking human speech for DTMF tones. • Minimum tone duration and interdigit delay times accurately handle speed dialing typical of power users • Utilizes echo cancellation which results in superior cut through for accurate DTMF tone interpretation during voice file playback within a broad range of network/switch environments • DTMF outbound dialing generated by DSP for accuracy and flexibility (dialing levels are adjustable to meet a variety of global PTT requirements) Detecting supervisory tones on phone lines is trivial. Not falsely detecting them is where things get interesting. The standard test for DTMF receivers is a set of cassette tapes from Bellcore containing about 3 hours of snippets from real telephone calls in North America. Most DTMF receiver chips get a few hundred false DTMF hits in those 3 hours. Dialogic get 20 something. My DTMF receiver gets 19. The reason its hard to detect these things reliably is voice doesn't sit there nicely at one level. Its level and its spectrum bounce all over the place, and a real DTMF digit is only there for 40ms or so. I defy anyone to visually identify a 40ms DTMF digit amongst real dynamic speech if it isn't *way* above the voice in amplitude. This is why your phone has to mute your voice when you press a digit. The DTMF receiver has no chance of reliable detection with speech and digits mixed. In the few special cases where concurrent speech and signaling tone are present on the PSTN (e.g. 2280Hz signaling in .eu and 2600Hz in .us) the signaling sequence is very carefully constructed to avoid confusing the system. DTMF is never used in that way. There is one obvious special case where all DTMF receivers need to tolerate spillback. They need to differentiate between dialing tone and DTMF on the first digit you dial. They do this very simply. Dialing tone was chosen to be pretty low frequencies - 350Hz + 440Hz, 425Hz + 475Hz and similar pairings. The lowest DTMF tone is well above this. An aggressive low pass filter in the DTMF receiver removes the dial tone spillback, while barely affecting the lowest DTMF tone. This was the original design of DTMF, but.. IVRs changed all that. Their DTMF receivers are expected to work amidst outgoing prompts, which may be going to phones with an awful match to the line. The spillback can be huge. The good IVR hardware suppliers, like Dialogic, very quickly added echo cancellation to their cards. I can say a lot of negative things about Dialogic, but one thing they did really well was their DTMF cut-through. When people get used to an IVR they expect to hammer in digit sequences as fast as they can, in the face of a machine desperately trying to play voice prompts to them. Dialogic cards do this really well, on lines of all types, and on networks of varying quality. This would be impossible without echo cancellation. David Knell wrote: 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
Re: [Freeswitch-users] Is mod vmd working?
Nik Middleton wrote: Another issue with this module is the resources it consumes. We had it running on 50 calls yesterday and the cpu’s all went to 90+% That's odd. Something must be fouling up, as the algorithm he used should be very lightweight. 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] 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] 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] 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] 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
Re: [Freeswitch-users] Running freeswitch on powerpc
Rajagopal, Sridhar (Sridhar) wrote: Hi all, I am planning to run freeswitch on powerpc MPC8358. Please let me know if any changes needs to be done in the code Regards Sridhar It may be easier to say what will currently stop Freeswitch working. The lack of an MMU is a problem right now, so Blackfins are out, which is sad. Cores without hardware floating point may not perform all that well, but should work. Endianness should not be a problem. I think machines which choke on misaligned access are probably OK, too. Checking that list, you should be OK on a PPC. 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] Detecting the origin of voice activity using VAD
Andy Spitzer wrote: Woof! On Sun, 01 Mar 2009 21:28:18 -0500, Brian West br...@freeswitch.org wrote: NO. You want something that people THINK exists and works well... Reliable human/voice detection doesn't exist in ANY form. I beg to differ. See http://www.freepatentsonline.com/5521967.html for one way to do it. It works rather well and can quickly descriminate between voice and tone. I've no idea who owns that patent now (not me, for sure). Since when did a patent mean a problem is solved? For things like speech recognition you can achieve pretty high accuracy in voice detection, but in that case you can delay the audio and make decisions that span the start of the speech burst. For most telephony purposes you need to make a decision on the very first frame of speech, as you can't afford to add latency. That turns it into a tough problem. Something like the VAD in G.729 is about the best people can currently do, but its far from perfect. There is a simpler, less reliable way of differentiating voice from tone, that as far as I know isn't patented. If you compare the RMS power levels of sequential 40 mS periods, call progress tones will have very consistent power levels from sample to sample. So if 5 or more 40 mS periods have about the same power measurement (within say, 2%), it's a tone. Voice will have dramatic power level differences over that same period. This works very well in today's telephony environment, where tones are computer generated. In the old days when ringback tone was generated off the audio hum from the 20 Hz ring voltage generator...not so well. That is *not* VAD. What you describe just says is its energy steady. I will trigger on music, background noise and maybe even some of the fast pulsed tone signals. A proper VAD won't. 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] Detecting the origin of voice activity using VAD
Hi, mod_vmd is a bit more sophisticated than that. It looks for the signal being narrowband energy. However, mod_vmd isn't very reliable, as it takes a rather high SNR for its narrowband detector to work. So high that a lossy codec like G.711 can barely manage it. Regards, Steve Anthony Minessale wrote: i think that's what mod_vmd does On Mon, Mar 2, 2009 at 11:16 AM, Andy Spitzer w...@nortel.com mailto:w...@nortel.com wrote: Woof! On Sun, 01 Mar 2009 21:28:18 -0500, Brian West br...@freeswitch.org mailto:br...@freeswitch.org wrote: NO. You want something that people THINK exists and works well... Reliable human/voice detection doesn't exist in ANY form. I beg to differ. See http://www.freepatentsonline.com/5521967.html for one way to do it. It works rather well and can quickly descriminate between voice and tone. I've no idea who owns that patent now (not me, for sure). There is a simpler, less reliable way of differentiating voice from tone, that as far as I know isn't patented. If you compare the RMS power levels of sequential 40 mS periods, call progress tones will have very consistent power levels from sample to sample. So if 5 or more 40 mS periods have about the same power measurement (within say, 2%), it's a tone. Voice will have dramatic power level differences over that same period. This works very well in today's telephony environment, where tones are computer generated. In the old days when ringback tone was generated off the audio hum from the 20 Hz ring voltage generator...not so well. --Woof! ___ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org mailto: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] Detecting the origin of voice activity using VAD
Andy Spitzer wrote: Woof! On Sun, 01 Mar 2009 21:28:18 -0500, Brian West br...@freeswitch.org wrote: NO. You want something that people THINK exists and works well... Reliable human/voice detection doesn't exist in ANY form. I beg to differ. See http://www.freepatentsonline.com/5521967.html for one way to do it. It works rather well and can quickly descriminate between voice and tone. I've no idea who owns that patent now (not me, for sure). I just had a look through that patent. Its amazing. There is a lot of focussed descriptive text, but a patent only really consists of its claims. Those claims are astonishingly open-ended, and characterise what people had been doing for many years before it was filed - Well we, er, make a call, we listen for some beeping, and we may hang up based on that. That is a really sick patent. 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] Transcoding G723
Shelby Ramsey wrote: Thanks Moises. It looks like good work. When is Sangoma coming out with a similar product ... Doug told me it was in the works, then not in the works, then back in the works ... The problem is this particular card is PCI only and it will only do 120 channels If I were them, I'd think long and hard about such a product, and in the end probably not do it. Its the only realistic way to do G.723.1, but the market for that is not so big. For the much larger number wanting G.729, the main CPUs keep getting faster. There are 6 core Xeons now, and there are supposed to be 8 cores by the end of 2009. You can have 4 of those in a 1U chassis. Their speed is just going to keep running ahead of a card. The only real DSP that needs to be offloaded is EC, because a large number of channels of that is probably going to challenge the main CPUs for some time to come. 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] Transcoding G723
Brian West wrote: well that'll not scale far :P That transcoding card does 120 channels. A modern quad core CPU with a well implemented codec can do several hundred. A dual quad core chassis can do twice as much. Which one has a scaling problem? Steve /b On Feb 5, 2009, at 2:52 PM, Nicolas Brenner wrote: In my case, I can't use hardware transcoding since I don't have physical access to the servers, I rent them. Hence I need a pure software/IP solution. ___ 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] mod_g729
Jason Garland wrote: If you want Speex support you need to target the chipset manufacturers: Here is the Texas Insturments chipset that Polycom uses in the IP650 CPU is TNETV1050/C55x, rev 2 running at 162MHz with memory at 125MHz. And here are the codecs that Chip supports from TI's datasheet on this chip: http://focus.ti.com/pdfs/bcg/tnetv1050_prod_bulletin.pdf Codec Options* G.711 Codec, G.726, G.729AB, G.723.1A, G.722 wideband codec Speex is not listed, so Polycom can't do Speex. I should note that even the non-HD Polycom phones have this same chip and are capable of doing G.722 some some config tweaking. ;) I'm willing to bet that Cisco doesn't make their own DSP chips either. Find out who makes their chips and put pressure on that chip manufacturer to develop chips with Speex support. You are confusing two things. TI makes the TNETV range of chips. Their Telogy division makes software for VoIP platforms. The two may be used together or apart, and things may be added to the basic set of Telogy software. For example, in the Linksys SPA series you'll find the TI silicon used with Telogy software, but they also have Asterisk thrown in there to provide voicemail features. I very much doubt that Polycom uses TI's software. They've had their own VoIP software for a very long time, and I expect they still use it. 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] mod_g729
Hi Abdul, Abdul Hakeem wrote: Is Brazil a 3rd world country ? The last I hear Brazil was building aeroplanes, has it's own space and nuclear program and a GNP UK would be envious of. Cheers, AH What relevance does that have to the current discussion? Brazil is a country with large trade barriers, which skews the cost of hardware from the world market considerably. It is also pretty advanced, technically, and has a local base of electronics manufacturers. That considerably affects the economic tradeoffs in the use computers, telecoms, and other technology in Brazil. If something can be manufactured (or at least pass through final assembly) in Brazil, it will generally be much cheaper than something imported. That means some people find the use of locally made intelligent E1 cards is cheaper than the use of dumb cards from Digium or Sangoma. 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] mod_g729
Hi João, João Mesquita wrote: Steve, As we speak I am actually negotiating with one of those companies to make a mod for their cards. Khomp has a very nice product and they are exporting to the rest of latin america now. It surprises me someone doesn't assemble Tormenta 2 cards in Brazil. Various people have done this in China, and shipped a lot of cards. They have to be a lot cheaper than the Khomp and Digivoice boards. The key issue with the Tormenta 2 is the lack of on board echo cancellation. Although OSLEC performs well, 120 channels of EC is a lot to do on the host CPU. Still, a lot of cards ship without on board EC. 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] mod_g729
Raul Fragoso wrote: Hi João, Please say hello to Giancarlo at Khomp for me :) Khomp is the best example in Brazil of what good engineering and fair commercial prices can do to a country that suffers from high import taxes. Unfortunately some companies are still inclined to buy imported products/brands instead of favouring local production. Apart from this discriminatory issue, I believe that local research and production can turn the table of trade barriers imposed to development countries. Foreigners face huge tariff barriers trying to sell into Brazil. Brazilian makers face little difficulty selling into other markets. If Brazilian makers have any problems in such an environment, I'd be amused to hear them. :-) 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] mod_g729
Kristian Kielhofner wrote: On Thu, Jan 22, 2009 at 7:30 PM, Steve Underwood ste...@coppice.org wrote: Depends what you are after. Speex offers the quality of G.729 at around the same processing load. However, nobody seems to want to pay for the processing load of G.729. Almost everything uses G.729A. Half the processing load, but significantly poorer quality. Throughout most of this thread I've been using G.729 and G.729a interchangeably. That's sloppy on my part. Most of the time I meant G.729a because that is what most people (everyone?) uses. I was under the impression the quality difference wasn't that significant. I can't say if I've ever knowingly used true G.729. It certainly doesn't help that G.729a is allegedly completely compatible with G.729, to the point where I don't think it's even valid to use G.729a or annexa in an SDP... There is no reason whatsoever to differentiate between G.729 and G.729A in the SDP as the bit streams are 100% compatible. Annex A data is just encoded and decoded in less optimal ways. 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] Q931 decoding
Helmut Kuper wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, just an update about my progress in this. Currently I have working C code which creates a pcap file containing all needed protocoll headers in front of the Q931 dump. I use libpcap to create the pcap file. The protocol addresses of each protocol header structure are dynamically set by the code to reflect direction, sequence and timeline of each Q931 packet in whireshark. Wireshark can read and decode the current packets generated by my C code correctly. Have you figured out how well the Q.931 decoder in wireshark works? The decoders I have used, like T.38, are extremely buggy. I wonder if wireshark offers a shortcut that you have missed, for getting the data in. If you look through the supported protocols, there are some which never touch an IP network. For those to be useful, people must have a easy way to tie their data sources into wireshark. I've never looked into what they do, though. 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] mod_g729
Kristian Kielhofner wrote: On Thu, Jan 22, 2009 at 6:35 PM, Michael S Collins m...@freeswitch.org wrote: On Jan 22, 2009, at 3:15 PM, Brian West br...@freeswitch.org wrote: Not really what I would call a break... but at some point in the $1.6 million range you stop paying. /b Like I said, OSS FTW baby! -MC Quite the contrary. If Speex means you require faster, more capable DSPs, you are going to continue paying for them per unit. At $1.6mil you stop paying for G.729 licenses (basically a fixed cost at that point, regardless of volume or quantity). I'm sure most of the big guys paying for G.729 have no problem with that. I love OSS and Speex as much as any of us; I'm just trying to play devil's advocate and attempt to explain some of the strategy from those continuing to pay for G.729... Depends what you are after. Speex offers the quality of G.729 at around the same processing load. However, nobody seems to want to pay for the processing load of G.729. Almost everything uses G.729A. Half the processing load, but significantly poorer quality. VoIP is mostly a race to the bottom, and people wonder why it makes no money for provides. :-\ 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] mod_g729
Michael S Collins wrote: That delta shrinks as processing power gets cheaper. I wonder if g729 licenses will get cheaper over time as well? I wouldn't take that bet. ;) Economics 101: The pricing of the licences is directly related to G.729's lock on the market. The only reason for the prices to come down is if G.729A loses its grip on the IP phone market. 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] Mod Fax: Error, problems and questions...
Dennis wrote: hi, after we managed to setup fs with mod_fax and our socket outbound script, we have some questioons about an error and problems, when sending a fax: 1.) there is one error, we get always - no matter, if the fax was sent successfully or not. in the pastebin under http://pastebin.freeswitch.org/6338 you can see the error in the last line. this is the full log of a fax in fs console loglevel debug. That looks like something annoying but harmless. It looks like the comms path is disabled slightly before the flow of packets is turned off. That's probably just a silly slip in the code. 2.) fax works quite good. we couls send long faxes over a normal fax machine without any problem. but for fast testing we are using a softfax (fritz fax). here we have some more problems. mostly a fax with one page will pass through, but more pages will mostly fail. because we are new to the fax thing, we do not really know, what the messages tell us about failed faxes. here are the top 3 messages (unordered and always one at a time - nerver at once): variable_fax_result_text = Received a DCN while waiting for a DIS fax_result_text = The HDLC carrier did not stop in a timely manner fax_result_text = Unexpected message received could someone please tell us, where the problem might be? Does Fritz FAX means the ISDN card stuff? If so, that should be something well proven. However, the errors you are getting sound like the FAX at the far end is buggy. I think a log of the audio from one or two of these calls is needed for analysis. 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] openbts
Hi, It is almost certainly trivial to avoid licencing issues through the use of sockets. The overhead for socket communication would be no real issue in this case, as the processing for the GSM stack will be so heavy, you won't really notice the difference using sockets. The openbts site makes light of the GSM protocols. It has taken huge efforts over long periods for each GSM stack supplier to shake out their wares. That has typically involved extented evaluations of why certain specific spots on a network cause call drops (e.g. 50% of calls in cars emerging from this particular tunnel drop as they emerge). Achieving a usable stack is not for the faint hearted. Regards, Steve Michael Collins wrote: OpenBTS is GPLv3... may have OS licensing issues trying to make that happen. -MC On Fri, Sep 5, 2008 at 11:56 PM, Tamas [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, Have you seen this? http://openbts.sourceforge.net/background.html I guess, FreeSWITCH would be better for this ;) Regards, Tamas ___ 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] Open g729 g723 codec, any expierence
Patrick wrote: Brian West wrote: You do realize its like 16 pages of patents. On Sep 2, 2008, at 10:30 PM, Diego Viola wrote: I live in Paraguay, doesn't that only affects in the U.S? Correct me if I'm wrong, but I guess the patents issue is only in the U.S. IANAL but why would 16 pages of patents matter? Afaik if you don't have software patents in your country then you can use this stuff legally. Am I missing something? What relevance has software patents to this discussion? 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] Open g729 g723 codec, any expierence
Brian West wrote: I would watch a blanket statement like that. You would be surprised to find out how far those patents reach. /b On Sep 1, 2008, at 11:19 PM, Diego Viola wrote: I would like to have this, since I live in a country where patents don't affect us. Diego Don't be so judgemental. He might be part of an Antarctic expedition, or spend his entire life afloat outside territorial waters. :-) 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] T1 RBS Support Revisited
Anthony Minessale wrote: we would probably need to make an em signaling module to handle that. It's kinda like the analog only without all the complexity. It's more or less on hook and off hook and reading DTMF I have one of those. :-) Actually, its a bit more than you said. You need to cater for wink start and a few other things. Nothing too difficult, though. 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] Exchange 2007 UM - DTMF problem
Hi, Brian West wrote: So if you can tell me where this is wrong as per 2833 and the clarification via 4733 ? rfc4733 obsoletes rfc2833 and says this: The special duration value of zero is reserved to indicate that the event lasts forever, i.e., is a state and is considered to be effective until updated. A sender MUST NOT transmit a zero duration for events other than those defined as states. The receiver SHOULD ignore an event report with zero duration if the event is not a state. /b PS: http://www.rfc-editor.org/rfc/rfc4733.txt As well as that definition in RFC4733, they also have an example working in the way the text describes. They send DTMF with a packet rate of one every 50ms. The first packet of the DTMF sequence contains a duration of 400. What does FS actually do when a sequence starts at 0? Does it just drop the first packet, or the whole sequence? If it just drops the first packet, and the far end cares, that's seriously broken on their part. It means a single lost packet screws up the whole sequence. Not good. If FS drops the whole sequence, that might be a little too aggressive. Some will argue that a gateway should be totally transparent in these situations, but total transparency is only workable in simplistic cases. In the end, if MS are doing this you can be sure it will not be fixed, and must be tolerated. 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] FreeSWITCH in latin america countries
Arnaldo de Moraes Pereira wrote: Hello, For those of you from latin american countries, please join #freeswitch-la. I have plans to knock down the barriers to adopt FreeSWITCH in third-world countries, specially Brazil, so this channel is one of the steps to achieve that. Brazilian portuguese and spanish are also welcomed languages. One of the biggest barriers to use FreeSWITCH as a TDM/SIP gateway, is to have MFC/R2 support, which is being written by Steve Underwood in a generic manner. I'll be focusing on the endpoint for the existing unicall implementation, which we hopefully will merge when Steve has finished his unicall work. So, anyone will be able to use MFC/R2 with a Sangoma and probably other cards. Take care. I started on a Unicall endpoint module for Freeswitch a few weeks ago, but I've been busy with other stuff and I haven't had time to go back to it. Unicall and spandsp are becoming LGPL, so there are no longer any licence barriers to Freeswitch integration. In the last week several people have expressed interest in getting such an endpoint module working, and if they are eager to do that, it will certainly leave me free to work on a long list of other things. The Unicall APIs are changing a little, to increase flexibility. However, if an endpoint is built for the existing Unicall code, only minor changes should be needed for the version I am working on now. 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
