3CX Advanced Certification

The Prioritised Hunt ringing strategy will call the extensions in the ring group one by one in the order which they are defined in the list. Again, each call to the ring group will take 1 simultaneous call from your 3CX license.

[SLIDE 4]

Creating Ring Groups in 3CX is very easy. In the Management Console, select “Ring Groups” from the menu on the left, and then click “Add Ring Group”

The name you give to the ring group will show up on the group members’ telephone screens, whether this is a 3CX Client or an IP Phone. This way, the agents will be able to see which ring group the call is coming to, and answer the phone accordingly.

[SLIDE 5]

Ring group members will be answering the calls directed to the ring group. These are normal user extensions, which are assigned to the ring group. They will only be able to answer one call at a time. When they are on a call they will not be polled for a second call.

If a group member is busy, there is no retargeting of the group member. The PBX will work its way through the list only once. If a member of the group is not available to answer a call, the PBX will try the next available member in the list.

If retargeting of the group members is required, calls queues will need to be used instead. For more information about call queues, please refer to Module 3.5 Call Queues, which covers the characteristics of queue polling.

An extension can be part of multiple ring groups. If an extension is talking on a call from one of the ring groups, it will not ring for a call of another ring group.

[SLIDE 6]

In the “Group Members” section of the Ring Group configuration, the members of the Ring Group can be chosen.

Click on “Add” to add them.

You will be presented with all the available extensions, which can be assigned to the Ring Group. If you do not see a particular extension in the list of the pop up window, please check that this extension is not already part of the Ring Group.

When you use the Prioritised Hunt ringing strategy, the order of the members in the group, as defined in the list will affect the ringing of the extensions. You can move the extensions up or down in the member list to change the ringing sequence of the extensions.

[SLIDE 7]

The way the prioritised hunt ringing strategy works, is as follows.

The ring group will always ring the first available ring group member in the list. It will ring this extension for the configured Ring Timeout. By default this is 20 seconds, but this can be increased or decreased as desired.

After ringing the extension for the ringing time configured, it will move along to the next available ring group member. It will keep doing this all the way through the list, until the call gets answered.

An extension which is already in an active call will not be polled, and the call will move on to the next available extension in the list.

Calls which are not answered by any of the extensions in the list will go to the Destination if no Answer.

More about the Destination if no Answer 2 slides further down.

[SLIDE 8]

The Ring All strategy will ring all available agents, that is, agents which are not already in a call, simultaneously for the duration of the ring timeout.

The first one to answer the phone will take the call and the rest of the phones will stop ringing.

After ringing all the phones for the duration of the ringing time, the call will go to the destination if no answer.

[SLIDE 9]

The Destination if no Answer is a preconfigured destination, which calls overflowing from a Ring Group will be routed to in case a call is unable to be serviced by the Group’s members.

A call can be dropped if it is not serviced by the ring group.

You can connect the call to a user or system extension, which may be another ring group, a call queue or a digital receptionist as well.

You can divert the call to a voicemail box of an extension, as well as a group voicemail. However, with the group voicemail, an email will be sent to the ring group or queue members as an attachment, and not as a voicemail to be heard from the phone of the extension.

A call can also be forwarded to an outside number.

[SLIDE 10]

When a call comes to an extension and doesn't get answered, then the call is logged as a missed call in the phone’s call log.

When a call comes to the Ring Group however, and you have a number of extensions servicing the call, how would the missed call notification be handled in the different Ring Group scenarios?

It basically depends on the ringing strategy configured on the PBX.

When you have a Ring All strategy, and the call ends up being routed to the Destination if no Answer, then all the members of the Ring Group will be notified of the missed call.

If the call gets answered by any one of the Ring Group members, then that call will not be logged as a missed call. No extension will be notified, as this call will be considered answered by the PBX.

When the Prioritised Hunt strategy is in use and the call ends up in the Destination if no Answer, then all the group members will be notified.

If a member of the group answers, then the members which were polled before this extension in the group list, will be notified. So if group member 4 answers the call, group members 1, 2 and 3 will be notified. Any extensions in the group list after this extension will not be notified.

[SLIDE 11]

When a call is not answered because the caller has hung up the call, the Missed Call Notification will again depend on the Ringing Strategy configured.

In a Ring All strategy, all member extensions will be notified.

In a Prioritised Hunt strategy, the members which were polled up until the point the call was hung up, will receive the Missed Call Notification.

So, for example, if extensions 1 through 5 were polled and the call was hung up while extension 5 was ringing, then the extensions from 1 through 5 will receive the missed call notification. Extensions after extension 5 will not be notified.

[SLIDE 12]

Paging groups will also merge multiple extensions under one virtual extension number, but instead of ringing the phone, it will open the speakers of the phones automatically, to allow the caller to make a broadcast.

This broadcast will be a one way transmission from the caller to the paging group extensions. The called extensions will not be able to communicate back to the caller.

There are two types of paging groups: Alert and Multicast. But what are the differences between the two?

[SLIDE 13]

An alert paging group is configured with up to 64 members possible to be added to the group.

It is possible to have local extensions configured, both IP Phones and 3CX clients, remote STUN extensions and remote SBC extensions.

Multicast paging groups can only be configured with local desktop IP Phone extensions. Multicast traffic will only be able to traverse the local network, so remote extensions receiving multicast traffic is not possible.

As this is happening at the network level, there is no limit to the number of extensions in the multicast group.

[SLIDE 14]

Creating an Alert paging group is very easy in 3CX. Going to the Ring Groups page, click the “Add Paging” button.

Choose “Paging” as the paging strategy

Define the paging group’s name. This name will show up on the screens of the extensions. Note that the paging group name will only show on the screen of the alert paging group, and not the multicast group.

Add the group members which you want to auto-answer when the paging group is dialled. If you do not see an extension in the pop up window to choose from, please check if this extension is already in the list of configured extensions.

[SLIDE 15]

When adding a Multicast Paging Group, follow the same procedure to add a Paging Group, but choose “Paging Multicast” instead.

You will see a slightly different configuration screen.

Give the Multicast group a name. Please note that this will not show up in the screens of the phones, like the Alert paging group.

You will not see a list of member extensions, as they will be listening to a multicast channel, on the network.

The settings which need to be set up are the following:

IP. This is the Multicast IP which the PBX will be broadcasting to and which the phones will listen on. This will need to be an IP Address which is reserved as a Multicast IP from IANA, the Internet Assigned Numbers Authority. SIP Multicast traffic is usually found on Multicast IP 224.0.1.75. This is also defined by default on the PBX.

The port can be any available high port. For example port 50001 is possible. Please don't confuse this port 5001 which may be configured as the HTTPS port of the PBX.

The audio codec which will be used can also be selected.

Packet time is the size of the audio packets the PBX will be sending. Please keep this value at 20.

From the phone provisioning tab of the extension, the multicast paging is able to be set. All you need to do is select the multicast paging group you want to listen to and the phone will be automatically configured at the next reprovisioning. The phone will now be configured to listen to the multicast channel and broadcast any messages coming through this multicast channel, to the user via the speaker.

[SLIDE 16]

I will now demonstrate the configuration of Ring Groups and Paging Groups.

2-Call Queues

https://www.youtube.com/watch?v=RsDAe7CsyyE&list=PL6sq0_ucoDuk4oiBicc1b8ls3zVNAXfIw&index=3&t=0s

[SLIDE 1]

Welcome to the online training series of 3CX. This module focuses on the Call Queueing functionality of 3CX.

[SLIDE 2]

This module will focus on the correct utilisation of the Call Queue functionality within 3CX.

We will go through the different Polling Strategies which are available, explaining how each one will ring the agents that are available in the queue.

We will describe the various queue options that are available.

We will talk about how extensions can log in and out of queues.This can also be automated, based on the time of the day. This will be a continuation of what is covered in the Time Based Scheduling module

We will finish off with a review of the Queue Manager rights, which can be configured for an extension.

[SLIDE 3]

In the Ring Groups module, we mentioned that the list of Ring Group members will only be polled once. After polling the list once, the caller will be transferred to the Destination if No Answer.

In the Call Queues however, the callers will be placed in a queue, they will listen to Music On Hold, and wait for an agent to become available, to answer their call.

The calls are distributed to the agents as they become available, to answer a call, according to the configured Polling Strategy.

The strategies which are available, are 13 in total. The polling strategies can be based on the position of the agents in the queue list, their performance, or even based on their skills.

The Polling Strategies will be explained shortly.

[SLIDE 4]

Creating a queue is very straight forward in 3CX. In the Management Console, go to the “Call Queues” menu. From within the Call Queue page, click “Add”. This will open the Call Queue configuration.

The first thing that will need to be configured is the Queue Name. This is what will appear on the screens of the agents’ phones when a call is coming in for this queue. Give the queue a descriptive name, so it is clear to the agent, for which queue they are answering the call.

[SLIDE 5]

An agent is the user of the extension who is answering queue calls. When an agent is in a queue call, they will not be polled for a second call until they have finished with their active call. This is also valid for calls coming from other queues.

An agent has the ability to log in or out from queues. This can also be automated, so at the beginning of the agents’ shift their extension will automatically be logged in to their queues, and at the end of the shift, be automatically logged out. This is achieved by changing the profile status of an extension as covered in the Time Based Scheduling module.

The option to “Log out from queues” is in the forwarding rules configuration of the extension, to achieve this.

The agents will also be able to log in and out of individual queues. This allows for more flexibility, allowing some agents to concentrate on answering calls for a certain queue, while being able to cover for other queues when the demand arises.

