Cloud Hosted FreePBX (Public IP)
Asterisk: 16.9.0

I have recently switched over and started using a different provider (Voyant -> Twilio) because they are discontinuing their SIP trunking services. I also wanted to implement secure trunking, which has worked, no problem. So it seems I can accomplish TLS/SRTP from server to provider. But I am having difficulty accomplishing the same from server to endpoints, which are all Yealink T48S phones. Currently they will register and work fine using UDP 5060. My test phone seems to register just fine via TLS, but SRTP won’t negotiate and connect. So even when I try *60 from the phone, I get “call failed, Not acceptable here”. I need to know what I am doing wrong, hopefully a second pair of eyes or two can identify what I’m missing.

Asterisk SIP Settings:

  • Valid and active LE Certificate selected
  • Verify Client / Server = No
  • UDP - 5060 - Enabled
  • TLS - 5061 - Enabled
    (Asterisk has been fully stopped and restarted in CLI when those above settings were originally adjusted.)

I only have ulaw codec selected.

Underneath my test user I have the following set:

  • Transport:
  • Media Encryption: SRTP via in-SDP
  • Allow Non-Encrypted Media: No

Settings on the Yealink Phone:

  • Sip Server: Pointing to my cloud FQDN
  • Sip Server Port: 5061
  • Sip Server Transport: TLS
  • Advanced -> RTP Encryption (SRTP): Compulsory
  • Security -> Trusted Certificates -> Only Accept Trusted Certificates: Disabled (For the sake of troubleshooting)

Turning off the media encryption for the user and in the Yealink phone, calls will work just fine. But they fail as soon as I enable. Anyone have any ideas?


(Tom Ray) #2

When did Voyant announce they were discounting SIP trunking services? Seems odd for a carrier to do that.


Right?! Seemed Odd to me too! I received a generic email last week about services getting terminated on my account by 7/15/20. Since I only use SIP trunks with them, it raised some red flags because I hadn’t requested to cancel anything. I emailed their support for more information, and here was their response:

