Any tips for speeding up a re-connection after being "slammed"

Forums › New Zealand Broadband › Any tips for speeding up a re-connection after being "slammed"

1 | 2 | 3

30853 posts

Uber Geek

Retired Mod

Trusted

Biddle Corp

Lifetime subscriber

#2782287 22-Sep-2021 19:10

Caketiger:

I threatened to leave Spark for another provider. Half an hour later, the service was restored and I am back online.

What a pain though. Thanks for the help from here.

Just to add some context here - threatening Spark would have achieved absolutely nothing and was certainly not the reason you got back online.

This issue is not "slamming" per se - Chorus made changes that allow connections to be churned without validating the provider, and despite the industry warning this would happen Chorus decided to proceed with their changes. This has resulted in connections being incorrectly churned when gaining RSP's don't correctly identify ONTs. Once you notified Spark they would have taken the steps to reverse the process which can't happen instantly.

nztim

3814 posts

Uber Geek

ID Verified

Trusted

TEAMnetwork

Subscriber

#2782291 22-Sep-2021 19:22

sbiddle:

Just to add some context here - threatening Spark would have achieved absolutely nothing and was certainly not the reason you got back online.

This issue is not "slamming" per se - Chorus made changes that allow connections to be churned without validating the provider, and despite the industry warning this would happen Chorus decided to proceed with their changes. This has resulted in connections being incorrectly churned when gaining RSP's don't correctly identify ONTs. Once you notified Spark they would have taken the steps to reverse the process which can't happen instantly.

We have taken the approach to ask the client to take a photo of the ONT serial number before we run a transfer

Any views expressed on these forums are my own and don't necessarily reflect those of my employer.

Caketiger

69 posts

Master Geek

#2782365 22-Sep-2021 20:55

sbiddle:

Caketiger:

I threatened to leave Spark for another provider. Half an hour later, the service was restored and I am back online.

What a pain though. Thanks for the help from here.

Just to add some context here - threatening Spark would have achieved absolutely nothing and was certainly not the reason you got back online.

This issue is not "slamming" per se - Chorus made changes that allow connections to be churned without validating the provider, and despite the industry warning this would happen Chorus decided to proceed with their changes. This has resulted in connections being incorrectly churned when gaining RSP's don't correctly identify ONTs. Once you notified Spark they would have taken the steps to reverse the process which can't happen instantly.

Haha, not sure it achieved nothing. I was hoping it would make Spark put some pressure on Chorus to do what was needed. And I think it did.

It seems nuts to me that connections can be cut without a provider even being able to check with its customer. And I also think mistakes like this should be reversible in under 48 hours once the customer raises it.

snnet

1410 posts

Uber Geek

#2782378 22-Sep-2021 22:05

I'd argue this is actually partly Chorus' fault for making it way too easy without validation when humans are entering the information.

BarTender

3606 posts

Uber Geek

ID Verified

Trusted

Lifetime subscriber

#2782381 22-Sep-2021 22:20

sbiddle:

Caketiger:

I threatened to leave Spark for another provider. Half an hour later, the service was restored and I am back online.

What a pain though. Thanks for the help from here.

Just to add some context here - threatening Spark would have achieved absolutely nothing and was certainly not the reason you got back online.

This issue is not "slamming" per se - Chorus made changes that allow connections to be churned without validating the provider, and despite the industry warning this would happen Chorus decided to proceed with their changes. This has resulted in connections being incorrectly churned when gaining RSP's don't correctly identify ONTs. Once you notified Spark they would have taken the steps to reverse the process which can't happen instantly.

And I think the process to reconnect is manual as well as I suspect Spark would have tried to contact the gaining RSP via Chorus to ensure it wasn't a legitimate churn. Manual steps involving different parties who may or may not answer the phone or respond immediately.

It's annoying, but I am not sure more could have been done.

Wheelbarrow01

1723 posts

Uber Geek

Trusted

Chorus

#2782390 23-Sep-2021 00:41

liquidcore: Perhaps @Wheelbarrow01 could chime in :)

If you hate long posts, you might regret tagging me on this one 😂