[SLIDE 6]

Next, the agents that will be assigned to this queue, will need to be selected. Go to the “Agents” tab, and click the “Add” button.

A list of all the available extensions which can be added to the queue will be shown. Choose the agents which are to be added to the queue and click “OK”

When choosing extensions, only the extensions which are available to be added as queue agents will be shown. If you do not see a particular extension, please check if this extension is not already part of the queue.

Depending on the Polling strategy used by the queue, the order in which the agents are in the list, will affect the order in which the agents’ phones will ring.

[SLIDE 7]

The Ring All strategy is one of the strategies available in the Queues of 3CX. When a call comes to the queue with a Ring All strategy, it will ring all the agents’ phones simultaneously. The first agent to pick up the phone will answer this call.

The order in which the agents are in the list of the queue is irrelevant to the ringing order, as they will all ring at once.

[SLIDE 8]

Round robin is a another polling strategy which is available.

It will remember which agent answered the last call, and on the next call will begin the polling from the next agent in the list. This will prevent the first agent on the list from being inundated with calls.

The order in which the agents are listed in the queue settings is important, as the list will be polled in a top down fashion.

[SLIDE 9]

The Prioritised Hunt polling strategy is a very simple strategy. It will always poll the first available agent in the list, and work its way down the list of agents, until an agent answers the call.

If an agent does not answer, it will move to the next available agent in the list.

The order in which the agents are configured in the queue list is important, as it affects the ringing of the call.

There is also a Hunt by Threes Prioritised polling strategy, which will poll the first three available agents in the list. Again, this polling strategy is affected by the order in which the agents are in the list.

The Hunt Random Start will poll any available agent at random. There is no particular order in which the PBX will choose an agent.

If an agent does not answer, another agent will be polled at random.

The Hunt by Threes Random, will choose any 3 available agents at random and poll them for the ringing time. It will then choose another 3 random agents. There is no particular order in which the agents will be polled. Please have more than 3 agents in the queue when choosing the “Threes” polling strategies, either Prioritised or Random.

[SLIDE 10]

Polling strategies can also be configured based on an agent's performance. Depending on the agents’ activity, they will be polled accordingly.

Least Talk Time will count the duration of incoming queue calls, of each agent. The PBX will poll the agent with the least talk time, in queue calls, first before moving to the agent with the 2nd least talk time.

When agents do not have talk time, for example when resetting the statistics of the queue, the PBX will use the Prioritised Hunt strategy until the extensions all have statistics.

The “Fewest Answered” polling strategy will count the total number of answered queue calls for each agent. It will initially poll the agent with the least amount of calls answered, irrespective of the talk time of these calls. If the agent does not answer, or is busy with another call, the PBX will poll the agent with the second least amount of calls, and so on.

[SLIDE 11]

The “Longest Waiting” polling strategy will count the amount of time an extension is idle after hanging up after an incoming queue call. When the agent hangs up the phone from a queue call, a timer will start ticking. The agent with the longest time off the phone will ring first, then the agent with the second longest waiting time.

The timer is reset after each call. This will not accumulate.

[SLIDE 12]

It is also possible to assign different skill sets to the agents.

There are five different skill sets available. These are numbered from 1 to 5.

The skills based polling strategies are four in number. These are Ring all, Hunt random Start, Round Robin and fewest answered.

What happens with these polling strategies is the following. The PBX will poll the agents within the 1st skill set, based on the configured polling strategy. The PBX will apply this polling strategy only between these agents in the 1st polling strategy. Agents in the skill sets 2 to 5 will not be polled at this time.

Only when all the agents within the 1st skill set are busy, on a call, will the PBX move on to the next skill set and poll these agents. When all the agents of skill set 2 are in a call, the PBX will move on to skill set 3, and so on.

[SLIDE 13]

The “Maximum Queue Wait Time” is the amount of time a caller will remain in the queue until the call times out and goes to the Destination if no Answer.

It will ring each agent for the configured ring time, according to the polling strategy chosen, until the Maximum Queue Wait Time is reached. If, within that time an agent does not answer the call, the call will be transferred to the Destination if no Answer.

A call will also go to the Destination if no Answer if no agents are logged in to the queue. Without any agents available to service calls, the calls will immediately be forwarded to the Destination if no Answer.

During the waiting period, the caller can go to the Destination if no Answer at any time, by pressing the * button on their phone. This will need to be recorded in the intro prompt of the queue, to make the caller aware of this option.

In a queue, you can configure the maximum number of callers which can be in the queue. This includes callers waiting, as well as callers talking to agents. This can be used as a mechanism to minimise the impact on your PBX license, by not allowing too many queue calls to use up the license of the PBX, as well as using the Destination if no Answer as an overflow mechanism. Once the maximum number of callers in the queue defined is reached, they will go to the Destination if no Answer.

[SLIDE 14]

The Destination if no Answer is a preconfigured destination on the PBX where the call will be transferred to in case the call is not serviced by an agent.

A call can be dropped if it is not serviced by the Call Queue.

You can connect the call to a user or system extension, which may be another ring group, another call queue or a digital receptionist as well.

You can divert the call to a voicemail box of an extension, as well as a group voicemail. However, with the group voicemail, an email will be sent to the ring group or queue members as an attachment, and not as a voicemail to be heard from the phone of the extension.

A call can also be forwarded to an outside PSTN number.

[SLIDE 15]

When a call comes to the Queue and rings an agent’s phone but doesn't get answered, this will not be registered as a missed call on the extension individually as it happens in the Ring Group.

This will be shown in the 3CX Apps and Web Client, under Call History. There is a separate section called “Abandoned”, where all abandoned queue calls can be seen.

In the Switchboard, you will be able to see the total number of Abandoned Calls of the queues, both individually and as a whole.

A call is considered abandoned if a call reaches the Destination if no Answer, or if the caller hangs up the call before it can be answered by an agent.

[SLIDE 16]

An intro prompt can be recorded which will welcome the caller, inform them where they have called and possibly provide them with a list of options available with the queue, for example to leave a message, please press *. This example assumes that the Destination if no Answer is a Voicemail box.

There is a choice available where the intro prompt will be played in its entirety to the caller before beginning to poll the agents.

Alternatively, the intro prompt can be played while the agents are being polled, if the intro prompt message is not required to be heard in its entirety.

A Queue can have it’s own Music on Hold, which will be played to the callers as they wait in the Queue. This could be an audio file with music, an advertisement, a jingle or any other message you might want to convey to the caller. You may have a different message, for example, to someone calling for technical issues, and another message for someone calling about account issues. Please note that this Music on Hold file will only be played while the caller is waiting for their call to be answered. Being put on hold by an agent will play the default Music on Hold of the system.

The Queue can provide the caller with an audible notification of their position in the queue. The numbering is based on the polling method. Some polling strategies poll more than one caller to the agents. In this case the calls being actively polled on agents phones will be informed that they are at position 1. If a Queue is using the Ring All polling strategy, only one call will be ringing all the agents at a particular time, and only this single caller will hear that they are at position 1.

The proper audio format for all audio files in 3CX, which includes the intro prompt and Music on Hold is WAV, PCM, 8 kHz, 16 bit, Mono. Any other format will not be played by the PBX.

[SLIDE 17]

We will now look at some of the more advanced capabilities of a call queue.

If a caller does not wish to wait on the line, but would prefer to receive a callback when it is their turn for their call to be serviced, this is possible.

The Callback feature, once enabled, can be triggered by the caller, by pressing 2, while waiting. This will need to be recorded in the intro prompt of the queue informing the caller of the available option.

The callback option can also be triggered after a timeout, if a call is in the queue for too long.

A callback prefix can be defined, which will allow you to limit to where callbacks can be made to, from within your outbound rules. The call back will be made from a system extension. More information about the limitations of the outbound rules from within system extensions are covered in the Advanced Outbound Routing module.

This has the added benefit of not clogging up the PBX with queue calls. The PBX will call the original caller back after the agent has answered the call.

The wrap up time is a timeout configured on the PBX to allow the agent to finish off some data entry duties of the previous call before being available to answer the next call. This may be an entry into a CRM application, or even paperwork which may need to be completed. The extension of this agent will not ring for the configured wrap up time, to allow the agent to complete their duties without the need to logout and log back into the queue.

It is possible to limit the number of callers waiting in the queue. When a call comes in to the queue and exceeds the maximum callers defined for the queue, the call will go to the Destination if no Answer.

A queue can be defined as a priority queue. This means that calls coming to an agent, who is a member of 2 or more queues, the call coming from the priority queue will always be polled first.

[SLIDE 18]

Some more advanced queue options.

The queue call recordings can be enabled or disabled accordingly.

When queue recordings are not enabled, the settings of the extension will be used.

Sometimes when people call in to a call centre, they do not want their calls to be recorded, especially when the information exchanged is of a sensitive nature. A caller has the capability to opt out of recording their call, by pressing 3 before the call is answered by an agent. This option, after being enabled, will need to be recorded in the intro prompt, which informs the callers of their options.

There is also an option to OPT IN to a recording, where the calls are not recorded by default and the caller selects if they want their call to be recorded.

The “Service Level Agreement” time, or SLA time, is the amount of time the call centre will commit to answer a call. This is defined in seconds. All agents will need to answer the queue calls within this timeframe, otherwise the call will be considered as having breached the SLA.

The queue statistics which are shown in the Switchboard and the wallboard, can be reset either on demand or on a scheduled basis.

