Rejecting crypto attribute - TLS SIP and SRTP for Inbound Voice Calls. Azure Deployment

Asterisk Asterisk SIP
1

Hello,

I have been using Asterisk certified/13.18-cert2 for the past year without any problems but, this is the first time I’m trying to encrypt the SIP trunk from my provider. This Asterisk server is only for Inbound calls only. I have managed to encrypt SIP with TLS but, I am having trouble with SRTP for Voice. I’m not sure where to start troubleshooting. The SIP provider doesn’t have an answer. I think this is their first too.

any help and or direction would be very much appreciated.

Thank You!

This is the message i receive when calling into the server.

Found peer ‘TLS-SIP’ for ‘1234567890’ from 1.1.1.71:5061
== Using SIP RTP CoS mark 5
Found RTP audio format 0
Found RTP audio format 18
Found RTP audio format 101
Found audio description format telephone-event for ID 101
[Jan 13 04:25:17] NOTICE[71515][C-00000000]: sdp_srtp.c:327 ast_sdp_crypto_process: Rejecting crypto attribute ‘1 AES_CM_128_HMAC_SHA1_80 inline:fPCkDUMHZlOH8axCwBcCWAhuolamEmnCa7SNL8C5|2^20’: lifetime ‘1048576.000000’ too short
[Jan 13 04:25:17] NOTICE[71515][C-00000000]: sdp_srtp.c:340 ast_sdp_crypto_process: SRTP crypto offer not acceptable: ‘1 AES_CM_128_HMAC_SHA1_80 inline:fPCkDUMHZlOH8axCwBcCWAhuolamEmnCa7SNL8C5|2^20’
[Jan 13 04:25:17] NOTICE[71515][C-00000000]: sdp_srtp.c:327 ast_sdp_crypto_process: Rejecting crypto attribute ‘2 AES_CM_128_HMAC_SHA1_32 inline:Dzt6HvFbcxwmWNmPTZdDFhwciPqdTE/PG3Rl29kN|2^20’: lifetime ‘1048576.000000’ too short
[Jan 13 04:25:17] NOTICE[71515][C-00000000]: sdp_srtp.c:340 ast_sdp_crypto_process: SRTP crypto offer not acceptable: ‘2 AES_CM_128_HMAC_SHA1_32 inline:Dzt6HvFbcxwmWNmPTZdDFhwciPqdTE/PG3Rl29kN|2^20’
[Jan 13 04:25:17] WARNING[71515][C-00000000]: chan_sip.c:10808 process_sdp: Rejecting secure audio stream without encryption details: audio 54230 RTP/SAVP 0 18 101

sip show registry
Host dnsmgr Username Refresh State Reg.Time
sip.provider.com:5061 N 1234567890 3585 Registered Sun, 13 Jan 2019 04:58:38
1 SIP registrations.

sip show peers
*CLI> sip show peers
Name/username Host Dyn Forcerport Comedia ACL Port Status Description
TLS-SIP/1234567890 3.3.3.245 Auto (No) No 5061 OK (217 ms)
1 sip peers [Monitored: 1 online, 0 offline Unmonitored: 0 online, 0 offline]

CUSEMD-INTL01*CLI> sip show tcp
Address Transport Type
3.3.3.245:5061 TLS Client

SIP.CONF

[general]
tlsenable=yes
tlsbindaddr=2.2.2.134
tlsdontverifyserver=YES
tlscertfile=/etc/asterisk/certificates/asterisk.pem
tlscafile=/etc/asterisk/certificates/ca.crt
tlscipher=ALL
tlsclientmethod=ALL ;none of the others seem to work with Blink as the client

register => tls://1234567890:password@sip.provider.com:5061/1234567890

context=from-pstn
externip = 1.1.1.71
localnet = 2.2.2.2/26

[TLS-SIP]
transport=tls
port=5061
encryption=yes
type=friend
secret=password
defaultuser=1234567890
host=sip.provider.com
dtmfmode=rfc2833
qualify=yes
context=from-pstn

