Yealink SRTP

[Scott1234]

In an effort to get every thing squared away with TLS and SRTP, I am reviewing config's and pcap's and question the following, in the built in Yealink common.

#Specify whether to encrypt the SIP messages; 0-Disabled (default), 1-Optional, 2-Forced;
account.{lc}.srtp_encryption = {outbound-secure tcp 1 0}

Where is it pulling outbound-secure from to decide? 

should it not be some thing like this, I just made it up based on how the rest of the config treats TLS using the domain setting.

#Specify whether to encrypt the SIP messages; 0-Disabled (default), 1-Optional, 2-Forced;
account.{lc}.srtp_encryption = {outbound-layer tcp:udp/tcp/tls udp=0 tcp=1 tls=2} 

The entire system is set TLS default my inbound and outbound partners are TLS and SRTP , confirmed with PCAP's, even though the trunks are not forced they do negotiate SRTP as they should because its been offered. 

Carrier -> PBX -> Yealink Phone will be TLS + SRTP on all legs with the original setup {outbound-secure tcp 1 0} which translates into '1-Optional' on the phone its self. 

Yealink Phone -> PBX will never get SRTP negotiated when in '1-Optional' mode the rest of the legs have SRTP. The phone is offering SRTP in the invite, so is the PBX but does not seem to pick it.

I have to use '2-Forced' for outbound calls from the phone to use it, not sure where to look more is it the PBX ignoring it ? or the Phone?

Has any one messed around with it in depth ? Ideally I would like to keep it on Optional to allow the fall back if possible so calls cant fail if some thing goes wrong some where. 

 

 

[Vodia PBX]

19 hours ago, Scott1234 said:

Where is it pulling outbound-secure from to decide?

The outbound-secure checks the MAC, the extension, the tenant, the system and then the default transport provided as argument what transport layer to use. If it tls, it will be secure, otherwise not. 

The whole logic whether TLS can be used or not has become very difficult with all the possibilities to upload certificates, automatically generate certificates from LetsEncrypt, and all sorts of manual override possibilities. The intention is to make this process invisible to the regular user and administrator, but its not always possible... 

We could force the phones to use SRTP when we are using TLS, and this would probably work. However in an effort to minimize trouble (potentially because some admins choose to override settings), we kept is more casual and let the phone also accept regular RTP over an otherwise secure connection. 

Anyhow, so far we had no trouble with the optional SRTP and everyone seems to be happy with it. If you want to enforce SRTP in your organization, you can just "hard code" the srtp_encryption to 2 in the general parameters—if then for whatever reason there is no SRTP, there will be no audio and this would be a precautionary measure.

[Scott1234]

Quote

@Vodia PBX

Yeah but, why doesn't the Yealink <-> PBX leg negotiate to SRTP when the call starts from the handset when 'Optional' is in use. 

When the call comes into the handset from say external source the PBX <-> Yealink leg will negotiate SRTP, as it should. 

The only way to get it to use SRTP when the call is placed from the phone is with it on forced. It's like the PBX isn't prioritizing SRTP in that instance, when it should, and forcing proves it works, when the phone gives it no other option....

The external trunk legs remain with SRTP in all flow cases. 

[Vodia PBX]

Hmm so if you change this in the template it works as it should?

#Specify whether to encrypt the SIP messages; 0-Disabled (default), 1-Optional, 2-Forced;
account.{lc}.srtp_encryption = {outbound-secure tcp 2 0}

Maybe Yealink has changed the behavior in the years since we did this...

[Scott1234]

5 hours ago, Vodia PBX said:

Hmm so if you change this in the template it works as it should?

#Specify whether to encrypt the SIP messages; 0-Disabled (default), 1-Optional, 2-Forced;
account.{lc}.srtp_encryption = {outbound-secure tcp 2 0}

Maybe Yealink has changed the behavior in the years since we did this...

Looking closer into the phone logs its self, even with mode set to 2 forced, its failing to encrypt.

I only became aware of this behaviour as the yealink dm portal generates alerts when calls fail to encrypt. 

Phone's logs show,

 