Within the queue settings, the statistics can be reset on demand.

The statistics can also be reset on a daily, weekly or monthly schedule. These statistics are important for the agent performance based polling strategies. If the queue statistics are reset then the polling strategy timers will also be reset.

[SLIDE 19]

A Queue can have one or more extensions acting as Queue Manager. This is available under the “Notifications” tab of the Queue settings. Choose which extensions you wish to add as Queue Managers.

The Queue Managers will receive notifications regarding the queue.

SLA time breaches are sent via email to the Queue Managers.

A Queue Manager will also be able to see when a callback is made.

A failed call back will also notify the Queue Managers. The caller may have called from a private number and not verified their number correctly, or requested a call back to an invalid destination, whether this is an erroneous number or a number not allowed by the outbound rules of the PBX.

Any queue call which is lost, either by the caller hanging up or the Destination if no Answer being triggered, will be sent as an email to the Queue Managers.

[SLIDE 20]

Agents have the capability of logging in and out of Queues.

The various methods of logging in and out of the Queues globally are:

Using the 3CX Apps or 3CX Webclient, pressing the Q button will log agents in and out of the Queues.

Using an IP Phone, you can also enter the dial codes which, by default, are *62 to log in and *63 to log out from the queues

Also using an IP Phone, BLF keys can be assigned to the extension, to log in and out from the queues. More information on the configuration of BLF keys can be found in the basic Configuring a Local Desktop IP Phone module.

If a user has access to the Management Console, to manage their own extension, they can log in and out of queues from the Extensions page of the PBX. If they have access to manage a group of extensions or any extension on the PBX, they will be able to log these extension in and out of the Queues on their behalf.

The agents and the queue managers have the option of logging agents in or out of individual queues as well.

This is achieved from within the switchboard of the 3CX App for Windows as well as the 3CX Web Client.

In the 3CX App for Windows switchboard, just click on a particular queue and right click an agent to log them in or out. When an agent is logged out from a queue with this method, they will not be logged in to the queue when they use one of the global login methods stated earlier.

With the 3CX Web Client, the list of agents on the right hand side of the switchboard, will provide the queue manager, with a Q button for each agent. They will now be able to log agents in and out of Queues as required.

This is especially helpful for logging agents in and out of queues when demand for one queue may be higher at certain times of the day, or allowing the manager to have an agent concentrate on a certain queue.

More information can be found on the link provided.

[SLIDE 21]

An extension can automatically log in or out from Queues if the automatic profile switching is configured. This is covered in more detail in the Time Based Scheduling module.

For each profile, choose the desired Queue login or logout status. The global Queue status will change with the extension profile status.

[SLIDE 22]

Let's assume extension 100 is logged in to 2 queues, A and B. The agent at this extension has explicitly logged out of Queue B.

At the end of the shift, the agent logs out of the queue A using the Q button their 3CX web client.

The next day at the beginning of the shift the agent logs in to the queues globally.

As the extension is explicitly logged out from Queue B, the agent will not be logged in to that particular queue. In order to log in to Queue B, the agent will need to explicitly log in to the queue from the switchboard of the 3CX App for Windows or web client.

[SLIDE 23]

A Queue Manager will be able to monitor the Queue or Queues they are responsible for via the Switchboard.

They will be able to monitor the Queue statistics for their agents. A Queue Manager can see the statistics for all agents. Agents who are not defined as Queue managers can only see their own statistics.

A Queue Manager can also log agents in or out from the queues on their behalf. Agents can only log themselves in or out.

A Queue Manager does not need to be a Queue agent. Any extension on the PBX can be defined as a Queue Manager.

[SLIDE 24]

3CX Webmeeting can also be used as a support resource. Just like an extension, a queue can have its own webmeeting room. Only in this case it is not personal, but the agents will all be notified of a caller waiting in the webmeeting room.

The webmeeting will be in a private webmeeting for each caller.

The Queue agents, who have a valid email address defined in their extension settings will receive an email notification of a caller waiting, as well as a chat message on their 3CX client.

[SLIDE 25]

Support can be provided in 3CX webmeeting via chat messages, or audio and video.

A support agent can also share documents, for example manuals, guides, and how to’s.

A participant can also request remote assistance via remote control of their computer directly from within the meeting.

[SLIDE 26]

In addition to 3CX Webmeeting, it is also possible to add a call us link on your website, which allows a website user to click on this and instantly chat to your queue agents.

They can chat to the agents, but if they want they can also escalate this to a voice or video call, with a simple click of a button. All they need is a browser and a headset.

[SLIDE 27]

For the demonstration of this module, we will see the configuration of a call queue. Agents will be placed into the queue, and calls made to this queue. We will see the SLA being breached, as well as a callback in action.

3-Configuring Inbound Routing

https://www.youtube.com/watch?v=7dsowZATZLs&list=PL6sq0_ucoDuk4oiBicc1b8ls3zVNAXfIw&index=4&t=0s

[SLIDE 1]

Welcome to the online training series of 3CX. In this module we will expand on the inbound rules of 3CX.

[SLIDE 2]

3CX, in addition to the routing of incoming calls based on the number which was dialled, a DID that is, can also route calls based on the Caller ID of the person calling.

We will also showcase the Caller ID reformatting, which will allow you to change the format of the incoming number, and present it in its modified form on the phones’ screens.

[SLIDE 3]

The routing of calls based on the Caller’s ID is done in exactly the same way as DID routing, but will ignore what number has been dialled and focus solely on the origin of the call.

A Caller ID inbound rule will, like a DID inbound rule, be able to route calls differently based on the time of day, with a different routing during office hours and outside of office hours.

Also, a Caller ID inbound rule can also have a holiday routing assigned to it.

Whereas an inbound rule for a particular DID can only be assigned to one SIP trunk, as this DID will be provided by that particular SIP Provider, a Caller ID inbound rule can have the same Caller ID rule assigned to multiple trunks, as someone from a particular Caller ID will be able to call you on any one of your SIP Trunks and consequently, your DIDs.

[SLIDE 4]

From the “Inbound Rules” page select the “Add CID Rule” button.

You can optionally give a name to this inbound rule, which will be prepended on incoming calls and show the name of the rule on the phones’ screens. This will help you to identify where the caller is coming from.

You will then need to set the Caller ID mask, which the PBX will use to identify the caller. You can add the number in it’s entirety, identifying a single caller, or use the * as a wildcard. For example 0044* will identify a UK Caller and 004420* will identify a caller from London.

Next, the routing of this call will be selected, to point to the destination.

[SLIDE 5]

The ordering of the rules is very important in 3CX. If the rules are ordered incorrectly, the incoming call will be routed to the wrong destination.

The inbound rules are ordered per trunk. The inbound rules for one trunk will not overlap with the inbound rules of another trunk.

The rules are processed, on a per trunk basis, in a top down fashion. When the PBX matches a number to a rule, it will process the call and ignore any subsequent rules.

We can see an example scenario below.

An incoming call is coming from 00442033272020 to 00498922061592. The first number is the Caller ID of the person calling, and the 2nd number is a DID on the PBX.

With the first scenario, the call will go to the inbound rule defined as a DID rule for the number *061592, irrespective that the call is coming from a UK number. The match has already been made by the DID Number.

If we want to have calls from the UK to be treated differently, the Caller ID inbound rule will need to be brought to the top of the list. In the second scenario the call will follow the routing defined by the Caller ID rule.

[SLIDE 6]

The PBX can modify the format of the Caller ID coming in through a SIP Trunk.

This modification is performed based on some 3CX specific Regular Expressions.

The PBX will identify a Source Pattern and then reformat, or replace the number based on a Replace Pattern.

Some providers, in addition to the Caller ID Number, may also send a Caller ID Name. This may be the same as the Caller ID number or may even be text, for example, the company name. The PBX will not reformat this Caller ID name, but will only modify the Caller ID Number.

