Busy Signal Outgoing Calls

[chevyman]

All my reseller lines are getting a busy signal on Outgoing calls.

Are other resellers having this problem too?

[VOIPoBrandon]

Hello,

I was able to locate your ticket and a call sample, it appears that one of our upstream carriers has enabled compact SIP headers -- and we are not receiving an ACK from your UAC after the call connects. We've temporarily disabled this carrier and are looking into mangling the compact headers back into their original form as it is likely that your UAC may not support compact headers due to its failure to respond. Let me know if your issues are not now resolved, thanks!

[jsiepka]

Yes, I have been getting a lot of complaints about this issue. It seems lately I've been putting more time into trouble shooting issues and dealing with hostile customers.

[GreenLantern]

Yes,

When SIP7 went down the other day, I had to move a bunch of customers over to the main SIP server.

Then, I spent most of yesterday answering support calls and moving those same customers back to SIP7, which didn't seem to suffer from whatever issue SIP was having.

Unfortunately, I really don't have the tools, knowledge or access to do much more than guess what is happening.

So the following are just some basic observations and guesses.

It seems it is mostly Comcast customers who have issues with the SIP server. A few customers using Charter, Cox and Time Warner have also had issues with SIP. I have even had one or two Verizon Fios customers who've had issue with SIP server.

And of course, not all customers using these ISPs have trouble with SIP server. However, for those that do have trouble, moving to SIP7 works like a charm (except when it went down completely the other day).

It may be coincidence, but I believe most of those ISPs use Level3 for their backbone connections. That makes me wonder if the SIP data center has some weird route to Level3. SIP7 being in a different data center, hosted by a totally different company, could potentially have a better route.

Or, it could simply be something different that voipo is doing (or not doing) at SIP7 that makes it work better.

I will say this. Other than when SIP7 went down completely the other day, I've never had a setup that wouldn't work perfectly on SIP7.

Again, hard to know what is up from the outside, but there is absolutely a difference between SIP and SIP7.

[chevyman]

well they told me to change all my accounts to sip7, I can't spend all day driving to all my customers about 150 miles to change this. Plus sip7 gives alot of my accounts over 100ms ping times

[GreenLantern]

At some point, I'd love to see support for our own domains (hint hint for Tim :) ), so that we can quickly and easily change customers to a different server if one or the other is down.

[jsiepka]

99% of my clients are using Comcast. SIP7 worked great until I had to move them to SIP due to the SIP7 outage. Now on SIP I get busy signals consistently. Putting a ticket in doesn't help when I have a tech onsite. My customers ask why do I have to wait for support from our carrier, why can't you call someone while the tech is onsite. I have setup a syslog server and receive debugging information but being on the outside looking in I cannot fix any of the issues. There is no one I can call to work on the problems when I need to work on them. I wish I could afford to sit and wait for a reply to my tickets but in reality I have to move on to the next task just like Voipo.

Greenlantern even if we had support for our own domains it is still a process to figure out the issue, find the corrective action, then implement the changes. I shouldn't have to wait for my clients to complain, then try to figure out the exact call so I can get the Call Reference ID, and that's assuming the call completed and is listed in the call history, create a ticket, wait for a response, hope my client is available to see if the fix worked, then report back.

I have been working on a solution to monitor my clients so that I can anticipate issues and implement corrective measures before my clients even know there is a problem. So far 99% of the issues we experience the corrective action has to be done at the carrier level just like this issue with compact sip headers. And since the issues are at the carrier level for me to monitor and implement corrective actions I would thus have to become a company like Voipo, which is not in my scope.

Ok I'm done venting :)

[chevyman]

I have asked Voipo for configuration files or a list of the configuration settings so i can set the proper settings for Voipo system. But i get no where with it, but yet i have to support my customers in the blind. I starting to think this reseller account is a lost cause.

[chevyman]

after trying sip7 now, the *-codes' "voice confirmation-tone" works every time. So i don't know what the big difference is between the sip & sip7 addresses, something is going on with there configurations.

[chevyman]

Is anyone getting any support on this issue, all i'm getting from support is they can't replicate the issue, answer!

and now i'm having trouble with one of my lines that is set to forward to a cell phone is going to VM, (they can't say that is my equipment problem!)

[GreenLantern]

