This depends on the protocols being used. All of the rules mentioned below should be stateful, and allow response packets in or out of the firewall:
UDP Port 5060 (inbound to PABX)
UDP Ports 2000-6000 (outbound from PABX, depending on devices used)
UDP Ports 10000-20000 (in- and outbound from PABX)
UDP Ports 4000-4999 (in- and outbound from PABX for T.38)
Note: Firewalls that use NAT will often cause additional problems with the SIP protocol.
no ip firewall alg sip
no inspect sip
no fixup protocol sip 5060
no fixup protocol sip udp 5060
no ip nat service sip tcp port 5060
no ip nat service sip udp port 5060
sip no fixup
We strongly recommend that you use TLS-SIP/SRTP, rather than attempting to pass unsecured SIP in the clear across the Internet.
We recommend this for several reasons:
The steps for setting this up (along with secure provisioning) are detailed in the KB article Setting up secure provisioning.
You could also use a Virtual Private Network (VPN) setup to securely tunnel SIP traffic back to an internal PABX. Traditionally this has been the recommended approach for deploying phones remotely. It is still useful in some scenarios (e.g. where an older phone does not support TLS-SIP) but comes with increased complexity.
IMPORTANT: There should only ever be one DHCP server on a network. Using a Draytek/Netgear or similar gateway router is usually OK, but if the device loses power (eg. during a power cut), then it has no storage, and will forget all of the leases. This then introduces the risk of duplicate IP addresses and a broken network. Therefore, if there is a server available, it is far better to use that for DHCP.
The PABX can offer a basic DHCP service, and that is what we recommend.
As documented elsewhere the DHCP server should be configured to supply Option 66 for phone auto-provisioning. The PABX DHCP server has this enabled by default.
In small environments without a DNS server, the ADSL gateway will generally serve DNS directly from the Internet, and as such, it cannot have any knowledge of internal devices, including the PABX. Working DNS is required by almost all VoIP handsets.
The PABX can be used to serve its own DNS information, and act as a forwarder. To do this, configure the PABX to use itself (127.0.0.1) as a primary DNS, and the ADSL gateway as its secondary DNS. Using DHCP, point all other devices at the PABX for their DNS services. The PABX will serve its own internal name directly, and pass all other requests on to the gateway.
DO NOT be tempted to use the ADSL gateway’s DNS as well as the PABX DNS, as they will respond with conflicting results for any non-Internet queries.
Having a separate ADSL service for VoIP is a good idea, but requires an understanding of IP routing to implement well. There are 2 common scenarios:
The VoIP connection is owned/managed by the client, and is a “normal” business ADSL connection - In this case, set the default gateway of the PABX to point at this VoIP router, leave all other devices pointing at the data connection.
The VoIP connection is managed by an ITSP and is heavily QoS’ed, and can only be used for VoIP In this case set ALL default gateways to point at the Data router, and then on the data router, add a static route so that all packets addressed to the ITSP’s IP address(es) are forwarded to the VoIP router. The second option may appear to put double traffic on the LAN, but in fact IP networking will optimise this out.
The following services cannot be used to remote administer the VoIPCortex PABX, among others:
Use of these services would mean sending a copy of our X.509 private key to the remote server in order to get full SSH access to the PABX, which is not possible.
SSH via these services is also unusable for efficient diagnostics with the PABX. This is because, for example, keystrokes and command key combinations that are needed are not possible and often the screen will scale and become unreadable.
We would recommend use of Remote Support Tunnel (RST) feature on the PABX. RST only requires an outbound port 122/tcp connection from the PABX, and does not need any inbound permissions. It is also only used if enabled by the customer on the PABX web UI. This session times out after 2 hours and is more secure than the above mentioned methods.
This is most often cause by an unclean shutdown of the system caused by a powercut. Please try gracefully shutting down and restarting the unit using the switch on the unit.
If the problem persists, it is possible that the unclean shutdown has caused a database issue. Make a note of the code number reported on the login screen and call support.
It is also possible to restart by logging into the console as the ‘pabx’ user, accessing the ‘root’ prompt and entering the command ‘reboot’.
This is supplemental information about OCM/Keevio enhancements:
This is a menu option on OCM, and will attempt to cause OCM dialled calls to be auto-answered hands-free on your handset so that the onward call can proceed immediately.
Supported by:
Exceptions:
This is a menu option on OCM, and will allow the PABX to attempt to put more than one call onto a phone line. If this feature is off, and a call already exists on a line, attempts to use that line will always fail.
Supported by:
Exceptions:
Allows a call to be placed on hold or retrieved using OCM.
Supported by:
Gigaset offer this solution for mid-to-large scale (up to 100 handset) roaming solutions. It seems to be a very capable self-installed solution. It would still be advisable to have a professional site survey to determine the best locations for the installation of radios.
It will be automatically provision if you are using recent PABX firmware, and the flexibility of the provisioning will improve over time.
These Gigaset DECT basestations support 6 handsets and 3 simultaneous calls. You need to be sure to buy the correct handsets to support all of the call and roaming features. You may also need more base stations due to their lower capacity, but handsets can be set to switch to best signal as the phone moves. They still do not roam in-call.
In the lab we have managed to configure a DECT repeater onto a Gigaset base station, so some of the issues from alternative 2 can be solved by having fewer base-stations, and linking up repeaters (a repeater is dedicated to a basestation). This technology was tested a long time ago, and we are not up-to-date on DECT repeater technology, so you’d need to take some advice on them, or test it out for yourself.
The device we used allowed you to repeat 1-hop in any direction from the base. You can have up to 6 repeaters on a base.
The username and password is sent to the phone based on the current system configuration. If the configuration has been changed but the phone has not recently reloaded its configuration, it may be out-of-sync. A reboot should fix this.
Some phones have a “user” login. This can be seen by looking on the PABX web interface “System -> PhoneHardware” screen, and clicking the “Show Info” icon.
Other phones have only an administration login. The password for this login is set in “Global Settings” in the PABX web interface.
Is the call being routed over the Internet, or other WAN link? If so, then you may simply not have enough bandwidth on the link. It may help to configure the link to use low-bandwidth codes.
If the problem is occuring on calls made internally, or via an ISDN link, then it is possibly a LAN traffic issue. Try connecting the phone to a switch port that is closer to the PABX and see if that improves the quality. Ensure that the network is switched, and does not use hubs. Use a network monitor to check that there is not a large amount of broadcast traffic on the LAN.
This is generally caused by one of:
This is caused by a facility called “RTCP”, which is some extra control signalling in the voice data. Some devices support it, and some devices do not. If a call switches from a device which supports it (eg. snom) to a device which does not (eg. an ISDN call) then some softphones can timeout and hangup the call.
This can be resolved by disabling the timeout. On X-Lite, Eyebeam and Bria, this setting is found under Network/Advanced in the preferences menu.
Phones are DC powered, un-earthed, and susceptible to mains AC noise. This can normally be solved by providing a better earth to the phone by using a SHIELDED twisted pair cable, and ensuring that the socket the cable is connected to has a path to earth.
(Note: if the phone has 2 network ports, and one is connected to a PC, using an STP cable between the phone and PC will be the easiest solution)
By default the PABX sends your extension number as the caller ID. The ISDN network, or other far-end service provider will then try to resolve this to a “valid” number. This resolution may vary between providers, so the results will vary.
To send a different number or to bar the sending of caller ID, edit the caller id override field in the edit-extension screen of the PABX web interface.
Extensive per-provider caller-ID configuration options are available. Click the ‘123’ icon next to the provider that the call is being sent to to check these settings. Different providers have different requirements, and behave differently if invalid numbers are sent to them.
Below are basic and generic configuration instructions. Please contact our support department for information on the latest compatibility with SIP software for Android and IoS.
First create a phone entry on the PABX:
Using the PABX hostname, and the SIP username and password from above, follow the configuration instructions for the handset software. It will probably be necessary to disable all audio codecs except “alaw/g711a” and perhaps “gsm”.
We don’t support entering contacts directly to the phone. Contacts should only ever be added via the PABX using one of the following methods:
PABX -> Users -> Manage Phonebook
User -> My Details User -> My Details -> CSV Addressbook This has the advantage of being able to replace a phone in the event of a failure and still retain existing contacts.
Handsets normally display the addressbook alphabetically. The address book is filled from the PABX in the following order:
Please note all phones have a limited number of phonebook entries, once this has been exceeded additional contacts will be ignored.
PDQ and Modem devices will struggle to work on an ATA device except for brief 9,600 baud connections. SIP is not a reliably clocked protocol, so frame-slippage occurs in the translation from analogue to SIP to ISDN and means it is generally very unreliable except for short transmissions.
If the communication is over the Internet, there is virtually no chance that it will work as the jitter introduced as the data crosses the Internet is variable.
For extended PDQ and Modem usage, we suggest connecting them to a real analogue line. The vast majority of services where PDQ/Modem equipment is used are replacing these devices with online equivalents, which will eventually make the problem disappear.
Information updated as of June 2014
Some Yealink products are listed in their datasheets as Hearing Aid Compatible, and others not, but having discussed this with their UK technical staff, we understand that the T41PN, T42GN, T46GN and T48GN models are fitted with a ‘T’ mode inductive loop in the handset.
Our supplier has informed us that none of the current snom handsets have support for hearing aids. The snom m3 DECT did but it is now a discontinued product.
From the Polycom datasheets on the IP and VVX range handsets:
All Polycom handsets are Hearing Aid Compatible (HAC) and have telecoils that magnetically couple to most forms of wearable hearing aids per FCC section 508 (compliant to ADA Section 508 Recommendations: Subpart B 1194.23).
The soft-fax facility is 99% reliable. Sadly, it is still only a piece of software pretending to be a fax and is ulikely to ever be 100% reliable.
We are constantly monitoring progress as this software improves, so if you have issues, let us know and we can keep you informed if things improve.
It is also possible that the Fax receive is working, but the email sending is not. If this is the case, you can find a copy of the received fax on the Users->Messages screen if logged in as administrator. Email configuration is available on the System->Global->Email screen.
There are 2 main reasons for difficulty with sending faxes from an ATA. Firstly, network quality is very important - Jitter or packet loss will prevent faxes from working as a fax machine cannot tolerate an imperfect audio stream; This can be monitored with a network trace, and using a PC product such as “Wireshark” to analyse the results.
Secondly, and more usually, the ATA units have a large number of analogue configuration options, and some faxmachines are intolerant of incorrect line settings, some suggestions follow, which apply to Sipura ATA devices:
(Set on the “Regional” settings tab of the ATA’s administration interface)
370+620||310nF - For an American device it is 600Once the above is set, it may then be necessary to modify the input and output gain settings. Using -6 in both fields is usually the best, but values of 0, -3 and -6 are usually worth trying in various combinations. Set and save a value, then try sending several (perhaps 10) faxes to see what the success rate is, then change one setting and re-test until the results are acceptable. It is usually possible to get a FAX machine working using this method.
T.38 is a relatively new protocol which can be used in the following ways on a digital system:
The PABX does not currently support this mode, but we are constantly monitoring progress as this software improves. It is expected that the “Next generation” PABX release will include a T.38 gateway facility to convert from T.38 to regular fax and vice-versa. This should be particularly helpful to enable sending and receiving faxes using a fax machine over ISDN or over a T.38 enabled SIP trunk.
Sorry, no. A combination of the number of different email document formats, and the processing power needed to convert them to fax (TIFF) format means that this facility is not supported. Alternatives are:
Connect a fax to an analogue phone socket - Most people have a spare socket on their ADSL line. Connect an ATA to the network. This is a fairly reliable solution to faxing. Use an external agency to provide a fax to email gateway.
The Bria softphone has some basic provisioning built-in. Basic steps to use this are as follows:
If the above auto provisioning is not being used, then Bria configured the same as X-Lite and Eyebeam. Important notes in that case are:
The Linksys range of ATA devices should auto-configure on the IP Cortex PABX. At present we support the SPA1001, SPA2002, SPA2102 and PAP2T. Sometimes they need some coaxing to collect their configuration as follows:
Plug the ATA into the network, power, and a phone handset, and wait until the flashing lights have settled. Dial “****” on the phone, and wait for the voice prompt. Dial “73738#” and wait for the next voice prompt. Dial “1”. The unit will reset to factory defaults.
You now need to wait between 30 seconds and 5 minutes for the unit to collect its initial configuration. This will become apparent when the device appears on the phone-hardware screen of the PABX Web-UI. It will probably also get a dialtone on the handset at this stage.
Once the device is on the PABX, rename the ports to something more meaningful than the MAC address, and associate the device with the correct user. Then repeat the reset cycle once more as above.
After a wait of up to 5 minutes, the dial-tone should return on the handset which should now be fully configured and working.
This issue generally only applies if a SIP call arrives on the PABX, and is routed back out to the same SIP provider without stopping on the PABX.
The issue is that SIP requires one party or the other to provide audio to act as a clocking source, but some SIP endpoints do not provide the initial audio under any circumstances, so the audio can never get started.
This can be rectified by adding a short burst of “silent audio” at the start of the call. Most simply this can be done by setting a “Welcome message” on the extension that handles the call. A sample of audio is provided at the link below that can be uploaded to a spare IVR audio slot and used for this purpose.
20ms.alaw silence file (Right-click and save-as)
There are two parts to this feature - marking the inbound trunk CID as trusted, and telling the outbound trunk to use the trusted CID.
It is not possible to restrict which extensions use trusted CIDs - all outbound calls on a given trunk will use the trusted CID if available.
BT no-longer publicise the 1xx three digit codes as a way of reaching BT services as they only work for direct subscribers connected to a BT line and using them for outgoing calls. This is no-longer universal so they now list only 0800 numbers as the official way to contact BT. Many of these are of the form0800800 1xx which are the same as the 1xx short codes.
The only exception to this is 100, which is still publicised by BT and connects the user to a BT operator if the customer uses BT for outgoing calls. The operator can then connect the user to a range of, usually expensive, chargeable services. Because this is a way to defeat call accounting and any barring or routing that may exist, and it is specific to BT, access to 100 is not configured on the PABX by default.
It is possible to configure the routing on the PABX web interface, by adding a number routing for “=100” and setting the destination as “ISDN”.
The PABX comes pre-configured able to recognise and route valid UK national and local telephone numbers. It will default to dialling these numbers over the ISDN interface only. To change this behaviour, it is first necessary to have configured an outbound VoIP service on the “Routing -> Service Providers” screen.
To make this provider the default channel for calls, add an new rule on the “Routing -> Number Routing” screen.
Note: If you are in an area where locally dialled numbers are less than 6 digits long, you may need to add another pattern to match against local numbers. See the help page on the Number Routing screen for more detail.
Assuming CLI set correctly and working for most destinations, this is usually outside of your control as it is function of the called parties Telco. The PABX passes the customer controlled CLI to your Telco according to its configuration (extension number, CLI override etc). For ISDN, the Telco network then verifies this CLI is valid on the line and passes both this CLI and also the Billing Number of the line onwards across the network. The latter Billing Number is hardwired for the circuit that it was received on and is used to uniquely identify the circuit for “legal” purposes like 999 calls, nuisance call tracing, billing etc as it is guaranteed to be correct by the telco. When a call is handed off to another Telco (mobile network, international call etc) then both the customer supplied CLI and Billing Number are offered, however in some circumstances other Telcos will discard the CLI and present only the billing number onwards. This sometimes happens with badly configured gateways on a network and may always happen for certain destinations (e.g. international gateways to networks that only support a single network calling party number). Basically if another network or gateway throws one of the numbers away then it will always be your CLI as this is considered a “nice to have” by the networks whereas preserving the Billing Number is a legal requirement in most environments.
We suggest that you always use the Billing Number for your line as the main Reception number or at least have the billing number be a destination that can be used to reach a real person in the event that the CLI is lost and a call returned to this number. The Billing Number is usually, but not always, the lowest DDI number in the range assigned to an individual line. If a line has multiple numbers or number ranges, please consult your Telco to identify the billing number.
Generally, the answer is that a call will record when configured to do so on the call recording matrix, but if a call is transferred, the answer is not necessarily obvious.
From PABX version 4.0.50, the following call recording behaviour should be well defined. In earlier cases, there were a number of exceptions that could make call recording more confusing:
The ‘*0’ shortcode will stop recording if dialled rapidly from an internal handset during a recorded call (unless the global option is set to disable this.)
Note: It is intended to add audible feedback that this succeeds in a future version.
Blind transfer of calls
After a blind transfer, the caller and callee settings are re-evaluated and recording will be stopped, started or re-started as necessary.
If both legs are set to be recorded, two recordings will be made, one identified by the first call and one for the second call.
Attended transfer of calls
An attended transfer occurs by setting up 2 completely unrelated calls, and then requesting that the calls are connected.
Exception, in the following scenario, call recording may stop:
A receptionist receives 2 separate calls inbound, and wants to connect those calls. If one caller is recording, and the other is not, then there is a 50/50 chance that recording will continue, depending on whether caller 1 is transferred to caller 2, or vice-versa. The order of a transfer is determined by the phone, so is not predictable.
It is intended to further improve the above as the technology allows.
If left completely unconfigured, the mail system on the PABX will attempt to use standard Internet mail rules for delivery, so configuring MX records in DNS may be sufficient.
A mail “SmartHost” may alternatively be configured into global settings to direct the PABX to send all mail via this single host.
Some (many) mail servers will not accept email from servers where the hostname and/or IP address cannot be correctly resolved in DNS, so it may be necessary to add the PABX to your internal DNS server.
References to “8500” are examples based on a default configuration. For these examples to work, it is necessary to manually create an extension 8500, then change its type to be “Voicemail Pickup” in the Extensions Edit screen.
On a multi-company system, this extesion should be owned by the “Default company”
Yes, using an automated fetch from the web interface using a tool like wget.
You will need to substitute the correct password, but the following lines should pull a config backup.
You can also be more specific about the location of “./cookies.txt” The cookie is only transient, so using
--save-cookies=/var/tmp/cookies.txt
would be a good example, and may prevent cookie files being left all over the place.
wget -O/dev/null --max-redirect=0 --save-cookies=./cookies.txt --keep-session-cookies --tries=1 "http://pabx.domain.name/login.whtm?sessionUser=admin&sessionPass=password"
wget -Obackup.tar.gz --max-redirect=0 --load-cookies=./cookies.txt --tries=1 http://pabx.domain.name/admin/backup.whtm/update/backup.tar.gz
Substitute backup.tar.gz with ivr.tar.gz in 2) to backup the IVR files.
Yes, but these backups remain on the PABX and are for “emergency” use only. If the hard drive is lost, then so are the backups.
In HA mode, the backups are automatically generated. In non-HA mode, there is a checkbox on the Global/Advanced screen to enable this feature.