VoIP One-way Audio and Voice drops
-
I almost hate to resurrect an ancient topic, but all of these issues have been resolved, and I would be amiss to not do a post-mortem on the whole resolution.
I think some of the problems with call quality went away, but there was still a lot of trouble with outgoing calls failing (mostly in the afternoon). What we came to realize was that Vitelity (SIP provider) required, but never stated, that it was necessary to have separate trunks set up for inbound and outbound calls. While their site provided the inbound PEER info, there was no posted settings (at least, that any of us could find) dictating the outbound call trunk configuration.
What was happening was that any outbound packets were being de-prioritized to guarantee inbound traffic. From the logs, you just saw that the call went out and got refused by their SIP server. We ended up working with support to learn that we needed an outbound trunk. After setting up the trunk (guessing; they gave us no details) and having the problem persist, we were finally able to give them the trunk settings, which they looked at and said "oh, this isn't correct" and gave us the right configuration. Suddenly, all of our troubles vanished.
I was unaware that certain SIP providers require a trunk for inbound and also outbound traffic.
There was also a secondary issue, which may have played into the latency that was experienced. This has also since been resolved. We had a bottleneck inside the LAN, as a group of switches for all of the users was connected to the "servers" switch, where the PBX lives, with a single 1gbit connection, as well as the gateway connection. Old switches (un-stackable) and physical location had a bit to do with the layout. Once we upgraded to a stack of Netgear S3300's and included the gateway, servers, and users in the "stack", the latency disappeared.
-
That's very good Vitelity information to have. Would be crappy to face that same problem again due to a lack of documentation.
-
I have never heard of a provider that required a separate trunk for inbound and outbound. that is just crazy.
-
And unexpected. How do they expect you to know that you need that?
-
I'm glad that this got resolved. Good job @art_of_shred and @ntg!
-
@scottalanmiller said:
And unexpected. How do they expect you to know that you need that?
Especially when there is no documentation on their website to indicate that is the proper configuration.
-
FYI-
Inbound trunk settings for Vitelity:username=???
type=friend
secret=???
insecure=port,invite
host=inbound33.vitelity.net
dtmfmode=auto
context=from-trunk ; (this could be ext-did or from-pstn as well)
canreinvite=noRegister String:
<user>:<secret>@inbound33.vitelity.net:5060 -
FYI-
Outbound trunk settings for Vitelity:type=friend
dtmfmode=auto
host=outbound.vitelity.net
username=???
fromuser=???
secret=???
trustrpid=yes
sendrpid=yes
allow=all
canreinvite=noNo register string for outbound!
-
Thanks, those will help with any future Vitelity installs.
-
@JaredBusch said:
I have never heard of a provider that required a separate trunk for inbound and outbound. that is just crazy.
So, is this just a Vitelity issue? I know many SIP providers have their subtle differences, and you always seem to find them at the most inopportune moments.