canreinvite=no
disallow=all
allow=ulaw
allow=alaw
allow=gsm
insecure=invite,port

2

I’d first suggest upgrading to the latest version of Asterisk 13, as there were some SDP tweaks for handling crypto lines. Secondly I’d suggest providing the actual SIP trace (sip set debug on) so it can be seen what they are actually offering.

3

Thanks jolp, Last night I decided to rebuild from 13.18-cert2 to 31.21-cert3 mainly because i was not comfortable with the build i was working with, so many changes made trying to determine how to resolve the problem.

the new build will be CentOS 7 in Azure with Asterisk asterisk-certified-13.21-cert3. I should have this build completed in about 2 hours. This is our first Asterisk server in Azure and using encryption.

i appreciate your suggestion and update as soon as i have completed the new build.

Thank you!

4

I don’t know if certified 13.21 will have the specific tweaks I mention. It is still a few versions behind current.

5

Hi jcoip, new version Asterisk PBX certified/13.21-cert3 with the same results. What version would you suggest?

Thanks

6

The latest version of Asterisk itself is 13.24.1. If after installing that the problem still exists you would need to provide what I mentioned.

7

Can certified/13.21-cert3 be patched to 13.24.1? Also, what is the best way to provide sip debug data in the room?

I will look to see if I can upgrade or if I should recompile with 13.24.1.

Thank you!

8

There is no patching mechanism for that. Using a pastebin is fine.

9

OK, I’m building 13.24.1 now. below is sip debug from 13.21

<— SIP read from TLS:162.223.83.245:5061 —>
OPTIONS sip:6086880514@40.122.112.62:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 162.223.83.245:5061;branch=z9hG4bK+61a8e5932b6ba1c3a9f8f64fb0b3999f1+sip+4+16b7e91f
From: sip:6086880514@162.223.87.140;tag=162.223.83.245+4+4e8bb861+180b791d
Content-Length: 0
Supported: resource-priority, siprec, 100rel
To: sip:6086880514@tlsnyc.granitevoip.com
Contact: sip:b9255ffb4fa0c6cc7ffc6b6131fe85af@162.223.83.245:5061;transport=tls
Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info, as-feature-event, calling-name
Max-Forwards: 69
Call-ID: 0gQAAC8WAAACBAAALxYAAGWYsateae0LmgeuTKuK+ACwapit1q57IKw+sUmM25/1@162.223.83.245
CSeq: 392348718 OPTIONS
Organization: Metaswitch Networks
Accept: application/sdp, application/dtmf-relay

<------------->
[Jan 14 17:12:00] VERBOSE[107922] chan_sip.c: — (13 headers 0 lines) —
[Jan 14 17:12:00] VERBOSE[107922] chan_sip.c: Sending to 162.223.83.245:5061 (no NAT)
[Jan 14 17:12:00] VERBOSE[107922] chan_sip.c: Looking for 6086880514 in from-pstn (domain 40.122.112.62)
[Jan 14 17:12:00] VERBOSE[107922] chan_sip.c:
<— Transmitting (no NAT) to 162.223.83.245:5061 —>
SIP/2.0 200 OK
Via: SIP/2.0/TLS 162.223.83.245:5061;branch=z9hG4bK+61a8e5932b6ba1c3a9f8f64fb0b3999f1+sip+4+16b7e91f;received=162.223.83.245
From: sip:6086880514@162.223.87.140;tag=162.223.83.245+4+4e8bb861+180b791d
To: sip:6086880514@tlsnyc.granitevoip.com;tag=as5b4e7715
Call-ID: 0gQAAC8WAAACBAAALxYAAGWYsateae0LmgeuTKuK+ACwapit1q57IKw+sUmM25/1@162.223.83.245
CSeq: 392348718 OPTIONS
Server: Asterisk PBX certified/13.21-cert3
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: sip:40.122.112.62:5061;transport=tls
Accept: application/sdp
Content-Length: 0

