Getting Started

Quick Overview of the Setup

• Create an extension under Accounts -> Extensions
• Register the phone to the extension. The extension number is the username for the end point.
• Test the phone by dialing the music on hold number *9664
• Setup a gateway
• Rescan the external profile from the Status -> SIP Status page.
• View the status of the Gateway at the top of the Status -> SIP Status page.
• Setup an outbound route
• Setup an inbound route.

Menu: Accounts->Extensions

For a phone system to be useful, local extensions need to be configured. The first time the Extensions page is viewed, there will be no extensions listed. Click on the + next to the list in order to add an extension.

"Effective Caller ID" information is shown within your organization, "Outbound Caller ID" information will be seen by those receiving outside calls.

Fill in Extension in order to get a basic phone up and running. It is suggested that a system administrator complete the following: Extension (according to the numbering scheme used in the implementation) User list (assign a user to each extension – this allows the end-user to log into the FusionPBX web GUI and check voicemails, faxes and so on via the web. This does not have to be done immediately.) Voicemail options (e.g. have voicemail sent to a designated email address.) (editors: Toll allow is a new option – where is this used? I don’t have this set on my system yet my calls all still work)

• The range entry allows more than one extension to be created at a time. This would probably be most useful when doing automated telephone provisioning (note to editors – you’ll need to flesh this out as we now have a provisioning section on this page and I have no idea how to use it).

Save each configured extension (the save button is at the bottom of the GUI). When the save is complete, the screen is returned to the list of extensions. Click on the extension just created. Click on the password field to reveal the current password directly below the field. Note the password is displayed because it will be needed to configure a telephone to negotiate with FusionPBX. At this point, it might be prudent to test a telephone negotiating with successfully FusionPBX so that further testing can be performed, ensuring that the following are also properly configured: IP address of FusionPBX (the phone might know this as the SIP server) Extension (the extension number is the username for the phone) Password for the extension

Read the manual for your IP phone or soft phone for more information. Once the phone is connected you can test it by dialing *9664 which is a code for music on hold.

Menu: Accounts->Gateways

To use a phone to call somewhere other than music on hold or another extension, configuration of a gateway is required. A gateway is a SIP provider that sells telecommunication services. A SIP provider performs two major functions which are:

• completing outbound calling to telephones outside of an end-user’s internal network (e.g. calling other offices, mobile phones, etc.)
• providing end-users with inbound services associated to a phone number, also known as Direct inward dialing (DID) or Direct Dial-In (DDI). (See more information about call provisioning and routing under DialPlan, Inbound Routes and Outbound Routes)

When a Gateway has been created, apply the settings

Go to the Status->SIP Status page and in the Sofia status profile external section click on the rescan button so that Freeswitch rescans the external profile. Once this is done the status of the new gateway should appear at the top of the Status->SIP Status page. If everything is successful the status should say “REGED” which means that it has been registered. This signifies that the account and password details were correct and that the associated Freeswitch server has logged onto the SIP provider’s network successfully using the designated account profile. The next step is to setup an outbound route.

Menu: Dialplan->Outbound Routes

When setting up a Gateway, Outbound Dialplan routes are added there. If Outbound routes are to be administered later in the process then this is still where those modifications are made.

Once outbound routes have been defined and settings applied appropriately, outbound calls can be attempted. Testing the function can be done at this time. If it doesn’t work, refer to CLI DialPlan Management to diagnose what is failing and to fix the problem.

Menu: Dialplan->Inbound Routes

Before receiving calls from an external source, an Inbound route must be configured. Click on the + next to the empty list of inbound routes.

Assign the Inbound route a name. (For example, the full international phone number people would dial from a standard phone to reach this route could be used as the name of the route. The chosen SIP provider will have given the telephone number designated to the system if the SIP service is supporting inbound calls).

In Condition 1 choose destination_number in the field and in the expression put: ^(full international number)$ replacing the full international number by the full international form of your inbound number. For instance, in Sydney, Australia the local number of 9999 9999 would have a prefix of 02, being the area code for Sydney, as well 61 as a country code for Australia. Therefore the full international number is 61299999999. Note that an entry starting with ^ and ending with $ is called a regular expression. For more information on this look at section Advanced DialPlan (editors – need to add a hyperlink here to that section of the document)

In the Action 1 field choose the extension previously defined. Leave the order as 0 and Enabled as true. Provide a description which could include the name of the SIP provider so that it is not forgotten who provides which service; especially if you have multiple providers for least-cost routing or redundancy purposes.

Press Save when completed. A Dialplan has now been defined that will take all calls from the trunk defined and deliver those calls to the extension(s) assigned.

With Inbound routes defined and settings applied, attempt some test calls to the phone system from another phone (for example, a mobile phone or a traditional fixed line phone). Try it now. If the Inbound route does not work properly, refer to CLI DialPlan Management to diagnose what is failing and to fix the problem.

Menu: System->Settings

Find and configure system settings at System->Settings. Area Code is important Default Gateway is referring to the SIP Gateway.

Voicemail to email

For voicemail to email configure SMTP server settings in Advanced ->Default Settings.  Configure the destination email account in the settings for each extension.  FusionPBX does not use an MTA (Message Transfer Agent eg. sendmail or postfix). Instead FusionPBX uses a PHP script that acts as an SMTP client and connects to the SMTP server using the account and password specified by the system and/or extension administrator.  As a result, there are no queues or logs where message sent or failed can be viewed.  However, if the php script was executed (whether the voicemail was successfully sent or not) there will be a file in /tmp called voicemailtoemail.txt. If voicemailtoemail.txt was created and the voicemail was not received as an email, there could have been two possible results from the action. One possible result was that the script may have executed but it did not successfully negotiate with the SMTP server. Alternately, the script successfully sent the voicemail; however, the destination email account was incorrectly assigned in the settings.  If the file is not present in /tmp then it is likely that the voicemail file and directory permissions to /var/www/fusionpbx/secure are incorrect.  The voicemail script is v_mailto.php.  If it is inaccessible to Freeswitch then the function will not run and the file in /tmp will not be created.

Menu: System->System Settings

Go to System-System Settings and configure the settings there.

Menu: System->Modules

When in System->Modules do not make the mistake of assuming that what is seen in the Modules configuration page represents settings configured in Freeswitch. By default, this is not the case. If there is a preference to work directly with Freeswitch rather than use a module GUI in FusionPBX, to protect any customizations made directly in Freeswitch those settings have to be applied to FusionPBX. With a fresh FusionPBX installation on the designated server there are no configurations to lose, so applying the Freeswitch settings is simple. To apply those settings edit ANY module setting in FusionPBX, an actual change does not need to be made but the settings need to be saved as they are. Then apply those settings. By doing this action settings are committed into freeswitch/conf/autoload_configs/modules.conf.xml. You can actually see the settings in the FusionPBX XML editor under autoload_configs/modules.conf.xml.