VoIP issue with Asus RT-N66U router and CallCentric

[Rowbby]

This suggests that the ATA is setting a session expiry in the initial INVITE less than 15 mins and so refresh messages (RE-INVITE's) happen soon enough to keep the NAT port open, whereas Callcentric have a much longer expiry on their invite.
What I don't understand is why the ATA NAT keep-alive's are not doing their job.
Another possible option is to reduce the REGISTER timer from the default 3600 seconds to 60 seconds. ITSP's don't like this as it increases load on their system if everyone did this, but just you doing it won't be a problem.


Sent from my iPhone using Tapatalk

Surprisingly enough Callcentric actually recommends to set "REGISTER EXPIRES" to 60 in their setup guides, and just double checked my own set up and yep, it's set to 60 on the Callcentric line.

I guess I'm not entirely clear on how the Asus DMZ function works because I figured that would eliminate any kind of port forwarding, NAT problem as being the cause. Is that not right?

 

[JDB]

Yea you can DMZ, but it's really not recommended from a security point of view.
I'm sure there is some combination of settings that will work, but it may require some trial and error!


Sent from my iPhone using Tapatalk

 

[Rowbby]

Yeah, just did it for testing. Wasn't crazy about having to leave it like that. Didn't work anyway. The results were the same: inbound calls drop at 15 minutes.
Will try running the ATA through a different router tomorrow and see what the results are so I know which device to focus on. Thanks!

 

[JDB]

As I suggested above also, well worth trying a soft phone on a PC so you can run Wireshark at the same time and get a PCAP trace of the packets. Will give us a much better idea of what's happening.


Sent from my iPhone using Tapatalk

 

[milhouse_00]

Yeah, just did it for testing. Wasn't crazy about having to leave it like that. Didn't work anyway. The results were the same: inbound calls drop at 15 minutes.
Will try running the ATA through a different router tomorrow and see what the results are so I know which device to focus on. Thanks!

Is it an intermittent problem or your inbound calls drop EVERYTIME ?

In my case it is intermitent and it makes it REALLY difficult to troubleshoot.

I will try it with another router as well this weekend.

I'll keep you posted.

 

[Rowbby]

Is it an intermittent problem or your inbound calls drop EVERYTIME ?

In my case it is intermitent and it makes it REALLY difficult to troubleshoot.

I will try it with another router as well this weekend.

I'll keep you posted.

I thought the last couple calls seemed to drop consistently at 15 minutes, but just checked my Callcentric log and over the last month I've had incoming calls which lasted well over an hour so you're right, it's inconsistent! I checked my outbound calls and couldn't find any that end around the 15 minute mark so I think I'm still correct that it's an inbound only problem, at least for me.

Just hooked up the SPA112 to a different router and the first inbound test call did NOT drop at 15 minutes, but given the inconsistency that doesn't say much yet. Will keep this setup for now and let you know if I hit any dropped calls.

 

[Kiwilad]

Hi this may be a strange one but we use the same router in our office on an external SIP VoIP provider (running 25 extns) and I've found that we had major issues with the latest firmware 380-66-4 with our Cisco SPA504G phones and our audio conf Polycom units. the Cisco phones would drop calls and loose the extn DSS module (one touch) dial features and the Polycom conf units would loose their time settings and revert back to "unknown extn". I changed the firmware on the ASUS RT-N66U back to 380-65-4 and everything works again. Just a thought for you to try.

 

[TOD]

Kiwilad
It is highly doubtful that there is a problem with firmware version.
My Gigaset C610-A IP works through 2 NAT:
1) ASUS RT-N16 with V25E1 ( john9527's fork)
2) ASUS RT-N66U with 380.66_4 (ASUS-Merlin)
and I never had problems with telephony in this configuration, none of firmware versions of those routers.

If it is not possible to diagnose at telephony level, then at least reset the router to be sure there are no issues associated with upgrade process.

 

[milhouse_00]

**** update*****

I had a TP-LINK archer c1200 laying around (stock config)

Without changing anything (except QoS) I switched my RT-N66u with this one.