<------------>
[Jan 14 17:12:00] VERBOSE[107922] chan_sip.c: Scheduling destruction of SIP dialog ‘0gQAAC8WAAACBAAALxYAAGWYsateae0LmgeuTKuK+ACwapit1q57IKw+sUmM25/1@162.223.83.245’ in 32000 ms (Method: OPTIONS)
[Jan 14 17:12:02] VERBOSE[107921] chan_sip.c: Really destroying SIP dialog ‘0gQAAC8WAAACBAAALxYAAKaJSKdRzo1QcagGPW40ptiMJ0Rx/SIExFhMF5rkXyN2@162.223.83.245’ Method: OPTIONS
[Jan 14 17:12:18] VERBOSE[107922] chan_sip.c:
<— SIP read from TLS:162.223.83.245:5061 —>
INVITE sip:6086880514@40.122.112.62:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 162.223.83.245:5061;branch=z9hG4bK+b202114b841e0b98a8a5a740b85118da1+sip+2+16bed0d0
From: “NUANCE COMMUNIC” sip:5042340883@tlsnyc.granitevoip.com;tag=162.223.83.245+2+1ca481b3+21ca5f29
To: sip:6086880514@tlsnyc.granitevoip.com
CSeq: 954706128 INVITE
Expires: 180
Content-Length: 380
Call-Info: sip:162.223.83.245:5061;method=“NOTIFY;Event=telephone-event;Duration=2000”
Supported: resource-priority,siprec, 100rel
Contact: sip:c7dc1e295099d55309285725bae6ae15@162.223.83.245:5061;transport=tls
Content-Type: application/sdp
Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info, as-feature-event, calling-name
Call-ID: 0gQAAC8WAAACBAAALxYAAF9eV5wml2+MiGnEWPWwpx2Gr064D54ZcCpns80h2KwQ@162.223.83.245
Organization: Metaswitch Networks
Max-Forwards: 67
Accept: application/sdp, application/dtmf-relay

