Incoming TLS call - fail

Hi all,

I am playing with the TLS/SRTP capabilities of Asterisk 1.8.
The test scenario include asterisk 1.8.2.3, nokia e52 with latest software and SPA941 with latest software.
Before to start with the configuration details - without TLS everything works perfect.

The TLS configuration is done by a book - the certificate is OK, asterisk listen on 5061, the nokia e52 have CA installed and can register. SPA941 is not TLS capable and will use plain SIP.
The test scenario:

  1. Echo test from nokia e52 - OK - debug info shows encryption is used
  2. Place a call - from nokia e52 to SPA941 - OK
  3. Place a call - from SPA941 to nokia e52 - FAIL - the call hang, no erros

Any clue?

Peers:

Name/username Host Dyn Forcerport ACL Port Status
66666/66666 10.0.0.140 D 5061 Unmonitored
77777/77777 192.168.5.100 D 5060 Unmonitored

The configuration is below

fixed-phone
transport=udp
host=dynamic
directmedia=no
nat=no
canreinvite=no
outgoinglimit=1
incominglimit=2

mobile-phone
encryption=yes
srtpcapable=yes
transport=tls
host=dynamic
directmedia=no
nat=no
canreinvite=no
outgoinglimit=1
incominglimit=2
insecure=invite

66666
type=friend
context=securecallnet
defaultuser=66666
callerid=66666
secret=000000
mailbox=66666
amaflags=default
accountcode=itcom

77777
type=friend
context=securecallnet
defaultuser=77777
callerid=77777
secret=000000
mailbox=77777
amaflags=default
accountcode=itcom

The dial plan contain:
exten => s,1,Set(_SIPSRTP=${SIPPEER(${ARG2},srtpcapable)})
exten => s,n,Set(_SIP_SRTP_SDES=1)
exten => s,n,Set(_SIPSRTP_CRYPTO=enable)

Debug output:

<— SIP read from UDP:192.168.5.100:5060 —>
INVITE sip:66666@192.168.5.210 SIP/2.0
Via: SIP/2.0/UDP 192.168.5.100:5060;branch=z9hG4bK-333c5c16
From: “77777” sip:77777@192.168.5.210;tag=a2d831624e98ed47o2
To: “66666” sip:66666@192.168.5.210
Call-ID: b7d57bbe-6156c69b@192.168.5.100
CSeq: 101 INVITE
Max-Forwards: 70
Contact: “77777” sip:77777@192.168.5.100:5060;+sip.instance="<00000000-0000-0000-0000-000E08DF7C36>"
Expires: 240
User-Agent: Linksys/SPA941-5.1.8
Content-Length: 372
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, SUBSCRIBE
Allow-Events: dialog
Supported: replaces
Content-Type: application/sdp

v=0
o=- 4590786 4590786 IN IP4 192.168.5.100
s=-
c=IN IP4 192.168.5.100
t=0 0
m=audio 16466 RTP/AVP 0 2 4 8 96 97 98 101
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:4 G723/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 G726-40/8000
a=rtpmap:97 G726-24/8000
a=rtpmap:98 G726-16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:30
a=sendrecv
<------------->
— (15 headers 17 lines) —
Sending to 192.168.5.100:5060 (no NAT)
Using INVITE request as basis request - b7d57bbe-6156c69b@192.168.5.100
Found peer ‘77777’ for ‘77777’ from 192.168.5.100:5060

<— Reliably Transmitting (no NAT) to 192.168.5.100:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.5.100:5060;branch=z9hG4bK-333c5c16;received=192.168.5.100
From: “77777” sip:77777@192.168.5.210;tag=a2d831624e98ed47o2
To: “66666” sip:66666@192.168.5.210;tag=as76b837ff
Call-ID: b7d57bbe-6156c69b@192.168.5.100
CSeq: 101 INVITE
Server: Secure Call Network
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“securecall”, nonce="286434d5"
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘b7d57bbe-6156c69b@192.168.5.100’ in 32000 ms (Method: INVITE)

<— SIP read from UDP:192.168.5.100:5060 —>
ACK sip:66666@192.168.5.210 SIP/2.0
Via: SIP/2.0/UDP 192.168.5.100:5060;branch=z9hG4bK-333c5c16
From: “77777” sip:77777@192.168.5.210;tag=a2d831624e98ed47o2
To: “66666” sip:66666@192.168.5.210;tag=as76b837ff
Call-ID: b7d57bbe-6156c69b@192.168.5.100
CSeq: 101 ACK
Max-Forwards: 70
Contact: “77777” sip:77777@192.168.5.100:5060;+sip.instance="<00000000-0000-0000-0000-000E08DF7C36>"
User-Agent: Linksys/SPA941-5.1.8
Content-Length: 0
Allow-Events: dialog

<------------->
— (11 headers 0 lines) —

<— SIP read from UDP:192.168.5.100:5060 —>
INVITE sip:66666@192.168.5.210 SIP/2.0
Via: SIP/2.0/UDP 192.168.5.100:5060;branch=z9hG4bK-27dc33e
From: “77777” sip:77777@192.168.5.210;tag=a2d831624e98ed47o2
To: “66666” sip:66666@192.168.5.210
Call-ID: b7d57bbe-6156c69b@192.168.5.100
CSeq: 102 INVITE
Max-Forwards: 70
Authorization: Digest username=“77777”,realm=“securecall”,nonce=“286434d5”,uri="sip:66666@192.168.5.210",algorithm=MD5,response=“5171cb7efa2c77011c1301f9464ee499"
Contact: “77777” sip:77777@192.168.5.100:5060;+sip.instance=”<00000000-0000-0000-0000-000E08DF7C36>"
Expires: 240
User-Agent: Linksys/SPA941-5.1.8
Content-Length: 372
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER, SUBSCRIBE
Allow-Events: dialog
Supported: replaces
Content-Type: application/sdp

