To create a Dial Profile you must enter a Name to recognize it. Then, we have various options we can modify for this Dial Profile. We can select who is allowed to Transfer or Park the calls. Either the Recipient, Caller, or Both. This will allow the selected option to use the feature code to transfer or park the call.

Note: Be sure that you know why you want to change this option, as stated by the Warning in the module, “Enabling transfer by the caller may allow an outside caller to exploit the PBX by transferring their calls to another external destination when a too permissive Class of Service is defined for the trunk.“

You can also change the Ringback Tone the extensions or features will use. This can playback the default ringing tone, or any Music on Hold class you have created. You can turn off the Ringing Tone altogether as well.

You can then turn on Call Screening and select between having it Disabled, Always Ask, or Only Once. This will prompt the incoming caller to record their name, which will be played back when the call is answered. Finally, you can enter Custom Options, which are custom dial parameters you can run that are not specified in the GUI.

For now, we will continue to use the Default Dial Profile, but if you have made a new one, make sure to click on the Save button in the lower right-hand corner, and apply changes

Here, you will see general configurations for PJSIP. Explaining all the features here is out of the scope of the VitalPBX guide, but we are interested in the bottom section called NAT Settings.

The only two fields we need to configure are External Media Address, External Signal Address, and Local Net. Both External Media and External Signal Addresses will need your Public IP Address. The Local Net field will require the Local Network where your VitalPBX installation is located.

The format for the Local Net field uses the dot cero for the whole network followed by a slash and the Netmask in CIDR or dotted format. E.g. 192.168.0.0/24 or 192.168.168.0.0/255.255.255.0.

With this, you can place calls normally when registered remotely.

As mentioned previously, NAT configurations are mostly necessary when you have your VitalPBX in a local environment and want to publish it with a Public IP Address/FQDN. And as we said, you will need to port forward ports on your router to be able to do this.

The necessary ports are as follows.

• 5060,5061 – These are used for PJSIP registration.
• 10,000-20,000 – These are ports used for RTP traffic (Voice).

Additional ports can be forwarded depending on your use. You can see a full list of ports used under Admin > Firewall > Services.

By default, these are ports used.

All of these ports can be modified with the green Edit button under the Actions column. You can also control how you treat these ports in VitalPBX under Admin > Firewall > Rules.

Here, you can choose if you are going to ACCEPT, DROP, or REJECT incoming packets through these ports. We will see in the VitXi Guide, how we manage the configuration of these ports for additional configurations.

Being able to modify and configure these ports and firewall rules is another way to secure your VitalPBX installation.

This module is mostly ignored by newer installations that start with VitalPBX 4 and will be removed in future versions of VitalPBX as this technology will no longer be available. No new SIP Devices and Trunks can be created. Rest assured that PJSIP is easy to adopt as it is backward compatible with any SIP device and SIP Trunk.

The Device Profiles can be created for PJSIP and IAX2 devices and trunks. Default Profiles for SIP, PJSIP, IAX2, and WebRTC have already been created. These are the ones used by default for these technologies. You can modify these default profiles if needed, but this is uncommon.

To create a profile you only need to select the Profile Type, add a Name, and a Description. You will then find additional configuration parameters to configure the specific profile. If the option you are looking to configure is not available in the UI options, you can go to the Advanced Tab to add the specific header with its value. Afterward, you can Save and Apply Changes.

For PJSIP Device Profiles we find the following options.

Network

• Transport – desired transport configuration.
• Qualify Frequency – the interval between attempts to rate the contact to reach it. If 0
  never qualify. Time in seconds.
• Qualify Timeout – If the contact does not respond to the OPTIONS request before the
  time out, the contact is marked as unavailable. If the value is 0 there is no timeout.
• Force rport – force use of the return port.
• ICE support – enable the ICE mechanism to help traverse NAT.
• Rewrite Contact – this allows the contact header to be rewritten with the source IP
  address port.
• Remove Existing – this allows registration to succeed by displacing any existing
  contacts that now exceed the “Max Contacts” count. Any removed contacts are the
  next to expire. The behavior is beneficial when “Rewrite Contact” is enabled and “Max
  Contacts” is greater than one. The removed contact is likely the old contact created
  by “Rewrite Contact” that the device is refreshing.
• Use AVPF – determine if res_pjsip will use and enforce the use of AVPF for this
  endpoint.
• RTP Symmetric – enforce that RTP must be symmetric.
• RTCP Mux – with this option enabled, Asterisk will try to negotiate the use of the
  rtcp-mux attribute on all media streams. This will result in RTP and RTCP being sent
  and received on the same port. This switches the demultiplexing logic to the
  application rather than the transport layer. This option is useful when interoperating
  with WebRTC endpoints as they enforce the use of this option.