v=0
o=- 119079711878097 119079711878097 IN IP4 162.223.83.240
s=-
c=IN IP4 162.223.83.240
t=0 0
m=audio 37382 RTP/SAVP 0 18 101
a=rtpmap:101 telephone-event/8000
a=fmtp:18 annexb=no
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:EawaxYFOqoc2uT2SqpvSBzzzOMqxZ2s2eVa+krKr|2^20
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:vEXtds7LsTycZsMJNJQiSexD1FsHxWLgGIQj1yl1|2^20
a=ptime:20
<------------->
[Jan 14 17:12:18] VERBOSE[107922] chan_sip.c: — (16 headers 11 lines) —
[Jan 14 17:12:18] VERBOSE[107922] chan_sip.c: Sending to 162.223.83.245:5061 (no NAT)
[Jan 14 17:12:18] VERBOSE[107922][C-00000000] chan_sip.c: Sending to 162.223.83.245:5061 (no NAT)
[Jan 14 17:12:18] VERBOSE[107922][C-00000000] chan_sip.c: Using INVITE request as basis request - 0gQAAC8WAAACBAAALxYAAF9eV5wml2+MiGnEWPWwpx2Gr064D54ZcCpns80h2KwQ@162.223.83.245
[Jan 14 17:12:18] VERBOSE[107922][C-00000000] chan_sip.c: Found peer ‘GRANITE-TLS-SIP’ for ‘5042340883’ from 162.223.83.245:5061
[Jan 14 17:12:18] VERBOSE[107922][C-00000000] netsock2.c: Using SIP RTP CoS mark 5
[Jan 14 17:12:18] VERBOSE[107922][C-00000000] chan_sip.c: Found RTP audio format 0
[Jan 14 17:12:18] VERBOSE[107922][C-00000000] chan_sip.c: Found RTP audio format 18
[Jan 14 17:12:18] VERBOSE[107922][C-00000000] chan_sip.c: Found RTP audio format 101
[Jan 14 17:12:18] VERBOSE[107922][C-00000000] chan_sip.c: Found audio description format telephone-event for ID 101
[Jan 14 17:12:18] NOTICE[107922][C-00000000] sdp_srtp.c: Rejecting crypto attribute ‘1 AES_CM_128_HMAC_SHA1_80 inline:EawaxYFOqoc2uT2SqpvSBzzzOMqxZ2s2eVa+krKr|2^20’: lifetime ‘1048576.000000’ too short
[Jan 14 17:12:18] NOTICE[107922][C-00000000] sdp_srtp.c: SRTP crypto offer not acceptable: ‘1 AES_CM_128_HMAC_SHA1_80 inline:EawaxYFOqoc2uT2SqpvSBzzzOMqxZ2s2eVa+krKr|2^20’
[Jan 14 17:12:18] NOTICE[107922][C-00000000] sdp_srtp.c: Rejecting crypto attribute ‘2 AES_CM_128_HMAC_SHA1_32 inline:vEXtds7LsTycZsMJNJQiSexD1FsHxWLgGIQj1yl1|2^20’: lifetime ‘1048576.000000’ too short
[Jan 14 17:12:18] NOTICE[107922][C-00000000] sdp_srtp.c: SRTP crypto offer not acceptable: ‘2 AES_CM_128_HMAC_SHA1_32 inline:vEXtds7LsTycZsMJNJQiSexD1FsHxWLgGIQj1yl1|2^20’
[Jan 14 17:12:18] WARNING[107922][C-00000000] chan_sip.c: Rejecting secure audio stream without encryption details: audio 37382 RTP/SAVP 0 18 101
[Jan 14 17:12:18] VERBOSE[107922][C-00000000] chan_sip.c:
<— Reliably Transmitting (no NAT) to 162.223.83.245:5061 —>
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/TLS 162.223.83.245:5061;branch=z9hG4bK+b202114b841e0b98a8a5a740b85118da1+sip+2+16bed0d0;received=162.223.83.245
From: “NUANCE COMMUNIC” sip:5042340883@tlsnyc.granitevoip.com;tag=162.223.83.245+2+1ca481b3+21ca5f29
To: sip:6086880514@tlsnyc.granitevoip.com;tag=as0e857545
Call-ID: 0gQAAC8WAAACBAAALxYAAF9eV5wml2+MiGnEWPWwpx2Gr064D54ZcCpns80h2KwQ@162.223.83.245
CSeq: 954706128 INVITE
Server: Asterisk PBX certified/13.21-cert3
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

<------------>
[Jan 14 17:12:18] VERBOSE[107922][C-00000000] chan_sip.c: Scheduling destruction of SIP dialog ‘0gQAAC8WAAACBAAALxYAAF9eV5wml2+MiGnEWPWwpx2Gr064D54ZcCpns80h2KwQ@162.223.83.245’ in 6400 ms (Method: INVITE)
[Jan 14 17:12:18] VERBOSE[107922] chan_sip.c:
<— SIP read from TLS:162.223.83.245:5061 —>
ACK sip:6086880514@40.122.112.62:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 162.223.83.245:5061;branch=z9hG4bK+b202114b841e0b98a8a5a740b85118da1+sip+2+16bed0d0
From: “NUANCE COMMUNIC” sip:5042340883@tlsnyc.granitevoip.com;tag=162.223.83.245+2+1ca481b3+21ca5f29
To: sip:6086880514@tlsnyc.granitevoip.com;tag=as0e857545
CSeq: 954706128 ACK
Content-Length: 0
Call-ID: 0gQAAC8WAAACBAAALxYAAF9eV5wml2+MiGnEWPWwpx2Gr064D54ZcCpns80h2KwQ@162.223.83.245
Max-Forwards: 67

