Re: [Freeswitch-users] Codecs and things

[Steve Underwood]

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] Choosing a Codec.

[Steve Underwood]

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] mod_conference scalability

[Steve Underwood]

On 12/18/2009 03:29 AM, Brian wrote:
>
> Hi Mike,
>
> I didn’t get around to testing on the FreeSWITCH trunk yet. Are there 
> substantial fixes to mod_conference in the FreeSWITCH trunk that might 
> increase capacity for my scenario of one speaker and many listeners? 
> If I want to put this into a production environment, I would need a 
> stable version, which as far as I know is the 1.0.4 version.
>
> However, I did test on Asterisk 1.4 using app_conference, and doing 
> the same scenario was able to get 1 speaker and 600 listeners on a 
> single conference with no audio issues. The CPU at that point was just 
> over 300%, same as where the single conference scenario failed on 
> FreeSWITCH with 300 listeners. I was able to push it to over 700 
> listeners before I reached 400% CPU usage (I guess maxing out my 
> quad-core processors), and asterisk finally crashed. But up until that 
> point, there were no audio problems.
>
> I’ve read a lot about how FreeSWITCH is supposed to be more scalable 
> than Asterisk, but unless there is something wrong with my FreeSWITCH 
> setup, Asterisk was clearly the winner in this test – more than 
> doubling FreeSWITCH capacity in this case. Again, maybe there is 
> something on the FreeSWITCH side that I’m doing wrong, but I don’t see 
> what it could be.
>
> Brian.
>

I don't think you have mentioned which codecs are involved. This can 
have a profound effect.

Steve

> *From:* Michael Jerris [mailto:m...@jerris.com]
> *Sent:* Thursday, December 17, 2009 10:18 AM
> *To:* freeswitch-users@lists.freeswitch.org
> *Subject:* Re: [Freeswitch-users] mod_conference scalability
>
> I would be curious what the same tests produce with svn trunk of 
> FreeSWITCH.
>
> Mike
>
> On Dec 16, 2009, at 4:49 PM, Brian wrote:
>
>
>
> Hi,
>
> I’m new to FreeSWITCH and I’m testing the scalability of 
> mod_conference to see if it will scale better that other solutions. My 
> scenario is to have one speaker, and many listeners (mute). Since I 
> have only one speaker, I was expecting this to scale well because 
> there is no audio mixing required, just send each frame of the single 
> speaker to each listener. Unfortunately, my testing was disappointing, 
> and it didn’t scale nearly as well as I’d hoped (based on what I’ve 
> read on how FreeSWITCH is supposed to be generally very scalable).
>
> Here’s my server setup is this:
>
> FreeSWITCH 1.0.4, 64 bit CentOS 5.3, on a quad-core Xeon server, 4 Gig 
> of RAM. I’ve set file logging to “notice” level. My conference profile 
> is configured to suppress several events, hoping that it would improve 
> performance.
>
> Here are a few scenarios I tested, and roughly where I reached the 
> point of audio failure on the conferences:
>
> Scenario 1:
>
> 1 conference, 1 speaker, audio failed at approx 300 listeners (mute)
>
> Scenario 2:
>
> 4 conferences, 1 speaker per conference, audio failed approx 110 
> listeners per conference (so just over 400 total channels on the system).
>
> Scenario 3:
>
> 16 conferences, 1 speaker per conference, audio failed at 32 listeners 
> per conference (so just over 500 total channels on the system).
>
> Looking at the output from “top”, it seems that in all 3 scenarios, 
> the audio quality failed when the % CPU for the FreeSWITCH process 
> exceeded 300%.
>
> I was hoping maybe someone else might have done similar testing, or 
> maybe has suggestions on how to improve the performance. Or perhaps an 
> alternate solution to the one speaker, many listener case?
>
> Thanks,
>
> Brian.
>
>


___
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 ?

[Steve Underwood]

On 12/17/2009 02:22 AM, Bruce McAlister wrote:
> Hi Michael,
>
> Michael Jerris wrote:
>
>> I expect the module will initially be available for linux and we will add 
>> other platforms as demand shows a need for it and I can get build servers up 
>> that will be used to produce the binaries.  Windows will likely be one of 
>> the early alternatives
>>
>>  
> Is support for Solaris and/or OpenSolaris x86 planned as well?
>
> Thanks
> Bruce
>
Support for the less popular platforms will probably depend mostly on 
the availability of machines for building and testing. The code is 
unlikely to ever be as well optimised for speed on the less popular 
platforms, but basic support should be largely an issue of access for 
development and support.

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 ?

