dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
1324
share rss forum feed

advocate99

join:2011-03-08

[Voip.ms] Los Angeles ALWAYS lagging??

Has anyone else noticed that the Los Angeles VOIP.ms server is always lagging?

I control five asterisk machines that are located all over the western U.S. (from Socal to Washington State). One of them is less than 15 miles from downtown L.A. For the last 6 months, at least, all of them have consistently reported lagging on the L.A. server.

I contacted VOIP.ms about this many month ago, and they insisted that they're not showing any problems (and thus, they're not going to do anything about it).

We solved the problem by switching to Seattle. But, now that Seattle is down, I've begun wishing that L.A. was more reliable.

Has anyone else observed that L.A. has these constant trouble with lagging?

Here's a sample of just one machine's logfiles from one time period (but they all pretty much look like this):

[2012-12-01 05:25:41] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Lagged. (2788ms / 2000ms)
[2012-12-01 05:25:51] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Reachable. (43ms / 2000ms)
[2012-12-01 05:58:29] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Lagged. (3749ms / 2000ms)
[2012-12-01 05:58:39] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Reachable. (18ms / 2000ms)
[2012-12-01 06:09:14] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Lagged. (3019ms / 2000ms)
[2012-12-01 06:09:24] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Reachable. (25ms / 2000ms)
[2012-12-01 06:36:31] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Lagged. (2016ms / 2000ms)
[2012-12-01 06:36:41] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Reachable. (19ms / 2000ms)
[2012-12-01 06:41:15] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Lagged. (3809ms / 2000ms)
[2012-12-01 06:41:25] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Reachable. (18ms / 2000ms)
[2012-12-01 06:55:31] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Lagged. (3085ms / 2000ms)
[2012-12-01 06:55:41] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Reachable. (17ms / 2000ms)
[2012-12-01 07:00:44] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Lagged. (2019ms / 2000ms)
[2012-12-01 07:00:54] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Reachable. (17ms / 2000ms)
[2012-12-01 07:06:26] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Lagged. (2017ms / 2000ms)
[2012-12-01 07:06:36] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Reachable. (150ms / 2000ms)
[2012-12-01 07:11:41] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Lagged. (3175ms / 2000ms)
[2012-12-01 07:11:51] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Reachable. (17ms / 2000ms)
[2012-12-01 07:28:27] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Lagged. (3257ms / 2000ms)
[2012-12-01 07:28:37] NOTICE[3965] chan_sip.c: Peer 'VOIPMS Los Angeles' is now Reachable. (19ms / 2000ms)


pauleyisle

@verizon.net
they do not seem to care about their infrastructure and ensuring call completion and do not seem to be doing anything to grow the infrastructure to meet the needs of apparently too many users on too weak of equipment. can't recommend them anymore and switching all lines off from them


XCOM
digitalnUll
Premium
join:2002-06-10
Spring, TX
Reviews:
·Vestalink
said by pauleyisle :

they do not seem to care about their infrastructure and ensuring call completion and do not seem to be doing anything to grow the infrastructure to meet the needs of apparently too many users on too weak of equipment. can't recommend them anymore and switching all lines off from them

Dude you still at it? You are trashing every single post voip.ms post.
--
[nUll@dcypher ~]$

MartinM
VoIP.ms
Premium,VIP
join:2008-07-21
kudos:4
said by XCOM:

Dude you still at it? You are trashing every single post voip.ms post.

Unfortunately it seem that forum has become a place to express frustration toward providers and many posts do not contribute to adding useful information for the community members, at all.

---

Anyway, I'm side tracking.. Los Angeles have always been a stable location as far as I know, and if it was 3000 ms our monitoring system would sure pick it up.

But I'm interested in investigating the OP post. I'll check our SIP monitoring logs to see if I can pickup anything like that.
--
Martin - VoIP.ms


XCOM
digitalnUll
Premium
join:2002-06-10
Spring, TX
I agree...

In another note that's the way that asterisk and it's variants like to express a lag when using qualify. It has never been accurate.
--
[nUll@dcypher ~]$
Expand your moderator at work


