NHS organisations connected to the Transition Network (previously N3) delivered almost all clinical services over the private network. This included several services like voice over Internet Protocol (VoIP) and video conferencing. As a result, it was feasible to use either private IP addresses or public addresses (RIPE) on the Transition Network - see the Transition Network IP addressing policy for detail.
Migrate voice and/or video to HSCN
Dependent on how you choose to migrate your voice and/or video services to HSCN you will either:
- retain your existing hardware
- require new hardware and software
Retain existing hardware
If you wish to retain your existing voice and video conferencing hardware after migrating to HSCN you should read the common issues section in detail. You may find that you cannot simply re-establish a replacement voice and video conferencing service without making significant security and routing configuration changes or introducing additional hardware and/or software.
New hardware and software
If you purchase new or replacement HSCN voice and video conferencing services as a package you may have new or replacement hardware and software provided by your chosen voice and video supplier.
Your supplier is responsible for ensuring the services provided work as required. They should supply and configure any hardware and software purchased, assist with firewall configuration and provide any ancillary devices required.
Your chosen supplier should be the first point of contact for queries on any new hardware or software. Further guidance on this topic is out of the scope of this document.
HSCN video conferencing solutions
There are several solutions you can consider when replacing an existing TN IP video service or selecting a new video service.
- The NHSmail Skype for Business service works over both HSCN and the internet and is available through a framework. For details email email@example.com.
- Purchase a replacement video or unified communications service from one of the vendors currently published on the G-Cloud Framework. Some of these vendors already have a video, voice or unified communications service hosted on HSCN. See Business Applications guidance - video conferencing.
- Discuss available video or unified communications services with HSCN suppliers to determine what they can offer.
- You could choose to re-engineer existing architecture to provide a video, voice or unified communications service mapped to your own specific requirements.
This guidance aims to address some of the most common issues encountered when migrating voice and/or video services from the TN to HSCN.
1. Access video conferencing services across HSCN and the TN
The TN video platform has two methods of access:
Consumers with a fully managed BT video conferencing service connect to this over the TN. These consumers can initiate the conference and invite point-to-point or multi-point participants (guests). Consumers with an existing BT managed video conferencing service must cease or replace this service prior to migrating to HSCN.
Guest access: guests can access the video conference bridge over either:
- the TN, if the guest has a TN connection
- the internet video conferencing bridge for external guests
Guests can participate in conferences but can’t initiate them or invite other attendees.
Guests do not receive management or support from BT. You should be vigilant during your migration planning phase because the existing use of guest video conferencing services can easily be overlooked. Consumers who access the existing TN video conferencing service as a guest will also need to find a replacement video conferencing service when migrating to HSCN.
You must be able to route voice and video protocols H.323 and H.225 without intervention if you wish to take part in a TN video conference. If you’re using your existing TN video conferencing service, this will not work once migrated to HSCN.
2. Endpoint IP addresses
The initiating endpoint IP address and port mapping must be maintained for successful communication. This is because H.323/Session Initiation Protocol (SIP) embeds the endpoint IP address in the data payload, so when the packet is de-encapsulated at the receiving end the IP address that is presented to the video/voice service is the endpoint’s ‘real’ IP address.
If the endpoint’s IP address is a Request for Comments 1918 (RFC1918) address that is not visible or cannot be routed over the network (10.x, 172.16–172.31 or 192.168.x address for example) then the receiving video/voice system will try to send the response packets back to the non-routable address and the communication will fail.
Excluding the video conferencing bridge, the TN video conferencing service is a locally hosted service. BT has stated that registered endpoints must be located on the TN.
3. Network Address Translation
It is standard practice for organisations to use Network Address Translation (NAT) to map multiple internal devices to a single IP address when communicating over the internet. This is usually achieved by:
- addressing each internal device with an IP address from the RFC 1918 (private) address range
- mapping those addresses, using NAT, to an address that is unique on the wide area network (WAN)
NAT was not employed on the TN for voice and video conferencing sessions but is widely used on HSCN.
Voice and video services used on HSCN will still have NAT limitations. For example, for the H.323 and H.225 (audio/visual communications) protocols there is:
- no NAT on the same security interface
- no static Port Address Translation (PAT)
Audio/visual endpoint IP addresses on the TN were not subjected to NAT and the integrity of the IP address/port relationship was maintained.
Video conferencing using IP presents specific risks that must be mitigated in order to protect the systems and services within your network. Regular firewalls are generally considered inefficient unless they are SIP or video conferencing aware.
In addition, media and control ports are dynamically allocated between 1025 and 65535 unless the devices support, and are configured to use, fixed port ranges.
All network traffic should be encrypted to avoid eavesdropping.
Overcoming the NAT and firewall limitations for H.323 or SIP
If you currently use the BT-managed NHS video conferencing service, endpoints registered on the service will primarily use the TN to route video conferencing traffic.
Replacement HSCN video conferencing services are very likely to be cloud/internet hosted services. This means that any existing video conferencing endpoint device IP addresses cannot be directly exposed in the way they currently are on the TN.
There are several solutions that can be used to overcome the firewall and NAT limitations. Generally, the simpler the solution the lower the level of security protection that it provides. Video conferencing usually demands several, and sometimes all, of the ports within the ephemeral (dynamic) port range 1024 – 65535 to be allowed to traverse the firewall.
4. Locally hosted voice and video NAT, and security solutions
The following approaches are commonly used locally, either within an organisation or at the network egress of an organisation. They are used to overcome NAT issues and provide interoperability and security.
Home office networks - Universal Plug and Play
Small home office networks are usually connected to the Internet via their internet service provider, using a router provided by the service provider. The consumer is left to provide the firewall, so NAT is the only limitation to overcome. This is resolved by adopting Universal Plug and Play (UPnP). UPnP overcomes NAT traversal by recording a mapping of the IP address and port required for the H.323/SIP conversation and forwards the information whilst retaining the integrity of the mapping relationship.
This solution is considered rudimentary and provides a low level of security.
Small to medium business environments (<100 to 999 concurrent sessions)
Small to medium business environments usually demand a higher level of security and reliability. They should adopt a more robust approach using a Session Border Controller (SBC).
Most NHS organisations that currently have voice and video conferencing services and wish to retain their existing hardware fall into this category.
An SBC is a device or application that controls session communications, signalling and media stream control. It facilitates voice and video conferencing services, including:
- call control
- voice and video optimisation
In addition, an SBC can also:
- provide IP address translation and manipulate the call message to ensure compliance with media service message protocols and codec transposition
- hide internal network topology (network arrangement)
- enable encryption
- provide voice application specific firewall features
- detect and prevent denial of service attacks
SBC hardware devices are available from several leading suppliers. You as the consumer should determine which solution best fits your business requirements.
Application SBC examples include, but are not limited to:
- Session Traversal Utilities for NAT
- Traversal Using Relays around NAT
Enterprise environments E-SBC (>1000 concurrent sessions)
Enterprise SBC solutions work on the same principles as the small to medium business environment SBC solutions discussed above but are designed to accommodate significantly larger numbers of unique voice and video conferencing sessions.