Browse by category
- End points
- Platform and service specifications
- Virtual PBX
No matching documents
- Can I reduce the PABX's reliance on DNS in case my DNS server dies?
- What firewall ports do I need to configure?
- Can I use a SIP phone directly over the Internet back to my PABX?
- Can I use "VoIP service", and how do I configure it?
- General network considerations, DNS, DHCP, Gateways
- SIP outbound calls do not hear a ringtone
- How do I enable Remote access for IPCortex support team
- How do I enable SSL (HTTPS) on the PBX Web interface
- PABX firmware Upgrades - Additional notes
- How to configure Siemens Gigaset DECT devices
- How to configure Polycom IP Phones
- How to configure Bria Softphone
- How to configure X-Lite 2.0 for Linux
- How to configure Linksys ATA devices
- How do I integrate with Microsoft Lync?
- I cannot dial 100 to get the operator
- I want to use a VoIP channel by default. How?
- How can I calculate correct charges for calls made over the IPCortex VoIP service?
- My caller ID is sometimes sent incorrectly on ISDN.
NOTE: This applies only to older PABX releases. Newer systems will automatically use an IP address where prudent to reduce the reliance of the system on DNS.
The PABX has a simple built-in nameserver, which will always serve the PABX's own IP address for the hostname that it is configured to use. It is not possible to add any other hosts or addresses, which means it is not possible to use this facility as your main DNS server, but any unresolvable queries will be forwarded to the DNS servers that the PABX is configured to use.
Given this, there are a number of ways that this can be used as set out below. The "best" way is number 3) as it makes an exception only in the case of a failure, but the other methods are valid in some environments.
1) Manually configure all phone IP/DNS settings.
If it is not possible to change the DHCP or DNS server's settings at-all, then it is possible to manually configure all of the VoIP phone settings to use static IP addresses. This allows a DNS server to be specified manually for each phone, which can be set to point at the PABX instead of the usual DNS server. The PABX will always serve its own name/IP address automatically.
To manually configure phone IP/DNS values, change the settings on the "System -> Phone Hardware" screen of the PABX web interface. There is a significant overhead in managin this, so it is not recommended as a first choice.
WARNING: Ensure that there is no risk of duplicate IP addresses, do not use IP addresses that will be served by your DHCP server!
2) Use the PABX as the primary nameserver.
To use the PABX as a primary, it is necessary that the PABX hostname is put into a sub-domain of the main office domain name. For example, if the office domain is:
then DO NOT name the PABX:
instead, perhaps name it:
which is in a subdomain that will not interfere with the operation of the existing office DNS. Configure the PABX to use the office DNS as its own DNS server, and it should then be safe to set DHCP to refer to the PABX as the primary nameserver.
This solution is probably most suitable for environments where there is no internal DNS server at-all, as it removes the reliance on an ISP's DNS server, and the Internet link.
3) Use the PABX as a secondary nameserver.
This is an extension of option 2) above. Configure the PABX using a sub-domain as described, but instead of using the PABX as a primary nameserver, configure it as a secondary nameserver.
It will additionally be necessary to add the PABX subdomain to the existing primary nameserver as a "secondary" or "slave" from the PABX. This will cause the DNS data on the PABX to be transferred to the primary, and made available there.
If the primary nameserver dies, there may be an occasional pause when dialling calls (while the phone determinsed that the primary server is down), but the system will be largely unaffected.
An extension of the above in environments where a primary and secondary nameserver already exist, is to simply transfer/slave the subdomain from the PABX to both of the existing office DNS servers.
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:
1) A standard PABX install with no external phones or VoIP links will try to use the Internet to keep its internal clock correct. This uses:
UDP Port 123 (outbound from PABX)
2) If SIP phones or soft-phones are to be deployed remotely, this should be done using a VPN. The SIP protocol does not traverse firewalls at-all well. If absolutely necessary, the following ports are used:
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.
3) If a SIP trunk is being used to a provider, the same ports as for SIP phones above are used.
4) If an IAX2 trunk is being used to a provider, then only a single port, which will safely traverse NAT is required:
UDP Port 4569 (outbound from PABX)
5) IMPORTANT: If using a Cisco router or Firewall, you need to disable the SIP ALG (Fixup) module where possible - The Cisco SIP ALG is reportedly not compatible with non-Cisco SIP devices. The IOS commands will resemble the following:
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
6) To allow IP Cortex Ltd access to our PABX for support or maintenance:
TCP Port 22 (inbound to PABX) This can (and should) be further restricted by specifying that these connections are only allowed from IP Cortex addresses.
7) To allow the Remote support Tunnel to function the PABX must have access to the Internet for DNS resolution and to TCP port 122.
We strongly recommend that you use a Virtual Private Network (VPN) setup to securely tunnel SIP traffic back to an internal PABX, rather than attempting to pass unsecured SIP in the clear across the Internet.
We recommend this for several reasons:
1) SIP is an inherently insecure protocol, so you should only really run a remote node over a VPN - If you are running over a VPN, then it should terminate on a network that has unrestricted UDP access to the PABX. This makes things simple and in this environment remote phones "Just work"
2) SIP is a complex protocol which is poorly supported in most firewalls! Like FTP, the control channel carries information about which ports and IP addresses the audio stream will use. Firewalls in general do not understand SIP (and sometimes understand SIP, but badly, causing matters to be even worse) so you have to open all UDP ports between the PABX and the phone.
3) SIP does not like NAT - Some features have been included to assist in making this work, but it can still be tricky to configure. Again, some devices support SIP fully, and this may help.
The PABX has a setting against each phone on the phone hardware config which marks it as "non-local or NAT". This causes all communication for that handset to pass through the PABX, increasing the chance of the handset working remotely, but prevents handset-to-handset call handoff from working, so it is less efficient.
In contrast, setting up a VPN, or using an existing VPN is usually fairly simple and in many cases necessary for access to other internal applications. Once setup, a hard phone can simply be plugged into the network at the remote site and connect to the central PABX. Roaming applications can be dealt with using a soft phone and PC VPN client on a laptop.
Here are some documents which may assist. It is strongly recommended that you carry out your own testing in advance of any sale, before committing to using a specific provider:
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.
Multiple ADSL gateways
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:
1) 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.
2) 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.
This issue is probably caused by a fix in PABX version 4.0.65 which corrects a previously incorrect SIP behaviour in the PABX.
A very few SIP providers (ITSPs) will send audio for the ringtone instead of the more common method of sending a "please make a ringtone sound for me" message. If this occurs, then the ring-audio is flowing from the ITSP to the handset, but the call is not yet answered, so no audio flows in the other direction.
The above can cause issues if the firewall is not allowing the audio to flow from the ITSP to the PABX until a matching outbound audio stream starts.
At present the choices are to:
- Open the firewall to allow the audio
- See if the ITSP can be persuaded to not send the ring audio
- Downgrade to 4.0.64
- Upgrading to 4.0.67 should improve matters in most cases
The following services CAN NOT be used to remote administer the VoIPCortex PABX.
- Microsoft Remote Desktop Services
- Team Viewer
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.
RDP is a LOT less secure that SSH. In fact there are regularly reported RDP vulnerabilities from Microsoft. Other services operate on the basis of sending your session via a trusted 3rd party.
We would recommend either direct SSH access via an Internet facing IP passing port 22 to the PABX. If that is not possible RST access. 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 webUI. This session times out after 2 hours and is more secure than the above mentioned methods.
HTTPS is enabled by default on the PBX interface, but this uses a self signed certificate which is regenerated each time the PBX reboots. This is somewhat helpful to increase the security of things like the admin password which will no-longer be sent in the clear over the LAN on an HTTPS session, but will cause the browser to generate a warning each time the PBX is accessed, and does not verify the authenticity of the PBX.
If you wish to use SSL extensively then it is normal to apply a certificate signed by a public CA to the PBX. In order to do this, you should first turn off automatic regeneration of certificates at reboot, by adjusting the setting in system - global - advanced to check "Prevent HTTPS certificate being regenerated each reboot"
You will then need to login to the PBX at a root prompt by SSH and perform the following steps. Please complete these carefully, and preferably whilst you are onsite with console access as it is possible to prevent the HTTP server process re-starting on the PBX if there are any errors and this will lock you out of web access:
1- Generate a new 2048 bit private key
root@pabx:~# openssl genrsa 2048 > /etc/ssl/private/NEWapache-pabx.key
Generating RSA private key, 2048 bit long modulus
e is 65537 (0x10001)
root@pabx:~# chmod og= /etc/ssl/private/NEWapache-pabx.key
2- Generate a certificate signing request (CSR)
Note that the data you enter into the fields below may depend on the requirements of the Certificate Authority, the following is an example only, please check your CA documentation for the CSR data they require and enter the actual data for the organisation applying for the certificate:
root@pabx:~# openssl req -new -sha256 -key /etc/ssl/private/NEWapache-pabx.key >/etc/ssl/NEWapache-pabx.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
Country Name (2 letter code) [AU]:GB
State or Province Name (full name) [Some-State]:Borsetshire
Locality Name (eg, city) :Holby
Organization Name (eg, company) Internet Widgits Pty Ltd]:Acme Telephone and Spacedust Ltd
Organizational Unit Name (eg, section) :The PBX
Common Name (eg, YOUR name) :pbx.fully.qualified.hostname.net
Email Address :
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password :
An optional company name :
root@pabx:~# cat /etc/ssl/NEWapache-pabx.csr
-----BEGIN CERTIFICATE REQUEST-----
-----END CERTIFICATE REQUEST-----
Paste the above CSR into the CA request form
3- Install the certificate
When you receive the certificate from the CA, backup the existing files as follows:
root@pabx:~# mv /etc/ssl/private/apache-pabx.key /etc/ssl/private/OLDapache-pabx.key
root@pabx:~# mv /etc/ssl/certs/apache-pabx.crt /etc/ssl/certs/OLDapache-pabx.crt
and then install the new key and certificate by pasting the received certificate file (terminate the pasted input by pressing Ctrl-D):
root@pabx:~# mv /etc/ssl/private/NEWapache-pabx.key /etc/ssl/private/apache-pabx.key
root@pabx:~# cat >/etc/ssl/certs/apache-pabx.crt
If your certificate provider supplies you with both an identity certificate and one or more intermediate certificates then you should paste all of these certificates one after another into the above CRT file, preserving the BEGIN CERTIFICATE and END CERTIFICATE lines for each, but ensuring that there is otherwise no additional white space or other characters pasted into the file.
On completion of the above, it will be necessary to reboot the PBX in order to start connecting securely. If you wish to test the certificate without rebooting then you can do so by issuing the following command at the root prompt:
root@pabx:~# /etc/init.d/apache2 restart
A full reboot is however still required for all aspects of the PBX (including the API) to start using the new certificate.
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.
- Some Cisco SPA series phones
Yealink - Only one auto-answered call is possible at a time. Placing a second call before the first is completed will cause the 2nd call to be rejected.
Polycom - As per Yealink, but if the call is made to a spare line, it is allowed to ring.
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.
- Some Cisco SPA series phones
Yealink - Only one auto-answered call is possible at a time. Placing a second call before the first is completed will cause the 2nd call to be rejected.
Polycom - Ignores this setting.
Allows a call to be placed on hold or retrieved using OCM.
Aastra - There is an incompatibility with the Aastra SIP stack and this feature, which may cause instability in the handset if used.
- Always read the helptext on the Upgrades menu. This covers both upgrade and rollback procedures in case of issues.
- If using very old/discontinued Polycom handsets, refresh the firmware list, and use "Handset firmware mode" to see whether any of the older firmware needs updating. This is not upgraded by default as it is not generally needed.
- If using very VVX or Soundstation Polycom handsets, refresh the firmware list, and use "Handset firmware mode" to see whether any of the firmware needs updating. This is not included in the upgrade package due to its size.
Step 1 with these devices is always to ensure that the latest Siemens firmware has been installed using the upgrade option on the DECT unit's web interface.
1. Power up and connect the basestation to the LAN as described in the phone manual. It is optional, but worth also bonding the handsets at this point (full detail in the supplied manual)
2. If you are using static IP addresses, follow the phone instructions on setting the address, otherwise, use the phone handset or DHCP server to determine the DHCP allocated IP address. From a handset that is registered with the appropriate base, the IP address can be found on the phone menu under
Menu -> Settings -> Base -> Local Network
3. Connect to the basestation IP address from a PC web browser. Initially it is only possible to connect to the basestation from the LAN it is connected to. The default pin number is 0000.
4. On the "Status" screen, the MAC address of the device can be found. This can be used to manually create a phone of type "Unknown/Other" on the PABX web interface (System -> Phone Hardware menu.) Once the phone is created, use the "Show" spyglass option to discover the SIP Login and Password.
Up to 6 registrations can be created for a single S450IP basestation. On older systems this requires 6 separate phone devices to be created. On newer systems Selecting a phone type of "Gigaset S450IP" will automatically create 6 registrations.
Each base-station will also support up to 6 DECT handsets. Details of bonding or un-bonding the handests is covered in the supplied manual. A handset may be bonded to several basestations, but roaming while a call is in progress is not possible using this technique.
5. Before continuing, ensure that the latest phone firmware is installed on the basestation.
Simply chose the upgrade option using Settings -> Misc -> Update Firmware on the S450IP web interface. This takes a couple of minutes to complete.
6. On the Gigaset Web screen, select the Telephone -> Connections menu. For each SIP registration you created above, ensure that a VoIP provider entry is enabled.
Disable the Gigaset.net VoIP entry.
Edit each of the activated VoIP entries in turn, and set the following values:
- Name: (A memorable name)
- Authentication Name: (sip username)
- Authentication Password: (sip password)
- Username: (sip username)
- Display Name: Name of the extension
- CLICK "Show Advanced"
- Domain: Fully qualified DNS name of PABX
- Proxy Server Address: IP address or Fully qualified DNS name of PABX
- Registrar Server: IP address or Fully qualified DNS name of PABX
Click the "Set" button at the bottom of the screen to save these settings.
7. On the Telephony -> Audio menu, select "Own Codec Preference" and then remove all except "G711 a law" from the left column, so that all other codecs are disabled.
8. On the Telephony -> Number Assignment menu of the Gigaset, it is possible to select which registrations will ring which handsets, and which registration each handset will use when making an outbound call. Be sure to un-tick fixed-line and Gigaset.net checkboxes.
9. On the Telephony -> Advanced menu of the Gigaset, the "DTMF over VoIP" setting should be set to RFC2833 ONLY, the other settings should be un-ticked.
10. On the Miscellaneous menu of the Gigaset, set the Country to be used for time updates to "United Kingdon". You may also update the time server from "europe.pool.ntp.org" to point at the PABX, but either setting will work equally well.
Supported Polycom IP phone models will auto-configure on our PABX. On PABX systems with older software there is a small "bootstrap" process required to initiate the config.
During the boot-countdown when the device is powered-on, enter the boot setup menu (default password varies, IP4000 has a default password of "456") and change the boot method from FTP to TFTP. Save this setting and reboot.
The Bria softphone has some basic provisioning built-in. Basic steps to use this are as follows:
- If running DHCP on the PABX, go to Globals/DHCP and enable option 120. If not, then you'll need to enter the PABX hostname into Bria when it starts.
- To be provisionable, the Bria phone, must be owned, and the phone name must be the same as the owning user's login name (all in lower case)
- The user must have a password set.#
- When bria starts, enter the user's username and password into the popup.
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:
- Disable all unused Audio and Video Codecs
- Disable RTP and RTCP timeout detection
This FAQ does not consider the necessity of configuring a graphical X-based Linux system, and enabling a headset and microphone in this environment. Usually these items will auto-configure on a modern Linux desktop system such as Debian, Fedora or Ubuntu. Download the x-lite executable from CounterPath. Open the downloaded archive, and place the single executable file somewhere in the filesystem where it will be runnable. If desired, create a menu or desktop shortcut to this executable.
Start the program. On first use, the audio wizard, and then the configuration dialog will normally be opened so you can add set up sound and configure a SIP registration, if not, click the properties icon above the numeric pad (to the right of "CLEAR") to open this screen.
Under the "System Settings" menu, you can configure Speaker, Microphone and ringer devices.
Under the "System Settings" -> "SIP Proxy" -> "[Default]" menu, you can enter the credentials for your SIP account. The details will be available from your PABX administrator once your softphone account has been created.
- Enabled: Yes
- Display Name: (enter your extension number or name here)
- Username: (enter your SIP account username here)
- Authorization User: (same as above)
- Password: (your sip account password)
- Domain/Realm: (hostname of PABX. eg pabx.voipcortex.co.uk)
- SIP Proxy: (same as domain/realm)
- Outbound proxy: (same as domain/realm)
NOTE: Your PC must be able to resolve the hostname of the PABX to the correct IP address. If DNS does not provide this facility, you may need to add a mapping into your local
This should result in a phone that lets you know that you have registered okay. Dial "*600", and you should hear an announcement. After the announcement is over, anything you say will be spoken back to you. This will confirm that you can communicate with the system.
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.
We interoperate with Microsoft Lync for calls using SIP over TCP. This has been tested in our lab environment and also implemented at one stage or another by several resellers.
Nearly all of the complexity of configuring this is at the Lync end and in our experience it takes several man-days of effort to configure a basic Lync installation talking to an external PBX using SIP over TCP, and just a few minutes at the ipcortex PBX end to configure a SIP trunk as SIP over TCP and setup relevant routing rules.
We recommend that resellers attempting this are very familiar with Lync before proceeding. The only support that we can give will be with the PBX config itself, although we would be happy to share some notes that we used when setting up Lync (through the normal support channels) but cannot provide any further assistance at the Lync end of the connection.
Microsoft also has an optional XMPP connection piece available for server-server communication of IM and presence from/to Lync. As the ipcortex PBX includes server-server XMPP this should allow Lync and VoIPCortex to share presence and IM for connected users, but this has not at present been verified by us.
1) Check that the number is configured onto the system. The inbound number must be associated with an extension, which must call a user. Unless a user has been configured, all calls will hear "busy".
2) If the caller hears a long (typically 10 second) pause before getting a busy or fault tone, it is possible that the ISDN provider (ISDN2 only) has configured your line in PtMP Mode (Point-to-MultiPoint Mode) - This needs to be changed to PtP Mode (Point-to-Point Mode)
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)
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, but 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.
- Under Route Name enter a unique ID
- Under Number Prefixes enter "XXXXX" (5 X'es without the quotes)
- Under Provider 1 select your VoIP provider
- Under Provider 2 select "ISDN"
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.
A CSV file is available for download from HERE (pabx-070209.csv)
To use this file, open the PABX Call Rates and Charges screen, and select to create a new rate.
- Supply a rate name such as "ipcortex070209"
- Set the Active-from date to match the date in the filename "9 Feb 2007 0:00"
- Add a peak-time range by specifying: (Monday, Friday, 06:00-20:00, Peak) in the Create Charge band fields
- Click Append
- Click Add
Now that the rate is created, you can import the data from the CSV file. The supplied file should work with the default values on the import screen.
- Click the Import Rate icon next to the newly created rate
- Click the Browse button, and select the downloaded CSV file
- Click Import - This verifies the file
- If the data looks okay, browse to the same file and click Import again
Once this is done you need to specify the cases where these rates will be used. This is done by clicking the "Add New Usage" icon, and selecting the IPCortex provider from the drop-down list.
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:
1) 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.
2) 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.
3) Attended transfer of calls.
An attended transfer occurs by setting up 2 completely unrelated calls, and then requesting that the calls are connected.
- If neither of the calls was set to record, no recording will be started.
- If both of the calls were set to record, one of the recordings will be stopped.
- If only one of the calls was set to record, it will continue (NOTE: See the exception below)
- If never-record has been set for either remaining party, all recording will be stopped.
- An attended transfer may cause a recording to be split, either the first recording continues with a silent break in the middle, or the second recording continues. This will usually depend on the handset make that does the transfer.
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
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"
2) do a backup
wget -Obackup.tar.gz --max-redirect=0 --load-cookies=./cookies.txt --tries=1 http://pabx.domain.name/admin/backup.whtm/update/backup.tar.gz
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.