SIP ALG and why it should be disabled on most routers

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.

How do I turn off SIP ALG?
Most home/residential routers have a web interface. Typically this is 192.168.1.1 but you just check your default gateway by typing ipconfig in Windows command prompt or ifconfig on Linux systems from any connected device on the same LAN.
If your router does not have a web interface you will most likely need a Telnet client to login.
If you don't have a telnet client installed we recommend Smartty (smartty.sysprogs.com)
Connect in telnet to the IPv4 address of your gateway and hit enter again.
Asus Routers

Disable the option SIP Passthrough under Advanced Settings / WAN -> NAT Passthrough.
If your router doesn't have this option SIP ALG may be disabled via Telnet.

nvram get nf_sip 
(It should return a "1")

nvram set nf_sip=0 
nvram commit
Reboot

AVM Fritz!Box
SIP ALG cannot be disabled. (See above on how to get around this)
Barracuda Firewalls
Go to Firewall > Firewall Rules > Custom FirewallAccess Rules
Click the "Disabled" check box next to any rules named LAN-2-INTERNET-SIP and INTERNET-2-LAN-SIP
This disables SIP ALG.
Billion
Navigate to the web interface
-> Select Configuration
-> Select NAT
-> Select ALG
-> Disable SIP ALG
BT (Homehubs)
SIP ALG cannot be disabled in the settings of BT HomeHubs but can be disabled with BT Business Hub versions 3 and higher.
Cisco RV Range
(RV082, RV016, RV042, RV042G, RV325)
-> Go to System Summary and ensure that the firmware is up to date (1.1.1.06 or later).
-> f needed, update firmware by going to System Management > Firmware Upgrade.
-> Go to Firewall > General.
-> Ensure that Firewall and Remote Management are enabled (checked).
-> Ensure that the following are disabled (unchecked):
-> SPI (Stateful Packet Inspection)
-> DoS (Denial of Service)
-> Block WAN Request
-> SIP ALG
-> Click Save.
-> Browse to IPADDRESS/f_general_hidden.htm.
-> Set UDP Timeout to 300 seconds.
-> Go to Firewall > Access Rules.
-> Whitelist VoiceHost IP ranges
Save all changes.
D-Link
In 'Advanced' settings --> 'Application Level Gateway (ALG) Configuration' un-tick the 'SIP' option.
DD-WRT
No ALG function available - Consider using a public STUN server
DrayTek

DrayTek Vigor 2760 devices, the option can be found in the regular interface at Network -> NAT -> ALG.

If your device does not have a web interface then you'll need a telnet client.

You will be prompted to provide a username and/or password. These are the same credentials used to access the router's web interface.

Afterwards, type in these commands:

sys sip_alg 0
sys commit

On Draytek Vigor2750 and Vigor2130 please use these commands instead:

kmodule_ctl nf_nat_sip disable
kmodule_ctl nf_conntrack_sip disable

EE

Huawei E5330

Navigate to the web interface
Click Settings.
Enter the required username and password, then click Log In. 
Note: The default username and password is admin.
Click the Security dropdown.
Click SIP ALG Settings.
Untick the Enable SIP ALG box.
Click Apply.

Fortinet

Fortigate:

Disabling the SIP ALG in a VoIP profile
SIP is enabled by default in a VoIP profile. If you are just using the VoIP profile for SCCP you can use the following command to disable SIP in the VoIP profile.

config voip profile
edit VoIP_Pro_2
config sip
set status disable
end

Huawei

The SIP ALG setting is usually found in the Security menu.

  1. Vodafone / Huawei (HHG2500)
  2. TalkTalk / Huawei (HG633) 
  3. EE / Huawei (E5330)
Juniper

Type the following into the CLI
To check if currently enabled or disabled run show security alg status | match sip
To disable run:

configure
set security alg sip disable
commit

Linksys:
Check for a SIP ALG option in the Administration tab under 'Advanced'.
You should also disable the SPI Firewall option.
Mikrotik
Disable SIP Helper.
Netgear