There was a similar case back in early September that was discussed in this forum. I provided a detailed explanation of all the issues at play here. Unfortunately when that issue got resolved, the OP chose to delete the thread, so I am unable to link back to my original comments, but I will try to summarise again below. Brace yourself - this is a very long post but there is a lot to cover (and I've probably missed something out).

After consultation with the industry, Chorus recently decided to trial the removal of Losing Service Provider validation in a fibre transfer scenario. In reality this means that any RSP can now run a Transfer order on any fibre connection without having to know who the current RSP is. They still need to input the name of the Losing Service Provider, however right now, that information is not being checked to see if it is correct. Instead, the incoming RSP can select any LSP name at random, and the Transfer will proceed as if the name they have entered is correct. At the original end-date of the trial a month or so ago, RSPs generally agreed to the trial being extended. It is still ongoing and at this stage no decision has yet been made on whether the features of the trial will become permanent.

There are legitimate reasons why some industry players have long called for LSP validation to be removed:

1. Some smaller players are just resellers of larger players. For this reason, it can often be difficult to correctly identify the right LSP name. Let us say that customer Jim originally connected up with Aardvark Fibre Ltd, but Aardvark Fibre Ltd does not have a direct relationship with Chorus for fibre services - only copper services, so they choose to wholesale the fibre service as a second tier provider from Buffalo Internet Co. Jim gets billed by Aardvark Fibre Ltd but the service is ultimately connected with Chorus through Buffalo Internet Co. One day Jim decides to change RSPs and wants to connect with CamelNet. Jim tells Camelnet he's connected with Aardvark Ltd, so Camelnet runs the Transfer and selects Aardvark as the Losing Service Provider. Chorus reject the order as the LSP name is not correct. There are over 100 LSP names to choose from. That is a LOT of orders to run in the hopes of correctly identifying the correct LSP name, so a very frustrating and time consuming process for Camelnet to follow.

2. Some RSPs have complicated ownership structures as a result of years of larger players buying up smaller players. Let's pick up the example above. Jim stays with Aardvark Fibre a few more years, and in the meantime, Aardvark Fibre is swallowed up by Dolphin Com, a much larger company. Dolphin Com has a direct relationship with Chorus, so most of their customers have the LFC name Dolphin Com, but some may still be on the old Aardvark billing platform and are still being served through Buffalo Internet. You can see how this can very quickly get confusing...

3. To try and get around the nuances above, some RSPs have created robots to do all the legwork for them. When a consumer calls to request a Transfer to them, their automated robot runs the order - multiple times if necessary, and runs through the list of LSP names - one on each order - until the correct LSP name is selected and Chorus accept the order. Of course this sort of makes a mockery (personal opinion) of Chorus requiring the LSP validation in the first place, as the robot simply tries each name in turn until one works.

What we have been seeing for a few years now (prior to our Transfer Trial) is examples where Jim lives at number 6, but gives Buffalo Internet the wrong address by mistake. Maybe his letterbox says 6A but he's actually just 6 and his property manager who looks after both units doesn't know which is which (trust me, it happens). Or maybe Jim lives at 6 Bolton St Herne Bay but there's also a 6 Bolton St in Howick and the suburb is not correctly communicated (this also happens regularly). Either way, Buffalo Internet's first Transfer order is rejected by Chorus for the wrong LSP name (as the address is wrong), however rather than double check the address is definitely correct, Buffalo Internet assumes there's a second tier wholesaler issue at play, so they engage their robot to try all possible LSP names. Multiple automated orders are placed in quick succession until one is eventually accepted. Jim's neighbour Shirley subsequently loses service as the wrong connection has now been transferred, but Jim is still with Aardvark and could be completely unaware that anything has gone wrong.

Shirley calls her provider Echidna Fibre, who have no idea what's happened - all they can see is that their connection is no longer active at the address as it's been replaced by another RSP's connection. Echidna can't just transfer it back as they don't know which RSP has it. They try a couple of the main players but no joy, so at this stage all they can do is run an Abandonment order (Connect & Replace) commonly used in Move Address scenarios. This sends a notification to Buffalo that their customer may have moved out, but Buffalo are not yet aware that they've connected Jim at the wrong address, so they reject the Connect & Replace order (as is their right), and Shirley still has no service. Echidna eventually escalates the issue to Chorus, and it eventually makes it's way to the Chorus Service Delivery Manager. The SDM has to work backwards to find out what's happened (and what should have happened), then contact Buffalo's SDM, so that the mistake can be made known and corrected. This all takes time and manual effort.

The solution sought by the Chorus Transfer trial is to remove any roadblocks to allow any Transfer to be completed successfully first time. And in theory, if the Transfer is completed on the wrong address/service by mistake, it should be just as easy for the RSP that has lost service to transfer it right back again. Unfortunately as the validation removal is still only in a trial phase, some RSPs have actively chosen not to tell their frontline agents that the trial is happening. This is because LSP validation is still required for transfers of other services (such as copper voice services and DSL). If they advise their frontline agents that LSP validation has been temporarily removed for fibre transfers on a trial basis, their agents may get confused and try to transfer copper voice or DSL with missing or incorrect LSP details - which will of course fail and cause a lot of rework and delays for those customers. So without knowing that they can transfer the customer straight back in a matter of hours, they instead follow the old process of running a Connect & Replace order - which takes much longer and can possibly be rejected by the other RSP, requiring escalation to Chorus.

There are other risks that have been identified as a result of the transfer trial and these are currently being investigated to see what solutions can be found, and this is part of the reason that no final decision has been made on whether LSP validation will remain off permanently, or whether it will be turned back on again. But at this stage Chorus appears to have wide support from the industry for the validation to be permanently turned off, with very low volumes of complaints due to transfers being completed in error. Most instances of incorrect transfers have been reversed quicker than ever, but we appreciate some have not due to the existence of the trial not being communicated to some RSP frontline agents.

Of course I appreciate it appears to have had a big impact on the OP in this case, but from what I can tell it looks like Spark eventually managed to get it all sorted out without asking for Chorus assistance. I suspect Spark frontline tried the Connect & Replace process first, and when that made no progress, Spark's Fibre Connection Support team stepped in (who are aware of the trial), so they will have then canned the C&R, and run the transfer that eventually got the OP reconnected.

If you are still reading this, I commend you.

The views expressed by me are not necessarily those of my employer Chorus NZ Ltd

KiwiSurfer

1449 posts

Uber Geek

ID Verified

Lifetime subscriber

#2782415 23-Sep-2021 08:11

Appreciate the reply @Wheelbarrow01 -- understand in this case you are just the messenger.

I can understand why it may make sense from Chrous' and the RSPs' perspectives that they would prefer to do things this way. As someone currently WFH and dependant on my internet connection for my work, this approach does make me feel quite uneasy. It seems to me any person could ring up any RSP and request a connection at any address in NZ and ensure the connection is slammed. While knowledge of the fact no validation is being done is currently limited to just a few people (such as those of us on Geekzone following this issue with interest, RSP staff, etc), I shudder to think what would happen if this became much wider knowledge. The media could pick up on this issue and broadcast this far and wide. I can imagine certain types of unsavoury people in our society would very quickly see what damage could be done and take advantage of this...

I would much prefer some sort of validation take place. I note mobile phone porting requires sharing the prepay SIM card number and/or the account number associated with the old SIM, which the gaining provider is required to provide. It's interesting to contrast the rigorous process mobile carriers are required to follow to the approach now undertaken by Chorus. Is fibre considered a much less essential service that it is acceptable for 'slamming' to take place on fibre connections but mobile connections are held to a higher standard of proof? (I do hope the mobile porting process doesn't end up adopting what Chorus is now doing).

