G729 Codec

[GoogleCodeExporter]

Implement the G729 Codec

Original issue reported on code.google.com by r3gis...@gmail.com on 20 Mar 2010 at 8:39

[GoogleCodeExporter]

Original comment by r3gis...@gmail.com on 20 Mar 2010 at 8:42

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

pentor88@gmail.com

Original comment by pento...@gmail.com on 11 Apr 2010 at 3:15

[GoogleCodeExporter]

+1, I would love to have G729 Codec support

Original comment by anishna...@gmail.com on 20 May 2010 at 1:29

[GoogleCodeExporter]

+1, with low umts band G729 is essential.

Original comment by markmar1...@gmail.com on 7 Jun 2010 at 10:25

[GoogleCodeExporter]

I Agree, really need G729

Original comment by niitserv...@gmail.com on 21 Jun 2010 at 5:14

[GoogleCodeExporter]

really want g729. that would be awesome

Original comment by xavierdy...@gmail.com on 9 Jul 2010 at 10:48

[GoogleCodeExporter]

g729, thank you so much!

Original comment by mgshu...@gmail.com on 21 Jul 2010 at 1:41

[GoogleCodeExporter]

Think someone mentioned it somewhere here before, but sipphon which is also 
based on pjsip has some G729 code which I assume could be ported. However the 
patent issue might be a cause for concern in this case.

The way around it is to either rely on a disclaimer telling the user its up to 
him or her and then hope no lawyer comes calling... the other way would be to 
have a market version with a pricetag covering the patent fee. This might not 
actually be such a bad idea but it would require a license deal from someplace 
other the sipro since they charge some ridiculous initial amount just to sign 
up. Maybe something like http://www.synapseglobal.com/g729_codec_license.html
But I guess that begs the question if anyone would actually pay 10-15 bucks to 
get a version containing G729...

Original comment by michael....@gmail.com on 21 Jul 2010 at 11:49

[GoogleCodeExporter]

please note, you should purchase license only if you transcode something with 
g729. nypassing g729 is absolutely free

Original comment by zdevel on 22 Jul 2010 at 6:26

[GoogleCodeExporter]

Softphones require licenses at least according to sipro if I remember 
correctly. The bypassing case would apply if I had an asterisk server just 
passing the stream along but the softphone would still require a patent license.

Original comment by michael....@gmail.com on 22 Jul 2010 at 6:49

[GoogleCodeExporter]

For the technical part, I'm in contact with Samuel who write siphon and its 
g729 implementation for arm. 
He (and I) think that just including his code will be enough to support g729. 
I'll probably try it today :)

For the license part.... it's more complicated.  
I agree with micheal's comment and that's also what Samuel explained to me. 
Thanks a lot micheal for the SynapseGlobal link. I didn't know that there where 
retailers that allow a per license purchase. Really interesting !! It could be 
easier to manage than the sipro solution that afraid me a lot !!!

In the case I get a solution to manage the license, the best solution is to 
provide a plugin app on the market that provide an updated version of the 
dynamic library. Some changes has to be done in the update process but that was 
already planned.

This method will sip providers to provide their own application that relies on 
CSipSimple and include a g729 library if they already pay fees for their users.

Original comment by r3gis...@gmail.com on 22 Jul 2010 at 7:30

[GoogleCodeExporter]

Just out of curiosity did you try to get this working yet?

Original comment by michael....@gmail.com on 25 Jul 2010 at 1:36

[GoogleCodeExporter]

Yes, 

Thanks to the very great support from Samuel (author of Siphon), I get 
something that build.

There is one thing I miss to be able to test... Allow local accounts (because 
all my registrar rewrite invite offers and doesn't allow g729 :D ).
I'm pretty confident in the fact that it will work, but I don't know what will 
be the performances.
In fact, for the Iphone version, it was possible to use assembler code, but for 
android, since we commonly use a aebi assembler, instructions are not the same, 
so I fall back to generic code. Less efficient but that build within the NDK.

For now, my priority is to implement filters and rewriting rules for native 
dialer intergration. But I continue this task in background.

Original comment by r3gis...@gmail.com on 25 Jul 2010 at 2:14

[GoogleCodeExporter]

If you don't have a place to test g729, you can get in touch (egcrosser at 
gmail) and I'll set up an account for you on my system.

