[Home]

Summary:ASTERISK-17282: [patch] Unable to choose which SRTP suite to offer
Reporter:Bob Beers (bbeers)Labels:
Date Opened:2011-01-25 09:56:32.000-0600Date Closed:2012-09-07 08:33:14
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/SRTP
Versions:Frequency of
Occurrence
Related
Issues:
is related toASTERISK-16849 Indicate SRTP + Feature reqest
Environment:Attachments:( 0) configurable-srtp-crypto-suite-offer-bbeers01.patch
( 1) configurable-srtp-crypto-suite-offer-bbeers02.patch
( 2) configurable-srtp-crypto-suite-offer-bbeers03.patch
( 3) configurable-srtp-crypto-suite-offer-bbeers04.patch
( 4) configurable-srtp-crypto-suite-offer-bbeers05.patch
( 5) srtp-cryptosuite-bbeers22.patch
Description:Setting encryption=yes in sip.conf will cause asterisk to
generate a line in SIP INVITE SDP:

a=crypto: AES_CM_128_HMAC_SHA1_80 ...

There is no way to specify that asterisk should offer
AES_CM_128_HMAC_SHA1_32 instead of
AES_CM_128_HMAC_SHA1_80.


****** ADDITIONAL INFORMATION ******

RFC 3711 and RFC 4568 are relevant.

I have patched asterisk's sdp_crypto.c function sdp_crypto_offer()
to offer _32 vs. _80 and it correctly establishes an SRTP connection.

I would rather have a configuration parameter to select
which suite will be offered.

Comments:By: Bob Beers (bbeers) 2011-01-25 09:59:33.000-0600

I have a patch ready that adds a new sip.conf parameter, encryption_suite.
Shall I upload it here?
By: Bob Beers (bbeers) 2011-01-25 10:03:53.000-0600

I have signed the contributor's agreement.
By: Leif Madsen (lmadsen) 2011-01-25 10:52:14.000-0600

OK we'll just wait until it is acknowledged :)
By: Birger "WIMPy" Harzenetter (wimpy) 2011-01-25 11:36:25.000-0600

Wouldn't it be nicer to just add the parameters to encryption= instead of having two parameters that interact?
By: Bob Beers (bbeers) 2011-01-25 12:50:31.000-0600

I thought about that, but I wanted to avoid altering the existing behavior
of the SIP_PAGE2_USE_SRTP flag as much as possible.  
Also, this is just a first step toward full SRTP compliance.  We need to
be able to offer NULL cipher and F8_128_HMAC_SHA1_80 suite. And we need
to be able to offer different suites for audio and video in the same call.
Trying to put all of that into a one bit flag will be difficult.
By: Birger "WIMPy" Harzenetter (wimpy) 2011-01-25 14:20:31.000-0600

I was only referring to the configuration options for the user, not the internals.

Otherwise I think the most important thing is to make sure res_srtp does not crash Asterisk.

But it's good to see that someone tries to make it more complete. It was one of the catches I fell for when trying srtp.
By: Bob Beers (bbeers) 2011-01-25 14:35:16.000-0600

With my initial patch, a user can ignore the new parameter and get exactly
the same behavior as before by using only encryption=[yes|no].  
I thought that might help gain acceptance.  
But, going forward, I can see the 'encyption' param (which maps directly to
SIP_PAGE2_USE_SRTP) becoming superfluous, since the internal flag might
be easily derived from the value/presence of the new parameter,
'encryption_suite', and any others which may become available as new
capabilities are added.
By: gilles (gilles) 2011-01-30 21:47:18.000-0600

I tired the patch on Asterisk 1.8.2 but I get an error message dduring the 'make' :
chan_sip.c:5182: error: too many arguments to function ‘setup_srtp’
By: Bob Beers (bbeers) 2011-01-31 08:58:02.000-0600

Apologies.  Thank you for looking.  

I was testing/running on an older release (1.8.0-beta2)
(w/ several other patches which are not yet ported forward)
and did not compile check this single-issue patch by
itself against svn.

I thought I had created a clean patch, but I missed the
setup_srtp prototype (@~ line 1544 of chan_sip.c), and
a few other things ... please try the new patch.
By: Leif Madsen (lmadsen) 2011-01-31 13:34:06.000-0600

bbeers: why not allow you to specify the type of encryption with encryption=... and then just letting encryption=yes default to the same as it is now. That way you're backwards compatible while at the same time not having a separate option (which makes the existing encryption= option confusing).
By: gilles (gilles) 2011-01-31 22:57:30.000-0600

Thanks for the patch, everything works fine now with this new
encryption_suite=aes_32
variable in my sip.conf (only set for the sip phone).

But still, I get a warning when I make a phone call from the SIP phone (Yealink T20) to PhonerLite (1.85), no problem from PhonerLite to the phone, as you can see below.

