Hi Jac,

No problem, I had originally spoken to Readytechnology and asked if he had a
version for OpenPBX and IPP 5.  He replied that he was holding out for
someone to fund a codec based on IPP5, and there is certainly nothing wrong
with that position.  I replied that if ZettaServe did develop an IPP5 codec
we would send him a copy of our code, which we will do shortly.  I ported
his IPP 4.1 to OpenPBX, but was then unable to determine from the Intel
website if licenses for IPP 4.1 were still available.  I then looked at
porting his codec to IPP5 but it was determined that we were better off
starting from scratch, which we did.  We then also took the opportunity to
see if the timer changes in OpenPBX would allow the support of annex b which
in fact they do.  The diff file for OpenPBX enables support of annex b -
further details regarding the diff file are available at the ZettaServe page
at http://www.zettaserve.com/default.asp?catid=78.  Again, I believe that
annex b support is significant as I have seen documentation implying that it
can triple the amount of calls per given bandwidth - see
http://www.connect802.com/voip_bandwidth.php and calculate for g729 with and
without VAD enabled.

We are going to add g723.1 very shortly now that we have pretty much sorted
out g729 - my developer assures me that adding g723.1 support is 'trivial'
using the IPP libraries.

The code currently on the website will compile optimised static and shared
libraries versions of the codec based on the makefile selection.  Any
version downloaded earlier than about 48 hours ago does not produce
optimised static binaries.  For the benefit of others reading this thread,
the transcoding times using the optimised libraries have improved
significantly, by approx 40% across the board (eg 12ms to 7ms on a P4
3.0Ghz).  The static version (default) will determine the cpu at compile
time and add the appropriate libraries to the binary.  The shared library
version will determine the cpu at runtime and load as appropriate, although
it requires the full intel redistributable to be installed and in the
ld.so.conf search path in order to work.

Craig

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jac Barben
Sent: Sunday, 29 April 2007 1:28 AM
To: 'OpenPBX.org Developers Mailing List'
Cc: [EMAIL PROTECTED]
Subject: Re: [Openpbx-dev] G729 Licensing thread

Since we know what the licensing will cost and that there is enough 
"interest" to support the costs, what remains is to:
1.  Select a technology
2.  Figure out how to control licensing
3.  Build a legal structure that will satisfy Sipro, Lucent, NEC and Nokia

I have my lawyers investigating #3 and I'm currently tackling #1.  I'm 
pretty sure we need to figure out which technology we're going to use 
before we land on how to control license distribution.

Below are the solutions I've tested so far.  My testing has not been 
particularly scientific.  I've merely caused the system to load up with 
"live" calls, including myself in one or more of the calls (listening 
for quality), and monitoring CPU utilization (looking for an upper limit 
of 70% on a single processor AMD duo core).  Relative to transcoding, 
most of the calls were g.711/g.729.

ZettaServe solution (thank you Craig): 
    This is an Intel IPP 5 based solution. 
    It clearly works. 
    I've found no incompatibilities. 
    I was able to process 200 simultaneous transcoded calls.

ReadyTechnology solutions (thank you Sam): 
    This is an Intel IPP 4 based solution. 
    It works. 
    It also has g.723 properties that were interesting. 
    I was able to get 163 simultaneous g.729 transcoded calls.
    I was able to get 144 simulatneous g.723 transcoded calls (g.729/g.723).

If there is more "scientific" approach y'all would like to see, please 
advise your parameters and I'll see what I can do to report on them.

I would like to "test" other solutions as well.  There have been several 
"off-line" posts suggesting various solutions.  While options are 
good... I really want to select the "best-of-breed".

_______________________________________________
Openpbx-dev mailing list
[email protected]
http://lists.openpbx.org/mailman/listinfo/openpbx-dev

_______________________________________________
Openpbx-dev mailing list
[email protected]
http://lists.openpbx.org/mailman/listinfo/openpbx-dev

Reply via email to