Moto g1 incoming calls disconnect due to no response timeout while on my office wifi

been working with both RW and our office wifi now for ?? couple weeks to figure out why almost every incoming call to my phone, while on my office wifi, gets “disconnected due to no response time out” . So far noone has been able to nail down the issue. Phone works fine while at home/wifi, and seems to work fine out in public while on wifi…

The kind of obvious conclusion is that there is some kind of setting on our office wifi network that is impacting VOIP calls. However after working with our IT department we have verified that anything that “could or would” restrict VOIP calls is not the issue. So I am continuing to work with both RW and our IT department to see if we can figure this out.

I’ve been “googling” the crap out of this issue and so far haven’t found the needle in the haystack…

Any help out there would be greatly appreciated…thanks/Gary

I am sure that either your IT or Republic has checked to ensure that the current firewall/router considers the following

Your Router (home, school or business) or ISP *must not block outbound traffic *(from your phone) destined to the following ports:

  • 5090 UDP which is used for call set up
  • 6000-29999 UDP which are used for voice/audio
  • 8883 TCP MQTT which is used for Voicemail, Messaging SMS/MMS and keep-alive messages to RW servers.
  • NOTE: Most firewalls are stateful, meaning they allow two way communication *as long as it is initiated *by a client (phone) that is inside the routers network. This could be your home, school or office router/firewall
    • *Republic phones will always send the initial voice/audio data packet *to a destination port of 6000-29999 (regardless of who placed the call)
      Has your IT folks traced the line using something like Wireshark an open source (free) tool that can be used to capture the event?

Thanks jben!, I am going to forward this along to our IT dept. to see what kind of response I get from them. I do appreciate your input on this and lets hope it sparks some further investigations that may uncover something. I will be sure to report back to this thread!!! again, many thanks!!!

1 Like

The reference information quoted above was ‘crowd sourced’ from the Republic Community, in cooperation with Staff from
Republic Wireless, a IT personnel from both a University and an Enterprise customer.

KEEP IN MIND, THESE ARE INCOMING CALLS ONLY, AND ONLY HERE IN MY OFFICE WIFI. I HAVE NO PROBLEMS ON PUBLIC OR HOME WIFI’S.

The battle continues. This morning I sent a link to the ROUTER GENERAL SETTINGS for phone on REPUBLIC , to see if our IT dept will take the time to verify the suggested router settings. Further it just dawned on me that I have not always had this problem, even here at work. It seems to me that all of a sudden at some point I started having this problem.

Now this could have been 1 of 2 things. Either an app got installed on my phone or updated, or my office made some type of change to our wifi here at the office.

Again, whereas I have no control over the wifi here on campus, I do have control over my phone/status. So with that I am wondering if a factory reset is an option? would rolling back to factory original settings possibly resolve the issue? and what will I loose if/when I do this…thoughts??

thanks/Gary

Ok… I totally missed the “incoming call” in your original write-up. Many users with various phone models experience ‘wake-up’ problems that appear to be a Android Doze problem. It would be valuable to know if your phone is actually asleep when the delay occurs. Those of us that had/have the problem see the phone not being woke up when the call comes in on WiFi and it reverts over to Cell (see is-your-phone-losing-its-wifi-connection-while-sleeping ) Republic created 3.10.1.2 that fixed the problem for some, however many of still see failures)

On my Moto X Pure, if I let phone set idle for ~1.5 hours and call it shows OWA (Open White Arc) lack of WiFi, then the call comes in over on Cell and reverts to WiFi in 45 sec and this remains after the code update

  • You may want to see what the call quality is if you have an incoming call that occurs after a timeout compared to one that comes in following a call (<55 min) … this might be another clue as your problem sure looks like a corner case or others would probably have picked up on it with you

Let me explain further. The fact is, I have a solid RW ARC, and I actually am able to see the call coming in on the phone screen. I am actually able to slide/attempt answer the call…and while I am saying “hello hello”…the incoming call disconnects with the “disconnected due to response timeout” message displayed.

It’s not like the call never comes in, and ends up in voice mail or anything like that. I fully looks and feels like a cell->wifi handoff issue…at least to my observation. Hope this is helpful.

When the call comes in and wakes the screen and before you answer… does it say ‘Incoming via Cellular Network’ or “Incoming via Republic Wireless” (or close to that)

My hope is that we can narrow down a description that would provide Republic an idea of where to look.

Just thinking outloud here. I “assume” the handoff or handover process is what takes my incoming calls while I am on wifi, and “hands over” the call to the router/wifi I am currently attached to.

I’ve been reading about SIP timers, registrations etc etc which I understand the topic, but far from being an expert on. So my question is, ? does my phone get some kind of registration on the local router here at work when it attaches to it? Does that registration period have a timer? and does it expire? what happens to the registration when I loose the wifi signal then get it back. does it re-register itself again? what role does SIP play as it relates to the RW hand over process??

NOTE*** these incoming calls don’t even make it to voice mail. They get DROPPED at the point when the handoff is being attempted…seems to me the phrase TIME OUT is key here. Where is this “timer set”…which is apparently set to something within roughly 10-20 seconds…because these calls get disconnected pretty quick. And it’s roughly the same exact lenght of time every time the incoming call gets disconnected.