Chevy, what ISP is involved? Is this one of the cable providers? Comcast, TWC, Charter, Cox, etc?

I'm getting sporadic reports of busy on outbound as well, mostly from customers using one of those cable services.

Most of it seems to go away when I move them to SIP7.

I suspect voipo can't duplicate it, because they are not able to test via Comcast, Time Warner, etc. But I can't confirm that.

[GreenLantern]

I just had another customer call for support this morning.

I had switched them from SIP7 to SIP during the SIP7 outage.

Not long after the switch, they started having trouble with busy signals on outbound calls, and also trouble getting voicemail.

I switched them back to SIP7 and all problems solved.

They are using Comcast for internet.

There definitely seems to be some issue between some Comcast users (and some other cable users) and the SIP server, but SIP7 works for them.

[wingsohot]

I just had another customer call for support this morning.

I had switched them from SIP7 to SIP during the SIP7 outage.

Not long after the switch, they started having trouble with busy signals on outbound calls, and also trouble getting voicemail.

I switched them back to SIP7 and all problems solved.

They are using Comcast for internet.

There definitely seems to be some issue between some Comcast users (and some other cable users) and the SIP server, but SIP7 works for them.

This may be a stupid question, but, how do you switch your customers to sip7 from your end?

[GreenLantern]

Most of my customers are using byod devices. So if I'm lucky, I can simply instruct them to change the address in their device. But for less tech savvy customers, I have to log in remotely and do it for them... which is a big pain when a bunch all need to be switched on the same day.

That is why I wish we could map our own domains. We could change the mapping at anytime, to redirect an entire group of customers to a different server.

I'm able to do that with another voip service, and it works perfectly.

[GreenLantern]

We've had to switch several more comcast users back over to SIP7 today.

I have an open ticket for another comcast user who is suffering from various outbound calling issues. I'm leaving them on SIP for now, in hopes that support can resolve these issues. I may have to move them to SIP7 soon though, if no other solution can be found.

Interesting thing is that they have been using the regular SIP server for a fairly long time (a year or more) without issues, until this past week or two. Now they are suddenly having trouble like so many others.

[chevyman]

Chevy, what ISP is involved? Is this one of the cable providers? Comcast, TWC, Charter, Cox, etc?

I'm getting sporadic reports of busy on outbound as well, mostly from customers using one of those cable services.

Most of it seems to go away when I move them to SIP7.

I suspect voipo can't duplicate it, because they are not able to test via Comcast, Time Warner, etc. But I can't confirm that.

sorry i didn't back sooner just got done doing a 31 hour server upgrade.

the busy calls are going to Comcast, sprint, t-mobile, vonagebusiness and 800 numbers to name a few, i don't think it matters, but i know calls to other Voipo numbers don't get a busy.

One thing i have been fighting with Voipo on is the *codes, that every time i do a star-code i get a busy signal even though the code went through and sometimes i would get the "Thank You" response.

Now switching to the sip7 the busy has gone away and i get the "thank you" on every *-code.

Today i had a VM and went to delete it with "7" and nothing happen it just kept playing it so i hung up the phone, then a minute later the message light went out.

I'm loosing faith in Voipo

[chevyman]

As for what internet service some of my customers use, one is a small town cable, centurylink and i tried at&t wireless android app was doing it.

[GreenLantern]

Are they using a particular voip device? Or does that vary as well?

[chevyman]

GL

They are using different voip devices mostly business voip phones. I also found out the 'digits' are not working on VM so I had to change the sip7 ones to 'inband'.
Plus the old sip.voipwelcome.com they are getting busy signal to VM too, which is strange as calls going to Voipo wasn't doing the busy problem.

[chevyman]

now i'm having problems with sip7! can't make any calls and registration is flaky.

I just did a trace of sip and sip7 and they are both going to chicago to some company liquidweb.com and not to texas as its been for years, did Voipo change servers?

[GreenLantern]

yes, looks like they've remapped SIP to the north server, in Michigan I think.

whoever was attacking the texas server must have started hitting the michigan one too.

[VOIPoTim]

now i'm having problems with sip7! can't make any calls and registration is flaky.

I just did a trace of sip and sip7 and they are both going to chicago to some company liquidweb.com and not to texas as its been for years, did Voipo change servers?


Can you guys verify if you are having issues now?

We think we tracked it down and had an attack on our network that we believe has been firewalled out for good now.