I wanted to let you know that Inteliquent and Voyant have integrated their operations to better serve customers and to bring more services to the customers of each business. We are merging into a single company, but we are not moving away from the markets and customers that Voyant serves today, with the goal to better serve the Voyant customers and markets. With this integration we are consolidating services, and due to the amount of supported SIP Trunking platforms that exist today, only 3 will be supported moving forward. Unfortunately, the Voyant SIP Trunking platform that you are on today is not one of the platforms that will be supported moving forward and will be eventually discontinued and closed.
So that is the reason our Management team decided to send out this notice, so you can migrate your services to another provider. If you wish to stay in Voyant’s network, we can offer to migrate you to our Vitelity platform (, which also offers SIP Trunking services. However, you will need to sign an agreement for spending at least $300 USD per month in usage (call traffic, DIDs, etc). If you are interested in that, please let me know so I can get a Sales Engineer to reach out. If you wish to move away from Voyant, you may want to consider QuestBlue, which is also a SIP Trunking and Hosted PBX provider. To begin the onboarding process with QuestBlue, please call (919) 443-1617 and select option 1 or email
In any case, we will do our best to assist you during this migration process, so please let me know if we can help with that.

(Jared Busch) #4

TLS and SRTP work perfectly on the T4S series phones but does depends on the firmware version and who your certificate CA is.

The T4G series (EoL now) have a lot more issues.

Even the current T5 series has issues with certs depending on the CA and the firmware version you have on the phone.


Well this raises a couple of questions. Since this is a Let’s Encrypt certificate that I have selected, do I need to load that into the Yealink phones’ trusted certificate manager? Besides that, I had disabled requiring a valid certificate anyway. I wouldn’t see any reason why it wouldn’t work perfectly, but just the SRTP doesn’t work for me. What do I need to change or try? If it ultimately comes down to needing that certificate loaded on the phones, is there anyway to do that via EPM? Even with base file edits, because I know I have to add manual entries to enable the settings for TLS/SRTP as it is.

The firmware version on these phones is

I am currently trying to test this on a T42S as well, also running the same firmware version,


Please confirm that Media Encryption for the extension is set to SRTP via in-SDP.

If that’s not your issue, at the Asterisk command prompt, type
pjsip set logger on
make a failing call to *60, paste the log at and post the link here.


And yet they are still selling it:


Maybe you were targeted by a competitor.

(Richard Smith) #8

Something I noticed recently when testing TLS/SRTP was that if the extension were created prior to the change to TLS I had to manually set the extension to use TLS transport in the extension setting in FreePBX. Having it set to auto didn’t seem to work.


It seems like it, but this was received directly from Voyant support, I submitted a ticket with them and that was one of their support agents responses. I did not respond to the initial email, I opened a new ticket directly to Voyant myself.


I do not have the extension set to auto, I do have it set to The TLS works fine though, so I know that part is good. It registers via TLS just fine, it seems to not want to encrypt the media (SRTP) when I enable that part though.


Here are some screenshots to confirm my settings:


(Jared Busch) #12

I am assuming you enabled it in the phone also right?


Yes that is correct.


Please paste a log with SIP trace and post the link here.


Here is the trace of that. I have masked my domain name and IP addresses.


Taken at face value, the 488 means that the list of ciphers enabled in pjsip does not include the AES_CM_128_HMAC_SHA1_80 or AES_CM_128_HMAC_SHA1_32 offered by the phone.

Normally, FreePBX does not restrict the list. What does the Asterisk CLI show for
pjsip show transport

If the cipher field is blank, try sending an incoming call to the extension and see which ciphers are offered by pjsip.


Running the command you recommended does indeed show the cipher field blank.

So I created a secondary test user signing in to a Bria softphone. First I made this second user register like the rest, via UDP 5060 and had encryption turned off. Phone rings and call is established, but no audio. Here is that trace:

Then I switched that second test user to use TLS/SRTP. This time the call doesn’t connect and seems to give the same error. Here is that trace:


This trace is very strange. I would expect (if things were working properly) unencrypted media between 298 and Asterisk, and encrypted media between 299 and Asterisk. However, Asterisk offered unencrypted media to 299, and 299 accepted it! So, I suspect that the Media Encryption setting for 299 was not processed properly, which would also explain the 488 error given to 299 in the older post.

Please post the output of
pjsip show endpoint 299


Here is the output for 299:

 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:  <criteria.........................>
    Channel:  <ChannelId......................................>  <State.....>  <Time.....>
        Exten: <DialedExten...........>  CLCID: <ConnectedLineCID.......>

 Endpoint:  299/299                                              Not in use    0 of inf
     InAuth:  299-auth/299
        Aor:  299                                                2
      Contact:  299/;transport e75303802f Avail        21.956
  Transport:               tls      3     96

 ParameterName                      : ParameterValue
 100rel                             : yes
 accept_multiple_sdp_answers        : false
 accountcode                        :
 acl                                :
 aggregate_mwi                      : true
 allow                              : (ulaw)
 allow_overlap                      : true
 allow_subscribe                    : true
 allow_transfer                     : true
 aors                               : 299
 asymmetric_rtp_codec               : false
 auth                               : 299-auth
 bind_rtp_to_media_address          : false
 bundle                             : false
 call_group                         :
 callerid                           : "Test User" <299>
 callerid_privacy                   : allowed_not_screened
 callerid_tag                       :
 connected_line_method              : invite
 contact_acl                        :
 context                            : from-internal
 cos_audio                          : 5
 cos_video                          : 4
 device_state_busy_at               : 0
 direct_media                       : true
 direct_media_glare_mitigation      : none
 direct_media_method                : invite
 disable_direct_media_on_nat        : false
 dtls_auto_generate_cert            : No
 dtls_ca_file                       :
 dtls_ca_path                       :
 dtls_cert_file                     : /etc/asterisk/keys/default.crt
 dtls_cipher                        :
 dtls_fingerprint                   : SHA-256
 dtls_private_key                   : /etc/asterisk/keys/default.key
 dtls_rekey                         : 0
 dtls_setup                         : actpass
 dtls_verify                        : Yes
 dtmf_mode                          : rfc4733
 fax_detect                         : false
 fax_detect_timeout                 : 0
 follow_early_media_fork            : true
 force_avp                          : false
 force_rport                        : true
 from_domain                        :
 from_user                          :
 g726_non_standard                  : false
 ice_support                        : false
 identify_by                        : username,ip
 ignore_183_without_sdp             : false
 inband_progress                    : false
 incoming_mwi_mailbox               :
 language                           : en
 mailboxes                          :
 max_audio_streams                  : 1
 max_video_streams                  : 1
 media_address                      :
 media_encryption                   : dtls
 media_encryption_optimistic        : false
 media_use_received_transport       : false
 message_context                    :
 moh_passthrough                    : false
 moh_suggest                        : default
 mwi_from_user                      :
 mwi_subscribe_replaces_unsolicited : no
 named_call_group                   :
 named_pickup_group                 :
 notify_early_inuse_ringing         : false
 one_touch_recording                : true
 outbound_auth                      :
 outbound_proxy                     :
 pickup_group                       :
 preferred_codec_only               : false
 record_off_feature                 : apprecord
 record_on_feature                  : apprecord
 refer_blind_progress               : true
 rewrite_contact                    : true
 rpid_immediate                     : false
 rtcp_mux                           : false
 rtp_engine                         : asterisk
 rtp_ipv6                           : false
 rtp_keepalive                      : 0
 rtp_symmetric                      : true
 rtp_timeout                        : 0
 rtp_timeout_hold                   : 0
 sdp_owner                          : -
 sdp_session                        : Asterisk
 send_connected_line                : yes
 send_diversion                     : true
 send_pai                           : false
 send_rpid                          : false
 set_var                            :
 srtp_tag_32                        : false
 sub_min_expiry                     : 0
 subscribe_context                  :
 suppress_q850_reason_headers       : false
 t38_udptl                          : false
 t38_udptl_ec                       : none
 t38_udptl_ipv6                     : false
 t38_udptl_maxdatagram              : 0
 t38_udptl_nat                      : false
 timers                             : yes
 timers_min_se                      : 90
 timers_sess_expires                : 1800
 tone_zone                          :
 tos_audio                          : 184
 tos_video                          : 136
 transport                          :
 trust_connected_line               : yes
 trust_id_inbound                   : true
 trust_id_outbound                  : false
 use_avpf                           : false
 use_ptime                          : false
 user_eq_phone                      : false
 voicemail_extension                :
 webrtc                             : no


Sounds like a bug somewhere. You have Media Encryption for 299 set to SRTP via in-SDP, but pjsip thinks you selected DTLS. What does pjsip.endpoint.conf have?