More information can be found at our Caller ID Reformatting technical document found on our website. (https://www.3cx.com/docs/cid-reformatting)

[SLIDE 7]

The Caller ID reformatting is very helpful in some scenarios where a provider may send the Caller ID in an inconvenient format, for example it is sent as a non dialable number, and the number cannot be used by a user when trying to redial this number, or call a person back.

An example scenario is like the one presented here.

A call comes in from the UK. The provider sends the Caller ID Number as 442033272020. The extension misses the call. When the user attempts to call this number back, the PBX will not be in a position to recognise the number when it is dialled in this format.

Some PBXs may also have different providers which will send the caller ID in different formats, making it difficult for the users to manage dialing numbers.

A provider may send the number in the format shown on screen here, but another provider on the same PBX may show the same number with a leading + sign.

A solution is to modify the numbers starting with 44, adding a 00 to the beginning of the number and then routing the call through to its destination.

[SLIDE 8]

The reformatting of the number is done from within the SIP Trunk configuration. In the configuration of the SIP Trunk, go to the “Caller ID” tab.

In the “Inbound” section, click “Add”. The editing box is then shown, which will allow you to configure the reformatting of the Caller ID.

[SLIDE 9]

The source pattern is structured in the following way.

A simple dot will represent a single digit.

Two dots will represent two digits and so on. So, if you want to have an eight digit number represented, you would write this down as eight dots.

A dot followed by a star will represent the rest of the digits. This is used at the end of an expression to specify any numbers following. Nothing can follow the * sign at the end.

You can also identify specific digits, from 0-9. A plus sign in the number can also be represented.

Any characters of the source pattern can be isolated as variables by enclosing them within a set of parentheses. These variables can then be used in the Replace Pattern.

For example, to identify numbers coming from the UK, the source pattern would start with the known country code, for example, 44 which comes from our scenario mentioned a couple of slides ago. It would then be followed by any number.

So our source pattern would become 44(.*)

[SLIDE 10]

The Replace Pattern is used to modify the number after it has been identified by the Source Pattern.

The number will be re-written with numbers and/or a plus sign at the beginning of the number.

A backslash will then be used to add a value of a variable defined in the source pattern. Each subsequent variable will be addressed by a single digit number. The first, leftmost variable will be variable number 1, the second variable to the right will be variable number 2, and so on.

Taking our sample number from our scenario, we can apply the source pattern of 44(.*), meaning all numbers starting with 44 and replace it with 44\1. This will in effect give you the same number.

We could also add the number 44 as a variable and add it in parentheses, followed by dot star, also in parentheses.

The replace pattern in this scenario could be +44\2. This will give you the number +44 followed by whatever is in the 2nd variable, in this case the resulting number would be +442033272020. An alternative answer would be +\1\2

This would give the same number as a result, but you can see that is it possible to have different source and replace patterns, to achieve the same result.

If we add the source pattern (44)20(.*), where we basically add the country code 44 as a variable and the area code 20 as a fixed number followed by the local number as the rest of the numbers, we could replace the number with the replace pattern \2. This would result in the number 33272020. Please note that this is a local number.

[SLIDE 11]

Let's have a look at some examples to test your knowledge of what you have learnt in this module.

We want to reformat the number starting with 44 to international format. So from 442033272020 we want to reformat the number to 00442033272020, by adding a 00 at the beginning of the number.

Secondly, we want to convert an international number to local format. So from 00442033272020 we want to convert the number to 33272020, how would the re-formatting be done?

Feel free to pause this video and try this exercise, before moving on to the next slide to see the answer.

[SLIDE 12]

Our source pattern for the first example is 44(.*). The .* as it is placed in parentheses will be the first variable. So the Replace Pattern is 0044\1.

The 2nd example will have a source pattern of (0044)(20)(.*). The 0044 will be variable number 1. (20) will be variable number 2. (.*) will be variable number 3. Our replacement pattern will only need to be \3 to only show the local number, without the international dial code, or the London area code.

[SLIDE 13]

For this module’s demonstration, we will create an inbound rule, based on the caller ID of an incoming caller. We will then proceed to modify the incoming caller ID of this incoming caller.

4-Configuring Outbound Routing

https://www.youtube.com/watch?v=BNQBOTarSvU&list=PL6sq0_ucoDuk4oiBicc1b8ls3zVNAXfIw&index=5&t=0s

[SLIDE 1]

Welcome to the online training series of 3CX. In this module, we will expand on the Outbound Rules, which we covered briefly in the Basic SIP Trunks module.

[SLIDE 2]

In this module, we will see the different criteria that are used in the outbound rules, and how they match an outgoing call.

We will see how the Outbound rules can be used to block outgoing calls from certain user extensions.

We will see how the system extensions can be configured in the Outbound Rules to make outgoing calls.

And finally, least cost routing will take up the last part of this module, and we will see how the outbound rules can be configured to take advantage of this cost saving measure.

[SLIDE 3]

For the purposes of this module, we are assuming that a SIP trunk is already configured in 3CX and that some basic knowledge of the Outbound rules is available.

[SLIDE 4]

There are 4 different outbound rule criteria which are used to configure the outbound rules.

First is the prefix. This is what the dialled number starts with. There is no wildcard available for the outbound rule prefix.

Next is the “Calls from extension(s)” criterion, which will limit the rule for a specific extension or a number of extensions. This is where the call originates from.

The dialled number length can then be configured, to limit the rule to a particular dialed number length. For example the rule may only be valid for 8 digit numbers, which may signify a local call for example.

In addition to the calls from extensions field above you also have a choice of Extension Groups. In some cases, it may be tedious to remember which extensions belong to which department, so you can use the Extension Groups as an outgoing call routing group as well.

[SLIDE 5]

The Outbound Rules of 3CX are checked in a top down manner, always starting at the top and working down the list.

When a match is made, it will process the call with the matching rule, and will not check the next rule, or any other subsequent rules.

If there are no criteria in the Outbound Rule, this rule will be ignored and the PBX will proceed on to the next rule. Having your criteria blank does not mean that “All Calls” will be processed. On the contrary this rule will be redundant.

The criteria fields of the Outbound Rules can accept single values. For example, a single extension.

Comma separated values can also be added, to have multiple values, for example 100,102 to have both extensions 100 and 102 as values.

You can also use the dash, or minus sign to signify a range of values. For example 100-105 will take extensions 100 to 105 inclusive.

Combinations of the above are also possible. For example 102,105-117,302 will take extensions 102 and 302 as well as the range of extensions 105 till 117.

[SLIDE 6]

In order for a call to be processed, the rule will need to match the criteria. The match will be the prefix and the number length and either an extension number or extension group.

This can be scripted or coded in the following format, as shown.

[SLIDE 7]

Once the criteria have been met, the PBX will then proceed to process the call.

Further processing will now be based on the dialled number.

The PBX has the capability to reformat the outgoing dialled number, before sending it to the provider.

It will begin by stripping any digits from the the beginning of the number. When selecting the value of digits to strip, you are selecting how many digits to take away from the beginning of the dialed number.

After the stripping of the digits has been performed, the PBX will prepend any digits you require at the beginning. Please note that you will not be choosing how many digits to prepend, but you will need to choose which digits to prepend in this particular case.

The PBX will provide you with 5 outgoing routes. These are 5 different possible routings the call will be able to go out from.

The PBX will check these in numerical order. If the first route fails for any reason, whether the provider defined in this route is busy or unavailable, the call will move to the next route. A provider being busy may mean that there are no available channels on that trunk to service the call or the provider returns an error message to the PBX. Being unavailable will mean that the PBX cannot reach the provider for any reason.

A call will fail when all the set routes fail or you have defined this particular rule as a blocking rule, with all routes set to “BLOCK CALL”. Once the PBX Hits a “BLOCK CALL” route, it will stop trying to further process the call.

[SLIDE 8]

In addition to configuring your outbound rules to allow calls, and to choose which trunk the particular call will go out from, you can also use the outbound rules to block calls to particular destinations, or from specific extensions.

The configuration is the same as any other outbound rule, but the 5 routes are now set to block the calls.

Again, reminding you that the ordering of the rules is very important and that once the criteria have been met, the PBX will not move on to the next rule, to find a better match.

[SLIDE 9]

Outgoing calls do not necessarily need to be from a user extension. Sometimes outgoing calls are made from the PBX System Extensions.

There is a feature in the voicemail system, which allows outgoing calls to be made, from within the PBX Voicemail system. After authenticating to the voicemail system, entering the options of voicemail will give you an option to dial a number. This is disabled by default for security reasons. If enabled, the PBX is in a position to place calls from within the voicemail menu.

When making audio conference calls, the PBX will be able to make the outgoing calls to the external participants, at the time of the scheduled conference.

Sometimes when a call is being processed by the PBX, the call will need to be forwarded to an outside number. For example, when there is an extension exception in the forwarding rules which forwards to an outside number. Or, if the destination if no answer in a call queue or ring group is set to go to an external destination.

A call to an external destination, does not necessarily need to pass through a queue or ring group, but may be defined in an inbound rule to forward immediately and directly to an external number.

When using Call Queues, the Queue Callback feature will need to place calls to an external location.

These will all need to be configured in the outbound rules to allow calls to the external locations defined.

[SLIDE 10]

The system extensions of the PBX are not user extensions. They do not have a phone provisioned on them and they are not part of any extension group in the PBX.

Outbound calls from system extensions will fail when you have extension criteria and/or extension group criteria defined. The PBX will look for rules which do not have extension based restrictions defined in order to process the call.

The solution is the following. Order your rules so any extension specific rules are at the top of the list. Insert a blocking outbound rule for all user extensions or the extension groups underneath the extension rules.

Underneath this catch all blocking rule, add the rule or rules without extension or extension group restrictions so the system extensions can place the calls, unrestricted.

[SLIDE 11]

The example shown here will allow user extensions to perform the calls to destinations they are allowed to make calls to. In the blue box, there is a rule which will block any other calls, originating from the extensions, from going out. Then in the orange section, the system extensions are allowed to go out, to specific destinations, with only the dialled number prefix being the restriction available for these extension less calls.

[SLIDE 12]

When making a call, the least cost that can be incurred is zero. It is always desired, when making an outgoing call that given the circumstances, that the least cost will be incurred in any outgoing call.

The PBX can be programmed to minimise the cost of outgoing calls.

This is achieved using the outbound rules and determining which trunk is cheapest for each destination. An outgoing rule can then be created for each costing route, in order to take advantage of lower rates through a particular provider.

It is very important in this particular case to notice the ordering of the rules as well as the order of the Providers in the 5 outgoing routes.

[SLIDE 13]

An example scenario would be the following:

Use a PSTN Gateway to process local landline calls. The local Telco may provide cheaper calls to the local networks.

Use a GSM Gateway to make calls to local mobile numbers. You may have a few SIM cards from the local mobile provider with unlimited calls to either their own or all networks.

A VoIP Provider may be used for long distance national and/or International calls.

A Bridge may be used to call extensions on a remote PBX, or use any resources connected to this PBX, for example gateways and/or VoIP Providers.

[SLIDE 14]

An example of the dialled number formatting for the UK is as follows.

For local calls within London, the number can start with any number from 1-9.

Long distance calls from London to other parts of the UK, like Manchester will start with 0 followed by the area code of the area you wish to dial.

Calling internationally, from London to Spain for example will have the number starting with 00 and followed by the country code, which in this case would be 34.

Calls over a bridge may sometimes need a prefix to be defined, in order to identify that it is a call that needs go over a bridge. In this particular case, calling to a remote bridged extension of 153 may require a prefix, for example 6 followed by the extension number. The Bridges module covers the configuration of bridges in more detail.

[SLIDE 15]

Configuring the rule for local calls is very simple.

The outbound rule name will need to be descriptive, to indicate that this is for local calls. Please note that this will not affect the capability of the PBX to process calls, it is just very helpful when administering the PBX and eases troubleshooting.

The prefix will need to be 1-9. The first route will then be defined as the PSTN gateway.

[SLIDE 16]

You can also define a local number in long distance format, in case someone accidentally dials the number in its entirety, or has a local number stored in a phonebook, in the long distance format.

In this case you would add the number prefix as 020 and route the call through the PSTN gateway, after stripping away the 3 digits used for the London area code.

[SLIDE 17]

Likewise, you can also add a rule for the local numbers dialled in international format. The prefix would now be 004420 and routed through the PSTN Gateway after stripping away the 6 digits of the international country code of the UK and area code of London.

[SLIDE 18]

The rule to match the calls to mobile numbers would be configured with a prefix of 07.

The call would then be routed through the GSM Gateway which will process the calls at a lower cost than if they were processed through the PSTN Gateway.

The PSTN Gateway could then be used as a backup route, if the GSM gateway is busy or unavailable to process the call.

[SLIDE 19]

For long distance calls, the outbound rule will need a prefix of 0. The routing would be via the PSTN gateway for Route 1 and the VoIP Provider will be defined as Route 2. This is to provide capacity in case the PSTN Gateway does not have enough channels, or is not available.

[SLIDE 20]

To make international calls, the prefix would need to be 00 and the routing would need to go through the VoIP Provider.

[SLIDE 21]

The order in which the rules are listed is very very important. There is a possibility that the rules will need to be reordered in order for the calls to be routed correctly.

For example, our intention in the following example is to have the international calls routed through the VoIP Provider.

From the rules shown here, we can see that when an extension dials 00, it will match the rule starting with a prefix of 0, which will route the calls through the PSTN Gateway and consequently, through the local telco which may have higher rates than the VoIP Provider.

Therefore our rules are ordered incorrectly.

[SLIDE 22]

Fortunately it is very easy to resolve this. All that is required is to select the rule for the international calls and press the “Move Up” button and move the rule above the local calls rule.

This will result in calls starting with a prefix of 00 going through the VoIP Provider instead of the PSTN gateway.

[SLIDE 23]

Calls through the Bridge, to bridged extensions are also configured through the outbound rules of the PBX.

You will need to have a prefix to signal the PBX to send the calls through the Bridge. In this case we will use the prefix of 6. If your remote PBX is using a 3 digit extension numbering scheme, you will define the length of the called numbers to 4. That is the prefix and the extension number.

The call will be routed through the Bridge connection, but in this case, you will strip the 1st digit, the 6 in this case so only the 3 digit extension number is sent to the remote PBX.

Sometimes, the extra prefix is not required, if the extension range being dialled on the remote PBX does not overlap with the extensions on the local PBX.

[SLIDE 24]

Calls through the Bridge, through remotely connected resources is also possible. In the example here, we can send calls destined for Germany, to go through the Bridge to a PBX we have in Germany and then be used to process the call using its own outbound rules.

The rule prefix to match calls to Germany would be 0049 or +49

The call will then be routed through the Bridge to the German Office. The 4 digit international dialling prefix and international dial code for Germany will be stripped from the number. If you are using +49 you would strip 3 digits only.

In order to process the number locally the provider would need a 0 in front of the dialled number, so we will prepend this to the number before sending it through the Bridge. The remote bridge would then use its outbound rules to process the call as a local call.

We can also send the call through the VoIP Provider as the 2nd route, but this call will be processed without any modification to the number.

[SLIDE 25]

For the demonstration of this module, we will send a call from an extension on one PBX, through a provider which is configured on another PBX, through the bridge.

5-Bridge Configuration

https://www.youtube.com/watch?v=5Oua1GXyjlk&list=PL6sq0_ucoDuk4oiBicc1b8ls3zVNAXfIw&index=6&t=0s

[SLIDE 1]

Welcome to the online training series of 3CX. This module will take you through the configuration of Bridges in 3CX.

[SLIDE 2]

In this module, we will create a bridge between two 3CX PBXs. We will be configuring both the Master and Slave Bridges, using the Tunnel protocol.

We will see how the Bridge is used to make calls between extensions. We will see how a meshed setup is configured, to connect more than 2 PBXs together, and we will see how the presence information is shared between the PBXs across the Bridge.

[SLIDE 3]

Bridges traditionally connect two pieces of land. In 3CX, a Bridge will connect two remote PBXs.

A traditional bridge will have its two ends defined as geographical points, such as North/South, East/West. A 3CX Bridge will have its ends defined as Master and Slave.

A 3CX Bridge can also pass the traffic between the 2 PBXs via the tunnel protocol. This is referred to as a Tunneled Bridge.

Connecting 2 or more 3CX Systems together via bridges requires at least a PRO edition license.

[SLIDE 4]

The Master Bridge will control the connection between the 2 PBXs. It will listen for incoming connections from the Slave Bridge. If the connection is tunneled, it will listen on the PBX Tunnel Port, which by default, is 5090.

[SLIDE 5]

Creating a bridge in 3CX is very simple. From the “Bridges” page in the Advanced menu on the left hand side, click the “Add” button, and select “Add Master” from the drop down box.

[SLIDE 6]

The configuration page will ask for the Bridge name. This will be used to identify the Bridge in the Outbound Rules, as well as show the remote bridge name in the 3CX Windows App and Web Client presence screens, to show the presence between the bridged PBXs.

The Virtual Extension Number will be used during the authentication process of the connection, when the Slave PBX will be connecting to the Master PBX, so it is important that the Virtual extension number is identical on both the PBXs on both ends of the bridge. A common free virtual extension number will need to be assigned to both ends of the bridge.

The Outbound Rule prefix is added to the bridge settings in order to facilitate the placement of calls from one PBX to another. This can be left blank, depending on your setup, for example if you have extension numbers in different ranges, on each PBX. This can also be the case when the 2 PBXs are using a different extension digit length.

You can limit the number of calls going through the bridge, by defining the maximum number of calls.

The number of calls placed through the bridge will count towards the licenses of both PBXs.

[SLIDE 7]

The authentication of the bridge consists of the password, that the Slave will use to connect onto the Master. The bridge password can be changed, but if you do change it, please keep the password complex.

If the 3CX Tunnel protocol is going to be used to pass the traffic from one PBX to the other, check the “Remote PBX uses SBC/Tunnel Connection” option. The Remote PBX IP Address and Tunnel Port will need to be defined in the fields below.

[SLIDE 8]

The Slave Bridge PBX will be the PBX which initiates the registration attempts to the Master Bridge PBX. When the connection is tunneled, it will use the tunnel port to pass this traffic to the Master Bridge PBX. By default this port is 5090.

[SLIDE 9]

Similar to the creation of the Master Bridge PBX, the creation of a Slave Bridge PBX is very simple. When you click on “Add” however, choose “Add Slave”.

[SLIDE 10]

The configuration of the slave bridge parameters will be mainly identical to the Master PBX.

The Bridge Name however will be slightly different to reflect the name of the PBX which you will be connecting to.

The Virtual extension number will need to be identical to the Master PBX.

The outbound rule prefix is optional and can be added depending on the configuration of the extension numbers, just like in the Master Bridge PBX. This can also be left blank depending on your setup and if you have no overlapping extension number ranges, or different extension digit lengths.

The number of calls allowed to traverse the bridge will also be defined on the Slave PBX as well. Please note that if you have different numbers of calls allowed on the 2 bridges, the lower number will take effect. Calls traversing the bridge will also count towards your license usage on both PBXs.

[SLIDE 11]

In the Authentication section, you will need to copy the password from the Master Bridge PBX. This password will be used to authenticate the slave to the master.

If you are using the tunnel protocol to connect the two PBXs together, enter the IP Address of the master PBX and its tunnel port, in the “Remote PBX” section.

The time between registration attempts shows the time in seconds that the Slave Bridge PBX will send a new REGISTER attempt to the Master Bridge PBX.

[SLIDE 12]

You can easily check the connectivity status of the bridge from both the PBXs, by going to the “Bridges” page in the Advanced menu. A green dot next to the name of the remote PBX indicates an established connection. Red means the bridge is disconnected.

[SLIDE 13]

When the bridge connection has been established, the presence information between the 2 PBXs can be exchanged.

There is the option to “Publish” or send the presence information from the local PBX. Extension Group information will be sent across to the bridged PBX.

The option to “Receive” the presence information from the remote bridge PBX is also available, and is configurable. Here, you choose which specific extensions will have the right to see the presence information for this connection, from the remote PBX, not entire extension groups.

The presence information for remote PBXs can only be viewed from 3CX apps as well as the 3CX Web client. Call status and presence information is not transmitted through the BLF keys of IP Phones. IP Phones can only see the call status of local extensions.

[SLIDE 14]

The configuration of the presence is performed from the “Presence” tab of the bridge configuration.

In the “Publish Information” section, you will Add the Extension Groups you wish to publish the presence information for.

[SLIDE 15]

To receive the presence information from the remote PBX go to the “Receive Information” section, and define the FQDN and HTTPS port of the remote PBX, to receive the presence. Please have in mind that the presence information will not traverse the bridge connection but will be flowing through the normal HTTPS route.

To receive the presence, you will then add the local individual extensions which you want to receive presence information. You can control the number of extensions which can receive the presence. The viewing of presence information does not count towards the license count of the PBX.

[SLIDE 16]

Each remote system which is bridged to the local PBX will be shown in the presence screens of the 3CX apps and Web Client, as a different header in the 3CX App, or the People tab in the 3CX Web Client, and it is possible to see the presence of multiple bridged PBXs and Extension Groups.

[SLIDE 17]

Let's go and see an example of a bridge configuration.

Let us assume that prior to the configuration of the bridge, the administrator had in mind that there was a plan to connect two sites together and had a numbering plan put into effect.

The Master Bridge PBX is configured with 4 digit extensions in the 1000 range. The Slave Bridge PBX is configured with 4 digit extensions in the 2000 range.

The outbound rule required in the Master bridge to connect to the slave bridge would be just a prefix of 2, representing the first digit of the 2000 range of extensions. In order to differentiate between the 4 digit extensions of the bridge, and any other external number starting with 2, we add the number length of 4 to the outbound rule.

Similarly, in the slave PBX, we would have the prefix of 1 in the Outbound Rule, with a digit length of 4, to represent the 1000 range of extensions.

With this type of setup, no outbound rule prefix is required in the Bridge Settings.

[SLIDE 18]

On the other hand, if both your PBXs have the same extension range, that is in the 1000 range for example, the outbound rules on both the PBXs will be similar to this scenario.

A prefix would be required in this case, for example 9. This could be any number. The number 9 was just used as an example.

A digit length of 5 would be required in this case, as the prefix will be detected as a digit. We will need to strip this prefix, however, as the remote PBX will not be in a position to recognise the prefix as part of a valid extension number.

In the outbound rule prefix in the bridge settings, a 9 would be required, assuming you have used 9 as the prefix. This will show the remote PBX extensions with the prefix, to differentiate the other extensions from the local PBX extensions.

[SLIDE 19]

Let’s have a look at a configuration of a fully meshed setup with 3 PBXs.

We will need to configure each of the connections between the 3 PBXs.

As we can see in this example, PBX A will be the Master Bridge in the connection between PBX A and PBX B.

PBX A will be the Master Bridge for the connection to PBX C as well.

PBX B will be the Master Bridge for the connection to PBX C.

We can see that PBX B is a Master Bridge for one connection, and a Slave Bridge in the other connection. This is entirely feasible and will not cause any problems. A PBX does not need to be a Master or Slave solely, but can be either or.

The numbering plans will be as follows:

PBX A will have extensions in the 1000 range.

PBX B will have extensions in the 2000 range.

PBX C will have extensions in the 3000 range.

Just a note that the PBXs do not need to have the same extension digit length, to be bridged together.

[SLIDE 20]

The calls will be sent from one PBX to the other via the Outbound Rules.

We will configure an outbound rule for each PBX to contact its connected bridge PBX.

We will have a total of 6 outbound rules in this case.

PBX A will have an outbound rule to connect to PBX B, by defining a prefix of 2 and a length of 4 digits. No digits will be stripped in this case.

PBX A will also have an outbound rule to connect to PBX C, by defining a prefix of 3 and a length of 4 digits. No digits will be stripped in this case, neither.

PBX B will have an outbound rule to connect to PBX A, by defining a prefix of 1 and a length of 4 digits. No digits will be stripped in this case.

PBX B will also have an outbound rule to connect to PBX C, by defining a prefix of 3 and a length of 4 digits. No digits will be stripped in this case, neither.

PBX C will have an outbound rule to connect to PBX A, by defining a prefix of 1 and a length of 4 digits. No digits will be stripped in this case.

PBX C will also have an outbound rule to connect to PBX B, by defining a prefix of 2 and a length of 4 digits. No digits will be stripped in this case, neither.

You can also define a backup route to send the calls to PBX B through PBX A. All you need to do is define PBX A as Route 2.

[SLIDE 21]

With the 3CX Web Client, you are able to see the presence of remote extensions, if you have been given the access to do so.

By using the 3CX Web Client, you will be able to perform a variety of functions to interact with the extension as well.

[SLIDE 22]

With the 3CX Web Client, you are able to see the presence of remote extensions, if you have been given the access to do so.

By using the 3CX Web Client, you will be able to perform a variety of functions to interact with the extension as well.

6-Security and Anti-Fraud

https://www.youtube.com/watch?v=bFBk7crm5Ic&feature=youtu.be

[SLIDE 1]

Welcome to the online training series of 3CX. This module will take you through the security aspects of 3CX.

[SLIDE 2]

In this module we will see the different vulnerabilities which are out there, and see what countermeasures 3CX has and how they are applied.

We will see the various security options 3CX has, to protect the VoIP resources.

Finishing off, we will talk about how to maximise security with 3CX, and in general.

[SLIDE 3]

3CX protects itself from any fraudulent actions, either based on certain rules, where restrictions may be put into effect, to control who access to certain resources. Or via certain thresholds, where if these are exceeded, the PBX will take actions to prevent further abuse.

[SLIDE 4]

Here we can see some of the more common VoIP attacks, hacks or exploits.

Brute force attacks are attempts to guess their way into your network and PBX. In order to access the PBX, they will need to know the extension number, SIP username and SIP Password. They will try to guess the extension numbers and login credentials

A Denial of Service, or DOS attack is aimed at preventing the rightful owner of a resource from using said resource. This is accomplished by flooding the resource with requests, rendering it unable to service legitimate requests.

Dictionary attacks are attempts to use default passwords or simple word passwords to login to a system.

Password crackers are special software packages aimed to methodically attempt to login to a system using various password combinations

Attacks don't necessarily need to be from the outside, but could be from within the network, where anyone with access to a switch could possibly take a capture from the network, taking in valuable information, for example, the audio traffic.

Man in the middle attacks are also a possibility where an attacker could spoof their identity to fool a system, to think that they are talking to a legitimate peer, while in the meantime, the attacker is copying the information, while relaying this information to the legitimate peer.

[SLIDE 5]

In addition to the possibility of VoIP Attacks, being an internet connected system, 3CX may also be susceptible to HTTP attacks, in the form of man in the middle attacks or attempts to have the management console or RPS system compromised.

[SLIDE 6]

Let’s start with the most common method of security breaches. The authentication credentials of the SIP Endpoints.

This is the most common form of breach, as admins may define easy, common, or predictable passwords.

By default 3CX will create a random alphanumeric Username or SIP ID, and SIP Password. These could be in uppercase and lowercase characters as well. The default length of the username and password is 10 characters.

Security can be further enhanced by increasing the character length to a maximum of 50 characters.

[SLIDE 7]

The voicemail system is enabled by default on the extensions and the PIN authentication is enabled and, by default, a 4 digit random numeric PIN. This can be increased to 10 characters, to make it more difficult to guess. After 3 failed attempts to log in to the voicemail system, access will be blocked for a period of 2 minutes.

If not needed, the voicemail functionality can be disabled for an extension, to prevent abuse of the system, as voicemail can, if configured, be used for making outgoing calls to the PSTN.

[SLIDE 8]

3CX provides various rules sets and thresholds to control and secure its environment.

We will look at these now, and see how the PBX can be configured to protect itself, and its users from malicious attacks and activities.

[SLIDE 9]

In addition to the outbound rules, which can restrict who is allowed to make calls, the allowed country codes are a nice feature, where the PBX can limit to which countries, it is able to make outgoing calls to.

It will use the E164 settings of the PBX to match the international dial code of the country it is configured to work in, then it detects the international dialling codes of the countries it is allowed to make calls to.

The dialled number will be matched after being processed, and possibly reformatted by the outbound rule.

[SLIDE 10]

Secure SIP can be used to secure the SIP communications between the configured extension end points. TLS certificates will be needed in this case, to be applied to the PBX and the deskphones.

If you are using a 3CX FQDN and certificate, the Secure SIP configuration will automatically be set up, and enabled in the Security section of the PBX.

If you use your own FQDN and SSL certificate, then, you will need to enable Secure SIP in 3CX and enter your certificate and certificate key into the management console.

The IP Phones will need to be configured to communicate over TCP port 5061, which is the default secure SIP port. Provisioning via Secure SIP is currently done manually, but automatic Secure SIP provisioning is expected to be available in a future service pack.

To secure the communications between the PBX and any 3CX Apps for Windows, you will need to go to the extension’s “Phone Provisioning” tab, choose the 3CX App SIP Transport mode to be TLS.

[SLIDE 11]

In addition to the SIP traffic, the audio stream between the configured extensions can also be secured.

Secure RTP, or SRTP can be configured from within the IP Phones themselves.

For 3CX Apps for Windows, you will need to change the RTP mode from the Phone provisioning tab of the 3CX App extension to “Only Secure”.

[SLIDE 12]

Moving on to the Anti-hacking module of 3CX which defines the thresholds the PBX will adhere to, in order to protect itself.

The first parameter is the failed authentication attempts, which will define how many failed requests the PBX will accept from a particular IP before placing it into the blacklist. By default this is 25, but can be increased or decreased according to the network load. Just don't reduce it too much, so as not to blacklist even legitimate traffic.

[SLIDE 13]

When a host tries to register on to the PBX, the PBX will send it a challenge that needs to be responded to. The PBX will then wait for a response. A bogus host will not respond to these challenges as it will try to flood the PBX with requests. The PBX will then subsequently ignore any bogus Register attempts from a particular IP if it exceeds 1000 by default.

You can further secure the PBX by decreasing the number to a recommended minimum of 100.

[SLIDE 14]

Let's also have a look at the various security barriers of the PBX. These are designed to protect the PBX against packet floods.

When the PBX detects a packet coming in from a particular IP Address, it will start taking a sampling for the duration of the Green security barrier. By default this is 200 ms.

Depending on the number of packets received within that sampling period, the PBX will take the necessary action.

It will throttle the traffic from this IP Address for 5 seconds, if the amount of received packets exceeds what is defined in the Amber Security barrier configuration but is below the Red Security barrier level.

If the number of packet received within the sampling period exceed what is defined in the Red Security barrier, then the PBX will place this IP Address into the blacklist, for the defined blacklist interval.

[SLIDE 15]

The blacklist time interval, by default is 86400 seconds, or 24 hours.

This can be raised to a maximum value of 1 billion seconds, which is about 11574 days, or 31.7 years. That will give the admin plenty of time to investigate and take action. In the meantime, the PBX will be ignoring requests from this IP Address.

[SLIDE 16]

The IP blacklist will be populated when the Anti Hacking criteria have been met and any IPs added here, will remain for the duration of the Global Blacklist time interval.

In addition to automatically populating the IP Blacklist, you can also add IPs or IP ranges manually. When adding IP Ranges, this will be based on network addresses and subnets.

You may also use the IP Blacklist to add IPs that will not be blacklisted, no matter what requests they may be sending. You will need to set the action to Allow, in order for this to take effect.

It is also possible to import or export IPs and IP Ranges if you wish to replicate this list to other PBXs, or from other PBXs.

[SLIDE 17]

In addition to the import and export functionality of the Blacklist, 3CX also maintains and distributes a global blacklist which can be used by your PBX as well. This will gather malicious IPs or IP Ranges based on certain algorithms, and when a particular IP or range is added to this list, it will be distributed to each of the PBXs which have this option enabled.

[SLIDE 18]

While it is recommended to whitelist your trusted static IPs, and we do stress the fact that these will need to be static, don't whitelist IPs blindly, as the whitelisted IPs are exempt from all anti-hacking filters.

Also, while it is a good practice to place malicious IPs into the blacklist, avoid blacklisting large IP ranges. It would be preferred to placed these into the Access Control List of the firewall, so that this malicious traffic is not even entering your network.

[SLIDE 19]

The Management Console login screen will be exposed to the internet, as it works on the same port as the web provisioning ports of the PBX.

An IP address will be blacklisted if the authentication has failed after 3 attempts. The anti-hacking parameter for failed authentications will not be used in this case.

If the administrator enters the admin username/password incorrectly, the forgot password prompt will show after the 2nd failed login attempt. This will send the admin login password to the first specified admin email address. This link will only be shown when the password is entered incorrectly for the ADMIN account, not any other account.

Logging in from the local host will not blacklist the IP as it is always exempt.

As with all passwords, not just with 3CX, it is recommended to change passwords regularly, and keep them complex.

It is also possible to restrict access from certain IPs or IP ranges. By default the local LAN IP ranges as defined by RFC 1918 are allowed by default.

[SLIDE 20]

When a remote extension attempts to log in from the internet, the PBX will request a Username and Password. This will be matched with the MAC address of the configured extension and if all 3 authentication parameters match, the PBX will allow the extension to be configured.

This will also be subjected to a 3 attempt limit before being blacklisted, for the duration of the global blacklist interval.

A phone will also be blacklisted if the security restriction “Disallow use of the extension outside the LAN” is kept active.

[SLIDE 21]

The 3CX Certificates issued by Let’s Encrypt are trusted certificates and therefore on your browser you will see that a secure connection is established.

Avoid using self signed certificates. 3CX certificates are provided at no additional cost, so self signed certificates are no longer required.

If you opt to use your own SSL certificates, ensure that they are trusted and that they are supported by the IP Phone manufacturer of your choice.

If the phone manufacturer does not support them, a secure connection will not be possible, and the phones will not download a configuration file from the PBX.

Attempting to connect to a PBX with an invalid certificate will give a warning in your browser alerting to an insecure connection. Any browser warnings should be investigated. It may be a matter of your certificate having just expired, but it is always good to be vigilant.

[SLIDE 22]

Finishing off, let's talk about security in general.

I mentioned earlier that it is recommended to use your firewall’s access control list for filtering malicious traffic into the network. Always attempt to block attacks from as close to the source as possible, possibly even engaging your ISP to filter these from their network as well.

Use the 3CX tunnel to achieve your communications as much as possible and leave communication over the SIP port, solely from your VoIP Providers network. This can even be defined in your firewall as well, thus blocking any malicious scans on the SIP port, especially if this is on 5060.

Therefore all your remote extensions could be through the SBC and your 3CX clients could be coming in through the tunnel port.

Some companies already have VPN infrastructure in place, and if this is the case we do encourage you to use your VPN capabilities. VoIP traffic will not be exposed to the internet and since the 2 networks will be communicating on a private IP basis, this will allow for your remote phones to be provisioned as local extensions.

[SLIDE 23]

For the demonstration of this module, we will show you the various security features of 3CX.

7-Basic Troubleshooting

https://www.youtube.com/watch?v=o8VyfmJQksU&list=PL6sq0_ucoDuk4oiBicc1b8ls3zVNAXfIw&index=8&t=0s

[SLIDE 1]

Welcome to the online training series from 3CX. This module will take you through the Basic Troubleshooting of 3CX, as well as explaining the SIP Protocol.

[SLIDE 2]

There are a variety of tools and resources available to troubleshoot the PBX when an issue arises.

We will see the various bits of information the PBX will provide in order to facilitate the administrator to pinpoint any issue is.

[SLIDE 3]

Let’s start with the PBX dashboard. The Dashboard will provide a quick overview of the current activity and status of the PBX. We will be able to see at a glance whether everything is running the way it should.

From the screenshot shown, you can see that the Firewall Check has not passed and it is shown in red, and we also do not have automatic backups. There is nothing better than a current backup to save you when a disaster happens. Always enable automatic backups. Better to be safe than sorry.

[SLIDE 4]

By default, the PBX will retain minimal logs, in order to conserve CPU power and disk space.

When the services are restarted or the PBX server itself is restarted, the log files will be cleaned to allow you to create a fresh set of logs, when needed.

In order to troubleshoot possible issues with the PBX, the normal logging level of LOW will not be sufficient, and Verbose logs will be needed. By definition, verbose means having more information than what is required, and in this case we will need a lot of information which the PBX is in a position to provide us.

The log files of the PBX are retained in a folder on the server itself.

The various log files kept by the PBX are also available for perusal from the management console in addition to being available from the file system of the server. The “Logs” button in the Activity log gives you access to the logs, directly from the browser, allowing you to download them onto your computer.

[SLIDE 5]

In the Activity Log we are able to see basic SIP Flow messages given by the PBX in relation to phone registrations, interactions with gateways and VoIP Providers as well as information on the calls being processed by the PBX.

These can be filtered based on the date and time an event happened that we would want to troubleshoot.

If we want to filter by extension, this is also possible, and in addition to that, the relevant calls for that extension will only be visible in the Call drop down box. The Call ID is an incremental counter of calls since the PBX or services were last restarted.

[SLIDE 6]

The event log can be found in the dashboard and it provides summarised events pertaining to the registrations of Extensions, providers and gateways. These types of event would be logged as Informational events

There are 3 different levels shown, warnings, errors and informational messages. These can be filtered and shown as separate, individual levels.

Requests sent to the RPS servers of IP Phone providers are also logged here giving an indication if the requests is successful or not. These are informational messages if successful, and warnings if unsuccessful.

IPs being blacklisted are also logged here. These would be logged as Errors.

An example of other Warning events would be SLA time breaches in the queues, as well as abandoned queue calls.

[SLIDE 7]

Emails are the main way that the PBX will inform the admin of the activity in the PBX. In the email notifications settings of the PBX it is possible for more than one admin to be configured. All that is needed is to comma separate the email addresses.

This will require a valid and tested SMTP Server to be defined on the PBX.

[SLIDE 8]

The majority of configuration and troubleshooting of 3CX can be done from within a web browser, but there are some cases where access to the operating system is required.

With the 3CX Linux Edition, this would require an SSH client to establish an SSH connection to the operating system. This was proving a challenge as connecting to the Operating System in Linux is more difficult than on to a windows Operating System.

A connection to the machine is easy to achieve in a Linux environment without the need for an SSH Client. From the dashboard, a button to access the web shell terminal is available. This will give you access to a limited set of functions which may be needed for troubleshooting.

[SLIDE 9]

Another tool in the administrator’s arsenal, to troubleshoot call issues is the inbuilt packet capture utility, which allows an admin to easily take a packet capture on the PBX, right from within the Management Console.

You will need to have wireshark installed on a Windows machine to have the necessary prerequisites to run the packet capture. In a Linux environment, this is not needed as all the necessary packages are installed upon installation of 3CX.

Choose the relevant interface, or choose to capture on all the interfaces if the server has more than one interface, just click Capture to start capturing network traffic on the PBX interface or interfaces.

When the capture is stopped, a download link will be provided to download the capture directly, as well as a link to create the 3CX Support information, which will also include the capture in the log files. The support info file will be sent via email to the admin.

[SLIDE 10]

Using the capture taken from the management console, we can use Wireshark to decode the capture and perform a SIP flow debugging. This is very easy in Wireshark, as VoIP calls can be isolated and analysed in a clear, easy to read format.

All we need to do is select the relevant call legs we want to analyse and click Flow Sequence.

The selected call legs will now be represented in a graphical form, making it easy to see the flow of the call from beginning to end. Selecting a particular packet on the Call Flow screen will take you to the raw packet data in wireshark as well.

[SLIDE 11]

As the packet capture is done from the server’s network interface, any audio traffic traversing the interface will also be captured.

You will be able to see the different audio streams coming from the SIP endpoints, allowing you to determine where problematic audio is originating from, if you are facing audio issues.

Any timing issues on the packets coming in and leaving the PBX will also be shown in the audio streams.

We will need to select the call legs and click Play Streams.

Ideally 4 audio streams will be seen in a call between 2 SIP endpoints, when the audio is proxied by the PBX. One for each of the streams from the PBX to the end points and one each from the end points to the PBX.

[SLIDE 12]

Let’s have a look at some of the information we can see in Wireshark.

The SIP Protocol, which 3CX uses to make and receive calls, basically consists of requests and responses. The request messages are simple words, like we can see on the slide right now.

To Register a SIP Endpoint on the PBX, the word used is REGISTER.

To begin a call, an INVITE will be sent, basically inviting another endpoint into a conversation.

A BYE request is used to terminate an active call, just like saying goodbye to someone.

CANCEL is used to terminate a call which has not been answered yet. You are basically cancelling the INVITE.

ACK is used to acknowledge an action, a request and response pair.

When you configure a BLF key, a SUBSCRIBE is used to enable this button and request statistics.

When the status of the BLF changes, a NOTIFY will be used to instruct the BLF to show the new status.

REFER is used when a call is transferred from one SIP Endpoint to another.

[SLIDE 13]

The words used by the SIP Protocol of which we saw a few examples in the previous slide, are requests. They will receive responses in the form of a numbered code, and usually followed by a word. The way the word is presented is usually up to the vendor to send.

Response codes in the 100 range are provisional and are usually followed by another provisional code or a final code. An example would be 180 Ringing, indicating that the end point is in the ringing phase.

Response codes in the 200 range are Final messages and indicate a successful response to the request.

Response codes in the 300 range are Final message and indicate a redirection. For example 302 Moved Temporarily. This indicates that the endpoint is not found at the requested location, but can be found at the defined location.

Response codes in the 400 range indicate a local failure, for example when authentication is not possible, as in the case of 401 Unauthorized. 404 Not Found is a common error, when an endpoint is not contactable.

Response codes in the 500 range indicate an internal error, for example a service being unavailable, and this would give a 503 Service Unavailable message.

Response codes in the 600 range are final as well, and indicate a global failure. This would be given when a device is totally uncontactable or the endpoint refuses to communicate, as would be the case with 603 Decline.

[SLIDE 14]

This is a sample call flow of a REGISTER request coming from an endpoint.

The SIP endpoint, in this case an IP Phone, will try to REGISTER on to the PBX. The endpoint sends the REGISTER request. The PBX responds with a 407 Proxy Authentication Required. It is basically telling the phone to authenticate itself.

The phone will resend the REGISTER request with authentication credentials this time.

In the REGISTER message, an Expires header is also sent, indicating the time after which this message will expire and no longer be valid.

[SLIDE 15]

This is a sample call flow of an INVITE request. The INVITE request is sent when a SIP Endpoint wants to engage in a conversation with another SIP Endpoint, namely making a call.

An INVITE request is sent, from the phone to the 3CX server. The 3CX server responds with a 407 Proxy Authentication Required response.

The phone ACKnowledges the request.

A new INVITE is sent, with the authentication credentials.

The PBX will then forward a 100 trying response code, after successful authentication

As it is a provisional message, it is followed by a 180 Ringing, indicating that the endpoint is ringing.

If PBX Delivers Audio, or recordings are enabled, you should also see the RTP traffic flowing to and from the server, if the capture has been performed on the server itself.

The 200 OK message indicates the call has been answered.

The Endpoint ACKnowledges that this has been answered.

When the time comes for the call to be ended, a BYE is sent from the requesting endpoint. A 200 OK message from the PBX will indicate the request is successful.

[SLIDE 16]

This is what an actual INVITE packet looks like.

We will now analyse each of the different headers within this packet.

[SLIDE 17]

Let's start with the FROM header. This indicates where the call is coming from. In our example here we can see the call is originating from SIP extension 100 at the IP Address 192.168.9.59.

We see the TO header is showing the destination as extension 102, at the same IP Address. This indicates that they are connected to the same registrar server. Very similar to email, where you send an email to a colleague, and they are on the same domain.

In order to know where to communicate the call information, the endpoint will send its CONTACT information. Here we can see the real IP of the phone.

[SLIDE 18]

The VIA header is the next header we will see.

Each SIP intermediary a call goes through, whether this is the PBX or a VoIP Provider, will add its own address to the VIA header.

This will allow the return call to go through the same path on the reverse route to find the original calling party.

[SLIDE 19]

The CALL-ID header is a unique identifier which identifies the packets within a specific call leg. All packets which are for a particular call leg will have the same Call-ID.

The CSeq header, or Command Sequence header will link packets within a call leg together.

For example, when the first INVITE is sent, it will have a command sequence number, like 1 in our example. When a packet comes in response to the INVITE, it will also have a CSeq number of 1, to link to that packet.

The User-Agent header, will identify the SIP Endpoint sending the packet.

[SLIDE 20]

The Proxy-Authorization header is used to send the authentication credentials to the SIP Registrar. In the example we can see an INVITE without credentials, and an INVITE with credentials.

[SLIDE 21]

Within the INVITE packet, the media negotiation is also done via the Session Description Protocol.

From here we can see the Connection information, which is similar to the contact header, but here, the IP and PORT the AUDIO will be sent to is defined.

We can also see the codecs which are available and will be negotiated with the destination endpoint. The codecs will be shown as numbers, and each number will correspond to a codec.

Some examples:

0 is PCMU, or G711u

8 is PCMA, or G711a

9 is G722

18 is G729. Protocol 18 also has an extra attribute in this case, indicating it is not an annex B codec, so it will be negotiating a G729a codec call.

Attribute 101 is the DTMF tones.

[SLIDE 22]

When we analyse a capture, we can assign certain filters, to make it easier to identify the packets we want to analyse. For example, typing “sip” into the filter field, will isolate and show all the sip packets in the capture.

[SLIDE 23]

Going a bit deeper now, let's go and isolate all the INVITE packets. By typing sip.Method==INVITE, only the INVITE packets are shown in the wireshark interface.

[SLIDE 24]

By typing sip.CSeq.method==INVITE, we will isolate and see all packets which are linked to an INVITE Packet. How are they linked? Using the CSeq header in the packets.

[SLIDE 25]

We can assign a variety of CSeq Method filters to link the packets of various REQUESTS, like INVITE, SUBSCRIBE, REGISTER and NOTIFY.

This makes it easy to see the packets linked to an event, for example the making of a call with the INVITE.

[SLIDE 26]

Sometimes we want to identify the packets which are in a particular call leg. We can use the CALL-ID as a filter in this case. Now, if we go to an INVITE packet and right click the CALL-ID, we can choose to apply this as a filter, and it will apply the filter directly into wireshark allowing us to isolate the packets for this particular call leg.

[SLIDE 27]

It isn't always easy to troubleshoot an issue on your own, and sometimes it is necessary to bring in the big guns to assist.

However, before asking for assistance, we would recommend looking at our online documentation, which contains a wealth of information concerning all aspects of the configuration of 3CX.

This ranges from the configuration guides for each model of the supported phones, gateways as well as the prerequisites of the PBX in detail.

Occasionally, when we release a new feature, or when we see that some people are having difficulty with a certain feature, we publish a technical document which will clarify things up for people.

[SLIDE 28]

Now, after you’ve done your research and done your best, you may still be facing difficulty configuring or troubleshooting an issue.

This is where you call in the cavalry, and bring in the big guns, namely, 3CX Technical Support.

Our Technical Support team is on hand to provide assistance to our active partners, who are our first line of defence in troubleshooting issues for our customers. Support is also provided to inactive partners and end users, upon purchasing of a support ticket.

Support can be provided for all the supported equipment, which is defined on our technical support website, www.3cx.com/support, as well as supported SIP Trunks.

3CX branded products have support for the latest version as well as the immediate previous version. Currently, versions 15.5 and 16 are supported.

Support is also provided for the 3CX Apps as well as 3CX Webmeeting.

3CX Technical Support can be engaged in one of two ways, either by telephone for our active partners, which is convenient for receiving advice, guidance or clarification of certain issues.

The option to open a ticket, which is the preferred method when the sending of information, for example logs, is required from the customer, or sending of guides and instructions in writing from the Technical Support team.

[SLIDE 29]

I will now demonstrate how to create a wireshark capture, and how to create the 3CX Support info, which will facilitate the 3CX Support team to assist with any issues on the PBX.