Porting - what to do if both sides blame each other?

Forums › New Zealand Mobile and Wireless › Porting - what to do if both sides blame each other?

1 | 2

ECHELON

6 posts

Wannabe Geek

#3273548 19-Aug-2024 17:37

KiwiSurfer:

Phoned 2degrees and inquired. Poor agent had never heard of Devoli and literally googled them. But the agent also had the idea of looking up who currently holds that number -- and it turns out to be Spark and not Devoli(!).

Spark is the wholesale provider/carrier, Devoli Mobile is the MVNO "service provider"

KiwiSurfer:

Entered my Devoli account number and it was immediately rejected -- apparently account numbers are meant to be 8-17 digits.

The account number I have been trying for the last three weeks is in fact a 6 digit number.

You are being run around unfortunately. Devoli Mobile is configured in the porting system to be numeric only and 5 - 7 digits for account lengths.

I can understand Skinny failing to request from Devoli if there is a weird interaction with pre-emptive checks before raising a port request/SOM because it all sits on Spark systems but I wouldn't expect 2degrees to not be able to make the request from Devoli unless some system is missing the configuration to make the request. We also have to maintain our records for the porting to be able to submit a port request request against new providers, if we were smarter it would be automatically done though 🙃

Mrcutiepatootie

47 posts

Geek

ID Verified

#3273620 19-Aug-2024 21:02

Complete shot in the dark but have you tried porting the number as a prepaid account?

I had a similar dilemma with Orcon mobile (pre-merger) that I assumed was on account because it was billed with fibre, but when I tried to move to Spark it didn't accept the account number. When I called for help, I was told most MVNOs are prepaid services that are billed "on account" by the reseller so it could be the same case here.

KiwiSurfer

1451 posts

Uber Geek

ID Verified

Lifetime subscriber

#3273623 19-Aug-2024 21:17

Mrcutiepatootie:

Complete shot in the dark but have you tried porting the number as a prepaid account?

I had a similar dilemma with Orcon mobile (pre-merger) that I assumed was on account because it was billed with fibre, but when I tried to move to Spark it didn't accept the account number. When I called for help, I was told most MVNOs are prepaid services that are billed "on account" by the reseller so it could be the same case here.

Have tried porting to Skinny as 'Devoli'/Prepaid -- that was in fact my 2nd port attempt about 3 weeks back.