[Steve Underwood]

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  > 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] Which ATAs to chose for modem connections?

[Steve Underwood]

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] Hardware echo cancellation.

[Steve Underwood]

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] Hardware echo cancellation.

[Steve Underwood]

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] Build FS without spandsp or libtiff

[Steve Underwood]

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 West  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

[Steve Underwood]

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  <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  <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] wav files compression

[Steve Underwood]

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  > 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] SILK speech codec, Celt, FreeSWITCH

[Steve Underwood]

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] SILK speech codec, Celt, FreeSWITCH

[Steve Underwood]

On 09/29/2009 09:05 AM, Jason White wrote:
> Brian West  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] FreeSWITCH and OpenBTS integration

[Steve Underwood]

On 09/17/2009 09:19 PM, Brian West wrote:
> Just create an OpenBTS page on our wiki.
>
> /b
>
> On Sep 17, 2009, at 7:46 AM, Alberto Escudero wrote:
>
>
>> Sorry, just realized that the sourceforge page is protected by
>> password. I
>> am happy to put the info in FreeSWITCH wiki, where does it  make
>> sense to
>> add this project info?
>>  
>
Isn't there still some legal wrangling over openBTS?

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

[Steve Underwood]

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=

Re: [Freeswitch-users] faxrx error 13 Unexpected message received

[Steve Underwood]

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

[Freeswitch-users] T.38 with V.34 support

[Steve Underwood]

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

[Steve Underwood]

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

[Steve Underwood]

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:
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>
> 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

[Steve Underwood]

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

[Steve Underwood]

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] voip-voip echo cancel possible

[Steve Underwood]

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

[Steve Underwood]

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] FS beats Aculab Prosody S on subjective test on lay users for conference quality

[Steve Underwood]

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] mod_fax problems

[Steve Underwood]

Hi Evgeniy,

Evgeniy Zolotov wrote:
>   Hello!
>
>   I have some problems with receiving fax messages. My FreeSWITCH
> cann't decode some faxes. As I understood this problem has occurred
> with Panasonic and Panasonic-like fax-machines.
>   I have recorded wav-file, which corresponds to the receiving fax
> (see fax.wav.tgz) and log-file of this session (fax.log.tgz).
>   I tried decode this fax with the help of transferring them from one
> FreeSWITCH to another, but with no luck (I used for this SIP and
> openzap - result the same).
>   Transferring from one FreeSWITCH to another with the help of 'txfax'
> works perfect.
>
> OS: Centos 5.2
> FreeSWITCH: 1.0.2 (11053)
>
>   Configuration file for mod_fax - original.
>
>   So, please, help me to understand this situation.
>
>   Thanks, Evgeniy
The audio you posted doesn't seem to come from the call in your log 
file. The audio is very odd, with sections of a FAX called joined 
together in a strange order. The log file is very simple, and tells you 
exactly what went wrong. It says:

Fax processing not successful - result (10) Far end is not able 
to transmit.

and the reason it says this is because the DIS message from the far end 
says:

 ...0= Ready to transmit a fax document (polling): Not set

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 on blackfin

[Steve Underwood]

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

[Steve Underwood]

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] Dialogic cards

[Steve Underwood]

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  > 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] Language Handling: call for assistance

[Steve Underwood]

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 >> <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] Language Handling: call for assistance

[Steve Underwood]

Michael Collins wrote:
>
>
> On Thu, Jul 2, 2009 at 3:01 AM, Igor Neves  > 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] Is there any license G729?

[Steve Underwood]

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?

[Steve Underwood]

Brian West wrote:
> Cuz its harder to lie to your wife!  :P
>
> /b
>
> On Jun 29, 2009, at 12:31 PM, Steve Underwood wrote:
>
>   
>> 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.
>> 
Now you're thinking :-)

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?

[Steve Underwood]

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] Is there any license G729?

[Steve Underwood]

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  
> AT&T 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?

[Steve Underwood]

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] MPL and licensing

[Steve Underwood]

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] Open source Java based inbound event socket library available

[Steve Underwood]

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] Web page thoughts

[Steve Underwood]

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 
 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?

[Steve Underwood]

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

[Steve Underwood]

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

[Steve Underwood]

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 
.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

[Steve Underwood]

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] VoiceXML

[Steve Underwood]