Please let us know if you're seeing normal service or or still having issues.

[GreenLantern]

Can you guys verify if you are having issues now?

We think we tracked it down and had an attack on our network that we believe has been firewalled out for good now.

Please let us know if you're seeing normal service or or still having issues.

It has improved, but is still not back to normal.

I'm still getting some "unreachable" and "lagged" results on both servers, especially SIP7. :(

Example from right now...

sip 7 LAGGED (2405 ms)
sip OK (465 ms)
other provider 1 OK (25 ms)
other provider 2 OK (26 ms)

[GreenLantern]

texas server is also still lagging bad.

sip LAGGED (3178 ms)

[VOIPoBrandon]

Hello,

Please advise if you are not seeing this issue completely resolved at this point, thank you!

[chevyman]

Hello,

Please advise if you are not seeing this issue completely resolved at this point, thank you!

do you mean the busy signal on sip.voipwelcome.com & sip7.voipwelcome.com for the last week or what happen Today?

[VOIPoTim]

do you mean the busy signal on sip.voipwelcome.com & sip7.voipwelcome.com for the last week or what happen Today?

Everything should be back to normal on them. We mitigated what looked like an attack on them earlier in the week and discovered an issue with some users that were using TCP to register with instead of UDP and that was causing issues since TCP held all the packets and released them at once causing issues and delays for everyone. We disabled TCP registrations because everyone should be using UDP.

Between blocking the attack and disabling TCP registrations (which were causing a quasi-attack on their own), everything appears completely stable on our end now.

Reseller support load is now drastically lower than it has been all week with only some typical support issues that seem unrelated.

Greenlantern - We are looking at your ticket, but everything looks fine on our end. We even did a test on your accounts by registering to them and they worked fine. Brandon will get in touch with you.

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.

[GreenLantern]

Hi Tim,

Thanks for all the hard work you guys did the last few days. It was rough sledding, but things look great right now.

Any idea if/why these attacks are intentionally targeting voipo?

Great info on the MTU limits. We'll know now to look for extraneous info like extra codecs, names, etc. in case BYOD users add any of that.

Thanks again, and now everyone go perform your preferred good luck rituals.

[VOIPoTim]

Hi Tim,

Thanks for all the hard work you guys did the last few days. It was rough sledding, but things look great right now.

Any idea if/why these attacks are intentionally targeting voipo?

Great info on the MTU limits. We'll know now to look for extraneous info like extra codecs, names, etc. in case BYOD users add any of that.

Thanks again, and now everyone go perform your preferred good luck rituals.

The attacks hopefully should be mitigated. They weren't intentional...just certain BYOD devices causing loops (think forwarding back to itself spawning tens of thousands of calls). We have a lot of loop detection/prevention in place but there was a new case we'd never seen before where it was happening with devices connecting using TCP and registrations looping in a way.

So far everything seems to be smooth now. This was happening on SIP but not SIP7 but then at one point to isolate things earlier in week, we redirected a lot of traffic from SIP to SIP7 while we tested that server more thoroughly and that's why SIP7 started acting up too (the users that had devices looping got moved). Once we isolated it and blocked it, we got things back to normal and added in logic to prevent it.

Hopefully smooth sailing now.

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.

[jsiepka]

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.

In 2 years I have not seen anything to let us know how we are to have our devices setup. You say that we are using the incorrect Codecs, well we are trying to connect to you but we can't and the equipment is trying to figure out what Codec to use.

You do not offer the devices needed to support business class customers which forces me to use BYOD devices. The Grandstream ATA are absolute garbage! We have had an 80% failure rate (90% purchased through Voipo), but they are the cheapest ones around. I tried Patton Analog gateways with them locked to 711u and had the same connection issues. I switched to Cisco SPA8000 because they worked the best and easier to provision. And now you tell me after a year and a half later that I have them configured incorrectly? Really why couldn't you tell me that back then when I reached out to your tech support but instead I was told Voipo don't support BYOD. I didn't ask you to tell me how to program the SPA8000, I just needed to know what the problem was on your end so I could configure our SPA8000s accordingly.

I am still guessing if the problems are on my end or your end, I put in a ticket and give a time frame that we are experiencing issues with accounts and I get short responses that unless I provide a call reference number they cant help. Really? I can look right at the call logs on each account and tell you when they are having issues, simply its when they have 0 to 1 minute calls back to back to and from the same numbers.

