Dropped cals - any issues today?

[usa2k]

That's VOIPoTrump's job

[voipinit]

... For the most part people don't log on to these types of forums just to say "everything is hunky dory." "That's the nature of a support board."

Everything is hunky dory.

[MisterEd]

Everything is hunky dory.

I knew I was walking into that.

[stevech]

It's not the Nature Of VoIP.
It's the Nature Of VoIP across the Internet (rather than a private network).

My employer uses VoIP on a very large scale (Hundreds of offices including Asia and the UK/EU). Its QoS is like POTS, because traffic does NOT flow on the wild-west of the Internet routing.

VoIPo, In My Experience, is near average in quality/reliability, a bit overpriced, slowly improving. In the running. Not yet way above average.

But really, the combination of the Internet and use of Asterisk (which I assume) mean that no cottage-industry VoIP provider can excel. But with the slow demise of the US class 5 switch POTS, this is the future.

I don't rely on VoIP - just testing the waters.

[ctaranto]

For the most part, everything is also hunky dory for me. I lost my Comcast connection for a few hours last week. No phone service, very little mobile coverage (T-Mobile at my house is weak and we rely on UMA over WiFi/Internet for connectivity). If we had an emergency, we'd be screwed, but we didn't and everything came back automatically.

As for VOIPo specific issues, I had a ton at first, but once I started using a solid adapter (the 2nd of 2 PAP2Ts tried), it's been relatively solid. We did have an issue with incoming calls last week, but that was an announced issue on VOIPo Twitter account.

Earlier this week, I was getting echoes and got an echo for a few minutes today (I was talking to my wife who was at home).

It's not perfect, nor do I expect it to be, but for $8 and change per month (2 year pre-paid), I have no complaints.

I'm about 30 miles west of Boston using Comcast and a DOCSIS3 modem (Motorola SB6120), connected to the Central servers.

[sr98user]

I just had a outgoing call drop after about 20 minutes. I checked my router and there were no dropped packets and the NAT entry was still there for the call.

I noticed that it was using the media gateway at 66.62.140.38. When I ping that machine, I get a very high latency.. Most of the times its around 110ms. But sometimes its very high.. If I do a traceroute most of the hops are fine except for the last one.

ping -t 66.62.140.38
Pinging 66.62.140.38 with 32 bytes of data:
Reply from 66.62.140.38: bytes=32 time=437ms TTL=48
Reply from 66.62.140.38: bytes=32 time=438ms TTL=48
Reply from 66.62.140.38: bytes=32 time=430ms TTL=48
Reply from 66.62.140.38: bytes=32 time=440ms TTL=48
Reply from 66.62.140.38: bytes=32 time=437ms TTL=48

Ping statistics for 66.62.140.38:
Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 430ms, Maximum = 440ms, Average = 436ms

[stevech]

FYI
66.62.140.38
from here in So. CA.

average 80-100. But often increases to 200-400mSec then timeouts, for tens of seconds for minutes. I just watched it go from 90 to 500, then timeouts, then back to 80mSec in two episodes.

Not my connection: pings to yahoo.com are without anomalies (steady 50-60mSec)

That address may be a client on
OrgName: 360Networks (USA) Inc.
OrgID: 360NE-1
Address: 2401 4th Avenue
Address: 11th Floor
City: Seattle
StateProv: WA
PostalCode: 98121
Country: US

NetRange: 66.62.0.0 - 66.62.255.255
CIDR: 66.62.0.0/16
NetName: 360NETWORKS-BLK-1
NetHandle: NET-66-62-0-0-1
Parent: NET-66-0-0-0-0
NetType: Direct Allocation
NameServer: TAISP1.IN-TCH.COM
NameServer: TAISP2.IN-TCH.COM
Comment: ADDRESSES WITHIN THIS BLOCK ARE NON-PORTABLE
RegDate: 2001-01-03
Updated: 2004-08-05

OrgTechHandle: 360NE1-ARIN
OrgTechName: 360Networks Technical
OrgTechPhone: +1-877-993-4237
OrgTechEmail: network.operations@360.net

[rjbasye]

From KY

ping -t 66.62.140.38

Pinging 66.62.140.38 with 32 bytes of data:
Reply from 66.62.140.38: bytes=32 time=110ms TTL=53
Reply from 66.62.140.38: bytes=32 time=99ms TTL=53
Reply from 66.62.140.38: bytes=32 time=102ms TTL=53
Reply from 66.62.140.38: bytes=32 time=100ms TTL=53
Reply from 66.62.140.38: bytes=32 time=97ms TTL=53
Reply from 66.62.140.38: bytes=32 time=95ms TTL=53
Reply from 66.62.140.38: bytes=32 time=105ms TTL=53
Reply from 66.62.140.38: bytes=32 time=93ms TTL=53
Reply from 66.62.140.38: bytes=32 time=93ms TTL=53
Reply from 66.62.140.38: bytes=32 time=97ms TTL=53
Reply from 66.62.140.38: bytes=32 time=111ms TTL=53
Reply from 66.62.140.38: bytes=32 time=91ms TTL=53
Reply from 66.62.140.38: bytes=32 time=106ms TTL=53
Reply from 66.62.140.38: bytes=32 time=100ms TTL=53
Reply from 66.62.140.38: bytes=32 time=92ms TTL=53
Reply from 66.62.140.38: bytes=32 time=91ms TTL=53
Reply from 66.62.140.38: bytes=32 time=92ms TTL=53
Reply from 66.62.140.38: bytes=32 time=93ms TTL=53
Reply from 66.62.140.38: bytes=32 time=91ms TTL=53
Reply from 66.62.140.38: bytes=32 time=91ms TTL=53
Reply from 66.62.140.38: bytes=32 time=103ms TTL=53

Ping statistics for 66.62.140.38:
Packets: Sent = 52, Received = 52, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 90ms, Maximum = 133ms, Average = 98ms

[stevech]

66.62.140.38
watch pings for 10 minutes, in the busy hour. Much worse.

( we should not be using this thread's title for this gripe re a non-VoIPo server)

[scott2020]

66.62.140.38
watch pings for 10 minutes, in the busy hour. Much worse.

( we should not be using this thread's title for this gripe re a non-VoIPo server)

Maybe, but if one of VOIPo's upstream providers has a crummy gateway causing problems, Tim can put some pressure on them to fix it. It doesn't hurt to call out the upstream in my opinion.

I average 130ms from Missouri btw.