good question, let me try a test call and see if I can capture that! be right back

the screen reads “incoming call via wifi”…

Couple more observations to consider.

  • i just tried 3 land line calls to my phone and all 3 came through.

  • i powered off the phone, then turned it back on, and the calls are failing.

  • i noticed a couple icons bouncing back and forth…the icon that looks like a Y and the RW arc were bouncing back and forth, which I assume is the cell trying to hand over to the wifi…it makes a couple 2 or 3 attempts to do this and then is disconnects…interesting…

actually it’s less than 10-20 seconds as mentioned above. I get to say hello like 3 or 4 times then BANG! gone…

My understanding of the call flow process

  • Incoming Call -> call goes to RW Server where a check is made to see if you currently active on SIP/WiFi (Registered)
    • If you are active, then call is routed via Internet and eventually WiFi to you
      • Else call is passed off to the Carrier and it is routed to you via Cell (and the underlying hidden number)
  • On power up or reconnection to the Internet your phone will initiate a SIP Register, followed by Request/Status exchange and the time between these can vary up to ~120 sec… it will look something like this short sample

At this point I would suggest that you either update your Ticket (if it is still open) or open a new one referencing the closed one. As there is no logging visible to us, all you can provide is a clear description of the problem as you see/experience it. When trying to gather info on the failure seen in the problem I referenced above (by @billg), I used another phone to video the ring/answer/ and subsequent changes of the Status … then by playing back was able to get a clear picture of what was happening.

I did in fact update my current open ticket with the information regarding the bouncing between cell and wifi hand off…

OK the response I just got from RW technical assistance was what I call useless…basically the tech suggested I go do some testing based on the changes our company made to our wifi…when I specifically provided a screen shot along with some specific technical router questions requesting that RW tech support read and give feed back on…I find this to feel like a brush off!!!

So, here’s the first statement from our IT dept that I posted in my ticket…


more info from IT dept.

There is no router in Beaven. The Wireless Access Points are dump they just pass traffic along. All 800+ Wireless Access Points are controlled by three load balancer controllers (Aruba 7220 controllers). in the data center. It would be hard to find comparisons.

There are no SIP timers in the Wireless Access Point because it does not work like a home router. The Wireless Access Points take the traffic and dump it on the core network then the Palo Alto Firewall inspects the traffic and accepts or denies the traffic and type of traffic. I sent the sip application setup page and timers in the previous message as a screen shot.

Can you ask Republic if they are using IPv6 or toretto tunnelling in ipv4. I think it may be more related to that since we drop IPv6 packets if they are expecting an IPv6 response that may be the issue.

And here’s the second observation from our IT dept…


So it turns out that on the Palo Alto with ALG enabled it is actually off. When it is disabled it is actually enabled. We tested with the Deaf VoIP system today and it worked get.

so other than testing when I get to work tomorrow, I still have no real technical feedback from RW on the router configuration information provided above…so I’ve requested they reply specifically to this information…lets see what happens…

Sounds to me like the ports needed 5090 UDP to setup the calls is working fine but the audio ports a blocked so the call looks good but audio is not passing. Meaning your IT network is not allowing or losing the inbound RTP beofre it can get to the phone.

so other than testing when I get to work tomorrow, I still have no real technical feedback from RW on the router configuration information provided above…so I’ve requested they reply specifically to this information…lets see what happens…
This is not a level of corp network support we and any other carrier cannot support.

1 Like

You may want to make sure they realize that Republic uses port 5090 … because if they have disabled the SIP ALG in accordance with the example in Disable the SIP Application-level Gateway (ALG) they may have used 5060 (which is the standard)

I may have listed this above in one of my reply/updates…this latest action/response from my IT dept. seems to have resolved the issue…

“So it turns out that on the Palo Alto with ALG enabled it is actually off. When it is disabled it is actually enabled.”

tested this morning 3/9/2017 several calls to my phone from my office land line. All calls connected 100% without issue. The true test now will be incoming calls from professors in the classrooms here on campus looking for technical assistance…

just want to say thank you very much for everyone’s input and suggestions. Yes, it appears the problem existed here on our end. But getting to that point was…shall we say…“challenging”, :slight_smile:

1 Like

Here is a quote from Disable the SIP Application-level Gateway (ALG) a document by Paloalto Networks

When the firewall serves as an ALG for the Session Initiation Protocol (SIP), by default it performs NAT on the payload and opens dynamic pinholes for media ports. In some cases, depending on the SIP applications in use in your environment, the SIP endpoints have NAT intelligence embedded in their clients. In such cases, you might need to disable the SIP ALG functionality to prevent the firewall from modifying the signaling sessions. When SIP ALG is disabled, if App-ID determines that a session is SIP, the payload is not translated and dynamic pinholes are not opened. See Disable the SIP Application-level Gateway (ALG).
The SIP/VoIP relies on NAT (Network Address Translation) for proper function

SIP ALG (Application Layer Gateway) if enabled may cause problems with the NAT process

I have added the above note to the section in Checklist - Phone Info that deals with the Required Ports & Protocol

Thanks for your perseverance in working with Republic and the Community in resolving this problem

1 Like
Message an
Expert customer