Changing Chorus Fibre RSP with overlap

Forums › New Zealand Broadband › Changing Chorus Fibre RSP with overlap

1 | 2 | 3

4014 posts

Uber Geek

Trusted

#2911308 7-May-2022 14:53

OldProvider can take the 30 days notice, but they dont need to submit the disconnection order until close to the termination date.

That means there are no in-flight orders to block the connection request from NewProvider.

Or the customer can be proactive and get NewProvider set up on port2 and tested working before giving notice to oldprovider and just accepting there will be a 30 day overlap.

This is especially important with number porting where if there is an issue with the porting request, oldprovider may cancel the line before the porting is successful and then you go down the rabbit hole of trying to reclaim the number.

Ray Taylor

There is no place like localhost

Spreadsheet for Comparing Electricity Plans Here

Jase2985

13457 posts

Uber Geek

ID Verified

Lifetime subscriber

#2911312 7-May-2022 15:22

OldGeek:

You are correct in theory but:

Chorus are the problem because they block legit connect requests. You can put a disconnect on port one and a connect on port 2 (concurrently in that sequence - I did this moving from Orcon to Voyager) but Chorus are refusing to process a disconnect on port 2 concurrently with a connect on port 1.
Voyager (and probably all other RSPs) require 30 days notice of disconnection. If they cannot place a disconnect order with Chorus then the whole thing is invalid from their perspective. I had exactly the same issue with Orcon (being on a grandfathered no-contract plan). So the timing of both the disconnect and connect is driven by the disconnect notice period.
I prefer to tackle the problem of illogical Chorus restrictions rather than get into an argument with Voyager (probably through the TDR) about the (long established) disconnect notice period. As I said in an earlier post the TDR service have succeeded in getting Chorus to reach out to me late yesterday (Friday) after a request from me to intervene.

1. you never used be to be able to do it like that, so the ISP has scheduled something at their end as you could only do one request at a time. see the link i posted above about this changing.

2. that's not your problem, you have given them the notice as per your contract. what ever happens at the isp end is irrelevant.

3. the restrictions aren't illogical now, the old ones were where there could only be one request at a time.

MaxineN

Max
1772 posts

Uber Geek

ID Verified

Trusted

Subscriber

#2911332 7-May-2022 16:38

raytaylor:

OldProvider can take the 30 days notice, but they dont need to submit the disconnection order until close to the termination date.

That means there are no in-flight orders to block the connection request from NewProvider.

Or the customer can be proactive and get NewProvider set up on port2 and tested working before giving notice to oldprovider and just accepting there will be a 30 day overlap.

This is especially important with number porting where if there is an issue with the porting request, oldprovider may cancel the line before the porting is successful and then you go down the rabbit hole of trying to reclaim the number.

This in bold is exactly what it should be. Giving notice is not the same as "please put through a disconnect order".

Ramblings from a mysterious lady who's into tech. Warning I may often create zingers.

hamish225

1418 posts

Uber Geek

ID Verified

#2912072 9-May-2022 21:52

So, Why couldn't this have just been a transfer order again?

*Insert big spe*dtest result here*

Wheelbarrow01

1723 posts

Uber Geek

Trusted

Chorus

#2912089 10-May-2022 00:26

So once again, to eliminate any doubt, any RSP can issue a connect order on a free/available port even if there is an open order on an in-use port. This has been possible since February this year.

Below is a screenshot of the OP's address record in the Chorus order system from 10 minutes ago, showing the Voyager disconnection order:

And below this is the screenshot of the same address record from 30 seconds ago showing the Port 3 activation order I have just created for testing/demonstration purposes. You can clearly see that I did this while the Voyager disconnection order remains on Port 2:

