Browse by category
No matching documents
- 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
- How do I enable Remote access for IPCortex support team
- What is the best way to implement a large DECT install?
- The manual says our phone can be auto provisioned, but it is not working
- I cannot log-on to the web interface of my phone. What is the username and password?
- I hear pops hisses and/or pauses when talking on my phone
- Phones periodically report 'NR' or 'No Service' / All my phones have stopped working
- If I transfer a call to a softphone it hangs up after 30 seconds
- When I talk on my phone/headset, people say I sound very quiet
- I use a headset on my phone, and can hear lots of humming or buzzing
- I do not get caller ID on inbound calls
- I do not get the correct caller ID on outbound calls
- Can I use my mobile phone as a SIP Phone on your PABX?
- My phone is in a reboot loop. How do I fix this?
- I lose my manually added contacts when my phone is restarted?
- Can I use a PDQ or modem device on an ATA?
- Which phones are hearing aid compatible?
- We are using a soft-fax, and some people can never get a fax to us
- We are using a FAX machine on an ATA, and it is unreliable. What can we do?
- I've heard about using T.38 for faxes on digital systems. What is it, and can it help?
- Is there an email-to-fax facility on the PABX?
- PABX firmware Upgrades - Additional notes
- How to configure Bria Softphone
- How to configure Linksys ATA devices
- 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.
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.
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.
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.
Near Optimal solution - Gigaset N720IP
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.
- Upside - Almost "Perfect" solution. Mostly auto-provisioned.
- Downside - Need 3rd party for radio survey/installs.
Simple Alternative 2 - Gigaset N300IP/N510IP with no repeaters
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.
Upside - Slightly better roaming solution. Mostly auto-provisioned.
Downside - Lots of manual configuration, more base stations.
Alternative 3 - Gigaset N300IP/N510IP with DECT repeaters
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.
- Upside - Full roaming solution within repeater range. Base stations mostly auto-provisioned.
- Downside - Significant manual configuration of repeaters. One-hop limited range.
- It is possible that the phone is requesting its configuration from the wrong server (some phones come with this field pre-set). Try doing a factory reset of the phone.
- The DHCP server that the phone gets its IP address from must have the "066: TFTP Server Name" parameter set. The PABX administration guide has details on configuring this setting on Unix or Windows DHCP servers. If your DHCP server does not support custom parameters, auto-configuration will not function.
- The DHCP server will also be handing out DNS server addresses to the phone. It is required that ALL of these DNS servers can resolve the full hostname of the PABX to the correct IP address. A common error is to use a made-up domain-name for the PABX, but still use and Internet DNS server that cannot resolve this name on the phone.
- Auto-configuration of more recent models of phone may not be supported by your version of the PABX software. An upgrade may be necessary
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 PABXweb 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:
- The DHCP server has stopped functioning.
- The DHCP server has handed out a duplicate IP address (often caused if an ASDL router is serving DHCP, rather than a server)
- The DNS server is no longer serving the name of the PABX correctly.
- There is a LAN issue, perhaps a faulty switch or router.
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.
Most phones allow the microphone volume to be configured for the handset and headset. This is configured by using the phone's own menus or web interface. The PABX will not attempt to set these values.
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)
Please contact your telephony service provider and request that this facility is enabled. The PABX will always present a supplied caller-ID. If it is missing, it is probably because it is not being sent.
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:
- On the PABX web UI, manually add a generic phone to the PABX from the System -> Phone Hardware menu.
- Use a made up, unique MAC Address and set the phone type to Unknown/Other.
- Unless you use static network settings (definitely not recommended) don't enter any network settings
- Set Monitor/Keepalive Override to Enabled.
- Having created the phone, click on Show Phone info (magnifying glass symbol) next to the phone and note the Line 1 SIP Login/Pass username and password which you will need when setting up the mobile.
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".
- See the section above entitled "The manual says our phone can be auto provisioned, but it is not working." Most often this issue is caused by an issue with DHCP or DNS.
- The firmware on the handset may be very old. In this case it is sometimes necessary to update the phone to a minimum required version before it can proceed.
- Some manufacturers do not allow us to distribute handset firmware. Verify that the handset firmware version is recent.
- Check that the PABX has the correct firmware on it. Some firmware files are large and are not included by default. Go to the "System->Upgrades" screen. Click the refresh link, and then use the handset-mode screen to update or fetch the required firmware.
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:
Logged in as admin...
- PABX -> Phonebook Mgmt. -> CSV Upload Entries
- PABX -> Phonebook Mgmt. -> Additional Entries
- PABX -> Users -> Manage Phonebook
Logged in as a user...
- 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.
Address book order
Handsets normally display the addressbook alphabetically. The address book is filled from the PABX in the following order:
- Auto-generated (Modified via PABX -> Phonebook Mgmt. -> Ex-directory Status)
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)
- FXS Port Impedence: The correct UK setting is "370+620||310nF" - For an American device it is "600"
- Caller ID Method: ETSI FSK With PR(UK)
- Caller ID FSK Standard: v.23
- Fax Passthru Method: ReINVITE (Asterisk does not currently support NSE, but this setting should be unimportant)
- Disable any Echo Cancelling and silence supression options, and/or set to disable EC on FAX tone detection
Once 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:
- T.38 defines a method for a fax end-point (a fax machine or gateway) to transmit a fax over a network using the UDP protocol natively. This does not fit into Asterisk's means of transmitting data as it describes a method of exchanging data that is unique to the T.38 protocol. Using this method would basically take the PABX out of the loop entirely (which may be acceptable)
It may be possible to use a 3rd party T.38 service directly with a T.38 enabled ATA to achieve bi-directional Fax over the Internet, but this is beyond the remit of the PABX configuration.
- Asterisk is able to terminate a T.38 call, and the IPCortex PABX will automatically use T.38 if offered on a SIP trunk call that terminates on a soft-fax number. At present there is no facility to scan and send documents outbound from the PABX, only to receive and email them.
- T.38 can also be represented in a manner compatible with existing SIP devices. At present, Asterisk is only capable of acting as a pass-through agent for T.38 streams, so cannot convert it to other formats - Pass-through allows two endpoints which understand T.38 over RTP to exchange faxes. This might include two ATA devices within the same company, but excludes fax machines connected to an ordinary telephone line, so is generally not particularly useful to our customers.
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.
- 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..
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
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.
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.