Android OS Forum banner
1 - 2 of 2 Posts

·
Premium Member
Joined
·
1,812 Posts
G.729 is the more common light weight protocol. But it is patent encumbered and typically requires some type of license for an app to use it. Thus, it's not common to see G.729 in an open source/free app.

I do a lot of VoIP with my business stuff, but I've only briefly messed with VoIP and Android. I know you want to use the built-in dialer, but if you can get one that supports G.729, I think it would be worth it.

Of course, you would also have to deal with the G.729 license issue on your PBXes.org system as well. Digium sells G.729 licenses for Asterisk at $10.00 per channel. I'm not sure what type of access you have on the pbxes.org account (you would need to be able to load the driver and license file from the command line.

Also, if you search a little bit, there are some 'free for testing purposes' pre-compiled g.729 drivers out there.

EDIT: G.729 and asterisk may not need an actual license, depending on what you are doing. If Asterisk is just bridging the channel, and passing the data through unchanged, then you can do that without a license. If asterisk has to do any transcoding or generation, then it would need the license (ie, voice-mail). So if you are just picking up calls and forwarding them to the phone, with no voice-mail, IVR, etc, you might be able to avoid a g.729 license on the asterisk server.
 

·
Premium Member
Joined
·
1,812 Posts
Just to add a little clarity here. You may want to use TCP for signaling, but definitely not for the voice stream. TCP is a 'guaranteed' delivery protocol. It requires an acknowledgement from the receiver. Thus, you increase the overhead/bandwidth, and slow down the delivery. UDP is just sent by the sender without any regard to its arrival at the destination. It's your best option for any streaming media. The receiving end will simply drop packets/information (ie, a small drop in the conversation, a few missed frames on a video, etc) for any parts of the stream that don't arrive within the timing windows necessary.

UDP will suffer quality issues on a bad connection, but may still work. TCP will simply shutdown on a bad connection, and cost you bandwidth on top of it. Might also make an otherwise acceptable connection completely unusable.
 
1 - 2 of 2 Posts
Top