Spark (telecom) paging pacnet interface broken ?
Hi all, Does anyone here look after, or know who looks after, the 026 400 1283 modem interface to spark paging ? It's currently answering calls, but not giving a modem handshake. (Please don't respond with messages about paging being end-of-life'd, the fire service is paying for it to kept alive on life-support.) Thanks
On Thu, 20 Jul 2017 19:01:49 +1200, Ian Batterbee
Does anyone here look after, or know who looks after, the 026 400 1283 modem interface to spark paging ?
It's currently answering calls, but not giving a modem handshake.
We're getting modemy sounding noises today but NO CARRIER :( Anyone know what's up? Spark has not been helpful so far. -- Michael
On 2017-07-24 15:32, Michael Fincham wrote:
On Thu, 20 Jul 2017 19:01:49 +1200, Ian Batterbee
wrote: Does anyone here look after, or know who looks after, the 026 400 1283 modem interface to spark paging ?
It's currently answering calls, but not giving a modem handshake.
We're getting modemy sounding noises today but NO CARRIER :(
Anyone know what's up? Spark has not been helpful so far.
Talking to a firie contact, they're under the impression that the platform's been EoLed for everyone other than the firies. So that could be the issue? Cheers David
What happened on the 21st (I think ?) is that pager RICs that aren't fire/ambos/hospitals have been deleted from the system - they're now returning the error "Record not found for ID: 2583495" (that's not a real number). This may have been done as part of the steps of the handover to FENZ (Fire Emergency NZ). Sending messages to fire service RICs are successful, *if* you manage to get a modem that actually answers the phone. The paging software that I'm using treats this message as a recoverable error, and so it requeues the message and retries. I suspect that other email/web paging services are doing the same, and that the modem banks that answer the calls to 026 400 1283 are therefore getting overloaded with retries, and only the dead modems - the ones that pick up but don't give a modem tone (which have been broken for ages, but were worked around by calling back and getting another modem) are now getting the majority of calls since they disconnect more quickly, making them more available than the ones tied up doing retries. This is of course just a theory, based on my observations. On 24/07/2017 16:14, David Maclagan wrote:
On 2017-07-24 15:32, Michael Fincham wrote:
On Thu, 20 Jul 2017 19:01:49 +1200, Ian Batterbee
wrote: Does anyone here look after, or know who looks after, the 026 400 1283 modem interface to spark paging ?
It's currently answering calls, but not giving a modem handshake.
We're getting modemy sounding noises today but NO CARRIER :(
Anyone know what's up? Spark has not been helpful so far.
Talking to a firie contact, they're under the impression that the platform's been EoLed for everyone other than the firies. So that could be the issue?
Cheers David _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz https://list.waikato.ac.nz/mailman/listinfo/nznog
Hi all, This is now the ninth day that the paging system has been broken. Here is what I've learned in the past week: -> We are paying considerably more than ever for access to the paging network -> Spark has exactly one person doing support for this product (Hi Ben!) -> Spark has outsourced management of the TAP modem banks to a third party -> Even though we raised a ticket eight days ago, they only raised the problem with the modem management third party yesterday Spark people on the list: seriously? This is a critical service and we're paying you an inordinate amount of money for it. This is not acceptable. What makes you think this situation is OK? If you don't want to run a paging service for us, please make proper arrangements to stop instead of letting the system die while pretending it isn't. This extra-expensive non-functional "new" paging service is a joke. A nine day fault on a critical message delivery service is a joke. -- Michael
On 2/08/2017 3:27 PM, Michael Fincham wrote:
Hi all,
This is now the ninth day that the paging system has been broken.
Here is what I've learned in the past week:
-> We are paying considerably more than ever for access to the paging network -> Spark has exactly one person doing support for this product (Hi Ben!) -> Spark has outsourced management of the TAP modem banks to a third party -> Even though we raised a ticket eight days ago, they only raised the problem with the modem management third party yesterday
Spark people on the list: seriously? This is a critical service and we're paying you an inordinate amount of money for it. This is not acceptable. What makes you think this situation is OK?
[...] From memory, when I looked at using the "new" service, the actual usage fees were quite reasonable, what killed it was the Spark $6000pa (from memory, don't quote me) "contract administration" fee. I never got a sensible answer on what the fee was meant to cover. Dave
participants (4)
-
Dave Green
-
David Maclagan
-
Ian Batterbee
-
Michael Fincham