I performed many tests (inbound, outbound, from a landline, from a VoIP softphone.

Everything was going well until my mom (yes, my mom) called me from her landline....and the call dropped at 15 min precisely...

I really don't know what to think now.

Is it CallCentric's fault ?!?!
The ATA ?
The router settings ? (did not change any settings with the TP-LINK)

 

[Rowbby]

**** update*****

I had a TP-LINK archer c1200 laying around (stock config)

Without changing anything (except QoS) I switched my RT-N66u with this one.

I performed many tests (inbound, outbound, from a landline, from a VoIP softphone.

Everything was going well until my mom (yes, my mom) called me from her landline....and the call dropped at 15 min precisely...

I really don't know what to think now.

Is it CallCentric's fault ?!?!
The ATA ?
The router settings ? (did not change any settings with the TP-LINK)

The "intermittentness" is the most frustrating part to me. Since you have a softphone up and running, could you do a few tests (trying to get a dropped call) while using Wireshark and dump the output when the call drops?

I haven't dropped a call yet since switching routers on Saturday. Going to leave it a few more days and see what happens. I used this SPA112 with an older RT-N66U (on a much older version of Merlin) flawlessly for 2+ years (2012-2014) and then with a TP-Link WDR3600 for 2+years after that so I don't think the SPA112 is the lone culprit here...

 

[milhouse_00]

The "intermittentness" is the most frustrating part to me. Since you have a softphone up and running, could you do a few tests (trying to get a dropped call) while using Wireshark and dump the output when the call drops?

I haven't dropped a call yet since switching routers on Saturday. Going to leave it a few more days and see what happens. I used this SPA112 with an older RT-N66U (on a much older version of Merlin) flawlessly for 2+ years (2012-2014) and then with a TP-Link WDR3600 for 2+years after that so I don't think the SPA112 is the lone culprit here...

Were you with Callcentric all those years ?

FYI, I tried Tomato Shibby on my N66u... same result. Even Callcentric suggested me a GrandStream ATA over my Cisco SPA112.

Other people have the same setup as us. But they're using VoIP.ms rather than Callcentric and everything is fine.

Is it a missmatch between ATA/router/VoIP provider ?!?!

 

[Rowbby]

Were you with Callcentric all those years ?

FYI, I tried Tomato Shibby on my N66u... same result. Even Callcentric suggested me a GrandStream ATA over my Cisco SPA112.

Other people have the same setup as us. But they're using VoIP.ms rather than Callcentric and everything is fine.

Is it a missmatch between ATA/router/VoIP provider ?!?!

Yep, been with Callcentric through all those years.

I've seen posts of people saying they were only able to resolve the "15 minute issue" by changing VoIP providers away from Callcentric. Others say, the SPA112 is to blame and changing it to Obihai or Grandstream will resolve the problem. And then there's me at the moment where, on a different router, I haven't had any issues since Saturday. Just like the drop issues aren't consistent, the way people are resolving them isn't consistent either. Because of that, I'm a little hesitant to dump any service or device just cause it worked for someone else without understanding why.

I'm going to stay on the other router a few more days to make I sure I don't drop any calls, then I'll switch back to the Asus and do whatever I can to diagnose what's going wrong. I'm remote though so there's a limit to what I can do in terms of switching firmwares, resets, etc. for the time being.

P.S. I do have a different VoIP provider set up on line 2. The call quality is horrible, but I never noticed any drops. So switching away from Callcentric may "resolve" the problem in the sense that another provider might not have the same requirement that a response be received to keep the call up longer than 15 minutes, but I'd rather stick with Callcentric and figure out why the response isn't being sent/received.

 

[TOD]

I think you can mirror the traffic(using iptables on ASUS-Merlin) between ITSP and the ATA to your computer , where in promiscuous mode you will be able to collect this traffic by Wireshark for further analysis.
Of course unless you think it's too difficult for you.

 

[JDB]

I think you can mirror the traffic(using iptables on ASUS-Merlin) between ITSP and the ATA to your computer , where in promiscuous mode you will be able to collect this traffic by Wireshark for further analysis.
Of course unless you think it's too difficult for you.

You can also install tcpdump on the router itself, probably easier.
https://swenotes.wordpress.com/2013/10/15/monitoring-asus-rt-n66u/


Sent from my iPhone using Tapatalk

 

[milhouse_00]

Here is what Callcentric Help Desk answered to my ticket (reinvite and BYE issue)
*************************
[
LOT OF LOGS
]
Just to explain what's occurring above for this call is; firstly in terms of the call setup, we do not see anything unusual, we are showing that your SPA112 is receiving the call attempt (your SPA112 received the call from our server 204.11.192.161) and processed/ established the call. The main problem that we do see is the SIP BYE packet we're receiving from your SPA112; while we are receiving one from your device, your device is not sending it to the correct server -- your device is suppose to send the SIP BYE packet to the server that call originated from in this case your device was suppose to send the call to the server 204.11.192.161; instead your device sends the call to 204.11.192.22 as well as 204.11.192.163, which it shouldn't be doing.

Before anything, from the screen captures that you have provided us; are you able to set the option "Proxy Redundancy Method" to "Based on SRV Port". If you are still having issues are you able to remove what you've defined on the option "Outbound Proxy". Note that any changes that you do perform, you will need to reboot the device for the changes to take into effect.

If you have any other questions, please let us know.
***************************

Are they investigating the right settings or they're not even close ?

If I listen to them, the ATA settings are faulty. Not necesserly the router. (strange because I used their recommended settings)

 

[JDB]

Pffft, could be Proxy issues I guess, but really they should only affect REGISTER and INVITE, the BYE will go where it's told based on the Contact/Via/Record-Route headers from the proceeding messages (can get very complex where Proxies are involved).
Worth a go doing as they suggest but I'd only be 10% sure of it fixing the issue.
More likely the ATA has a bug (unlikely assuming you are using latest firmware) or the router is doing SIP ALA badly (but I think you said that was off).


Sent from my iPhone using Tapatalk

 

[RMerlin]

This might be dodging the issue rather than fixing it, but are you tied to Callcentric? I've used voip.ms at home (with an SPA112) and Callcentric at the office (with an Asterisk box). Of the two, Callcentric is the one which gave me the most headaches over the years.

A few weeks ago, I ported my business Callcentric number to voip.ms as well (the port from CC to VoIP.MS went fine). Had to open one ticket with voip.ms since I needed inter-subaccount forwarding (and it can only be manually enabled by their tech support). Within 15 mins they completed the request, and everything's working great so far. They also offer a lot of different servers, so you can pick one that's closest to you for best performance.

Debugging SIP can be a real PITA. It's a fairly complex technology, not many persons have the required know-how to do low-level troubleshooting of it (personally, I don't).

Otherwise, I'd try a Google search for SPA112 and Callcentric, see if your issue is common to this combination. If it is, someone might have a suggestion on how to get around the issue - the SPA112 has a LOT of settings you can tweak and adjust.

 

[TOD]

It's a fairly complex technology, not many persons have the required know-how to do low-level troubleshooting of it

And you must know server platform, to know how it handle all SIP headers. The differences may be radical.

 

[milhouse_00]

This might be dodging the issue rather than fixing it, but are you tied to Callcentric? I've used voip.ms at home (with an SPA112) and Callcentric at the office (with an Asterisk box). Of the two, Callcentric is the one which gave me the most headaches over the years.

A few weeks ago, I ported my business Callcentric number to voip.ms as well (the port from CC to VoIP.MS went fine). Had to open one ticket with voip.ms since I needed inter-subaccount forwarding (and it can only be manually enabled by their tech support). Within 15 mins they completed the request, and everything's working great so far. They also offer a lot of different servers, so you can pick one that's closest to you for best performance.

Debugging SIP can be a real PITA. It's a fairly complex technology, not many persons have the required know-how to do low-level troubleshooting of it (personally, I don't).

Otherwise, I'd try a Google search for SPA112 and Callcentric, see if your issue is common to this combination. If it is, someone might have a suggestion on how to get around the issue - the SPA112 has a LOT of settings you can tweak and adjust.

VoIP.MS was my first choice... but they weren't able to port my existing number, while CC were.

CC suggested me GrandStream or Obi ATA. I might go with this one: https://www.amazon.ca/dp/B007EYY3XU/?tag=smallncom-20

What do you guys think ?!?!

As soon as VoIP.MS can port my number, I'll go with them hands down.

 

[RMerlin]

What do you guys think ?!?!

Grandstream are usually well-regarded. I don't have any first-hand experience with their products however. My fear would be if you end up spending a good amount of money and in the end it doesn't really solve your problem.

As soon as VoIP.MS can port my number, I'll go with them hands down.

Check again to see if they can port it. If you log on to your voip.ms account, you can check for portability of a number. Maybe it will be portable now that it's with CC? I'm not sure what their criteria is for determining eligibility.