From SIP phone to PhonerLite :

 == Using SIP RTP CoS mark 5
 == SRTP_CRYPTO_SUITE is set to 0.
 == SRTP_CRYPTO_SUITE is set to 1.
   -- Executing [8002@from-sip:1] Dial("SIP/8001-0000001a", "SIP/phonerlite1") in new stack
 == Using SIP RTP CoS mark 5
 == Encrypted Media is required, offering suite 1.
 == SRTP_CRYPTO_SUITE is set to 1.
 == Selecting 'AES_CM_128_HMAC_SHA1_80' for srtp crypto offer.
   -- Called phonerlite1
   -- SIP/phonerlite1-0000001b is ringing
 == SRTP_CRYPTO_SUITE is set to 1.
   -- SIP/phonerlite1-0000001b answered SIP/8001-0000001a
 == Selecting 'AES_CM_128_HMAC_SHA1_80' for srtp crypto offer.
[Feb  1 16:14:46] WARNING[23193]: res_srtp.c:338 ast_srtp_unprotect: SRTP unprotect: authentication failure
 == Spawn extension (from-sip, 8002, 1) exited non-zero on 'SIP/8001-0000001a'

From PhonerLite to SIP phone :

 == Using SIP RTP CoS mark 5
 == SRTP_CRYPTO_SUITE is set to 0.
 == SRTP_CRYPTO_SUITE is set to 1.
   -- Executing [8001@from-sip:1] Dial("SIP/phonerlite1-00000018", "SIP/8001") in new stack
 == Using SIP RTP CoS mark 5
 == Encrypted Media is required, offering suite 2.
 == SRTP_CRYPTO_SUITE is set to 2.
 == Selecting 'AES_CM_128_HMAC_SHA1_32' for srtp crypto offer.
   -- Called 8001
   -- SIP/8001-00000019 is ringing
 == SRTP_CRYPTO_SUITE is set to 2.
   -- SIP/8001-00000019 answered SIP/phonerlite1-00000018
 == Selecting 'AES_CM_128_HMAC_SHA1_80' for srtp crypto offer.
 == Spawn extension (from-sip, 8001, 1) exited non-zero on 'SIP/phonerlite1-00000018'


By: Bob Beers (bbeers) 2011-02-01 08:42:15.000-0600

lmadsen:  wimpy asked a similar question on 25 Jan.  
I'm anticipating a future where we have an audio+video call that may
require different suites.  
There could be some other new parameters becoming available, perhaps
encryption_audio, encryption_video, encryption_text,
that would override the "default" encryption_suite if necessary.  
Leaving encyption=[yes|no] also allows for quickly turning off all
encryption without changing all the other params (probably only
useful for testing/debugging).  
Also, I had intended that the current patch does allow for backward
compatibility.  Is that not the case?

giles:  I'll look at that warning (I think it is due to return value
of a libsrtp function call, srtp_unprotect_rtcp or srtp_unprotect)
and see if I can tell what is happening.  I didn't notice it during
my testing, but I will look more carefully.


By: Birger "WIMPy" Harzenetter (wimpy) 2011-02-01 10:10:02.000-0600

lmadsen wrote how to be backwards compatible without introducing a new option, which was exactly my idea.
Giving that you think it might be necessary to be able to configure different encryption for different media types in the future, I think that makes an extra default option even more confusing.

KISS! (just IMHO, off course)
By: John T. (c1nco) 2011-02-01 15:19:43.000-0600

I am having the same issue as gilles.
By: Bob Beers (bbeers) 2011-02-01 15:24:51.000-0600

As you wish,

Please try/review 03.patch, encyption=value can be yes|no|aes_80|aes_32|f8_80|null.

Only the first 4 are currently valid.
Setting encryption=yes will have the same effect as aes_80.
There is no longer an encyption_suite param.

I have only compile tested, have not run the resulting binary yet.


By: Bob Beers (bbeers) 2011-02-01 15:33:57.000-0600

gilles & c1nco: What do the a=crypto: lines in the INVITE and 200 OK SDP look like?
By: John T. (c1nco) 2011-02-01 17:52:29.000-0600

Here is some logs from an external call to phonerlite client

http://pastebin.com/Sarg21fL


Here is Phonerlite when trying to dial VM box

http://pastebin.com/ysWQTMNv


I was able to connect to phonerlite client through external call (cell phone) on your previous patch (rev 2) however asterisk would spam: SRTP unprotect: authentication failure

I now cant connect to any client at all.

I using the below variable per extension 201
encryption=aes_32

Any thoughts?
By: Bob Beers (bbeers) 2011-02-02 08:12:23.000-0600

This:

a=crypto:1 OFF inline:83/tqfQYLydlotymyiAv+x/WSWWw6yKsAJVly3Tn

and this:

#
[Feb 1 15:34:46] VERBOSE[24428] chan_sip.c: == Encrypted Media is required, offering suite 2.
#
[Feb 1 15:34:46] VERBOSE[24428] chan_sip.c: == Invalid SRTP_CRYPTO_SUITE = 2.
#
[Feb 1 15:34:46] VERBOSE[24428] sip/sdp_crypto.c: == Selecting 'OFF' for srtp crypto offer.