Look for a 'SIP ALG' checkbox in 'WAN' settings.

Under 'NAT Filtering' uncheck the option 'SIP ALG'
Port Scan and DoS Protection should also be disabled.
Disable STUN in VoIP phone's settings.

openwrt
No ALG feature - Consider using a public STUN server
PfSense
https://www.voicehost.co.uk/help/pfsense-voip-configuration
SonicWALL Firewall
Under the VoIP tab, the option 'Enable Consistent NAT' should be enabled and 'Enable SIP Transformations' unchecked.
Detailed instructions can be found here: https://www.voicehost.co.uk/help/sonicwall-configuration
Speedtouch

To disable SIP ALG you need to telnet into your Speedtouch router and type the following:

-> connection unbind application=SIP port=5060
-> saveall

TalkTalk

2017/18 See Huawei (HG633)

  1. Navigate to the web interface
  2. Select 'Port Forwarding' from the menu
  3. Uncheck SIP-ALG from the ALG section at the bottom of the page.
Technicolor / Thompson
TG588 TG589 TG582 DWA0120
Open Command Prompt – “Start” → “Run” → type “cmd” and press “Enter”.
In Command Prompt, type “telnet 192.168.1.254” and press enter. 192.168.1.254 is the default IP address of the router. If you are running on Windows 7/8/8.1/10, you might need to install the telnet client from “Control Panel” → “Programs and Features” → “Turn Windows features on and off”.
The default username is “Administrator”, and there is no default password, leave blank.
Type “connection unbind application=SIP port=5060” and press “Enter”.
Type “ saveall ” and press “Enter”.
Type “exit” and press “Enter” to exit the telnet session.
Tomato
Depending on the version of Tomato, SIP ALG can be found under Advanced then Conntrack/Netfilter in the Tracking/NAT Helpers section. If you find SIP checked then SIP ALG is enabled. Uncheck it to disable it.
TP-Link
Navigate to your routers web interface.
The default username is admin and the default password is admin.
On the left, click on Advanced Setup and then click on NAT and then click on ALG.
Uncheck the box by SIP Enabled. (Some TP firmware shows this as SIP Transformations which is the same thing).
Click Save/Apply.
UBEE Gateways
Go to Advanced > Options.
Disable (uncheck) SIP.
Disable (uncheck) RTSP.
Click Apply.
Ubiquiti

Use the configuration tree if supported: system -> conntrack -> modules -> sip -> disable

Alternatively, you can SSH into the device and run the following commands:

configure
set system conntrack modules sip disable
commit
save
exit

Virgin SuperHub
SIP ALG cannot be disabled in the settings of SuperHubs.
Please see our workarounds at the top of the page.
Vodafone
2018 Onwards - See Huawei (HHG2500)
Vyatta / Brocade:

Type the following into the CLI

configure
set system conntrack modules sip disable
commit
save
exit

Watchguard Firewall
Detailed instructions can be found here: https://www.voicehost.co.uk/help/watchguard-firewall-sip-configuration
ZyXEL

Under Network or Advanced -> ALG un-tick the options Enable SIP ALG and Enable SIP Transformations.
Telnet commands must be used to disable SIP ALG with some other Zyxel routers.

  1. Telnet into the router.
  2. Select menu items 24 then 8.
  3. To display the current SIP ALG status run the following command:
  4. ip nat service sip active
  5. To turn off SIP ALG:
  6. ip nat service sip active 0
ZyXEL (ZyWALL USG Routers)
Go to Settings > Configuration > Network > ALG.
Disable SIP ALG.
Turn ON Enable SIP Transformations.
Turn OFF Enable Configure SIP Inactivity Timeout.

2n Helios Verso IP Door Entry Configuration for SIP

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 Network General Settings

Broadband - General configuration settings for the VoiceHost Broadband Network
 ADSL2+ SoADSLFTTC SoGEA & G.FastFTTP
