FreePBX 15 Cisco Linksys SPA 922 remote phone misbehaving

FreePBX Endpoints
1

FreePBX 15.0.17.34 / Current Asterisk Version: 16.17.0 / all modules up to date

Apologies if my description is a bit vague tho’ I will attempt to describe the issue as well as I can. Also I’m not sure that this forum is the right place for this problem, but I’ll start here.

The FreePBX server is located in Vancouver BC and there are a number of Cisco Linksys SPA 922 IP phones deployed as remote extensions across Canada, including Ladysmith on Vancouver Island BC, Kelowna BC, Edmonton AB, and as well as one at a cottage in a wilderness location about 3 hours north of Toronto ON. I chose the Cisco 922 because they’re cheap to buy, easy to configure as a remote phone (factory reset and modify a couple of parameters), not terribly complicated for end users to operate, and light enough so they’re cheap to ship. (In addition to the 922s, the FreePBX server has a number of phones of various makes and models–Yealink, Aastra, Cisco, Sangoma, etc.–deployed in the city of Vancouver as remote extensions but they are not at issue here).

All of the 922s are in use and working well except for the 922 at a cottage in Ontario, so I am only concerned with the latter. Unfortunately, except for the logs on the FreePBX server, I don’t have much visibility into the 922 as somebody is physically only at the cottage for a few hours on occasional weekends.

Here’s the issue. A few weeks ago I had someone at the cottage plug in the phone to the AC adapter, plug in an Ethernet cable into the “router” and into the phone, and send me the public IP address of the “router” (as I said, simple for users to set up). I have a pfSense firewall configured with rules to allow access to specific IP addresses (i.e., the public IPs of remote phones) and their specific SIP and RTP port ranges. It all works very well, except for the cottage 922.

Initially, as far as I can recall, the cottage 922 worked just fine. I made a few test calls to and from the 922, and checked that the 922 could make local calls here in Vancouver, and all seemed well. I have a FOP2 server, and I could see that the cottage 922 was available, so I pretty much forgot about it.

However, I started noticing some random “chattering” (unreachable/reachable) in the logs, as follows (IP, port, and extension anonymized):

[2021-05-30 09:13:42] VERBOSE[6253] res_pjsip/pjsip_configuration.c: Endpoint 1004 is now Reachable
[2021-05-30 09:13:42] VERBOSE[6253] res_pjsip/pjsip_options.c: Contact 1004/sip:[email protected]:5062;x-ast-orig-host=192.168.0.159:5061 is now Reachable. RTT: 1221.096 msec
[2021-05-30 09:14:44] VERBOSE[31685] res_pjsip/pjsip_configuration.c: Endpoint 1004 is now Unreachable
[2021-05-30 09:14:44] VERBOSE[31685] res_pjsip/pjsip_options.c: Contact 1004/sip:[email protected]:5062;x-ast-orig-host=192.168.0.159:5061 is now Unreachable. RTT: 0.000 msec
[2021-05-30 12:20:41] VERBOSE[28683] res_pjsip/pjsip_configuration.c: Endpoint 1004 is now Reachable
[2021-05-30 12:20:41] VERBOSE[28683] res_pjsip/pjsip_options.c: Contact 1004/sip:[email protected]:5062;x-ast-orig-host=192.168.0.159:5061 is now Reachable. RTT: 136.431 msec
[2021-05-30 12:21:44] VERBOSE[31756] res_pjsip/pjsip_configuration.c: Endpoint 1004 is now Unreachable
[2021-05-30 12:21:44] VERBOSE[31756] res_pjsip/pjsip_options.c: Contact 1004/sip:[email protected]:5062;x-ast-orig-host=192.168.0.159:5061 is now Unreachable. RTT: 0.000 msec
[2021-05-30 13:07:42] VERBOSE[5904] res_pjsip/pjsip_configuration.c: Endpoint 1004 is now Reachable
[2021-05-30 13:07:42] VERBOSE[5904] res_pjsip/pjsip_options.c: Contact 1004/sip:[email protected]:5062;x-ast-orig-host=192.168.0.159:5061 is now Reachable. RTT: 438.286 msec
[2021-05-30 13:08:44] VERBOSE[6253] res_pjsip/pjsip_configuration.c: Endpoint 1004 is now Unreachable
[2021-05-30 13:08:44] VERBOSE[6253] res_pjsip/pjsip_options.c: Contact 1004/sip:[email protected]:5062;x-ast-orig-host=192.168.0.159:5061 is now Unreachable. RTT: 0.000 msec
[2021-05-30 13:54:43] VERBOSE[31685] res_pjsip/pjsip_configuration.c: Endpoint 1004 is now Reachable
[2021-05-30 13:54:43] VERBOSE[31685] res_pjsip/pjsip_options.c: Contact 1004/sip:[email protected]:5062;x-ast-orig-host=192.168.0.159:5061 is now Reachable. RTT: 1432.722 msec
[2021-05-30 13:55:44] VERBOSE[28683] res_pjsip/pjsip_configuration.c: Endpoint 1004 is now Unreachable
[2021-05-30 13:55:44] VERBOSE[28683] res_pjsip/pjsip_options.c: Contact 1004/sip:[email protected]:5062;x-ast-orig-host=192.168.0.159:5061 is now Unreachable. RTT: 0.000 msec
[2021-05-30 14:41:42] VERBOSE[5904] res_pjsip/pjsip_configuration.c: Endpoint 1004 is now Reachable
[2021-05-30 14:41:42] VERBOSE[5904] res_pjsip/pjsip_options.c: Contact 1004/sip:[email protected]:5062;x-ast-orig-host=192.168.0.159:5061 is now Reachable. RTT: 1273.873 msec
[2021-05-30 14:42:44] VERBOSE[31685] res_pjsip/pjsip_configuration.c: Endpoint 1004 is now Unreachable
[2021-05-30 14:42:44] VERBOSE[31685] res_pjsip/pjsip_options.c: Contact 1004/sip:[email protected]:5062;x-ast-orig-host=192.168.0.159:5061 is now Unreachable. RTT: 0.000 msec
[2021-05-30 17:48:41] VERBOSE[11409] res_pjsip/pjsip_configuration.c: Endpoint 1004 is now Reachable
[2021-05-30 17:48:41] VERBOSE[11409] res_pjsip/pjsip_options.c: Contact 1004/sip:[email protected]:5062;x-ast-orig-host=192.168.0.159:5061 is now Reachable. RTT: 193.525 msec
[2021-05-30 17:49:44] VERBOSE[11409] res_pjsip/pjsip_configuration.c: Endpoint 1004 is now Unreachable
[2021-05-30 17:49:44] VERBOSE[11409] res_pjsip/pjsip_options.c: Contact 1004/sip:[email protected]:5062;x-ast-orig-host=192.168.0.159:5061 is now Unreachable. RTT: 0.000 msec
[2021-05-30 18:35:43] VERBOSE[6253] res_pjsip/pjsip_configuration.c: Endpoint 1004 is now Reachable
[2021-05-30 18:35:43] VERBOSE[6253] res_pjsip/pjsip_options.c: Contact 1004/sip:[email protected]:5062;x-ast-orig-host=192.168.0.159:5061 is now Reachable. RTT: 1553.815 msec
[2021-05-30 18:36:44] VERBOSE[31685] res_pjsip/pjsip_configuration.c: Endpoint 1004 is now Unreachable
[2021-05-30 18:36:44] VERBOSE[31685] res_pjsip/pjsip_options.c: Contact 1004/sip:[email protected]:5062;x-ast-orig-host=192.168.0.159:5061 is now Unreachable. RTT: 0.000 msec