Today I made a second call to 2degrees (who doesn't recognize Devoli as a valid RSP) who attempted a Spark Prepaid port and was very confident that it would definitely work -- that also failed. It is very interesting to note 2degrees seemed very confused about Devoli and kept telling me they are just Spark and I should just submit a port with Spark as the LSP. The guy was a but like you, wouldn't believe I had an on account hence their attempt at a prepaid port.

It's worth noting Devoli/FF have been quite clear to me several times that I must do a on account port with their 6 digit account number against Devoli as the LSP.

My best guess so far is that the gaining RSPs so far seem to struggle with either the fact I'm porting from an unfamiliar RSP and/or their system expects a certain account format and/or possibly something else entirely.

What I find interesting is not one of the gaining RSPs I've dealt with so far seem to understand the issue and have a process in place for their front line staff to escalate these sort of issues. Not Skinny. Not One NZ. Not 2degrees. Very surprising especially from One/2degrees who I'd expect deal with the most porting requests. Skinny I may understand given they're a smaller RSP but they are backed by Spark so I'd expect better still.

Fingers crossed for some news tomorrow from FF who assure me this is being worked on by their higher ups. (Unlike the gaining RSPs I should add).

nztim

3816 posts

Uber Geek

ID Verified

Trusted

TEAMnetwork

Subscriber

#3273626 19-Aug-2024 22:06

Maybe its. a sign that the small guys offer better service even when you are trying to lave them.

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

Hephaestus

5 posts

Wannabe Geek

#3273628 19-Aug-2024 22:17

Mrcutiepatootie:

I had a similar dilemma with Orcon mobile (pre-merger) that I assumed was on account because it was billed with fibre, but when I tried to move to Spark it didn't accept the account number. When I called for help, I was told most MVNOs are prepaid services that are billed "on account" by the reseller so it could be the same case here.

It is because Orcon & Slingshot pre-merger were reselling Skinny services that are pre-paid despite you being billed on account which was a hassle to explain why we needed SIM identifiers instead of account number. At least Orcon & Slingshot via Vocus do accept the account number, though I still encounter the odd one on the Skinny carrier under those RSP where they haven't moved between networks yet.

devolihq

1 post

Wannabe Geek

Devoli

#3273852 20-Aug-2024 12:14

Hi James, sorry that this has been such an ordeal. I understand your number has now successfully ported to your new provider - sad to see you go but happy this is now completed for you. We've followed up with Skinny to understand why none of the previous ports made it into our IPMS queue (where we would normally do our best to resolve things like incorrect account numbers).

Jan / Devoli

KiwiSurfer

1451 posts

Uber Geek

ID Verified

Lifetime subscriber

#3274052 21-Aug-2024 08:50

Good news at last! Got a message from FF yesterday to advise I should try a port with a new account number (7 digits rather than the 6 I had originally). Popped over to Skinny to request a new port with the new details. TCF text requesting confirmation received 4:28, replied Yes, and TCF text received 4:30 confirming move to new provider. Checked Skinny dashboard a while later and it said port was confirmed and will complete 8am tomorrow (i.e. today as I write this post). And yep sometime around 8am Devoli SIM dropped of and Skilly became active.

Thanks to those who have helped. I just hope the RSPs involved work to figure out what went wrong and fix their systems (including the other RSPs I tested with as even their systems were broken). But at least it's all done now! :)

AliExpress

Shop now on AliExpress (affiliate link).

bagheera

539 posts

Ultimate Geek

#3274054 21-Aug-2024 09:02

KiwiSurfer:

(7 digits rather than the 6 I had originally). (including the other RSPs I tested with as even their systems were broken). But at least it's all done now! :)

then their systems is not broken, you did not have the right account number, so no port, working to specs as a wrong account is a wrong account

nzkc

1572 posts

Uber Geek

#3274056 21-Aug-2024 09:20

bagheera:

KiwiSurfer:

(7 digits rather than the 6 I had originally). (including the other RSPs I tested with as even their systems were broken). But at least it's all done now! :)

then their systems is not broken, you did not have the right account number, so no port, working to specs as a wrong account is a wrong account

What!? They gave them a new account number with 7 digits is the way I read it. So originally they were correct with their original 6 digit account number.

ECHELON

6 posts

Wannabe Geek

#3274057 21-Aug-2024 09:22

bagheera:

KiwiSurfer:

with a new account number (7 digits rather than the 6 I had originally).

then their systems is not broken, you did not have the right account number, so no port, working to specs as a wrong account is a wrong account

Sounds more like the GSP systems were broken and that Devoli had to associate it to a new account number for Skinny to be able to work around and submit the port request. As no port requests had been created in IPMS by Skinny, Devoli as the LSP did not even have a chance to reject or approve the account number that would have been provided. Why would Skinny not create a port request as they would need to, to know if Devoli accepted the original account detail that KiwiSurfer was providing them?

KiwiSurfer

1451 posts

Uber Geek

ID Verified

Lifetime subscriber

#3274063 21-Aug-2024 09:30

bagheera:

KiwiSurfer:

(7 digits rather than the 6 I had originally). (including the other RSPs I tested with as even their systems were broken). But at least it's all done now! :)

then their systems is not broken, you did not have the right account number, so no port, working to specs as a wrong account is a wrong account

I suspect the account number was correct and that there were issue specific to each GSP preventing them from putting the port request through. I know for a fact no port request with the 6-digit number made its way into IPMS other than the successful port request yesterday afternoon with the 7 digit number.

I have detailed above some of those GSP issues.

Some of these are just plain bonkers such as 2degrees refusing to acknowledge Devoli (not listed on their website and two of their helpdesk agents and one manager all refused to accept Devoli is a valid RSP to port from). In 2degrees' case I point finger squarely at 2degrees as it's clearly nothing to do with Devoli or the porting infrastructure.

One NZ I suspect has a port-in form that just throws an exception when a 6 digit account number is provided. Not surprisingly the port didn't even go through to IPMS.

Skinny accepted the port-in details on their website and over the phone but once inside their automation system it doesn't seem to go through to IPMS and just stays in their system without anything happening. This makes sense as at one point Skinny gave up and deleted my account and asked me to create a new account and try another port, which had the same effect of it being stuck with nothing going through to IPMS. My theory is something in their code stops the port but doesn't seem to alert someone to follow up.

Would love to know but suspect the GSPs will quietly fix.

bagheera

539 posts

Ultimate Geek

#3274066 21-Aug-2024 09:48

KiwiSurfer:

I suspect the account number was correct and that there were issue specific to each GSP preventing them from putting the port request through. I know for a fact no port request with the 6-digit number made its way into IPMS other than the successful port request yesterday afternoon with the 7 digit number.

I have detailed above some of those GSP issues.

Some of these are just plain bonkers such as 2degrees refusing to acknowledge Devoli (not listed on their website and two of their helpdesk agents and one manager all refused to accept Devoli is a valid RSP to port from). In 2degrees' case I point finger squarely at 2degrees as it's clearly nothing to do with Devoli or the porting infrastructure.

One NZ I suspect has a port-in form that just throws an exception when a 6 digit account number is provided. Not surprisingly the port didn't even go through to IPMS.

Skinny accepted the port-in details on their website and over the phone but once inside their automation system it doesn't seem to go through to IPMS and just stays in their system without anything happening. This makes sense as at one point Skinny gave up and deleted my account and asked me to create a new account and try another port, which had the same effect of it being stuck with nothing going through to IPMS. My theory is something in their code stops the port but doesn't seem to alert someone to follow up.

Would love to know but suspect the GSPs will quietly fix.

not knowing the spec for the porting system, you can not point the finger at anyone - IE does the spec say that the minimum account length is 7 and max is x - the fact that all the major providers fail points to more likely Devoli accounts are not within spec, but who knows.

but yes 2d should have all rsp

KiwiSurfer

1451 posts

Uber Geek

ID Verified

Lifetime subscriber

#3274070 21-Aug-2024 09:57

bagheera:

not knowing the spec for the porting system, you can not point the finger at anyone - IE does the spec say that the minimum account length is 7 and max is x - the fact that all the major providers fail points to more likely Devoli accounts are not within spec, but who knows.

I have a source advising IPMS lists Devoli as having 5-7 digits. So can't be that either as I assume their account number specs are available to GSPs to include in their validation code. I still think there's some faulty code -- for example a faulty assumption that all account numbers are >=7 perhaps.

bagheera

539 posts

Ultimate Geek

#3274074 21-Aug-2024 10:04

KiwiSurfer:

bagheera:

not knowing the spec for the porting system, you can not point the finger at anyone - IE does the spec say that the minimum account length is 7 and max is x - the fact that all the major providers fail points to more likely Devoli accounts are not within spec, but who knows.

I have a source advising IPMS lists Devoli as having 5-7 digits. So can't be that either as I assume their account number specs are available to GSPs to include in their validation code. I still think there's some faulty code -- for example a faulty assumption that all account numbers are >=7 perhaps.

this might be the case, but there will be a spec for porting that has to be 100% correct before any port can happen otherwise it becomes a free for all on numbers - if the spec says accounts need to be 7 - x and were agreed to by the providers at the time (which was most like voda, spark and 2d back then) then later someone comes along and say, I do not agree, I only want 5 - who at fault?

ECHELON

6 posts

Wannabe Geek

#3274076 21-Aug-2024 10:08

bagheera:

this might be the case, but there will be a spec for porting that has to be 100% correct before any port can happen otherwise it becomes a free for all on numbers - if the spec says accounts need to be 7 - x and were agreed to by the providers at the (which was most like voda, spark and 2d back then) then later someone comes along and say, I do not agree, I only want 5 - who at fault?

IPMS Technical specification outlines that each Service Provider can have their max and minimum lengths configured.

https://www.tcf.org.nz/wp-content/uploads/2.-TCF-IPMS-Technical-Specification-4_20.pdf - Page 33

1 | 2