Skip to end of metadata
Go to start of metadata

Overview

Digium D-Series phones, beginning with D6x phone firmware 2_2_0_4_5a54ff2 and D80 firmware 1_12_0, support SDES SRTP encrypted media and TLS-encrypted signaling.  This page provides a brief overview of the capabilities and the setup procedure.

Limitations

As of firmware 2_2_0_4_5a54ff2, Digium phones do not validate the SIP server's certificate, nor can they be loaded with a client certificate to present to Asterisk.  Future releases of phone firmware may eliminate these limitations.  

As of firmware 2_3_9, Digium phones no longer support anonymous or null ciphers.

As of firmwares 2_9_0 and 1_12_0, D-Series phones now validate the SIP Server's certificate by default.

Getting Started - Certificates

n order to setup a TLS transport, Asterisk requires the use of certificates.  A good description of the process of generating a self-signed certificate authority, along with the requisite server certificate is available on the Secure Calling Tutorial wiki page.  

Best practice, however, is to use a publicly-signed certificate.  D-Series phones include a current (as of the time of the firmware build date) copy of the publicly-signed root CA list.  Thus, they will be able to properly validate any server using a publicly-signed certificate. If the server does not use a publicly-signed certificate, then a copy of the privately-signed root CA must be loaded onto the phone before it will be able to make a SIP TLS connection to the SIP server.

SIP RFC 5922 section 7.2 forbids the use of wildcard certificates for TLS signaling. For many deployments of servers, this can present a problem.  Where these servers are often deployed with wildcard certificates for HTTPs traffic, implementors may assume they can do the same thing for SIP.  Per the RFC, one cannot.  In order to provide assistance for wildcard implementations, D-Series phone firmwares, beginning with 2_9_2 and 1_12_1 provide a setting, tls_allow_wildcard_certs, disabled by default, that will permit the telephone to accept a wildcard certificate as valid for SIP TLS signaling.

Asterisk TLS Transport

Once certificates have been generated and installed for Asterisk's use, a TLS signaling transport must be set up for use by PJSIP.  The transport should look similar to:

