B
Premium,MVM
join:2000-10-28
| Hangups Every __ Minutes!
What is this CRAP?
Frankly, in the scheme of things, I hardly ever use my Viatalk line at home, but tonight I am trying to help a relative with some tech support.
Every 10 or 15 minutes (?) Viatalk kicks me off the line and I have to re-dial.
Of course, my relative calls back too during this time, and because of the 2-line Viatalk feature and because I am calling out, my other line rings (in another room) where I can't get to it at all!
So one of us eventually reaches the other, and then the whole thing starts all over again the next time Viatalk disconnects us.
What is this bull()@#&$*()@# ? Haven't they fixed this stuff by now?
For what it's worth, it's a long distance call to a roaming cell user.
I am NOT on the Viatalk beta system. I am an ordinary provisioned user most all of the time.
Are other people getting these periodic hangups today? I've been reading about this problem for years.
-- B
--
In a realm outside causality and function |
|
B
Premium,MVM
join:2000-10-28
| Just noticed »ViaTalk: Network Update
My provisioned PAP2T is at firmware 3.1.15(LS) .
I don't know if that's a pre or post upgrape version.
-- B
--
In a realm outside causality and function |
|
VTBrendan
Viatalk
Premium
join:2005-06-27
Clifton Park, NY
edit:
July 9th, @11:49PM
| Hi,
Is it actually a set amount of time at which this happens or is it just approx. the same? I don't believe you have had the firmware updated if you are at that version, but doing that or having us do it for you couldn't hurt.
If you know how, try checking the DHCP lease time that your router has set.
-Brendan |
|
B
Premium,MVM
join:2000-10-28
edit:
July 9th, @11:53PM
| I'm angry enough to complain about it but not angry enough to hunt down my VT login credentials, go through the portal, and check the logs to compare call durations right now. 
If it's not happening to anyone else (no corroboration in this thread yet) I'll leave it alone until/unless other household members complain.
Thanks for the reply!
Edit: No, not a DHCP lease issue -- mine is at least 8 hours -- it's currently at 7:31:00 and counting down.
-- B
P.S. No, not a cell phone signal strength issue.
--
In a realm outside causality and function |
|
VTBrendan
Viatalk
Premium
join:2005-06-27
Clifton Park, NY | Also, If your adapter is DMZ'd you might want to give the new servers a try. That takes us out of the audio stream entirely, which removes a potential point of failure.
-Brendan |
|
B
Premium,MVM
join:2000-10-28
| Okay, I checked the logs.
We've got a repeatable (or at least repeated) problem.
Thu Jul 10 01:57:52 UTC 2008
Duration: 00:29:59
Thu Jul 10 02:29:00 UTC 2008
Duration: 00:29:59
Something's clearly cutting off right at the 30 minute mark. I'm thinking it has to be on the VT side, because it's unlikely that the recorded call times would be that precisely matched if, for example, the cell phone network took a dive, even at regular intervals?
My adapter's not DMZed, nor is it port-forwarded. As I said, I try to be a very ordinary user, and VT for the most part works that way.
-- B
--
In a realm outside causality and function |
|
dmolavi
Premium
join:2005-04-11
Sewell, NJ
 ·Verizon FIOS
 ·Comcast
 ·ViaTalk
·Teleblend
| said by B  :Okay, I checked the logs. We've got a repeatable (or at least repeated) problem. Thu Jul 10 01:57:52 UTC 2008 Duration: 00:29:59 Thu Jul 10 02:29:00 UTC 2008 Duration: 00:29:59 Something's clearly cutting off right at the 30 minute mark. I'm thinking it has to be on the VT side, because it's unlikely that the recorded call times would be that precisely matched if, for example, the cell phone network took a dive, even at regular intervals? My adapter's not DMZed, nor is it port-forwarded. As I said, I try to be a very ordinary user, and VT for the most part works that way. -- B what server are you on? i routinely make 1hr+ calls to my parents with no problem at all.
--
Compare how Obama and McCain have voted on issues that matter to you.
TheMolavis.com |
|
Bluethunder
Thunder PC
join:1999-12-05
Duncan, SC
·ViaTalk
·PHONE POWER
 ·AT&T Southeast
