Printable View
I'm getting no devices listed in vPanel this morning. No dial tone & incoming calls go straight to failover (voicemail). I entered a ticket, but figured I'd mention it here in case others might be offline as well. My service w/the PAP2T has otherwise been rock solid to this point.
I had the same thing this AM with my PAP2.
I'm O.K. with both my PAP2Ts..
I am fine here too with PAP2T. But I did notice that my PAP2T was restarted around 4pm yesterday. Must be some provisioning changes. I wonder if there is a way to save the configuration and compare it later to see what has changed.
My PAP2T is all good :)Quote:
Originally Posted by burris
Tom,Quote:
Originally Posted by TomP
Sorry to hear about this recent experience. Lets see if we can't figure out what is going on. I have quickly took a look your SIP traffic coming to our network from your ATA. I do see that your REGISTER requests are making it to our network. However generally in SIP based authentication the way it works is as follows:
ATA SENDS REGISTER REQUEST -> VOIPo
(this is done without any *Proxy-Authorization header)
VOIPo REPLYS WITH 401 Unauthorized -> ATA
(this is done because there is no credentials in the original REGISTER request)
Now here is where it looks like the problem lies, if the ATA does discover and "see" the REPLY to it's REQUEST, it will then continue and send another REGISTER request -- however this time containing the Proxy-Authorization request header -- and as long as your realm / hash / etc is valid you will be registered.
Now here is where the problem appears to be happening. Your ATA is not receiving our 401 response to your REQUEST. Which only leads me to believe ports are not forwarded -- or are not forwarded correctly? However also if seems have been working just dandy in the past, it also makes me ask "What changes have happened recently"
*Proxy-Authorization Header: A header that contains your SIP credentials essentially, to authenticate with the proxy.
Disclaimer:
Sorry for the technical explanation but I wanted you to see why we're saying the ports needed to be forwarded and that we weren't just giving you a blanket reply.
________
Outdoor russian
Thanks for the follow-up, Brandon. There have been no changes on my end. The PAP2T has been purring along since 2/19. My network is simple: DIR-655 sitting behind a (non-router) cable modem. The PAP2T hangs off the DIR-655. I have no ports forwarded for the ATA, though per this morning's support ticket discussion, I will add the appropriate ports when I get home this eve and see what that does. Not sure why I would need the forwarding as things have been working fine until this point.
Thanks for the detailed explanation! Even if I only understand part of it, it's bound to help us zero in on the actual problem.
Fwiw, my outage today appears to be related to a DHCP problem that my ISP was having. After power-cycling everything this eve, I could not pull an external IP from my cable modem. Called Charter and, after testing a bunch of things, the tech confirmed it was a DHCP problem on their end. Things appear to be up now and my ATA is back online.
Anyway, sorry for the red herring. Our regular internet access (web, email) was okay throughout the day despite the DHCP problem, so I couldn't understand why the ATA was not re-registering. Makes sense now, I think.