I appreciate the issues re selecting the correct LSP. I'm curious as to why the logic can't be tweaked so that e.g. choosing Vodafone would match either of Vodafone, TelstraClear, IHUG, et al (so even if it was an ex-TelstraClear connection, it would still respond as a match if Vodafone was chosen as the LSP). This could also be done for RSPs that resell other RSP services (e.g. choosing SKY, Orcon, Slingshot, et al would result in a match for Vocus). Basically, RSPs that sell a mixture of services could have their name match all valid possibilities. This would surely significantly cut down on the amount of 'oh this was actually a Telstra connection even though they say their bill is from Vodafone' type of errors.

Just my two cents...

AliExpress

Shop now on AliExpress (affiliate link).

Caketiger

69 posts

Master Geek

#2782429 23-Sep-2021 08:35

Thanks for explaining all that Wheelbarrow01 - I did read it all.

You are right, the frontline agent I spoke to told me there was no option other than to run that Abandonment Order and wait up to 5 days. He promised to put it through as an urgent request and hoped I would be connected within 24 hours. I just presumed he would know what he was talking about.

A couple of hours after talking to the frontline agent, I remembered that I dealt with some sort of specialist team when I moved into the house. I found his email address - he was part of the Spark Fibre Connection Support team you mentioned. He explained the situation in more detail. He suggested that the best thing he could do to help me was to chase the team at Chorus. He said Spark's problem was not knowing the identity of the company who had "slammed" my connection. He told me Chorus were usually reluctant to share this information.

It was the support team who kept me updated the most and I don't know whether he was able to intervene in a different way but my connection was restored 30 minutes after I emailed him saying I was looking at alternative suppliers. Maybe it was a coincidence? I don't like doing the "threaten to leave" stance but the advice on here was that Spark should have been able to sort this in a matter of hours - at that point, I had been without a home connection for 2 days of working from home.

If it happens again, I can go straight to the Connection Support team without going through the general helpline.

KiwiSurfer is right here. I am in my 40s, have grown up with tech, am not an expert with broadband but know where to look for advice. What if this happens to elderly customers or those who don't have English as a first language? The industry should think of the consequences of making things easier for the fibre companies at the customer's expense. There is a massive potential for abuse of the system.