from your first trace indicates the problem.

I changed the offset of the srtp tructure's suite bits to allow for 4 options,
and forgot to change the offset.

New patch to follow.
By: Bob Beers (bbeers) 2011-02-02 15:35:34.000-0600

gilles & c1nco: 04.patch is uploaded, only compile tested.
Should also show better which suite flag values and
descriptions are set/detected at the various places
in the code where they are manipulated.
Tomorrow I may have my package building of 1.8.2.2
worked out and I can test the patches on my hardware.
I appreciate all testing/comments/suggestions in the meanwhile.
By: John T. (c1nco) 2011-02-02 16:45:32.000-0600

Applied new patch, however, I am still having issues please see below links--

external caller to phonerlite client: http://pastebin.com/xtEkJe2n

phonerlite trying to dial Voice Mail: http://pastebin.com/2Y3wjZ90

Both internal and external calls are still being dropped.

Thanks for your assistance!
By: Bob Beers (bbeers) 2011-02-03 07:55:47.000-0600

c1nco:  I still have something wrong in my flag translations
between the sip_pvt/sip_peer structure and the srtp structure.  
I should be able to get that resolved today.  
Here is evidence from your 'external caller to phonerlite client' trace:

 "a=crypto:1 (null) inline:..."
and
 [Feb 2 14:32:05] VERBOSE[23479] sip/sdp_crypto.c: == Selecting 0 ((null)) for srtp crypto offer.

But, in your second trace, the INVITE from phonelite has

"m=audio 5063 RTP/AVP 0 8 111 110 97 101"

and asterisk complains because it expects to see RTP/SAVP.  
That is a separate issue, IMHO, from the crypto suite patch.
By: Jakub Kapus (kapo) 2011-02-04 09:04:44.000-0600