Jun  9 08:42:17 ATP [1092.1109]: DURL<3+error > [DCMN]download common error, errcode:404, no out.
Jun  9 08:42:17 ATP [1092.1109]: ATP <3+error > https to file failed, code = 404, msg = , retry = 1
Jun  9 08:42:17 sua [1002.1970]: NET <3+error > [255] depth=2:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
Jun  9 08:42:17 sua [1002.1970]: NET <3+error > [255] depth=1:/C=US/O=Let's Encrypt/CN=R3
Jun  9 08:42:17 sua [1002.1970]: NET <3+error > [255] depth=0:/CN=pbxdomain.com
Jun  9 08:42:17 ATP [1092.1109]: DURL<3+error > [DCMN]Recode is 404, Request err.

 

[Scott1234]

I am guessing it's because the phone just needs to be able to read the cert? and its never worked? 

[Vodia PBX]

On 6/9/2023 at 1:49 AM, Scott1234 said:

I am guessing it's because the phone just needs to be able to read the cert? and its never worked? 

Hmm. I am sure it did work at some point, however Yealink used to have the problem that the SIP TLS did not include the TLS/SNI extension which is a problem for multi-tenancy. But if SIP/TLS works, I would not see any problem negotiation the SRTP/SDES keys. 

[Scott1234]

I have reverted from TLS mode to TCP for now, until I can figure out a solution.  If you have any ideas please share. 

As I am wanting to advertise end to end encrypted calls but cant if one leg wont encrypt. 

[Scott1234]

On 6/10/2023 at 10:36 PM, Vodia PBX said:

Hmm. I am sure it did work at some point, however Yealink used to have the problem that the SIP TLS did not include the TLS/SNI extension which is a problem for multi-tenancy. But if SIP/TLS works, I would not see any problem negotiation the SRTP/SDES keys. 

The SDP looks like this with a call starting from the handset. But then proceeds to send as non SRTP. 

Phone -> PBX

Frame 1: 1356 bytes on wire (10848 bits), 1356 bytes captured (10848 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: XXX.XXX.XXX.XXX, Dst: XXX.XXX.XXX.XXX
User Datagram Protocol, Src Port: 12270, Dst Port: XXXX
Session Initiation Protocol (INVITE)
    Request-Line: INVITE sip:XXX@XXXXX.COM:XXXX;user=phone SIP/2.0
    Message Header
    Message Body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): - 20008 20008 IN IP4 XXX.XXX.XXX.XXX
            Session Name (s): SDP data
            Connection Information (c): IN IP4 XXX.XXX.XXX.XXX
            Time Description, active time (t): 0 0
            Media Description, name and address (m): audio 12438 RTP/AVP 8 0 107 9 101 102
            Media Attribute (a): rtcp:12439
            Media Attribute (a): rtpmap:8 PCMA/8000
            Media Attribute (a): rtpmap:0 PCMU/8000
            Media Attribute (a): rtpmap:107 opus/48000/2
            Media Attribute (a): fmtp:107 sprop-maxcapturerate=48000; maxaveragebitrate=40000; maxplaybackrate=48000; useylrtx=1; useinbandfec=1
            Media Attribute (a): rtpmap:9 G722/8000
            Media Attribute (a): ptime:20
            Media Attribute (a): sendrecv
            Media Attribute (a): rtpmap:101 telephone-event/8000
            Media Attribute (a): fmtp:101 0-15
            Media Attribute (a): rtpmap:102 telephone-event/48000
            Media Attribute (a): fmtp:102 0-15
            Media Attribute (a): crypto:1 AES_CM_128_HMAC_SHA1_80 inline:Qd1a3pYU0wuRVFUYIHgjag/i7U05sJy+eNQBAOkr
            Media Attribute (a): crypto:2 AES_CM_128_HMAC_SHA1_32 inline:rq9ThvgXz6vkwdbFZCIfCdR6qGcowDhvNJvTBPKv
            [Generated Call-ID: 0_911050508@192.168.1.33]

PBX -> Phone