mszlazak wrote:
> If you don't like vxml then here is a post on voicePHP
>
> http://www.speechtechblog.com/2009/04/22/voicexml-to-go-down-in-the-third-says-voicephp
>
> It's from a vendor but there might be some good ideas to get from what they
> are doing.
>
> FreeSWITCH needs demand to get vxml and it's not there yet. For now, it
> looks like the FS community is waiting for demand instead of trying to
> create it. 
>   
Its interesting how the VoiceXML pushers have been able to create the 
air in some circles that VoiceXML is the norm for IVR creation. Its 
actually pretty hard to find people who have ever used it.

I think voiceXML has one big thing going for it - nothing else for IVR 
building has been standardised. Apart from that its really clunky. Only 
the most trivial examples look even moderately clean and readable.

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 ?

[Steve Underwood]

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?

[Steve Underwood]

Kristian Kielhofner wrote:
> On Sun, Apr 5, 2009 at 11:12 PM, David Knell  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] How to call multi gateways for failover with early media?

[Steve Underwood]

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] freeswitch as a session border controller

[Steve Underwood]

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

[Steve Underwood]

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] echo cancellation on PRI cards

[Steve Underwood]

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

[Steve Underwood]

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] Is mod vmd working?

[Steve Underwood]

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

[Steve Underwood]

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 pur

Re: [Freeswitch-users] echo cancellation on PRI cards

[Steve Underwood]

David Knell wrote:
> Steve Underwood wrote:
>> [whopping big snip]
>>   
>>> The first bit of that's a tad patronising, isn't it,
>>> 
>> You are the one who started out being offensive.
>>   
> I'm sorry if you find disagreement offensive; you might not wish to 
> read beyond this
> point if so.
>>> and, in the case of the decade-old Aculab
>>> cards which which I'm most familiar, is also untrue.
>>> 
>> I can't find too much about the old cards on the web now, but I found 
>> http://www.amdevcomm.com/voice-mail-products/voice-mail-components/dialogic/dti_sc.html
>>  
>> which is pretty much a copy and paste from the old Dialogic web pages, 
>> and you'll see it says "Cut through : Local echo cancellation permits 
>> 100% detection with a >4.5 dB return loss line". The Aculabs did the 
>> same thing for sure. They just couldn't work without cancellation. There 
>> were some very early Dialogic cards, using DTMF receiver chips and OKI 
>> ADPCM chips, and had no general purpose DSPs. They performed really 
>> badly because of the lack of cancellation, and were quickly replaced 
>> with cards that put the OKI ADPCM, DTMF anf echo cancellation algorithms 
>> into a Motorola 56k DSP chips.
>>   
> The same document, under the bit which you've quoted, says:
> "(E-1) Digital trunks use separate transmit and receive paths to network.
> Performance dependent on far end handset's match to local analog loop."
> - i.e. the card does no echo cancellation. 
Your messages are starting to looked deranged. Why would they only apply 
echo cancellation to T1s? Its a bizarre idea, and you must realise its 
wrong. Are you so desperate to support a wrong answer you'll clutch at 
straws? :-\

>
> Aculab didn't even offer echo cancellation on Prosody for years and, 
> when they did, it
> consumed prodigious amounts of DSP.  Nonetheless, the DTMF detection 
> worked
> perfectly well, even across 120 channels per 40MHz SHARC - there's 
> just no way
> that those DSPs had enough horsepower to do echo cancellation across 
> that many
> channels.
This page 
http://www.aculab.com/support/pdf_documents/v6_solaris/ting/pubdoc/an-dtmf-det-issues.html
 
seems to support what you say. It also implies DTMF detection sucks 
unless you echo cancel. The statement "If the outgoing signal is a tone 
of some sort (e.g. a 'beep'), ensure that its frequency is below 600Hz" 
is telling you to keep your outgoing signal in the same frequency range 
as dial-tone where the dial-tone filter on the DTMF receiver will 
obviate the need for an echo canceller. They are freely admitting 
exactly what I have said. If you want a normal IVR with cut-through to 
work you better turn that echo canceller on.

My only experience with Aculab was fitting a box designed by other 
people into a system. That one definitely echo cancelled, as it worked 
as well as the Dialogic based boxes we developed ourselves.