In the past several weeks I have had many of my customers screaming, yes screaming at me about the service and after 2 years I am ready to throw the towel in. But I won't because I know this will work, the service does work, we just need more from our provider, our partner, to insure we provide great service. We need information from Voipo when the services are hindered BEFORE the customers start complaining. We need to know from you that you are receiving too much header information, or using the wrong Codecs BEFORE the customer starts complaining. I really want to stop the guess work, how am I supposed to work with you to insure my devices are configured and connecting correctly. I can't call anyone, and the ticketing system, well I know your techs are a busy as I am also, but its impossible to work on anything when you have to wait for a message that may come in the next few minutes or an hour or so. Not to mention if the calls go through then we assume its configured correctly.


just certain BYOD devices causing loops

I believe one of my accounts experienced this. I had a SPA8000 been in service for over a year, reconfigured it for a different account, worked fine for several months then in November and December highly intermittently we started receiving bogus incoming calls on all ports at the exact same time. The phone system would answer these calls by the thousands, and yes every call left a dead air voice mail message. I have pulled that unit out of service but not had the time to evaluate it on the bench to see if the unit is defective or if something else is causing the issues.

I also had another SPA8000 at a different location that I believed was hacked as this one was facing the public side directly. I know its very dangerous but I was seeing if the call drops were being caused by a router so we gave it a public IP address and put it outside the firewall. Thousands of calls out of state to the same area code and exchanges were made within seconds of each other. I was on location when it was happening and no one was using the phone, but hundreds of calls were being made. I pulled that SPA8000 out of service and will evaluate the firmware. But my question is doesn't Voipo have anything in place to detect auto dialers being used and to shutdown the account? I found it by accident looking at the account's call logs. There were thousands of calls spanning over a few months, and we paid for all those calls. But how, as a reseller, can I control or stop this. I have limits set but they were never reached nor can I lower the limits as my clients would exceed them shutting down the service. So how do we monitor the activity from the outside looking in? I would like to see some real time evaluations and not have to manually read through the call logs after the fact.