Original comment by egcros...@gmail.com on 26 Jul 2010 at 5:12

[GoogleCodeExporter]

Performance might still be ok using the latest android devices which have 
pretty descent hardware. Will be interesting to see the results of the tests.

Original comment by michael....@gmail.com on 26 Jul 2010 at 9:45

• Added labels: OpSys-All

[GoogleCodeExporter]

Well, thanks for your nice proposition egcrosser but I've just succeeded using 
one of my sip server without SBC.

So after many tests (there is still bugs with the codec priority management), 
my calls between a HTC Sapphire (Magic / G2) and Nexus One using G729. (Both 
handset use wifi)

Result is pretty good. Latency is really low. Sometimes (probably due to VAD) I 
get some choppy sound on the G2 but sound is clear on Nexus One.

So it's worth to be continued. For now what I did is just unreleasable : I made 
code to allow compilation at midnight... But I'll try to do something more 
clean, and contribute it back to Samuel's Siphon project once it will be enough 
clean. And of course it will be available on my repo.

Meanwhile, I'll get more information about how to solve this licensing issue. 
SynapseGlobal sounds a good solution, but give license for special 
implementation (such as Asterisk's one). And there is maybe a little trick with 
the fact that a exception to GPL has to be added in code license to allow the 
*distribution* with the G729 license.

Original comment by r3gis...@gmail.com on 26 Jul 2010 at 12:31

[GoogleCodeExporter]

I also agree that g729 would improve voice quality! What is the situation now 
with project?

Original comment by jar...@gmail.com on 16 Aug 2010 at 9:22

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi r3gis.3R , 

   When i build project (include g729 ) with ndk i recived "Error: selected processor does not support `smulbb" so i don't know how to Solved it  , so please send me your g729 source code project , my mail is bravechou2009@gmail.com thanks in advance!!!!!!!!!!!!!!!!!!!!!!!!!

Original comment by bravecho...@gmail.com on 24 Aug 2010 at 6:20

[GoogleCodeExporter]

Hi r3gis.3R ,

Would you please send me your g729 source code project too? My mail is 
mgshuter@gmail.com   

Thank you so much!!

Best Regards,
Arthur Chiang

Original comment by mgshu...@gmail.com on 25 Aug 2010 at 6:08

[GoogleCodeExporter]

I support work on adding g729 to CSIPSIMPLE.  This would put it far ahead of 
other open source SIP apps for Android.  My VOIP provider only seems to support 
the g729 codec, so it is somewhat of a key feature for me.

I don't know the first thing about compiling, but I can offer to test builds on 
my HTC Hero running VillainRom 10.3.2 (Android OS 2.1)

Original comment by ben...@gmail.com on 26 Aug 2010 at 8:24

[GoogleCodeExporter]

I think it's ok to include g729 codec without additional fee as all SIP 
providers already paid license fees. Mine (sipnet.ru) already gives windows 
softphone with g729 codec for free. 

Original comment by xnov...@gmail.com on 4 Sep 2010 at 9:00

[GoogleCodeExporter]

G729 codec is essential in Voip. I propose to make it a paid add on like the 
bria softphone in the apple store.

Original comment by dcitele...@gmail.com on 9 Sep 2010 at 9:57

[GoogleCodeExporter]

IMHO you should include it disabled by default for those who already have a 
G729 license making this clear on the about menu, that is if they don't require 
any GPL exception.

Original comment by marcu...@gmail.com on 18 Sep 2010 at 1:25

[GoogleCodeExporter]

> In the case I get a solution to manage the license, the best solution is to 
provide a plugin app on the market that provide an updated version of the 
dynamic library. Some changes has to be done in the update process but that was 
already planned.

I am willing to pay for the plugin in the future, if that works for the 
licensor(s).

Original comment by huan...@gmail.com on 21 Sep 2010 at 4:49

[GoogleCodeExporter]

+1 g729 codec support..wiiling to pay 

Original comment by jefb...@gmail.com on 25 Sep 2010 at 3:40

[GoogleCodeExporter]

I too am willing to pay for g729

Original comment by zveda2000@gmail.com on 2 Oct 2010 at 3:35

[GoogleCodeExporter]

I'm also willing to pay. need this bad.

Original comment by waiz...@gmail.com on 21 Oct 2010 at 11:21

[GoogleCodeExporter]

I am willing to pay also... PLEASE get this working.

Original comment by j...@iostechs.com on 25 Oct 2010 at 9:26

[GoogleCodeExporter]

At this stage, can we please be advised when we shall be getting the G729 codec 
on cSipSimple? I need to take some urgent decisions and need to know this 
urgently. Cheers Sunil (bediskb@yahoo.com)

Original comment by akshykb...@gmail.com on 26 Oct 2010 at 7:28

[GoogleCodeExporter]

Again that's just a licensing issue for me. Code is functional.
However it will take me time to find the good and ethical way to release and 
distribute this code.

It's really hard to say when I'll be able to distribute something. So do not 
make plan that rely on csipsimple .... already I would say that choosing g729 
to make business that rely on opensource solutions is a bad idea.
And last point I'm not sure that you are absolutely aware about the fact 
CSipSimple is and will remain Gpl. Which mean the core app if modified should 
be fully redistributed.

Ilbc is a good alternative to g729...

Original comment by r3gis...@gmail.com on 26 Oct 2010 at 9:06

[GoogleCodeExporter]

Now I use another client app with my hero 2.1, the VoipSwitch (I do not say if 
assembly compiled, or java), that is on android market. 
I pay it, i think, for g729 licence.
Could I use csipsimple with that licence? 
I need csipsimple facility (multiple account registration etc).
Thanks

Original comment by markmar1...@gmail.com on 27 Oct 2010 at 1:56

[GoogleCodeExporter]

r3gis, you should pay for g729 ONLY if you recode something with it. g729 
pass-through is free.

Original comment by zdevel on 27 Oct 2010 at 1:59

[GoogleCodeExporter]

Actually, the problem is that g729 "usage" is not free. 
So distributing it encouraging it's usage without paying the license could be 
attacked.
So usually what is done is :
 * Either your sip provider give you the app with G729 (they already pay for G729 channels usage)
 * Or if it's an app that is generic, it is distributed included the g729 licensing fee.

But well, I'm about to find a good way to distribute the plugin with g729. Just 
be patient... It took time to convince guys I'm talking to to distribute it...
Once there will be a way for users to get the app + the licensing fee, I'll be 
free to distribute my source code without any risk.
So just be patient guys ;)... You'll probably have to pay for the fee (maybe 
less than the g729 fee if I can convince guys I'm talking to), OR, get the 
plugin to the app distributed by another sip provider for free if they already 
pay for their users, OR, build the app by your own means and use it for tests 
(or for an usage in which you are sure somebody has pay the license usage for 
you). 

