The license is not the problem, the problem is that you cannot send faxes using G729. Also when using G729 we found that asterisk is prone to “deadlock” under heavy load , therefore we do not use it in a production environment.[/code]
And then my response to that:
So my question to all of you is does his reasoning have any merit (other than faxing, which is obvious)?
Indeed, g729 is not good for fax but good for voice conversations. I have not heard of it being the culprit of ‘deadlocking’ Asterisk. Sounds like an excuse unless they may back it up with a pointer to a bug in Asterisk.
Don’t know if this is relevant, but I used to use G729 a lot, but found it not at all tolerant of packet loss. I’ve reverted to using G711a with much happier customers.
Well I’m using local cable for my 'net connection (1024kb/s upstream), so I want to at least test it out so that I can attempt reducing my bandwidth usage. 64kbps vs 8 kbps is a huge difference. Theoretically even though packet loss has more of an effect on G.729, there should be half as much.
[quote=“naughtyusmaximus”]I sent the following email to my VoIP provider:
The response I received was as follows:
[code]Sorry, but no.
The license is not the problem, the problem is that you cannot send faxes using G729. Also when using G729 we found that asterisk is prone to “deadlock” under heavy load , therefore we do not use it in a production environment.[/code]
[/quote]
I am sure they refer to “deadlock under heavy load” as a way of saying that the G729 codec is to heavy on CPU consumption. As far as I have seen the G729 codec is the one that uses most rescources when coding/decoding.
So your VoIP provider have dicided that the G729 will force them to upgrade HW, hence if they stay with less CPU intensive codec they will do just fine with excisting HW.
Might not be for all I know, as english is not my native tongue:-)
But there is no coming around that the harder you compress the audio the more rescoruces [CPU] is needed to code/decode the audio, hence my interperation/assumption. Also remember that all coding/decoding is bound to take place in real-time, with a minimal time-delay in order for this to work.
If deadlock is used as in “freeze/unresponsive” server I can tell you that is plain bullocks. Many many has sucessfully implementet G729 codec in production enviroment.
If any other has had trouble using the G729 please let us know. Cause as of now I for certain am not aware of problems other then heavy resource usage, and that can hardly be adressed as a problem as long as it is in the codecs nature to compress hard.