[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.

[chevyman]

Tim

What about the confirmation tone (Thank You) for the * codes working on 'sip7' and getting a "busy" confirmation tone on 'sip' ?

[VOIPoTim]

Tim

What about the confirmation tone (Thank You) for the * codes working on 'sip7' and getting a "busy" confirmation tone on 'sip' ?

Open a ticket on it with info on how to reproduce and devs will look into it. Could be a bug.

[chevyman]

Tim

Sip7.voipwelcome.com is unstable, sometimes i'll make a calls and the call don't go through, then it looses registration and I have to switch back to sip.voipwelcome.com.

When i do a trace to sip7.voipwelcome.com its not very good to liquidweb.com from here in the Seattle area, its a lot better to softlayer.com on sip.voipwelcome.com.

Is there any chance Voipo going to have a sip in the Northwest?

[chpalmer]

Tim


When i do a trace to sip7.voipwelcome.com its not very good to liquidweb.com from here in the Seattle area, its a lot better to softlayer.com on sip.voipwelcome.com.

Is there any chance Voipo going to have a sip in the Northwest?


I too get better traceroute results to Texas but find sip7 works very well from Bremerton. Who is your ISP chevyman?

74ms but my jitter is relatively low.



C:\>tracert sip7.voipwelcome.com

Tracing route to sip7.voipwelcome.com [72.52.231.45]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms [172.31.125.1]
2 9 ms 10 ms 11 ms 10.28.0.1
3 13 ms 11 ms 11 ms static-24-113-126-254.wavecable.com [24.113.126.254]
4 13 ms 11 ms 10 ms wave-gw.ae0.sea-bdr0.noanet.net [64.146.252.249]
5 12 ms 13 ms 13 ms xe-0-0-0.3006.oly-cor1.noanet.net [64.184.178.22]
6 17 ms 17 ms 17 ms xe-0-3-1.3026.ptl-bdr0.noanet.net [64.184.178.89]
7 16 ms 17 ms 17 ms te3-3.ccr01.pdx01.atlas.cogentco.com [38.104.104.181]
8 17 ms 18 ms 16 ms te0-0-2-2.rcr11.pdx02.atlas.cogentco.com [154.54.0.86]
9 20 ms 21 ms 21 ms te0-3-0-2.ccr21.sea01.atlas.cogentco.com [154.54.40.118]
10 21 ms 20 ms 22 ms be2083.ccr21.sea02.atlas.cogentco.com [154.54.0.250]
11 48 ms 42 ms 41 ms be2085.ccr21.slc01.atlas.cogentco.com [154.54.2.198]
12 52 ms 51 ms 52 ms be2126.ccr21.den01.atlas.cogentco.com [154.54.25.65]
13 64 ms 63 ms 64 ms be2128.ccr21.mci01.atlas.cogentco.com [154.54.25.174]
14 77 ms 76 ms 76 ms be2156.ccr41.ord01.atlas.cogentco.com [154.54.6.86]
15 82 ms 76 ms 76 ms be2005.ccr21.ord03.atlas.cogentco.com [66.28.4.74]
16 77 ms 77 ms 77 ms be2409.rcr11.b002281-5.ord03.atlas.cogentco.com[154.54.29.66]
17 101 ms 101 ms 94 ms cogent-chi.liquidweb.com [38.104.103.166]
18 72 ms 71 ms 71 ms lw-dc3-core2-te8-16.rtr.liquidweb.com [209.59.157.229]
19 74 ms 74 ms 73 ms lw-dc3-dist16-po6.rtr.liquidweb.com [69.167.128.95]
20 74 ms 73 ms 73 ms 72.52.231.45

Trace complete.

[GreenLantern]

I too get better traceroute results to Texas but find sip7 works very well from Bremerton. Who is your ISP chevyman?

74ms but my jitter is relatively low.

[/code]

Same here. SIP7 doesn't look as good "on paper", but seems to work better in practice.

But now that the TCP flooding has been cleaned up, SIP in Texas seems to work pretty well too.

[VOIPoTim]

Tim

Sip7.voipwelcome.com is unstable, sometimes i'll make a calls and the call don't go through, then it looses registration and I have to switch back to sip.voipwelcome.com.

When i do a trace to sip7.voipwelcome.com its not very good to liquidweb.com from here in the Seattle area, its a lot better to softlayer.com on sip.voipwelcome.com.

Is there any chance Voipo going to have a sip in the Northwest?

Yes, we're planning to add a west coast POP soon.

We still feel Dallas is the best for 99% of customers and the connectivity there is very robust especially since Softlayer is now owned by IBM, but we understand that there are a handful of people that may have a better connection to a different DC so that's where sip7 comes in and we're going to add a west coast option soon.

[chevyman]

I'm using Centurylink (old Qwest), i think they are getting cheap. A while back i was having problems and found they had started to use Comcast for a while and now it seems they are using some (zip.zayo.com) whoever they are. here is a trace back on 9-2013.

http://forums.voipo.com/showthread.php/34006-Resellers-Testing-Michigan-Datacenter?p=58805#post58805

It was 71 ms to texas now i'm getting 125 ms

[chevyman]

Yes, we're planning to add a west coast POP soon.

We still feel Dallas is the best for 99% of customers and the connectivity there is very robust especially since Softlayer is now owned by IBM, but we understand that there are a handful of people that may have a better connection to a different DC so that's where sip7 comes in and we're going to add a west coast option soon.

when i do a voip quality test with megapath's test, i get good results with San Francisco, so that would be a good west coast option, other than Seattle :)

[VOIPoTim]

when i do a voip quality test with megapath's test, i get good results with San Francisco, so that would be a good west coast option, other than Seattle :)

For those of you wanting a west coast node, how is your connection to this IP? 198.55.111.5

It's is a facility we're considering.

[GreenLantern]

I'm not west coast, but here's some data. I'm using Comcast in Texas.

west coast server

198.55.111.5
53ms avg
14 hops

here's sip7

72.52.231.45
58ms avg
14 hops

and dallas

67.228.182.2
18ms avg
10 hops

[VOIPoTim]

How about 50.28.98.7? That's another facility we're considering for west coast. It's in Phoenix vs LA.

[GreenLantern]

from Comcast, Houston, TX

50.28.98.7
51ms avg
11 hops


for any resellers that may not know how to get these numbers... open a command prompt in windows, then enter the following commands.

(if you are on a Mac, open terminal instead, and use "traceroute" instead of "tracert")

ping 50.28.98.7
tracert 50.28.98.7

ping 198.55.111.5
tracert 198.55.111.5

ping 72.52.231.45
tracert 72.52.231.45

ping 67.228.182.2
tracert 67.228.182.2

[chpalmer]

From around Seattle

Trace 198.55.111.5
10 37 ms 37 ms 37 ms colo-lax6.as29761.net [96.44.180.34]
11 36 ms 38 ms 37 ms repos.lax-noc.com [198.55.111.5]


Trace 50.28.98.7

15 64 ms 65 ms 65 ms 154.24.18.226
16 103 ms 64 ms 63 ms cogent-phx.liquidweb.com [38.122.88.42]
17 64 ms 65 ms 64 ms lw-dc4-dist2-po1.rtr.liquidweb.com [50.28.96.9]
18 64 ms 64 ms 63 ms network-phx.noc.liquidweb.com [50.28.98.7]

[chpalmer]

Ill throw one in there for consideration :)

