VoIP issue with Asus RT-N66U router and CallCentric

[milhouse_00]

Hello,

I'm new to this forum and I've already read a lot of issues similar to mine on SNB.
Unfortunately, I haven't been able to resolve it.

Here's a quick summary.

Router: Asus RT-N66u running AsusWRT Merlin v. 380.66_4
ATA: Cisco SPA112 (with latest firmware)
ISP: Teksavvy
VoIP provider: CallCentric

So here's what is happening intermittently: my calls drop at the 15min mark.

I've read about SIP ALG (which I disabled), my QoS is fine (I guess...) and every other settings are left to default.

My ATA as been configured according to CallCentric settings (https://www.callcentric.com/support/device/cisco/spa112-spa122)

Everything is fine except this problem.

Do you have any clue ?

Thanks

 

[JDB]

Does the RTP audio stream drop, or do you actually receive a BYE?


Sent from my iPhone using Tapatalk

 

[JDB]

And if it's RTP drop, 1 way (which way) or 2 way?


Sent from my iPhone using Tapatalk

 

[JDB]

And I'd suggest ditching the Cisco ATA temporarily and using a soft phone on your computer as then you can run a Wireshark trace at the same time and see what is happening in detail.


Sent from my iPhone using Tapatalk

 

[milhouse_00]

It drops.

As I said, the problem is intermittent but when it happens CallCentric tells me that I don't acknowledge a reINVITE packet.

JDB: the softphone idea is a good one.

Until I try that, if you or other members have any idea on how to solve this issue, I will try anything.

This is driving me nuts

 

[JDB]

Sounds like a NAT issue, they are sending you a REINVITE to maintain the session, but the router has closed the NAT'd port due to inactivity.

Can you screenshot all the Cisco ATA SIP config pages and I'll see if I can suggest which timer you need to reduce to make sure the NAT is refreshed more often.


Sent from my iPhone using Tapatalk

 

[JDB]

Reading the user guide these would be the key values to check...

Sent from my iPhone using Tapatalk

 

[RMerlin]

I have the same ATA at home, also on Teksavvy (not that it matters tho), but I'm using VoIP.ms. I recommend checking the configuration Wiki for VoIP.ms for the SPA112, some of these settings might also help you with Callcentric.

https://wiki.voip.ms/article/Cisco_SPA112

 

[milhouse_00]

JDB:
here are the screenshots of the SIP pages

RMerlin: I already did have a look at the voip.ms SPA112 pages and there is nothing unusual with CallCentric settings.
tbh I would have chosen voip.ms over CallCentric but they weren't able to port my phone #

*****************************
I know it will make a long post, but here is what CallCentric sent me today regarding my issue:
****** --> censored information


********************************
Hello,

We have gone over our records for calls that dropped abruptly, and we see the following recent calls (note that the timestamps below are in GMT/UTC):

Init date // Disc date // ANI
May 31, 2017 19:40:25 // May 31, 2017 19:59:26 // 1581******
May 31, 2017 19:21:11 // May 31, 2017 19:36:19 // 1581*******
May 31, 2017 17:30:41 // May 31, 2017 17:45:51 // anonymous
May 31, 2017 15:34:07 // May 31, 2017 15:47:21 // 1418*******

Going over the SIP signaling for these calls, like with your previous trouble ticket, we are showing that a ReINVITE was sent towards your SPA112 at the 15 minute mark/ however we're not receiving any sort of response back from your SPA112. Because we're not receiving any response back from your device, the call drops.

The following is the SIP signaling of an example (this was the incoming call received on May 31, 2017 19:21:11 (GMT/UTC) from 158*******):

Key:
204.11.192.22 -- our network
107.179.***.***-- your SPA112

204.11.192.22 --> 107.179.***.***
Arrival Time: May 31, 2017 19:21:11.604807000 GMT
INVITE sip:*************@192.168.1.250:5060 SIP/2.0
v: SIP/2.0/UDP 204.11.192.22:5080;branch=z9hG4bK-9f0f0474f984f7f5b585bbf3de364717
f: "Cell *****" <sip:158*******@66.193.176.35>;tag=3705247270-794329
t: <sip:1418******@ss.callcentric.com>
i: 34865041-3705247270-794300@msw1.telengy.net
CSeq: 1 INVITE
Max-Forwards: 13
m: <sip:53a4ce15cc0296dcc6af2638c4f6bf93@204.11.192.22:5080;transport=udp>
c: application/sdp
l: 231

v=0
o=NexTone-MSW 1609851661 1609851661 IN IP4 204.11.192.22
s=sip call
c=IN IP4 204.11.192.22
t=0 0
m=audio 61760 RTP/AVP 0 8 18 101
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=silenceSuppff - - - -
a=setup:actpass
----------------------------------

204.11.192.22 <-- 107.179.***.***
Arrival Time: May 31, 2017 19:21:11.647249000 GMT
SIP/2.0 100 Trying
t: <sip:1418*******@ss.callcentric.com>
f: "Cell *****" <sip:1581*******@66.193.176.35>;tag=3705247270-794329
i: 34865041-3705247270-794300@msw1.telengy.net
CSeq: 1 INVITE
v: SIP/2.0/UDP 204.11.192.22:5080;branch=z9hG4bK-9f0f0474f984f7f5b585bbf3de364717
Server: Cisco/SPA112-1.4.1(002)
Content-Length: 0
----------------------------------

204.11.192.22 <-- 107.179.***.***
Arrival Time: May 31, 2017 19:21:11.741508000 GMT
SIP/2.0 180 Ringing
t: <sip:1418*******@ss.callcentric.com>;tag=3188418750b5c97ai0
f: "Cell ******" <sip:1581*******@66.193.176.35>;tag=3705247270-794329
i: 34865041-3705247270-794300@msw1.telengy.net
CSeq: 1 INVITE
v: SIP/2.0/UDP 204.11.192.22:5080;branch=z9hG4bK-9f0f0474f984f7f5b585bbf3de364717
Contact: "***** *******" <sip:************@192.168.1.250:5060>
Server: Cisco/SPA112-1.4.1(002)
Remote-Party-ID: "****** *****" <sip:*********@callcentric.com>;screen=yes;party=called
Content-Length: 0
----------------------------------

204.11.192.22 <-- 107.179.***.***
Arrival Time: May 31, 2017 19:21:15.802501000 GMT
SIP/2.0 200 OK
t: <sip:1418*******@ss.callcentric.com>;tag=3188418750b5c97ai0
f: "*****" <sip:1581*******@66.193.176.35>;tag=3705247270-794329
i: 34865041-3705247270-794300@msw1.telengy.net
CSeq: 1 INVITE
v: SIP/2.0/UDP 204.11.192.22:5080;branch=z9hG4bK-9f0f0474f984f7f5b585bbf3de364717
Contact: "*******" <sip:**************@192.168.1.250:5060>
Server: Cisco/SPA112-1.4.1(002)
Remote-Party-ID: "******" <sip:********@callcentric.com>;screen=yes;party=called
Content-Length: 255
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces
Content-Type: application/sdp

v=0
o=- 443094 443094 IN IP4 192.168.1.250
s=-
c=IN IP4 192.168.1.250
t=0 0
m=audio 16470 RTP/AVP 0 100 101
a=rtpmap:0 PCMU/8000
a=rtpmap:100 NSE/8000
a=fmtp:100 192-193
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
----------------------------------

204.11.192.22 --> 107.179.***.***
Arrival Time: May 31, 2017 19:21:16.508701000 GMT
ACK sip:************@192.168.1.250:5060 SIP/2.0
v: SIP/2.0/UDP 204.11.192.22:5080;branch=z9hG4bK-a76573282aa3f60370f0373ed6500391
f: "******" <sip:1581********@66.193.176.35>;tag=3705247270-794329
t: <sip:1418*******@ss.callcentric.com>;tag=3188418750b5c97ai0
i: 34865041-3705247270-794300@msw1.telengy.net
CSeq: 1 ACK
Max-Forwards: 13
m: <sip:5f5953916cc4e47bfa954f5e5797aca1@204.11.192.22:5080;transport=udp>
Allow-Events: calling-name
Allow-Events: as-feature-event
Allow-Events: call-info
Allow-Events: presence
Allow-Events: line-seize
Allow-Events: dialog
Allow-Events: refer
Allow-Events: message-summary
l: 0
----------------------------------

204.11.192.22 --> 107.179.***.***
Arrival Time: May 31, 2017 19:36:02.616201000 GMT
INVITE sip:***********@192.168.1.250:5060 SIP/2.0
v: SIP/2.0/UDP 204.11.192.22:5080;branch=z9hG4bK-73bb106bc6f21f5fdf44874fa9f00c61
f: "*****" <sip:1581*******@66.193.176.35>;tag=3705247270-794329
t: <sip:1418********@ss.callcentric.com>;tag=3188418750b5c97ai0
i: 34865041-3705247270-794300@msw1.telengy.net
CSeq: 2 INVITE
Max-Forwards: 13
m: <sip:5f5953916cc4e47bfa954f5e5797aca1@204.11.192.22:5080;transport=udp>
Allow-Events: calling-name
Allow-Events: as-feature-event
Allow-Events: call-info
Allow-Events: presence
Allow-Events: line-seize
Allow-Events: dialog
Allow-Events: refer
Allow-Events: message-summary
c: application/sdp
l: 226

v=0
o=NexTone-MSW 1609851661 1609851661 IN IP4 204.11.192.22
s=sip call
c=IN IP4 204.11.192.22
t=0 0
m=audio 61760 RTP/AVP 0 101
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=silenceSuppff - - - -
a=setup:actpass

In terms of how the call was initially established, we are not seeing anything unusual; the call establishes normally. The issue occurs when a ReINVITE was sent towards your SPA112 (the packet that arrived at May 31, 2017 19:36:02.616201000 GMT)/ we don't receive any sort of response back from your device.

Going over our records, we see that your device is back to listening on port 5060; did you change it back from 6080 (as per the exchange from your previous trouble ticket)? Can you visit the Line configuration page of your SPA112 and set it to a port number other than 5060, as an example 5080 or 6080?

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

************************************************

To answer to CallCentric about their question: "we see that your device is back to listening on port 5060; did you change it back from 6080"... Yes I did. At first it was 5060 and the calls dropped. I changed it to port 6080...same result. I changed it back to 5060...

Thanks !

 

[JDB]

I would suggest enabling the NAT redirect keep alive as the first step and see how you go.


Sent from my iPhone using Tapatalk

 

[milhouse_00]

No luck with the "NAT redirect keep alive settings". It dropped at the 15min marks.

By doing my research on this forum and elsewhere, everyone was pointing at the SIP Passthrough settings and the ports 5060/5080 being blocked by the those settings.

Does this ring a bell to you ?

And how about those settings too:
RTSP passthrough
H.323 passthrough etc.

Thanks.

 

[JDB]

The problem is related to the SIP port 5060 being closed prematurely by the router, to stop that periodic packets need to be sent during the call. However I'm surprised that you are also not experiencing issues with missed incoming calls (maybe you are and are not aware!).

One possible solution would be to give the ATA a fixed LAN IP, and then set the router to port forward WAN:5060>ATA:5060 and port trigger ATA:5060>WAN:5060. This way you should get a permanent mapping of that port open. It's a bit of a hack but it should work.

 

[RMerlin]

And how about those settings too:
RTSP passthrough
H.323 passthrough etc.

I just keep everything set to Enabled + NAT Helper on that page.

 

[milhouse_00]

I just keep everything set to Enabled + NAT Helper on that page.

SIP Passthrough as well ?

 

[RMerlin]

SIP Passthrough as well ?

Yes.

 

[TOD]

milhouse_00
I guess the only thing that you need to enable "NAT Keep-Alive" for keeping allocated port(when your device registering on ITSP's server) in the open state to be able receive signaling(SIP) messages from ITSP's server.
But I recommend to check and other settings:
Go to
"SIP" >> "Remove Last Reg" >> Yes
"SIP" >> "Handle VIA received" >> No
"SIP" >> "Insert VIA received" >> No
"SIP" >> "Substitute VIA Addr" >> No
"SIP" >> "STUN Enable" >> No
"SIP" >> "Redirect Keep Alive" >> No
"SIP" >> "Handle VIA rport" >> No
"SIP" >> "Insert VIA rport" >> No
"SIP" >> "Send Resp To Src Port" >> No
"SIP" >> "STUN Test Enable" >> No
"SIP" >> "NAT Keep Alive Intvl" >> 30 (with standard value "UDP Timeout" in ASUS router, there is no need to send Keep-Alive packet often than 30 sec)

"Ext/Line" >> "NAT Mapping Enable" >> No
"Ext/Line" >> "NAT Keep Alive Enable" >> Yes
"Ext/Line" >> "NAT Keep Alive Msg" >> set it empty
"Ext/Line" >> "NAT Keep Alive Dest" >> $PROXY
"Ext/Line" >> "SIP Transport" >> UDP
"Ext/Line" >> "Register Expires" >> 3600 (there is no need to reregister every 60 seconds, if you are not in mobile network and your IP/ Port changes very often)
"Ext/Line" >> "Preferred Codec" >> G711a (or G711u) (G.711a/u gives voice more quality than G729, but many ITSP like to recommend G729, because it save his bandwidth[64 kbit/s vs 8 kbit/s] : )
"Ext/Line" >> "Use Pref Codec Only" >> Yes
"Ext/Line" >> "DTMF Tx Method" >> AVT
"Ext/Line" >> "Enable IP Dialing" >> No

This settings I recommend to many our clients, and that usually was enough for the devices to work correctly.

 

[milhouse_00]

Thx TOD, I wil give it a try tonight !

 

[Rowbby]

Just want to chime in that I'm having the exact same problem with a very similar setup...

Asus RT-N66U - Merlin v. 380.65_4
Cisco SPA112 (latest firmware - default SIP timers, etc.)
Callcentric VoIP

For me at least, only Inbound calls drop at the 15 minute mark; Outbound calls seem to continue just fine.

I've tried a whole bunch on the router side of things (passthroughs, port forwards) including putting the SPA112 on the DMZ. Didn't help.

Glad it's not just me. Was going crazy trying to figure it out...

 

[extensi0n]

With Bicom, we had to disable SIP passthrough, or the phones would lose sync.

So, the following may or may not help. Here's my 2 cents in relation, I hope, here. (via Bicom) The SPA112's IMHO, as fax adapters suck. (Yes, I knew better. Vendor said do it this way. Which I did.) Yes, VOIP faxing does suck period. Generally a last mile problem. I'm sure you can google issues in general with SPA112's. An SPA112 via voice calls, while not horrible, but, with many different firmwares, as they have been transitioned to voice. Ugh. I've had many of them just be not stable, drop packets via asuswert merlin, and just lock up with no rhyme or reason. Sure, VOIP system issue or not...Never got to the bottom of it...

I can say though, if the SPA112 works for you via voice, great. Fax on VOIP, forget it obviously. We've had better stability with the OBi200 1-Port VoIP Phone Adapter, but last mile issues with faxing still exist. We've used the Bicom solution, and now Netsapien's Skyswitch. The Obihai isn't supported on Netsapiens, but we've been able to make the SPA112 work as a generic device. Either way, good luck with the Cisco spa112...I'd rather step on a rusty nail, than keep relying on them in my ecosystem.

 

[JDB]

Just want to chime in that I'm having the exact same problem with a very similar setup...

Asus RT-N66U - Merlin v. 380.65_4
Cisco SPA112 (latest firmware - default SIP timers, etc.)
Callcentric VoIP

For me at least, only Inbound calls drop at the 15 minute mark; Outbound calls seem to continue just fine.

I've tried a whole bunch on the router side of things (passthroughs, port forwards) including putting the SPA112 on the DMZ. Didn't help.

Glad it's not just me. Was going crazy trying to figure it out...

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