>
> An Asterisk box with an el-cheapo quad E1 card in that I use for 
> TDM-SIP gatewaying
> detects DTMF perfectly well with no echo cancellation.
You must have very low standards for "works well".
>
> You just don't need echo cancellation to achieve perfectly acceptable 
> DTMF detection.
Well, not if you expect people to wait for silence before entering DTMF, 
but who would tolerate that these days? Cut through has been de rigeur 
since the late 80s.
>
> ASR - yes, maybe, but surely only in the case where the application 
> requires barge-in;
> even then, I'd be interested to see some test results, particuarly 
> where the outbound prompt
> is killed the moment the ASR reports start of speech.
Doesn't any sane system expect barge in to be nearly as reliable as 
waiting for silence? Who would tolerate something that doesn't? It has 
been a standard expectation of any decent IVR since they began.
>
> I'm afraid that your original bald claim - that "IVRs badly need echo 
> cancellation" is simply
> wrong, misleading and irresponsible: those believing it will end up 
> spending large sums
> of money on technology which they probably do not need.
You must have very low standards for what works well. If you suggest 
people leave out echo cancellation you are just asking for customer 
service issues down the line. That whole Aculab page is a clear response 
to just such issues they had, which forced them to add the necessary 
improvements.

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

[Steve Underwood]

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 L&H'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.
>>> 
>> L&H 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] echo cancellation on PRI cards

[Steve Underwood]

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

[Steve Underwood]

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 L&H'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.
L&H 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

[Steve Underwood]

Wasim Baig wrote:
> 2009/3/17 Anthony Knight  >
>
> 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] Detecting the origin of voice activity using VAD

[Steve Underwood]

Andy Spitzer wrote:
> Woof!
>
> On Sun, 01 Mar 2009 21:28:18 -0500, Brian West  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] Detecting the origin of voice activity using VAD

[Steve Underwood]

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  > wrote:
>
> Woof!
>
> On Sun, 01 Mar 2009 21:28:18 -0500, Brian West
> 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
> 
> 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

[Steve Underwood]

Andy Spitzer wrote:
> Woof!
>
> On Sun, 01 Mar 2009 21:28:18 -0500, Brian West  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] Running freeswitch on powerpc

[Steve Underwood]

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

[Freeswitch-users] Skype as a path to wideband adoption

[Steve Underwood]

Hi all,

Consider the following:

- FS has recently greatly enhanced its support for wide, wider and 
widest band telephony
- That advantage is of no benefit when interworking with the PSTN
- Skype has had wideband since day one, and just got 
super-ultra-duper-wideband.
- FS is acquiring skype connectivity options (2, which hopefully 
will converge to one best in class option).

One obvious conclusion is Skype offers the best possibility for having 
broad coverage with wideband voice.
However, codec issues are certain to degrade quality. Lossy compressed 
codecs don't transcode well, and the
codecs Skype uses are their own. FS is gaining a range of open and 
royalty free licence wideband codecs, but
not the ones Skype uses. Skype choose widely supported narrowband codecs 
- G.711 and G.729 - but have not used a wideband codec with broad support.

So the point of this note is "what can we do to optimise things?"

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

[Steve Underwood]

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

[Steve Underwood]

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

[Steve Underwood]

Hi Raul,

Raul Fragoso wrote:
> Hi Steve,
>
> My point is more towards the high import taxes here. A foreign company
> won't pay as much taxes to export to Brazil as brazilians would pay
> import taxes for such goods.
> I will give you a simple example: a Snom 320 phone would cost roughly US
> $180.00 if bought in the US. Here it would cost at least double the
> price, but usually more. We pay almost 100% for importing taxes + GST,
> excluding the greedy profit that dealers and resellers usually apply,
> but Snom (or their distributors) would pay only a small fraction of that
> to export phones to Brazil. The irony is that we don't see where all
> this money is spent, as the country still suffers of a huge social and
> economical dissimilarity among their people.
> On the other hand, our current government seems to be making some
> progress to make exporting from Brazil easier, specially for small
> companies (international trade is known to be very bureaucratic here). 
> Anyway, this is turning into a politics discussion thread and I know it
> can annoy some people. Just to stay in the subject thread, I also
> endorse the support for open codecs rather than paying millions for
> G.729 licenses.
>   

Well, any discussion of trade immediately has a political element. 
However, this discussion is quite interesting from an engineering point 
of view. Engineering is never separate from politics, as so much 
engineering is working around artificial barriers erected by politics. 
To many engineers, a lot of decisions seem wacky, because they can't see 
the political angle. The different pressures guiding decisions like buy 
local/buy foreign, use ISDN/use MFC/R2, and so on can be quite illuminating.

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