Trace speedtest.sjc01.softlayer.com

8 29 ms 29 ms 29 ms ae5.dar01.sr01.sjc01.networklayer.com [173.192.18.249]
9 29 ms 29 ms 28 ms po1.fcr01.sr01.sjc01.networklayer.com [50.23.118.131]
10 40 ms 29 ms 29 ms speedtest.sjc01.softlayer.com [50.23.64.58]

[racerdude]

How about 50.28.98.7? That's another facility we're considering for west coast. It's in Phoenix vs LA.

Tim - for me the first one is definitely better and I think it would be a better choice for West Coast folks:


WinMTR to 198.55.111.5:

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| Router - 0 | 86 | 86 | 0 | 0 | 35 | 13 |
| cpe-172-251-32-1.socal.res.rr.com - 0 | 86 | 86 | 7 | 14 | 231 | 17 |
| tge0-9-0-16.simicacd01h.socal.rr.com - 0 | 86 | 86 | 8 | 12 | 48 | 11 |
| agg23.vnnycajz01r.socal.rr.com - 0 | 86 | 86 | 11 | 15 | 53 | 19 |
| agg29.lsancarc01r.socal.rr.com - 0 | 86 | 86 | 10 | 15 | 52 | 19 |
|bu-ether36.lsancarc0yw-bcr00.tbone.rr.com - 2 | 83 | 82 | 10 | 20 | 478 | 12 |
|bu-ether11.tustca4200w-bcr00.tbone.rr.com - 0 | 86 | 86 | 15 | 20 | 56 | 18 |
| 0.ae3.pr1.lax10.tbone.rr.com - 0 | 86 | 86 | 13 | 17 | 59 | 14 |
| 66.109.7.38 - 0 | 86 | 86 | 13 | 18 | 53 | 20 |
|64.124.12.126.IPYX-100216-005-ZYO.above.net - 0 | 86 | 86 | 11 | 15 | 52 | 18 |
| colo-lax6.as29761.net - 0 | 86 | 86 | 13 | 18 | 86 | 19 |
| repos.lax-noc.com - 0 | 86 | 86 | 12 | 15 | 51 | 16 |
|________________________________________________| ______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider


WinMTR to 50.28.98.7
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| Router - 0 | 51 | 51 | 0 | 0 | 0 | 0 |
| cpe-172-251-32-1.socal.res.rr.com - 0 | 51 | 51 | 8 | 11 | 15 | 12 |
| tge0-9-0-16.simicacd01h.socal.rr.com - 0 | 51 | 51 | 9 | 12 | 16 | 11 |
| agg23.vnnycajz01r.socal.rr.com - 0 | 51 | 51 | 9 | 13 | 24 | 17 |
| agg29.lsancarc01r.socal.rr.com - 0 | 51 | 51 | 11 | 14 | 20 | 14 |
|bu-ether26.lsancarc0yw-bcr00.tbone.rr.com - 0 | 51 | 51 | 13 | 15 | 21 | 18 |
| 0.ae1.pr0.lax00.tbone.rr.com - 0 | 51 | 51 | 40 | 49 | 132 | 40 |
| 66.109.9.122 - 3 | 47 | 46 | 10 | 15 | 78 | 11 |
| ae-1-4.bar2.Phoenix1.Level3.net - 0 | 51 | 51 | 20 | 30 | 82 | 25 |
| ae-1-4.bar2.Phoenix1.Level3.net - 0 | 51 | 51 | 20 | 29 | 81 | 20 |
| LIQUID-WEB.bar2.Phoenix1.Level3.net - 0 | 51 | 51 | 22 | 26 | 69 | 25 |
| lw-dc4-dist1-po2.rtr.liquidweb.com - 0 | 51 | 51 | 22 | 24 | 37 | 24 |
| network-phx.noc.liquidweb.com - 0 | 51 | 51 | 24 | 25 | 37 | 25 |
|________________________________________________| ______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