The remote extension is mostly down, but as can be seen, it does come up for a minute or so every hour or two. I’ve actually been able to make a call to that extension in the brief interval that it’s up, tho’ nobody has answered the phone. [Also today, I saw that the public IP had changed from 11.22.33.117 to 11.22.33.2 but I was able to modify the rules in pfSense to accommodate this.]

I did check with someone at the cottage who told me that the “router” that’s being used is a Bell Turbo Hub, which is apparently something that Bell (i.e., the ISP) uses to provide remote locations such as those in Ontario cottage country with reasonably fast internet access. I believe the Bell Turbo Hub is just a hot spot which provides access from the nearest cell tower.

If anyone has suggestions on how I can further this issue it would be appreciated.

2

I’m going to make a couple assumptions and guesses. If I’m right, cool; if not, they’re just guesses.

Your assumption that this is a cell-based hotspot would imply that the hotspot will only stay connected as long as there’s traffic and will be pretty aggressive about knocking the line down when not in use. If that’s the case, you would see the line go up when the phone registers every hour. RTP traffic might not be enough to keep the line up, and the UDP SIP Management traffic will only light the connection when the phone registers.

A different issue is the 1-second round trip times. That’s not going to work for a reasonable phone circuit. It might be theoretically a phone connection, but no one is going to put up with that for very long.

The fact that the public address changes should also be expected, since each new connection from the phone is a new “session” and the router would pick up a new connection for that. The fact that you would get the same address from one connection to the other is programmed as a preference by most providers, but there’s certainly no guarantees.

1 Like
3

@cynjut Thanks for the reply. I think your assumptions are quite likely correct, in particular that the hot spot will only stay connected as long as there’s traffic. On the weekend, I was able to text someone at the cottage and have them power cycle the IP phone, and as soon as this was done the line immediately came up, tho’ it didn’t stay up for very long. The last point you raise, re: the public IP address changing randomly, I believe I have addressed by modifying the rules in pfSense. (We’ll see if that’s true.)

The excessive RTT (round trip times) numbers are possibly a function of the fact that this is an inexpensive (maybe the least expensive available) internet connection. I believe Bell does offer phone service on top of the internet provided for an additional cost, so I presume that would mean upgrading to faster internet.

But I suppose, since this is a wilderness phone one could use it like people used to communicate on an old-fashioned walkie-talkie (what my nine year old grandson calls “old school”):