I still have some difficulties. I`m using this scenario: http://kb.asipto.com/asterisk:realtime:kamailio-3.1.x-asterisk-1.6.2-astdb

My Asterisk version: 1.8.2.3

SIPtrace is on: http://pastebin.com/XkwVBSXT

Interesting line is:

a=crypto:1 (null) inline:0o4FL8kR4/cjJVOmbrla492XWt4f9tyuayp/Fsiv.

In phone (both are cisco SPA508G) Calleer phone show the call is encrypted, callee phone not.

Thanks.


By: Bob Beers (bbeers) 2011-02-04 09:40:28.000-0600

kapo:  Your results are using 05.patch?
What do you set encryption= in sip.conf?
( 5 options: no entry, yes|no|aes_80|aes_32 )
How is this result different from unpatched 1.8.2.3?
( 3 options: no entry, yes|no )
Can you show the Asterisk trace, where Cisco INVITE SDP
is parsed and SRTP_CRYPTO_SUITE flag bits are set?

I think 05.patch should work for you if you set encryption=aes_32.
Since Cisco INVITE has both, but Asterisk only uses the first
a=crypto: line it sees (which in this case is _32), you could
get by with a single line patch to force Asterisk to use aes_32.  

If you like, try applying just this, in channels/sip/sdp_crypto.c:

int sdp_crypto_offer(struct sdp_crypto *p)
{
       char crypto_buf[128];
-       const char *crypto_suite = "AES_CM_128_HMAC_SHA1_80"; /* Crypto offer */
+       const char *crypto_suite = "AES_CM_128_HMAC_SHA1_32"; /* Crypto offer */

       if (p->a_crypto) {
               ast_free(p->a_crypto);

It worked for me, but now you can't do aes_80 at all.

c1nco & gilles: Any luck with 05.patch?


By: John T. (c1nco) 2011-02-05 11:11:34.000-0600

Ok External Calls in are connecting again -- but spamming:

res_srtp.c: SRTP unprotect: authentication failure

Here are logs from an external call to phonerlite client--
http://pastebin.com/cQukbFut

Here is Phonerlite client dialing out (voicemail)--
http://pastebin.com/Wu7vhkLM
By: Bob Beers (bbeers) 2011-02-07 10:15:20.000-0600

c1nco:  Looks like we're back where we were before I caved to
the "no new parameters" suggestions.
The SRTP unprotect warnings are happening at 5 second intervals.  
Could they be (S)RTCP related?  
( I have not had any luck using (S)RTCP while using SRTP.  
 In fact, one of my other, related, patches is to ignore incoming
 (S)RTCP packets when using SRTP. Another issue to bring up soon.)  
Can you disable (S)RTCP from the other end and see if those
warnings stop?

As for the Phonerlite trace, the problem is the same as
before ...  Asterisk sees the a=media line:

m=audio 5062 RTP/AVP 111 110 97 3 0 8 101

and decides that secure_audio is off.
I can't quote RFC chapter and verse, but Asterisk expects
it to be:

m=audio 5062 RTP/SAVP 111 110 97 3 0 8 101

You could modify the logic in process_sdp() function in chan_sip.c,
but I have no idea of the repercussions of such a decision.
I think the other end should be fixed.


By: John T. (c1nco) 2011-02-08 18:45:22.000-0600

bbears-- can you link me your related patch to ignore the incoming (S)RTCP packets...I am unfamiliar with how I would go about blocking them.
By: Bob Beers (bbeers) 2011-02-09 09:45:29.000-0600

c1nco:  Let me first say, I think that ignoring the incoming RTCP packets
is the wrong answer to the problem.  But I had to stop asterisk from
hanging up the calls when RTCP packet arrived.  

There is already an open issue, id=17976,
about RTCP causing problems when using SRTP,
https://issues.asterisk.org/view.php?id=17976.

Take a look at my comments/patch there.


By: Bob Beers (bbeers) 2011-02-11 17:34:49.000-0600

I just uploaded a new patch that follows more along the lines of
the allow parameter used for codec selection.
You can select more than one cryptosuite, for example:

encryption=aes_80,aes_32

and the INVITE will have 2 a=crypto lines

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:...
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:...

Did not work out to prefer one cryptosuite over another,
so aes_80,aes_32 gives the same SDP as aes_32,aes_80.
Could work on that if it's deemed important/necessary.

I think I will next tackle negotiating when multiple cryptosuites
arrive in INVITE, and first one is not in our list.  Asterisk
currently accepts the first cryptosuite parsed (if it is
aes_32 or aes_80) as long as we have not disabled encryption.

Please try out the 22.patch, make comments.


By: Andrey Karadimov (andrewhack) 2011-02-18 07:53:46.000-0600

I tried 22.patch with asterisk 1.8.2.3
Two devices are tested - Cisco SPA303 and Nokia e52.
In both cases I receive "WARNING[28418] chan_sip.c: No SRTP key management enabled" and asterisk crash

Could you share any idea?
By: Bob Beers (bbeers) 2011-02-18 08:47:39.000-0600

andrewhack:  ouch.  AFAICT, that warning means that Asterisk
expected a=crypto line in SDP, but it was not there.
Can you tell what config you used in sip.conf?
If you use encryption=no, does the call go ok?
How are the phones configured wrt SRTP encryption?  
Can you show SIP trace?
By: Andrey Karadimov (andrewhack) 2011-02-18 11:59:13.000-0600

bberrs: this is my conf:
[fixed-phone](!)
encryption=aes_32
srtpcapable=yes
transport=tls
host=dynamic
directmedia=no
nat=no
canreinvite=no
outgoinglimit=1
incominglimit=2

[mobile-phone](!)
encryption=aes_80
srtpcapable=yes
transport=tls
host=dynamic
directmedia=no
nat=no
canreinvite=no
outgoinglimit=1
incominglimit=2

[66666](mobile-phone)
type=friend
context=securecallnet
defaultuser=66666
callerid=66666
secret=000000
mailbox=66666
amaflags=default
accountcode=itcom

[77777](fixed-phone)
type=friend
context=securecallnet
defaultuser=77777
callerid=77777
secret=000000
mailbox=77777
amaflags=default
accountcode=itcom


I din't try encryption=no. Actually I reverted back to 1.8.2.2 and 05.patch - I am sorry, I reverted immediately after my post and can't provide SIP trace now.

Now everything, from SIP trace point of view, looks good but wireshark shows plain packets.
This is the SIP trace from 1.8.2.2 and 05.patch:
<--- SIP read from TLS:10.0.0.87:32824 --->
INVITE sips:11111@192.168.5.210 SIP/2.0
Via: SIP/2.0/TLS 10.0.0.87:5061;branch=z9hG4bK4ktmlhhpfphc6r9v071k4t1;rport
From: <sips:66666@192.168.5.210>;tag=0rq6lhn5slhc6cdl071k
To: <sips:11111@192.168.5.210>
Contact: <sips:P_C1uMG4BIAVypRQIfLt@10.0.0.87:5061>
Supported: precondition,100rel,timer
CSeq: 782 INVITE
Call-ID: Tp1GNEQ8oIfNYg73gKXvKBR7wNkG0g
Allow: UPDATE,PRACK,SUBSCRIBE,REFER,NOTIFY,INVITE,ACK,CANCEL,OPTIONS,BYE
User-Agent: Nokia RM-469 052.003 (en)
Expires: 120
Privacy: None
Session-Expires: 1800
Max-Forwards: 70
Content-Type: application/sdp
Accept-Language: en
Content-Length: 756

v=0
o=66666 63466315031581125 63466315031581125 IN IP4 10.0.0.87
s=-
c=IN IP4 10.0.0.87
t=0 0
m=audio 10000 RTP/SAVP 100 96 0 8 97 18 98 13
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d2wwa2o2ZWlMbE5mMDYwVE1qSzVxTjlHTldRUnlX
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:RTE1RVlBTFZtU2d6MmQ3bUJhRVdkQWZaYTVmSzBh
a=curr:sec e2e none
a=des:sec optional e2e sendrecv
a=rtpmap:100 AMR-WB/16000
a=ptime:20
a=maxptime:200
a=fmtp:100 mode-change-period=2; mode-change-neighbor=1
a=rtpmap:96 AMR/8000
a=fmtp:96 mode-set=0,1,2,3,4,5,6,7; mode-change-neighbor=1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:98 telephone-event/8000
a=fmtp:98 0-15
a=rtpmap:13 CN/8000
<------------->
--- (17 headers 25 lines) ---
Sending to 10.0.0.87:32824 (no NAT)
Using INVITE request as basis request - Tp1GNEQ8oIfNYg73gKXvKBR7wNkG0g
Found peer '66666' for '66666' from 10.0.0.87:32824

<--- Reliably Transmitting (no NAT) to 10.0.0.87:32824 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 10.0.0.87:5061;branch=z9hG4bK4ktmlhhpfphc6r9v071k4t1;received=10.0.0.87;rport=32824
From: <sips:66666@192.168.5.210>;tag=0rq6lhn5slhc6cdl071k
To: <sips:11111@192.168.5.210>;tag=as0f38e4c9
Call-ID: Tp1GNEQ8oIfNYg73gKXvKBR7wNkG0g
CSeq: 782 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="432442a1"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog 'Tp1GNEQ8oIfNYg73gKXvKBR7wNkG0g' in 32000 ms (Method: INVITE)

<--- SIP read from TLS:10.0.0.87:32824 --->
ACK sips:11111@192.168.5.210 SIP/2.0
Via: SIP/2.0/TLS 10.0.0.87:5061;branch=z9hG4bK4ktmlhhpfphc6r9v071k4t1;rport
From: <sips:66666@192.168.5.210>;tag=0rq6lhn5slhc6cdl071k
To: <sips:11111@192.168.5.210>;tag=as0f38e4c9
Call-ID: Tp1GNEQ8oIfNYg73gKXvKBR7wNkG0g
CSeq: 782 ACK
Supported: sec-agree
Max-Forwards: 70
Content-Length: 0

<------------->
--- (9 headers 0 lines) ---

<--- SIP read from TLS:10.0.0.87:32824 --->
INVITE sips:11111@192.168.5.210 SIP/2.0
Via: SIP/2.0/TLS 10.0.0.87:5061;branch=z9hG4bK2qhgpvr33g5fno3vdb3534r;rport
From: <sips:66666@192.168.5.210>;tag=0rq6lhn5slhc6cdl071k
To: <sips:11111@192.168.5.210>
Contact: <sips:P_C1uMG4BIAVypRQIfLt@10.0.0.87:5061>
Supported: precondition,100rel,timer
CSeq: 783 INVITE
Call-ID: Tp1GNEQ8oIfNYg73gKXvKBR7wNkG0g
Allow: UPDATE,PRACK,SUBSCRIBE,REFER,NOTIFY,INVITE,ACK,CANCEL,OPTIONS,BYE
User-Agent: Nokia RM-469 052.003 (en)
Expires: 120
Privacy: None
Session-Expires: 1800
Max-Forwards: 70
Authorization: Digest realm="securecall",nonce="432442a1",algorithm=MD5,username="66666",uri="sips:11111@192.168.5.210",response="ae5328698bd10fe65f39f509508ba4d3"
Content-Type: application/sdp
Accept-Language: en
Content-Length: 756

v=0
o=66666 63466315031581125 63466315031581125 IN IP4 10.0.0.87
s=-
c=IN IP4 10.0.0.87
t=0 0
m=audio 10000 RTP/SAVP 100 96 0 8 97 18 98 13
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:d2wwa2o2ZWlMbE5mMDYwVE1qSzVxTjlHTldRUnlX
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:RTE1RVlBTFZtU2d6MmQ3bUJhRVdkQWZaYTVmSzBh
a=curr:sec e2e none
a=des:sec optional e2e sendrecv
a=rtpmap:100 AMR-WB/16000
a=ptime:20
a=maxptime:200
a=fmtp:100 mode-change-period=2; mode-change-neighbor=1
a=rtpmap:96 AMR/8000
a=fmtp:96 mode-set=0,1,2,3,4,5,6,7; mode-change-neighbor=1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:98 telephone-event/8000
a=fmtp:98 0-15
a=rtpmap:13 CN/8000
<------------->
--- (18 headers 25 lines) ---
Sending to 10.0.0.87:32824 (no NAT)
Using INVITE request as basis request - Tp1GNEQ8oIfNYg73gKXvKBR7wNkG0g
Found peer '66666' for '66666' from 10.0.0.87:32824
 == Using SIP RTP CoS mark 5
Found RTP audio format 100
Found RTP audio format 96
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 97
Found RTP audio format 18
Found RTP audio format 98
Found RTP audio format 13
 == SRTP_CRYPTO_SUITE is set to 0 ((null)).
 == SRTP_CRYPTO_SUITE is set to 16 (AES_CM_128_HMAC_SHA1_80).
Found audio description format AMR-WB for ID 100
Found audio description format AMR for ID 96
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Found audio description format iLBC for ID 97
Found audio description format G729 for ID 18
Found audio description format telephone-event for ID 98
Found audio description format CN for ID 13
Capabilities: us - 0x40f (g723|gsm|ulaw|alaw|ilbc), peer - audio=0x50c (ulaw|alaw|g729|ilbc)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x40c (ulaw|alaw|ilbc)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x3 (telephone-event|CN|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 10.0.0.87:10000
Looking for 11111 in securecallnet (domain 192.168.5.210)
list_route: hop: <sips:P_C1uMG4BIAVypRQIfLt@10.0.0.87:5061>

<--- Transmitting (no NAT) to 10.0.0.87:32824 --->
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 10.0.0.87:5061;branch=z9hG4bK2qhgpvr33g5fno3vdb3534r;received=10.0.0.87;rport=32824
From: <sips:66666@192.168.5.210>;tag=0rq6lhn5slhc6cdl071k
To: <sips:11111@192.168.5.210>
Call-ID: Tp1GNEQ8oIfNYg73gKXvKBR7wNkG0g
CSeq: 783 INVITE
Server: Secure Call Network
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Session-Expires: 600;refresher=uas
Contact: <sip:11111@192.168.5.210:5061;transport=TLS>
Content-Length: 0


<------------>
   -- Executing [11111@securecallnet:1] Playback("SIP/66666-00000006", "demo-echotest") in new stack
Audio is at 5061
 == Selecting 1 (AES_CM_128_HMAC_SHA1_80) for srtp crypto offer.
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.87:32824 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 10.0.0.87:5061;branch=z9hG4bK2qhgpvr33g5fno3vdb3534r;received=10.0.0.87;rport=32824
From: <sips:66666@192.168.5.210>;tag=0rq6lhn5slhc6cdl071k
To: <sips:11111@192.168.5.210>;tag=as3eefcc7a
Call-ID: Tp1GNEQ8oIfNYg73gKXvKBR7wNkG0g
CSeq: 783 INVITE
Server: Secure Call Network
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Session-Expires: 600;refresher=uas
Contact: <sip:11111@192.168.5.210:5061;transport=TLS>
Content-Type: application/sdp
Content-Length: 389

v=0
o=root 442929548 442929548 IN IP4 192.168.5.210
s=Asterisk PBX 1.8.2.2-1
c=IN IP4 192.168.5.210
t=0 0
m=audio 43272 RTP/SAVP 8 0 97 98
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:98 telephone-event/8000
a=fmtp:98 0-16
a=ptime:20
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:byXQQP1sUKtBPssVZ6IWYcHHnH85RVGg1SBq2MqY

<------------>

<--- SIP read from TLS:10.0.0.87:32824 --->
ACK sip:11111@192.168.5.210:5061;transport=TLS SIP/2.0
Via: SIP/2.0/TLS 10.0.0.87:5061;branch=z9hG4bKhm1fkaklp6v8ro3vdb37pgj;rport
To: <sips:11111@192.168.5.210>;tag=as3eefcc7a
From: <sips:66666@192.168.5.210>;tag=0rq6lhn5slhc6cdl071k
Call-ID: Tp1GNEQ8oIfNYg73gKXvKBR7wNkG0g
CSeq: 783 ACK
Supported: sec-agree
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INVITE,ACK,CANCEL,OPTIONS,BYE
Max-Forwards: 70
Authorization: Digest realm="securecall",nonce="432442a1",algorithm=MD5,username="66666",uri="sips:11111@192.168.5.210",response="ae5328698bd10fe65f39f509508ba4d3"
Content-Length: 0

<------------->

I will try 1.8.2.2 and 22.patch after this post
By: Andrey Karadimov (andrewhack) 2011-02-18 12:00:15.000-0600

bbeers, just to mention - I am available for any test required by you
By: Andrey Karadimov (andrewhack) 2011-02-18 12:34:14.000-0600

bbeers, the result from combination 1.8.2.2 and 22.patch is the same like 1.8.2.3 and 22.patch - "WARNING[28418] chan_sip.c: No SRTP key management enabled" and asterisk crash
By: Bob Beers (bbeers) 2011-02-18 13:51:30.000-0600

andrewhack:  I am deep into porting some other patches forward to
1.8.2.3, and can't dig into what is going wrong with
srtp-cryptosuite-bbeers22.patch today.
All I have really looked at is the construction of the INVITE/OK
SDP a=crypto lines (which look ok).  
I hope I will be able to test the actual SRTP stream early next
week with Asterisk 1.8.2.3.  Look for something (an updated
patch) on Tuesday or Wednesday (/me fingers crossed).

In the meanwhile, if anyone else can see what is amiss, please share.

BTW, srtpcapable is not necessary in Asterisk 1.8.x, AFAICT.
By: Irontec (irontec) 2011-02-24 10:28:40.000-0600

Hi,

I've tested latest patch (*22.patch) with the same result. Asterisk Crash.


[Feb 24 17:14:36] WARNING[20316]: chan_sip.c:10446 get_crypto_attrib: No SRTP key management enabled
   -- Called 200
   -- SIP/200-00000001 is ringing
[Feb 24 17:14:52] WARNING[20293]: chan_sip.c:8421 process_sdp: We are requesting SRTP, but they responded without it!
   -- SIP/200-00000001 answered SIP/100-00000000
 == Using 0x1 (AES_CM_128_HMAC_SHA1_32) for srtp crypto offer.
[Feb 24 17:14:52] WARNING[20316]: chan_sip.c:10446 get_crypto_attrib: No SRTP key management enabled
 == Spawn extension (remoteParty, 200, 2) exited non-zero on 'SIP/100-00000000'
*** glibc detected *** asterisk: double free or corruption (!prev): 0x000000000291db30 ***
======= Backtrace: =========
/lib/libc.so.6[0x7f4ac0f359a8]
/lib/libc.so.6(cfree+0x76)[0x7f4ac0f37ab6]
/usr/lib/asterisk/modules/chan_sip.so[0x7f4abdb194ca]
/usr/lib/asterisk/modules/chan_sip.so[0x7f4abdb1a385]
/usr/lib/asterisk/modules/chan_sip.so[0x7f4abda94bbb]
/usr/lib/asterisk/modules/chan_sip.so[0x7f4abda95b0e]
/usr/lib/asterisk/modules/chan_sip.so[0x7f4abda95a75]
asterisk[0x442783]
asterisk(__ao2_ref+0x38)[0x4426b2]
/usr/lib/asterisk/modules/chan_sip.so[0x7f4abda85b45]
/usr/lib/asterisk/modules/chan_sip.so[0x7f4abda87b6e]
/usr/lib/asterisk/modules/chan_sip.so[0x7f4abdacb4ea]
asterisk[0x443297]
asterisk(__ao2_callback+0x59)[0x4436ce]
/usr/lib/asterisk/modules/chan_sip.so[0x7f4abdaf4026]
asterisk[0x55d68b]
/lib/libpthread.so.0[0x7f4ac074cfc7]
/lib/libc.so.6(clone+0x6d)[0x7f4ac0f9164d]


With encryption=no there is also a crash but is a different one.
By: Bob Beers (bbeers) 2011-02-24 16:13:37.000-0600

Hi Irontec, and all other interested srtp users,
I have my other patches ported, so I'll be back on the srtp
issue tomorrow morning.  For what it's worth, on my system the a=crypto
line is not being added to the outgoing INVITE as I expected it to (with
*22.patch), but I don't see a crash.
What devices are you using to test the srtp capability?
By: keys (keys) 2011-02-25 01:39:02.000-0600

With 22.patch I also get asterisk crash.
I tried 05.patch with settings encryption=aes_32 and is working last 10 days. Thanks.

Im using Asterisk 1.8.2.3
Acrobits softphone 4.7 (TLS-SIPS)
By: Irontec (irontec) 2011-02-25 01:54:15.000-0600

Hi, I'm using Cisco SPA5XX phones and Snom360.

Without any patches and changing only the sdp_crypto.c to offer AES_32 instead AES_80 works well. We only have a Warning like:
 WARNING[4187]: res_srtp.c:338 ast_srtp_unprotect: SRTP unprotect: authentication failure
(The warning appears every X seconds, being X a different value each time, maybe 5 seconds, maybe 10s..., other times it only appears when tha call hangs-up)

But, the conversation is protected (using Wireshark or Omnipeek we can't hear real audio)

Change to AES_32 is required because SPA5XX phones send two Crypto lines and the first one is AES_32 and as we know Asterisk only uses the first line....
(With Snoms we can choose which type to use)

Thanks for your effort with this issue.


By: Bob Beers (bbeers) 2011-02-25 07:58:51.000-0600

Irontec:  IMO, that 5 second warning must be RTCP related.  
Your wireshark trace should show the correlation between the
warnings and the arrival of packets on the RTCP_PORT.
Does it only happen when using AES_32?  
Several people complain about it after trying to use aes_32.
There may be some disconnect between how SRTP and SRTCP get "unprotected"
inside Asterisk.  (I wonder if SRTCP is somehow 'hard-coded' to aes_80?)


By: arqum (marqumch) 2011-02-27 08:19:21.000-0600

hi
i installed latest release of asterisk from svn ..
when imake a call on srtp .. it gives error...

when i try to make a call from eyebeam 1.5.7 it give follwoing error..

sip/sdp_crypto.c:226 sdp_crypto_process: Unsupported crypto parameters: [Feb 27 09:11:50] WARNING[13888]: chan_sip.c:8409 process_sdp: Can't provide secure audio requested in SDP offer

and when i try to make a call from phonerlite then it gives...

chan_sip.c:8414 process_sdp: We are requesting SRTP, but they responded without it!
 == Using SIP RTP CoS mark 5

i try to make call between two softphones... tls registration is working well...
please help me out ...is this internal error or i do some mistake...

i need to make it work tomorrow..

thanks
By: Irontec (irontec) 2011-02-28 05:54:55.000-0600

Hi bbeers,

You're right. This Warning appears when the phone sends to Asterisk a RTCP packet with "Source Description" header.

I've been checking Asterisk code to find hard-coded about RTCP but no luck...

And using Cisco phones I can't change AES_32 because the phones send this mode as first crypto line, (they send both lines, AES_32 and AES_80) but we can't choose between them.

Maybe Asterisk can't handle those packets? I mean, all RTCP packets from phones to Asterisk have "Source Description" and Asterisk complains with the Warning.

I don't know...
By: Stanislav Kutil (mammal) 2011-02-28 06:25:13.000-0600

Tried public asterisk 1.8.2.4 with patch 22 applied

The problem is that our softphone offers both 32 and 80. Asterisk sets the cryptosuite to 32 internally but responds with 80 in SDP. So we start sending RTP with SHA1-80 and it results with SRTP unprotect: authentication failure
of course.

Also it seems that non RTP/RTCP packets are fed into srtp unprotect (e.g. ZRTP packets) which fills logs with auth failure messages as well.
By: keys (keys) 2011-03-02 07:31:10.000-0600

I have been using 05.patch with encryption=aes_32.
I am still getting these messages in log:


Outbound call from softphone TLS+SRTP (encryption=aes_32) to server A onto server B using iax2:

chan_iax2.c:     -- Format for call is ulaw
app_dial.c:     -- IAX2/SSS-17853 is making progress passing it to SIP/101-00000185
sip/sdp_crypto.c:   == Selecting 2 (AES_CM_128_HMAC_SHA1_32) for srtp crypto offer.
res_srtp.c: SRTP unprotect: unsupported parameter
res_srtp.c: SRTP unprotect: authentication failure



Inbound call from server B to server A using iax2 and then onto softphone using TLS+SRTP (encryption=aes_32):

netsock2.c:   == Using SIP RTP TOS bits 184
netsock2.c:   == Using SIP RTP CoS mark 5
chan_sip.c:   == Encrypted Media is required, offering suite 2 (AES_CM_128_HMAC_SHA1_32).
chan_sip.c:   == SRTP_CRYPTO_SUITE is set to 32 (AES_CM_128_HMAC_SHA1_32).
sip/sdp_crypto.c:   == Selecting 2 (AES_CM_128_HMAC_SHA1_32) for srtp crypto offer.
app_dial.c:     -- Called 101
app_dial.c:     -- SIP/101-00000187 is ringing
res_rtp_asterisk.c: RTP Read too short
chan_sip.c:   == SRTP_CRYPTO_SUITE is set to 32 (AES_CM_128_HMAC_SHA1_32).
app_dial.c:     -- SIP/101-00000187 answered IAX2/701-11563
pbx.c:     -- Executing [s@macro-auto-blkvm:1] Set("SIP/101-00000187", "__MACRO_RESULT=") in new stack
pbx.c:     -- Executing [s@macro-auto-blkvm:2] NoOp("SIP/101-00000187", "Deleting: BLKVM/700/IAX2/701-11563 TRUE") in new stack
res_srtp.c: SRTP unprotect: authentication failure


Thanks for all your efforts bbeers.
By: Bob Beers (bbeers) 2011-03-02 08:37:56.000-0600

keys:  Those unprotect errors are coming from one of the libsrtp functions,
srtp_unprotect() or srtp_unprotect_rtcp(), I am leaning toward the latter.
But it is not obvious from my quick glance at the libsrtp code why those
codes would come up.  
BTW, I am not trying to change iax2 encryption, just SIP.  
If any of my patches are affecting iax2, that is unintentional.
By: keys (keys) 2011-04-20 05:08:58

bbeers: any updates?

FYI your patches do not affect IAX2 encryption.
The unprotect errors that you say are related to libsrtp functions, do they in any way mean that there is a fallback to standard RTP during a call, or at the start of a call?

Using Wireshark everything looks correct with srtp packets but of course its harder to tell when TLS is also enabled.
By: Gregory Hinton Nietsky (irroot) 2011-05-21 15:38:32

F8_ cannot be used as its not supported in libsrtp so no need to add support for it.

see ASTERISK-17895 for some related work.
By: Matt Jordan (mjordan) 2012-09-07 08:34:29.475-0500

This feature was added in Asterisk 10.  As the ability to choose a crypto suite is arguably an improvement and not a bug, it was done in what was the next major release at the time (Asterisk 10) and will not be backported to Asterisk 1.8.  If you require the ability to configure the SRTP crypto suite, you may want to consider migrating to Asterisk 10 or later.