·Charter Pipeline
edit:
July 10th, @08:01AM
| reply to B
said by B :... My adapter's not DMZed, ... That's a good thing. Putting the adapter in the DMZ gives anyone with an internet connection the same access access to your PAP2T as you have from your PC. Putting the adpater in the DMZ with VT's provisioning (lack of a user password) is a very bad idea except for very brief troubleshooting. |
|
digger16309
join:2007-06-26
00001
·VOIPo
·ViaTalk
| said by Bluethunder :said by B :... My adapter's not DMZed, ... That's a good thing. Putting the adapter in the DMZ gives anyone with an internet connection the same access access to your PAP2T as you have from your PC. Putting the adpater in the DMZ with VT's provisioning (lack of a user password) is a very bad idea except for very brief troubleshooting. Which means anyone with an internet connection could access your PAP2T, change the settings, and turn provisioning off, thus screwing over your phone service until you discover what has happened, correct?
This has been a long-standing pet peeve of mine because VT Tech Support insists there is no security risk at all to keeping the ATA in the DMZ. |
|
dmolavi
Premium
join:2005-04-11
Sewell, NJ
·Verizon FIOS
·Comcast
·ViaTalk
·Teleblend
| said by digger16309 :Which means anyone with an internet connection could access your PAP2T, change the settings, and turn provisioning off, thus screwing over your phone service until you discover what has happened, correct? This has been a long-standing pet peeve of mine because VT Tech Support insists there is no security risk at all to keeping the ATA in the DMZ. From »en.wikipedia.org/wiki/DMZ_host :
"an external attacker only has access to equipment in the DMZ"
'nuf said.
--
Compare how Obama and McCain have voted on issues that matter to you.
TheMolavis.com |
|
Bluethunder
Thunder PC
join:1999-12-05
Duncan, SC
·ViaTalk
·PHONE POWER
·AT&T Southeast
·Charter Pipeline
| reply to B
The sad part about it is, they could easily mitigate some of the security risk of putting the adapter in the DMZ by provisioning a user password in addition to the admin password. It doesn't exactly make it safe or sensible to run it in the DMZ, but certainly would help a little with the security issues of leaving it wide open. |
|
ptrowski
Got Helix?
Premium
join:2005-03-14
Putnam, CT
clubs:
·AT&T DSL Service
·ViaTalk
| reply to digger16309
said by digger16309 :said by Bluethunder :said by B :... My adapter's not DMZed, ... That's a good thing. Putting the adapter in the DMZ gives anyone with an internet connection the same access access to your PAP2T as you have from your PC. Putting the adpater in the DMZ with VT's provisioning (lack of a user password) is a very bad idea except for very brief troubleshooting. Which means anyone with an internet connection could access your PAP2T, change the settings, and turn provisioning off, thus screwing over your phone service until you discover what has happened, correct? This has been a long-standing pet peeve of mine because VT Tech Support insists there is no security risk at all to keeping the ATA in the DMZ. I personally don't keep anything in the DMZ for long. It's great for troubleshooting, but I don't want anything there for long. |
|
pende_tim
Premium
join:2004-01-04
Andover, NJ
·Verizon Online DSL
·ViaTalk
| Leaving stuff in the DMZ is a bit like chumming for sharks.
I have a FTP site that I set up on port forward as needed. It amazes me how fast the far eastern (China and Hong Kong especially) 'bots find and try the open port when I turn it on.
--
The difference between genius and stupidity is that genius has its limits. |
|
VTJohn
Premium
join:2006-09-14
Clifton Park, NY
| reply to B
Let me provide a little insight into what the DMZ is and how it is used. DMZ is short for demilitarized zone. In network security design infrastructure it is used to refer to a segment on a network that is not behind a firewall. On a router it is slightly different but because of certain similarities it is called the same thing. A router that performs network address translation is by its nature a natural firewall just based on a limitation of the technology. If an initiating connection comes in from the outside it doesn't know which of it's hosts it belongs to and thus throws the packet away. In this sense it is a firewall. Not really by design but by ambiguity of destination.
Most internet traffic is comes in the form of TCP and UDP packets. TCP is a session based protocol. This is used for most traffic on the internet because with this form of packet transmission is guaranteed. If a packet gets lost on its way to its destination it will be sent again until the receiving host confirms that it has received the packet. This makes it particularly good for file transfers and for visiting websites. UDP on the other hand is not session based and not a guaranteed transmission. This is the standard for RTP (VoIP audio) transmission. Protocols that provide guaranteed transmission can't be used for VoIP because if latency or a network outage were to occur during a call it would delay the audio for the rest of the call. If the audio were to cut out for 2 seconds then everything would be delayed two seconds for the entire call. That wouldn't be good.
So what does this have to do with routers? Router's themselves are not the problem, in fact each packet runs through numerous routers on their way through the internet whenever they are transmitted. What cause problems are the types of routers that are in people's homes and this is because they perform NAT - which is basically just a way of using one IP address for multiple devices (computers, ATAs, etc). TCP traverses routers with no troubles so long as the session was started from behind the router. Because TCP is session based the router can simply look at a database in memory of which of its hosts started the initial session and the returning packets go on their way. Because UDP is stateless when a UDP packet comes in to a router there is no session to lookup to know where to route such a packet. Even though this is typically the case there are still some routers that have advanced VoIP processing in their firmware and are capable at doing a better job at routing these packets than others. Newer firmware typically resolves a lot of the problems as well since so many people are switching to VoIP a lot of router manufacturers are modifying their code to work better for that application. With Linksys routers especially firmware upgrades help drastically as Linksys has done a lot to keep up with the VoIP industry. I suspect it's also because they manufacture VoIP ATAs and know what trouble their own routers can be.
However many routers simply aren't able to do it correctly. This is where the DMZ and port forwarding comes in. Port forwarding is a way to tell your router which host to send packets to if it doesn't know where to send them. Typically port forwarding is set to forward UDP ports 5060,5061 and 10000-20000 to the IP address of your ViaTalk adapter. Sometimes the 10000-20000 range has to be widened also depending on the upstream carrier. Port forwarding works for some people's routers, and not for others. DMZ is the way to get past all of the trouble. Putting the IP address of your adapter in the DMZ tells your router to send all of the traffic it doesn't know what to do with to your adapter. This is typically the best practice as your router should know what to do with all of your non-VoIP packets.
As for security the DMZ is no less secure than any configuration your adapter can be set up in. If your adapter can receive audio then it can receive packets from the outside world. The DMZ just ensures it gets there. All adapters have security and authentication systems programmed into their firmware by their manufacturers and if we didn't have the administrative passwords for them here even we wouldn't have the ability to mess with them remotely.
I hope this answers a lot of the questions you've been discussing. |
|
dmolavi
Premium
join:2005-04-11
Sewell, NJ
·Verizon FIOS
·Comcast
·ViaTalk
·Teleblend
edit:
July 10th, @12:18PM
| said by VTJohn :As for security the DMZ is no less secure than any configuration your adapter can be set up in. If your adapter can receive audio then it can receive packets from the outside world. The DMZ just ensures it gets there. bzzzt wrong. if you have your ATA behind your router in your LAN, bots and bad guys wouldn't be able to get past your router (since they have no way of knowing what your NAT table looks like). however, if you put your ATA in the DMZ, it is directly exposed (you don't want me exposing myself, do you?) to the 'net, and isn't protected via any NAT'ing, and a simple scan of your IP address would show that port as being open and available for exploit.
edit - I realize that NAT isn't a good protection mechanism, but it prevents most bots/script kiddies who rely solely on a port scan of an address.
--
Compare how Obama and McCain have voted on issues that matter to you.
TheMolavis.com |
|
B
Premium,MVM
join:2000-10-28
| Actually NAT is a great protection mechanism.
But I'm glad you pointed to that statement of VTJohn's -- I too thought it was pretty wrongheaded. Your adapter won't receive ANY unsolicited packets ("from the outside world") behind an ordinary NAT router. The only reason it does is because the ATA is constantly holding an open connection to the remote SIP server, as far as I understand. Even then the accepted traffic is from particular sources, not "the world".
Also, it's misleading to perpetuate the SOHO router "DMZ" myth when they're really "forward all ports" settings. Anyway...
But anyway, VTJohn, while this might be interesting for some, it really doesn't address my OP at all. Any theory on the precise 30 minute cutoffs?
-- B
--
In a realm outside causality and function |
|
VTJohn
Premium
join:2006-09-14
Clifton Park, NY
| reply to B
No I don't want you exposing yourself. You are correct that there are bots and port scanners out there looking for open ports. However it takes more than an open port to exploit a device. The other part of the equation is exploitable software. There needs to be an exploit available for the software on the device you are exploiting and thus far I have yet to see one for any of the adapters we use. What bots are mainly looking for are Windows and Linux machines because there's a million exploits out there for them and I would never recommend putting workstations in the DMZ without a secondary firewall. An open port doesn't mean you connect and have access to the computer. You need to perform a buffer overflow or something similar to gain access to the machine. |
|
dmolavi
Premium
join:2005-04-11
Sewell, NJ
·Verizon FIOS
·Comcast
·ViaTalk
·Teleblend
| reply to B
said by B :Actually NAT is a great protection mechanism. I said "isn't good"...great isn't good, it's great 
seriously, I was thinking more big-picture. NAT will (if properly implemented) keep folks out of your LAN, but the mechanism itself isn't intended to be a firewall or any such thing.
--
Compare how Obama and McCain have voted on issues that matter to you.
TheMolavis.com |
|
VTJohn
Premium
join:2006-09-14
Clifton Park, NY
| reply to B
B,
Also it went off on a tangent the DMZ setting really has nothing to do with the problem you're having. We've had a problem in the past with a particular upstream provider severing calls at 30 minutes. If you provide me via PM with the number you dialed I can check on it and address it with the upstream personally. |
|
B
Premium,MVM
join:2000-10-28
| PM sent VTJohn, and thanks. You might want to rethink your relationship with that provider. Really, it's this sort of thing that is a big turnoff for those of us looking for simple POTS replacements.
dmolavi, just FYI, NAT/PAT as implemented in SOHO routers is very much a firewall, as it always maintains a state table for active connections. This was bounced around in the Security forum quite a bit. Home users don't need anything else.
-- B
--
In a realm outside causality and function |
|