Line typeAnnex A + M: Analogue/Raw Copper (PSTN)VDSL2: Analogue/Raw Copper (PSTN)Full Fibre
EncapsulationPPPoAPPPoEPPPoE
MultiplexingVC-Mux
IPv4Static x 1 included (see below if >1 required)
IPv6/64 Enabled by default
ATMVPI: 0
VCI: 38
N/AN/A
VLANN/A101 for routers with built-in VDSL2 modemsN/A
MTU1492
AuthenticationVOICEHOST PROVIDED
DNS - Domain Name Servers
 NameIPv4 addressIPv6 address
PrimaryVoiceHost (Private)xx.xxx.xx.xxxxxxx:xx:xxx:xxxx
SecondaryVoiceHost (Private)xx.xxx.xx.xxxxxxx:xx:xxx:xxxx
PrimaryCloudflare (Public)1.1.1.12606:4700:4700::1111
SecondaryCloudflare (Public)1.0.0.12606:4700:4700::1001
PrimaryGoogle DNS (Public)8.8.8.82001:4860:4860::8888
SecondaryGoogle DNS (Public)8.8.4.42001:4860:4860::8844
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.

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.

Asterisk PBX SIP Trunk Configuration

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]

Number Porting - Complete Handbook

  • One Touch Switching is currently set to apply to all 'Residential' Number ports from September 2024.

    Learn more here One Touch Switching | VoiceHost

  • Preface

    VoiceHost will always endeavor to port your inbound telephone numbers to the VoiceHost VoIP service in a timely fashion. However, we cannot provide any guarantees that numbers can port successfully or at all, that numbers can port within a certain time-frame (including but not limited to the minimum industry lead time for the import type), or that there will not be problems porting the number(s) away from your current provider.

    Please note that whilst UK number portability is regulated by the UK Telecommunications Regulator (Ofcom) in line with EU regulations (http://stakeholders.ofcom.org.uk/telecoms/numbering/guidance-tele-no/number-portability-info/), UK geographic and non-geographic number porting is presently a best-endeavours process with no guarantees, and all lead times quoted in this article are minimum industry standards.

    The accepted practice is for service providers who have been allocated numbers from Ofcom to have completed the technical service establishment and signed a porting agreement with at least 1 network operator to be able to export their allocated numbers, however this is not a mandatory requirement when taking allocations of telephone numbers from the UK telecommunications regulator (presently Ofcom).

    Reseller or Wholesale porting from one service provider to another service provider is not supported, as number portability exists for subscribers/end-users wishing to change provider only. This applies to any imports to VoiceHost and exports from VoiceHost. See here for more information: http://stakeholders.ofcom.org.uk/binaries/telecoms/numbering/letter101212.pdf

    Any number port orders received to import or export numbers via VoiceHost which are suspected of being reseller ports will be rejected, however, changes in service type (e.g. ISDN to Hosted PBX) may be permitted on a case by case basis.

    Please note that if the number(s) being imported are active within Directory Management Solutions (i.e. the BT Phonebook or Directory Enquiries), you may be notified of charges without prior notice when a reprint occurs.
    Any unwanted directory services should be cancelled as soon as possible with the current service provider to avoid unwanted costs.

    Number porting may incur charges from any intermediary parties (including the current provider and/or your new provider) facilitating your port orders, please be aware of this before committing to submit a port order. Additionally, please be advised that amending the port date may not be possible depending on the type of circuit or number due to port.

  • Number porting is a change in the CP (Communications Provider) or Current Network Operator (CNO) of the inbound routing of a telephone number.

    UK number porting is made technically possible by onward routing, where the number(s) to be ported are prefixed by the rangeholder or host network operator for the rangeholder with a number porting prefix for the gaining network operator. When a call is placed to the ported number after the porting prefix has been applied the call is then routed directly to the gaining network operator via the designated points of interconnect agreed under the service establishment between the new network operator and the host network or rangeholder.

    As such number porting does not change the Ofcom-allocated RH (Range Holder) of a number, as the calls will usually always route through the RH systems or the RH's host network operator.

    VoiceHost use BTIPEX (BT IP Exchange) for the vast majority of porting requests for the VoiceHost platform. IPEX has arguably the widest SE (Service Establishment) with range holders and host networks, enabling VoiceHost to facilitate the porting of most UK landline and non-geographic telephone numbers, particularly from the larger tier 1 network operators.

    IPEX cannot import a number from a RH or host network that they do not have service establishment (SE) with. In any case, where IPEX do not have SE with a range holder or host network, they will attempt to complete SE with them and sign a porting agreement for the portability of those numbers. The SE process can take a minimum of 55 working days for geographic numbers, however, any errors or obstructions found on the systems they are attempting to service establish will lengthen this timeframe accordingly, in addition, a porting agreement must be signed before porting orders may be exchanged.

    For a port request to be accepted by the CNO (Current Network Operator) / Losing CP (LCP) or RH, all of the information on the documents forwarded to the LCP/RH must match what is on file for the telephone number(s) to be ported. It is usually best to contact the current provider and ask them what is on file for the postcode and additional information against the numbers to be ported when filling out the porting document, at this point you may also inform them of your intention to port the number away from them, so that the port request is not obstructed.

    VoiceHost can attempt to facilitate direct porting agreements and service establishments with network operators that fall out of scope with the BT standard interconnect agreement. Our porting team will be able to advise you should this situation arise.

  • When a number ports from a fixed telephone line, the original line is usually ceased. This means that any and all additional services directly provided on the telephone line will also be ceased, e.g broadband or voicemail. Number port prefixing on analogue and digital line (ISDN) import activation's from BT as the range holder usually happens at the exchange level.

    When a number is ported to our service, the original RH changes the prefix on the number, so that it routes out to IPEX. It is imported onto the IPEX platform and programmed in their core routing engine, which then routes all calls into that number onwards to the VoiceHost platform.

  • In order for VoiceHost to port your number onto the VoiceHost VoIP platform, we need, for all numbers:

    1. Proof of ownership of the number (ideally in the form of a copy of the latest bill from the current CP)
    2. Authorisation from the subscriber to port the number (in the form of a GNP Customer Letter of Authority signed by the subscriber)
    3. Relevant telephone number details (in the form of completed porting documents)
    4. Range holder CUPID (find on www.telecom-tarrifs.co.uk AND check against Ofcom S1 allocation form)
    5. LCP CUPID (may also be Range holder, otherwise is the company billing you for the number)

    We are unable to progress any ports without this information.

  • There are a number of factors that can delay port orders.

    1. Redcare / security tag exists on the line. You must cancel Redcare or transfer the service to another circuit number before that number can be ported.
    2. The Installation address or postcode is incorrect or does not match the current network operator's data against the number. We need to know the current postcode of the number(s) for a port order to validate correctly. See Pre-Order Validation PoV
    3. LCP/RH failure to provide a response. You should always inform the current provider of an intention to port away so that a port order is not held up.
    4. No SE (Service Establishment) with LCP/RH. Unfortunately, you as the subscriber can do nothing to affect this.
    5. Incorrectly labelled (single line as multiline etc). You should always confirm the line type with the LCP/RH.
    6. Incorrect telephone details (main billing number, DDI range etc). You should always confirm with the LCP/RH all attached phone numbers, main billing number etc).
  • VoiceHost is able to request the line information (associated address) held by a CP/NO that is UK registered on the Ofcom scheme. This mitigates the trial/error of porting numbers with unknown details.

    The Ofcom register is available here: App_J3-Consolidated_Contacts_Register-PoV_Process-v8.4.pdf

  • The number porting process is always GCP (Gaining Communications Provider) led and exists exclusively for the end-user/subscriber. This means that to export numbers, the subscriber follows the import process with another provider. The LCP simply validates the data submitted accordingly. A Customer Letter of Authority (CLoA) is still required with the new provider, and this is checked prior to exports being progressed. Porting guidelines are industry-wide so the process will usually be similar to another CP.

    It is always expeditious to provide VoiceHost with a copy of the CLoA if your porting timescale is short as delays in receiving this from the GCP will cause the port to time-out as it cannot be validated.

    Any number that has been ported into to BTIPEX can usually be ported out again, i.e where we are not the range holder. Numbers imported to VoiceHost can usually be exported as they were initially imported, or split accordingly, however, if numbers to be ported were a range of numbers was imported then that entire range must be exported in order to keep the desired number(s).

    Geographic numbers where VoiceHost is the range holder may be exported away from VoiceHost but there are some caveats to the IPEX platform to be aware of, both of which should hopefully be negated in the future:

    1. Once number ranges allocated by Ofcom to range holders that built on IPEX have been exported away from IPEX, they cannot yet return to IPEX, importantly this includes any other IPEX Communications Provider (e.g. if a number exported to the BT PSTN wants to port somewhere else this cannot be fulfilled at present).
    2. Number ranges allocated by Ofcom to VoiceHost which are built on IPEX can presently only be prefixed away from IPEX once. This means that the porting prefix cannot be updated or changed for subsequent ports to other network operators, thereby making the initial export of the VoiceHost number permanent until advised accordingly by IPEX as above
    3. Non-Geographic number ranges (beginning 03, 05, 08 or 09) allocated by Ofcom to VoiceHost and built on IPEX cannot currently be exported and export requests of this nature are currently out of technical scope.

    Numbers that are not in service cannot be exported. The number(s) to be ported must be live and be working in order to be ported. Any number ports requested for numbers that fail when calling will be rejected.

    Reseller / Wholesale bulk porting of subscribers' numbers into or out of VoiceHost is not supported as number portability exists for subscribers (i.e. end-users) wishing to change provider only. Any reseller ports requested will be rejected. The above process is mandatory in all circumstances. See here for more information:http://stakeholders.ofcom.org.uk/binaries/telecoms/numbering/letter101212.pdf

    The Export Process:
    1. Submit your GNP request to the GNP.
    2. VoiceHost will be notified by BT Openreach of the export request.
    3. VoiceHost will validate the request and notify the subscriber/reseller for legitimacy.
    4. Legitimate requests are then cleared for export subject to lead times.
    • Single Line Geographic - A single telephone number beginning 01 or 02, that is not part of a DDI range, is not the main billing number for a DDI range, and is not part of a multi-line.
    • Multi Line Geographic - Multiple lines on one or more telephone numbers, including WLR analogue Multi-Line and single-number ISDN.
    • Simple DDI - Multiple digital lines (ISDN/T1/E1/SS7) on one or more telephone numbers, consisting of a main billing number. It can contain a whole block of DDI's (minimum 10, multiple of 10) and/or have SNDDIs on the circuit.
    • Complex DDI - Multiple digital lines (ISDN/T1/E1/SS7), consisting of part of a block of DDI's, and a main billing number. Note: All DDI's attached to the circuit must be included on porting document, and intention given as to which numbers to port. Any numbers not ported will be handed back to the RH.
    • Single Line Non Geographic - A single telephone number that is non geographic, is not part of a DDI range, is not the main billing number for a DDI range, and is not part of a multi-line or Feature Line.
    • Multi Line Non Geographic - Multiple non geographic telephone numbers, consisting of an original and whole block of DDI's (minimum 10), and a main billing number.
    • International - Telephone numbers from countries outside the UK (+44).
    • Single Line Geographic - Porting Form, Letter of Authority, Copy of Latest Bill
    • Multi Line Geographic - Porting Form, Letter of Authority, Copy of Latest Bill
    • Simple & Complex DDI - Porting Form, Letter of Authority, Copy of Latest Bill
    • Non Geographic - Porting of Non-Geographic Numbers Notice, Copy of Latest Bill
    • Multi Line Non Geographic - Porting of Non-Geographic Numbers Notice, Copy of Latest Bill
    • International - Requirements vary and are country specific
  • NOTE: THESE ARE THE MINIMUM LEAD TIMES:

    • Single Line Geographic Import - 4 to 13 working days
    • Multi Line Geographic Import - 7 to 25 working days
    • Simple DDI - 10 to 23 working days
    • Complex DDI - 22 to 25 working days
    • Non-Geographic Import  - 15+ working days
    • International (non-uk)  - Varies between countries
    1. Customer submits to VoiceHost: Porting form (Customer Letter of Authority / CLoA), copy of the latest bill.
    2. VoiceHost submits to IPEX using online portal with CRD (Customer Required Date).
    3. IPEX complete an automated look up on their systems, verifying line type and range holder.
    4. If details match records with LCP/RH, the order is confirmed.
    5. IPEX receive response from LCP/RH confirming acceptance on DD/MM/YYYY@HH:MM
    6. VoiceHost notifies the customer that number has been accepted to port.
    7. At least 24 hours prior to port, VoiceHost will add the porting number to the customer's account ready to receive traffic from BT IP Exchange.
    8. On date and time of port, IP Exchange automatically loads number onto ENUM and direct calls from that number to VoiceHost so they are ready to catch traffic from RH.
    9. RH automatically applies porting prefix so calls are routed to IP Exchange
    10. Confirmation that number has ported is sent by IP Exchange to us.
    11. VoiceHost test-call after receiving completed port notification to make sure calls are routing correctly. If not routing correctly, escalate to BT immediately.
    1. Customer submits to VoiceHost: Porting form, Letter of Authority, copy of the latest bill.
    2. VoiceHost submits a request to IPEX using online portal.
    3. IPEX then apply this information on a NPOR form manually.
    4. NPOR gets sent to BT Openreach, who send it off to the LCP/RH.
    5. LCP/RH then check the details on the NPOR and respond back to Openreach accordingly, if rejected providing the reason why.
    6. Openreach then sends the response to IPEX.
    7. If accepted, a confirmation response is sent to VoiceHost confirming date and time the porting process will begin
    8. At least 24 hours prior to the port, VoiceHost add numbers into customer's account ready to receive traffic.
    9. On the date of port, VoiceHost manually configures the number port on IP Exchange portal after the Port Configuration Window Start(s). This loads it into ENUM.
    10. On date and time of port, VoiceHost call IP Exchange, give reference number(s) and/or MBN, and ask them to progress the port and perform a test-call to make sure ENUM load is correct.
    11. Openreach then progresses the port, where the RH applies the porting prefix, and inbound traffic on PSTN should then route through to VoiceHost.
    12. If there is downtime of 15 minutes or more VoiceHost ring IP Exchange requesting they escalate due to the downtime.
    1. The subscriber has to fill in a separate Non-Geographic Number Porting Notice - this form must be typed, printed on customer-headed paper, signed and dated and sent back to us with a copy of a bill from LCP. There must be an account number the subscriber has with the current provider where available, the address of the Losing Communications Provider and contact email address and telephone number, and the Gaining Communications Provider must be VoiceHost Ltd and our address.
    2. If resellers are involved in the transaction the porting lead-time stretches - for non-geographic porting all parties have to be informed of the port request. The minimum lead time for non-geographic number porting is 15 working days.
    3. Once all the correct subscriber paperwork is received, VoiceHost sends the paperwork to IPEX, who then process the port request on VoiceHost's behalf via BT Inbound Services. Inbound Services then send a port request to the current communications provider (this could be a reseller), or reject the port request because of incorrect paperwork or inability to port.
    4. BT, upon acknowledgement of the porting request to the end-users provider, then approach the RH with a port order.
    5. Once the port order has been accepted, a confirmed date for the port to take place will be confirmed to IPEX, and if appropriate a fixed time or time range.
    6. At least 24 hours prior to the port taking place, VoiceHost will add the number(s) required into the subscriber's VoiceHost account ready to receive inbound calls,
    7. On the date and time of the port, IP Exchange builds the number(s) on ENUM, then contact RH to initiate porting prefix.
    8. The number should then have been ported, VoiceHost does test calls to confirm number routes to us correctly. If there is downtime of 15 minutes or more VoiceHost ring IP Exchange requesting they escalate due to the downtime.
  • POR (Port Override Requests) exist to force through a number porting request when the LCP is deliberately blocking or being obstructive towards the end users right to retain the telephone number.

    POR (Port Override Requests) can be placed on any UK originating line type be it Geographic, Non-Geographic, Residential or Business, Single or Multiline

    The decision to initiate the POR process must be a joint decision made by the End User’s Retailer (i.e. the Gaining Party-GP) and the Gaining Wholesaler (i.e. the Gaining CP-GCP), on the basis that both parties will have first hand knowledge of the port order in question and the obstacles preventing it’s progress.

    POR (Port Override Requests) have a 6 stage process

    • Stage 1 – POR alert
    • Stage 2 – POR trigger
    • Stage 3 – POR Evidence Pack
    • Stage 4 - POR Pack submitted for EAP approval
    • Stage 5 – POR Executive Authorisation Panel (EAP)
    • Stage 6 – POR execution & closure
  • Most common number Port rejection reasons can be avoided by completing a PoV (See above)

    Here are some of the common rejection codes and their reasons and explanations

    • Code 2 = CUPID missing or invalid
    • Code 6 = Porting telephone number missing or invalid
    • Code 15 = Other (must detail reason for rejection separately)
    • Code 25 = Single Line Order but porting telephone number is Multi Line
    • Code 26 = Multi Line Order but porting telephone number is Single Line
    • Code 30 = Telephone Number Already Ported
    • Code 31 = Customer has no service with LCP
    • Code 32 = Porting request out of current scope for Number Portability
    • Code 41 = LCP Installation Postcode invalid
    • Code 44 = Telephone number(s) associated with MBN missing or invalid
    • Code 52 = Invalid Range Holder (i.e. telephone number does not belong to Range Holder)
  • In the context of this document, the following acronyms are used:

    • IPEX = British Telecom IP Exchange
    • IPEX = IP Exchange
    • CUPID = Communications Unique Provider ID
    • CP = Communications Provider
    • LCP = Losing Communications Provider
    • CNO = Current Network Operator
    • GNP = Geographic Number Porting
    • CRD = Customer Required Date
    • RH = Range holder
    • SE = Service Establishment
    • DDI = Direct Dial In
    • ISDN = Integrated Services Digital Network (ISDN2e or BRI, ISDN30e or PRI)
    • PSTN = Public Switched Telephone Network
    • SS7 = Switched Signaling 7 – a set of protocols typically on a fixed E1 circuit defining call routing and signaling
    • NGN = Non-Geographic Number
    • ENUM = E.164 Number Mapping - IPEX's call routing engine which directs incoming calls on telephone numbers to the allocated carriers/destinations

     