gareth41

742 posts

Ultimate Geek

#2782627 23-Sep-2021 12:01

If this happened to me I would first log a request with my ISP to get my connection back, then I would reconfigure the WAN on my router to use the "new connection" that's apparently been assigned and continue use it until its reverted back - it's not difficult as majority of IPS don't require a password now - tag vlan 10, then check for DHCP or setup a new PPPoE dialer with default credentials - you'll probably get on straight away and have a working connection through the new ISP.

Edit:

This brings me to another scenario that may play out here, if the connection is slammed and the new ISP happens to use the same authentication method / WAN settings as the previous ISP - the customer who had their connection slammed may not even be aware as service will continue to work as normal. They only way they could know is by checking the IP address assigned.

decibel

315 posts

Ultimate Geek

#2782673 23-Sep-2021 13:46

Caketiger:... He suggested that the best thing he could do to help me was to chase the team at Chorus. He said Spark's problem was not knowing the identity of the company who had "slammed" my connection. He told me Chorus were usually reluctant to share this information..

I can understand the problem here but surely the solution is simple? Why doesn't Spark "double-slam" the connection?

Not knowing the identity of the second RSP should not be a problem as they didn't know the identity of the original RSP in the first place.

Maybe in the future, RSPs should ask for a photo of the HONT's serial number.

Wheelbarrow01

1723 posts

Uber Geek

Trusted

Chorus

#2782811 23-Sep-2021 14:35

Something I missed out of my long post was with regard to Multiple Primaries. Chorus is working hard to introduce functionality by early next year which will enable RSPs to connect additional primary offers on the next available port of the ONT (not just Port 1). As of right now, only secondary offers are available to order on additional connections, and many RSP's don't sell secondary offers, effectively meaning only a single connection can currently be catered for on a Chorus ONT in most cases.

The change means that very soon, multiple RSPs will be able to connect onto a single ONT. One of the benefits will be in this exact scenario. Let's say a connection is incorrectly transferred from one RSP to another by mistake. If the original RSP is having trouble getting their Port 1 connection reprovisionioned due to another RSP holding the port, the affected RSP will be able to liven up a new connection on Port 2 very quickly and easily.

The same will apply in instances where a previous occupant has moved out and left their connection active, or active with a future dated disconnection order open. Rather than the incoming RSP trying to negotiate with the old RSP through Chorus to get their disconnection completed, they will be able to simply connect the new occupant on Port 2 straight away.

The views expressed by me are not necessarily those of my employer Chorus NZ Ltd

afe66

3181 posts

Uber Geek

Lifetime subscriber

#2782931 23-Sep-2021 15:56

The provider that requested the wrong disconnection should pay a fine or the wronged party get one month credited.

There is no reason why the inconvenienced party should not get reimbursement fir the hassle.

Oh sorry we clamped your car not the neighbours, it will be 5 days to unclamp.

decibel

315 posts

Ultimate Geek

#2782936 23-Sep-2021 16:06

afe66: The provider that requested the wrong disconnection should pay a fine or the wronged party get one month credited.

It is not always that provider's fault - people don't always get their address right.

We once lived in Whites Line West and I was surprised by the number of neighbours who did not know that there was a Whites Line East.

nztim

3814 posts

Uber Geek

ID Verified

Trusted

TEAMnetwork

Subscriber

#2783346 24-Sep-2021 09:15

decibel:

It is not always that provider's fault - people don't always get their address right.

Providers can see the ONT serial number when running a transfer, it should be simple enough for the incoming provider to request a photo of the serial number so they don't accidently "SLAM" the wrong ONT

There are merits to not requiring the losing service provider when transferring a connection - for example Vodafone brought out numerous RSPs over the years and the ONT could still be in the chorus database as "wave, ihug, telstraclear, etc"

Any views expressed on these forums are my own and don't necessarily reflect those of my employer.

trig42

5810 posts

Uber Geek

ID Verified

#2783402 24-Sep-2021 10:55

nztim:

decibel:

It is not always that provider's fault - people don't always get their address right.

Providers can see the ONT serial number when running a transfer, it should be simple enough for the incoming provider to request a photo of the serial number so they don't accidently "SLAM" the wrong ONT

There are merits to not requiring the losing service provider when transferring a connection - for example Vodafone brought out numerous RSPs over the years and the ONT could still be in the chorus database as "wave, ihug, telstraclear, etc"

It's not that easy to find the serial number on an ONT.

Here's one we've just had installed at one of our sites - where is the Serial? You wouldn't wat people taking them off the wall to find it.

1 | 2 | 3