Original comment by r3gis...@gmail.com on 27 Oct 2010 at 2:16

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

> Ilbc is a good alternative to g729...

I wish I could use it.

Not with phones that don't have FPU, as Ilbc doesn't have a fixed point 
implementation.

Maybe it will be a non-issue in just a matter of months... as we're getting 
more powerful phones.

Original comment by huan...@gmail.com on 30 Oct 2010 at 8:18

[GoogleCodeExporter]

Please, please distribute the g729 source code if it works, just like the 
author of siphon. Thank you very much.

Original comment by Puzzle.W...@gmail.com on 9 Nov 2010 at 12:43

[GoogleCodeExporter]

Issue 385 has been merged into this issue.

Original comment by r3gis...@gmail.com on 22 Nov 2010 at 9:22

[GoogleCodeExporter]

Thanks!  I'll also pass this to the provider.  Why does SIP-SIP calls work 
then?  It's only SIP-landline and SIP-mobile (or vice versa) that doesn't.
And I agree that G729 is essential for VoIP.  If you require any 3rd party 
testing, I'll be happy to assist.

Original comment by willieme...@gmail.com on 23 Nov 2010 at 5:39

[GoogleCodeExporter]

Sip to sip works cause codec negotiation is done between the two clients while 
landline calls use your restrictive sip provider gateway that only support g729.

Original comment by r3gis...@gmail.com on 23 Nov 2010 at 7:05

[GoogleCodeExporter]

Thanks!  That makes sense.  Understood.  Please keep us updated on your 
progress with implementing G729 on CSipSimple :-)

Original comment by willieme...@gmail.com on 23 Nov 2010 at 7:14

[GoogleCodeExporter]