“Hi Joe, this is Sam. Do you copy? Over.”
“Roger Sam, I copy you fine. How’re you doing? Over”

Of course, if possible I’d rather the long RTT issue be addressed either in the Cisco 922 configuration, or in FreePBX…

4

Neither of those is going to get a vote in how fast the connection is, and that going to be the primary predictor of RTT Time. A Straight phone line connected to the PSTN and then routed into your phone system would probably not be a bad idea.

5

@cynjut Thanks.

For comparison, here are RTTs for the identical models of Cisco Linksys SPA 922 phones configured similarly. Ext. 1001 is about 400 km from the FreePBX server, while ext. 1002 is about 1600 km. Both destinations are in cities with good infrastructure…

2021-05-30 23:03:18] VERBOSE[11409] res_pjsip/pjsip_options.c: Contact 1001/sip:[email protected]:5060;x-ast-orig-host=10.0.0.139:5060 is now Reachable. RTT: 82.416 msec
[2021-05-30 23:13:21] VERBOSE[5904] res_pjsip/pjsip_options.c: Contact 1001/sip:[email protected]:5060;x-ast-orig-host=10.0.0.139:5060 is now Unreachable. RTT: 0.000 msec
[2021-05-30 23:14:18] VERBOSE[31756] res_pjsip/pjsip_options.c: Contact 1001/sip:[email protected]:5060;x-ast-orig-host=10.0.0.139:5060 is now Reachable. RTT: 78.310 msec
[2021-05-30 23:56:21] VERBOSE[5904] res_pjsip/pjsip_options.c: Contact 1001/sip:[email protected]:5060;x-ast-orig-host=10.0.0.139:5060 is now Unreachable. RTT: 0.000 msec
[2021-05-30 23:57:18] VERBOSE[5904] res_pjsip/pjsip_options.c: Contact 1001/sip:[email protected]:5060;x-ast-orig-host=10.0.0.139:5060 is now Reachable. RTT: 80.778 msec
[2021-05-31 02:24:21] VERBOSE[11409] res_pjsip/pjsip_options.c: Contact 1001/sip:[email protected]:5060;x-ast-orig-host=10.0.0.139:5060 is now Unreachable. RTT: 0.000 msec
[2021-05-31 02:25:18] VERBOSE[11409] res_pjsip/pjsip_options.c: Contact 1001/sip:[email protected]:5060;x-ast-orig-host=10.0.0.139:5060 is now Reachable. RTT: 73.317 msec
[2021-05-31 20:10:05] VERBOSE[11409] res_pjsip/pjsip_options.c: Contact 1002/sip:[email protected]:5060;x-ast-orig-host=192.168.0.19:5060 is now Unreachable. RTT: 0.000 msec
[2021-05-31 20:54:02] VERBOSE[5904] res_pjsip/pjsip_options.c: Contact 1002/sip:[email protected]:5060;x-ast-orig-host=192.168.0.19:5060 is now Reachable. RTT: 51.634 msec
[2021-05-31 22:24:05] VERBOSE[23934] res_pjsip/pjsip_options.c: Contact 1002/sip:[email protected]:5060;x-ast-orig-host=192.168.0.19:5060 is now Unreachable. RTT: 0.000 msec
[2021-05-31 22:28:02] VERBOSE[31756] res_pjsip/pjsip_options.c: Contact 1002/sip:[email protected]:5060;x-ast-orig-host=192.168.0.19:5060 is now Reachable. RTT: 49.884 msec
[2021-06-02 01:47:05] VERBOSE[6253] res_pjsip/pjsip_options.c: Contact 1002/sip:[email protected]:5060;x-ast-orig-host=192.168.0.19:5060 is now Unreachable. RTT: 0.000 msec
[2021-06-02 01:48:02] VERBOSE[23934] res_pjsip/pjsip_options.c: Contact 1002/sip:[email protected]:5060;x-ast-orig-host=192.168.0.19:5060 is now Reachable. RTT: 41.379 msec

6

That’s a perfectly respectable round trip time.

That, on the other hand, is not. The amount of time it takes for the packets to get from the server to the phone and back again (RTT, or round trip time) make a noticeable difference within the real-time conversations between the end points.

7

@cynjut Thanks again for sticking with me on this.

Yes, I agree the RTTs from ext. 1001 and 1002 are respectable; they were only included for comparison.

In your earlier post you indicated that the primary predictor of RTT most likely is in the hands of the ISP (Bell) and the hardware (i.e., the Bell Turbo Hub) and not something that can be addressed from afar within FreePBX or by changing settings on the Cisco 922. So I suppose my next line of inquiry should be to the ISP to see if they have any recommendations. Unfortunately I am not the subscriber who owns the internet connection, so they might be (understandably) suspicious of someone calling from thousands of kilometers away. I do know the subscriber well, but he is not technically oriented and I don’t really want to bother him with this at the moment (I know he has more pressing issues on his plate).

I’ll have to ponder this for a while.

1 Like
8

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.