Have you been told your calls were Orphaned -- near WiFi hotspots

Apparently Republic’s phone OS does not ping/verify for a fully connected WiFi hotspot – like those at McDonalds – before switching to VoIP mode.

I’ve been informed of numerous failed attempts to call my phone – that seem to correlate to my proximity to one of those hotspots – that is showing a connection on the phones WiFi icon – but is actually still waiting on a user dialog/login.

Does Republic verify an actual internet connection – say, with a “ping” – before switching to VoIP mode? or could it be that even a pending connection is allowed – thereby effectively deactivating service while near some hotspots?

1 Like

Your phone will connect to the McDonald’s WiFi hotspot, but you won’t actually have internet connectivity (necessary to complete calls) until you open your browser and accept the User Agreement. This is true with hotspot connections at most commercial hotspots. I wonder if that might be the cause of the missed calls.

1 Like

Yes, I’m thinking the code might read:

PreTestVoIPMode()

If WiFi = TRUE

If(Ping(RepublicServer)) = TRUE

VoIP = TRUE

else

return (cell_mode)

I know – oversimplified. But I’m wondering if the VoIP hand-off has been oversimplified?

1 Like

Actually @beachb gave you the answer above.

Once a connection is made to the Internet, they the phone will register (via an IP exchange) to the Republic server… then they call can be set up for outgoing, or can be routed to you for incoming. Once registered the phone will maintain the IIP connection to Republic until you loose the WiFi/Internet connection. If the WiFi can’t complete the connection between your phone and Republic it will revert to cell only (OWA (Open White Arc) … If the connection is not great, then the Bonded Calling will come into play during calls and merge cell/WiFi(Internet) data to provide a better quality call

1 Like

While that is a great answer – calls are still getting lost

Clearly there is vast room for the nice algorithm cited above to go awry, in practice. At any point the software could mistakenly decide it has a good IP connection – unless a successful PING is performed. Only a detailed test – at a public wifi hotspot like McDonalds – followed by a nasty line by line code review would duplicate the bug.

Sadly, this is precisely the kind of bug that can slip thru the cracks. You can’t know what calls you didn’t receive – unless someone thinks to tell you (ask your mate if you couldn’t be reached lately).

OK I’m done with this issue. I can only report what I found. I did switch to a Google WiFi enabled phone – with the same bug!

Thanks for the kind help!

If you have a sequence of events that can be reliably repeated and result in you losing calls, I would hope that Republic would want to work with you to understand the root cause.

  • Perhaps if you open a Ticket with Republic Help you could work with them as @billg did see: GSM Band 12 Coverage Problem Solved
  • Details like the calling number, time of missed call and any visual indicators that you see would be helpful

Yes, I’m thinking the code might read:

PreTestVoIPMode()

If WiFi = TRUE

If(Ping(RepublicServer)) = TRUE

VoIP = TRUE

else

return (cell_mode)

I know – oversimplified. But I’m wondering if the VoIP hand-off has been oversimplified?

We are actually much simpler if the server cannot get a response back from the phone over WiFi then we send the inbound call over cell. If the cell carrier is unable to send the call to the phone then they forward to voicemail. Not a lot of logic needed there. Our secret sauce logic is what do we do during the call to maintain call quality over the duration of the call when on WiFi, cell or both.

The setup of the call in or out is pretty binary. Is the phone able to converse with the server or is the server able to converse with the phone? SIP is a two way protocol. The server, on an inbound call, initiates the call with the registered device(full filled in arc) if the device does not respond with a ringing(180 or 183) command within a specified amount if milliseconds then we immediately move to cell, if cell cannot complete then carrier forwards to our voicemail.

I hope this helps.

seanr wrote:

We are actually much simpler if the server cannot get a response back from the phone over WiFi then we send the inbound call over cell. If the cell carrier is unable to send the call to the phone then they forward to voicemail.

Great answer…BUT

If the phone OS has deluded itself into VoIP mode (see WiFi, but no internet) – by the cited algorithm – then voicemail is the only service it can get in that state. The provider would seem to be negligent it allowing a spotty service condition – if that is the case.

The fact that "the server cannot get a response from the phone over WiFi" does not trap this error condition or prevent the phone from hanging in an indeterminate state – falsely thinking it is on a valid WiFi with internet connectivity. The SIP protocol does not validate internet connectivity. A simple PING test would though – and resolve this problem.

It still appears that the phone firmware needs to perform a PING (outside of SIP protocol) to determine if the WiFi signal is really just in a pending state – unable to respond to the Republic server – and not in cellphone mode either!

I persist only the call failure is real. Clearly something is amiss.

Thank you!

1 Like

Yes, there has always been a problem with captive portals and “zombie” APs - the phone attaches to WiFi and then *assumes *there is internet and drops cellular. This is especially troublesome for teephony, but is also a nuisance for any usage of data. Messaging apps fail, streaming gets interrupted, etc.

Interestingly, Fi seems to not have such a problem. Simply connecting to WiFi does NOT close the cellular data channel unless and until internet connectivity over WiFi is confirmed. So if the backhaul to my AP goes down, for example, the phone will use cellular – for data and telephony.

Can’t Republic do something like that, @seanr ? Initially, and preferably periodically, ping something (like maybe the VOIP server?), and if it fails, go back to cellular? It is quite problematic to simply assume that WiFi = internet.

OK, I do not think you understand. We try the call on WiFi, if it cannot setup the call then we move to cell. If there is no cell signal to get, then voicemail. There is really no VoIP mode. There is a registered or not registered state. Even if it cannot reach the phone on wifi we send the call over cell next. If you give support a recent call example, like the day it happens, then we can clearly see if we tried WiFi, cell or both. Easy to see.

Some routers may block the incoming request but that is not an issue since we would just move to cell. We are a hybrid service using both networks. When both are bad then the phone is not going to be reachable.

The provider would seem to be negligent it allowing a spotty service condition – if that is the case.
Every carrier has conditions where there is no coverage, we just have the addition of WiFi on top of cell.

The fact that "the server cannot get a response from the phone over WiFi" does not trap this error condition or prevent the phone from hanging in an indeterminate state

Yes it does the server makes a decision based on the availability of the phone.

Yes, there has always been a problem with captive portals and “zombie” APs - the phone attaches to WiFi and then *assumes *there is internet and drops cellular. This is especially troublesome for teephony, but is also a nuisance for any usage of data. Messaging apps fail, streaming gets interrupted, etc.

Not true, we never shut off the cell radio and unlike other VoIP hybrid companies we do not use the cell data for inbound call setup. Messaging, yes but we pop an error and queue the messages for when you get online again.

Interestingly, Fi seems to not have such a problem. Simply connecting to WiFi does NOT close the cellular data channel unless and until internet connectivity over WiFi is confirmed. So if the backhaul to my AP goes down, for example, the phone will use cellular – for data and telephony.
They do things the Android way, the same way we do. Just their phones are cellular first. If we start messing with that we would need to be in the ROM again and would definitely mess up third party apps.

It is quite problematic to simply assume that WiFi = internet.

Think about the anger people would have if they saw they were connected to WiFi and were still using billable data. We have looked at ways to free up SMS|MMS over cell data if WiFi is challenged. Kind of like bonded calling for texting but it can cause issues with third party apps and will require more things in Android to change.

1 Like

Thanks very much SEANR! I was deliberately a 'lil provocative – so as to get a good response You came thru biggly.

Can we just agree that SOMETHING is happening to hamper calling – apparently in a “captive” WiFi site – like McDonalds?

Just pay your largest software test person to go sit at McDonalds – and let them expense all the happy meals they can eat – while several other testers attempt a set number of calls to him. It should be clear if the error is reproducible or not. You’ll also get a very jolly software tester as well

BTW – I got a Google Fi phone – and I’m told that I have missed several calls – apparently near a captive WiFi portal!

Merry Christmas Ya’ll! (from Texas)

1 Like

We would need call examples and then it would be very clear, but I have seen this before, what it will look like is:

We try phone over cell 3 times (few milliseconds) then we try it over cell by (low tech) calling the underlying number and if that will also not ring then off to voicemail. If you are having this issue on Fi then that only strengthens my argument, since they are cellular 1st. Your coverage just sounds either spotty or there is some interference in that particular MacDonald’s blocking cell access.

There is nothing about a captive portal that would block the cell calling. If your phone did not ring over WiFi we would have forwarded to cell and probably did, and they could not get to the phone either. If you were a direct customer of the underlying carrier you would have been in the same boat.

On the bright-side – if Google buys-up 'Republic – and your stock pops thru-the-roof – you won’t need to consternate over these things anymore. Thanks again.

@ronaldp.vdj1r4

Google eats little companies and spits out the remnants. I don’t see Google buying out RW. They just became independent this month. They need an Independance Day Party if anything!

*** ~~ßocephous™***

1 Like

Yes, PLEASE do not copy Project Fi! They are awful. It is exactly their selection algorithm that is at the heart of their problems and as far as I can tell there is no active development going on for the product. They drop WiFi calls repeatedly when there is no reliable cellular connection. I was extremely patient with them on this matter and kept the service long after many people had given up on it.

I just read a new posting yesterday that presented a familiar story of someone who needed to rely on WiFi and was told they needed a new SIM. When that failed they were told they needed a replacement phone (which they were charged for). Of course that didn’t work either and the customer now had an old beat up phone instead of their new shiny one that they sent back. You can’t get your old phone back, you can’t get a refund for either old or new phone, and they have the nerve to tell you to keep trying to contact support.

From all reports their support staff never give up and never get frustrated with users. That’s good, but sometimes the best answer is that you need to choose a service provider that is more compatible with your needs. There are many people like me for whom the only benefit of Project Fi is their pricing model. They could price it at zero, but if it doesn’t work, what’s the point?

1 Like
Message an
Expert customer