Is there any possibility to make more performant the ilbc codec on armv6 
processor with vfp? maybe some build option?
Armv6 seem to be the more widely diffused processors on commercial devices (not 
high end), and Ilbc has a GPL licence, and better quality expecially on 3g 
considering the low bitrate and the high robustness to packet loss. 

Original comment by Gianluca...@gmail.com on 23 Nov 2010 at 11:25

[GoogleCodeExporter]

@Gianluca : the GPL version only support floating point implementation. There 
is an implementation from Nokia (not absolutely sure that's nokia, but a big 
device manufacturer), that support fixed point. But that's not opensource. If 
you can find an opensource and gpl compatible implementation of iLBC, I can try 
to port it. But for now AFAIK, the only one is floating point (and without any 
build option to support fix point).
However maybe something could be tried on some armv6 devices that actually 
support floating points. The tricky thing is that the android NDK disable 
floating point for armv6 but some devices actually support it. So maybe the 
floating point implementation could be built on armv6 but will not be portable.

Original comment by r3gis...@gmail.com on 23 Nov 2010 at 12:02

[GoogleCodeExporter]

Thanks for your reply.
My hope was that the NDK could build for armv6 with vfp (FPU) that seems the 
most popular processor.
But it seems not a good idea for portability, if you can not produce a 
'Universal' apk as RockPlayer (a video player on the market).
Looking at the link to the apk http://updates.anplayer.com/rockplayer/ they
seem to distribute in a single apk three .so build.
But maybe I do not know what I'm saying. I do not know the NDK and more

Original comment by Gianluca...@gmail.com on 23 Nov 2010 at 12:32

[GoogleCodeExporter]

My distribution mode of apk are much more clever than universal package :

The apk doesn't contains the library it the library is retrieved by the device 
at first run. So it's really not a problem for me to distribute some custom lib 
optimized for some device. (Even better, I can produce a lib by device, at the 
first step of the project I did that cause I used private API).
So I can do almost everything I want with my modified version of the NDK and my 
distribution mode (I'm able to support armv4t with the same apk available on 
the android market... which is not the case of most of the android apps). The 
other good side of my method is that the distributed apk is not an heavy 
package with a lot of native lib versions.

The biggest deal is to detect if the CPU will support or not floating point. 
And that could be really tricky ! In the android API we have only the 
information about the thumb support version (which is not always relevant - for 
example armv4t devices). 
However I can divert the library downloaded at first run and update according 
to the device name for example or anything available on the android API.
That was the sens of my last remark. If I do a custom build for armv6 with vfp, 
it will not be portable to all devices as it. I'll add to populate my manifest 
with devices that actually support vfp.

Original comment by r3gis...@gmail.com on 23 Nov 2010 at 1:00

[GoogleCodeExporter]

Thanks for the clarification, I had not thought about this interesting aspect 
of the application.
It would be nice to use the application taking full advantage of the device 
hardware. Csipsimple is definitely the best SIP client on Android.
Thank you for your work.

Original comment by Gianluca...@gmail.com on 23 Nov 2010 at 1:28

[GoogleCodeExporter]

G729 would be great to conect to sipura gateways with a low bandwidth codec.  I 
have a spa3102 and there are no low bandwidth codecs compatible with CSipSimple 
and spa3102, so I have to transcode with my pbx, which introduces some delay 
and potential problems like packets loss.  I would be willing to pay for the 
license.

Original comment by JRam...@gmail.com on 25 Nov 2010 at 10:25

[GoogleCodeExporter]

@ r3gis.3R

Maybe you can create same thing as CounterPath with Bria Android edition? That 
G729 could be optional and user can buy it if want. 

http://www.counterpath.com/bria-android-edition.html?utm_source=xlite&utm_medium
=banner&utm_campaign=nov2010&utm_content=android_app

Original comment by jar...@gmail.com on 25 Nov 2010 at 10:29

[GoogleCodeExporter]

@jarsiv, indeed, that's what I'll do.
It will be included in next release on the android market.
0.00-16 will bring g729 as an optional codec with an big warning about the 
responsibility the user take by activating it and with a link to somewhere he 
can buy the license if his sip provider doesn't already pay it for him.

Original comment by r3gis...@gmail.com on 25 Nov 2010 at 12:14