Search found 8 matches

Will do Aaron. Thanks again.

Aaron, once again you are the man. After stepping through your instructions, I could see the old number and then changed it and applied the new number. I double-checked everything and all is good.

I think I have my work cut out for me today to check about 200 other subscribers to make sure the same issue doesn't exist with them.

Thanks Aaron.

Bill

This is a bizarre situation, so bare with me while I share the details:

James City County VA 911 is using Page Gate version 5.0

A subscriber recently (a few weeks ago) requested a change in his record to redirect all pages to his Verizon personal cell phone instead of his Verizon business cell phone. For the sake of discussion, let's pretend that his work cell number is (757) 555-5555. His personal number is (757) 999-9999. His subscriber record currently reflects (757) 999-9999. I generated a report of all subscribers and searched for his work number (757) 555-5555 to make sure it was gone and not accidently assigned to a different user by mistake. This number was not found, which is what I expected.

The carrier for this subscriber is VERIZON_WIRELESS_SMTP using the SMTP protocol obviously. On the Advanced TAB, I have a FAILOVER carrier set up as VERIZON_WIRELESS_TAP which uses the TAP protocol. Occasionally the SMTP protocol fails for whatever reason and the Verizon_Wireless_TAP kicks in to make an attempt to deliver the page request to Verizon using the TAP protocol.

When this happens, I can see this subscriber's original cell number (his work phone) (757) 555-5555 being paged via the TAP protocol instead of the (757) 999-9999. SMTP always uses the correct number (757) 999-9999.

There are no subscribers listed for Verizon_Wireless_TAP. It is strictly used as a FAILOVER carrier for Verizon_Wireless_SMTP.

So where is this (757) 555-5555 hiding and in such a way that I can't see it anywhere? Obvously Page Gate still has a record of it somewhere. Is my understanding of how a FAILOVER Carrier should work incorrect? Once upon a time, before version 5.0, we used FAILOVER Recipients but were hoping that the FAILOVER Carrier concept would simplify maintenance of this database.

Thanks in advance for any assistance on this.

Thanks for the info. I'll try to keep up with their progress.

Good to know that you are in the Public Safety business andcan relate. I have a feeling that a lot of members on this forum are tied to Public Safety and are probably going through the same issues. Thank goodness for the forum itself.

As many Verizon subscribers that are out there, you would think that Verizon would have stepped into the real world using a state-of-the-art technology. I think Verizon has gotten too big for their britches and maybe don't care. I may be able to stir something up through the Association of Public Safety Communications Officials (APCO) and possibly through the CIO from the City of Richmond. He loves beating on vendors.

Lizardkng, I was searching for topics about SMTP delays and came across your answer about Verizon's server. I have been investigating delays reported to me today which have been going on at least since February 26, 2008. This too is a 911 center located in James City County, Virginia. In looking at the logs, it appears that there is a huge slowdown recently as more volunteers have switched to Verizon wireless. James City County's CAD System automatically does an All Page whenever there is a report of a structure fire. And yes, you hit it on the head, one hour later the pages finally got out to everyone. As you know, this is not acceptable in our environment. I have invoked a second connector. We upgraded to version 5 about a month ago. But I am really tempted to switch Verizon notifications from SMTP to TAP. How long has the Verizon SMTP server been running this slow?

We have been using Pagegate for almost 3 years as an interface to OSSI's Computer-Aided Dispatch product, but now we need to allow desktop users on our County Intranet the ability to send to pages. The current PageGate database sits on a XP workstation (not server). We are licensed for 5000 pagers. We are thinking about purchasing the Getweb interface for PageGate. The IT folks do not want to install IIS on this workstation for fear that it will adversely affect performance of some mission critical 911 applications that are running on it. Instead they would like to see the web piece installed on a Windows 2003 server that is already running IIS for another purpose. Can the Getweb interface and the database run on two different machines without a problem?