[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061
cert_file=/etc/asterisk/keys/asterisk.crt
priv_key_file=/etc/asterisk/keys/asterisk.key
method=sslv23

Here, we've declared a new transport type, that will be using the tls protocol, bound to all local IPv4 addresses (0.0.0.0) on the default port for TLS (5061).  We've also provided Asterisk with the asterisk.crt cert_file and the asterisk.key private key file.  And, importantly, we've declared that the TLS method we want to use is sslv23.  This method actually enables SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2 communication methods.

Restart Asterisk, and, from the Asterisk CLI, perform:

pjsip show transports

If you see:

asterisk*CLI> pjsip show transports 
Transport:  <TransportId........>  <Type>  <cos>  <tos>  <BindAddress....................>
==========================================================================================
Transport:  transport-tls             tls      0      0  0.0.0.0:5061
asterisk*CLI>

The TLS transport has been created successfully.

If it is not seen, then your system may not be compiled with SSL support or you may have introduced a typographic error into the configuration.

Icon

Adding, removing or changing PJSIP transports within Asterisk requires a restart. Adding a new transport and performing an Asterisk reload is not effective.

TLS Endpoint Considerations

Endpoints setup in Asterisk to use connection-based protocols such as TCP or TLS should be configured with the rewrite_contact enabled.  It is disabled by default.  Additionally, endpoints using TCP or TLS cannot have an explicit transport attached to the endpoint.  Therefore, and endpoint configured for TLS should include:

[myendpoint]
type=endpoint
...
rewrite_contact=yes
...

Asterisk SDES SRTP Encryption

Media encryption for a PJSIP endpoint in Asterisk is set using the media_encryption option, e.g.:

[myphone]
type=endpoint
aors=myaor
auth=myauth
disallow=all
allow=g722
callerid="Fancy Pants" <101>
[email protected]
media_encryption=sdes

By default, the media_encryption option is null, disabled.  Once it is enabled for an endpoint, it can be made effective by performing a reload from the Asterisk CLI.  To check if an endpoint is configured for SDES SRTP media encryption, you can perform pjsip show endpoint <endpoint identifier> from the Asterisk CLI.  Look for the media_encryption display line:

asterisk*CLI> pjsip show endpoint 104 
 Endpoint:  <Endpoint/CID.....................................>  <State.....>  <Channels.>
    I/OAuth:  <AuthId/UserName...........................................................>
        Aor:  <Aor............................................>  <MaxContact>
      Contact:  <Aor/ContactUri..........................> <Hash....> <Status> <RTT(ms)..>
  Transport:  <TransportId........>  <Type>  <cos>  <tos>  <BindAddress..................>
   Identify:  <Identify/Endpoint.........................................................>
        Match:  <ip/cidr.........................>
    Channel:  <ChannelId......................................>  <State.....>  <Time.....>
        Exten: <DialedExten...........>  CLCID: <ConnectedLineCID.......>
==========================================================================================
 Endpoint:  104/104                                              Not in use    0 of inf
     InAuth:  104/104
        Aor:  104                                                1
      Contact:  104/sip:[email protected]:35833;transport=T 7351e70801 Unknown         nan
 ParameterName                      : ParameterValue
 ===========================================================
 100rel                             : yes
 accountcode                        : 
 acl                                : 
...
 media_encryption                   : sdes
...

Digium Phone Settings

DPMA

Use of TCP or TLS signaling with DPMA and Digium phones requires Asterisk 13.11.0 or greater.

When using the DPMA to configure phones, TLS signaling is setup first in the mDNS broadcast.

mDNS Broadcast

To setup DPMA's mDNS broadcast to use advertise TLS, a new configuration option has been added for the [general] section, mdns_transport, and can be used such as:

[general]
globalpin=1234
userlist_auth=disabled
config_auth=disabled
mdns_address=server.example.com
mdns_port=5061
mdns_transport=tls
service_name=Asterisk
service_discovery_enabled=yes
file_directory=/var/lib/asterisk/digium_phones

With this set, DPMA will broadcast that a phone should connect to it using TLS signaling on port 5061.

Phone Settings

In order for the phone to retrieve its configuration from DPMA properly, and for the phone to be configured to register to Asterisk using TLS, and for the phone to be configured to encrypt RTP media, the following phone configuration elements and options should be considered:

  • config_server_url
  • host_primary port
  • host_primary transport
  • host_primary media_encryption

First, as we know from our discussion in Advanced DPMA Configuration, the config_server_url option tells the telephone where to go to retrieve its configuration and communicate with DPMA.  Normally, for a UDP-based connection, this option might be configured as such:

 

<?xml version="1.0" ?>
<config>
    <setting id="config_server_url" value="sip:[email protected]:5060" />
</config>

 

In order to specify that we want to communicate with the server using TLS, we need to point to the TLS port that the SIP server presents, e.g. 5061, and append ";transport=tls" to the value, e.g.:

 

<?xml version="1.0" ?>
<config>
    <setting id="config_server_url" value="sip:[email protected]:5061;transport=tls" />
</config>

 

Next, we need to direct the telephone to register and communicate with the server using TLS.  We'll also go ahead and tell it to encrypt the media.  This is accomplished in the host_primary definition of the account using the porttransport, and media_encryption parameters as such:

 

<?xml version="1.0" ?>
<config>
    ...
    <accounts>
        <account index="0" status="1" register="1" account_id="101" username="101" authname="101" password="1234" passcode="1234" line_label="Bobby J" caller_id="Bobby J" dial_plan="[0-8]xx">
            <host_primary server="asterisk.example.com" port="5061" transport="tls" media_encryption="sdes" />
        </account>
    </accounts>
</config>

 

Phone Settings for old-style DPMA key-value pairs:

In order for the phone to retrieve its configuration from DPMA singing the older-style DPMA key-value pairs, and for the phone to be configured to register to Asterisk using TLS, the phone's DPMA network must be configured for TLS.  This is accomplished with the new transport network option.  It is set such as:

[tls-network]
type=network
alias=TLS Network
cidr=0.0.0.0/0
registration_address=server.example.com
registration_port=5061
transport=tls
file_url_prefix=http://server.example.com/digium_phones
ntp_server=0.digium.pool.ntp.org
network_vlan_discovery_mode=NONE
sip_dscp=24
rtp_dscp=46
 

A phone can be configured for TLS also by specifying transport=tls on the phone's primary line configuration. The transport option, when defined for a phone's primary line, will override the network section transport settings. Be careful, though, as using one network for UDP and TLS can prove difficult, given that they typically operate on different ports.

When using the DPMA to configure phones, SDES SRTP media encryption is setup in one area:

  1. phone line

Media encryption is setup on the phone's line settings using the media_encryption option, such as:

[myline]
type=line
media_encryption=sdes
line_label=Fancy Pants
[email protected]

When the phone's line has media_encryption set to sdes, the phone will be configured to perform SDES SRTP encryption.

Media Crypto Suite

D-Series phones support only AES_CM_128_HMAC_SHA1_80.

D-Series phones do not support AES_CM_128_HMAC_SHA1_32 nor F8_128_HMAC_SHA1_80.

D-Series phones do not perform optimistic SRTP encryption. When SDES SRTP encryption is enabled on the phone, the phone will INVITE using RTP/SAVP.  Incoming INVITES not using RTP/SAVP will be rejected.

Signaling Ciphers

Setting PJSIP's TLS method to sslv23 should provide compatibility.  D-Series phones support TLS v1.0, TLS v1.1, and TLS v1.2.  SSLv2 and SSLv3 are not supported.

If a specific cipher is desired, the following may be used with Digium phones:

 Digium Phone TLS Ciphers

RC4-SHA, RC4-MD5

AES128-SHA, AES256-SHA
CAMELLIA128-SHA, CAMELLIA256-SHA
SEED-SHA

 

Versions of firmware prior to 2.3.9 also supported the following, additional ciphers:

 Digium Phone older firmware TLS Ciphers

 

DES-CBC-SHA, DES-CBC3-SHA
ECDHE-RSA-RC4-SHA, ECDHE-RSA-DES-CBC3-SHA, ECDHE-RSA-AES128-SHA, ECDHE-RSA-AES256-SHA
AECDH-RC4-SHA, AECDH-DES-CBC3-SHA, AECDH-AES128-SHA, AECDH-AES256-SHA


On the Phone

A Digium phone indicates to the user when TLS signaling and/or SDES SRTP are enabled for a call with a shield indicator on the line, denoting TLS, and a shield indicator for the call disposition, denoting SRTP, as such:

Troubleshooting

If the phone fails to connect to the server, it may show an error message indicating the specific TLS error.  In the event that it does, the following table provides the definitions of the errors:

Error Bitmask
Error
Error Definition
0x0000 0001EISSUER_NOT_FOUNDIssuer cert not found
0x0000 0002EUNTRUSTEDCert untrusted
0x0000 0004EVALIDITY_PERIODCert expired or not yet valid
0x0000 0008EINVALID_FORMATSome cert fields have invalid format
0x0000 0010EINVALID_PURPOSECert can't be used for specified purpose
0x0000 0020EISSUER_MISMATCHIssuer info in cert does not match candidate issuer
0x0000 0040ECRL_FAILURECRL cert could not be found or read
0x0000 0080EREVOKEDCert has been revoked
0x0000 0100ECHAIN_TOO_LONGCert chain length too long
0x4000 0000EIDENTITY_NOT_MATCHServer identity mismatch
0x8000 0000EUNKNOWNUnknown verification error

A typical error response might be something like 0x400000022, which would be EIDENTITY_NOT_MATCH, EISSUER_MISMATCH, EUNTRUSTED

  • No labels