[chevyman]

For those of you wanting a west coast node, how is your connection to this IP? 198.55.111.5

It's is a facility we're considering.

Tim

LA is better, but PHX is not good, looks like anything going to 'Liquidweb' has poor routing, or maybe its 'Level3' that's the problem.
here is traces and pings:

Pinging 198.55.111.5 with 32 bytes of data:
Reply from 198.55.111.5: bytes=32 time=72ms TTL=57
Reply from 198.55.111.5: bytes=32 time=70ms TTL=57
Reply from 198.55.111.5: bytes=32 time=70ms TTL=57
Reply from 198.55.111.5: bytes=32 time=74ms TTL=57

Ping statistics for 198.55.111.5:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 70ms, Maximum = 74ms, Average = 71ms

Tracing route to repos.lax-noc.com [198.55.111.5]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.0.1
2 42 ms 44 ms 42 ms 63.231.10.248
3 44 ms 43 ms 46 ms tukw-agw1.inet.qwest.net [71.217.185.185]
4 44 ms 44 ms 48 ms sea-brdr-02.inet.qwest.net [67.14.41.18]
5 74 ms 73 ms 69 ms ae-20.r04.sttlwa01.us.bb.gin.ntt.net [129.250.9.133]
6 71 ms 72 ms 73 ms ae-6.r20.sttlwa01.us.bb.gin.ntt.net [129.250.5.42]
7 68 ms 70 ms 68 ms ae-3.r23.snjsca04.us.bb.gin.ntt.net [129.250.3.124]
8 67 ms 64 ms 65 ms ae-0.r22.snjsca04.us.bb.gin.ntt.net [129.250.2.182]
9 73 ms 80 ms 73 ms ae-7.r21.lsanca03.us.bb.gin.ntt.net [129.250.4.151]
10 69 ms 73 ms 70 ms ae-2.r04.lsanca03.us.bb.gin.ntt.net [129.250.5.70]
11 73 ms 71 ms 72 ms xe-0-6-0-4.r04.lsanca03.us.ce.gin.ntt.net [129.250.201.50]
12 71 ms 68 ms 70 ms colo-lax6.as29761.net [96.44.180.102]
13 72 ms 70 ms 70 ms repos.lax-noc.com [198.55.111.5]



Pinging 50.28.98.7 with 32 bytes of data:
Reply from 50.28.98.7: bytes=32 time=97ms TTL=53
Reply from 50.28.98.7: bytes=32 time=101ms TTL=53
Reply from 50.28.98.7: bytes=32 time=95ms TTL=53
Reply from 50.28.98.7: bytes=32 time=97ms TTL=53

Ping statistics for 50.28.98.7:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 95ms, Maximum = 101ms, Average = 97ms


Tracing route to network-phx.noc.liquidweb.com [50.28.98.7]
over a maximum of 30 hops:

1 <1 ms 1 ms <1 ms 192.168.0.1
2 45 ms 47 ms 46 ms 63.231.10.248
3 41 ms 46 ms 42 ms tukw-agw1.inet.qwest.net [71.217.185.185]
4 * * * Request timed out.
5 46 ms 44 ms 48 ms ae14.edge2.Seattle1.Level3.net [4.68.62.189]
6 93 ms 93 ms 101 ms ae-0-11.bar2.Phoenix1.Level3.net [4.69.148.114]
7 94 ms 91 ms 91 ms LIQUID-WEB.bar2.Phoenix1.Level3.net [4.28.83.26]
8 94 ms 97 ms 97 ms lw-dc4-dist1-po2.rtr.liquidweb.com [50.28.96.11]
9 97 ms 96 ms 95 ms network-phx.noc.liquidweb.com [50.28.98.7]