guzzlegums

@ip-142-4-212.net

Re: [Voip.ms] Los Angeles ALWAYS lagging??

I'll tell you, I would drop voip.ms because I think it doesn't make the grade, but there is nobody else I know of who has its outstanding call-handling ability in a form that is usable to an average man.

Callcentric would be a winner if they got off their arse and put in an IVR, or just a canned voice for callers who were not whitelisted, which requested a PIN. If they then allowed their call treatments to check both for callerid and the PIN before deciding how to route the call, they would have something. But they are 'conservative'. They are conserving themselves into second-rate status.

Anveo looks like it will do the job, but that call-flow diagram stuff looks too formidable to me. If I can figure it out, I'll probably go to anveo.

But for now it looks like voip.ms is the only choice.
Expand your moderator at work

PX Eliezer70
Premium
join:2008-08-09
Hutt River
kudos:13

1 recommendation

reply to pauleyisle

Re: [Voip.ms] Los Angeles ALWAYS lagging??

said by pauleyisle :

can't recommend them anymore and switching all lines off from them

Please do it already and put us all out of our misery.


Motofreak
Premium
join:2009-08-03
Oshawa, ON
Reviews:
·voip.ms

1 recommendation

reply to advocate99
Most people don't have enough knowledge about how routing works. The VoIP.ms LA server is fine with no issues at all my servers in Chicago less than 55ms and the highest its been is 65ms in the past year!, because the routing quality/peering connections is fantastic from the LA server to my servers in 725 S Wells St, Chicago data center.

But from my ISP in Toronto, they're lag spikes are all over the place because my ISP is one cheap ***k and spikes of 3000+ at times using very congested routes.

Next time you see spikes, run a trace route to see where the problem is.


XCOM
digitalnUll
Premium
join:2002-06-10
Spring, TX
Reviews:
·Vestalink
said by Motofreak:

Most people don't have enough knowledge about how routing works. The VoIP.ms LA server is fine with no issues at all my servers in Chicago less than 55ms and the highest its been is 65ms in the past year!, because the routing quality/peering connections is fantastic from the LA server to my servers in 725 S Wells St, Chicago data center.

But from my ISP in Toronto, they're lag spikes are all over the place because my ISP is one cheap ***k and spikes of 3000+ at times using very congested routes.

Next time you see spikes, run a trace route to see where the problem is.

Very good advice.
You can use something like mtr with the -u flag.
That's exactly how I found that the issue was my ISP.
--
[nUll@dcypher ~]$

advocate99

join:2011-03-08

3 edits
reply to advocate99
MartinM,

Please do look into this. I'd love it if you'd solve this, so I could switch back to L.A.

There was a time that Los Angeles was perfect, but call quality started going bad about 6-8 months ago, which was when the lagged and unreachable messages started showing up. Right now, LA is completely useless at all of my sites, even though they are all over the West Coast and use different ISPs.

A tracert is sometimes useful in diagnosing these issues, but I have found that some providers are treating UDP SIP packets differently from UDP, TCP and ICMP packets. So a tracert and ping test might show nothing, but the UDP SIP packets never get through. I tracked down that very problem with Frontier Communications earlier this year, and they eventually admitted that one of their Juniper switches was incorrectly configured.

I'm beginning to suspect that some ISP or backbone providers are violating net nuetrality.

advocate99

join:2011-03-08

1 edit
reply to XCOM
If that's true, then qualify=5000 or qualify=10000 will solve the log problem (here at least), but it wouldn't solve any call quality problems.

said by XCOM:

I agree...

In another note that's the way that asterisk and it's variants like to express a lag when using qualify. It has never been accurate.


advocate99

join:2011-03-08
reply to XCOM
For some reason, my MTR (.71) is missing the -u option. Any suggestions on how to get it to send UDP packets?

??


XCOM
digitalnUll
Premium
join:2002-06-10
Spring, TX
Can you update your mtr?
You must have an older version.
--
[nUll@dcypher ~]$

advocate99

