Test Plan
Test Plan System Setup
This section explains how the 3CX test system should be set up in order to perform the test cases.
3CX Installation
The server you install 3CX on must meet the minimum hardware and software requirements mentioned in the 3CX manual, This can be found here.
If you do not already have a Licence Key to activate 3CX, you may acquire a free Annual 16 Simultaneous Call Standard License by filling in the form here.
Also ensure that the 3CX version you are using is the latest released version at the time of conducting the test cases.
Endpoint Devices
To run all the tests, at least 2 extensions will have to be registered. Additionally, in order to run some of the test cases, you will additionally require a FXS/ATA device registered.
All hardware used must be listed in the list of supported/approved devices by 3CX. This list can be found here.
For the registered extensions, you may also use the 3CX client instead of a supported IP deskphone.
SIP Trunk Provider Resource Requirements
The SIP Trunk provider under testing will need at least one account with 2 DIDs to be able to run the test cases outlined in this section.
In order to run the test cases in section “Inbound Calls With Multiple SIP Trunks”, an additional account will be required with a new set of at least 2 DIDs. If adding 2 different accounts on a single 3CX installation is not possible for whichever reason, please state this clearly to the users/customers who will be using the SIP Trunk service with the 3CX software.
Required Skills
The person(s) that will be performing the test cases should have the following skills:
- Configuring 3CX as required by the test cases
- Configuring any endpoints/devices with 3CX using the 3CX approved methods (provisioning of handsets, gateways, etc)
- Knowledge of SIP
- Use of Wireshark and analyzing capture files
These will allow the person(s) to perform all test cases without running into an issue.
SIP Trunk Settings
Before running the Test Cases in section “Test Cases”, it is recommended that you have read and understood all chapters in this series of documents. This will ensure that you know how 3CX operates and what behavior to expect.
Once you have set up a SIP Account of the SIP Trunk service provider under testing, you must make sure that all test cases performed must pass without the need to change the SIP Trunk settings between test cases.
All test cases must be able to pass with the same set of SIP Trunk settings in 3CX. Tests that require modifications to pass should be considered “failed”. The reason for this is because the template that will be generated has a static set of settings.
Test Cases
This section outlines the test case scenarios required to ensure that the SIP Trunk service provider under testing is capable of performing the majority of the expected call-related features when being used with 3CX and also ensures the stability of such a setup.
Test cases are categorized as “Mandatory” and “Optional”. Mandatory test cases must be completed successfully. If they fail, it is not recommended to use the certain SIP Trunk service provider with 3CX.
Optional test cases can be skipped, as long as the feature/function they are testing is documented as “not supported”.
1 DNS Resolution
This section will test the DNS resolution of the registrar used. If the SIP trunk uses an IP as registrar this section can be skipped
1.1 DNS Lookup
Importance: Mandatory (if FQDN is used as Registrar and/or Outbound Proxy)
Purpose: Makes sure that the PBX can correctly resolve the registrar and the correct transport method is used.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Go to Dashboard → Services and restart the SIP server service. | The 3CX SIP Server and any associated services will stop and then start automatically |
Step 2 | Registration based Trunks: Wait for the server to start and make sure that the DNS resolution was done correctly in Wireshark. IP based Trunks: Force an Outbound call to force a DNS lookup. | The PBX must check for A and AAAA records as well as NAPTR and SRV records. All results must match what is configured for the registrar. |
2 Registration
This section tests the registration compatibility between 3CX and the SIP Trunk provider. If the SIP Trunk provider under testing is IP-based, this section can be skipped.
2.1 Basic Registration
Importance: Mandatory
Purpose: Check that 3CX can register with the SIP Trunk provider.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Go to Dashboard → Services and restart the SIP Server | The 3CX SIP Server and any associated services will stop and then start automatically |
Step 2 | Wait for the services to start, then go to “Voice & Chat” in the Admin Console and check the registration status of the SIP Trunk | The SIP Trunk after the services have restarted should be seen as “Registered” with a green status |
Step 3 | Check the capture file and ensure that the registration sequence is correct | Check that 3CX sent the REGISTER message correctly and that the SIP Trunk provide responded accordingly |
2.2 Maintaining Registration
Importance: Mandatory
Purpose: Check that 3CX can maintain registration over a period of time.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Go to Dashboard → Services and restart the SIP Server | The 3CX SIP Server and any associated services will stop and then start automatically |
Step 2 | Wait for the services to start, then go to “Voice & Chat” in the Admin Console and check the registration status of the SIP Trunk | The SIP Trunk after the services have restarted should be seen a “Registered” with a green status |
Step 3 | Wait more than 60 minutes | Allow enough time for 3CX to refresh the registration multiple times |
Step 4 | Go to “Voice & Chat” in the Admin Console and check the registration status of the SIP Trunk. | The SIP Trunk should still be seen as “Registered” with a green status |
Step 5 | Check the capture and ensure that 3CX respects the ‘Expiry’ time set by the provider and that registrations occur at correct intervals | 3CX should respect the ‘Expiry’ sent by the provider in the 200 OK and refresh the registration within the ‘Expiry’ interval |
2.3 Releasing the Binding and re-Registering #1
Importance: Mandatory
Purpose: Ensures that 3CX can release the registration binding and re-register immediately.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Ensure that the SIP Trunk is registered | This scenario must start off with the SIP Trunk registered |
Step 2 | In the “Voice & Chat” section of the Admin Console, select the SIP Trunk and press “Refresh Registration” | 3CX will release the registration binding and then immediately send a new registration request |
Step 3 | Click away from the “Voice & Chat” section and the go back, then check the SIP Trunk is registered | The SIP Trunk should be seen as “Registered” with a green status |
2.4 Releasing the Binding and re-Registering #2
Importance: Mandatory
Purpose: Ensures that 3CX can release the registration binding and re-register immediately.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Ensure that the SIP Trunk is registered. | This scenario must start off with the SIP Trunk registered. |
Step 2 | In the “Voice & Chat” section in the Admin Console, highlight the SIP Trunk and go to the “Options” tab. Disable the options “Allow inbound calls” and “Allow outbound calls”. Press “OK” to confirm. | 3CX will release the registration binding and stay unregistered. |
Step 3 | Reverse the process in Step 2 by re-enabling the 2 options. Press “OK” to confirm. | 3CX will send a new registration and the trunk will register. |
2.5 The correct Transport is Used
Importance: Mandatory
Purpose: Checks that the correct transport type has been used and depending on this, if the SIP message is correct
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Go to Dashboard → Services and restart the SIP Server | The 3CX SIP Server and any associated services will stop and then start automatically |
Step 2 | Wait for the services to start, then go to “Voice & Chat” in the Admin Console and check the registration status of the SIP Trunk | The SIP Trunk after the services have restarted should be seen a “Registered” with a green status |
Step 3 | In the capture check the REGISTER message that was sent:
| If 3CX based on the settings or DNS resolution chooses to send the REGISTER message over TCP transport, then the REGISTER message must contain “transport=TCP”. If UDP is used, it must not contain this. |
2.6 SIP Trunk provider returns “rinstance” value
Importance: Optional
Purpose: This scenario checks if the SIP Trunk provider returns the “rinstance” parameter 3CX sends on each registration with the corresponding value.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Go to Dashboard → Services and restart the SIP Server | The 3CX SIP Server and any associated services will stop and then start automatically |
Step 2 | Wait for the services to start, then go to “Voice & Chat” in the Admin Console and check the registration status of the SIP Trunk | The SIP Trunk after the services have restarted should be seen as “Registered” with a green status |
Step 3 | Check the capture file and ensure that 3CX sends the “rinstance” parameter in the “Contact” header of the REGISTER message with a random value. | On each new registration 3CX should send the “rinstance” parameter with a new random value. |
Step 4 | In the 200 OK from the provider check if the “Contact” header contains the “rinstance” parameter with the same value sent in Step 3 | The expected behavior is that the SIP Trunk provider will store the “rinstance” value and send it back in the 200 OK. |
3 Inbound Calls
This section is designed to test Inbound calling compatibility between the PBX and the SIP Trunk provider.
3.1 “rinstance” Support
Importance: Optional
Purpose: This test will check if Register based providers support rinstance for call source identification. IP based trunks can skip this test
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Make an Inbound call to the main trunk number of the sip trunk. Check if the “rinstance” value of the register message is included in the Request Line URI on an Inbound call Invite message. | The ”rinstance”value is included in the incoming invite message; it should be part of the Request Line URI sip field. |
Step 2 | Make sure that the “rinstance” value matches the one sent in the last registration message from the PBX. If “rinstance” is not present in the Invite you can skip this step. | The “rinstance”value included in the incoming invite message should be the same as the one sent by the PBX in the last Register message. |
Step 3 | Make an Inbound call to the second DID number of the sip trunk. Check if the “rinstance” value of the register message is included in the Request Line URI on an Inbound call Invite message. | The ”rinstance”value is included in the incoming invite message; it should be part of the Request Line URI sip field. |
Step 4 | Make sure that the “rinstance” value matches the one sent in the last registration message from the PBX. If “rinstance” is not present in the Invite you can skip this step. | The “rinstance”value included in the incoming invite message should be the same as the one sent by the PBX in the last Register message. |
3.2 Call Routing
Importance: Mandatory
Purpose: This test will check if Inbound calls are identified and routed correctly by the SIP trunk.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Route the main trunk number destination to Extension A and make an Inbound call. | Make sure that the call routes correctly in the PBX and that the correct extension is ringing. |
Step 2 | Answer the call. | Navigate to Dashboard → Active calls and make sure that the call is between the correct extension and SIP trunk. |
Step 3 | Route the second DID number destination to Extension B and make an Inbound call. | Make sure that the call routes correctly in the PBX and that the correct extension is ringing. |
Step 4 | Answer the call. | Navigate to Dashboard → Active Calls and make sure that the call is between the correct extension and SIP trunk. |
3.3 Basic Call Functionality
Importance: Mandatory
Purpose: This test will check the basic call functionality for Inbound National and International calls.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Make an Inbound call to the trunk from a national number to Extension A. | The call should be established and Extension A should have 2-way audio with the remote party The call should run for at least 60 seconds |
Step 2 | Check that Extension A sees the correct CLI | Extension A should see the caller ID of the remote party. |
Step 3 | Extension A hangs up the call | Make sure that the call is terminated correctly on both ends |
Step 4 | Make an Inbound call to the trunk from an international number to Extension A. | The call should be established and Extension A should have 2-way audio with the remote party The call should run for at least 60 seconds |
Step 5 | Check that Extension A sees the correct CLI | Extension A should see the caller ID of the remote party. |
Step 6 | Extension A hangs up the call | Make sure that the call is terminated correctly on both ends |
3.4 Basic inbound Call #1
Importance: Mandatory
Purpose: Ensure that a caller can make an inbound call and place and retrieve the call from on-hold.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Establish an inbound Call with Extension A from an external number by calling the Main Trunk Number (DID A). | The inbound call should be established and Extension A should have 2-way audio with the remote party |
Step 2 | Check what CLI Extension A sees | Extension A should see the correct CLI |
Step 3 | Leave the call active for at least 60 seconds and ensure 2-way audio remains | The call should still have 2-way audio after at least 60 seconds |
Step 4 | Extension A places the call on hold | The remote party should hear the MoH configured in 3CX. |
Step 5 | Wait 60 seconds | The remote party should still hear MoH after 60 seconds |
Step 6 | Extension A retrieves call from on-hold | The remote party should stop hearing the MoH and 2-way audio is possible between Extension A and the remote party |
Step 7 | Leave the call active for another 60 seconds and ensure 2-way audio remains | The call should still have 2-way audio |
Step 8 | Extension A hangs up the call | 3CX should send a BYE message and an appropriate response should be sent by the Provider. Also the remote partys phone should hang up |
3.5 Basic Inbound Call #2
Importance: Mandatory
Purpose: Ensure that a caller can make an inbound call and place and retrieve the call from on-hold.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Establish an inbound Call with Extension A from an external number by calling a DID number Number (DID B). | The inbound call should be established and Extension A should have 2-way audio with the remote party |
Step 2 | Check what CLI Extension A sees | Extension A should see the correct CLI |
Step 3 | Leave the call active for at least 60 seconds and ensure 2-way audio remains | The call should still have 2-way audio after at least 60 seconds |
Step 4 | The Remote party places the call on hold | Extension A should hear MoH (either that of the Local PBX of the Remote PBX). |
Step 5 | Wait 60 seconds | Extension A should still hear MoH after 60 seconds |
Step 6 | The Remote party retrieves call from on-hold | Extension A should stop hearing the MoH and 2-way audio is possible between Extension A and the remote party |
Step 7 | Leave the call active for another 60 seconds and ensure 2-way audio remains | The call should still have 2-way audio |
Step 8 | The Remote party hangs up the call | 3CX should receive a BYE message and an appropriate response should be sent to the Provider. Both phones should hang up |
3.6 Call Continuation
Importance: Mandatory
Purpose: Ensure that call continues if a DID is added or change is made to the SIP Trunk while a call is active. If the SIP trunk is IP based this test can be skipped.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Establish an inbound Call with Extension A from an external number. | The inbound call should be established and Extension A should have 2-way audio with the remote party |
Step 2 | Edit the Trunk and add a DID number. Press Ok to save changes | The trunk should re-register but the call should continue for at least another 60 seconds. |
Step 3 | Extension A hangs up the call | 3CX should send a BYE message and an appropriate response should be sent by the Provider. Also the remote partys phone should hang up |
3.7 Inbound call to Digital Receptionist
Importance: Mandatory
Purpose: Ensure that a call is established with a Digital receptionist and routing works using DTMF inputs.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Create a Digital receptionist and assign extension A on Option 0. Route the main trunk number to the Digital receptionist. Establish an inbound call to the Digital receptionist from an external number. | The inbound call should be established and the external party should hear the Digital receptionists Music on hold. |
Step 2 | On the device on the external party press 0 | The Digital receptionist should recognise the DTMF tone and route the call to Extension A. |
Step 3 | Extension A Answers call | The inbound call should be established and Extension A should have 2-way audio with the remote party. The call should be established for at least 60 seconds |
Step 4 | Extension A terminates the call | 3CX should send a BYE message and an appropriate response should be sent by the Provider. Also the remote partys phone should hang up |
3.8 Inbound call to Digital Receptionist #2
Importance: Mandatory
Purpose: Ensure that a call is established with a Digital receptionist and routing works using DTMF inputs.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Establish an inbound call to the Digital receptionist from an external number. | The inbound call should be established and the external party should hear the Digital receptionists Music on hold. |
Step 2 | On the device on the external party dial Extensions A number (e.g 000). | The Digital receptionist should recognise the DTMF tones and route the call to Extension A. |
Step 3 | Extension A Answers call | The inbound call should be established and Extension A should have 2-way audio with the remote party. The call should be established for at least 60 seconds |
Step 4 | The remote party terminates the call | 3CX should receive a BYE message and an appropriate response should be sent to the Provider. Both phones should hang up |
Step 5 | Using wireshark identify the DTMF method used. | Identify if RFC2833 or inband is used. |
3.9 Inbound call to Queue
Importance: Mandatory
Purpose: Ensure that a call is established with a Queue and a member of the Queue is able to pick up the call
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Create a Queue and assign extension A a queue agent. Route the main trunk number to the Queue. Establish an inbound call to the Queue from an external number. | The inbound call should be established and the external party should hear the Queues Music on hold. |
Step 2 | Check what CLI Extension A sees | Extension A should see the Queue name and the correct CLI. |
Step 3 | Extension A Answers call | The inbound call should be established and Extension A should have 2-way audio with the remote party. The call should be established for at least 60 seconds |
Step 4 | Extension A terminates the call | 3CX should send a BYE message and an appropriate response should be sent by the Provider. Also the remote partys phone should hang up. |
3.10 Inbound call to Ring Group
Importance: Mandatory
Purpose: Ensure that a call is established with a Ring Group.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Create a Ring Group and assign extension A as a Ring Group agent. Route the main trunk number to the Ring Group. Establish an inbound call to the Ring Group from an external number. | The inbound call should arrive in the Ring Group and the Ring Group agents should be polled. |
Step 2 | Check what CLI Extension A sees | Extension A should see the Ring Group name and the correct CLI. |
Step 3 | Extension A Answers call | The inbound call should be established and Extension A should have 2-way audio with the remote party. The call should be established for at least 60 seconds |
Step 4 | Extension A terminates the call | 3CX should send a BYE message and an appropriate response should be sent by the Provider. Also the remote partys phone should hang up. |
3.11 Inbound call to Voicemail
Importance: Mandatory
Purpose: Ensure that a call is established with the Voicemail service.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Route the main trunk number to voicemail of extension A. Establish an inbound call to the voicemail service from an external number. | The inbound call should be established and the external party should hear the voicemail prompt for Extension A |
Step 2 | Follow the prompt and leave a message | Make sure that the message was left and the call was successfully disconnected. |
Step 3 | Extension A retrieves the message | Make sure that Extension A can listen to the message and that the quality of the message is good. |
3.12 Inbound call - Rejection test - Call Reject by phone
Importance: Mandatory
Purpose: Ensure that the call is successfully rejected by the phone.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Route the main trunk number to Extension A. Ensure that extensions A forwarding rules for the “Available” status are all set to “End Call”. Establish an Inbound call to the main trunk number. | Call should ring Extension A and Extension A sees the correct CLI. |
Step 2 | Reject the call without answering | Make sure that the call is rejected and a “486 Busy Here” is generated from the PBX. The call should be terminated for the external party as well |
3.13 Inbound call - Rejection test - Call Reject by Forwarding Rule
Importance: Mandatory
Purpose: Ensure that the call is successfully rejected by the extensions forwarding rules.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Route the main trunk number to Extension A. Ensure that extensions A forwarding rules for the “Away” status are all set to “End Call”. Switch Extensions A status to “Away”. | Make sure that everything is setup correctly and that routing works. |
Step 2 | Establish an Inbound call to the main trunk number. | Make sure that the call is rejected by the PBX without polling Extension A and a “486 Busy Here” is generated from the PBX. The call should be terminated for the external party as well |
3.14 Inbound call - Rejection test - Call Reject by Number Blacklist
Importance: Mandatory
Purpose: Ensure that the call is successfully rejected by the numbers blacklist.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Navigate to Settings → Blacklisted Numbers and add the external party’s number into the Blacklist | Make sure that number is saved in the correct format in the Blacklisted Numbers |
Establish an Inbound call to the main trunk number. | Make sure that the call is rejected by the PBX without polling Extension A and a “603 Decline” is generated from the PBX. The call should be terminated for the external party as well. |
3.15 Inbound call - Rejection test - Call Reject by Maximum simultaneous calls
Importance: Mandatory
Purpose: Ensure that the call is successfully rejected if the SIP trunk reaches its maximum simultaneous calls.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Route the main trunk number to Extension A and ensure that:
Establish an Inbound call to the main trunk number. | The inbound call should be established and Extension A should have 2-way audio with the remote party. |
Step 2 | Make another call to the main trunk number | Make sure that the call is rejected and a “600 Busy Everywhere” is generated from the PBX. The call should be terminated for the external party as well |
Step 3 | Extension A terminates the established call. | 3CX should send a BYE message and an appropriate response should be sent by the Provider. Also the remote partys phone should hang up. |
3.16 Inbound Long Duration Call
Importance: Mandatory
Purpose: This tests the ability of the SIP Trunk provider and 3CX to maintain a long duration call
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Make an inbound call from an external party to Extension A and make sure the call is established. | The inbound call should be established and Extension A should have 2-way audio with the remote party. |
Step 2 | Leave the call active for at least 1 hour | The call should be left active for at least 1 hour and should not drop. Also 2-way audio should be possible throughout the whole duration. |
Step 3 | Extension A hangs up the call. | The call should terminate on the remote party |
Step 4 | Check the capture file if any “keep alive” method was used (e.g. OPTIONS messages, session-timer, etc) | State in the note if any SIP method was used by either 3CX or the Provider. Examples of such could be either OPTIONS messages at certain intervals of a session-timer (RFC 4028) |
4 Inbound Calls With Multiple SIP Trunks
This section tests the compatibility between 3CX and the SIP Trunk provider for Inbound Calls, when there are multiple SIP Trunks created in 3CX for the same provider.
This at the same time validates that “Source Identification” for this SIP Trunk provider has been set up correctly.
4.1 Basic Inbound Call #1
Importance: Optional
Purpose: This tests if Inbound Calls to 3CX, when there are multiple instances of the same provider, are identified correctly by 3CX.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | In 3CX under “Voice & Chat”, edit each SIP Trunk and in the “General” tab configure so that:
Both SIP Trunks bust have different main trunk numbers configured. Also ensure that in “Inbound Rules” report, there is no entries at all | This setup will test the “Catch All” routing ability when multiple SIP Trunks from the same provider exist |
Step 2 | From an external source, make a call to SIP Trunk A main trunk number and answer | Call should ring Extension A and the call should be able to be answered with 2-way audio. |
Step 3 | While call is active, go to Dashboard → “ActiveCalls” and check if 3CX identifies the incoming as coming from SIP Trunk A correctly | This ensures that 3CX is able to distinguish calls arriving for SIP Trunk A and associate them correctly. |
Step 4 | Hang up the call on SIP Trunk A | |
Step 5 | From an external source, make a call to SIP Trunk B main trunk number and answer | Call should ring Extension B and the call should be able to be answered with 2-way audio. |
Step 6 | While call is active, go to Dashboard → Active Calls” and check if 3CX identifies the incoming as coming from SIP Trunk B correctly | This ensures that 3CX is able to distinguish calls arriving for SIP Trunk B and associate them correctly. |
4.2 Basic Inbound Call #2
Importance: Optional
Purpose: This tests if Inbound Calls to 3CX, when there are multiple instances of the same provider, are identified correctly by 3CX.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | In 3CX under “SIP Trunks”, edit each SIP Trunk and ensure that each one, in the “DIDs” tab, has at least 1 DID other than the main trunk number. The DIDs must be different on SIP Trunk A and B.
| This setup will test the Inbound Rule routing ability when multiple SIP Trunks from the same provider exist |
Step 2 | From an external source, make a call to the DID of SIP Trunk A and answer | Call should ring Extension A and the call should be able to be answered with 2-way audio. |
Step 3 | While call is active, go to Dashboard → “Active Calls” and check if 3CX identifies the incoming as coming from SIP Trunk A correctly | This ensures that 3CX is able to distinguish calls arriving for SIP Trunk A and associate them correctly. |
Step 4 | Hang up the call on SIP Trunk A | |
Step 5 | From an external source, make a call to the DID of SIP Trunk B and answer | Call should ring Extension B and the call should be able to be answered with 2-way audio. |
Step 6 | While call is active, go to Dashboard → Active Calls” and check if 3CX identifies the incoming as coming from SIP Trunk B correctly | This ensures that 3CX is able to distinguish calls arriving for SIP Trunk B and associate them correctly. |
4.3 Basic Inbound Call #3
Importance: Optional
Purpose: This tests if Inbound Calls to 3CX, when there are multiple instances of the same provider, are identified correctly by 3CX when the same DID number may exist on multiple SIP Trunk entries.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | In 3CX under “Voice & Chat”, edit each SIP Trunk A and ensure that in the “DIDs” tab, it has at least 1 DID other than the main trunk number. Edit SIP Trunk B and in the “DIDs” tab, add the DID of SIP Trunk A (do so even if it is not associated with this account). In the “General” tab of both SIP Trunks configure so that:
Also ensure that in “Inbound Rules” report, there is no entries at all | This setup will test the Inbound Rule routing ability when multiple SIP Trunks from the same provider exist and there are common DIDs between multiple SIP Trunks in 3CX. |
Step 2 | From an external source, make a call to the DID of SIP Trunk A and answer | Call should ring Extension A and the call should be able to be answered with 2-way audio. |
Step 3 | While call is active, go to Dashboard → “Active Calls” and check if 3CX identifies the incoming as coming from SIP Trunk A correctly | This ensures that 3CX is able to distinguish calls arriving for SIP Trunk A and associate them correctly. |
Step 4 | Hang up the call |
4.4 Basic Inbound Call #4
Importance: Optional
Purpose: This tests if Inbound Calls to 3CX, when there are multiple instances of the same provider, are identified correctly by 3CX when the same DID number may exist on multiple SIP Trunk entries.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | In 3CX under“Voice & Chat”, edit each SIP Trunk B and ensure that in the “DIDs” tab, it has at least 1 DID other than the main trunk number. Edit SIP Trunk A and in the “DIDs” tab, add the DID of SIP Trunk B (do so even if it is not associated with this account). In the “General” tab of both SIP Trunks configure so that:
Also ensure that in “Inbound Rules” report, there is no entries at all | This setup will test the Inbound Rule routing ability when multiple SIP Trunks from the same provider exist and there are common DIDs between multiple SIP Trunks in 3CX. |
Step 2 | From an external source, make a call to the DID of SIP Trunk A and answer | Call should ring Extension B and the call should be able to be answered with 2-way audio. |
Step 3 | While call is active, go to Dashboard → “Active Calls” and check if 3CX identifies the incoming as coming from SIP Trunk A correctly | This ensures that 3CX is able to distinguish calls arriving for SIP Trunk B and associate them correctly. |
Step 4 | Hang up the call |
5 Outbound Calls
This section will test the outbound call compatibility between 3CX and the SIP Trunk provider under testing.
5.1 Basic Outbound Call #1
Importance: Mandatory
Purpose: Ensure that an endpoint can make an outbound call and place and retrieve the call from on-hold.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Establish an Outbound Call from Extension A registered on 3CX to an external number. | The outbound call should be established and Extension A should have 2-way audio with the remote party |
Step 2 | Check what CLI the remote party sees | The remote party should see the Main Trunk number as the CLI |
Step 3 | Leave the call active for at least 60 seconds and ensure 2-way audio remains | The call should still have 2-way audio after at least 60 seconds |
Step 4 | Extension A places the call on hold | The remote party should hear the MoH configured in 3CX. |
Step 5 | Wait 60 seconds | The remote party should still hear MoH after 60 seconds |
Step 6 | Extension A retrieves call from on-hold | The remote party should stop hearing the MoH and 2-way audio is possible between Extension A and the remote party |
Step 7 | Leave the call active for another 60 seconds and ensure 2-way audio remains | The call should still have 2-way audio |
Step 8 | Extension A hangs up the call | 3CX should send a BYE message and an appropriate response should be sent by the Provider. Also the remote partys phone should hang up |
5.2 Basic Outbound Call #2
Importance: Mandatory
Purpose: Ensure that an endpoint can make an outbound call and can be placed and retrieved from on-hold from the remote party.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Establish an Outbound Call from Extension A registered on 3CX to an external number. | The outbound call should be established and Extension A should have 2-way audio with the remote party |
Step 2 | Check what CLI the remote party sees | The remote party should see the Main Trunk number as the CLI |
Step 3 | Leave the call active for at least 60 seconds and ensure 2-way audio remains | The call should still have 2-way audio after at least seconds |
Step 4 | Remote party places the call on hold | Extension A should hear the MoH |
Step 5 | Wait 60 seconds | Extension A should still hear MoH after 60 seconds |
Step 6 | Remote party retrieves call from on-hold | Extension A should stop hearing the MoH and 2-way audio is possible between Extension A and the remote party |
Step 7 | Leave the call active for another 60 seconds and ensure 2-way audio remains | The call should still have 2-way audio |
Step 8 | Remote party hangs up the call | 3CX should receive a BYE message and should send an appropriate response. Also Extension A phone should hang up |
5.3 Presenting a DID as CLI
Importance: Mandatory
Purpose: Checks that on outbound calls can be made when presenting one of the DIDs as CLI to the remote party.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | In the SIP Trunk settings → “Options” tab → “Caller ID Control”, set the Caller ID to be one of the DIDs you have associated to this trunk (must not be the main trunk number) | |
Step 2 | Make an outgoing call from Extension A to an external number | The remote party should ring and see the DID number set as CLI. |
Step 3 | Remote party answers the call and 2-way audio is established | The call should be established and 2-way audio possible |
Step 4 | Extension A hangs up the call | 3CX should send a BYE message and an appropriate response should be sent by the Provider. Also the remote partys phone should hang up |
5.4 Presenting a Number as CLI that is not a DID (Clip No Screening)
Importance: Optional
Purpose: Checks that on outbound calls can be made when presenting a number that is not a DID as CLI to the remote party (Clip No Screening).
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | In the SIP Trunk settings → “Options” tab → “Caller ID Control”, set the Caller ID to be a national number that is not associated to this trunk | Enter a national number that is not associated with the SIP Trunk account being used |
Step 2 | Make an outgoing call from Extension A to an external number | The remote party should ring and see the number set in Step 1 as CLI. |
Step 3 | Remote party answers the call and 2-way audio is established | The call should be established and 2-way audio possible |
Step 4 | Extension A hangs up the call | 3CX should send a BYE message and an appropriate response should be sent by the Provider. Also the remote partys phone should hang up |
5.5 Outbound Calls with Withheld CLI (Anonymous)
Importance: Optional
Purpose: Checks that outbound calls can be made while withholding the CLI.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Make an outgoing call from Extension A to an external number using the Anonymous dial code (default *5) | Make an anonymous outbound call using the 3CX dial code. If using the default dial code, if the external number is 123456789, on the extension dial: *5123456789 |
Step 2 | Remote party phone rings | The remote party should ring and should not display any number as CLI. |
Step 3 | Remote party answers the call and 2-way audio is established | The call should be established and 2-way audio possible |
Step 4 | Extension A hangs up the call | 3CX should send a BYE message and an appropriate response should be sent by the Provider. Also the remote partys phone should hang up |
5.6 CLI Presented Correctly when calling International Numbers
Importance: Mandatory
Purpose: Checks that on outbound calls to international numbers, the CLI is presented correctly to the remote party.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | In the SIP Trunk settings → “Options” tab → “Caller ID Control”, set the Caller ID to be one of the DIDs you have associated to this trunk (must not be the main trunk number) | |
Step 2 | Make an outgoing call from Extension A to an external international number | The remote party should ring and see the DID number set as CLI. |
Step 3 | Remote party answers the call and 2-way audio is established | The call should be established and 2-way audio possible |
Step 4 | Extension A hangs up the call | 3CX should send a BYE message and an appropriate response should be sent by the Provider. Also the remote partys phone should hang up |
5.7 DTMF Tones / Traversing IVRs #1
Importance: Mandatory
Purpose: This tests the compatibility of the provider with 3CX regarding single DTMF tones.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Make an outgoing call from Extension A to an external number thats has an IVR that answers | Call a number that answers with an IVR. This can be a different 3CX system registered with a different account. |
Step 2 | Ensure Extension A hears the IVR greeting | Extension A should be able to hear the IVR greeting |
Step 3 | Extension A enter a valid IVR option (single digit) | Extension A sends a DTMF tone which is also sent over the call through the SIP Trunk provider |
Step 4 | Validate that call is routed correctly based on option pressed | The call must be routed to the destination based on the option set. This ensures that the remote system “understood” the DTMF tone correctly |
Step 5 | In the capture file, identify which DTMF method was used by 3CX to send the DTMF tones (RFC2833 or In-band) | In the notes of the test results, state which DTMF method was used to transmit the DTMF tones |
5.8 DTMF Tones / Traversing IVRs #2
Importance: Mandatory
Purpose: This tests the compatibility of the provider with 3CX regarding multiple consecutive DTMF tones.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Make an outgoing call from Extension A to an external number thats has an IVR that answers | Call a number that answers with an IVR. This can be a different 3CX system registered with a different account. |
Step 2 | Ensure Extension A hears the IVR greeting | Extension A should be able to hear the IVR greeting |
Step 3 | Extension A enter a valid mutl-digit IVR option, e.g. an extension number of the system (multiple digits) | Extension A sends a DTMF tone which is also sent over the call through the SIP Trunk provider |
Step 4 | Validate that call is routed correctly based on input | The call must be routed to the destination based on the option set. This ensures that the remote system “understood” the DTMF tones correctly |
Step 5 | In the capture file, identify which DTMF method was used by 3CX to send the DTMF tones (RFC2833 or In-band) | In the notes of the test results, state which DTMF method was used to transmit the DTMF tones |
5.9 Outbound Long Duration Call
Importance: Mandatory
Purpose: This tests the ability of the SIP Trunk provider and 3CX to maintain a long duration call
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Make an outgoing call from Extension A to an external number and make sure the call is established. | The destination number should ring and the remote part should answer the call and 2-way audio should be possible |
Step 2 | Leave the call active for at least 1 hour | The call should be left active for at least 1 hour and should not drop. Also 2-way audio should be possible throughout the whole duration. |
Step 3 | Extension A hangs up the call. | The call should terminate on the remote party |
Step 4 | Check the capture file if any “keep alive” method was used (e.g. OPTIONS messages, session-timer, etc) | State in the note if any SIP method was used by either 3CX or the Provider. Examples of such could be either OPTIONS messages at certain intervals of a session-timer (RFC 4028) |
6 Fax Calls
This section is designed to test the FAX compatibility between the PBX and the SIP Trunk provider.
6.1 Inbound FAX
Importance: Optional
Purpose: This tests the ability to receive a FAX using T.38 using the built in FAX server of the PBX. If the SIP trunk does not support T.38 you can skip this test.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Create a Fax Forward by navigating to Advanced → Fax → Add → Add Fax Forward and route the main trunk number to send FAX to the email of Extension A. Click OK to save the changes. Then send 10 pages of FAX towards the main trunk number. | Ensure that the call is answered by the 3CX Fax server and that the 2 parties communicate using T.38. Upon completion the FAX should be sent as pdf to Extensions A email address. |
6.2 Outbound FAX
Importance: Optional
Purpose: This tests the ability to send a FAX using T.38 using a supported ATA device. If the SIP trunk does not support T.38 you can skip this test.
Procedure:
| DESCRIPTION | EXPECTED RESULT |
Step 1 | Using the configured supported ATA device send 10 pages FAX to a remote party | Ensure that the call is answered by the remote party and T.38 is negotiated correctly. All 10 pages must be sent successfully and received by the remote party. |
10.3 Test Case Summary
Following is a list of all test case titles, along with their respective ID and importance.
TEXT CASE ID | TITLE | IMPORTANCE |
1.1 | DNS Lookup | Mandatory |
2.1 | Basic Registration | Mandatory |
2.2 | Maintaining Registration | Mandatory |
2.3 | Releasing the Binding and re-Registering #1 | Mandatory |
2.4 | Releasing the Binding and re-Registering #2 | Mandatory |
2.5 | The correct Transport is Used | Mandatory |
2.6 | SIP Trunk provider returns “rinstance” value | Optional |
3.1 | “rinstance” Support | Optional |
3.2 | Call Routing | Mandatory |
3.3 | Basic Call Functionality | Mandatory |
3.4 | Basic inbound Call #1 | Mandatory |
3.5 | Basic inbound Call #2 | Mandatory |
3.6 | Call Continuation | Mandatory |
3.7 | Inbound call to Digital Receptionist | Mandatory |
3.8 | Inbound call to Digital Receptionist #2 | Mandatory |
3.9 | Inbound call to Queue | Mandatory |
3.10 | Inbound call to Ring Group | Mandatory |
3.11 | Inbound call to Voicemail | Mandatory |
3.12 | Inbound call - Rejection test - Call Reject by phone | Mandatory |
3.13 | Inbound call - Rejection test - Call Reject by Forwarding Rule | Mandatory |
3.14 | Inbound call - Rejection test - Call Reject by Number Blacklist | Mandatory |
3.15 | Inbound call - Rejection test - Call Reject by Maximum simultaneous calls | Mandatory |
3.16 | Inbound Long Duration Call | Mandatory |
4.1 | Basic Inbound Call #1 | Optional |
4.2 | Basic Inbound Call #2 | Optional |
4.3 | Basic Inbound Call #3 | Optional |
4.4 | Basic Inbound Call #4 | Optional |
5.1 | Basic Outbound Call #1 | Mandatory |
5.2 | Basic Outbound Call #2 | Mandatory |
5.3 | Presenting a DID as CLI | Mandatory |
5.4 | Presenting a Number as CLI that is not a DID (Clip No Screening) | Optional |
5.5 | Outbound Calls with Withheld CLI (Anonymous) | Optional |
5.6 | CLI Presented Correctly when calling International Numbers | Mandatory |
5.7 | DTMF Tones / Traversing IVRs #1 | Mandatory |
5.8 | DTMF Tones / Traversing IVRs #2 | Mandatory |
5.9 | Outbound Long Duration Call | Mandatory |
6.1 | Inbound FAX | Optional |
6.2 | Outbound FAX | Optional |
Last Updated
This document was last updated on 25 July 2024