Busy Signal Outgoing Calls

[chevyman]

Also worth noting...we've noticed on a few users that if their device is sending too much info in the headers it can cause the MTU to be too big in the headers and cause issues. We control this on our ATAs to limit the amount of info they send but if you have BYOD devices configured to send things like codecs we don't support, a name in the from header, etc it could push it over the MTU limit in the headers and cause a busy signal or call failure.

I TOO have been asking for configuration setting to set my customer's ATAs, I have posted here and ask in trouble tickets But over the years I never get the answers, like it's Top Secret! and over this last week i have been looking at other providers, which they all list the settings for there systems.

Like on 'sip' if i do *21 or *20 i get "busy signal" but the command goes through anyway. But if i change to 'sip7' without changing any settings and do the *21 or *20 i get the response "Thank You" every time.

So TIM when is Voipo going to give resellers the configuration settings needed to support there customers!

[VOIPoTim]

I TOO have been asking for configuration setting to set my customer's ATAs, I have posted here and ask in trouble tickets But over the years I never get the answers, like it's Top Secret! and over this last week i have been looking at other providers, which they all list the settings for there systems.

Like on 'sip' if i do *21 or *20 i get "busy signal" but the command goes through anyway. But if i change to 'sip7' without changing any settings and do the *21 or *20 i get the response "Thank You" every time.

So TIM when is Voipo going to give resellers the configuration settings needed to support there customers!

Just contact reseller@voipo.com with any questions you have and we'll be happy to help.

In terms of my post above about codecs, we only support the G.711 codec so it's best to disable any others on your device so it doesn't even attempt to negotiate anything else.

[chevyman]

Just contact reseller@voipo.com with any questions you have and we'll be happy to help.

In terms of my post above about codecs, we only support the G.711 codec so it's best to disable any others on your device so it doesn't even attempt to negotiate anything else.

So are they going to give a list of the configuration settings needed?

what about my question about the *21 or *20 issue?

[VOIPoTim]

So are they going to give a list of the configuration settings needed?

what about my question about the *21 or *20 issue?

In terms of * codes, that sounds like a DTMF setting where it's being recognized on one and not the other...just e-mail and ask support what you should have your DTMF set to...I'm honestly not sure which method we use...too technical for me.

In terms of other settings, I'm not sure what you're really needing. Your device may have lots of settings, but the ones ones that are rally needed are the SIP info, codec info, and DTMF info. There's nothing else really to provide since the rest are just built into the device and up to you whether you choose to use them or not. We can't get into all the special settings each device has since they have nothing to do with us or our service.

Just contact reseller support about the DTMF tone question and also if you have any specific questions about the basic settings and we'll be happy to help.

[GreenLantern]

One thing I would recommend is to buy one of the voipo provisioned ATAs.

Log in using the admin password.

Take screenshots of the various settings pages, as provisioned by Voipo.

Now you have a Voipo reference in PDF format, complete with labels and settings.

I haven't come across any major settings that I couldn't determine from there. Everything else is pretty much your preference, or defined by your local network situation.

In my experience, very few call drop/quality issues are due to the device, or even with voipo's service (except for specific account or route issues like the infamous route treatments, which seems to have been resolved by firing bad upstream carriers).

Most connectivity, registration and call drop issues are actually due to misconfigured, or non-voip-friendly routers/firewalls.

And most call quality issues are due to what I call bandwidth clipping... which is when users do not have enough "available" bandwidth, often due to non-voip apps/devices that are tying it up.

*** "Available" bandwidth is often very different from "idle" or "max" or "but I'm paying for X amount of" bandwidth. ***

That's why I'm very excited that voipo seems to have nailed down this TCP flooding issue. If so, I may finally be able to trust that the voipo network is not the problem.

So if I get connectivity or quality issues, I can have reasonable confidence that it is an issue at the end user's location, and focus my efforts there.

[burris]

Good post..

Just some question?...

For those who provision their own ATAs, what are you telling them to do with opening ports.

Years ago Brendan told me to port forward 5400-65000 pointed to my ATA and since then, except for a burp here and there, I don't recall any related problems.
Some are concerned about opening so many ports, but it hasn't affected me in any way that I am aware of yet.
Having come from the world of POTS, I can fully understand the routing problems. In order to compete in either the POTS or VOIP world, we had to select the least cost routing, knowning that when a customer has a connection problem, we would immediately choose another carrier until the problems were resolved.

What are your thoughts on this? I was never keen on using DMZ

[chevyman]

In terms of * codes, that sounds like a DTMF setting where it's being recognized on one and not the other...just e-mail and ask support what you should have your DTMF set to...I'm honestly not sure which method we use...too technical for me.

In terms of other settings, I'm not sure what you're really needing. Your device may have lots of settings, but the ones ones that are rally needed are the SIP info, codec info, and DTMF info. There's nothing else really to provide since the rest are just built into the device and up to you whether you choose to use them or not. We can't get into all the special settings each device has since they have nothing to do with us or our service.

Just contact reseller support about the DTMF tone question and also if you have any specific questions about the basic settings and we'll be happy to help.

Tim

Its not DTMF, on sip.voipwelcome.com when doing say *20+(Phone number) or *21 i get a busy signal response, but the code still goes through and forward/un-forward the number. Now with the same configuration, ONLY change is to sip7.voipwelcome.com I get the "Thank You" response to the *20+(Phone number) or *21.

So something is different with the sip.voipwelcome.com & sip7.voipwelcome.com servers. Also this does the same with Voipo ATA you guys sent me years ago.

Also i found out with sip7.voipwelcome.com i have to set DTMF to "In audio" and on sip.voipwelcome.com i have to set DTMF to "RFC2833" for digits to be recognized on the Voice Mail System (123).

So something is different between the two sip's.

[racerdude]

Also for what it's worth, we are in the midst of expanding the BYOD network with several new servers for you guys to choose from so there will be more choices in more DCs for you guys soon.

This is great news Tim! Will there be one located close to Los Angeles and if so, are you planning on configuring these new servers like sip7 in which the audio is also proxied from the same server? And you mentioned earlier about the headers from BYOD devices, should we enable "compact headers" if our device supports it or does that setting make any difference?

[VOIPoTim]

This is great news Tim! Will there be one located close to Los Angeles and if so, are you planning on configuring these new servers like sip7 in which the audio is also proxied from the same server? And you mentioned earlier about the headers from BYOD devices, should we enable "compact headers" if our device supports it or does that setting make any difference?

Not 100% sure on locations yet, we've been testing a few options. We are planning to have the audio stream from the same location as the SIP server since it makes more sense if someone has a better connection to a certain datacenter that their audio goes through it too.

I'm not 100% and would need to check with my devs but I think compact headers would be preferred. Basically the less sent in headers the better.

[VOIPoTim]

Tim

Its not DTMF, on sip.voipwelcome.com when doing say *20+(Phone number) or *21 i get a busy signal response, but the code still goes through and forward/un-forward the number. Now with the same configuration, ONLY change is to sip7.voipwelcome.com I get the "Thank You" response to the *20+(Phone number) or *21.

So something is different with the sip.voipwelcome.com & sip7.voipwelcome.com servers. Also this does the same with Voipo ATA you guys sent me years ago.

Also i found out with sip7.voipwelcome.com i have to set DTMF to "In audio" and on sip.voipwelcome.com i have to set DTMF to "RFC2833" for digits to be recognized on the Voice Mail System (123).

So something is different between the two sip's.

I would open a ticket on this. They actually both use the same voicemail server so it sounds like that could be a bug. Please open a ticket with details and be sure to tell them how to replicate it and our devs can look into it for you.