On Friday, James City County had a hardware failure with the USB COM ports or the modem and PageGate started generating a message that read "PGDialer1 Unable to Access Modem". By the time that the problem was discovered mid-day Saturday, 259 pages had backed up in the queue. Most pages there are normally delivered across the Internet using one of the Internet delivery protocols, but someone had tried to page a pager that required the TAP protocol over dial-up. This is when the problem started.

Is there any way to configure PageGate so that if a hardware failure such as this occurs again, that PageGata will bypass the pages requiring dial-up and move forward to process the pages to be sent via one of the Internet delivery protocols? If it helps, I noticed that, according to their registration under PG Rev 4, they are licensed for 2 dialers, but I only see where one has been configured. Is there some way that the second dialer can come into play and help with this situation if it ever happens again?

Author	Message
Topic: TAP FAILOVER CARRIER SENDING WRONG NUMBER WHEN SMTP FAILS
hobgoolw Replies: 4 Views: 14050	Forum: PageGate Support Posted: Fri Aug 13, 2010 7:28 am Subject: TAP FAILOVER CARRIER SENDING WRONG NUMBER WHEN SMTP FAILS
hobgoolw Replies: 4 Views: 14050	Will do Aaron. Thanks again.
Topic: TAP FAILOVER CARRIER SENDING WRONG NUMBER WHEN SMTP FAILS
hobgoolw Replies: 4 Views: 14050	Forum: PageGate Support Posted: Fri Aug 13, 2010 6:52 am Subject: TAP FAILOVER CARRIER SENDING WRONG NUMBER WHEN SMTP FAILS
hobgoolw Replies: 4 Views: 14050	Aaron, once again you are the man. After stepping through your instructions, I could see the old number and then changed it and applied the new number. I double-checked everything and all is good. I think I have my work cut out for me today to check about 200 other subscribers to make sure the same issue doesn't exist with them. Thanks Aaron. Bill
Topic: TAP FAILOVER CARRIER SENDING WRONG NUMBER WHEN SMTP FAILS
hobgoolw Replies: 4 Views: 14050	Forum: PageGate Support Posted: Thu Aug 12, 2010 9:37 pm Subject: TAP FAILOVER CARRIER SENDING WRONG NUMBER WHEN SMTP FAILS
hobgoolw Replies: 4 Views: 14050	This is a bizarre situation, so bare with me while I share the details: James City County VA 911 is using Page Gate version 5.0 A subscriber recently (a few weeks ago) requested a change in his record to redirect all pages to his Verizon personal cell phone instead of his Verizon business cell phone. For the sake of discussion, let's pretend that his work cell number is (757) 555-5555. His personal number is (757) 999-9999. His subscriber record currently reflects (757) 999-9999. I generated a report of all subscribers and searched for his work number (757) 555-5555 to make sure it was gone and not accidently assigned to a different user by mistake. This number was not found, which is what I expected. The carrier for this subscriber is VERIZON_WIRELESS_SMTP using the SMTP protocol obviously. On the Advanced TAB, I have a FAILOVER carrier set up as VERIZON_WIRELESS_TAP which uses the TAP protocol. Occasionally the SMTP protocol fails for whatever reason and the Verizon_Wireless_TAP kicks in to make an attempt to deliver the page request to Verizon using the TAP protocol. When this happens, I can see this subscriber's original cell number (his work phone) (757) 555-5555 being paged via the TAP protocol instead of the (757) 999-9999. SMTP always uses the correct number (757) 999-9999. There are no subscribers listed for Verizon_Wireless_TAP. It is strictly used as a FAILOVER carrier for Verizon_Wireless_SMTP. So where is this (757) 555-5555 hiding and in such a way that I can't see it anywhere? Obvously Page Gate still has a record of it somewhere. Is my understanding of how a FAILOVER Carrier should work incorrect? Once upon a time, before version 5.0, we used FAILOVER Recipients but were hoping that the FAILOVER Carrier concept would simplify maintenance of this database. Thanks in advance for any assistance on this.
Topic: Send email and SMS at the same time?
hobgoolw Replies: 12 Views: 30153	Forum: PageGate Support Posted: Sat Mar 08, 2008 9:19 am Subject: Send email and SMS at the same time?
hobgoolw Replies: 12 Views: 30153	Thanks for the info. I'll try to keep up with their progress. Good to know that you are in the Public Safety business andcan relate. I have a feeling that a lot of members on this forum are tied to Public Safety and are probably going through the same issues. Thank goodness for the forum itself.
Topic: Send email and SMS at the same time?
hobgoolw Replies: 12 Views: 30153	Forum: PageGate Support Posted: Sat Mar 08, 2008 9:06 am Subject: Send email and SMS at the same time?
hobgoolw Replies: 12 Views: 30153	As many Verizon subscribers that are out there, you would think that Verizon would have stepped into the real world using a state-of-the-art technology. I think Verizon has gotten too big for their britches and maybe don't care. I may be able to stir something up through the Association of Public Safety Communications Officials (APCO) and possibly through the CIO from the City of Richmond. He loves beating on vendors.
Topic: Send email and SMS at the same time?
hobgoolw Replies: 12 Views: 30153	Forum: PageGate Support Posted: Sat Mar 08, 2008 12:18 am Subject: Verizon SMTP Server Delays
hobgoolw Replies: 12 Views: 30153	Lizardkng, I was searching for topics about SMTP delays and came across your answer about Verizon's server. I have been investigating delays reported to me today which have been going on at least since February 26, 2008. This too is a 911 center located in James City County, Virginia. In looking at the logs, it appears that there is a huge slowdown recently as more volunteers have switched to Verizon wireless. James City County's CAD System automatically does an All Page whenever there is a report of a structure fire. And yes, you hit it on the head, one hour later the pages finally got out to everyone. As you know, this is not acceptable in our environment. I have invoked a second connector. We upgraded to version 5 about a month ago. But I am really tempted to switch Verizon notifications from SMTP to TAP. How long has the Verizon SMTP server been running this slow?
Topic: Getweb Add-on to PageGate Version 4
hobgoolw Replies: 1 Views: 8791	Forum: PageGate Support Posted: Fri Feb 09, 2007 2:53 pm Subject: Getweb Add-on to PageGate Version 4
hobgoolw Replies: 1 Views: 8791	We have been using Pagegate for almost 3 years as an interface to OSSI's Computer-Aided Dispatch product, but now we need to allow desktop users on our County Intranet the ability to send to pages. The current PageGate database sits on a XP workstation (not server). We are licensed for 5000 pagers. We are thinking about purchasing the Getweb interface for PageGate. The IT folks do not want to install IIS on this workstation for fear that it will adversely affect performance of some mission critical 911 applications that are running on it. Instead they would like to see the web piece installed on a Windows 2003 server that is already running IIS for another purpose. Can the Getweb interface and the database run on two different machines without a problem?
Topic: Method to Configure PageGate to Bypass Dial-up Services
hobgoolw Replies: 2 Views: 12006	Forum: PageGate Support Posted: Sun Oct 16, 2005 9:37 pm Subject: Method to Configure PageGate to Bypass Dial-up Services
hobgoolw Replies: 2 Views: 12006	On Friday, James City County had a hardware failure with the USB COM ports or the modem and PageGate started generating a message that read "PGDialer1 Unable to Access Modem". By the time that the problem was discovered mid-day Saturday, 259 pages had backed up in the queue. Most pages there are normally delivered across the Internet using one of the Internet delivery protocols, but someone had tried to page a pager that required the TAP protocol over dial-up. This is when the problem started. Is there any way to configure PageGate so that if a hardware failure such as this occurs again, that PageGata will bypass the pages requiring dial-up and move forward to process the pages to be sent via one of the Internet delivery protocols? If it helps, I noticed that, according to their registration under PG Rev 4, they are licensed for 2 dialers, but I only see where one has been configured. Is there some way that the second dialer can come into play and help with this situation if it ever happens again?