CDR Access via FTP - How it works

CDRs and Services files are available to our wholesale customers via our FTP platform.

  • Daily CDR files (A folder containing records of chargeable calls made the previous calendar day based on GMT)
  • Monthly CDR files (A folder containing records of chargeable calls made the previous calendar month based on GMT)
  • Monthly Service Files (A folder containing records of chargeable services consumed either in-advance or arrears)

CDR and Service files are supplied as a comma-separated values file (.csv).

Accessing the FTP Platform

File Transfer Protocol Secure — aka FTP over TLS/SSL or FTPs — is a protocol for transferring files using Secure Sockets Layer (SSL) to secure the commands and data that are being transferred between the client and the server. We only support FTP connections over TLS (FTPS).

PLEASE NOTE: You will only be able to connect for the first time after the first billing cycle has completed successfully

  1. Download an FTP client, this will allow you to connect to our FTP platform.
    If you don't have an FTP client then we recommend Filezilla which can be downloaded here and is free: https://filezilla-project.org
  2. Create a new connection and populate with the basic details as shown below. Your username, password and host can be found in the re-seller portal under Accounts.
  3. You will now have read-only access to CDRs inline with VoiceHost data-retention policy https://www.voicehost.co.uk/privacy-policy

SSH connections will be available in the future.

