PJSIP Configuration
Important Update: October 06, 2026
Scopserv-telephony25-8.2.0.0.20261005 now provides remarkable chan_pjsip and app_queue enhancements
To take advantage of these enhancements you must fully update your ScopTEL server packages.
chan_sip to chan_pjsip migration Shared Device usernames <authname>_[23]
- ScopTEL now creates additional AOR records in /etc/asterisk/<tenant>/pjsip.conf for each chan_sip legacy <authname>_[23] and binds all AOR records to the extension.
- This binding guarantees foolproof migration from chan_sip to chan_pjsip by preserving authnames and binding all chan_pjsip AORS as members of app_queue.
- This means that all Shared Devices and ScopLINK-UPA accounts will ring if their Extension is a Member of a Queue (Dynamic or Static Members).
- This feature ensures the migration of all Shared Device users when migrating a server from chan_sip to chan_pjsip. This means that SCOPCOMM chan_sip accounts previously configured to use <authname>_[23] will continue to work after the SIP driver migration without any user intervention or forced resending of SCOPCOMM QR codes.
- ScopTEL now creates additional AOR records in /etc/asterisk/<tenant>/pjsip.conf for each chan_sip legacy <authname>_[23] and binds all AOR records to the extension.
- This binding guarantees foolproof migration from chan_sip to chan_pjsip by preserving authnames and binding all chan_pjsip AORS as members of app_queue.
- This means that all Shared Devices and ScopLINK-UPA accounts will ring if their Extension is a Member of a Queue (Dynamic or Static Members).
- This feature ensures the migration of all Shared Device users when migrating a server from chan_sip to chan_pjsip. This means that SCOPCOMM chan_sip accounts previously configured to use <authname>_[23] will continue to work after the SIP driver migration without any user intervention or forced resending of SCOPCOMM QR codes.
Device Provisioning should select the preferred transport and SRTP options
- Transports are a negotiation initiated by the User Agent, so as long as the User Agent is configured to use TLS/SRTP then it will continue to do so and AUTO transport allows any supported transport to be negotiated even among concurrent Shared Device logins. Configuring the transport manually disallows all other transports during negotiation. Setting to AUTO allows all. Enabling SRTP on the Phone Options enforces TLS/SRTP sdes on SCOPCOMM and any other registered User Agent so each User Agent must be provisioned with matching TLS/SRTP options in their configuration files. The SCOPCOMM xml provisioning file is automatically tls/sdes enforced if the Phone Options SRTP option is enabled.
- Transports are a negotiation initiated by the User Agent, so as long as the User Agent is configured to use TLS/SRTP then it will continue to do so and AUTO transport allows any supported transport to be negotiated even among concurrent Shared Device logins. Configuring the transport manually disallows all other transports during negotiation. Setting to AUTO allows all. Enabling SRTP on the Phone Options enforces TLS/SRTP sdes on SCOPCOMM and any other registered User Agent so each User Agent must be provisioned with matching TLS/SRTP options in their configuration files. The SCOPCOMM xml provisioning file is automatically tls/sdes enforced if the Phone Options SRTP option is enabled.
chan_sip to chan_pjsip walkthrough
Review and edit the Extensions transport settings and check for AUTO
- It is highly recommended that for each extension configured in ScopTEL that the Extension|Phone|Options|Transport selection is set to AUTO
- Setting the transport to AUTO allows the User Agent to choose its preferred signalling and RTP transports. And this allows each <authname>_[23] AOR to accept any combination of UDP, TCP, TLS/SRTP transports.
- This setting can be quickly changed for all Extensions using the Mass Operations Tool. If the extension was previously configured to use SRTP Enabled then the extension will continue to use SRTP regardless of the Extension's transport selection.
- Setting the transport to AUTO allows the User Agent to choose its preferred signalling and RTP transports. And this allows each <authname>_[23] AOR to accept any combination of UDP, TCP, TLS/SRTP transports.
- This setting can be quickly changed for all Extensions using the Mass Operations Tool. If the extension was previously configured to use SRTP Enabled then the extension will continue to use SRTP regardless of the Extension's transport selection.
Using the Mass Operations Tool to select Automatic Transport En Masse
This release also adds support for the ScopLINK-UPA
The ScopLINK-UPA is ScopServ's groundbreaking WebRTC based multi-channel client.
It is entirely web based and provides exceptional call control and productivity enhancements by integrating multiple applications into a single clientless installation.
To enable the ScopLINK-UPA you need to purchase licenses for your server.
Enabling the ScopLINK-UPA is very straight forward.
Either enable it per extension or use the Mass Operations tool to add the configuration for each Extension.
The configured result will display if you edit the Extension
If you want the SCOPCOMM application to use SRTP then set the SCOPCOMM Transport to TLS and enable SRTP in the Phone Options.
You can also use the Mass Operations tool to change the SRTP options.
You can also use the Mass Operations tool to change the SRTP options.
Version History
scopserv-telephony25-7.87.0.0.20260112
This version fully supports SIP Trunk Registrations and Contact Header Matching required by Videotron.A new feature was also added to support SIP Identity using CIDR IP address blocks.
If you must reset the ScopCOMM Mobile app settings and allow a new QR code to be scanned. Open the ScopCOMM App and tap on the 3 dots to enter the configuration menu.
Tap on Reset Application to remove the current configuration since it's no longer valid.
The user must check their email for the new QR Code and scan the code into the ScopCOMM app.
The ScopCOMM app should automatically register with the server using the updated registration credentials.
- Feature/Caveat: Any Hotdesk extensions or Agent members will also ring registered Shared Devices concurrently when the primary extension is called.
- SRTP/TLS support is greatly improved.
- Load improvements, concurrent channels should improve.
- T.38 Fax transmissions will no longer use chan_sip so fax performance should improve.
- SIP VoIP Interfaces will use Identify and other parameters to check INVITE's for the proper Class of Service lookup. This fixes a known issue where multiple friend registrations to the same IP address/registrar fail to pass the Incoming Class of Service lookup when the incoming INVITE is parsed. This means it is no longer necessary to use the Multiple Trunk feature on Incoming Lines.
- Caveat: It is possible to toggle a server between chan_sip and chan_pjsip but this is a global change and effects all tenants. Only one channel driver can be selected per server and the recommendation is chan_pjsip.
- Caveat: Asterisk sip CLI commands are replaced with pjsip commands. Example: 'sip show peers' becomes 'pjsip show aors'. This does not affect ScopSTATS reports in any way.
- Greatly improved support for WebRTC using wss transport.
- chan_pjsip supports AUTO SIP transport (default)
- This allows connecting User Agents to select their transport; this in turn supports Shared Devices registered to a single extension (AOR) using client unique transports per device.
Example:
Deskphone, TLS/SRTP
ScopServ User Access Portal (UPA)
WebRTC DTLS with ICE
SCOPCOMM Mobile App using TLS/SRTP
This version fully supports SIP Trunk Registrations and Contact Header Matching required by Videotron.
- This allows connecting User Agents to select their transport; this in turn supports Shared Devices registered to a single extension (AOR) using client unique transports per device.
Example:
Deskphone, TLS/SRTP
ScopServ User Access Portal (UPA)
WebRTC DTLS with ICE
SCOPCOMM Mobile App using TLS/SRTP
New Feature Identify Match Addresses
Additional IP addresses or CIDR network blocks for identifying incoming traffic. Supports CIDR notation (e.g., 192.168.1.0/24, 10.0.0.0/8). Multiple entries separated by commas or newlines. Used for carriers with multiple SBC addresses.
Source IP routing can now be allowed by CIDR blocks using a single trunk configuration!
New Feature Match Header Mode
Some carriers (Videotron) require Contact Header Matching on INVITE's so Contact Header matching has been added to username and auth_username identify methods.
If you select Contact Extension Matching it is Mandatory to enter the matching Contact Extension in the text field.
This Feature is only available when the trunk is configured to Register
New Feature Enable Contact (AOR)
Enabling this setting will specify the aor/contact for this trunk.
WARNING Enabling Proxy Settings will ALWAYS overwrite the From Header with the username.
If your carrier is not honouring P-Asserted or RPID values and requires the From header to provide the callerid information for the call (Videotron) then you MUST NOT enable Proxy Settings!
How to toggle Channel Drivers between chan_sip to chan_pjsip
Edit Telephony|Configuration|Telephony Modules|Protocols|Module Version and select PJSIP from the drop list.
Save
Commit
Restart Services to complete migration to chan_pjsip
Restart Telephony Server, FastAGI Server and Live Monitoring daemons (Realtime) to Finish changing the channel driver to chan_pjsip (this can be done with root/admin GUI access or by SSH). Or simply reboot the server after the Telephony Dial Plan and APS Commits.
To revert to chan_sip
Edit Telephony|Configuration|Telephony Modules|Protocols|Module Version and select SIP from the drop list by referring to the previous example.
Save
Commit
Edit Telephony|Configuration|Telephony Modules|Protocols|Module Version and select SIP from the drop list by referring to the previous example.
Save
Commit
Restart Services to revert channel driver to chan_sip
Restart Telephony Server, FastAGI Server and Live Monitoring daemons (Realtime) to Finish changing the channel driver to chan_pjsip (this can be done with root/admin GUI access or by SSH). Or simply reboot the server after the Telephony Dial Plan and APS Commits.
Restart Telephony Server, FastAGI Server and Live Monitoring daemons (Realtime) to Finish changing the channel driver to chan_pjsip (this can be done with root/admin GUI access or by SSH). Or simply reboot the server after the Telephony Dial Plan and APS Commits.
P-Asserted Migration pre-requisites for STIR/SHAKEN/ATIS support.
Servers configured with RPID caller ID support should be migrated to P-Asserted because RPID cannot support Caller ID enhancements necessary to implement STIR/SHAKEN/ATIS protocols. P-Asserted will also support Caller ID updates on transferred calls. STIR/SHAKEN/ATIS is a new module provided by chan_pjsip
Servers configured with RPID caller ID support should be migrated to P-Asserted because RPID cannot support Caller ID enhancements necessary to implement STIR/SHAKEN/ATIS protocols. P-Asserted will also support Caller ID updates on transferred calls. STIR/SHAKEN/ATIS is a new module provided by chan_pjsip
Migrating to P-Asserted
Use the Extensions|Mass Operations|Caller ID tool to mass edit extensions from RPID to P-Asserted.
Change each VoIP Interface to send P-Asserted.
Commit
Polycom, Snom, Aastra/Mitel/Grandstream phones by default use PAI
Yealink phones configured in the ScopTEL APS may require a change to each MAC/Line to enable PAI-FROM.
Verify each line assignment is set to PAI-FROM for all MAC addresses.
Once each MAC address/Line is correctly configured Commit APS changes and reboot all Yealink phones to acquire the new setting.
Use the Extensions|Mass Operations|Caller ID tool to mass edit extensions from RPID to P-Asserted.