Vitelity - best configuration; muddy audio

[jerrymaynor]

I have a problem with "muddy" (low treble) audio on some outbound calls so decided to re-check my Vitelity setup. I took a good look at the support page and saw that there are 3 options for Asterisk system setup instructions - Trixbox, Asterisk and the wizard (which gives an option for TB and * but not PiaF). I'm set up now using the Trixbox instructions...is that the best configuration for PiaF?

Are there other things to look at to improve my audio quality? It seems to only impact the inbound audio...I'm clear to the called party usually. I've played around some with differnent codecs but not a lot.

 

[wardmundy]

trixbox setup should be fine. They also use FreePBX albeit camouflaged. You basically create two trunks: vitel-inbound and vitel-outbound.

In vitel-inbound, fill in the Outbound Settings section of the form only:

disallow=all
allow=ulaw
canreinvite=no
context=vitelity-incoming
host=inbound1.vitelity.net
insecure=port,invite
secret=**yourpasswordhere**
t38pt_rtp=no
t38pt_tcp=no
t38pt_udptl=no
type=friend
username=**yourusernamehere**

For the Registration string, enter the following:

username[email protected]:5060/**yourDIDnumber**

In vitel-outbound, fill in the Outbound Settings section of the form only:

disallow=all
allow=ulaw
canreinvite=no
context=from-pstn
fromuser=**yourusernamehere**
host=outbound1.vitelity.net
secret=**yourpasswordhere**
sendrpid=yes
trustrpid=yes
type=friend
username=**yourusernamehere**

 

[kenn10]

I have a problem with "muddy" (low treble) audio on some outbound calls.

There are also some rate centers with Vitelity that are grossly inadequate (either from low bandwidth to the softswitch there or some other problem.) I have one area that the call usually gets shunted down to g.729 and still breaks up. I've had to create routes to send the call via another carrier to those exchanges in that area code.

Ward's instructions for the trunks will give you the best possible configuration but understand that if you have problems in certain areas, make a note of them and open a ticket with Vitelity.

 

[jroper]

Hi

Not related to audio, but is this setting appropriate in 1.4?

insecure=very

I thought that had been deprecated, and its replacement was:-

insecure=port,invite

Joe

 

[stuck]

There are also some rate centers with Vitelity that are grossly inadequate (either from low bandwidth to the softswitch there or some other problem.) I have one area that the call usually gets shunted down to g.729 and still breaks up. I've had to create routes to send the call via another carrier to those exchanges in that area code.

I'm experiencing some of that "rate center" problem right now. over past couple of days, quality was very choppy. They insisted that it was my problem, eventhough I explained to them that I have other vitelity DID's that sound perfect with the exact same settings on the same server.
Then this AM, calls on those choppy DID's don't even route to my servers at all. They finally admitted they're having problems with one of their providers.

 

[Fortel]

On Friday, inbound calls to our Vitelity DIDs would fail- never reached our * servers. Callers dialing the DIDs would simply be disconnected. These are Northern California numbers.

Vitelity is typically very good. On occasion, they have a problem.

Today it is happening again. Ugg. Vitelity says it's a problem with one of their vendors. Looking through the long list of trouble tickets we've had to open, they seem to have a lot of problems with their vendor(s.) I wonder if another provider is any better?

The PSTN sure looks good on days like this.

 

[wardmundy]

Stay tuned. We hope to have another option for you next week. The trick is to have several good providers. When you're paying by the minute, it really doesn't matter. If it's a business, NEVER trust your primary inbound DID to a VoIP provider, period, end of paragraph.

 

[ITHelpCenter]

Had the same problem with Vitelity today for at least 4 hours. We are sophisticated technically (albeit new to the VoiP world) but were still pretty convinced the problem was with the provider. There were periods where call after inbound call would not appear at the T1. A Vitelity trouble ticket went unanswered so I called their support number. It rang with a fast busy!! At least they are victims of their own problems, too. Thank goodness Joe Roper was at hand to provide background support and confirm our suspicions. Later my Vitelity ticket had the response.

One of our vendors is currently experiencing technical difficulty - we are working with them now and expect to have this resolved shortly. We thank you for your patience and apologize for any inconvenience this may cause. We will update this ticket as soon as possible.

How comforting when your end user experiencing the pain and you are in the middle, unfortunately this has been our second outage in 2 weeks.