Compatible Router List & General Router Configuration

General Router Setup and Configuration for the usage with the VoiceHost network

General Overview: Routers are typically the source of network issues related to the implementation of both our SIP trunks and our Cloud Platform. To ensure a network remains reliable, we recommend using the Technicolor TG582n TG589vn or TG588 for small office setups (<5 phones) and the Mikrotik range of routers (RouterOS) for deployments >10 phones or office setups requiring dual-WAN capabilities.

NOTE: The TG582n may not be suitable for PBX deployment due to difficulties port-forwarding to the PBX.

Most routers do not prioritise VoIP traffic (the Technicolor routers do this properly). Further to this, some routers actively disrupt the traffic coming through them, which further inhibits the phones' abilities to correctly route VoIP traffic. In addition, without prioritization of VoIP traffic on transmission, other devices on the network which use the available bandwidth may cause a drop in call quality. The settings below should be taken as a guide to configuring 3rd party routers. However, we cannot guarantee the success of these 3rd party routers, even when configured to have the settings below. If problems persist after these changes, we advise purchasing a recommended router.

"Free" routers provided by other ISPs may be either locked down to only their internet service or still accessible by them (meaning they can see everything you use it for). It also means that they can update it at any time, thereby resetting the main settings used to process VoIP packets. It is highly recommended to change it, even if the model number is the same.

