Choose the app sip transport mode tls addition the sip traffic
[SLIDE 1]
Welcome to the online training series from 3CX. This module will focus on the configuration of Ring Groups and Paging Groups in 3CX.
First of all, let's talk about what a ring group is.
A ring group is a virtual extension, which merges multiple extensions together. By contacting this one number, you will be able to contact a group of extensions, for example, the Sales Department’s extensions.
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.
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]
[SLIDE 7]
The way the prioritised hunt ringing strategy works, is as follows.
More about the Destination if no Answer 2 slides further down.
[SLIDE 8]
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.
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?
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]
[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.
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.
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.
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:
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]
Welcome to the online training series of 3CX. This module focuses on the Call Queueing functionality of 3CX.
[SLIDE 2]
We will finish off with a review of the Queue Manager rights, which can be configured for an extension.
[SLIDE 3]
The Polling Strategies will be explained shortly.
[SLIDE 4]
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.
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.
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 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.
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.
The timer is reset after each call. This will not accumulate.
[SLIDE 12]
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]
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]
A call can also be forwarded to an outside PSTN number.
[SLIDE 15]
[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.
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]
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.
Some more advanced queue options.
The queue call recordings can be enabled or disabled accordingly.
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.
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.
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.
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.
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.
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]
[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.
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.
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
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.
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]
[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.
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.
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)
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.
[SLIDE 9]
The source pattern is structured in the following way.
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.
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.
[SLIDE 11]
Let's have a look at some examples to test your knowledge of what you have learnt in this module.
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 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.
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]
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.
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.
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.
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.
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.
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.
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.
[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.
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.
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.
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.
[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 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.
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.
[SLIDE 23]
Calls through the Bridge, to bridged extensions are also configured through the outbound rules of the PBX.
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
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
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.
Connecting 2 or more 3CX Systems together via bridges requires at least a PRO edition license.
[SLIDE 4]
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 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 10]
The configuration of the slave bridge parameters will be mainly identical to the Master PBX.
[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.
[SLIDE 13]
When the bridge connection has been established, the presence information between the 2 PBXs can be exchanged.
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.
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]
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.
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]
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.
Just a note that the PBXs do not need to have the same extension digit length, to be bridged together.
[SLIDE 20]
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.
[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.
6-Security and Anti-Fraud
https://www.youtube.com/watch?v=bFBk7crm5Ic&feature=youtu.be
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.
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.
[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.
Security can be further enhanced by increasing the character length to a maximum of 50 characters.
[SLIDE 7]
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]
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.
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.
[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.
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.
[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 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]
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.
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.
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.
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.
https://www.youtube.com/watch?v=o8VyfmJQksU&list=PL6sq0_ucoDuk4oiBicc1b8ls3zVNAXfIw&index=8&t=0s
[SLIDE 1]
[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.
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.
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]
An example of other Warning events would be SLA time breaches in the queues, as well as abandoned queue calls.
[SLIDE 7]
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.
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]
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.
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.
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.
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.
[SLIDE 14]
This is a sample call flow of a REGISTER request coming from an endpoint.
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.
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.
We will now analyse each of the different headers within this packet.
[SLIDE 17]
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.
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.
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.
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 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.
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]
[SLIDE 28]
Now, after you’ve done your research and done your best, you may still be facing difficulty configuring or troubleshooting an issue.
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.