Introduction
In this post I will share some observations and reflections made during the past years. Before I got my hands dirty with the details of the telecare alarm domain, I spent most of my time moving the telco world from analogue to IP, actively promoting and using the SIP protocol for VoIP.
Quite a few of the challenges and issues this industry is facing in the transition, we were through back in the days of migration to VoIP. Unfortunately, I see many of the early day’s mistakes being repeated which could be avoided since they were addressed back then.
I hope this post will save people some time to not re-invent the wheel by spending time on problems solved in the past. Also, it could help those that are in the migration process to make educated decisions on solution architecture and procurement of equipment or services. If you don’t have proper requirements, you will face problems down the line.
The migration challenges
There is no doubt that the migration from analogue connected to IP connected telecare systems has started or will happen! Some parts in the world have come further than other, but still most solutions use the plain old telephony systems to connect alarm devices back to alarm centres.
In the old systems an alarm event is sent from the alarm-device by placing an ordinary phone call which is answered by the alarm receiving centre. The device first automatically exchanges some information using DTMF tones or modem signalling to indicate which type of alarm event that is sent and identity of the device. Then in some cases a voice call is established between an operator at the alarm receiving centre and the device.
Today most voice communication have moved to IP based protocols and the old telephony systems will be shut down. Using the old analogue protocols in the VoIP networks impose some technical challenges. It is much more efficient and secure to move the alarm transmission to native IP based protocols.
However, there is a huge installed base out there using the old protocols, and even though some of them support IP based protocols it is a costly and time-consuming effort to re-program the devices since many of them don’t support mass remote provisioning. So, over the coming years there will be need for co-existence of old and new protocols.
IP protocol challenges
In the old protocols the alarm was transmitted as data signalling inside a voice call. In the new protocols the alarm transmission is separated from voice calls. This mean that to be able to replicate the old systems it is not just a matter of handling alarm events and voice in the same communication session.
The service provider also needs to understand the details of and operate a VoIP infrastructure to be able to set up a voice call between the device and the receiving operator.
The latter part is a well know domain for players in telecom and enterprise communications space, but its new territory for telecare alarm device vendors and providers of alarm receiving centres. It is common to under-estimate the complexity of the IP based voice infrastructure and that is why we see many of the mistakes being repeated which I will touch upon here.
Lack of SIP protocol understanding
A root cause of challenges I have seen is lack of understanding of IP protocols and the Internet model.
First, some of the protocols such as SCAIP/CENELEC TS 50134-9 and NOW-IP/BS 8521:2020 are built as extensions to the SIP protocol (RFC 3261 and other applicable extensions). SIP is the Internet protocol designed for voice and video real time communication. This means that implementors of these protocols first must have sufficient understanding and use proper implementations of SIP.
The SIP protocol gives the impression to be very simple, and to build something that send something that looks like proper SIP messages is easy. But it is easy to get trapped since a working solution requires use of a proper SIP stack and relevant extensions, as well as a deeper understanding of the protocol operation.
Lack of DNS understanding
This is where it shines through that many players lack Internet experience. Some devices out there are not supporting DNS domain resolving properly and assume static IP addresses of the remote system to be configured. For the SIP protocol the use of DNS is fundamental to build a reliable service, for example how to allow a system of multiple servers to be deployed with automatic failover as specified in RFC 3263.
The worst implementation I have seen seemed to only resolve a host in DNS when it started. If servers got new IP-addresses, it required a restart of the device to trigger a new resolve.
Also, DNS domains play an important role in the SIP signalling to identify a target destination. I have also seen cases where SIP destinations could only be IP addresses. This means that the device would not be able to use most of the services out there since these are resolved using domains from DNS.
Proper DNS support is a must to be able to build a fault tolerant and robust service. A robust solution is not built around single points of failure. It is a design based on multiple active nodes and where traffic can take multiple different paths. In case one path fail, the device will make a new attempt selecting another path which will hit a working node. This is the fundamental design of the Internet which is applied in all modern communication network and cloud service design.
Appropriate security design
Maybe security should be the main driver to quickly migrate old solutions. In the old analogue protocols, there is no security in place at all. If you know the phone number of the alarm receiving centre, you could easily place calls impersonating a device since there is no authentication mechanism in place. And signalling traffic is assumed to be protected physically by the old telephone wires. It would also be quite easy to bring down the service by placing many calls at the same time to the alarm centre.
It seems like the old players have not understood the new environment and see security as a feature that in best case it patched on afterwards. This is a pity since the SIP protocol already have appropriate security mechanisms built in such as request authentication, encryption of signalling and encryption of media streams.
Use of anything than SIP/TLS for and SRTP for media is not secure and can’t be GDPR compliant since it is breaking the privacy by design requirement.
These problems must be addressed by the customers procuring solutions, otherwise suppliers will continue to take security shortcuts. At the end it is the party providing the service that will suffer in case of leak of personal data or DoS attacks due to poor system implementation.
Another thing I have experienced is that suppliers claim that the solution is secure because they use devices with mobile network connectivity, using private APN to cover for their lack of implementation of SIP security functionality. But what happens when the traffic leaves the mobile operator network? And what if you want to use the ethernet port on the device for redundancy and connect via public Internet?
Each SIP request must be authenticated. SIP supports the use of username/password credentials but even better would be if each device used a client TLS certificate for authentication.
And TLS server certificates must be evaluated by connecting devices to prevent man in the middle attacks and service theft.
Obviously, security layers can’t be supplier proprietary since it will break the whole ecosystem. But this unfortunately happens. I once was involved in a case where one supplier was using SIP over UDP to send SCAIP events. They had introduced their own encryption scheme of the SIP body containing the SCAIP XML message. But the rest of the SIP message and headers containing personal data remained in clear. This solution not only had questionable security design but also breaks interoperability in the ecosystem. The proper solution would have been to use SIP over TLS.
Unfortunately, the current state of implementations out there is sad to see. I hope the industry would take this seriously and not have to act reactively after some major security incident that otherwise would happen eventually.
Other VoIP challenges
The new IP based telecare alarm protocols de-couple the alarm event transmission from the SIP VoIP call. This mean that end to end solution must incorporate a proper SIP VoIP infrastructure that addresses all associated complexity.
For example, NAT traversal is one challenge. Devices may be placed behind a NAT or broadband router. This means that the device is not using a public IP address in signalling which may cause problems in communication back to the device.
There exist best practices how to address these challenges, such as use of persistent TLS connections as specified in RFC 5626 where the device make an outbound TLS connection back to the SIP server that then is re-used for incoming calls and thereby allow it to traverse the NAT.
To address media issue use of symmetrical ports for SRTP packets and SRTP relay servers may be used. Best practices for NAT traversal and SIP are described in RFC 6314.
One more complexity is that the devices now are spread across multiple networks on Internet. The receiving side must be prepared to handle incoming SIP traffic from multiple sources. This mean that access control can’t just be made using IP address filters or be limited from specified source networks. A security infrastructure resilient to Internet exposure must be in place.
Summary
I know this article is very problem focused and the purpose is to make sure there is an awareness of the problems but not at least show that there are already proven solutions to the problems. It is just a matter of customers to be aware of these and put requirements on the suppliers.
Of course, there are several positive aspects moving from the old analogue protocols to IP based protocols beyond improved security, such a rise of new innovative services, entrant of new players to the market and improved user experience. To be covered in another post.
Build critical alarm communications services with Alarmbridge
Build real-time and critical alarm services with our Alarmbridge API. Send and receive alarm events. Convert between a wide range of protocols, regardless of if they are analog or digital. Escalate alarms to trigger voice calls between the receiving platform and the devices.
