Initial Broadband fault checks for VoiceHost ADSL and FTTC connections

1. Check the router is set to an 'Always on' connection and not 'On demand'.
2. If you have ADSL try changing the ADSL Micro Filter, the most common cause of intermittent connections is a faulty filter. If you have FTTC please skip this step.
3. Please ensure that you change the RJ-11 lead between the microfilter/FTTC faceplate and the router/modem.
4. Make sure your router is connected to the BT Master Socket and no telephone extension leads are used between the wall and the router. Only use the supplied modem cable directly into the BT master socket.
5. You can also try disconnecting any additional devices connected to the phone line such as fax machines, Sky Box, Red Care alarm, Credit Card terminal/Paying Device, telephone extension leads, etc. to avoid any possible interferences coming from these devices.
6.  Swap the router out for a replacement.
7. Noises on the telephone line can cause disconnections in the broadband signal. In order to identify if this is the case please try a Quiet Line Test.
8. Connect only a phone, preferably a corded one, directly to the phone socket and dial 17070. It is recommended that you disconnect all devices from the line, such as ADSL routers, phones, faxes, credit card terminals, Sky Boxes and alarm systems.
   Once prompted, select option 2, and then observe the line for any cracklings, noises, interferences or clicks.
   If you do hear noises on the line, please contact the line provider and inform them that your line is experiencing high noise on the line and this is affecting your broadband signal.
   If you are still experiencing disconnects after carrying out the above checks please contact the support department to carry out further fault diagnostics on the line.

NOTE: It may require an engineer visit to resolve the issue, therefore it is important to carry out the above checks to rule out any equipment faults on site. Any engineer visits that do not find a fault within the provider network are chargeable.

System Preparation

Before configuring the SIP trunk it is required to go through the following checklist and make changes where necessary:

• NAT (when used) created to 3CX
  ( https://www.3cx.com/docs/ports/ )
• Firewall Checker passed
  ( https://www.3cx.com/docs/troubleshooting-firewall-checker/ )
• Firewall SIP ALG checked and if present disabled
  ( https://www.3cx.com/docs/manual/firewall-router-configuration/ )

Further setup information can be found in our Academy:  3CX Academy Basic Course

3CX Version

Some providers gained support and compatibility with 3CX on a specific product version. It is advisable to always run the latest version of 3CX to ensure ongoing compatibility.

Minimum 3CX Version: 3CX Phone System 16.0

Provider Capabilities

Below is a short overview of the provider's capabilities and services and whether they’re supported or not:

• CLNS (Clip No Screening): No
• Catch All Routing: Yes
• Fax in T38: Yes
• CLIR (Number Suppression): Yes
• DTMF via RFC 2833: Yes
• Outbound Codec Order: G711A, G711U, G722, GSM, Opus
• NAT Support: Yes

Configuring the Trunk with 3CX

The general instructions outlining how to add a new SIP Trunk to your 3CX installation can be found  here .

Adding the Trunk

Go to  “SIP Trunks”  and select  “Add SIP Trunk”

• Select Country: UK
• Select Provider in your Country: VoiceHost
• Main trunk number: This will have been provided to you by VoiceHost. You must enter the number in the E164 number format (e.g. +44123456789)
• Press OK

Under the  “General”  tab in the  “Authentication”  section, enter your Authentication ID and Password as well as the registrar address (these will be supplied to you by VoiceHost).

Adding Additional DIDs

To associate all other DIDs/Numbers you have in your VoiceHost account with 3CX, go to the Management Console → SIP Trunks, double-click on your VoiceHost Trunk and go to the  “DIDs”  tab

Here you should already see 1 entry; that is the Main Trunk number you have set. Add all other DIDs/Numbers you have to the list in the E164 number format (e.g. +44123456789) and press OK.

Creating Inbound Rules

Now that you have associated all your DIDs/Numbers with your SIP Trunk in 3CX, you can create Inbound Rules to set where calls will be routed when those numbers are called. Instructions on how to create Inbound Rules can be found  here .

Number Format

General

When configuring VoiceHost SIP Trunks in 3CX, all numbers should be entered in the E.164 number format (e.g. +44123456789), otherwise, call routing will fail.

Outbound Caller ID

VoiceHost trunks do not support Clip No Screening which means you can only present numbers that are associated with your account as Outbound Caller ID.

Outbound Rules

When configuring your Outbound Rules, numbers can be dialled in all valid number formats. More information about how to create Outbound Rules and how they work can be found here

Enabling TLS and SRTP

Under the 'General' tab please update the host to the one shown in the VoiceHost portal. This changes for TLS and SRTP so it will only be changed once enabled.
Under Options, please also upload the linked PEM under the option for the trunks 'TLS Root'.
Ensure SRTP is enabled.
Ensure TLS is set and the transport.
Ensure that host port is set to 'Auto-Detect'

Root Certificate: download here (You will need to rename to .pem)

What is SIP ALG?

SIP ALG stands for Application Layer Gateway and is common in all many commercial routers. Its purpose is to prevent some of the problems caused by router firewalls by inspecting VoIP traffic (packets) and if necessary modifying it.

Many routers have SIP ALG turned on by default.

There are various solutions for SIP clients behind NAT, some of them in the client side (STUN, TURN, ICE), others are in the server side (Proxy RTP as RtpProxy, MediaProxy).

Generally speaking, ALG works typically in the client side LAN router or gateway. In some scenarios, some client-side solutions are not valid, for example, STUN with symmetrical NAT router. If the SIP proxy doesn't provide a server-side NAT solution, then an ALG solution could have a place.

An ALG understands the protocol used by the specific applications that it supports (in this case SIP) and does a protocol packet-inspection of traffic through it. A NAT router with a built-in SIP ALG can re-write information within the SIP messages (SIP headers and SDP body) making signalling and audio traffic between the client behind NAT and the SIP endpoint possible.

How can it affect VoIP?

Even though SIP ALG is intended to assist users who have phones on private IP addresses (Class C 192.168.X.X), in many cases it is implemented poorly and actually causes more problems than it solves. SIP ALG modifies SIP packets in unexpected ways, corrupting them and making them unreadable. This can give you unexpected behaviour, such as phones not registering and incoming calls failing.

Therefore if you are experiencing problems we recommend that you check your router settings and turn SIP ALG off if it is enabled.

• Lack of incoming calls: When a UA is switched on it sends a REGISTER request to the proxy in order to be localisable and receive any incoming calls. This REGISTER is modified by the ALG feature (if not the user wouldn't be reachable by the proxy since it indicated a private IP in REGISTER "Contact" header). Common routers just maintain the UDP "connection" open for a while (30-60 seconds) so after that time the port forwarding is ended and incoming packets are discarded by the router. Many SIP proxies maintain the UDP keepalive by sending OPTIONS or NOTIFY messages to the UA, but they just do it when the UA has been detected as NAT'd during the registration. A SIP ALG router rewrites the REGISTER request to the proxy doesn't detect the NAT and doesn't maintain the keepalive (so incoming calls will be not possible).
• Breaking SIP signalling: Many of the actual common routers with inbuilt SIP ALG modify SIP headers and the SDP body incorrectly, breaking SIP and making communication just impossible. Some of them do a whole replacing by searching a private address in all SIP headers and body and replacing them with the router public mapped address (for example, replacing the private address if it appears in "Call-ID" header, which makes no sense at all). Many SIP ALG routers corrupt the SIP message when writing into it (i.e. missed semi-colon ";" in header parameters). Writing incorrect port values greater than 65536 is also common in many of these routers.
• Disallows server-side solutions: Even if you don't need a client-side NAT solution (your SIP proxy gives you a server NAT solution), if your router has SIP ALG enabled that breaks SIP signalling, it will make communication with your proxy impossible.

I have disabled SIP ALG but I'm still experiencing problems...

If you are still having problems after disabling SIP ALG, please check your firewall configuration.

I can't disable SIP-ALG? How to Circumnavigate any networking vendors broken implementation of SIP ALG

• Enable TLS on SIP Endpoints, VoiceHost supports TLS which masks SIP signalling from the prying eyes of ALG functionality.
• Enable IPv6 on SIP Endpoints. Practically this is not a realistic option for users requiring mobility but for static locations, this does remove the requirement (Must be supported by your ISP). Most Internet providers do not fully support pure IPv6
• Change you Router Obviously a last resort if all else fails.

The 2N IP Verso is a security intercom that is highly scaled thanks to its modular design. The Helios Verso can not only be easily integrated into your current camera and monitoring system but thanks to programmable scripts, the whole system can be used as a security component to protect the building.

Broadband - General configuration settings for the VoiceHost Broadband Network

DNS - Domain Name Servers

Unmanaged SMTP relay for sending Email:

Relay SMTP access is granted only for email sent using VoiceHost internet connections and does not require a username or password, this is an unmanaged service and faults regarding email failure are not supported.

The relay domain addresses are:

• relay.ukdsl.co
• relay.voicehostdsl.com
• relay.newbreedbb.co.uk

Speed Test Servers

Speedtest tools calculate a snapshot of the connection speed to our network AS31472:

• Download - The maximum currently available bandwidth downstream
• Upload - The maximum currently available bandwidth upstream
• Ping - <150 ms is preferred for QoS
• Jitter - <30 ms is preferred for QoS

You should ensure that no other devices are using the connection during the test and you are connected directly into the primary router.

• speedtest.ukdsl.co
• speedtest.voicehostdsl.co.uk
• speedtest.voicehost.co.uk

Reverse DNS and SPF:

Reverse DNS is IP address to domain name mapping - the opposite of forward (normal) DNS which maps domain names to IP addresses. Please contact support if you require reverse DNS as you may require this in order to send emails and have them accepted by other networks.

Sender Policy Framework (SPF) is an email validation system designed to prevent email spam by detecting email spoofing, a common vulnerability, by verifying sender IP addresses. If your domain does not have an SPF record, you will also need to add this as some recipient domains may reject messages from your users because they cannot validate that the messages come from an authorised mail server.

Additional IPv4 addressing and IPv6:

Subject to approval based on RIPE guidelines and RFC2050 (Section 2.1), VoiceHost can offer additional static IPv4 subnets to its broadband customers on all products.
Please contact support for further details.

IPv6 is disabled by default but can be enable IPv6 via your account control panel.

Our service is 100% compatible with Asterisk using either standard SIP registration or IP authentication where SIP trunks are configured as such. Asterisk is the base software behind many open-source PBX distributions, including FreePBX, Trixbox and Elastix, and is also the enabler behind many other ITSPs and commercial PABX manufacturers.

Please Note: Chan SIP is now deprecated in favor of PJSIP
https://www.asterisk.org/asterisk-21-module-removal-chan_sip/

Suitable for Asterisk versions >13, you should have the following in your pjsip.conf file:

This configuration is for authentication based on a registration with username and password. The protocol can be changed as desired. TLS and SRTP will require additional configuration.

[transport-udp] ; Configures res_pjsip transport layer interaction.
type = transport
protocol = udp
bind = 0.0.0.0

[voicehost]  ; Contains information about an outbound SIP registration
type=registration
transport=transport-udp
outbound_auth=voicehost_auth
server_uri=sip:[sip-trunk-username]@[hostname]:5060
client_uri=sip:[hostname]:5060
retry_interval=20
expiration=3600

[voicehost_auth] ; Stores inbound or outbound authentication credentials for use by trunks, endpoints, registrations.
type=auth
password=[sip-trunk-password]
username=[sip-trunk-username]

[voicehost_aor] ; Stores contact information for use by endpoints.
type=aor
contact=sip:[sip-trunk-username]@[hostname]

[voicehost] ; Configures core SIP functionality related to SIP endpoints.
type=endpoint
context=voicehost-in
dtmf_mode=rfc4733
disallow=all
allow=alaw
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
timers=yes
from_user=[sip-trunk-username]
from_domain=[domain]
language=en
outbound_auth=voicehost_auth
aors=voicehost_aor

[voicehost] ; Maps a host directly to an endpoint
type=identify
endpoint=voicehost
match=[hostname]