<------------->
[Jan 14 17:12:18] VERBOSE[107922] chan_sip.c: — (8 headers 0 lines) —
[Jan 14 17:12:19] VERBOSE[107921] chan_sip.c: Really destroying SIP dialog ‘0gQAAC8WAAACBAAALxYAAF9eV5wml2+MiGnEWPWwpx2Gr064D54ZcCpns80h2KwQ@162.223.83.245’ Method: ACK
[Jan 14 17:12:33] VERBOSE[107921] chan_sip.c: Really destroying SIP dialog ‘0gQAAC8WAAACBAAALxYAAGWYsateae0LmgeuTKuK+ACwapit1q57IKw+sUmM25/1@162.223.83.245’ Method: OPTIONS
[Jan 14 17:12:36] VERBOSE[107921] chan_sip.c: Reliably Transmitting (no NAT) to 162.223.83.245:5061:
OPTIONS sip:tlsnyc.granitevoip.com SIP/2.0
Via: SIP/2.0/TLS 40.122.112.62:5061;branch=z9hG4bK79897e39
Max-Forwards: 70
From: “asterisk” sip:asterisk@40.122.112.62;tag=as125c313f
To: sip:tlsnyc.granitevoip.com
Contact: sip:asterisk@40.122.112.62:5061;transport=tls
Call-ID: 16812063758dc0781519b1d14a22cada@40.122.112.62:5061
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX certified/13.21-cert3
Date: Mon, 14 Jan 2019 17:12:36 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

[Jan 14 17:12:36] VERBOSE[107922] chan_sip.c:
<— SIP read from TLS:162.223.83.245:5061 —>
SIP/2.0 200 OK
Call-ID: 16812063758dc0781519b1d14a22cada@40.122.112.62:5061
CSeq: 102 OPTIONS
From: “asterisk” sip:asterisk@40.122.112.62;tag=as125c313f
To: sip:tlsnyc.granitevoip.com;tag=sip+1+bce000fe+760acd7e
Via: SIP/2.0/TLS 40.122.112.62:5061;branch=z9hG4bK79897e39
Content-Length: 0
Supported: resource-priority, siprec, 100rel
Server: DC-SIP/2.0
Organization: Metaswitch Networks
Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info, as-feature-event, calling-name
Allow: INVITE, ACK, CANCEL, BYE, REGISTER, OPTIONS, PRACK, UPDATE, SUBSCRIBE, NOTIFY, REFER, INFO, PUBLISH
Accept-Encoding: identity
Accept: application/sdp, application/simple-message-summary, message/sipfrag, application/isup, application/x-simple-call-service-info, multipart/mixed, application/broadsoft, application/hook-flash, application/vq-rtcpxr, application/media_control+xml, application/dtmf-relay, text/plain, application/x-as-feature-event+xml, application/vnd.telekom.service_indication+xml, application/calling-name-info

<------------->
[Jan 14 17:12:36] VERBOSE[107922] chan_sip.c: — (14 headers 0 lines) —
[Jan 14 17:12:37] VERBOSE[107921] chan_sip.c: Really destroying SIP dialog ‘16812063758dc0781519b1d14a22cada@40.122.112.62:5061’ Method: OPTIONS
[Jan 14 17:12:48] VERBOSE[107922] chan_sip.c:
<— SIP read from TLS:162.223.83.245:5061 —>
OPTIONS sip:6086880514@40.122.112.62:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 162.223.83.245:5061;branch=z9hG4bK+64a3435694a761b9b06ff99cd5b9f9551+sip+1+16b814cb
From: sip:6086880514@162.223.87.140;tag=162.223.83.245+1+b70184c+aad28966
Content-Length: 0
Supported: resource-priority, siprec, 100rel
To: sip:6086880514@tlsnyc.granitevoip.com
Contact: sip:b9255ffb4fa0c6cc7ffc6b6131fe85af@162.223.83.245:5061;transport=tls
Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info, as-feature-event, calling-name
Max-Forwards: 69
Call-ID: 0gQAAC8WAAACBAAALxYAAGnqBjTvDzjTlYKvWTlga+HEg6VAYFCLGZC0lzfhu41w@162.223.83.245
CSeq: 918418118 OPTIONS
Organization: Metaswitch Networks
Accept: application/sdp, application/dtmf-relay

10

Hi jcolp, upgrading to 13.24.1 resolved the cipher problem. However, I’m see a problem when it enters my extensions.conf file.