[Steve Underwood]

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

[Steve Underwood]

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

[Steve Underwood]

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

[Steve Underwood]

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

[Steve Underwood]

Kristian Kielhofner wrote:
> On Thu, Jan 22, 2009 at 7:30 PM, Steve Underwood  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] mod_g729

[Steve Underwood]

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_g729

[Steve Underwood]

Kristian Kielhofner wrote:
> On Thu, Jan 22, 2009 at 6:35 PM, Michael S Collins  
> wrote:
>   
>> On Jan 22, 2009, at 3:15 PM, Brian West  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] Q931 decoding

[Steve Underwood]

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 Fax: Error, problems and questions...

[Steve Underwood]

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

[Steve Underwood]

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] 
> > 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

[Steve Underwood]

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

[Steve Underwood]

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

[Steve Underwood]

Anthony Minessale wrote:
> we would probably need to make an e&m 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] Can we have a forum

[Steve Underwood]

Brian West wrote:
> The only worry about forums is that it splits support resources  
> between the two.  Any thoughts?
>   
Yeah, I have a thought. Would anyone who thinks forums are a good idea 
care to name one that actually works, isn't a war zone, and yet 
functions without truly massive full time moderation?

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] Comparison matirx

[Steve Underwood]

Grey Man wrote:
> On Sun, Aug 3, 2008 at 1:20 AM, Simon Shaw <[EMAIL PROTECTED]> wrote:
>   
>> I have built a comparison matrix that will enable me to compare the leading
>> Open Source soft switches.
>>
>> In the attached spread sheet there is a first suggestion of what I think
>> should be compared and relevant weightings and I would be glad to hear your
>> feedback.
>>
>> Regards,
>>
>> Simon
>>
>> ___
>> 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
>>
>>
>> 
>
> Hi Simon,
>
> Looks like a good idea to me even though you're going to need to be an
> expert in each product to be able to fill it in and the experts in
> this case tend to be a bit biased :).
>
> One suggestion I'd have for another row is "Security Fix Rate". For
> example while the Asterisk community's approach to handling security
> releases is commendable the rate at which they happen is a real pain
> when you have to potentially upgrade a production system for each one.
> Although the pain comes from having to worry about whether the version
> of Asterisk that you need to upgrade to will be one of the stable or
> dud versions!
>   
I think measures of non-security bug fix responsiveness are fine. 
Everyone ships with bugs, even if some ship with far more than others. 
Responsive in dealing with those bugs is probably as important as their 
frequency.

Security related bug responsiveness is quite another issue. Do you 
realise the guy that wrote qmail has been s unresponsive that he has 
never posted a security fix since the original 1.0 release was shipped? 
It has been one of qmail's strongest attractions. :-)

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

[Steve Underwood]

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

[Steve Underwood]

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

Re: [Freeswitch-users] g729

[Steve Underwood]

Brian West wrote:
> It expires in 2016
>   
That is presumably for the US. Do you know when the rest of us will be 
free? Also, do you know if some of the later annexes have patents in the 
pool? If their VAD relies on some patent(s) which came later that could 
be a real pain.
> /b
>
> On Jun 5, 2008, at 11:10 AM, Andy Spitzer wrote:
>
>   
>> Woof!
>>
>> On Thu, 05 Jun 2008 10:17:14 -0400, Ken Rice <[EMAIL PROTECTED]>  
>> wrote:
>>
>> 
>>> The whole problem is the
>>> Patents held by The G729 Consortium, and 2 other companies...
>>>
>>>   
>> Has anyone ever gotten a list of the actual patent numbers in  
>> question?  I've
>> tried on several occasions and have always been balked.  The ITU  
>> patent site
>> http://www.itu.int/ipr/IPRSearch.aspx?iprtype=PS has never worked  
>> for me,
>> always "timing out".  It's been this way for at least two years.
>> 
http://www.itu.int/ipr/IPRSearch.aspx?iprtype=PS works OK for some 
searches (e.g. G.729 annex B just worked OK), but seems to time out for 
others (e.g. G.729 just timed out - there's probably just too many 
entries :-) )
>> As the original G.729 spec was approved by the ITU some 13 years  
>> ago, I suspect
>> that any of the patents in them has expired, or is very close to  
>> expiration.  Given
>> a list of the actual patents one should be able to determine the  
>> date when
>> G.729 becomes patent un-emcumbered.
>>
>> 
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