• Asymmetric RTP Codec – allows the send and receive RTP codec to differ.
• Send Diversion Header – send the forward header, transmitting the forwarding
  information to the called user agent.
• Send P-Asserted Identity – send the Header P-Asserted Identity.
• Send Remote-Party-ID – send the Header Remote-Party-ID.

• WebRTC – when set to Yes, this also enables the following settings required for basic
  WebRTC support to work: rtcp_mux, use_avpf, ice_support, and
  use_received_transport.
  Media
• Media Encryption – this determines if res_pjsip will use and enforce the use of media
  encryption for this endpoint.
• Direct Media – this determines if media can flow directly between endpoints.
• Received Media Transport – this determines if res_pjsip will use the media transport
  received in the offer SDP in the corresponding response SDP.
• Optimistic Media Encryption – this determines whether encryption should be used if
  possible, but does not terminate the session if not achieved.
• Disable NAT Direct Media – direct media session disable is updated when NAT
  obstructs the media session.
  DTLS
• DTLS certificate – certificate to use with DTLS connections.
• DTLS Setup – if we are willing to accept connections, connect with the other party, or
  both. Valid options are:
• Active – we want to connect with the other party.
• Passive – we only want to accept connections.
• Actpass – we will do both. This value will be used in outbound SDP when offered and
  for inbound SDP offers when a remote party sends actpass.
• DTLS Verify – verify that the provided peer certificate is valid.
• DTLS Fingerprint Hash – the hash to use for the fingerprint in SDP.
• DTLS Rekey interval – interval in which to renegotiate the TLS session and reactivate
  the SRTP session. If this is not configured or the provided value is 0, reordering will be
  disabled.
  For IAX2 Device Profiles, we have the following options.
  Network
• Host – hostname, or device address.
• Type – this defines the type of device.
• User – this option is a device that makes calls, and requires authentication.
• Peer – this option is a trunk device, accompanied by the Host.
• Friend – this option is a combination of “User” and “Peer”.
• Call Token – this uses requirecalltoken for authentication.
• Qualifier Frequency – this defines the interval of qualifying in seconds. A value of
  zero will disable this feature.
• Qualifier Timeout – this defines the maximum response time in milliseconds before a
  device is considered unreachable. A value of zero will disable this feature.
• Transfer – allow transfers from this device

The first thing we need to do is to create a new Device Profile for PJSIP. Go to Settings > Technology Settings > Device Profiles.

Here, we will select the PJSIP Profile Type. Then, enter a Name and Description to identify this device profile. Under Network, we will set the Transport to TLS. And under Media, we will set the Media Encryption to SDES.

Then click on Save, and then Apply Changes.

Next, we will create a new SSL Certificate. Go to Admin > System Settings > Certificates. In this example, we will be creating a Let’s Encrypt certificate. In this module, you can create self-signed certificates and custom SSL certificates you may acquire with an SSL Certificate vendor. Self-signed may be used in local network environments, but they are not recommended as many browsers consider sites using self-signed certificates risky.

For the Let’s Encrypt certificate, we need to enter a Description to identify the certificate, enter the Hostname for the VitalPBX server, and enter the Owner’s Email address.

When creating a Let’s Encrypt certificate, we support Sub-Domains. This means that under hostname, you can enter the main valid FQDN. Then, you can enter a sub-domain, i.e. sip.mydomain.com, that you can use to access the VitalPBX installation if you use this certificate for an HTTPS connection. You can enter multiple sub-domains in this section. This is helpful if you want to separate different tenants by sub-domain, and still use a single VitalPBX instance.

With the fields configured, click Save.

Now, go to Settings > Technology Settings > PJSIP Settings. Under Certificate select the certificate we just created. If you are using multiple sub-domains, you must also enable the Allow Wildcard Certs just created. If you are using multiple sub-domains, you must also enable the Allow Wildcard Certs option. Then, click on Save and then Apply Changes.

Afterward, we will need to assign the device profile we created to the devices we want to use TLS encryption with. Go to PBX > Extensions > Extensions, and under the device section on the Profile field, select the device profile we created.

All that is left is to register the extensions using the TLS port instead of the default port for PJSIP. By default, this is port 5061. Some devices will require you to enable encrypted calls so you are able to use TLS for the voice packets and change the signaling from UDP to TLS. With this, your devices will have their calls encrypted, making their conversations even more private and secure.