join:2011-03-08
I use what's included in my Distro. Yum update says that I have the latest.

said by XCOM:

Can you update your mtr?
You must have an older version.



XCOM
digitalnUll
Premium
join:2002-06-10
Spring, TX
Reviews:
·Vestalink
reply to advocate99
said by advocate99:

If that's true, then qualify=5000 or qualify=10000 will solve the log problem (here at least), but it wouldn't solve any call quality problems.

said by XCOM:

I agree...

In another note that's the way that asterisk and it's variants like to express a lag when using qualify. It has never been accurate.

advocate99,

True. With that statement it looks like the issue might be in the network/route. I am sure with a trace rout we should be able to see hop/node with the issue.
I had this problems in the past.
You can also change POP and the route should change.

Is your system still lagging?
--
[nUll@dcypher ~]$

advocate99

join:2011-03-08
I think that it is in the network/route - but - whatever part of the network/router that is having trouble is the same for five different machines that are located all over the west coast. That means it is one of the last few hops, and it is probably something that Martin should do something about...

said by XCOM:

said by advocate99:

If that's true, then qualify=5000 or qualify=10000 will solve the log problem (here at least), but it wouldn't solve any call quality problems.

said by XCOM:

I agree...

In another note that's the way that asterisk and it's variants like to express a lag when using qualify. It has never been accurate.

advocate99,

True. With that statement it looks like the issue might be in the network/route. I am sure with a trace rout we should be able to see hop/node with the issue.
I had this problems in the past.
You can also change POP and the route should change.

Is your system still lagging?



XCOM
digitalnUll
Premium
join:2002-06-10
Spring, TX
Reviews:
·Vestalink
said by advocate99:

I think that it is in the network/route - but - whatever part of the network/router that is having trouble is the same for five different machines that are located all over the west coast. That means it is one of the last few hops, and it is probably something that Martin should do something about...

advocate99,

I am sorry but Martin does not control the internet nether he is your ISP. How do you expect Martin to change your route?
--
[nUll@dcypher ~]$

advocate99

join:2011-03-08
Because the last few hops are either inside the datacenter where Martin has his equipment hosted or controlled by the datacenter's ISP. Martin should have influence over them, and should demand that they fix the problem.

That's what I did when Frontier (the ISP for one of my Washington state machines) was having routing trouble. I demanded that they fix it, and they did.

Why do you believe that Martin lacks the ability to influence his providers?

said by XCOM:

said by advocate99:

I think that it is in the network/route - but - whatever part of the network/router that is having trouble is the same for five different machines that are located all over the west coast. That means it is one of the last few hops, and it is probably something that Martin should do something about...

advocate99,

I am sorry but Martin does not control the internet nether he is your ISP. How do you expect Martin to change your route?



XCOM
digitalnUll
Premium
join:2002-06-10
Spring, TX
Reviews:
·Vestalink
downloadmtr.txt 2,139 bytes
mtr
said by advocate99:

Because the last few hops are either inside the datacenter where Martin has his equipment hosted or controlled by the datacenter's ISP. Martin should have influence over them, and should demand that they fix the problem.

That's what I did when Frontier (the ISP for one of my Washington state machines) was having routing trouble. I demanded that they fix it, and they did.

Why do you believe that Martin lacks the ability to influence his providers?

said by XCOM:

said by advocate99:

I think that it is in the network/route - but - whatever part of the network/router that is having trouble is the same for five different machines that are located all over the west coast. That means it is one of the last few hops, and it is probably something that Martin should do something about...

advocate99,

I am sorry but Martin does not control the internet nether he is your ISP. How do you expect Martin to change your route?

Actually I didnt mean it that way.
Let me be more direct.
I switch to LA POP this morning and I had no issues. Now the test was not long enough where I can say for sure no there is no issue but I had no lags for the 10Min I was connected.

Please see attached mtr.
--
[nUll@dcypher ~]$

SCADAGeo

join:2012-11-08
N California
kudos:2
reply to advocate99
said by MartinM:

Unfortunately it seem that forum has become a place to express frustration toward providers