General Router and Firewall Settings:
  • Disable SIP ALG
  • Disable SPI Firewall
  • Enable SIP Transformations (specific to Sonicwall)
  • Disable Consistent NAT (Specific to Sonicwall)
  • White-list our IPv4 addresses (contact support for info)
  • Update Firmware to latest recommended version based upon hardware
  • Do NOT open port 5060 (or the RTP ports) to any internet-based traffic (i.e. WAN links) unless you are explicitly filtering on the firewall or PBX based upon the public IP addresses of the platform. This is how SIP scanners identify systems to attempt to compromise them!

Router Compatibility

Compatible Routers

(Recommended and Supported)

Date Tested
Compatible Routers

(Limited Support - Firmware update required / SIP-ALG MUST BE DISABLED/Not Supported)

Date Tested
Incompatible Routers

(Broken for SIP usage on tested firmware)

Date Tested
Technicolor TG582n and TG589n (IPv6 compliant)2013/14Zyxel Range (AMG1302 Tested)2017Netgear DGN1000 (aka N150 ADSL2+) - INCOMING CALL FUNCTIONALITY BROKEN2016
Technicolor TG588v (IPv6 compliant)2017Draytek Vigor Series (Update Firmware & uncheck 'accept large fragmented UDP packets' within router settings)2014Netgear WNR1000 (aka N150 cable) - INCOMING CALL FUNCTIONALITY BROKEN2016
Mikrotik Routers (RouterOS based devices)2017PfSense (see additional help article)2015Sky Hub2018
Cisco RV042(G) / RV082 / RV016 / RV110W / RV180W / RV320 (All IPv6 compliant)2015WatchGuard (see additional help article)2015  
Cisco Integrated Services Routers (1900/2900/3900 series)2015Routers with VoIP DD-WRT/Tomato firmware2013  
  Virgin Media SuperHub  (stealth-update of the firmware by the ISP can break some settings)2015  
  BT HomeHub or BusinessHub (stealth-update of the firmware by the ISP can break some settings)2015  
  O2/Be Routers (stealth-update of the firmware by the ISP can break some settings)2015  
  Netgear DG834(g) | DGN2000 | DGN3500 | WNR20002016  
  TP-Link2014  
  D-Link2014  
  TalkTalk (D-link) (stealth-update of the firmware by the ISP can break some settings)2014  
  FritzBox2014  
  Speedtouch2014  
  Billion2014  
  ASUS (DSL-N16 & ASUS DSL-AC55U Tested) - Disable SIP-ALG by enabling SIP PASSTHROUGH under WAN settings)2016  
  Vyatta & Brocade (Disable SIP-ALG)2016  
  Huawei HG633 (TalkTalk Super Router) - (Disable SIP-ALG)2017  
  Sky Hub (SIP-ALG cannot be disabled so TLS must be forced for SIP Services.2018