v=0
o=- 4590786 4590786 IN IP4 192.168.5.100
s=-
c=IN IP4 192.168.5.100
t=0 0
m=audio 16466 RTP/AVP 0 2 4 8 96 97 98 101
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:4 G723/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 G726-40/8000
a=rtpmap:97 G726-24/8000
a=rtpmap:98 G726-16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:30
a=sendrecv
<------------->
— (16 headers 17 lines) —
Sending to 192.168.5.100:5060 (no NAT)
Using INVITE request as basis request - b7d57bbe-6156c69b@192.168.5.100
Found peer ‘77777’ for ‘77777’ from 192.168.5.100:5060
== Using SIP RTP CoS mark 5
Found RTP audio format 0
Found RTP audio format 2
Found RTP audio format 4
Found RTP audio format 8
Found RTP audio format 96
Found RTP audio format 97
Found RTP audio format 98
Found RTP audio format 101
Found audio description format PCMU for ID 0
Found audio description format G726-32 for ID 2
Found audio description format G723 for ID 4
Found audio description format PCMA for ID 8
Found audio description format G726-40 for ID 96
Found audio description format G726-24 for ID 97
Found audio description format G726-16 for ID 98
Found audio description format telephone-event for ID 101
Capabilities: us - 0x40f (g723|gsm|ulaw|alaw|ilbc), peer - audio=0x100c0d (g723|ulaw|alaw|g726|ilbc|h263p)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x40d (g723|ulaw|alaw|ilbc)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 192.168.5.100:16466
Looking for 66666 in securecallnet (domain 192.168.5.210)
list_route: hop: sip:77777@192.168.5.100:5060

<— Transmitting (no NAT) to 192.168.5.100:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.5.100:5060;branch=z9hG4bK-27dc33e;received=192.168.5.100
From: “77777” sip:77777@192.168.5.210;tag=a2d831624e98ed47o2
To: “66666” sip:66666@192.168.5.210
Call-ID: b7d57bbe-6156c69b@192.168.5.100
CSeq: 102 INVITE
Server: Secure Call Network
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:66666@192.168.5.210:5060
Content-Length: 0

<------------>
– Executing [66666@securecallnet:1] Macro(“SIP/77777-00000010”, “normal,66666,SIP/66666”) in new stack
– Executing [s@macro-normal:1] Set(“SIP/77777-00000010”, “_SIPSRTP=”) in new stack
– Executing [s@macro-normal:2] Set(“SIP/77777-00000010”, “_SIP_SRTP_SDES=1”) in new stack
– Executing [s@macro-normal:3] Set(“SIP/77777-00000010”, “_SIPSRTP_CRYPTO=enable”) in new stack
– Executing [s@macro-normal:4] Dial(“SIP/77777-00000010”, “SIP/66666,30”) in new stack
== Using SIP RTP CoS mark 5
Audio is at 5061
Adding codec 0x1 (g723) to SDP
Adding codec 0x2 (gsm) to SDP
Adding codec 0x8 (alaw) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x400 (ilbc) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 10.0.0.140:5061:
INVITE sips:P_C1uMG4BIAVypRQIfLt@10.0.0.140:5061 SIP/2.0
Via: SIP/2.0/TLS 192.168.5.210:5061;branch=z9hG4bK27511d59
Max-Forwards: 70
From: “77777” sip:77777@192.168.5.210;tag=as15de063b
To: sips:P_C1uMG4BIAVypRQIfLt@10.0.0.140:5061
Contact: sip:77777@192.168.5.210:5061;transport=TLS
Call-ID: 78213a1667636a9a768b204166a7456a@192.168.5.210:5061
CSeq: 102 INVITE
User-Agent: Secure Call Network
Date: Sun, 13 Feb 2011 08:43:29 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 459

v=0
o=root 387375316 387375316 IN IP4 192.168.5.210
s=Asterisk PBX 1.8.2.3-0
c=IN IP4 192.168.5.210
t=0 0
m=audio 14144 RTP/SAVP 4 3 8 0 97 101
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:N7CXtvohCu9HcxtUTTNndSafS3gpulnOqdFOIe4S


-- Called 66666

Hi,

Your SPA probably doesn’t support the 80-bit cipher for SRTP.

Checkout line 290 of channels/sip/sdp_crypto.c. Look for:

 const char *crypto_suite = "AES_CM_128_HMAC_SHA1_80"; /* Crypto offer */

Change it to:

 const char *crypto_suite = "AES_CM_128_HMAC_SHA1_32"; /* Crypto offer */

And try that.

Also, check the documentation on the Wiki:

wiki.asterisk.org/wiki/display/ … re+Calling

malcolmd, thank you for the response.
SPA941 doesn’t support TLS/SRTP at all.
The issue is that, I can call SPA941 from nokia e52 but not the opposite.

Meanwhile I create an another test - successfully configured a SFL Phone ( support TLS/STRP) - the behavior is the same. I can call SPA941 from SFL Phone but not the opposite.
In this scenario I can’t place a call between nokia e52 and SFL Phone in both directions.

According to the documentation the asterisk certificate should contain CA and private key in one file - this is the only way to make it listen on port 5061. The same file in DER format is installed on nokia 52 - ( again this is the only way to register nokia e52 in asterisk )

Am I missing something regarding the certificates or the scenario is wrong? Can I make e call between SRTP capable device and SRTP not capable device ( in my configuration I have directmedia=no for all devices - based on my understanding the entire traffic should go via asterisk and any encryption/decryption need to be done by asterisk )?