Last Fall our internet provider, CRRS Tv, upgraded our internet service from DSL to fiber and also included VoIP landline for us. Most hams that have used and are familiar with a phone patch know, there are restrictions on how a phone patch is connected and operated. The most important restriction for us at this point is that the Phone Patch cannot be accessed remotely from outside the local calling area. In Labrador West this includes the three local communities of Wabush, Labrador City, & Fermont Quebec. The regulations for phone patches was based on Landlines and is very grey these days with the use internet phones, cell phones VoIP, etc. The plan is to allow access to the phone patch from the RF side of the repeaters only (ie. Not from any remote connections such as iax, echolink…). Also, upon our request, outgoing Long Distance dialing has ben disabled by our ISP, CRRS Tv. The primary reasoning for a phone patch is for safety & security communications for our members as the cell phone coverage in our area degrades with every hardware upgrade made to the system.
The initial idea was to have three of our five repeaters have access to the phone patch. A huge number of VoIP telephone networks these days use the Asterisk server as a backend, the very same backend that AllstarLink & HamVoIP use. Great, should make connecting our Allstarlink based repeaters easy to connect to the VoIP landline… or so I thought! The issue that arises is the regulations stated above. Our repeater controllers are AllstarLink based, allowing incoming external connections using multiple modes (iax, iaxRpt, Echolink, Repeater Phone, IRLP, etc….) To strictly follow the Regs, all these modes of access would have to be disabled from incoming connections before engaging the phone patch. For some of these modes, this means unloading the module & restarting the asterisk server to disble the mode before ever connecting to the patch. Obviously a very poor solution that was quickly ruled out.
AllstarLink also has the ability to create ‘Private’ nodes behind a public node, by simply creating a new node on the asterisk server with a node number below 2000. These private nodes are generally used to crosslink a node to other Modes that is not natitvely supported by AllstarLink (eg. Fusion, P25, DMR, etc.). Under normal usage a private node is disconnected before linking the public node to other public nodes or networks, but if this were reversed it may be the solution to our phone patch. The idea was to create a private node for the phone patch and each of the the repeaters. All the repeater private nodes would be running the RF side of each repeater (ie. running the SimpleUSB) while the Public side would run as a Pseudo node that is permanetly connected to its own private node. Under normal use, this would be transparent to any user, remote or local, but once the patch was engaged, the private node (ie. the RF side of the repeater) would disconnect from the public side & connect to the private node containing the SIP (ie. the landline), isolating the two private nodes from any remote access & giving the local RF user a connection to the phone system.
Shortly after the fiber was installed last fall, VO2LB link to The Canada Hub was taken down for VO2LB station to be used for the initiall testing of the phone patch. A Private Node was created on VO2LB repeater & connected to the RF side of the repeater using simpleUSB. The Public side of the repeater was reconfigured as a pseudo node (ie. no RF). The private node was permanently connected to public node internally, making it appear to the end user as if it were an “All In One” RF repeater. When the patch was triggered for use, the private side disconnected from the Public node and then connected to the SIP line, isolating the phone patch from any remote access. The priliminary test proved the idea to have merit and further testing was needed using multiple repeaters, but other personal priorities & the December Holiday season overtook the project.
Sometime in February, VO2WL would key up intermittently with no apparent cause, then the problem would disappear after a few minutes as quickly as it started, making it look like some sort of looping problem in the network. Several days were spent trying to catch the problem while it was happening, but nothing could be found in the normal log files. A couple of custom scripts were written to catch possible events not recorded in any of the normal logging in Asterisk or Allstarlink. Another few days of collectting log files on VO2WL did leave a couple of clues that suggested VO2WL was not actually the problem at all. However, it did show that every time WL had problems, VO2LB had been connected to VO2WL, a leftover of a permanent connecat setup in a script the previous fall while testing the pacth. This further enforced the looping theroy. A request for an easy test from an intermediate node would have proven/disproven the looping theroy within minutes, but the request was very quickly & firmly denied. The only option left was pouring through log files to find exactly where the problem lay. Around early/mid April, both VO2WL & VO2LB were taken off the air for further testing in isolation, and a temporary hub (ie. No RF) was setup as VO2WL and left running on a seprate network.
Eventually a discovery was made in the log files of VO2LB that another node in the network was using a private node # of 1993, the same private node number that was used for patch testing on VO2LB last fall. Every time the ‘PTT log’ on VO2LB began the “Ping Pong” Keying, the log files showed there were two private nodes connected, both with the node number 1993. One of them was VO2LB but the log files are text based so it was not possible to see where the other 1993 was connecting from. Unfortunately, I assumed the issue was within the HoWL network and never did look at the bubble chart when the problem was occurring. The fix was very easy by simply changing the private node number on VO2LB, but that raises more potential issues with implementing a phone patch.
After the problem with VO2LB was resolved, VO2WL was upgraded to ASL 3.0, with a private node on the RF side, and reinstalled at the club building the day prior to our May meeting. A very brief update was given at that meeting, along with a commitment to give a more detailed explanation in a post on the web page, ( and why you’ve read this Long Post… :). A couple of days after the meeting, Myself & the XYL left for an extended trip, so time simply ran out to do any further work on the repeaters. At our next club meeting, (most likely in the fall) we need to have a discussion regarding the phone patch and the restrictions needed on the repeaters, and which direction we need to go in order to make a phone patch technically feasible and legitimate.
VO2WL is back on the air operating with a private node on the RF, as described above, for further patch testing. All incoming AllstarLink & Echolink connections on VO2WL have been disabled with the exception is Repeater Phone which bypasses the Allstarlink node numbering system and can connect regardless of the control mode of the repeater. This also introduces another problem for implementing a phone patch on a repeater. VO2LB is still on the test bench and currently operating as a Hub only (ie. No RF) & won’t be back on the air until later in the fall, but a priority has to be given on upgrading VO2LMC to ASL 3.0 and repairing the downlink from Smokey Mountain to the club building, which can only done in summer/early fall months, and is necessary before the phone patch can be completed.
Everyone have a safe & enjoyable summer. See you in the fall.
73, de VO2GO