I move my number recently MilesR & pheasent gave the steps needed.
I kept my old Plusnet line running and set up a brand new Cityfibre (Vodaphone) line with FTTH.
Had to keep my old line running, the internet going down was not an option as the son couldn't handle no gaming broadband (he has issues), you also need the old line running as has been discussed so you can port the number to a Voip service.

Once you get the sipgate code you can use/test the number you picked when you signed up, you then ask for them to port your number over which cancels the original line. The code is required by them to tie the number to you / your address.
A good way to think about it your old number is it's virtual so when you get a call on the original landline number, your mobile rings, I use GS wave app and have set it up on the wifes mobile too so both ring when we get a call on the old landline number. Not fully decided if I should get the hardware required to have the line back in the house so we have the virtual "landline" that rings in the house again.

Not an expert but recently went through the process and figured out what I needed to do before going for it. As has been said I only use the mobile to make calls and just use the virtual number to get calls on the old landline number. That way no costs for calls, I did load £10 to it so I could test the outgoing line but will probably never use the remaining credit.

Glad to know it's helped.
Hopefully these sort of threads will be found by others who can follow a similar path.

Hi bit of an update I have received the code from sipgate earlier today

Am currently using the baked in option in android (not using any apps atm)

All calls coming through fine - battery life seems normal

Thanks for the update. It is annoying that SIP/VOIP is probably being removed by Google from Android though. It seems a bit of a strange move considering the main purposes of a phone - making and receiving calls.

In reply to a post by think26872:

Thanks for the update. It is annoying that SIP/VOIP is probably being removed by Google from Android though. It seems a bit of a strange move considering the main purposes of a phone - making and receiving calls.

Further update the inbuilt SIP option is currently hit and miss it seems fine on initial setup but an hour or two later calls fail to connect

I installed the linphone app from fdroid which is fine but it using a tad more battery

Using the baked in system the battery was more or less same as usual

I need to do more testing/research

Also applied to sipgate to port my number and they have sent me the forms, I will hold fire until my FTTP is installed

In reply to a post by gap300:

Further update the inbuilt SIP option is currently hit and miss it seems fine on initial setup but an hour or two later calls fail to connect

I installed the linphone app from fdroid which is fine but it using a tad more battery

Using the baked in system the battery was more or less same as usual

I need to do more testing/research

Also applied to sipgate to port my number and they have sent me the forms, I will hold fire until my FTTP is installed

If it still makes outgoing calls fine but is failing to receiving incoming calls randomly this may be due to the software using IPv6. Sipgate has 4 servers it uses for IPv6, so what can happen is the VoIP device uses a keepalive to one of the IPv6 addresses, and if you get a call in on that IP address this keepalive has kept a path open through the firewall and you get the call. However if the incoming call is received from one of the other server addresses, a firewall will block it.

Solution is to ensure the firewall is told to allow all IPv6 traffic from 2001:ab7::/64.

Alternatively you could use Sipgates IPv4 IP address 217.10.79.23 in place of sipate.co.uk in the settings to force IPv4 and see if that helps. Sipgate only uses one IPv4 address so it doesn't change and get stopped by a firewall, assuming keepalive packets are working.

In reply to a post by E300:

In reply to a post by gap300:

Further update the inbuilt SIP option is currently hit and miss it seems fine on initial setup but an hour or two later calls fail to connect

I installed the linphone app from fdroid which is fine but it using a tad more battery

Using the baked in system the battery was more or less same as usual

I need to do more testing/research

Also applied to sipgate to port my number and they have sent me the forms, I will hold fire until my FTTP is installed

If it still makes outgoing calls fine but is failing to receiving incoming calls randomly this may be due to the software using IPv6. Sipgate has 4 servers it uses for IPv6, so what can happen is the VoIP device uses a keepalive to one of the IPv6 addresses, and if you get a call in on that IP address this keepalive has kept a path open through the firewall and you get the call. However if the incoming call is received from one of the other server addresses, a firewall will block it.

Solution is to ensure the firewall is told to allow all IPv6 traffic from 2001:ab7::/64.

Alternatively you could use Sipgates IPv4 IP address 217.10.79.23 in place of sipate.co.uk in the settings to force IPv4 and see if that helps. Sipgate only uses one IPv4 address so it doesn't change and get stopped by a firewall, assuming keepalive packets are working.

This setting is currently set to automatic, do you think changing it will help?

https://postimg.cc/B8wHs9Kw

In reply to a post by gap300:

This setting is currently set to automatic, do you think changing it will help?

https://postimg.cc/B8wHs9Kw

I don't think so, in my experience keepalives are sent even on IPv6 anyway.

Either try the IPv4 address to force IPv4, or set a firewall rule to allow all incoming IPv6 traffic from Sipgate address range (2001:ab7::/64). The firewall rule of course is only possible whilst you have control of the network.

In theory you don't need keepalives on IPv6 at all provided the firewall is set to allow incoming traffic from Sipgate servers. In this particular case the keep alive is keeping the connection open through the firewall but only for one of the possible servers that could want to signal a call to you, so if you are on IPv6 with Sipgate with the firewall not recognising the other 3 servers and so blocking them, it gives rise to random failures on incoming calls because sometimes they come in from the other servers. Outgoing calls are always okay as firewalls allow outgoing traffic by default.

Hope that helps.

Edited by E300 (Tue 25-Jan-22 11:47:25)

In reply to a post by E300:

In reply to a post by gap300:

This setting is currently set to automatic, do you think changing it will help?

https://postimg.cc/B8wHs9Kw

I don't think so, in my experience keepalives are sent even on IPv6 anyway.

Either try the IPv4 address to force IPv4, or set a firewall rule to allow all incoming IPv6 traffic from Sipgate address range (2001:ab7::/64). The firewall rule of course is only possible whilst you have control of the network.

In theory you don't need keepalives on IPv6 at all provided the firewall is set to allow incoming traffic from Sipgate servers. In this particular case the keep alive is keeping the connection open through the firewall but only for one of the possible servers that could want to signal a call to you, so if you are on IPv6 with Sipgate with the firewall not recognising the other 3 servers and so blocking them, it gives rise to random failures on incoming calls because sometimes they come in from the other servers. Outgoing calls are always okay as firewalls allow outgoing traffic by default.

Hope that helps.

Yes thanks that helps a lot

I was having some issue with bluetooth in my vehicle and as soon as I changed from sipgate.co.uk to the IPv4 address my incoming calls instantly came through

There is one setting in android that I need to keep an eye on 'All calling accounts' I have noticed it switches itself off if you make any changes

Thanks for all your help on this, I will keep you updated

Edit: Since changing to IPv4 everything seems 'snappier' calls are coming through instantly

Edited by gap300 (Tue 25-Jan-22 12:07:20)