Frame 3: 1020 bytes on wire (8160 bits), 1020 bytes captured (8160 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: XXX.XXX.XXX.XXX, Dst: XXX.XXX.XXX.XXX
User Datagram Protocol, Src Port: XXXX, Dst Port: 12270
Session Initiation Protocol (200)
    Status-Line: SIP/2.0 200 Ok
    Message Header
    Message Body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): - 323925493 323925493 IN IP4 XXX.XXX.XXX.XXX
            Session Name (s): -
            Connection Information (c): IN IP4 XXX.XXX.XXX.XXX
            Time Description, active time (t): 0 0
            Media Description, name and address (m): audio 53990 RTP/AVP 8 101
            Media Attribute (a): crypto:1 AES_CM_128_HMAC_SHA1_80 inline:NoxP2O73jCrJ6flyRiTHneE9eC9Ex3wDjB0npLrR
            Media Attribute (a): rtpmap:8 PCMA/8000
            Media Attribute (a): rtpmap:101 telephone-event/8000
            Media Attribute (a): fmtp:101 0-15
            Media Attribute (a): ptime:20
            Media Attribute (a): rtcp-xr:rcvr-rtt=all voip-metrics
            Media Attribute (a): sendrecv
            [Generated Call-ID: 0_911050508@192.168.1.33]

Key's are being offered, but not being accepted. Any ideas on what to look at ? I really want end to end encryption. The phones all talk over TLS no problems, even if you say use only trusted certs on the phone that all works. 

[Scott1234]

When started from the PBX side so, external call. It will use SRTP and this is what the SDP looks like, and the Protocol will be marked as SRTP. And no SRTP fail alerts from Yealink DM/RPS system. 

PBX -> Phone

Session Description Protocol
    Session Description Protocol Version (v): 0
    Owner/Creator, Session Id (o): - 774385152 774385152 IN IP4 XXX.XXX.XXX.XXX
    Session Name (s): -
    Connection Information (c): IN IP4 XXX.XXX.XXX.XXX
    Time Description, active time (t): 0 0
    Media Description, name and address (m): audio 51428 RTP/SAVP 8 101
    Media Attribute (a): crypto:1 AES_CM_128_HMAC_SHA1_32 inline:oP4MFtsvAaIRFPjMEY+vuaRhV0IS+Wu95uRyaiSQ
    Media Attribute (a): rtpmap:8 PCMA/8000
    Media Attribute (a): rtpmap:101 telephone-event/8000
    Media Attribute (a): fmtp:101 0-15
    Media Attribute (a): ptime:20
    Media Attribute (a): rtcp-xr:rcvr-rtt=all voip-metrics
    Media Attribute (a): sendrecv
    [Generated Call-ID: 42ee1295@pbx]

Phone -> PBX

Session Description Protocol
    Session Description Protocol Version (v): 0
    Owner/Creator, Session Id (o): - 20009 20009 IN IP4 XXX.XXX.XXX.XXX
    Session Name (s): SDP data
    Connection Information (c): IN IP4 XXX.XXX.XXX.XXX
    Time Description, active time (t): 0 0
    Media Description, name and address (m): audio 12440 RTP/SAVP 8 101
    Media Attribute (a): rtpmap:8 PCMA/8000
    Media Attribute (a): ptime:20
    Media Attribute (a): rtpmap:101 telephone-event/8000
    Media Attribute (a): fmtp:101 0-15
    Media Attribute (a): crypto:1 AES_CM_128_HMAC_SHA1_32 inline:ttCdLX6ZvWf7NoUibr+tyZ4d2pQx8dtMhXb98Tdn
    Media Attribute (a): sendrecv
    Media Attribute (a): rtcp:12441
    [Generated Call-ID: 42ee1295@pbx]

From Yealink Site,

https://support.yealink.com/en/portal/knowledge/show?id=5acd46f5b10e6e087e86b614

[Vodia PBX]

Hmm this all looks good. Don't be fooled by the PCAP traces on the PBX, they are always decrypted because otherwise we would not be able to hear anything. You could double check from the phones built-in PCAP.