Of course I have removed any identifying numbers (and I've also now deactivated my test order after capturing the above screenshots), but it proves that the system works as designed. Any RSP can do this and the process was clearly documented and conveyed to all RSPs well before the February launch. The RSPs I look after routinely activate additional ports on a daily basis since Chorus made this system enhancement. I'm not sure I can make it any clearer.

It is possible that Sky have some sort of issue with their B2B ordering setup, but I am not qualified to comment specifically on that as they are not my customer from a service delivery standpoint, and I have no knowledge of their specific setup. It's also possible that maybe some of their staff just don't understand how to do it - but again that is conjecture. However from a Chorus standpoint this functionality is available to all RSPs.

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

OldGeek

893 posts

Ultimate Geek

ID Verified

Lifetime subscriber

#2912141 10-May-2022 09:02

With respect @wheelbarrow01, Sky have specifically accused Chorus of refusing a connect order on port 1 because a disconnect order was in place. I have raised the issue with the TDR and consequently made direct contact with Chorus on this. I will post in a few days on the results of my efforts but it is not looking good.

--

OldGeek.

Voyager referral code: https://refer.voyager.nz/6XQR2QG9Q

Jase2985

13457 posts

Uber Geek

ID Verified

Lifetime subscriber

#2912142 10-May-2022 09:09

OldGeek:

With respect @wheelbarrow01, Sky have specifically accused Chorus of refusing a connect order on port 1 because a disconnect order was in place. I have raised the issue with the TDR and consequently made direct contact with Chorus on this. I will post in a few days on the results of my efforts but it is not looking good.

With respect, Wheelbarrow01 works for chorus and has proven its not an issue at chorus' end.

Ask sky to connect you on port 3 and the image above shows its possible. if they cant/wont do that then they have some internal issues.

Maybe Simon could see if there is an issue with having a connection on port 1?

Equinox IT

Cloud spending continues to surge globally, but most organisations haven’t made the changes necessary to maximise the value and cost-efficiency benefits of their cloud investments. Download the whitepaper From Overspend to Advantage now.

OldGeek

893 posts

Ultimate Geek

ID Verified

Lifetime subscriber

#2912999 12-May-2022 15:29

Summary: @wheelbarrow was right - Sky got it wrong. My original plan (connection to new RSP (Sky) precedes termination of service from old RSP (Voyager)) is now confirmed as in place.

Note that this post is to publish my experiences and nothing more.

Detail:

My approach was to set dates based on Voyager's termination policy of 30 days notice. So that is where I started - Voyager agreed to a specific termination date. I then approached Sky through the usual process of 'adding' broadband to my existing Sky account connecting at a date prior to the Voyager disconnect date. They accepted then deleted my request for service. I only knew about this because on my Sky account the progress report on broadband connection disappeared. When I contacted Sky they said that their connect request to Chorus was rejected (by Chorus) because of the Voyager disconnect request.

I approached the TDR service over this. They advised that Chorus was not a member so they could not intervene, but they forwarded my issue to someone in Chorus (not @wheelbarrow01) who made contact and clarified exactly how Sky can request connection to a different port on the ONT regardless of the Voyager request (this was a different process than that used by Sky and rejected by Chorus). I contacted Sky via their broadband helpdesk and that person claimed that the Chorus employee was wrong and refused to do anything until the Voyager disconnect request had been cancelled.

I contacted the TDR again. They acknowledged that Sky was the issue so my complaint this time was about Sky and the TDR accepted the dispute. Their standard procedure is to ask the RSP to make contact so I got a call from someone at Sky. We went over the situation. She promised to investigate. 30 minutes later she called back to confirm my new connection would be made under the original terms and apologised for what had gone before. In my Sky account the broadband connection data appeared again and this time included a confirmation of the original connection date I requested.

The above is a summary that includes all the important stuff but missing some irrelevant detail. The moral of the story is persistence and getting the TDR involved gained access to senior Sky Broadband personnel. I am happy to field any questions and to provide support to anyone who encounters difficulty in similar circumstances but please PM me rather than post to this thread.

Hat-tip to @wheelbarrow01 for initial assistance and to the TDR for very fast response times.

I will update again only if what is planned does not happen.

--

OldGeek.

Voyager referral code: https://refer.voyager.nz/6XQR2QG9Q

Jase2985

13457 posts

Uber Geek

ID Verified

Lifetime subscriber

#2913000 12-May-2022 15:50

The thing is it should never have gotten to this point because the ISP in question should have known how it worked.

antoniosk

2358 posts

Uber Geek

ID Verified

Trusted

Lifetime subscriber

#2913059 12-May-2022 16:31

Wheelbarrow01:

So once again, to eliminate any doubt, any RSP can issue a connect order on a free/available port even if there is an open order on an in-use port. This has been possible since February this year.

It is possible that Sky have some sort of issue with their B2B ordering setup, but I am not qualified to comment specifically on that as they are not my customer from a service delivery standpoint, and I have no knowledge of their specific setup. It's also possible that maybe some of their staff just don't understand how to do it - but again that is conjecture. However from a Chorus standpoint this functionality is available to all RSPs.

I think this is your key point.

When the process was first created in the mists of time, it was not possible to issue an order as you describe - it was locked out as per the rules then. I imagine Sky built their workflow process around that.

Chorus has since updated it's service to be more capable, but that doesn't mean SKY has spent more money updating its systems.

To use the expression, it takes two to tango - and while this community knows what is possible, doesn't mean changes have been implemented. Sky is a volume business and has built its processes for the masses and not classes. The process the call centre currently has is the process that will be used, irrelevant of whether new capabilities exist.

________

Antoniosk

nztim

3812 posts

Uber Geek

ID Verified

Trusted

TEAMnetwork

Subscriber

#2913128 12-May-2022 18:32

It should also be made aware that NOT ALL RSPs can activate a second primary and general helpdesk staff may not necessary be using wireline but using an automation process from their own systems

Someone Seinor in the provisioning team would be able to log into wireline and create the order

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

quickymart

13924 posts

Uber Geek

ID Verified

#2913141 12-May-2022 19:56

Wireline? For fibre?

Jase2985

13457 posts

Uber Geek

ID Verified

Lifetime subscriber

#2913166 13-May-2022 07:19

nztim:

It should also be made aware that NOT ALL RSPs can activate a second primary and general helpdesk staff may not necessary be using wireline but using an automation process from their own systems

Someone Seinor in the provisioning team would be able to log into wireline and create the order

they can, they choose not to because of their own process's

OldGeek

893 posts

Ultimate Geek

ID Verified

Lifetime subscriber

#2915058 17-May-2022 13:14

hamish225:

So, Why couldn't this have just been a transfer order again?

See Paragraph 4 of my original post.

I have since seen in other threads on Geekzone that you can loose service for 30 minutes or more with a transfer. Given that this can only be done during normal business hours (ie not evenings or weekends) and Chorus will only commit to a schedule of 'morning' or 'afternoon' this is not tolerable to those of us who exclusively work from home, particularly when paid by time during business hours. The whole point of my approach is that this inconvenience is not necessary if you can afford to pay for 2 RSPs for a short time.

With an overlap period in addition to testing and any problem resolution, I can as a last resort stay with the old RSP. I can also choose exactly when I wish to migrate each device from the old to new router.

--

OldGeek.

Voyager referral code: https://refer.voyager.nz/6XQR2QG9Q

wratterus

1687 posts

Uber Geek

#2915107 17-May-2022 14:17

Just a note, you might find interesting @oldgeek.

A client wanted a new connection at a location that already had a current connection, and they didn't want to cancel the current connection until the new one was setup & working. They contacted Spark, the connection was provisioned & operational on port 2 on the ONT in less than a day, no issues at all. They can then cancel the old connection at their leisure.

That's certainly how it should work - obviously Spark are following the correct protocols.

1 | 2 | 3