It does seem like that, but it can also serve as a bellwether...
 
 
said by MartinM:

Los Angeles have always been a stable location as far as I know

said by Motofreak:

The VoIP.ms LA server is fine with no issues at all

Los Angeles is one of the better POPs, although I still experience issues with approximately 2-3% of the calls.
 
 
said by advocate99:

For some reason, my MTR (.71) is missing the -u option. Any suggestions on how to get it to send UDP packets?

said by advocate99:

I use what's included in my Distro. Yum update says that I have the latest. :(

Please download mtr-0.82.tar.gz and save it in /usr/src.

Please run the following commands from the shell/terminal:

mv /usr/sbin/mtr /usr/sbin/mtr.0.71
cd /usr/src
tar -xvf mtr-0.82.tar.gz 
cd mtr-0.82
./configure
make
make install
 

It will be installed in /usr/local/sbin. :)

advocate99

join:2011-03-08

1 edit
Scadageo, thanks for the instructions. Will do tomorrow.

Here's my two sets of logs showing LA problems today. This is just a small chunk, around noon in two locations, showing repeated lags. There are similar groups of lag and unreachable messages appearing throughout the day.

Also, I should clarify that it doesn't happen ALWAYS, i.e. every minute of every day. But, it does happen every day at some point, and usually several times each day...

Southern Cal.

[2012-12-20 12:26:14] NOTICE[30157] chan_sip.c: Peer 'VOIPMSLA' is now UNREACHABLE! Last qualify: 1122
[2012-12-20 12:26:24] NOTICE[30157] chan_sip.c: Peer 'VOIPMSLA' is now Reachable. (16ms / 2000ms)
[2012-12-20 12:36:31] NOTICE[30157] chan_sip.c: Peer 'VOIPMSLA' is now Lagged. (3323ms / 2000ms)
[2012-12-20 12:36:41] NOTICE[30157] chan_sip.c: Peer 'VOIPMSLA' is now Reachable. (18ms / 2000ms)
[2012-12-20 12:38:15] NOTICE[30157] chan_sip.c: Peer 'VOIPMSLA' is now Lagged. (3283ms / 2000ms)
[2012-12-20 12:38:25] NOTICE[30157] chan_sip.c: Peer 'VOIPMSLA' is now Reachable. (16ms / 2000ms)

Southern Washington

[2012-12-20 12:26:14] NOTICE[30891] chan_sip.c: Peer 'VOIPMS LA' is now UNREACHABLE! Last qualify: 37
[2012-12-20 12:26:24] NOTICE[30891] chan_sip.c: Peer 'VOIPMS LA' is now Reachable. (70ms / 2000ms)
[2012-12-20 12:27:27] NOTICE[30891] chan_sip.c: Peer 'VOIPMS LA' is now Lagged. (2038ms / 2000ms)
[2012-12-20 12:27:37] NOTICE[30891] chan_sip.c: Peer 'VOIPMS LA' is now Reachable. (40ms / 2000ms)
[2012-12-20 12:29:09] NOTICE[30891] chan_sip.c: Peer 'VOIPMS LA' is now Lagged. (2047ms / 2000ms)
[2012-12-20 12:29:19] NOTICE[30891] chan_sip.c: Peer 'VOIPMS LA' is now Reachable. (37ms / 2000ms)
[2012-12-20 12:30:53] NOTICE[30891] chan_sip.c: Peer 'VOIPMS LA' is now Lagged. (2075ms / 2000ms)
[2012-12-20 12:31:03] NOTICE[30891] chan_sip.c: Peer 'VOIPMS LA' is now Reachable. (37ms / 2000ms)

mcbsys

join:2011-05-22
reply to advocate99
I have an Asterisk install in San Diego that was constantly lagging in Los Angeles. Seattle was similar in lags earlier this year, but by June had become more stable, so I switched the DID to Seattle and have been pretty happy with that. The long and sordid tale (including delving into how Asterisk tests for lag, Wireshark sniffing, etc.):

»www.pbxinaflash.com/community/in ··· s.12425/

Mark Berry
MCB Systems