<— SIP read from TLS:162.223.83.245:5061 —>
ACK sip:6086880514@40.122.112.62:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 162.223.83.245:5061;branch=z9hG4bK+459b0fd88922a359b7ed7ec386c3a74e1+sip+1+16bc98ca
Call-ID: 0gQAAC8WAAACBAAALxYAAAN+wmDkYoU69WyB4rVbr2e+SNUjq7RO+UgmbAQbU+yv@162.223.83.245
From: “NUANCE COMMUNIC” sip:5042340883@tlsnyc.granitevoip.com;tag=162.223.83.245+1+dfffa67e+349d8a31
To: sip:6086880514@tlsnyc.granitevoip.com;tag=as40ec4690
CSeq: 26111758 ACK
Contact: sip:c7dc1e295099d55309285725bae6ae15@162.223.83.245:5061;transport=tls
Content-Length: 0
Allow-Events: message-summary, refer, dialog, line-seize, presence, call-info, as-feature-event, calling-name
Max-Forwards: 69
Organization: Metaswitch Networks

<------------->
— (11 headers 0 lines) —
– Executing [0@livesystem:2] Goto(“SIP/GRANITE-TLS-SIP-00000002”, “nuance_landing,0,1”) in new stack
– Goto (nuance_landing,0,1)
– Executing [0@nuance_landing:1] Wait(“SIP/GRANITE-TLS-SIP-00000002”, “8100”) in new stack
== Spawn extension (playfile, 0, 1) exited non-zero on ‘SIP/GRANITE-TLS-SIP-00000002’
[Jan 14 17:59:58] WARNING[2789][C-00000002]: pbx.c:4418 __ast_pbx_run: Channel ‘SIP/GRANITE-TLS-SIP-00000002’ sent to invalid extension but no invalid handler: context,exten,priority=playfile,0,1
Scheduling destruction of SIP dialog ‘0gQAAC8WAAACBAAALxYAAAN+wmDkYoU69WyB4rVbr2e+SNUjq7RO+UgmbAQbU+yv@162.223.83.245’ in 6400 ms (Method: ACK)
Reliably Transmitting (no NAT) to 162.223.83.245:5061:
BYE sip:c7dc1e295099d55309285725bae6ae15@162.223.83.245:5061;transport=tls SIP/2.0
Via: SIP/2.0/TLS 40.122.112.62:5061;branch=z9hG4bK36acc083
Max-Forwards: 70
From: sip:6086880514@tlsnyc.granitevoip.com;tag=as40ec4690
To: “NUANCE COMMUNIC” sip:5042340883@tlsnyc.granitevoip.com;tag=162.223.83.245+1+dfffa67e+349d8a31
Call-ID: 0gQAAC8WAAACBAAALxYAAAN+wmDkYoU69WyB4rVbr2e+SNUjq7RO+UgmbAQbU+yv@162.223.83.245
CSeq: 102 BYE
User-Agent: Asterisk PBX 13.24.1
X-Asterisk-HangupCause: Unknown
X-Asterisk-HangupCauseCode: 0
Content-Length: 0

11

The warning states the problem. It was sent to an invalid extension. Your dialplan is not correct.

12

Thanks jcoip, I will take a look at the extensions.conf file. Could this have to do with now the SIP is encrypted. I’m using the same dial plan as before without encryption.

also, other then using third party tools how can I tell if the call is now encrypted. I see the SIP is encrypted but not sure about voice, SRTP?

Thank you!

13

I do not know if it is because of the encrypted SIP, you would need to look at what is happening yourself and see. I don’t know what your dialplan is like/what is expected to happen/etc.

As for seeing if it is encrypted you can look at the SDP to see if it was negotiated, there’s also a field in the CHANNEL dialplan function which can display[1], and you can look at the size of the resulting RTP traffic.

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Function_CHANNEL

14

Sounds good jcoip, thank you very much for your help.

15

Hi jcoip, was trying to use wrong extensions.conf file. Got the correct one and everything working as expected.

thanks again for your help in resolving the problems.

Thanks!