Jump to content

Can I upload Codec G729 in IVM?


laomedon

Recommended Posts

Hello,

 

Sometimes, the quality of the outbound calls is awfull.

 

I asked my sip provider why, an they answered me that the problem could be from the G729 codec missed.

 

How select the G729 codec for IVM?

 

If the problem of the quality of the outbound calls doesn't depend of the G729 codec, have you other hypothesys???

 

Thank You!

 

Alexandre (France, Lille)

Link to comment
Share on other sites

The G.729 codec cannot be used with IVM, nor any other NCH software. The reason being, it is a proprietary codec meaning that there is a license fee to use it and NCH has decide to only use free/open codecs for the software.

 

You don't need G.729 to fix your quality issues though, the only reason your VoIP provider recommended it is because it provides very good quality and requires relatively low bandwidth.

 

First you must try and define what you mean by poor audio quality. With VoIP there are 2 types of poor audio connections and they have completely different solutions, so it is important to figure out what the cause of the problem is.

 

Quality Type 1: Audio clarity. This is where the audio does not break up, stutter, or scramble, it is simply difficult to understand what the other person is saying and sounds like a they are holding a towel over the mouth piece.

-> Solution: Change to a higher bandwidth codec (or select the option in IVM to use 'higher bandwidth'). Higher bandwidth codecs typically offer much better audio clarity for clear, crisp sound however they do take up more bandwidth on your Internet connection and if that bandwidth is not available, you might have problem 2 (below).

 

Quality Type 2: Connection issues. This is where the audio randomly starts breaking up, skipping/missing words, stutters, or scrambles up. This is the result of using a codec that needs too much bandwidth, more bandwidth than is available on your connection. As a result, the audio packets can become lost, discarded, ignored (leaving blank/silent stutter spots in speech or missed words) or the audio packets can arrive at the receiving end in a mixed up order, resulting in scrambled speech.

-> Solution: Change to a lower bandwidth codec (or select the option in IVM to use 'lower bandwidth'). Lower bandwidth codecs, as the name suggest use much less bandwidth (e.g. 10kbps vs 80kbps) and are more suitable for slower connections, partially blocked connections, or congested (i.e. heavily used) connections.

 

 

Note that you can also solve many audio quality issues by doing the following:

 

1) Set-up port forwarding on your router and forward UDP ports 8,000 through 16,000 and TCP port 5060 through 5061 to your IVM computer.

2) If your router has the feature, enable QoS. QoS (or Quality of Service) can be used to give VoIP packets priority when they travel through your network. This ensures the audio packets are sent out to the Internet first and in the right order rather than having the router treat them like everything else which can lead to them being sent in the wrong order, or having random pauses while some web data is sent and the VoIP packets are put in queue to be sent later.

3) Run the built-in network set-up wizard in IVM

Link to comment
Share on other sites

It's ok, my new voip provider have change the configuration of our account to adapt it to the codec G711.

 

However, I have another problem now :

 

The persons who have outbound calls can't use the Key Response.

 

For example : Before, with the anscient voip provider, when a person received an outbound call he could leave message for mailbox pressing touch 1.

 

Now, with the new voip provider, when a person receive an outbound call and press the touch 1, nothing happens.

 

Thank You.

Link to comment
Share on other sites

This is probably because unlike analog systems where it is a simple 'tone' system for key responses, VoIP actually has about 3 or 4 different ways to send key responses to the other end (in this case IVM). If it is using an incompatible method, IVM will simply ignore the key presses.

 

See if your VoIP provider can adjust the DTMF options and try different settings to see if it will work.

Link to comment
Share on other sites

I'm sorry but my voip provider have try several tests yesterday, and he didn't reach to resolve the problem.

 

You say there are 3 - 4 ways to send key responses to the other end, could you detail a program of a compatible method (name, language, codec, process or other) to adapt the voip service with IVM?

 

Thank you

Link to comment
Share on other sites

RFC2833 is one of the ways I was talking about for transferring DTMF responses. I guess if IVM isn't receiving the responses, perhaps it doesn't support this method. Can your provider set it to a different option to try and find one that is compatible (the only other one I remember is SIP Info.. and I don't know which one(s) IVM supports).

Link to comment
Share on other sites

RFC2833 is one of the ways I was talking about for transferring DTMF responses. I guess if IVM isn't receiving the responses, perhaps it doesn't support this method. Can your provider set it to a different option to try and find one that is compatible (the only other one I remember is SIP Info.. and I don't know which one(s) IVM supports).

 

We support RFC2833 and In-band, but not SIP Info. Codecs supported are G.711u/a, G.726 and GSM. G.729 is not supported because it is a royalty-based codec.

 

If key responses aren't working then (assuming RFC2833 is being used), it's a 1-way audio issue. You can check this by enabling the SIP logging in properties for your SIP line in IVM (Advanced tab) and checking the logs to confirm this.

 

Port forwarding will only make an effect on the software if the software's networking wizard failed to find your external/public IP address when you installed or ran it. Since the software will already make use of either uPnP or STUN to resolve networking issues, running port forwarding at the same time may make the behaviour less predictable. So you should only run one or the other, but not both. If you want to keep port forwarding then you should enable the static IP option in the Networking tab of the SIP line properties. If you do this, also remember to keep the Local SIP/RTP and External SIP/RTP ports the same, or else you will get further problems (all these are also configurable in the Networking tab).

 

For audio issues we recommend you maintain talks with your VoIP provider in this circumstance because their gateway does a lot of the audio processing and they will normally have some good advice to offer in this area. Some providers say that they primarily support G.729 as a native standard and they have to transcode to other formats when necessary - this is one area where audio degradation can occur. Since G.711 is the only mandatory codec under the SIP standard, a good VoIP provider will support it natively on their gateway.

 

Your own Internet bandwidth is the other area where audio issues can occur. We support QoS by default in our software so check to see if your router supports it. Also make note of *both* your upload *and* download bandwidth, as VoIP requires both directions equally. G.711 for example needs up to 64kbps downstream and upstream equally. GSM needs only 8kbps, while G.726 needs 32kbps. If the stream of audio up/down through your router doesn't occur at the same sorts of speeds then this is another big area where audio degradation can occur.

 

You can also try a benchmark test of connecting the computer directly into the modem and see if the behaviour is any different (i.e. bypass the router).

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...