[Home]

Summary:ASTERISK-05267: [patch] [branch] Secure RTP (SRTP)
Reporter:mikma (mikma)Labels:
Date Opened:2005-10-09 10:36:15Date Closed:2010-06-08 01:00:30
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) ast_srtp_depend.patch
( 1) ast_srtp_r51249_mikey_r3124.patch
( 2) ast_srtp_r61760_mikey_r3250.patch
( 3) ast_srtp_r81432_mikey_r3412.patch
( 4) ast_srtp_trunk_r29093.patch
( 5) ast_srtp_trunk_r48360.patch
( 6) ast_srtp_trunk_r48491.patch
( 7) ast_srtp6.patch
( 8) ast_srtp7.patch
( 9) asterisk-1.6.2.0-rc3-srtp.patch
(10) asterisk-1.6.2.0-rc3-srtp-test.patch
(11) asterisk-oej-securertp-trunk-r34330.patch
(12) asterisk-oej-securertp-trunk-r34481.patch
(13) srtp_ast-1.6.2_v3.patch
(14) srtp_missing_free.patch
(15) SRTP_SoundPoint_IP-TB25751_3725-17495-001_RevB.pdf
Description:This patch adds initial support for secure RTP using libsrt[1]. It can
be used in for example an implementation of the sdecriptions draft[2].

[1] http://srtp.sourceforge.net/srtp.html
[2] http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-12.txt


Update (16/03/2010): Branch against trunk is located here http://svn.asterisk.org/svn/asterisk/team/group/srtp_reboot

*** IF TESTING, PLEASE USE THE ABOVE BRANCH AND NOT THE PATCHED ATTACHED TO THIS ISSUE AS THEY ARE OUT OF DATE ***

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

Example:

#define CRYPTO_KEY_LEN 30

/* Declarations */
ast_policy_t *local_policy;
unsigned char local_key[CRYPTO_KEY_LEN];
char local_key64[50];
ast_policy_t *remote_policy;
unsigned char remote_key[CRYPTO_KEY_LEN];

/* Allocate policies and generate key */
remote_policy = ast_policy_alloc();
local_policy = ast_policy_alloc();
ast_get_random(local_key, CRYPTO_KEY_LEN);
ast_policy_set_key(local_policy, local_key, CRYPTO_KEY_LEN);
ast_base64encode(local_key64, local_key, CRYPTO_KEY_LEN, sizeof(local_key64));

/* Activate SRTP */
suite_val = AST_AES_CM_128_HMAC_SHA1_80;
key_len = ast_base64decode(remote_key, salt, sizeof(remote_key));
ast_policy_set_suite(local_policy, suite_val);
ast_policy_set_suite(remote_policy, suite_val);
ast_policy_set_key(remote_policy, remote_key, key_len);
ast_rtp_set_io_policy(rtp, remote_policy, local_policy);

(The return values should be checked, but I have removed it from the
example to make it clearer)
Comments:By: Olle Johansson (oej) 2005-10-09 14:14:01

Cool. Moving this to post 1.2.

By: mikma (mikma) 2005-10-17 06:35:55

Updated patch, added functions to set policy parameters specified in MIKEY SP (RFC 3830) payloads and possibility to install security policies on demand in a callback function.

By: rchen (rchen) 2005-11-20 02:45:59.000-0600

looking for instruction on how to use the patch.  Please point us to the right direction.

By: Olle Johansson (oej) 2005-11-20 08:55:55.000-0600

I don't think we should #ifdef SRTP functionality.

Also, the naming of the functions is unfortunate. Better to use rtp_ than ast_ or ast_rtp_ , just using ast_ does not make sence, since I don't see these functions as generic enough - they're very RTP specific, right?

Thanks for contributing!

By: mikma (mikma) 2005-11-21 08:28:44.000-0600

I could move the SRTP implementation to a resource module (res_srtp), that registers the SRTP interface in load_module. Rtp.c would contain stub functions that use the SRTP interface if available, or else return an error.

(I'll rename the policy functions also.)

What do you think?

By: Olle Johansson (oej) 2005-11-21 10:52:14.000-0600

I see, whe're depending upon a third party library.

For information: The SRTP library used here is licensed under a special BSD-like license, see http://srtp.sourceforge.net/license.html. Seems to be no problem for us to use it.

So a separate resource module that is compiled and installed provided we have the srtp library seems to be a good choice. From channels like chan_sip, we need to be  able to check for the existence of such a module to enable/disable acceptance of and sending of SRTP invites. We should always understand them, so I don't think we should have compile time #ifdef statements in the channels. What do you think?

By: Olle Johansson (oej) 2005-11-21 10:54:44.000-0600

Do you have any code changes ready for chan_sip ?

By: mikma (mikma) 2005-11-21 13:45:54.000-0600

We could add an ast_rtp_is_srtp_supported function or similar, that indicates if the srtp module is available and loaded.

I don't have any patch for chan_sip, but I have implemented sdescriptions and MIKEY (using libmikey) in a GPL:ed SIP channel if you are interested:

http://www.hem.za.org/chan_exosip/chan_exosip-0.1.tar.gz

By: Olle Johansson (oej) 2005-11-21 14:02:31.000-0600

The problem is that we need to update chan_sip as well. I can't steal that code from your exosip channel unless you disclaim it.

If you disclaim it, I can take out the code needed. We can't include the exosip channel in the main cvs due to licensing problems. Maybe in addons.

Without srtp in chan_sip, the chances of this patch getting into cvs are pretty low.  

Would it be really hard for you to help us adding support to chan_sip and disclaim that work? Or tell us how to do it?

I hope you understand my dilemma here.

By: mikma (mikma) 2005-11-21 14:58:00.000-0600

I understand, and I'll extract the portions of my sdp negotiator that's related to sdescriptions and post it as an example here when I have updated the patch.

chan_sip also needs TLS support since the SRTP master keys are in clear text in sdescriptions.

By: Olle Johansson (oej) 2005-11-21 15:56:11.000-0600

Yes, I know about the TLS requirement. Just to clarify: Your examples will be disclaimed?

Thank you for helping us out here. And thank you for contributing to Asterisk!

By: mikma (mikma) 2005-11-22 16:41:39.000-0600

Yes, the examples I post here will be disclaimed.

By: mikma (mikma) 2005-11-29 11:55:49.000-0600

I have updated the patch. It now includes basic support for draft-ietf-mmusic-sdescriptions-12.txt in chan_sip and I have moved the SRTP implementation to a separate library called res_srtp.

The SIP channel will automatically use sdescriptions if received in a SDP offer, and res_srtp is loaded. SRTP with sdescriptions key exchange can be activated in outgoing offers by setting _SIP_SRTP_SDES=1 in extension.conf before executing Dial.

Edit: I Forgot to mention that sdescriptions require a secure transport, for example IPsec or TLS, since the keys are exchanged in clear text.



By: John Todd (jtodd) 2005-12-07 18:47:20.000-0600

Sorry if I'm missing the obvious here, but I don't see any instructions or additional command sequences for testing.  Is there a list of settings that are required to get this working between two Asterisk systems?  This is a lot of code to fish through, so a quickstart would be ideal.

By: mikma (mikma) 2005-12-08 03:31:24.000-0600

SRTP + sdescriptions is automatically used on incoming calls if the caller supports it in the SDP offer. It can be activated in all outgoing SIP calls originated from the current channel by setting a variable (_SIP_SRTP_SDES) in extensions.conf. The dial fails if the callee doesn't support SRTP and sdescriptions.

exten => 2345,1,Set(_SIP_SRTP_SDES=1)
exten => 2345,2,Dial(SIP/1001)
exten => 2345,3,Congestion

Edit: res_srtp.so need to be loaded before a call can use SRTP.



By: Christoph Fürstaller (kex) 2006-01-05 06:52:21.000-0600

Great Job!!

Looked for this implementation for a while. Great step!

Just patched my asterisk sources and compiled asterisk. But when i start asterik with asterisk -vvvvvc, i get this errors : /

[res_srtp.so] => (Secure RTP (SRTP))
Warning, flexibel rate not heavily tested!
Speicherzugriffsfehler
Ouch ... error while writing audio data: : Broken pipe
Warning, flexibel rate not heavily tested!

Anyone know what this is?

KeX

By: philipp2 (philipp2) 2006-01-05 09:41:29.000-0600

For those that do not understand German:
Speicherzugriffsfehler = memory access violation

By: mikma (mikma) 2006-01-06 06:12:05.000-0600

KeX: Both "Ouch ... error while writing audio data: : Broken pipe" and "Warning, flexibel rate not heavily tested!" come from mpg123.

Did Asterisk crash and created a core dump? Loading the core dump info gdb and executing "thread apply all bt" would tell more about the crash in that case.

/Mikael

By: Christoph Fürstaller (kex) 2006-01-08 23:48:46.000-0600

mikma: I can't find such a dump file. I started asterisk in the dir I compiled it, there is no such file, neigther in my home or tmp dir.
Here is the output what I get when I start asterisk: http://phpfi.com/95317

KeX

By: mikma (mikma) 2006-01-09 02:34:21.000-0600

You may need to enable core dumps with:
ulimit -c unlimited

Have you verified that res_srtp is causing the problems? What happens if you disable res_srtp.c in modules.conf and load it manually instead?

By: Christoph Fürstaller (kex) 2006-01-09 04:13:17.000-0600

hi
I re-patched the original source files and recompiled asterisk. now it is working. But I think it is not using SRTP: As mentioned above: "The dial fails if the callee doesn't support SRTP and sdescriptions." I tried to call from a non SRTP capable phone to a SRTP capable phone with success. And I successfully recorded the call with cain.

After break I'll set up another asterisk and try to establish a call between them via SRTP.

KeX

By: Olle Johansson (oej) 2006-01-09 09:24:34.000-0600

New branch for testing:

http://svn.digium.com/svn/asterisk/team/oej/securertp/

Added some error messages and changed a few option-debug.

This code needs more comments that explains what's going on.

By: mikma (mikma) 2006-01-11 09:43:08.000-0600

Could you describe more in detail what type of documentation are needed?

KeX: You will still be able to receive an unsecured SIP call when you have loaded res_srtp, and you currently need to look in the debug log to check if it's secure or not.

By: Christoph Fürstaller (kex) 2006-01-11 10:11:28.000-0600

Hi Mikma,

I defined an extention in the dialplan:
exten => 2345,1,Set(_SIP_SRTP_SDES=1)
exten => 2345,2,Dial(SIP/1001)

A Snom 190 (should be capable of SRTP) is assigned to extention 1001. On this Phone I can dump all packages. In the Initial SIP/SDP Packages i can see an header which defines the crypto thing (aes) --> (sry, i'm not at work so i don't know the exact name)
But this header is only in the first paket, in the following pakages there are no crypto headers any more. And I successfully recordet this call via cain. So I think SRTP is not enabled in this call?

Think i've to test this more in detail.

KeX

By: mikma (mikma) 2006-01-11 11:05:20.000-0600

I don't know if Snom 190 supports the sdescriptions draft, and if it does it's  possible that it only can be used with tls transport.

Chan_sip offers a audio stream using the RTP/SAVP protocol (i.e. SRTP) if   _SIP_SRTP_SDES has been enabled.

The called phone should reject that offer if it can't establish a SRTP stream, but maybe Snom 190 downgrades to RTP/AVP in the answer. I don't think it's RFC compliant, but it needs to be tested for in and rejected in chan_sip.

By: philipp2 (philipp2) 2006-01-11 15:48:22.000-0600

On the snom 190: It appears that the SNOM does work without TLS. If instead you want TLS you'll need DNS SRV entry for the server that points to sips.tcp.mydomain.org (and don't forget to upload the server certificate to the phone).
Also: The recent SNOM firmware versions include some notes about SRTP fixes.

Taken from the SNOM FAQ: "Technically speaking SRTP doesn't make sense without having a TLS based signalling connection. However, the media is still secure even if SRTP is used without TLS. The master key sent in the INVITE is not used as such but is instead used to generate the actual SRTP encryption keys via AES. These keys are then used to encrypt the RTP. For a completely secure call, SRTP can be used in conjunction with a TLS signalling connection."

Sources:
http://www.ip-phone-forum.de/showthread.php?t=73380
http://www.voip-info.org/tiki-index.php?page=Asterisk+encryption

By: John Todd (jtodd) 2006-01-14 12:32:33.000-0600

This may be relevant, as it notes some progress that Snom and Ingate have made with each other.  Perhaps someone can test?  I'll try to patch again if I have time this week, but it's not looking good for minutes in a day...

To: Voipsec@voipsa.org
From: Per Cederqvist <ceder@ingate.com>
Date: Fri, 13 Jan 2006 12:14:52 +0100
Subject: Re: [VOIPSEC] sdescriptions interop testing -- looking for
implementations

Per Cederqvist <ceder@ingate.com> writes:

> Does anybody here have a pointer to any product or program that
> implement sdescriptions?  We at Ingate Systems have recently
> implemented support in our SIP-aware firewalls for transcoding SIP
> calls between SRTP (negotiated via sdescriptions) and plain RTP, and
> we would like to do some interop testing.
>
> Drop me a line if you have a SIP client, voicemail server, or any
> other kind of SIP system that understands sdescriptions, and are
> willing to test it (via the Internet) against our implementation.  I
> will summarize to the list (unless you ask me not to be included in
> the summary).

The only vendor that responded and had an implementation ready for
test was Snom.  Ahmar Ghaffar of Snom and myself have now concluded
successful interop testing between a Snom 360 phone and an Ingate
Firewall 1400.  We ran SRTP over the internet.  The Ingate Firewall
transcoded it to unencrypted RTP and sent it to a Cisco 7960 phone
(that, to my knowledge, don't support SRTP).

If anybody else wants to perform Interop testing with the Ingate
Firewall or Ingate SIParator, just drop me a line.  I also have an
Ethereal trace of the call setup and teardown (including the first and
last few SRTP packets, with the corresponding clear-text RTP packets
on the LAN).  To help others implement SRTP with sdescriptions I am
prepared to send them to anybody that is interested, so that you can
use them as test vectors for your implementation.

Ahmar Ghaffar also asked me to say that Snom is available if anybody
wants to do interop testing with them.  You can contact him via email
to ghaffar at snom.de.

The complete line of Snom products that supports SRTP is snom320,
snom360 and snom300.

   /ceder
--
Per Cederqvist <ceder@ingate.com>, Chief Architect, Ingate Systems AB

_______________________________________________
Voipsec mailing list
Voipsec@voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

By: John Todd (jtodd) 2006-01-14 13:00:39.000-0600

Well, that was easier than I thought it would be - I've asked Per@Ingate to test against my platform (1234@loligo.com) and we'll see if this works with Ingate's version of SRTP.

By: mikma (mikma) 2006-01-14 13:44:46.000-0600

I downloaded sdes.zip referenced in another message on the Voipsec list. It contains a Ethereal trace and readable SIP dump of a secured call between snom360/5.1 and Pbxnsip PBX.

Snom360 offers the following SDP in the INVITE:

o=root 8852175 8852175 IN IP4 172.20.25.100
s=call
c=IN IP4 172.20.25.100
t=0 0
m=audio 51766 RTP/AVP 0 2 3 18 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:Y9yjmhF2WhrBauTS58ODi2SBYoUspIrlg8ZrcxVY
a=rtpmap:0 pcmu/8000
a=rtpmap:2 g726-32/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=encryption:optional
a=sendrecv

Asterisk generates a SDP offer with RTP/SAVP as transport method and an authentication tag length of 80 bits which is the default according to specified in RFC3711.

Snom360 uses RTP/AVP as transport method, and 32 bits authentication tag. Asterisk should accept the offer above, but I'm not sure Snom360 would accept the transport method and tag length currently offered by the patch.

http://voipsa.org/pipermail/voipsec_voipsa.org/2006-January/001087.html

By: John Todd (jtodd) 2006-01-17 11:18:49.000-0600

Verified operational with Ingate devices under their (still unreleased) SRTP train.  Here's the confirmation mail:

To: John Todd <jtodd@loligo.com>
Subject: Re: Fwd: Re: Fwd: Re: [VOIPSEC] sdescriptions interop testing -- looking for implementations
From: Per Cederqvist <ceder@ingate.com>
Date: Tue, 17 Jan 2006 13:50:07 +0100

I used an Ingate Firewall 1400.  The software I'm using is an
unreleased snapshot of our development sources.  Version 4.3.4 does
not include SRTP support.  We have not yet decided what the next
version will be called, but it will probably be 4.4.0 or 5.0.0, and
that will include SRTP.  (We don't plan to make any more 4.3.x
releases, but if we do, they will most likely not include SRTP
support.)

Our SRTP encryption is also based on the SRTP package from Cisco.  (We
have verified it against an implementation we made from scratch in
Python, for our automated functional test system, so we have high
confidence in that the cryptographic transforms are correct.)

   /ceder

By: John Todd (jtodd) 2006-01-29 20:39:52.000-0600

Slight changes to recent TRUNK have caused patches to fail, but changes are minor.

By: Olle Johansson (oej) 2006-01-30 00:53:34.000-0600

jtodd: Please test the branch instead of the patch. The branch will be kept up to date more easily, so there's no need to update the patches.

By: John Todd (jtodd) 2006-01-30 02:26:45.000-0600

Looks like the most recent Snom firmware works:

From: "Ahmar Ghaffar" <ghaffar@snomNO.SPAMde>
To: "'John Todd'" <jtodd@loligoDOOMEDTOGET.SPAMcom>
Subject: AW: Asterisk SRTP testing with Snom
Date: Mon, 30 Jan 2006 10:27:28 +0100


Ok I have tried from a public IP. SRTP is working fine. I could hear the
screaming or at least that‚s what it sounds like :-). Our versions 5.2 and
onwards for snom320/snom360 should be compatible with your stuff.

By: Olle Johansson (oej) 2006-01-30 03:45:36.000-0600

That's great!

By: mikma (mikma) 2006-01-30 05:48:19.000-0600

Could you add res/res_srtp.c? It seems to be missing in the branch.

/Mikael

By: Olle Johansson (oej) 2006-01-30 05:52:09.000-0600

Thanks mikma. Done.

By: John Todd (jtodd) 2006-01-31 00:05:34.000-0600

This does not work with the Beta release of CounterPath (aka: Xten) Eyebeam2.  It seems that Eyebeam demands TLS in order to have functional SRTP in an originated call from Eyebeam to Asterisk, and inbound from Asterisk it gives a media error (enclosed as "eyebeam-inbound-test" file) when I force encryption using the Set(_SIP_SRTP_SDES=1) configuration.

I can see it being reasonable that TLS is required, but at the same time it would be nice to turn it off.  I don't see CounterPath changing their software, as this is a security issue (transmitting the key for media in an unencrypted signalling path) but it's a matter of taste, I suppose.  I'll just wait for TLS support in Asterisk, eh?  <sigh>

By: mikma (mikma) 2006-01-31 10:39:41.000-0600

You could try to use OpenSER as proxy server. I think it can translate between SIP over UDP and TLS.

By: mikma (mikma) 2006-02-01 16:16:03.000-0600

Patch for ASTERISK-6189 needs to be merged in the branch.

I have tried the Snom soft phone version 5.3, and I was able to negotiate SRTP encryption both when initiating the call from Asterisk and Snom.

http://www.snom.com/download/snom360-5.3.exe

By: dlu (dlu) 2006-02-06 12:03:30.000-0600

Hi all. Are there any news about tls from exosip move to chan_sip?

By: hauke (hauke) 2006-02-13 04:35:55.000-0600

Is it possible to add these patches into the main SVN trunk?
I want to use T.38 and SRTP.

Thanks.

By: lele (lele) 2006-02-21 08:51:53.000-0600

When chan_sip is starting a non crypto call, sending out an INVITE without any sdesc (_SIP_SRTP_SDES is unset), but the reply from the peer includes a sdes proposal, a crypto policy get set up and activated, without the local key being exchanged.

At least Snom 5.x always answer INVITE with a a=crypto line and "a=encryption:optional" in the sdp, calling one without setting _SIP_SRTP_SDES gives asterisk using srtp and the snom expecting unenctypted rtp, and nice white noise in the earpiece.

By: mikma (mikma) 2006-03-07 08:41:54.000-0600

I have uploadad ast_srtp7.patch which should fix that problem. The patch also makes it possible to optionally use SRTP if it's supported by the peer. It is activated with "_SIP_SRTP_SDES=optional".

By: Josh (jmcadam) 2006-03-21 23:31:18.000-0600

Works well for me with snom softphone :) - anyone happen to know what Sipura / Linksys stuff uses for its SRTP implementation? is it something like MIKEY?

By: mikma (mikma) 2006-03-22 04:27:50.000-0600

Sipura uses a public key method. To enable a secure call, both devices need to be configured with a certificate signed by the same "miniCA", and the key negotiation is sent in proprietary SIP INFO messages.

By: Yves Schumann (starwarsfan) 2006-03-28 08:37:25.000-0600

Hi there,

I have successfully compiled * out of the securertp branch with ast_srtp7.patch and connected two snom360 phones. A secure call to the standard info number 500 or  the echo test works nice. If I try to make a secure call between the two phones, * is telling me "Cannot native bridge in SRTP" (line 1867 in rtp.c). If I set canreinvite=no, then its leaving at line 1858 in rtp.c (the if clause).

What is the next step to enable secure calls between two phones?

By: mikma (mikma) 2006-03-28 09:08:17.000-0600

Bridging is broken in the srtp branch, since the solution for bug ASTERISK-6189 hasn't been applied.

By: Yves Schumann (starwarsfan) 2006-03-29 04:59:17.000-0600

Hi!

After applying patch for ASTERISK-6189 it`s working. Bridging is not working anyway but thats not a problem at the moment. Additionally I have set canreinvite=no to close this out.

Now the call from phone to phone is encrypted between caller and * and between * and recipient.

Thx a lot for your help!



By: Yves Schumann (starwarsfan) 2006-04-03 08:39:47

Hello!

What is the actual state of affairs on including the srtp functionality into the main branch? Is the functionality included in coming releases? And how? Still with the libsrtp?

Some questions and hopefully some answers next time...

Yves

By: John Todd (jtodd) 2006-04-15 20:13:36

1) I know that there are new patchs for chan_sip (in ast_srtp7.patch) but could the author please update to SVN-HEAD with one big patch?  (patch attempt output enclosed at bottom)

2) Is there any particular reason this patch is languishing?  We're now "post-1.2".  The code has been shown to work, and interoperate with several other vendor's SRTP stacks.  While it is true that secure key exchange has not been solved, that is kind of irrelevant.  The code works, let's get it in and the key exchange problem will be next on the list to figure out through some creative method.



[root@beta asterisk]# patch -p0 < ../patches/srtp.patch6
patching file include/asterisk/aes.h
patching file include/asterisk/rtp.h
Hunk #1 succeeded at 68 (offset 1 line).
Hunk #2 succeeded at 221 with fuzz 2 (offset 1 line).
patching file rtp.c
Hunk #1 FAILED at 70.
Hunk #2 succeeded at 127 with fuzz 2 (offset -2 lines).
Hunk #3 succeeded at 355 (offset -3 lines).
Hunk #4 succeeded at 673 (offset -4 lines).
Hunk ASTERISK-1 succeeded at 1377 (offset 61 lines).
Hunk ASTERISK-2 succeeded at 1378 (offset -4 lines).
Hunk ASTERISK-3 succeeded at 1509 (offset 61 lines).
Hunk ASTERISK-4 succeeded at 1514 (offset -4 lines).
Hunk ASTERISK-5 succeeded at 1843 with fuzz 2 (offset 31 lines).
1 out of 9 hunks FAILED -- saving rejects to file rtp.c.rej
patching file channels/chan_sip.c
Hunk #1 succeeded at 157 with fuzz 1 (offset 54 lines).
Hunk #2 succeeded at 775 with fuzz 2 (offset 77 lines).
Hunk #3 FAILED at 2079.
Hunk #4 succeeded at 2353 with fuzz 2 (offset 90 lines).
Hunk ASTERISK-1 succeeded at 2484 with fuzz 2 (offset 61 lines).
Hunk ASTERISK-2 FAILED at 3322.
Hunk ASTERISK-3 succeeded at 3848 (offset 204 lines).
Hunk ASTERISK-4 succeeded at 3741 with fuzz 2 (offset 61 lines).
Hunk ASTERISK-5 succeeded at 3919 with fuzz 2 (offset 202 lines).
Hunk ASTERISK-6 succeeded at 3867 (offset 57 lines).
Hunk ASTERISK-7 succeeded at 4029 (offset 202 lines).
Hunk ASTERISK-8 succeeded at 4647 (offset 56 lines).
Hunk ASTERISK-9 succeeded at 4809 (offset 202 lines).
Hunk ASTERISK-10 succeeded at 4710 (offset 56 lines).
Hunk ASTERISK-11 succeeded at 4887 with fuzz 1 (offset 206 lines).
Hunk ASTERISK-12 succeeded at 4826 with fuzz 2 (offset 61 lines).
Hunk ASTERISK-13 FAILED at 4838.
3 out of 17 hunks FAILED -- saving rejects to file channels/chan_sip.c.rej
patching file res/Makefile
Hunk #1 succeeded at 111 (offset 51 lines).
Hunk #2 succeeded at 128 with fuzz 2 (offset 11 lines).
patching file res/res_srtp.c
[root@beta asterisk]#

By: Holger Hornung (netview) 2006-05-01 04:26:36

Patch 'ast_srtp7.patch' is broken now for the actual branch (1.2.7.1). Is there any new patch planned for the future?

By: Serge Vecher (serge-v) 2006-05-01 10:02:38

Netview: patches are not intended for stable releases, but for the trunk. The latest code for SRTP is in the following trunk-integrated branch: http://svn.digium.com/view/asterisk/team/oej/securertp-trunk/ . The branch is currently at rev. 16500 vs 23000 for main trunk, but hopefully OEJ will fix that once he finds time. Please test the branch and report the results here. Thank you!

By: Holger Hornung (netview) 2006-05-01 10:11:59

vechers: I use OEJ MWI-branch 'asterisk/team/oej/subscribemwi-1.2/' and I want to use srtp too - any hint how can I do this without a working patch (ast_srtp6.patch is ok!)



By: mikma (mikma) 2006-05-01 10:23:37

team/oej/securertp-trunk doesn't contain the srtp patch.

By: Olle Johansson (oej) 2006-05-10 09:34:40

since the patches was accidentally deleted I am trying to recover the code from the failed branch into securertp-trunk.... Hopefully we can get this back together again.

By: Serge Vecher (serge-v) 2006-05-10 10:07:24

sorry about that, Olle.

By: Holger Hornung (netview) 2006-05-10 10:38:52

I have uploaded my backup of 'ast_srtp6.patch'!

By: Olle Johansson (oej) 2006-05-10 11:02:52

vechers: I've done that too, no worries...

THanks for the backup!

By: mikma (mikma) 2006-05-20 15:47:21

I have made a new patch against trunk revision 29093. Before the patch is applied you need to copy res_srtp.c from the branch. It can be done with:

svn cp http://svn.digium.com/svn/asterisk/team/oej/securertp/res/res_srtp.c res/res_srtp.c

By: Olle Johansson (oej) 2006-06-09 04:22:37

I think I've succeeded in creating a new branch with this code - "securertp-trunk". Please, please, test it and tell me what's missing!

Also, this code does not bother with video RTP as far as I can understand. That needs to be handled. There may be two keys and two encryption schemes. Or no encryption of the video. If we're only sending video prompts, there's no need to encrypt that and use the processor for it.

By: Olle Johansson (oej) 2006-06-09 04:24:33

We also need patches for autoconf/menuselect for this.

By: Olle Johansson (oej) 2006-06-09 07:59:15

mikma: Can you check the new securertp-trunk and give me the patches needed to update that to your new version?

By: Arif-Uz-Zaman (arifzaman) 2006-06-13 03:40:18

I have successfully compiled Asterisk-1.2.9.1 with ast_srtp6.patch and ast_srtp7.patch.
Now, i'm trying to make call between two snoom360 soft phones in RTP encryption mode. But, the debug shows 'Cannot native bridge in SRTP'.

scenario like this:
2001(192.168.30.98)----->Asterisk(192.168.30.123)----->2002(192.168.30.3)

Help me with your valuable feedback. Please let me know, if you need anything from me.

Thanks in advance.


INVITE Message:
---------------
INVITE sip:2002@2001;user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.30.98:5060;branch=z9hG4bK-hdukzbyzn43h;rport
From: "2001" <sip:2001@2001>;tag=1brt2rf1na
To: <sip:2002@2001;user=phone>
Call-ID: 3c267100a875-mfzohfsawoqe@192-168-30-98
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:2001@192.168.30.98:5060;line=lal9kivp>
P-Key-Flags: keys="3"
User-Agent: snom190-3.56i
Accept-Language: en
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer
Supported: timer, 100rel, replaces
Session-Expires: 3600
Content-Type: application/sdp
Content-Length: 300

v=0
o=root 1802012876 1802012876 IN IP4 192.168.30.98
s=call
c=IN IP4 192.168.30.98
t=0 0
m=audio 10004 RTP/AVP 8 101
k=base64:O8s2OIvhqnmb3VRCVH6lahFxV2pFq8E3kV1Y2ZNjXMY=
a=rtpmap:8 pcma/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=encryption:optional
a=sendrecv

OK for INVITE:
--------------
<-- SIP read from 192.168.30.3:1361:
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.30.123:5060;branch=z9hG4bK795de125;rport=5060
From: "2001" <sip:2001@192.168.30.123>;tag=as7bee19e0
To: <sip:2002@192.168.30.3:1361;line=ojn9itpa>;tag=83o2aqbtpi
Call-ID: 499b3ef4448bfba824562f6612bb1658@192.168.30.123
CSeq: 102 INVITE
Contact: <sip:2002@192.168.30.3:1361;line=ojn9itpa>;flow-id=1
User-Agent: snomSoft/5.3
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO
Allow-Events: talk, hold, refer
Supported: timer, 100rel, replaces, callerid
Content-Type: application/sdp
Content-Length: 303

v=0
o=root 2634 2635 IN IP4 192.168.30.3
s=call
c=IN IP4 192.168.30.3
t=0 0
m=audio 52636 RTP/AVP 8 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:M+lUwiFSg7VEw0SiUlrbLlfNTNw3blKHQVLGze6o
a=rtpmap:8 pcma/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=encryption:optional
a=sendrecv

Output:
-------
   -- Executing Set("SIP/2001-03c0", "_SIP_SRTP_SDES=1") in new stack
   -- Executing Dial("SIP/2001-03c0", "SIP/2002|60|tT") in new stack
   
   
   -- Attempting native bridge of SIP/2001-03c0 and SIP/2002-4354
Jun 13 20:00:40 NOTICE[2878]: rtp.c:1858 ast_rtp_bridge: Cannot native bridge in SRTP.



By: Yves Schumann (starwarsfan) 2006-06-13 04:00:34

Hi there!

I`m a little bit confused on how to get the srtp-asterisk running. Is it right to do the following?
- check out the rev. 29093 from http://svn.digium.com/svn/asterisk/trunk
- check out res_srtp.c from the branch http://svn.digium.com/svn/asterisk/team/oej/securertp/res/res_srtp.c
- apply patch "ast_srtp_trunk_r29093.patch"

It would be nice if someone could tell me if I do the right steps (or not :-)

Thx a lot,
Yves

By: Yves Schumann (starwarsfan) 2006-06-13 06:45:34

arifzaman:

You have to add the line "canreinvite=no" to the device configuration in your sip.conf file. This is needed to let the srtp traffic always go through asterisk. Normally asterisk is trying to do a re-invite after some rtp packets passed to let the traffic go directly from the caller to the callee and visa versa. But with srtp this is (at the moment) not possible.

Yves



By: Arif-Uz-Zaman (arifzaman) 2006-06-13 07:06:36

StarWarsFan,

Now, it's working perfectly. Thanks for ur valuable feedback.

Thanks a lot!
ARIF

By: Yves Schumann (starwarsfan) 2006-06-14 00:54:10

Arifzaman: Can you tell me how you have done this? I'm interested in your steps to bring asterisk up and running. I tried the steps described in my other posting but during compiling I got this error message:

gcc -shared -Xlinker -x -o res_srtp.so -include ../include/autoconfig.h -I../include -I.. -fPIC -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g3 -O6 -march=i686  @srtp_INCLUDE@ res_srtp.o @srtp_LIB@
gcc: @srtp_INCLUDE@: Datei oder Verzeichnis nicht gefunden
gcc: @srtp_LIB@: Datei oder Verzeichnis nicht gefunden
make[1]: *** [res_srtp.so] Fehler 1
make[1]: Leaving directory `/coding-linux/asterisk_srtp_29093_work/res'
make: *** [subdirs] Fehler 1

libSRTP is installed right and the build-in tests where passed. The two entried "@srtp_INCLUDE@" and "@srtp_LIB@" seems to be a little bit strange. Is there something wrong with the patch or how I have done this?

Thx for your help!
Yves

By: Arif-Uz-Zaman (arifzaman) 2006-06-14 01:32:52

Update ur res/Makefile with the following lines:

ifneq ($(wildcard $(CROSS_COMPILE_TARGET)/usr/local/include/srtp)$(wildcard $(CROSS_COMPILE_TARGET)/usr/include/srtp),)
 ifneq ($(wildcard $(CROSS_COMPILE_TARGET)/usr/local/lib/libsrtp.so)$(wildcard $(CROSS_COMPILE_TARGET)/usr/local/lib/libsrtp.a)$(wildcard $(CROSS_COMPILE_TARGET)/usr/lib/libsrtp.so)$(wildcard $(CROSS_COMPILE_TARGET)/usr/lib/libsrtp.a),)
   MODS+=res_srtp.so
   SRTP_LIBS=-lsrtp
 endif
endif

res_srtp.so: res_srtp.o
$(CC) $(SOLINK) -o $@ ${CYGSOLINK} $< ${CYGSOLIB} $(SRTP_LIBS)



Now, during compiling u'll get this message:

gcc  -pipe  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g3  -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE  -O6 -march=i686         -fomit-frame-pointer  -DOPENSSL_NO_KRB5 -fPIC   -c -o res_srtp.o res_srtp.c
gcc -shared -Xlinker -x -o res_srtp.so  res_srtp.o  -lsrtp

Try with that.
And let me know, if you need anything from me.

Cheers,
ARIF

By: Yves Schumann (starwarsfan) 2006-06-14 01:47:07

Arif: As I came back to write my quick'n'dirty solution I find your posting. :-) Thx for your help but let me explain how I quicksolved the problem:

I changed line 98 in res/Makefile from

 $(CC) $(SOLINK) -o $@ $(CFLAGS) $(SRTP_INCLUDE) $< $(SRTP_LIB)

to

 $(CC) $(SOLINK) -o $@ $(CFLAGS) -I/usr/local/include/srtp $< -lsrtp

I think this leads to the same result as your solution. But anyway, I will include your solution into res/makefile because this is the "clean" way. :-)

Would be nice if the developers could include your trick into the patch!?

Thx a lot
Yves



By: Arif-Uz-Zaman (arifzaman) 2006-06-14 02:31:20

StarWarsFan,

Excellent...

Cheers,
ARIF

By: Olle Johansson (oej) 2006-06-15 07:08:54

I've updated the securertp-trunk branch and need input for this branch. Please test that branch and *not* the patches to make sure I have included the latest code. Thank yoU!

By: mikma (mikma) 2006-06-15 17:53:28

I have added a patch that fixes some problems in the branch, and I have also merged ast_srtp7.patch.

By: Olle Johansson (oej) 2006-06-16 06:53:48

Thanks. Seems like res_srtp.c was missing from that branch totally, but I've added it now.

By: mikma (mikma) 2006-06-16 09:57:17

You need to run autoconf after modifying configure.ac. I have uploaded a patch which includes a diff of configure for those without autoconf.

The res_srtp.so target should be located in res/Makefile and not Makefile, also included in the asterisk-oej-securertp-trunk-r34481.patch.



By: mikma (mikma) 2006-06-28 13:11:40

ast_srtp_depend.patch: Add srtp dependency to res_srtp.c

By: Marek Cervenka (cervajs) 2006-07-18 10:26:53

svn checkout http://svn.digium.com/svn/asterisk/team/oej/securertp-trunk/ securertp-trunk

bash#./configure
...
checking for asprintf... yes
checking for vasprintf... yes
checking for compiler atomic operations... no
configure: creating ./config.status
configure: error: could not make ./config.status
make: *** [config.status] Error 1

update
bash#patch < ast_srtp_depend.patch
bash#autoconf;./configure;make menuselect;make
compiled ok

tested
eyebeam 1.5.5 - FAIL (eyebeam NEED TLS)
gxp 2000 fw1.1.1.7 - OK (sip debug in attachment gs-srtp.txt)
Sipura SPA 941 - FAIL? (not compatible - from comment)



By: evilbunny (evilbunny) 2006-07-22 11:43:17

While testing this trunk I came across an interesting bug with ENUMLOOKUP function, and since I didn't know what version the trunk currently is I don't know where else to report it to.

Basically using ENUMLOOKUP function is broken, regardless which enum zone you add in the parameter list it always uses e164.arpa.

By: cloos (cloos) 2006-07-23 10:58:51

evilbunny:

Are you using the 1.2 syntax of ENUMLOOKUP or the trunk (aka 1.4) syntax?

If you have this in 1.2:  ${ENUMLOOKUP(${EXTEN},sip,1,freenum.org)}
then you need this in 1.4: ${ENUMLOOKUP(${EXTEN},sip,,1,freenum.org)}

Note the extra comma; the field that used to be a union of options and Nth has become two separate fields.  Since this branch is based on trunk you need to use the 1.4 syntax with it.

By: evilbunny (evilbunny) 2006-07-23 13:04:22

Before I posted I was checking up on documentation, but there didn't seem to be any changes so I thought it was broken.

Also I put togeather a small howto in the hope of getting more people interested in using SRTP at least between asterisk servers.

http://www.e164.org/wiki/AsteriskSRTP

By: cloos (cloos) 2006-07-23 16:30:07

I didn't find it in the docs either.  My ISN gateway started failing after I upgraded to trunk (to see whether trunk deal better with out of order dtmf packets) and I had to discover the change by browsing the src.

Incidently, if the parameter c were used, as in:

${ENUMLOOKUP(+13015611020,ALL,c,loligo.com)}

(from doc/README.enum in the 1.2 branch)

it would become:

${ENUMLOOKUP(+13015611020,ALL,c,,loligo.com)}

in the new syntax.  

So, if the penultimate field in the 1.2 syntax is a number, it must be preceded by a new, empty field in the 1.4 syntax.  But if it is not a number it must be followed by an empty field in the 1.4 syntax.

By: evilbunny (evilbunny) 2006-07-23 21:02:10

Seems they fixed the enum function from responding with duplicates, any chance we can get this branch merged with trunk?

http://svn.digium.com/view/asterisk?rev=37691&view=rev

By: John Todd (jtodd) 2006-07-23 22:18:26

Of course, I'm very interested in the patches to the ENUMLOOKUP functions and documentation.  However, I think you might consider opening a new ticket on it since I think it probably deserves it as a separate thread from the SRTP patches...

By: evilbunny (evilbunny) 2006-07-23 22:38:28

My comment about the enumlookup changes, I wanted the changes to the trunk merged into this branch, not only does the enumlookup changes get incorporated but any other fixes made and it also keeps the SRTP code in sync with the main trunk so that when the word is given the SRTP code is merged into the main trunk with a minimum of fuss as it's been tested with current code etc...

Someone mentioned that they tested this branch in the past but they had to stop using it due to memory leaks etc, so getting any/all fixes into tested systems would be in everyones best interest etc...



By: Serge Vecher (serge-v) 2006-07-24 10:04:08

evilbunny: you are right, the automerge process has failed on securertp-trunk branch at r36288 vs. current r38149. Oej is the maintainer of this branch and is known to be extremely very busy at the moment ;) When he has time, he will resolve the automerge issues between the branch and trunk -- please watch the commit list to see when that takes place. Thanks!

By: evilbunny (evilbunny) 2006-07-24 10:14:55

Also is anyone planning to add/finish MIKEY code at all?

SRTP seems to be useless without some kind of key exchange, sipura uses MIKEY I don't know of anything that uses s/mime both are covered by RFCs



By: mikma (mikma) 2006-07-29 07:14:13

I'm implementing MIKEY in chan_sip, based on libmikey (GNU LGPL) from minisip.org. MIKEY messages can be big, in particular when using certificates. This probably means that TCP transport will be needed for all modes except shared secret.

Do you have any proof that sipura uses MIKEY? AFAIK it uses a proprietary key exchanged based on a "mini CA", and it requires that both devices in a call are configured with the same mini CA.

FYI: Session Description Protocol (SDP) Security Descriptions for Media Streams (AKA sdrescriptions) has been published as RFC 4568.

http://www.ietf.org/rfc/rfc4568.txt

By: evilbunny (evilbunny) 2006-09-14 00:04:04

Most likely a trunk bug, however this branch won't build...

/bin/rm -f libmxml.a
/usr/bin/ar crvs libmxml.a mxml-attr.o mxml-entity.o mxml-file.o mxml-index.o mxml-node.o mxml-search.o mxml-set.o mxml-private.o mxml-string.o
a - mxml-attr.o
a - mxml-entity.o
a - mxml-file.o
a - mxml-index.o
a - mxml-node.o
a - mxml-search.o
a - mxml-set.o
a - mxml-private.o
a - mxml-string.o
ranlib libmxml.a
make[1]: Leaving directory `/home/src/asterisk/securertp-trunk/mxml'
make[1]: Entering directory `/home/src/asterisk/securertp-trunk/menuselect'
make[2]: Entering directory `/home/src/asterisk/securertp-trunk/menuselect/mxml'
make[2]: *** No rule to make target `libmxml.a'.  Stop.
make[2]: Leaving directory `/home/src/asterisk/securertp-trunk/menuselect/mxml'
make[1]: *** [mxml/libmxml.a] Error 2
make[1]: Leaving directory `/home/src/asterisk/securertp-trunk/menuselect'
make: *** [menuselect/menuselect] Error 2

By: Donny Kavanagh (donnyk) 2006-09-26 13:59:20

Has anyone made a patch which will apply against Latest trunk? Or know of a another branch w/ srtp?  (keeping in mind /team/oej/securertp-trunk is way out of date)

By: deti (deti) 2006-10-05 10:23:27

Does not seem to work here either. It seems the automerge process didn't succeed since end of june. Unfortunately the menuselect stuff is up to date because it comes from an external repository (http://svn.digium.com/svn/menuselect). Could anyone please try to fix the current securertp-trunk?

By: jmls (jmls) 2006-11-04 02:18:34.000-0600

ping. seems the patches are out of date. Can we get an update on the patches please ? Thanks

By: Serge Vecher (serge-v) 2006-11-09 10:32:05.000-0600

this code is being tracked in oej's securertp-trunk branch. OEJ, when you have a chance, please give this one some loving -- looks like a wanted feature given the watchlist. Thanks!

By: T.J. Kniveton (kniveton) 2006-11-18 15:06:11.000-0600

You may want to update your link to the draft (now RFC):
http://www.ietf.org/rfc/rfc4568.txt

By: mikma (mikma) 2006-12-08 16:43:03.000-0600

Update to trunk revision 48358
------------------------------

I have made a patch for http://svn.digium.com/svn/asterisk/team/oej/securertp-trunk revision 37744 which updates the branch to trunk revision 48358.

I tried to upload the file, but it failed. It's probably to large.
It's available at http://hem.no-ip.info/ast-securertp-r37744-trunk-r48358.patch.gz [1630954 bytes]

/Mikael

By: dlu (dlu) 2006-12-09 09:31:53.000-0600

Mikma, thanks for doing that. Please write a little howto here how to use the patch for ppl they are not so experienced in svn (like me:-). Thanks

By: mikma (mikma) 2006-12-09 13:04:19.000-0600

I have uploaded a patch against trunk revision 48360.

Run the following commands to apply the patch:

$ cd asterisk
$ patch -p1 < ast_srtp_trunk_r48360.patch

By: Serge Vecher (serge-v) 2006-12-15 09:24:45.000-0600

has anybody tested the latest patches from mikma? Reports do help with the decision of putting new features into the trunk.

By: evilbunny (evilbunny) 2006-12-15 15:21:53.000-0600

Has keyhandling been dealt with or is this just encryption for the RTP stream still?

Without the key handling the password can be sniffed and then its trivial to decrypt the stream.

By: mikma (mikma) 2006-12-15 16:11:58.000-0600

I have a patch which implements the MIKEY keying method using libraries from minisip.

But it need some more work, most important building mikey as a loadable Asterisk module.

By: dlu (dlu) 2006-12-24 18:11:40.000-0600

Hey mikma. Merry xmas:-) A patch for the new 1.4.0 will be welcome to continue the tests on the first stable 1.4 *.

By: Serge Vecher (serge-v) 2006-12-27 14:01:59.000-0600

dlu, since this is a new feature, testing (via the bug-tracker at least) needs to be only against latest trunk, not 1.4.

Keep testing ast_srtp_trunk_r48491.patch, so that the Grinch does not steal this valuable feature from 1.6! Happy holidays....

By: mikma (mikma) 2007-01-18 17:22:35.000-0600

I have uploaded the a patch which adds SRTP and MIKEY support to
Asterisk.

The patch depends on several external libraries:

* libsrtp from sourceforge

* libmutil, libmnetutil, libmcrypto and libmikey from
 Minisip svn trunk (r3124). http://www.minisip.org/

Libmikey and the patch supports multiple MIKEY modes: Pre-shared,
Public-key (RSA), DH-Sign, DHHMAC and RSA in reverse mode.

Pre-shared and DHHMAC modes use the Asterisk SIP secret, and DH-Sign and the RSA
modes need a local certificate. The certificate, private key and CA
bundle need to be PEM encoded and located in:

* ${astetcdir}/asterisk.crt
* ${astetcdir}/asterisk.key
* ${astetcdir}/ca-certificates.crt

Currently DHHMAC is used for all secured outbound calls. DH-Sign
and the RSA modes are supported for inbound calls if a certificate is
present.

The patch has been tested and is interoperable with Minisip (svn trunk).


Compilation
-----------

* install required libraries

* run rootstrap.sh

* configure and select res_mikey, and res_srtp in menuselect

* build


Known issues
------------

* Sometimes RTP packets are received before the MIKEY response in the
 SDP answer, which may cause one-way-audio.

* Certificate and CA database file names should be configurable.

* No support for intermediate certificates.

By: Anthony LaMantia-2 (anthonyl) 2007-01-21 15:05:11.000-0600

why is it that no one at digium or oej has made a group branch for this issue so it can finally be put into trunk?

By: Leif Madsen (lmadsen) 2007-01-22 22:41:09.000-0600

anthonyl: you mean this one?

http://svn.digium.com/svn/asterisk/team/oej/securertp-trunk

By: Anthony LaMantia-2 (anthonyl) 2007-01-23 00:09:43.000-0600

i'm aware of that one, but pushing for a branch in group/ssrtp based of the current release of trunk would be not only more visible, but also not keep other developers with commit access to the branch from making changes that would speed up this IMO very important feature being integrated into asterisk proper.

By: Leif Madsen (lmadsen) 2007-01-23 09:08:33.000-0600

anthonyl: ahhhhh yes, I would 100% agree. I was just about to head to bed when I wrote that, so it didn't quite click it wasn't a group branch :)

By: Anthony LaMantia-2 (anthonyl) 2007-01-23 14:30:46.000-0600

so.. is anyone planning on starting the branch...?

By: kumar vivek (kumarvivek_24) 2007-01-29 04:29:30.000-0600

hi all

i did tls for asterisk-1.2.10 which works fine. now i want to add srtp for this branch of asterisk what should i do.
reply soon.
urgent

By: Serge Vecher (serge-v) 2007-02-01 11:55:16.000-0600

since this is a new feature, what you need to do is create a patch against the latest trunk and post it here. See  http://www.asterisk.org/developers/Patch_Howto. Also, don't forget to get a disclaimer on file, if you haven't already.

By: kumar vivek (kumarvivek_24) 2007-02-08 05:38:57.000-0600

hi
i m sorry to be mistaken as a developer. I don't want to add such kind rather i want to clarify my problem .First of all i m using tls+tcp as i have modified chan_sip.c for tls+tcp.For tls+tcp patch is already available on the net ,i m using the same.Further I have added patch ast_srtp6.patch and ast_srtp7.patch with asterisk-1.2.10. After adding these patches  my server is working well with udp,tcp,tls(eyebeam-1.5.2).But when i use media encryption, my server CLI shows "cannot provide secure audio requested in SDP offer".Actually i want to know this is problem with asterisk or eyebeam.If asterisk then what should i do?

By: Serge Vecher (serge-v) 2007-02-08 09:50:35.000-0600

kumarvivek_24: as I've said earlier, the discussion of feature patches is strictly against trunk, not 1.2.x or 1.4.x releases. If you need help with applying these patches, please seek help off the bug-tracker. Asterisk-backports.org is a good place to get started.

By: kumar vivek (kumarvivek_24) 2007-02-09 04:16:57.000-0600

hi
i have successfully add ast_srtp6.patch and ast_srtp7.patch to asterisk-1.2.10 after adding tls+tcp patch. i have succesfully compile the asterisk.I have successfully registered Xlite(tcp+tls+srtp) with asterisk.I made a call successfully between two xlite phone but one problem is still there. there is no audio between between xlite when we enable srtp for xlite.In case of only tls everything is fine.

By: kumar vivek (kumarvivek_24) 2007-02-12 23:15:49.000-0600

hi all
i have successfully patched my asterisk trunk revision 37419 with patch ast_srtp6.patch,ast_stp7.patch and ast_srtp_depend.patch. After this i have successfully compiled my code and run asterisk successfully. But when i made call between two xlite phone with srtp ,call is made successfully but there is no voice between them and at CLI of asterisk there is message "Cannot provide secure audio requested in SDP offer". May i know the reason behind it and Possible solution for it.

By: kumar vivek (kumarvivek_24) 2007-02-12 23:17:01.000-0600

hi all
i have successfully patched my asterisk trunk revision 37419 with patch ast_srtp6.patch,ast_stp7.patch and ast_srtp_depend.patch. After this i have successfully compiled my code and run asterisk successfully. But when i made call between two xlite phone with srtp ,call is made successfully but there is no voice between them and at CLI of asterisk there is message "Cannot provide secure audio requested in SDP offer". May i know the reason behind it and Possible solution for it.

By: kumar vivek (kumarvivek_24) 2007-02-12 23:26:07.000-0600

hi all
i have successfully patched my asterisk trunk revision 37419 with patch ast_srtp6.patch,ast_stp7.patch and ast_srtp_depend.patch. After this i have successfully compiled my code and run asterisk successfully. But when i made call between two xlite phone with srtp ,call is made successfully but there is no voice between them and at CLI of asterisk there is message "Cannot provide secure audio requested in SDP offer". May i know the reason behind it and Possible solution for it.

By: Olle Johansson (oej) 2007-02-13 08:35:12.000-0600

Can anyone confirm whether the code in the securertp-trunk branch still works? I need to know so we can work ahead. As I add TCP/TLS to codename pineapple (chan_sip3) I need to integrate that with the securertp so we have a secure solution.

By: Olle Johansson (oej) 2007-02-13 08:36:33.000-0600

btw, I brought the branch up to date with svn trunk yesterday.

By: Marek Cervenka (cervajs) 2007-02-13 12:15:01.000-0600

trying on centos4 but i have problem with minisip compiling
bash#cd libmnetutil
bash#./bootstrap
---cut--
Putting files in AC_CONFIG_AUX_DIR, `config'.
+ autoconf
configure.ac:1: error: possibly undefined macro: dnl
     If this token and others are legitimate, please use m4_pattern_allow.
     See the Autoconf documentation.

going to minisip forums&mailinglists...

mini-testing-howto
http://www.voip-info.org/wiki/view/Asterisk+SRTP

please delete duplicate post form kumarvinek. tnx



By: mikma (mikma) 2007-02-13 13:16:30.000-0600

You may need to add the path containing minisip's m4 files to
/usr/share/aclocal/dirlist.

# echo /usr/local/share/aclocal >> /usr/share/aclocal/dirlist

oej: The branch doesn't seem updated to me, at least not the public svn.
Are you going to use ast_srtp_r51249_mikey_r3124.patch?
It uses MIKEY which secures the keys end-to-end and supports several modes including two modes with Diffie Hellman key exchange, DHSIGN and DHHMAC, which provides perfect forward secrecy.

By: Bjoern (nightcrawler) 2007-03-23 03:28:29

Hi everybody,

I?ve got a problem regarding the current securertp-trunk and a question regarding SRTP-Parameters.

Problem:
I followed the steps documented in http://www.voip-info.org/wiki/view/Asterisk+SRTP and when checking out from the securertp-trunk I got Rev No 59179 and 137 (btw.: Why do I get two revision numbers?). I tried to compile on Fedora Core 6 i686 with standard kernel and gcc 4.1.1. When I ran the configure-script I first got an error stating that something around fi in line 30314 was wrong => I just removed the fi, which seem to have worked. Now I get the following, if I run configure:
?
checking for h323.h... no
checking for linux/ixjuser.h... no
checking for gtk-config... no
checking for curl-config... /usr/bin/curl-config
checking for mandatory modules: ... ok
configure: creating ./config.status
configure: error: could not make ./config.status  

Can anybody give me any hint what is wrong? Release 1.4.0, as well as trunk rev. 48360 with the ast_srtp_trunk_r48360.patch-patch compile without any problems.

Question:
When I use trunk 48360 with the patch and activate SRTP by Set(_SIP_SRTP_SDES=1), is there some way to force encryption? I would like asterisk to immediately stop the call-setup, if it receives an INVITE or OK during setup without an appropriate key. Another idea would be to pass on the keys in an INVITE/OK during setup enabling a direct SRTP-connection between two phones. Is anybody working on this? If none of the procedures are possible yet, I would like to try to get the first suggestion into chan_sip.c. Though I might need some help there.

Thanks,
Bj?rn

By: Marek Cervenka (cervajs) 2007-03-23 06:01:04

fedora6
http://www.voip-info.org/wiki/view/Asterisk+SRTP

minisip libraries compiled ok (r3250)

svn co securertp-trunk
./configure

--cut--
checking for tgetent in -ltinfo... no
checking for tone_zone_find in -ltonezone... no
checking for tone_zone_find in -ltonezone... (cached) no
./configure: line 30314: syntax error near unexpected token `fi'
./configure: line 30314: `fi'

securertp-trunk depends on zaptel. this is not good

when i comment out tonezone, i have same problem as nightcrawler

svn trunk r51249+patch compiled ok
tested gxp-2000(1.1.3.2) srtp forced  <-> asterisk+SRTP+echotest
[Mar 23 15:29:47] DEBUG[11215] res_srtp.c: SRTP unprotect: authentication failure



By: Bjoern (nightcrawler) 2007-03-23 06:39:20

I now tried to comment out the elif in line 35004 of configure, just to see what happens. Well the configure now exits okay, but make won't work, I guess for this reason:

--cut--
sed: file ./confCf8792/subs-3.sed line 103: unterminated `s' command
config.status: creating makeopts
sed: file ./confCf8792/subs-3.sed line 103: unterminated `s' command
config.status: creating channels/h323/Makefile
sed: file ./confCf8792/subs-3.sed line 103: unterminated `s' command
--/cut--

This is what I now get with the configure-script changed and consequently the three files mentioned are not created and make fails.

By: G (k6) 2007-03-23 07:20:54

I have the same problem that nightcrawler(0061283) with srtp-trunk:

- ./configure: error in line 30314 was wrong. Remove the fi. I run configure again
and I get this:
...
configure: creating ./config.status
configure: error: could not make ./config.status  

I have update the patch too...and I also had tried with ./bootstrap

(Asterisk 1.4.1)

By: Bjoern (nightcrawler) 2007-03-28 05:03:42

A big thank you to cervajs,

now it works, using the patched trunk 51249, but only if I compile without codec_zap (I just disselect this one in menuselect and leave evrything else unchanged).
The secure-trunk still won't compile.

With the patched version I now have some other trouble. As a direct-SRTP connection is still not possible, I have to route audio via the Asterisk. When I now use a phone as caller, that does not support MIKEY, but sdescription for keyexchange, Asterisk detects this and answers the INVITE with a corresponding OK containig an sdescription Master-Key. For the second part between Asterisk and callee, Asterisk now always uses MIKEY (I also have Set(_SIP_SRTP_SDES=1) in the extensions.conf for the callee). Unfortunately, some of my phones don't understand MIKEY. Is there any possibility of configuring per user whether MIKEY or sdescription should be used? Furthermore, is there a possibility to totally block all unencrypted call attempts?

Cheers,
Bjoern

PS: Which is the most reliable operating environment for the securertp-trunk?



By: mikma (mikma) 2007-03-28 05:46:58

I'll upload an updated patch soon, which makes it possible to select between MIKEY and sdescriptions for outgoing calls.

Btw, secure-trunk doesn't work AFAIK, it needs to be updated.

By: Bjoern (nightcrawler) 2007-04-01 09:56:56

That would be great.
Still I have one question left. Can anybody tell me, if there is a possibility to force encryption, by not accepting incoming INVITE-Messages without a usable key or without usable MIKEY content? Also OK-Messages without the necessary parameters anwering an INVITE from the Asterisk should be rejected.

By: mikma (mikma) 2007-04-23 13:53:07

Uploaded patch for trunk r61760, which supports libmikey r3250 from minisip.

This patch supports the following channel variables:

SIPSRTP=[optional|<any>]
Outgoing methods:
SIPSRTP_CRYPTO=[enable|disable] - Enable/disable sdescriptions
SIPSRTP_MIKEY=[enable|disable]  - Enable/disable MIKEY DH-HMAC

Example dialplan entries:

exten => 2002,1,Set(_SIPSRTP=optional)
exten => 2002,n,Set(_SIPSRTP_CRYPTO=enable)
exten => 2002,n,Dial(SIP/600@asterisk2)
exten => 2002,n,Congestion

exten => 2003,1,Set(_SIPSRTP=require)
exten => 2003,n,Set(_SIPSRTP_MIKEY=enable)
exten => 2003,n,Dial(SIP/600@asterisk2)
exten => 2003,n,Congestion

Known issues:
* MIKEY method doesn't support optional encryption.
* The callee can't force encryption or select method.
* The caller need to hangup if it requires encryption and it isn't available.

By: John Todd (jtodd) 2007-04-23 21:24:15

Looks good.  Your "known issues" do probably deserve some attention, though.

Here are my comments (not on the patch, which I'll try shortly, but on your brief description):

1) Can I request as possibly a feature the ability to set the key from within the dialplan?  This would allow database-driven shared secrets to happen much more easily rather than _only_ having them defined in sip.conf


2) Failure modes seem to require some additional work.  What happens when encryption fails?  How does chan_sip (via Dial) indicate what kind of failure has happened back to the dialplan?  

Thanks for all the work!

By: Bjoern (nightcrawler) 2007-05-06 06:06:22

I meanwhile got the chance to test the new patch (for 61760). Unfortunately it does not work as I hoped it would.
I've got two users (alice and bob) configured, set canreinvite = no and using snom  300. The following is my extensions.conf:

exten => 100,1,Set(_SIPSRTP=require)
exten => 100,2,Set(_SIPSRTP_CRYPTO=enable)
exten => 100,3,Dial(SIP/alice,20)
exten => 100,4,VoiceMail(100@default)

exten => 101,1,Set(_SIPSRTP=require)
exten => 101,2,Set(_SIPSRTP_CRYPTO=enable)
exten => 101,3,Dial(SIP/bob,20)
exten => 101,4,VoiceMail(101@default)

Now when I disable encryption on both phones I'm still able to do the call. When I disable encryption on one of the phones, I'm also still able to do the call. Futhermore the call is encrypted then between * and the phone with encryption enabled. This still leaves the one using this phone, to think the call is secure because the corresponding symbol is shown on the phone. I also tried the scenario between an SJPhone-Softphone, which doesn't support encryption at all and one snom using encryption. Still I can do a half-encrypted call. So have I done something completely wrong, is this the behaviour wanted or is it not working properly?

Cheers Bjoern

PS: Another idea I had, was using the OpenSER as a filter for INVITEs and there correspondings OKs. I will than simply drop messages which do not contain a key, matching a predefined regex. Because I would need the OpenSER anyway to support sips, as the Asterisk sips implementation still seems to be not reliabe enough. I tell you in about two weeks time about any sucess.



By: mikma (mikma) 2007-05-06 06:35:23

The patch currently relies on the other end to reject the call if it can't support required encryption. The Snom phone is not supposed to accept SAVP/RTP media if it can't encrypt the call. But Asterisk anyways needs to check the SDP answer and hangup the call if it's unencrypted.

And there are currently no way to force encryption of both call legs.

By: Bjoern (nightcrawler) 2007-05-11 10:59:49

Hi there!

@mikma: Thank you very much, so I'm going to try my OpenSER-Idea

There are a few other things I've tried with the new patch. All were done using 3 Snom 300, firmware 6.5.8:
Normal calls => I occasionally (about every tenth call) get no audio in one of the directions, sometimes I don't even get audion in any direction.
attended and unattended call transfer => both worked fine.
conferencing with three users (alice, bob, john) using the F_CONFERENCE - function of the Snom. This seems to turn the Phone initiating the conference into a mixer and wokrs fine when encryption is off, regardless if I'm permitting reINVITEs or prohibiting them. When Encryption is on:
1. alice calls bob => 2way audio
2. alice puts bob on hold => music at bobs site, dialtone for alice
3. alice calls john => 2 way audio
4. alice initiates a conference => alice, hears evrybod, john hears evrybody, but bob hears nobody (but music has stopped), though he is heard by the others.
I took a look with wireshark and found out, that bob didn't get the INVITE alice generates when initiating the conference. Anyway I doubt if he would have to get it, I just think the asterisk would have to continue sending audio it receives from alice (as i suppose alice also acts as a mixer in this scenario). Instead, after alice initiates the conference there are no more inbound (S)RTP-packets to
bob, only outbound ones.

By: philipp2 (philipp2) 2007-05-11 11:03:59

nightcrawler: Note that SNOM firmware 6.5.9 has a SRTP fix (roll-over-counter ROC)

By: Bjoern (nightcrawler) 2007-05-30 08:17:08

Hi all,

I meanwhile tried the MIKEY functionality of the current patch with a Siemens OptiPoint 410 S Beta-Firmware V7 R 0.7.0. After two attempted calls to the voicebox, it crashes the Asterisk. In Debug the last info I get is "Generate TGK", next is "terminate called after throwing an instance of 'MikeyExceptionMessageLengthException' what(): Given data is too short to form a KeyData.Payload". Now I'd like to know, which kind of MIKEY-exchange is supported by the Patch, is it only DH? The information I got from Siemens is that they are using a MIKEY 0 which does not encrypt the key at all, though I don't find any documentation on this.

cheers, Bjoern

By: mikma (mikma) 2007-05-30 09:51:18

The patch supports Pre shared, DH-SIGN, DH-HMAC, and RSA-R, but currently only DH-HMAC is used in outgoing calls. And I haven't tried Pre shared ( with NULL encryption.

By: kumar vivek (kumarvivek_24) 2007-07-20 23:11:06

hello all,

i have successfully add srtp patch with my asterisk tar version . But i want to do some more.
Is it possible that in case of srtp call between two snom phone, rtp will pass direct peer to peer,without asterisk is in the path.
             
              rtp
       snom <====> snom

please help me.
thanks to all.

By: CarloPi (cpiga) 2007-09-01 13:00:49

I had problem in compiling mikey in patched asterisk, on two different debian etch machines.
make[1]: Entering directory `/home/cpiga/Asterisk/asterisk-trunk/menuselect'
make[2]: Entering directory `/home/cpiga/Asterisk/asterisk-trunk/menuselect'
make[2]: `menuselect' is up to date.
make[2]: Leaving directory `/home/cpiga/Asterisk/asterisk-trunk/menuselect'
make[1]: Leaving directory `/home/cpiga/Asterisk/asterisk-trunk/menuselect'
menuselect/menuselect --check-deps   menuselect.makeopts
Generating embedded module rules ...
make[1]: Nothing to be done for `all'.
make[1]: Nothing to be done for `all'.
  [CXX] mikey.cc -> mikey.oo
mikey.cc:124: error: 'certificate_chain' was not declared in this scope
mikey.cc:124: error: template argument 1 is invalid
mikey.cc:124: error: invalid type in declaration before ';' token
mikey.cc:125: error: 'ca_db' was not declared in this scope
mikey.cc:125: error: template argument 1 is invalid
mikey.cc:125: error: invalid type in declaration before ';' token
mikey.cc: In constructor 'ast_mikey_config::ast_mikey_config()':
mikey.cc:447: error: invalid conversion from 'int' to 'CertificateChain*'
mikey.cc:447: error:   initializing argument 1 of 'MRef<OPType>::MRef(OPType) [with OPType = CertificateChain*]'
mikey.cc:447: error: invalid conversion from 'int' to 'CertificateSet*'
mikey.cc:447: error:   initializing argument 1 of 'MRef<OPType>::MRef(OPType) [with OPType = CertificateSet*]'
mikey.cc: In member function 'int ast_mikey_config::add_ca_file(const char*)':
mikey.cc:466: error: 'ca_db' was not declared in this scope
mikey.cc:466: error: template argument 1 is invalid
mikey.cc:466: error: invalid type in declaration before '=' token
mikey.cc:469: error: 'ca_db' is not a class or namespace
mikey.cc:472: error: invalid conversion from 'int' to 'CertificateSet*'
mikey.cc:472: error:   initializing argument 1 of 'MRef<OPType>::MRef(OPType) [with OPType = CertificateSet*]'
mikey.cc:475: error: base operand of '->' is not a pointer
mikey.cc:476: error: base operand of '->' is not a pointer
mikey.cc:477: error: base operand of '->' is not a pointer
mikey.cc:478: error: expected type-specifier before 'certificate_exception'
mikey.cc:478: error: expected `)' before '&' token
mikey.cc:478: error: expected `{' before '&' token
mikey.cc:478: error: 'e' was not declared in this scope
mikey.cc:478: error: expected `;' before ')' token
mikey.cc: In member function 'int ast_mikey_config::add_cert(const char*, const char*)':
mikey.cc:492: error: 'certificate_chain' was not declared in this scope
mikey.cc:492: error: template argument 1 is invalid
mikey.cc:492: error: invalid type in declaration before '=' token
mikey.cc:495: error: 'certificate_chain' is not a class or namespace
mikey.cc:498: error: invalid conversion from 'int' to 'CertificateChain*'
mikey.cc:498: error:   initializing argument 1 of 'MRef<OPType>::MRef(OPType) [with OPType = CertificateChain*]'
mikey.cc:501: error: incomplete type 'certificate' used in nested name specifier
mikey.cc:502: error: base operand of '->' is not a pointer
mikey.cc:503: error: base operand of '->' is not a pointer
mikey.cc:504: error: base operand of '->' is not a pointer
mikey.cc:505: error: expected type-specifier before 'certificate_exception'
mikey.cc:505: error: expected `)' before '&' token
mikey.cc:505: error: expected `{' before '&' token
mikey.cc:505: error: 'e' was not declared in this scope
mikey.cc:505: error: expected `;' before ')' token
mikey.cc: In function 'int mikey_init()':
mikey.cc:770: error: 'ca_db' has not been declared
mikey.cc:771: error: 'certificate_chain' has not been declared
mikey.cc: In function 'void mikey_uninit()':
mikey.cc:793: warning: converting to non-pointer type 'int' from NULL
mikey.cc:794: warning: converting to non-pointer type 'int' from NULL
mikey.cc: In function 'int mikey_add_global_ca_file(const char*)':
mikey.cc:805: error: base operand of '->' is not a pointer
mikey.cc:806: error: base operand of '->' is not a pointer
mikey.cc:807: error: base operand of '->' is not a pointer
mikey.cc:808: error: expected type-specifier before 'certificate_exception'
mikey.cc:808: error: expected `)' before '&' token
mikey.cc:808: error: expected `{' before '&' token
mikey.cc:808: error: 'e' was not declared in this scope
mikey.cc:808: error: expected `;' before ')' token
mikey.cc: In function 'int mikey_add_global_cert_file(const char*, const char*)':
mikey.cc:822: error: incomplete type 'certificate' used in nested name specifier
mikey.cc:823: error: base operand of '->' is not a pointer
mikey.cc:824: error: base operand of '->' is not a pointer
mikey.cc:825: error: base operand of '->' is not a pointer
mikey.cc:826: error: expected type-specifier before 'certificate_exception'
mikey.cc:826: error: expected `)' before '&' token
mikey.cc:826: error: expected `{' before '&' token
mikey.cc:826: error: 'e' was not declared in this scope
mikey.cc:826: error: expected `;' before ')' token
/usr/include/libmutil/MemObject.h: In member function 'bool MRef<OPType>::decrease() [with OPType = certificate*]':
/usr/include/libmutil/MemObject.h:366:   instantiated from 'MRef<OPType>::~MRef() [with OPType = certificate*]'
mikey.cc:501:   instantiated from here
/usr/include/libmutil/MemObject.h:335: error: invalid use of undefined type 'struct certificate'
/usr/include/libmikey/KeyAgreementDH.h:40: error: forward declaration of 'struct certificate'
/usr/include/libmutil/MemObject.h:366:   instantiated from 'MRef<OPType>::~MRef() [with OPType = certificate*]'
mikey.cc:501:   instantiated from here
/usr/include/libmutil/MemObject.h:344: warning: possible problem detected in invocation of delete operator:
/usr/include/libmutil/MemObject.h:344: warning: invalid use of undefined type 'struct certificate'
/usr/include/libmikey/KeyAgreementDH.h:40: warning: forward declaration of 'struct certificate'
/usr/include/libmutil/MemObject.h:344: note: neither the destructor nor the class-specific operator delete will be called, even if they are declared when the class is defined.
/usr/include/libmutil/MemObject.h: In member function 'void MRef<OPType>::setPointer(OPType) [with OPType = certificate*]':
/usr/include/libmutil/MemObject.h:367:   instantiated from 'MRef<OPType>::~MRef() [with OPType = certificate*]'
mikey.cc:501:   instantiated from here
/usr/include/libmutil/MemObject.h:300: error: cannot dynamic_cast 'o' (of type 'struct certificate* const') to type 'struct certificate*' (target is not pointer or reference to complete type)
mikey.cc: At global scope:
mikey.cc:183: warning: 'int message_to_base64(MRef<MikeyMessage*>, char*, size_t)' defined but not used
mikey.cc:208: warning: 'void dump_hex(unsigned char*, size_t)' defined but not used
make[1]: *** [mikey.oo] Error 1
make: *** [res] Error 2

By: mikma (mikma) 2007-09-01 13:30:20

Are you using libmikey (minisip) revision 3250?

"Uploaded patch for trunk r61760, which supports libmikey r3250 from minisip."

By: CarloPi (cpiga) 2007-09-02 04:33:02

"Uploaded patch for trunk r61760, which supports libmikey r3250 from minisip."
So how can I download the right version of minisip?
I tried with
svn checkout -r3250 http://svn.minisip.org/minisip/trunk/libmikey libmikeyr3250.
But with
$cat version
0.4.1+r3249
And it depends on libmtuils, lib..etc. etc.
so I need the right version of minisip to get. How?

By: mikma (mikma) 2007-09-04 04:31:07

I have uploaded an update patch. It has been tested with asterisk trunk revision 81432 and minisip trunk revision 3412.



By: Jau-Jan Tzeng (kennethzeng) 2007-09-05 01:44:54

OS: fedora core 6
I follow the steps in http://www.voip-info.org/wiki/view/Asterisk+SRTP,
and after entering "./bootstrap.sh" in installing Asterisk.

[root@localhost asterisk-trunk]# ./bootstrap.sh
Generating the configure script ...
configure.ac:14: /usr/bin/m4: Warning: sub-expression 1 not present
autom4te: /usr/bin/m4 failed with exit status: 1
configure.ac:14: /usr/bin/m4: Warning: sub-expression 1 not present
autom4te: /usr/bin/m4 failed with exit status: 1
autoheader: /usr/bin/autom4te failed with exit status: 1

Q1:Does anything go wrong? Do I have to apply other patches like
  ast_srtp7.patch, etc? Or is there any document that I can follow
  to patch this?

[root@localhost asterisk-trunk]#make menuselect
  I can't select the res_srtp in 8.Resource Modules.

Q2:How can I restart the installation and patch process. By simply delete the
asterisk-trunk directory? Sorry, I'm new to this. thank you.

By: mikma (mikma) 2007-09-07 12:30:47

Have you tried running bootstrap.sh on a unpatched asterisk tree? Does it work? The error looks unrelated to the patch I think.

You can reverse the patch by adding "-R" to the patch command.

By: Daniel Fernandez (student) 2007-09-12 10:17:27

Hi all,

I'm a student and I'm currently working on my thesis wich deals with secure SIP and Asterisk. I've managed to set up an Asterisk-Server so far, but I'm not able to install the libsrtp-Module correctly. I've followed the instructions at: http://www.e164.org/wiki/AsteriskSRTP and downloaded the latest files including the patch (ast_srtp_trunk_r48491.patch). The problem is that "./configure" allways returns me:
[...]
./configure: line 5867: AST_PROG_LD: command not found
[...]
./configure: line 6097: AST_CHECK_GNU_MAKE: command not found
[...]
./configure: line 6645: ACX_PTHREAD: command not found
./configure: line 6670: syntax error near unexpected token `ALSA,'
./configure: line 6670: `AST_EXT_LIB_SETUP(ALSA, Advanced Linux Sound Architecture, asound)'

I would appreciate it very much, if someone could give me any suggestion.
Thank you.

Btw, I'm running Asterisk 1.2.24

By: Daniel Fernandez (student) 2007-09-12 15:16:11

In the meantime i found out, there seems to be a problem with certain versions of autoconf . Instead of using autoconf you just have to run the bootstrap.sh script. Sadly this leads to a new error:
[...]
./configure: line 7598: syntax error near unexpected token `srtp,'
./configure: line 7598: `AST_EXT_LIB(srtp, srtp_init, srtp/srtp.h, SRTP, libSRTP)'

Does anybody know how to solve this problem???

P.S.: I'm using autoconf 2.61 and the patch from above (ast_srtp_trunk_r48491.patch) isn't working as expected.



By: mikma (mikma) 2007-09-12 16:21:53

Which patch are you using? I can't find the line "AST_EXT_LIB(srtp, srtp_init, srtp/srtp.h, SRTP, libSRTP)"
in ast_srtp_trunk_r48491.patch.

By: Daniel Fernandez (student) 2007-09-12 16:53:20

hi mikma,

these are the steps I tried out...

Building and Installing libSRTP:
================================
wget http://srtp.sourceforge.net/srtp-1.4.2.tgz
tar zxvf srtp-1.4.2.tgz
cd srtp
./configure
make
make install

until now everything went ok, but...

Building and Installing Asterisk with SRTP:
===========================================
svn checkout http://svn.digium.com/svn/asterisk/team/oej/securertp-trunk
cd securertp-trunk
wget "http://bugs.digium.com/file_download.php?file_id=12524&type=bug" -O ast_srtp_depend.patch
patch -p1 < ast_srtp_depend.patch

it looks like the current version of this patch isn't exactly maching the files provided by the trunk...

./bootstrap.sh
./configure

at this point it shows up the error. I even tried to apply the patch after executing the bootstrap, but without success. The only way to run the configure script is to comment out the line 7598 in configure itself, but than I still can't compile the software.

Thanks

By: mikma (mikma) 2007-09-13 03:29:36

I see, the patch you downloaded (ast_srtp_trunk_r48491.patch) is made against revision 48491 of trunk not the branch "securertp-trunk".

I recommend ast_srtp_r81432_mikey_r3412.patch instead, which supports both SDESC and MIKEY.

By: Jau-Jan Tzeng (kennethzeng) 2007-09-13 09:48:29

Thank you mikma.
I try to run ./bootstrap on the unpatched version

[root@localhost asterisk-trunk]# ./bootstrap.sh
Generating the configure script ...
configure.ac:14: /usr/bin/m4: Warning: sub-expression 1 not present
autom4te: /usr/bin/m4 failed with exit status: 1
configure.ac:14: /usr/bin/m4: Warning: sub-expression 1 not present
autom4te: /usr/bin/m4 failed with exit status: 1
autoheader: /usr/bin/autom4te failed with exit status: 1

Then I try to patch this, and continue to run "./bootstrap" that. The following are the outputs.

[root@localhost asterisk-trunk]# patch -p1 < ast_srtp_r81432_mikey_r3412.patch patching file build_tools/menuselect-deps.in
patching file channels/chan_sip.c
patching file channels/Makefile
patching file channels/sdp_crypto.c
patching file channels/sdp_crypto.h
patching file channels/sdp_mikey.c
patching file channels/sdp_mikey.h
patching file channels/sip_srtp.c
patching file channels/sip_srtp.h
patching file configure.ac
patching file CREDITS
patching file include/asterisk/aes_internal.h
patching file include/asterisk/autoconfig.h.in
patching file include/asterisk/mikey.h
patching file include/asterisk/rtp.h
patching file main/cryptostub.c
patching file main/rtp.c
patching file makeopts.in
patching file res/Makefile
patching file res/mikey.cc
patching file res/mikey.h
patching file res/res_mikey.c
patching file res/res_srtp.c

[root@localhost asterisk-trunk]# ./bootstrap.sh
Generating the configure script ...
configure.ac:14: /usr/bin/m4: Warning: sub-expression 1 not present
autom4te: /usr/bin/m4 failed with exit status: 1
configure.ac:14: /usr/bin/m4: Warning: sub-expression 1 not present
autom4te: /usr/bin/m4 failed with exit status: 1
autoheader: /usr/bin/autom4te failed with exit status: 1

It seems that the outputs are the same.

ps the whole steps I use. Do I miss something? thanks for your answering.

1.install LIBSRTP
2.install MINISIP Lib
 #svn co -r3412 svn://svn.minisip.org/minisip/trunk minisip-trunk
 #cd /usr/src/minisip-trunk
 #cd libmutil; ./bootstrap; ./configure --prefix=/usr; make; make install;
  cd ..
 #cd libmnetutil; ./bootstrap; ./configure --prefix=/usr; make; make install;      
  cd ..
 #cd libmcrypto; ./bootstrap; ./configure --prefix=/usr; make; make install;
  cd ..
 #cd libmikey; ./bootstrap; ./configure --prefix=/usr; make; make install; cd ..
3.install Asterisk
 #svn co -81432 http://svn.digium.com/svn/asterisk/trunk asterisk-trunk
 #cd asterisk-trunk
 #wget "http://bugs.digium.com/file_download.php?file_id=15384&type=bug"
 #patch -p1 < ast_srtp_r81432_mikey_r3412.patch
 #./bootstrap

By: Daniel Fernandez (student) 2007-09-14 16:57:26

I've carried out kennethZeng's tutorial and got also an error during ./configure of asterisk:
[...]
./configure: line 25165: syntax error near unexpected token `0.4.1,'
./configure: line 25165: `AM_MINISIP_CHECK_LIBMIKEY(0.4.1, PBX_MIKEY=1, PBX_MIKEY=0)'

while the installation and patch with revision 61760 worked just fine.

BTW: if I understand right, there is no support for TLS available in Asterisk 1.4.x at the moment?

Thank you

By: mikma (mikma) 2007-09-15 02:04:45

The latest patches with "mikey" in the file name depends on the minisip project. And you need to install libmikey and its dependencies before bootstrapping asterisk.

There is no support for SIP TLS in 1.4 or in trunk, but I think there exist a patch and/or branch.

But TLS is not required for using MIKEY messages since they already are protected.

By: mikma (mikma) 2007-09-15 02:16:27

kennethZeng, since you are having problems running bootstrap on the unpatched version it indicates a problem with autoconf or m4, I think.

By: Daniel Fernandez (student) 2007-09-15 17:38:31

Thanks a lot mikma,

I'm running asterisk r81432 now with the correspondent patch. The ip phones I use for testing are snom 300 and minisip clients. Although calls work in conjunction with sdes, I can't establish an efficient connection with mikey. The calling party has always an encrypted channel to the server, but the callee hasn't and you just hear noise. I've only tested mikey in the pre shared keys mode till now.

I've added these lines to the extensions.conf:
[...]
exten => _X.,1,Set(_SIPSRTP=require)
exten => _X.,n,Set(_SIPSRTP_MIKEY=enable)
exten => _X.,n,Dial(SIP/${EXTEN},20,tT)
[...]

Do I need to configure anything else?

Also I have to enter a different sip-uri within the minisip clients composed by "phone number"@"ip adress" of the collee instead of a simple phone number, since I've activated mikey.



By: Daniel Fernandez (student) 2007-09-18 16:35:44

I'm still wondering about MIKEY. Is it really supposed to work with Asterisk r81432? And if so, which SIP-Clients would you recommend for testing purposes?

By: Daniel Fernandez (student) 2007-09-19 15:53:39

One last question Mikael,

I've created the server certificates using the following commands:

#openssl req -new -x509 -keyout asterisk.key -out asterisk.crt -days 3650
#cp asterisk.crt ca-certificates.crt

unfortunately I get a segmentation fault when I start Asterisk. Is Mikey only working with Pre-shared secret?

Thank you

By: Klaus (kla960) 2007-10-02 10:06:35

I'm trying the latest patch with Fritz!box fon 7170 and Phoner an Softphone. Both can handle SRTP via sdp_crypto. I always get the following error. Why???

Executing [1235@default:1] Set("SIP/1236-0a0c0530", "_SIPSRTP=optional") in new stack
   -- Executing [1235@default:2] Set("SIP/1236-0a0c0530", "_SIPSRTP_CRYPTO=enable") in new stack
   -- Executing [1235@default:3] Dial("SIP/1236-0a0c0530", "SIP/1235,20") in new stack
 == Using TOS bits 0
 == Using CoS mark 5
[Oct  2 16:43:54] NOTICE[4219]: chan_sip.c:3554 sip_call: SIPSRTP_CRYPTO
[Oct  2 16:43:54] NOTICE[4219]: chan_sip.c:3541 sip_call: SIPSRTP
   -- Called 1235
   -- SIP/1235-0a0c6258 is ringing
   -- SIP/1235-0a0c6258 is ringing
--- set_address_from_contact host '156.150.133.150'
[Oct  2 16:43:55] WARNING[4219]: sdp_crypto.c:161 sdp_crypto_activate: Could not set remote SRTP policy
--- set_address_from_contact host '156.150.133.150'
   -- SIP/1235-0a0c6258 answered SIP/1236-0a0c0530
[Oct  2 16:43:56] NOTICE[4219]: rtp.c:3923 ast_rtp_bridge: Cannot native bridge in SRTP.
[Oct  2 16:43:56] WARNING[4219]: rtp.c:1331 ast_rtcp_read: RTCP Read too short
[Oct  2 16:43:56] WARNING[4219]: rtp.c:1624 ast_rtp_read: RTP Read error: Success.  Hanging up.
 == Spawn extension (default, 1235, 3) exited non-zero on 'SIP/1236-0a0c0530'

By: mikma (mikma) 2007-10-02 14:20:04

kla960 I have downloaded an tried PhonerLite 1.37, and I can't reproduce the error you get. I'm seeing "RTCP Read too short" warnings, maybe because PhonerLite doesn't encrypt RTCP, but it doesn't seem to affect the RTP bridge.

By: mikma (mikma) 2007-10-02 14:53:53

student, it's currently possible to receive calls with MIKEY using any mode supported by minisip: Pre-shared (PSK), DH, DH-HMAC, or RSA-R. All outgoing MIKEY calls in Asterisk use PSK.

By: Klaus (kla960) 2007-10-04 04:08:30

I don't think what the rtcp is the problem, because before that warning arrives you get the following message
sdp_crypto.c:161 sdp_crypto_activate: Could not set remote SRTP policy

By: Zuo-Ren, Liou (oarpvfpre) 2007-12-12 04:18:39.000-0600

Hi there,

I have successfully compiled SVN-trunk-r81432M with ast_srtp_r81432_mikey_r3412.patch and connected two minisip. A secure call to the number 01 or the echo test works nice. When I try to make a secure call between the two phones, Asterisk show a message "Cannot native bridge in SRTP".

I have try to set "canreinvite=no" in sip.conf, but it still doesn't work, what is the next step to enable secure calls between two phones?

--------------------------------------
configuration in sip.conf
--------------------------------------
[isec_01]
type=friend
username=isec_01
secret=isec
host=dynamic
context=tutorial
canreinvite=no
nat=no

--------------------------------------
configuration in extensions.conf
--------------------------------------
[tutorial]
exten => 01, 1, Set(_SIP_SRTP_SDES=1)
exten => 01, n, Set(_SIPSRTP=optional)
exten => 01, n, Set(_SIPSRTP_CRYPTO=enable)
exten => 01, n, Dial(SIP/isec_01)

--------------------------------------
message in Asterisk CLI
--------------------------------------
[Dec 12 17:50:04] NOTICE[2562]: sdp_mikey.c:112 sdp_mikey_setup: Using MIKEY PSK isec
   -- Executing [01@tutorial:1] Set("SIP/isec_02-08374fc0", "_SIP_SRTP_SDES=1") in new stack
   -- Executing [01@tutorial:2] Set("SIP/isec_02-08374fc0", "_SIPSRTP=optional") in new stack
   -- Executing [01@tutorial:3] Set("SIP/isec_02-08374fc0", "_SIPSRTP_CRYPTO=enable") in new stack
   -- Executing [01@tutorial:4] Dial("SIP/isec_02-08374fc0", "SIP/isec_01") in new stack
 == Using TOS bits 0
 == Using CoS mark 5
[Dec 12 17:50:04] NOTICE[2562]: chan_sip.c:3554 sip_call: SIPSRTP_CRYPTO
[Dec 12 17:50:04] NOTICE[2562]: chan_sip.c:3541 sip_call: SIPSRTP
   -- Called isec_01
   -- SIP/isec_01-0837e730 is ringing
--- set_address_from_contact host '140.125.84.30'
   -- SIP/isec_01-0837e730 answered SIP/isec_02-08374fc0
[Dec 12 17:50:08] NOTICE[2562]: rtp.c:3924 ast_rtp_bridge: Cannot native bridge in SRTP.

By: Andreas Anderson (aanderson) 2008-01-23 05:01:47.000-0600

*BUMP*

As SIPS was just merged into trunk this is getting really interesting. Is there an updated patch?

By: Xianglin Deng (xianglin) 2008-02-17 23:49:55.000-0600

Hi there,
  I am doing a research project on SRTP, with Asterisk and Minisip softphone. I followed the installation instruction at http://www.voip-info.org/wiki/view/Asterisk+SRTP

however, when I make phone calls, SRTP seems not working, as the media is still carried out by RTP.

Could anyone please let me know how to "enabloe" SRTP?
I will  really appreciate your help.
Thank you very much.

By: Jeff Peeler (jpeeler) 2008-02-20 16:23:42.000-0600

What versions of the required dependencies were used for this? The stable branch is missing libmcrypto and trunk doesn't compile.

By: Jeff Peeler (jpeeler) 2008-02-25 14:46:32.000-0600

Emailed developer directly at address listed on minisip.org.

By: Jeff Peeler (jpeeler) 2008-03-03 10:54:43.000-0600

Emailed mikma at his mantis registered address.

By: Jean-Michel BESNARD (jmbesnard) 2008-03-07 03:38:50.000-0600

I have followed the instructions at http://www.voip-info.org/wiki/view/Asterisk+SRTP and am now able to get the media over SRTP.

My problem is that the asterisk version used in the documentation does not support TLS.
Would it be possible to provide a new patch for the latest asterisk versions (1.6 that actually supports TLS) ?

Thanks

By: Jeff Peeler (jpeeler) 2008-03-11 10:17:57

jmbesnard, try testing using the branch here:
https://origsvn.digium.com/svn/asterisk/team/jpeeler/srtp

This branch is based off of trunk and I'm still working on it. You'll probably need to run autoreconf to update the configuration files.



By: dlu (dlu) 2008-03-18 06:39:24

Can anyone make a patch for an actual asterisk-release? So we can test it without running in other bugs?

Tkanks

By: Donny Kavanagh (donnyk) 2008-03-18 10:08:22

http://svn.digium.com/svn/asterisk/team/jpeeler/srtp/

Would be a better link, most people will not have origsvn access.

By: Jean-Michel BESNARD (jmbesnard) 2008-03-20 09:12:19

I have done a checkout on both

svn.digium.com/svn/asterisk/team/jpeeler/srtp/

and

svn.minisip.org/minisip/trunk minisip-trunk

My 2 SIP/TLS clients can register and, after about one minute, asterisk segfaults.....

1- should I be using a particular release on the svn repositories for asterisk and minisip ?
2- what traces would you require to find out what my problem is ?

By: Jeff Peeler (jpeeler) 2008-03-24 12:20:22

No particular versions need to be checked out. I was using trunk from both projects.

It would be helpful for you to compile with DONT OPTIMIZE turned on and then post a backtrace from gdb, perhaps even a "thread apply all bt". Which crypto options are you using in the dialplan (_SIPSRTP_MIKEY or _SIPSRTP_CRYPTO) ? What phones are you using for testing?

By: Jean-Michel BESNARD (jmbesnard) 2008-03-25 04:01:45

I have compiled asterisk with the DONT_OPTIMIZE flag. No core file has been dumped after asterisk crashed (again) though.

All I've got is:

*CLI> *** glibc detected *** asterisk: double free or corruption (!prev): 0x08238c30 ***
======= Backtrace: =========
/lib/i686/cmov/libc.so.6[0xb7c6e915]
/lib/i686/cmov/libc.so.6(cfree+0x90)[0xb7c72380]
/extra/srtp/lib/asterisk/modules/chan_sip.so[0xb6a4d63c]
asterisk(ast_io_wait+0x14b)[0x80c78da]
/extra/srtp/lib/asterisk/modules/chan_sip.so[0xb6a4eb71]
asterisk[0x812c617]
/lib/i686/cmov/libpthread.so.0[0xb7bec4fb]
/lib/i686/cmov/libc.so.6(clone+0x5e)[0xb7cd993e]
======= Memory map: ========
08048000-08190000 r-xp 00000000 08:04 32711      /extra/srtp/sbin/asterisk
08190000-0819d000 rw-p 00147000 08:04 32711      /extra/srtp/sbin/asterisk
0819d000-08290000 rw-p 0819d000 00:00 0          [heap]
b68dd000-b68de000 ---p b68dd000 00:00 0
b68de000-b6919000 rw-p b68de000 00:00 0
b6919000-b691c000 r-xp 00000000 08:04 32918      /extra/srtp/lib/asterisk/modules/codec_g726.so
b691c000-b691d000 rw-p 00002000 08:04 32918      /extra/srtp/lib/asterisk/modules/codec_g726.so
b691d000-b691f000 r-xp 00000000 08:04 32990      /extra/srtp/lib/asterisk/modules/res_realtime.so
b691f000-b6920000 rw-p 00001000 08:04 32990      /extra/srtp/lib/asterisk/modules/res_realtime.so
b6920000-b6922000 r-xp 00000000 08:04 32891      /extra/srtp/lib/asterisk/modules/app_readfile.so
b6922000-b6923000 rw-p 00001000 08:04 32891      /extra/srtp/lib/asterisk/modules/app_readfile.so
b6923000-b6925000 r-xp 00000000 08:04 32982      /extra/srtp/lib/asterisk/modules/res_convert.so
b6925000-b6926000 rw-p 00001000 08:04 32982      /extra/srtp/lib/asterisk/modules/res_convert.so
b6926000-b6937000 r-xp 00000000 08:04 32862      /extra/srtp/lib/asterisk/modules/app_dial.so
b6937000-b6938000 rw-p 00010000 08:04 32862      /extra/srtp/lib/asterisk/modules/app_dial.so
b6938000-b693b000 r-xp 00000000 08:04 32890      /extra/srtp/lib/asterisk/modules/app_readexten.so
b693b000-b693c000 rw-p 00002000 08:04 32890      /extra/srtp/lib/asterisk/modules/app_readexten.so
b693c000-b6940000 r-xp 00000000 08:04 32854      /extra/srtp/lib/asterisk/modules/app_amd.so
b6940000-b6941000 rw-p 00003000 08:04 32854      /extra/srtp/lib/asterisk/modules/app_amd.so
b6941000-b6946000 r-xp 00000000 08:04 32870      /extra/srtp/lib/asterisk/modules/app_externalivr.so
b6946000-b6947000 rw-p 00004000 08:04 32870      /extra/srtp/lib/asterisk/modules/app_externalivr.so
b6947000-b6948000 ---p b6947000 00:00 0
b6948000-b6983000 rw-p b6948000 00:00 0
b6983000-b6984000 ---p b6983000 00:00 0
b6984000-b69bf000 rw-p b6984000 00:00 0
b69bf000-b69c0000 ---p b69bf000 00:00 0
b69c0000-b69fb000 rw-p b69c0000 00:00 0
b69fb000-b6a75000 r-xp 00000000 08:04 32843      /extra/srtp/lib/asterisk/modules/chan_sip.so
b6a75000-b6a78000 rw-p 00079000 08:04 32843      /extra/srtp/lib/asterisk/modules/chan_sip.so
b6a78000-b6a88000 rw-p b6a78000 00:00 0
b6a88000-b6a89000 ---p b6a88000 00:00 0
b6a89000-b6ac4000 rw-p b6a89000 00:00 0
b6ac4000-b6ac5000 ---p b6ac4000 00:00 0
b6ac5000-b6b21000 rw-p b6ac5000 00:00 0
b6b21000-b6c00000 ---p b6b21000 00:00 0
b6c00000-b6c01000 r-xp 00000000 08:04 32873      /extra/srtp/lib/asterisk/modules/app_forkcdr.so
b6c01000-b6c02000 rw-p 00001000 08:04 32873      /extra/srtp/lib/asterisk/modules/app_forkcdr.so
b6c02000-b6c05000 r-xp 00000000 08:04 32927      /extra/srtp/lib/asterisk/modules/format_gsm.so
b6c05000-b6c06000 rw-p 00003000 08:04 32927      /extra/srtp/lib/asterisk/modules/format_gsm.so
b6c06000-b6c07000 r-xp 00000000 08:04 32876      /extra/srtp/lib/asterisk/modules/app_image.so
b6c07000-b6c08000 rw-p 00000000 08:04 32876      /extra/srtp/lib/asterisk/modules/app_image.so
b6c08000-b6c0c000 r-xp 00000000 08:04 32917      /extra/srtp/lib/asterisk/modules/codec_g722.so
b6c0c000-b6c0d000 rw-p 00004000 08:04 32917      /extra/srtp/lib/asterisk/modules/codec_g722.so
b6c0d000-b6c0f000 r-xp 00000000 08:04 32946      /extra/srtp/lib/asterisk/modules/func_cdr.so
b6c0f000-b6c10000 rw-p 00001000 08:04 32946      /extra/srtp/lib/asterisk/modules/func_cdr.so
b6c10000-b6c12000 r-xp 00000000 08:04 32924      /extra/srtp/lib/asterisk/modules/format_g723.so
b6c12000-b6c13000 rw-p 00001000 08:04 32924      /extra/srtp/lib/asterisk/modules/format_g723.so
b6c13000-b6c15000 r-xp 00000000 08:04 32861      /extra/srtp/lib/asterisk/modules/app_db.so
b6c15000-b6c16000 rw-p 00001000 08:04 32861      /extra/srtp/lib/asterisk/modules/app_db.so
b6c16000-b6c18000 r-xp 00000000 08:04 32905      /extra/srtp/lib/asterisk/modules/app_url.so
b6c18000-b6c19000 rw-p 00001000 08:04 32905      /extra/srtp/lib/asterisk/modules/app_url.so
b6c1Aborted (core dumped)

By: Jean-Michel BESNARD (jmbesnard) 2008-03-25 04:09:39

I have compiled asterisk with the DONT_OPTIMIZE flag. No core file has been dumped after asterisk crashed (again) though.

All I've got is:

*CLI> *** glibc detected *** asterisk: double free or corruption (!prev): 0x08238c30 ***
======= Backtrace: =========
/lib/i686/cmov/libc.so.6[0xb7c6e915]
/lib/i686/cmov/libc.so.6(cfree+0x90)[0xb7c72380]
/extra/srtp/lib/asterisk/modules/chan_sip.so[0xb6a4d63c]
asterisk(ast_io_wait+0x14b)[0x80c78da]
/extra/srtp/lib/asterisk/modules/chan_sip.so[0xb6a4eb71]
asterisk[0x812c617]
/lib/i686/cmov/libpthread.so.0[0xb7bec4fb]
/lib/i686/cmov/libc.so.6(clone+0x5e)[0xb7cd993e]
======= Memory map: ========
08048000-08190000 r-xp 00000000 08:04 32711      /extra/srtp/sbin/asterisk
08190000-0819d000 rw-p 00147000 08:04 32711      /extra/srtp/sbin/asterisk
0819d000-08290000 rw-p 0819d000 00:00 0          [heap]
b68dd000-b68de000 ---p b68dd000 00:00 0
b68de000-b6919000 rw-p b68de000 00:00 0
b6919000-b691c000 r-xp 00000000 08:04 32918      /extra/srtp/lib/asterisk/modules/codec_g726.so
b691c000-b691d000 rw-p 00002000 08:04 32918      /extra/srtp/lib/asterisk/modules/codec_g726.so
b691d000-b691f000 r-xp 00000000 08:04 32990      /extra/srtp/lib/asterisk/modules/res_realtime.so
b691f000-b6920000 rw-p 00001000 08:04 32990      /extra/srtp/lib/asterisk/modules/res_realtime.so
b6920000-b6922000 r-xp 00000000 08:04 32891      /extra/srtp/lib/asterisk/modules/app_readfile.so
b6922000-b6923000 rw-p 00001000 08:04 32891      /extra/srtp/lib/asterisk/modules/app_readfile.so
b6923000-b6925000 r-xp 00000000 08:04 32982      /extra/srtp/lib/asterisk/modules/res_convert.so
b6925000-b6926000 rw-p 00001000 08:04 32982      /extra/srtp/lib/asterisk/modules/res_convert.so
b6926000-b6937000 r-xp 00000000 08:04 32862      /extra/srtp/lib/asterisk/modules/app_dial.so
b6937000-b6938000 rw-p 00010000 08:04 32862      /extra/srtp/lib/asterisk/modules/app_dial.so
b6938000-b693b000 r-xp 00000000 08:04 32890      /extra/srtp/lib/asterisk/modules/app_readexten.so
b693b000-b693c000 rw-p 00002000 08:04 32890      /extra/srtp/lib/asterisk/modules/app_readexten.so
b693c000-b6940000 r-xp 00000000 08:04 32854      /extra/srtp/lib/asterisk/modules/app_amd.so
b6940000-b6941000 rw-p 00003000 08:04 32854      /extra/srtp/lib/asterisk/modules/app_amd.so
b6941000-b6946000 r-xp 00000000 08:04 32870      /extra/srtp/lib/asterisk/modules/app_externalivr.so
b6946000-b6947000 rw-p 00004000 08:04 32870      /extra/srtp/lib/asterisk/modules/app_externalivr.so
b6947000-b6948000 ---p b6947000 00:00 0
b6948000-b6983000 rw-p b6948000 00:00 0
b6983000-b6984000 ---p b6983000 00:00 0
b6984000-b69bf000 rw-p b6984000 00:00 0
b69bf000-b69c0000 ---p b69bf000 00:00 0
b69c0000-b69fb000 rw-p b69c0000 00:00 0
b69fb000-b6a75000 r-xp 00000000 08:04 32843      /extra/srtp/lib/asterisk/modules/chan_sip.so
b6a75000-b6a78000 rw-p 00079000 08:04 32843      /extra/srtp/lib/asterisk/modules/chan_sip.so
b6a78000-b6a88000 rw-p b6a78000 00:00 0
b6a88000-b6a89000 ---p b6a88000 00:00 0
b6a89000-b6ac4000 rw-p b6a89000 00:00 0
b6ac4000-b6ac5000 ---p b6ac4000 00:00 0
b6ac5000-b6b21000 rw-p b6ac5000 00:00 0
b6b21000-b6c00000 ---p b6b21000 00:00 0
b6c00000-b6c01000 r-xp 00000000 08:04 32873      /extra/srtp/lib/asterisk/modules/app_forkcdr.so
b6c01000-b6c02000 rw-p 00001000 08:04 32873      /extra/srtp/lib/asterisk/modules/app_forkcdr.so
b6c02000-b6c05000 r-xp 00000000 08:04 32927      /extra/srtp/lib/asterisk/modules/format_gsm.so
b6c05000-b6c06000 rw-p 00003000 08:04 32927      /extra/srtp/lib/asterisk/modules/format_gsm.so
b6c06000-b6c07000 r-xp 00000000 08:04 32876      /extra/srtp/lib/asterisk/modules/app_image.so
b6c07000-b6c08000 rw-p 00000000 08:04 32876      /extra/srtp/lib/asterisk/modules/app_image.so
b6c08000-b6c0c000 r-xp 00000000 08:04 32917      /extra/srtp/lib/asterisk/modules/codec_g722.so
b6c0c000-b6c0d000 rw-p 00004000 08:04 32917      /extra/srtp/lib/asterisk/modules/codec_g722.so
b6c0d000-b6c0f000 r-xp 00000000 08:04 32946      /extra/srtp/lib/asterisk/modules/func_cdr.so
b6c0f000-b6c10000 rw-p 00001000 08:04 32946      /extra/srtp/lib/asterisk/modules/func_cdr.so
b6c10000-b6c12000 r-xp 00000000 08:04 32924      /extra/srtp/lib/asterisk/modules/format_g723.so
b6c12000-b6c13000 rw-p 00001000 08:04 32924      /extra/srtp/lib/asterisk/modules/format_g723.so
b6c13000-b6c15000 r-xp 00000000 08:04 32861      /extra/srtp/lib/asterisk/modules/app_db.so
b6c15000-b6c16000 rw-p 00001000 08:04 32861      /extra/srtp/lib/asterisk/modules/app_db.so
b6c16000-b6c18000 r-xp 00000000 08:04 32905      /extra/srtp/lib/asterisk/modules/app_url.so
b6c18000-b6c19000 rw-p 00001000 08:04 32905      /extra/srtp/lib/asterisk/modules/app_url.so
b6c1Aborted (core dumped)

By: Alberto Sagredo (albersag) 2008-03-28 05:01:38

I have been trying to compile LIBSRTP + MINISIP 3412 + Asterisk trunk 81432 as commented before.

But i always get on asterisk cli when trying to load res_mikey.so

[Mar 28 01:08:38] WARNING[29973]: loader.c:360 load_dynamic_module:
Error loading module 'res_mikey.so': /usr/lib/libmcrypto.so.0:
undefined symbol: _ZN12StreamSocket5writeESs
[Mar 28 01:08:38] WARNING[29973]: loader.c:634 load_resource: Module
'res_mikey.so' could not be loaded.
albersag*CLI>

I have tried several clean compilations and always same problem

Any idea?

Thanks in advance



By: Raj Jain (rjain) 2008-04-13 09:34:28

All, I tested the following branch:
http://svn.digium.com/svn/asterisk/team/jpeeler/srtp/

against SNOM 360 as well as Grandstream phones using SDES for SRTP key exchange. I'm not hearing any voice. The SIP/SDP signaling looks fine and I see SRTP packets flowing back and forth. I'm doing a simple 1-party call with Asterisk doing a playback.

What could I be missing? What kind of a debug/trace information would be helpful? Help?

By: Terry Wilson (twilson) 2008-05-28 10:46:07

I've started take a look at this--I just keep running into other things that need done.  My goodness it is a large patch.  And with lots of comments like:
/* FIXME */
That don't say what needs to be fixed. I'll see what I can do.



By: Olle Johansson (oej) 2008-07-01 10:02:19

Terry, what's the status here? Still occupied with other issues?

By: Terry Wilson (twilson) 2008-07-01 13:30:23

oej: unfortunately, yes--and it looks like it will be that way for the foreseeable future.  :-(

By: saghul (saghul) 2008-08-08 01:32:05

I can confirm what rjain says, doing a simple test with a Snom360 and Asterisk just doing playback, I can't hear any audio... What trace do you need? or, how can I debug this? Thanks!

By: Y Chen (solitario) 2008-09-02 03:21:40

Hi

I had finished building and installing libSRTP, and was trying to proceed with patching my Asterisk PBX with "ast_srtp_depend.patch". However, I met with some errors, stated below:

# patch -p0 < ast_srtp_depend.patch
patching file build_tools/menuselect-deps.in
Hunk #1 FAILED at 28.
1 out of 1 hunk FAILED -- saving rejects to file build_tools/menuselect-deps.in.rej
patching file res/res_srtp.c
Hunk #1 FAILED at 29.
1 out of 1 hunk FAILED -- saving rejects to file res/res_srtp.c.rej


Does anyone know how I can resolve this? Please provide me with some guidance. Thanks.

By: Michel Belleau (malaiwah) 2008-10-18 08:11:55

Tested using http://svn.digium.com/svn/asterisk/team/jpeeler/srtp/ (most up-to-date branch for srtp that I found). I builded it on Ubuntu 8.04 LTS 32-bits.

root@buildbox:/usr/src/asterisk-srtp# dpkg -l | grep libsrtp
ii  libsrtp1-dev                      1.4.4~dfsg-1                Secure RTP (SRTP) and UST Reference Implemen

I did not try the res_mikey component as I do not think Grandstream devices are using it.
I had to include "srtp/srtp_priv.h" header file in "res/res_srtp.c" to make it compile properly (was missing symbols when compiling).
The "ast_srtp_depend" patch was not needed to compile properly.

I'm using the demo extensions.conf file from the samples, I only added a friend ip sip.conf and changed externip parameters because this testing server is on a private nat.

Using a GXP2000 firmware 1.1.6.16, SRTP forced in the device configuration, codec PCMU. All I get is garbage sound.
Using the same GXP device, SRTP disabled, codec PCMU worked as it should.
I will attach some captures that I made during testing (asterisk console at core verbose 99, gzipped tcpdump).

I tried forcing the GSM codec, but now there is only silence when forcing SRTP on the Grandstream device. Reverting back to disabling SRTP makes it work correctly.

I guess the garbled sound could be a side-effect of this warning.

[Oct 18 13:08:36] WARNING[23522]: sdp_crypto.c:161 sdp_crypto_activate: Could not set remote SRTP policy

But I don't know how to fix it.

By: umberto amorevoli (umberto71) 2008-11-24 10:57:29.000-0600

Tested using http://svn.digium.com/svn/asterisk/team/jpeeler/srtp/ . I builded it on fedora core 7. I build also minisip latest revision before. I enable SRTP:
sip.conf
[400]
type=peer
host=dynamic
secret=
context=tutorial
mailbox=400@default
canreinvite=no
nat=no

[401]
type=peer
host=dynamic
secret=
context=tutorial
mailbox=401@default
canreinvite=no
nat=no
extension.conf
[tutorial]
exten => 400, 1, Set(_SIP_SRTP_SDES=1)
exten => 400, n, Set(_SIPSRTP=require)
exten => 400, n, Set(_SIPSRTP_CRYPTO=enable)
exten => 400, n, Dial(SIP/400)

[tutorial]
exten => 401, 1, Set(_SIP_SRTP_SDES=1)
exten => 401, n, Set(_SIPSRTP=require)
exten => 401, n, Set(_SIPSRTP_CRYPTO=enable)
exten => 401, n, Dial(SIP/401)
Result no Audio: [Nov 24 17:26:20] NOTICE[8990]: rtp.c:4017 ast_rtp_bridge: Cannot native bridge in SRTP.

If i disable SRTP in one phone Audio is Half Duplex. (SNOM 300, AASTRA57, ...)
Does anyone know how I can resolve this? I'm doing something wrong ?

By: Andreas Anderson (aanderson) 2008-12-16 14:39:14.000-0600

*BUMP* (sorry)

I would like to test SRTP, but not with an eight month old branch

Last Changed Date: 2008-04-21 19:14:53 +0200 (Mon, 21 Apr 2008)

Is there a way where i can diff a branch against trunk (of the same version) to create a patch, from which i could try to apply it on 1.6?

Is this bug gonna get some love, or is security no longer important ;-)?

By: Terry Wilson (twilson) 2008-12-16 23:39:27.000-0600

Just for fun I went ahead and updated the SRTP branch to parity with trunk.

The old SRTP branch had gotten so far out of sync with trunk that it seemed like svnmerge just wasn't able to handle the merge...it pretended to, but missed all kinds of things.  So, I took the diff against trunk at the last successful merge, checked out trunk, and applied the diff.  Then svn update, fix conflicts, svn add new files and made some changes to actually get it to compile under dev mode.

I have not done any testing other than it compiles and loads.  Also to note is the the libsrtp1-dev package in 64-bit Ubuntu creates a static library that is not compiled with -fPIC, so building it from source and manually adding -fPIC to CFLAGS was necessary.

The new branch is located at http://svn.digium.com/svn/asterisk/team/group/srtp

By: Terry Wilson (twilson) 2008-12-17 17:12:44.000-0600

Ok, there were some calls to sendto() in main/rtp.c that needed to be changed to the helper function rtp_sendto() which actually does the check for whether or not asterisk should try to encrypt outbound audio.  Before the change, asterisk would receive the encrypted audio but not encrypt the outgoing stream.  On my polycom, anyay, this resulted in no audio.  Revision 165396 has the fix.

Anyone else still hanging on to test this stuff?

By: Raj Jain (rjain) 2008-12-18 04:55:33.000-0600

I tested this around 6 months back with mixed results. I can test this again.

By: Michel Belleau (malaiwah) 2008-12-18 09:02:13.000-0600

I could test it out again later this week at home; I had mixed results a few months ago and gave up because the version was not up-to-date. Having it based on trunk is a good thing imho so more people will want to try it.

By: umberto amorevoli (umberto71) 2008-12-18 15:02:42.000-0600

I've done a working patch for asterisk 1.6.0.1. release
I've tested with Snom, Astra Grandstream real phones and snom softphone and phonerlite. Audio works in full duplex, music on hold, transfer, conference work fine. (only with _SIPSRTP_CRYPTO )
I've merged Jpeeler trunk. I don't know if I can post this patch here, please send me some info .

By: Leif Madsen (lmadsen) 2008-12-18 15:25:10.000-0600

umberto71: you could post it here, however, that patch would never be merged into Asterisk as new features will not go into an existing release.

My recommendation would be to use the current branch in order to facilitate not having to track down issues that would have been previously fixed in addition to the testing of the secure RTP patch.

By: Terry Wilson (twilson) 2008-12-18 15:28:50.000-0600

umberto71: The first thing that you would need to do is get a disclaimer on file with Digium.  The 1.6.0.1 patch wouldn't be posted here as all "new features" are made against the trunk branch.  I have jpeelers branch merged up to date with trunk located at http://svn.digium.com/svn/asterisk/team/group/srtp.  Does your version have additional changes?  If so, after getting a disclaimer on file with Digium, if you could post the patches relative to the srtp branch, that would be great!  Thanks.



By: umberto amorevoli (umberto71) 2008-12-19 01:38:27.000-0600

Many thanks.I just fixed some issues in rtp.c (of JPEELER old branch)
1) void ast_rtp_new_source(struct ast_rtp *rtp)
{
rtp->set_marker_bit = 1;
//rtp->ssrc = ast_random();  <----- (As in 1.6.0.1 and new trunk)
return;
}
2)Change sendto into rtp_sendto...
3)Fixed Add_line in chan_sip.c (sometimes invite packet is cut .. but in 1.6.0.1 there isn't this problem)
I've got a look at  http://svn.digium.com/svn/asterisk/team/group/srtp. I think this issues are fixed. I'will try it next week.

By: Terry Wilson (twilson) 2008-12-19 16:59:13.000-0600

Ok, I've gone through and cleaned up most of the code to make it conform to coding guidelines, make it use the ast_ memory allocation functions, etc.  What I haven't really touched is res/mikey.cc.  So here are my questions: 1) Has anyone tested the MIKEY code lately?  2) Do any phones actually support MIKEY 3) Since asterisk has TCP/TLS support now, do we even want to support MIKEY?

I ask because the code in res/mikey.cc is full of debugging code that writes to stdout/stderr, the MIKEY stuff in general depends on a bunch of libraries that aren't actually packaged by distros from what I can tell, and I haven't seen any actual phones that support it and therefore haven't tested it myself.  My initial inclination is to just remove the support if nothing/no one uses it.

Anyone have any thoughts/feelings on the subject?

By: Andreas Anderson (aanderson) 2008-12-22 06:56:51.000-0600

Wow, that was fast, a lot faster than i expected, many thanks :-D

Anyway, my2cents(tm):

>1) Has anyone tested the MIKEY code lately?

Sadly, no, i dont have any phone that support's it.

>2) Do any phones actually support MIKEY

No idea, but...

>3) Since asterisk has TCP/TLS support now, do we even want to support MIKEY?

Even if currently not much support for it (i guess that would be the henn-egg-problem), i belive it would be bad to drop it at this point, i can imagine a lot of scenarios where SIPS/TCP would not be possible (uncooperative corporate-firewall admin, "noooo, it worked for years with UDP!" ;-)).

So, if i really get a vote, please leave it there, even if it is not well tested, it could be deactivated in the default config.

I've used this branch for a few day's now (maybe two dozens of calls, without srtp!), i'd say it could go intro trunk without breaking anything...

By: frank koster (notthematrix) 2008-12-22 07:08:16.000-0600

I did play a bit with it yesterday.
I have a grandstream HT-503 and I Foreced SRTP so it would only work if SRTP worked at asterisk this in combination with TLS.
And could call out.
do echo test.
but when I tryed to call in via external sip peer or called from extention to extention localy It crached with a seg fault.
calling out over sip peer voipbuster woked as expected sip between asterisk and ht-503 worked coectly.
but Iam not sure it had to do with the srtp code because it also crahed whitout srtp active.
a workble pachh make for 1.6.1-beta3 or beta4 would be a nice because Beta3 works corectly with tls enabled.
so I could test that with my grandstream ht-503 firmware 10.0.15



By: Leif Madsen (lmadsen) 2008-12-22 10:30:28.000-0600

You can use minisip softphone for MIKEY support

http://www.minisip.org/

Edit: I meant for this msg to be directed to otherwiseguy. After talking to file on IRC, it seems he may have meant, "in the real world" that he was asking if anyone actually uses MIKEY in the real world.



By: Terry Wilson (twilson) 2008-12-22 11:13:51.000-0600

notthematrix: If you could post the gdb output of a doing a 'bt' and a 'bt full' from a build of the branch with DONT_OPTIMIZE enabled, that would help me track down the crash you are experiencing.  Unfortunately, there won't ever be a patch for 1.6.1 made since SRTP would be going into a future 1.6.x release when it is ready.  All patches for new features are only made off of trunk.  Now, if some enterprising soul wants to make it available, that is great.  I just won't have time to work on it.

aanderson: kpfleming has talked to snom, coutnerpath, and polycom and they all said that they don't plan on supporting mikey.  Also, when he was at the SIPit conference (where everyone goes to test interoperability of their SIP phones), everyone he talked to told them that they were going with using sdescriptions and didn't plan on using mikey.  I'm guessing that any phone developer that is interested in implementing a security layer has easy access to TCP/TLS libraries and not many options for MIKEY.  Also, I guess that they are more interested in also encrypting the signalling...and once you do that, there is no need for MIKEY.

blitzrage: :-p

By: Leif Madsen (lmadsen) 2008-12-22 11:41:32.000-0600

otherwiseguy: so does this mean we simply remove MIKEY support then, and not bother with the effort of developing and maintaining something none of the major phone manufacturers will be supporting?

By: Terry Wilson (twilson) 2008-12-22 11:54:16.000-0600

blitzrage: that is the question.  :-)  My impulse is to remove it.  If for some reason there ever was a vendor that supported MIKEY, we would still have the code in svn history and could try to fix it when we actually had something to test with (besides the one implementation of minisip--which is where the mikey libraries actually come from).

But, the main thing is that I would like to get this code in soon, and w/ the lack of testing options for the MIKEY stuff, and the fact that the code isn't currently ready, then it could take a while.  There is no way that we are going to put in untested, possibly broken code into the tree. (on purpose!)  So, it boils down into how soon we would like to get SRTP into the main codebase.

By: Andreas Anderson (aanderson) 2008-12-22 11:56:43.000-0600

otherwiseguy: I guess it's a question of how you ask the question, if you're asking, "do you want MIKEY", then the answer (obviously) is: Yesplease.

If you ask, "do you want MIKEY and wait for another four years or dump it and srtp will be trunk'd now", then the answer will probably be no.

As i said, i think it's the Henn-Egg-Problem: 'course noon supports MIKEY if there is no support in asterisk. It would be kinda sad if, after more than 3 years with this patch including MIKEY, it would be droped.

i'd bet, if it would be included in trunk people *will* be willing to support mikey in their products. And choice is allways a good thing ;-)

my 0cents... (sorry, lehmanbrother got the rest... ;-))

By: Leif Madsen (lmadsen) 2008-12-22 12:06:44.000-0600

While I want to agree with aanderson that Asterisk is indeed influential enough to cause hardware manufacturers to start supporting something that Asterisk supports, I'm going to mostly disagree with that. I think in the case of dealing with security issues though, it is much better for us to be on the side of what the community/manufacturers are already supporting and what they plan on supporting in the near future.

As otherwiseguy mentions, the existing code will continue to exist in SVN trunk, and we can even continue to work on it separately outside of the rest of SRTP if we deem it beneficial to get MIKEY support into Asterisk.

Since this issue has been open for so long, I'd prefer to break out the MIKEY support into a separate issue from the rest of the code, and get what we have into Asterisk (since it all seems so close), and move this forward.

Plus, it seems the features that MIKEY provides us is actually able to be performed without MIKEY. Not all good ideas make it all the way to full adoption, and it may be the case that MIKEY is one of those that just doesn't make it.

By: Terry Wilson (twilson) 2008-12-22 12:19:20.000-0600

Yeah, if asterisk support was the problem, no phones would have SRTP at all now.  :-)  If Asterisk *only* supported MIKEY, then it might make a difference to them.  But as blitzrage mentioned, if they have another path to get the features that MIKEY provides, then I doubt they spend their limited resources on multiple technologies that do the same thing.

But yeah, what I'm really asking is, "Can we merge the sdescriptions stuff w/o MIKEY, since they are better tested and MIKEY isn't required to work with *any* devices in the field now?"  We can leave the code for MIKEY up in a branch somewhere and if someone gets around to showing it some love (and find at least two implementations to test against) it can get merged some day as well.  I just don't want to hold this up any longer than we have to, if noone knows of anything that supports it, anyway.

By: Leif Madsen (lmadsen) 2008-12-22 12:21:52.000-0600

+1 from me

By: Andreas Anderson (aanderson) 2008-12-22 12:39:29.000-0600

+1 from metoo, put sdescriptions into trunk now (or somwhere in the near future) and leave mikey in a branch sound's like a good idea ;-)

(The only question IMHO will arise at some point, what are the service provider going to do...? Afaik SIP/TLS+TCP uses a lot more resources than SIP/UDP+MIKEY...? But lets cross that bridge when/if we get to it)

By: John Laur (gork) 2008-12-22 13:02:02.000-0600

Speaking as another of the nameless bug followers around here, it's fairly evident that the SRTP feature and the Bug 8824 Remote Party feature have some EXTREMELY significant user demand. I have personally been following both issues going on 4 years now. Both issues have the common problem of being relatively complicated patch sets due to the way they twiddle with internals.

In situations like this there are always going to be problematic edge cases, but the fact remains that without getting the issue into trunk, these kinds of problems will just continue to come up occasionally as a report to an out of date branch that has languished and/or broken by automerge problems.

I'm not so sure what my opinion matters, but I will cast a vote for ANYTHING that will get these kind of issues merged at this point, no matter how absurd the consequence. As an extreme example, I would be happy to see SRTP merged at this point even if it ONLY supported MIKEY, simply because even though it would be largely useless, it would pave the way for additional support instead of leaving the whole patch lumbering along with no hope.

Things like SRTP and Called Party Identification are no longer novelty features in SIP software; they are widely implemented and expected offerings. While Asterisk probably doesn't have enough to actually *drive* vendors implementations of these things, getting the features integrated means that at least Asterisk gets its own 'vote' when vendors go to implement them in their software and firmwares.

By: frank koster (notthematrix) 2008-12-22 14:29:29.000-0600

tls/srtp will be the standard in my opinion.
the reason that udp was used in early ages was by the limitation of tcp sockets in unix/linux.
in 2008 computers espeasialy server have servral gig of memory and mutiple procesors a socket in linux 2.6 takes around 4k http://www.ibm.com/developerworks/linux/library/l-hisock.html
if you have a memory of 4 MB it is a problem but routers theese days even have more memory.
and most PC can under linux have 8GB or more so The recources limitaion of tcp was more valide in the 1995-2000's
and I agree a lot of poeple want to have it implamented because TLS whitout SRTP is like walking on one left shoe and leaving the right one at home ;)

@otherwiseguy
Later tonight I wil try to get a bt from gdb.

By: frank koster (notthematrix) 2008-12-22 16:21:48.000-0600

here the requested debug info!

[Thread 0x40991950 (LWP 20555) exited]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x418b4950 (LWP 20550)]
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000000000453bf8 in ?? ()
#2  0x0000000002540c30 in ?? ()
#3  0x7fffffff02540c30 in ?? ()
#4  0x0000000002540c30 in ?? ()
ASTERISK-1  0x000000000251cc80 in ?? ()
ASTERISK-2  0x000000000253ce00 in ?? ()
ASTERISK-3  0x0000000002533ab0 in ?? ()
ASTERISK-4  0x00000000418a4b80 in ?? ()
ASTERISK-5  0x00007f267d8f29d8 in dial_exec_full (chan=0x7f2690c65cbb, data=0x5790a4, peerflags=0x5790a2, continue_exec=0x418a3880) at app_dial.c:1754
Backtrace stopped: frame did not save the PC
(gdb) bt full
#0  0x0000000000000000 in ?? ()
No symbol table info available.
#1  0x0000000000453bf8 in ?? ()
No symbol table info available.
#2  0x0000000002540c30 in ?? ()
No symbol table info available.
#3  0x7fffffff02540c30 in ?? ()
No symbol table info available.
#4  0x0000000002540c30 in ?? ()
No symbol table info available.
ASTERISK-1  0x000000000251cc80 in ?? ()
No symbol table info available.
ASTERISK-2  0x000000000253ce00 in ?? ()
No symbol table info available.
ASTERISK-3  0x0000000002533ab0 in ?? ()
No symbol table info available.
ASTERISK-4  0x00000000418a4b80 in ?? ()
No symbol table info available.
ASTERISK-5  0x00007f267d8f29d8 in dial_exec_full (chan=0x7f2690c65cbb, data=0x5790a4, peerflags=0x5790a2, continue_exec=0x418a3880) at app_dial.c:1754
tmp = (struct chanlist *) 0x2538250
interface = 0x418a34f0 "?5\212A"
tech = 0x1 <Address 0x1 out of bounds>
tc = (struct ast_channel *) 0x7f2691787040
number = 0x460e79 "H\213E?H\211E?H\213E???UH\211?H\203?\020H\211}?H\203}
di = (struct ast_dialed_interface *) 0x56234c
callee_features = (struct ast_dial_features *) 0x2f418a34e0
dialed_interfaces = (struct {...} *) 0x562357
res = 32550
rest = 0x2540e68 ""
cur = 0x7f267b030d0c "SIPCALLID"
outgoing = (struct chanlist *) 0x7f267b030b5c
peer = (struct ast_channel *) 0x7b0c70
to = 2063386692
num = {chan = 0x5790a1, busy = 5738617, congestion = 0, nochan = 0}
cause = 0
numsubst = " <\212A\004\000\000\000\000??\220&\177\000\000?<\212A\000\000\000\000'\000\000\000\000\000\000\000@?\001\000\000\000\000\000\000??\220&\177\000\000?<\212A\000\000\000\000(\000\000\000\000\000\000\000@?\001\000\000\000\000\000?\025T\002\000\000\000\000\000??\220&\177\000\000O??\220&\177\000\000\000??\220&\177\000\0002?Q\002\000\000\000\000?<\212A\000\000\000\000\000?\003\000\000\000\000\000@px\221&\177\000\000PI\213A\000\000\000\000\200c\001A\000\000\000\000Y?Q\000\000\000\000\000\200c\001A\000\000\000\000Y?Q\000\000\000\000\000?<\212A\000\000\000\000\020TV\000\000\000\000\000\020TV\000\000\000\000\000"...
cidname = "?!P\002\000\000\000\000\000?S\002", '\0' <repeats 12 times>, " b+\215&\177\000\000?!P\002\000\000\000\000\000?S\002\000\000\000\000P=\212A\000\000\000\000?;E\000\000\000\000\0000\fT\002\000\000\000\0000\fT\002???\177"
config = {features_caller = {flags = 5709190}, features_callee = {flags = 0}, start_time = {tv_sec = 5703151, tv_usec = 0},
 feature_timer = 1099576904, timelimit = 124554051585, play_warning = 0, warning_freq = 1099577320, warning_sound = 0x418a3808 "",
 end_sound = 0x418a37b0 "??Q\002", start_sound = 0x418a3800 "", firstpass = 0, flags = 0, end_bridge_callback = 0, end_bridge_callback_data = 0x0,
 end_bridge_callback_data_fixup = 0x418a31df}
calldurationlimit = {tv_sec = 1099575968, tv_usec = 0}
---Type <return> to continue, or q <return> to quit---
dtmfcalled = 0x418a35a0 "\200?%{&\177"
dtmfcalling = 0x51f546 "H\211E?H\203}
pa = {sentringing = 39042274, privdb_val = 0,
 privcid = "\000\000\000\000\000\000\000\000d\v\003{&\177\000\000?;\212A\000\000\000\000\000\220S\002&\177\000\000\200c\001A\000\000\000\000@?S\002\000\000\000\000\032\021?\220&\177\000\0000\fT\002\000\000\000\000?|${&\177\000\000@?S\002\000\000\000\000@?S\002\000\000\000\000?5\212A\000\000\000\000n?S\002\001\000\000\000\030\000\000\0000\000\000\000P:\212A\000\000\000\000\2209\212A\000\000\000\000?;\212A", '\0' <repeats 12 times>, "\b\220S\002\000\000\000\000\030\000\000\0000\000\000\000\200:\212A\000\000\000\000?9\212A\000\000\000\000\020G?\002\000\000\000\000\006\000\000\000\000\000\000\000\024\000\000\000\000\000\000\000xz"...,
 privintro = "?\035J\220&\177\000\000\000\000\000\000\000\000\000\000X\fG\002\000\000\000\000\000?v\221&\177\000\000P7\212A\000\000\000\000?:\212A\000\000\000\000?:\212A\000\000\000\000?:\212A\000\000\000\000P7\212A\000\000\000\000G\000\000\000\000\000\000\000\2007\212A\000\000\000\000;?Q\002\000\000\000\000??Q\002\000\000\000\000;?Q\002\000\000\000\000\2007\212A\000\000\000\000l\000\000\000\000\000\000\000\0209\212A\000\000\000\000?\005W\000\000\000\000\000\200c\001A\000\000\000\000;?Q\002\000\000\000\000\032\021?\220&\177\000\000\001\200??\000\000\000\000;?Q\002\000\000\000\000;?Q\002\000\000\000\000;?Q\002\000\000\000\000"...,
 status = "\030`@", '\0' <repeats 22 times>, "Px\221&\177\000\000\017?\216}&\177\000\0008\017A\000\000\000\000\000\030\232\216}&\177\000\000\000\000\000\000\005\000\000\000?\005\000\000\001\000\000\000-\000\000\000\000\000\000\000()E\002\000\000\000\000?<\212A\000\000\000\000}\220\f?\000\000\000\000p<\212A", '\0' <repeats 12 times>, "\210<\212A\000\000\000\000\236\"W\221&\177", '\0' <repeats 18 times>, "\005", '\0' <repeats 15 times>, "P\000\000\000\000\000\000\000?;\212A\000\000\000\000`\000\000\000\000\000\000\000?;\212A\000\000\000\000(\000\000\000\000\000\000\000?;\212A\003\000\000\000,\000\000\000\000\000\000\000()E"...}
sentringing = 1099577728
moh = 32550
outbound_group = 0x418a35b0 "\2009\212A"
result = 2063387576
parse = 0x0
opermode = 0
args = {argc = 0, argv = 0x418a31f8, peers = 0x418a33f8 "\220?Q\002", timeout = 0x3000000018 <Address 0x3000000018 out of bounds>,
 options = 0xd1 <Address 0xd1 out of bounds>, url = 0x0}
opts = {flags = 139803626074176}
opt_args = {0x418a3120 "\206\035W", 0x418a3360 "\001", 0x730000d1 <Address 0x730000d1 out of bounds>, 0x418a3a10 "",
 0x579070 "Channel: %s\r\nVariable: %s\r\nValue: %s\r\nUniqueid: %s\r\n", 0x5705ed "\r\n", 0x0, 0x418a33f8 "\220?Q\002",
 0xe418a32d0 <Address 0xe418a32d0 out of bounds>, 0xfffffff40051fee2 <Address 0xfffffff40051fee2 out of bounds>, 0x51fe7e "H\211\225\030???H\215\2050????"}
datastore = (struct ast_datastore *) 0x2540c30
ds_caller_features = (struct ast_datastore *) 0x7f267b030d0c
ds_callee_features = (struct ast_datastore *) 0x253bd40
caller_features = (struct ast_dial_features *) 0x2533651
fulldial = 1099577728
num_dialed = 0
__PRETTY_FUNCTION__ = "dial_exec_full"
Backtrace stopped: frame did not save the PC
(gdb)

By: Joshua C. Colp (jcolp) 2008-12-22 16:42:19.000-0600

The backtrace shows an issue that was fixed this morning involving app_macro. If you update you should no longer see it.

By: frank koster (notthematrix) 2008-12-22 17:25:06.000-0600

oke i download the patch with wget 'http://bugs.digium.com/file_download.php?file_id=21060&type=bug' -O - | patch -p0 to patch it my self :)

but it was not instaled in the srtp svn when i did a update

the problem seem to be solved now busy testing setting up dailplan
for incomming calls.
are there alray some options to activate srtp in sip.conf?
because we have phone's that do and dont support srtp?
an option if not yet implamented yet might be something like
if device friend/user is using TLS then automacily activate srtp on that divice.
or maby  make a extra transport= option like transport=TLS+SRTP
just a sugestion from a intrested user.
.



By: frank koster (notthematrix) 2008-12-22 18:56:17.000-0600

dit the followibng in my dialplan

added following lines in my freepbx dialplan
exten => 103,n,Set(_SIP_SRTP_SDES=1)
exten => 103,n,Set(_SIPSRTP=optional)
exten => 103,n,Set(_SIPSRTP_CRYPTO=enable)

it worked if I set the device the ht-503 on forced srtp
when set to enebled it works too bu when set to disabled it fails
wondering if there is any $variable in asterisk were you can check if a
certan divice is registerd with TLS if so enable srtp.
for now I might put it in the dialplan it might also be an option to put in srtp.c self but thats not my peace of cake.

test result SRTP and TLS asterisk SVN-group-srtp-r166392M with
patch 21060 is funtioning properly.
wth grandstream HT-503 firmware 10.0.15
hope you guys can implement one of my sugestions to make live easyer :)

By: Terry Wilson (twilson) 2008-12-22 23:01:22.000-0600

notthematrix: the SIP_SRTP_SDES variable doesn't actually exist anymore.  Currently, it looks like that for the caller's leg of the call asterisk will encrypt that leg of the call no matter what if it offers encryption.  The variables currently only control what happens w/ the outgoing leg of the call.  So if you have two phones and call from one to the other, if the caller supports SRTP it will be encrypted.  If you have SIPSRTP_CRYPTO=disable set, then the leg between asterisk and the callee will not be encrypted.  Currently there isn't anything available which would allow the call to be rejected if both legs are not capable of encryption.

There is currently a bug where even if the dialplan specifies optional, Asterisk will send a a=crypto line, but in a normal RTP/AVP (instead of RTP/SAVP) offer which makes my polycom reject the call if it is set not to accept SRTP calls.  Fixing that is easy enough, but I agree a lot of the dialplan variable / setting stuff needs to be reworked.  I'll try to get it all hammered out into something more useable tomorrow.

By: frank koster (notthematrix) 2008-12-23 07:19:30.000-0600

perfect looking forward to it ;)
please inform me when you got somethig new posted.

By: Terry Wilson (twilson) 2008-12-24 12:58:29.000-0600

Ok, for now I am removing the SIPSRTP=optional setting as there is no standard way to provisionally offer SRTP that I can find.  The way that were were doing it was the way that snom supports, but it causes the Polycom to choke.  Instead, what I now have is a sip.conf peer option srtpenable=yes|no and have added the ability to check this option with the SIPPEER() dialplan function.  Now, if the value of SIPSRTP evaluates to false, then encryption will not be offered, otherwise it will.  Also gone is the SIPSRTP_CRYPTO dialplan variable since 1) We don't have MIKEY support here right now and 2) If we did, I think it would be better to just signal whether or not you want to encrypt via the dialplan and leave the choice of how to encrypt to a sip.conf variable.

An quick/short example of how to offer SRTP only to devices that are capable would be something like:

[default]
exten => _600X,1,Set(_SIPSRTP=${SIPPEER(${EXTEN},srtpcapable)})
exten => _600X,n,Dial(SIP/${EXTEN})


notthematrix (and eveyone else for that matter): Does that sound ok to you?

By: frank koster (notthematrix) 2008-12-25 07:35:25.000-0600

Oke First merry Christmas ;)
ok i will test it :)



By: frank koster (notthematrix) 2008-12-25 13:31:04.000-0600

oke i TRYED srtpenable=yes

but it did not enable srtp for some reason.
my ata is set to accept srtp only calls but when tho call was picked up it refused it because for some reason it did not see srtpenable=yes
maby it can only do peers now not friends?
the solution with srtpenable=yes is good becouse it can be easaly patched in to a setup system as freepbx or others.

this is my sip config....

sip_additional.conf

[31251788103]
type=friend
secret=xxxxxxx
qualify=yes
port=5060
pickupgroup=
nat=yes
mailbox=31251788103@device
host=dynamic
dtmfmode=rfc2833
dial=SIP/31251788103
context=klant-31-123-123456
canreinvite=no
callgroup=
callerid=device <31251788103>
accountcode=
call-limit=50

sip_custom_post.conf

[31251788103](+)
transport=tls
srtpenable=yes

By: frank koster (notthematrix) 2008-12-25 18:21:12.000-0600

svn checkout http://svn.digium.com/svn/asterisk/team/group/srtp  srtp

Fetching external item into 'srtp/menuselect'
@otherwiseguy

Fetching external item into 'srtp/menuselect/mxml'
Checked out external at revision 123.

Checked out revision 446.
Checked out revision 166771.

Path: srtp
URL: http://svn.digium.com/svn/asterisk/team/group/srtp
Repository Root: http://svn.digium.com/svn/asterisk
Repository UUID: f38db490-d61c-443f-a65b-d21fe96a405b
Revision: 166771
Node Kind: directory
Last Changed Author: twilson
Last Changed Rev: 166768
Last Changed Date: 2008-12-24 19:56:49 +0100 (Wed, 24 Dec 2008)

Path: srtp
URL: http://svn.digium.com/svn/asterisk/team/group/srtp
Repository Root: http://svn.digium.com/svn/asterisk
Repository UUID: f38db490-d61c-443f-a65b-d21fe96a405b
Revision: 166771
Node Kind: directory
Schedule: normal
Last Changed Author: twilson
Last Changed Rev: 166768
Last Changed Date: 2008-12-24 19:56:49 +0100 (Wed, 24 Dec 2008)



Fri Dec 26 01:17:31 CET 2008


I did a little research on why srtpenable=yes maby did not work.

Strangly I can not find any srtpenable like string anny of the source file in directory channels.
Is there a chance that tere is a delay between when I can download it with svn and you post it?
the changes look promising if srtpenable=yes does act correctly as set in my example config file it would definatly solve most problems ;)
Annyway merry chrismas!



By: frank koster (notthematrix) 2008-12-29 09:28:12.000-0600

anny news here?
Made the (old) version woreble by letting it check in /SIP/Registry/
with a gotoif statement if the entry in /SIP/Registry/ exists then dont use crypto if it does not activate crypto for the device since TLS has always SRTP on if you take TLS serously :)
in case of iax device it simply wil not care about the crypto setting.
this is for me a workable solution for now the extra commando's as rtpenable=yes are welcome ofcourse but did not get it to work yet.

By: Terry Wilson (twilson) 2008-12-31 13:07:46.000-0600

Sorry, srtpcapable=yes|no, not srtpenable!

By: frank koster (notthematrix) 2009-01-01 18:05:46.000-0600

Oke can happen I will check on it later ,
happy newyear!

By: Terry Wilson (twilson) 2009-01-08 19:28:16.000-0600

I have a post on asterisk-dev (copy available at http://lists.digium.com/pipermail/asterisk-dev/2009-January/036029.html) that lists some additions that I have made and have some example dialplans.  If some of you watching this ticket (that happen to be subscribed to asterisk-dev) could let me know what you think, I'd appreciate it.

The short version is that I've added the ability for Dial with the "execute macro for callee" option M() to allow you to play warnings/notifications just before the two legs of a call are bridged.  Combine that with using ${CHANNEL(secure_signalling)} and ${CHANNEL(secure_media)} you can control how you handle calls where only portions of the call may be encrypted, etc.  A short example from the email:

In this case, we will potentially have only one side of the  
conversation encrypted, but everyone who supports encryption will have  
their leg encrypted.  If you would like to let everyone know the  
status of the encryption across both legs of the call, you could do  
the following:

__extensions.conf__
[default]
exten => _600X,1,NoOp(Everyone that supports encryption will have it!)
exten => _600X,n,Set(_SIPSRTP=${SIPPEER(${EXTEN},srtpcapable)})
exten => _600X,n,Gosub(set-secure,s,1)
exten => _600X,n,Dial(${${EXTEN}_tech}/${EXTEN},,M(check-secure^$
{secure}))
exten => _600X,n,Hangup

[macro-check-secure]
exten => s,1,NoOp(Checking for secure signalling and media)
exten => s,n,Gosub(set-secure,s,1)
exten => s,n,Set(announce=${IF($[${secure} & ${ARG1}]?channel-
secure:channel-insecure-warn)})
exten => s,n,Set(MACRO_RESULT=PLAY_BOTH:${announce})

[set-secure]
exten => s,1,Set(secure=$[${CHANNEL(secure_signalling)} & $
{CHANNEL(secure_media)}])
exten => s,n,Return

Here, we define secure as a call that has both secure signalling and  
secure media.  In SIP, this would mean both the transport being TLS  
and the media being encrypted with SRTP.  For IAX, this would be both  
Asterisk and the IAX phone (or other Asterisk box) having negotiated  
encryption.

Anyway, let me know what you think and feel free to get some conversation going on the asterisk-dev mailing list.  People by and large seem to ignore the SRTP posts I make there.  It would be nice to see some actual discussion.

By: phsultan (phsultan) 2009-01-09 05:14:46.000-0600

Hi Terry,

I had tested the SRTP branch right before the changes you just brought to the code. I had it working with Eyebeam (1.5.18.2 on Mac), Aastra 55i (2.1.2.30) and SNOM 360 (6.5.15).

However, I had to revert a change you made to have the SNOM phone work, as well as the Aastra (when configured to place SRTP calls when possible). In both cases, when placing calls from those phones to Asterisk, the SDP packets contain an unsecured RTP profile, plus a crypto offer :
m=audio 5062 RTP/AVP 0 8
[...]
a=crypto:1 [...]

And we furtherly fall into this code section, so the call is refused :
if (!secure_audio && p->srtp) {
 ast_log(LOG_WARNING, "We are requesting SRTP, but they responded without it!\n");
 return -2;
}

Don't you think we should accept those packets, and consider them as a request to place a call with SRTP? From your previous notes, it looks like Polycom phones don't like those messages, so maybe we can have Asterisk change the RTP profile to RTP/SAVP before relaying the SIP requests.

The use case I was asked to work on by the customer is to not have the calls encrypted by default, and to prefix the dialed number with * if the caller wants to protect the call. This makes SRTP optional and proposed by default on the phones.

Thanks for the hard work you're putting on that, I think we now have a good dialplan control on how to process SRTP calls.

PS: maybe we should advertise SRTP in _sip_show_peers too.

By: frank koster (notthematrix) 2009-01-09 06:34:09.000-0600

why should calls not be encrypted by default?
If the device supports it use encryption.
a other way to support it might be using the USERAGENT if it was possible to make a settings DB based on the user agent , you could set the auth en encrytion type in the flaver of the phones you support.
but personaly I think that enforced encryption is the best way if you want security.
we use ht-503 boxes and ht-502 and have srtp enforced,
this solves the problem with unwanted clear lines
if no encryption the call will fail.
so making a list with phones that support encryption based on user agent is a good option you have to make that list your self offcource.
but if you switch phones on the same account/peer this could be a working way to set srtp. but again I dont see the use of TLS whitout SRTP.....

By: Terry Wilson (twilson) 2009-01-09 09:39:08.000-0600

pshultan: Asterisk should be encrypting those calls if there is an SAVP profile. It sounds like they are using the "Send RTP/AVP but add a crypto line" method (which is totally not valid according to the specs, but I digress).  I meant to remove asterisk *sending* calls that way, but didn't mean to remove accepting calls that way.  I will try to get it to go back to encrypting calls with an optional SRTP specified this way.

notthematrix: I'm not maintaining a useragent db.  Of course, all the information is available to the user to be able to maintain there own if they want, I just think that there are easier ways for most circumstances.  My job is to make enough information available to the user to let them do whatever they want.  :-)  That is what the srtpcapable flag is for in sip.conf, the administrator knows which phones support encryption and need it enabled at least on some calls.  And on incoming calls, if their is an encryption offer, we will automatically encrypt.  It just sounds like I may have broken that for phones that don't adhere to the RFCs w/ regard to SDP/SRTP.

By: phsultan (phsultan) 2009-01-09 10:01:08.000-0600

> pshultan: Asterisk should be encrypting those calls if there is an SAVP profile.
> It sounds like they are using the "Send RTP/AVP but add a crypto line" method
> (which is totally not valid according to the specs, but I digress). I meant to
> remove asterisk *sending* calls that way, but didn't mean to remove accepting
> calls that way. I will try to get it to go back to encrypting calls with an
> optional SRTP specified this way.

This is indeed the method they chose, at least on the phones (+ versions) I tested. In my case, ignoring the 'secure_audio' parameter (set if RTP/SAVP is received) solved the problem. So I commented out this section :
if (!secure_audio && p->srtp) {
 ast_log(LOG_WARNING, "We are requesting SRTP, but they responded without it!\n");
 return -2;
}

That's a quick and dirty hack, maybe a test to see if the call is outgoing would be more relevant :
if (!secure_audio && p->srtp && p->outgoing_call == TRUE)

By: Terry Wilson (twilson) 2009-01-09 10:43:01.000-0600

pshultan: yeah, I had to add that line because one phone I tested (may have been a grandstream?) if I send  only a SRTP request, would respond with regular RTP only which we would happily accept.  We definitely shouldn't accept responses that don't match what we send.  Would doing something like this work for you?

} else if (!strncasecmp(a, "crypto:", (size_t) 7)) {
process_crypto(p, a);
+ secure_audio = 1;
+ if (!p->novideo) {
+ secure_video = 1;
+ }
continue;
} else if (!strncasecmp(a, "key-mgmt:mikey ", (size_t) 15)) {
ast_log(LOG_NOTICE, "Asterisk currently does not support MIKEY key negotiation\n");

By: Terry Wilson (twilson) 2009-01-09 11:13:41.000-0600

Actually, come to think of it, this part needs work anyway because the a=crypto lines are actually specific to the media description, not the session.  And of course asterisk doesn't actually parse things this way at all:  
/* Next, scan through each "a=xxxx:" line, noting each
    * specified RTP payload type (with corresponding MIME subtype):
    */
   /* XXX This needs to be done per media stream, since it's media stream specific */
   iterator = req->sdp_start;
   while ((a = get_sdp_iterate(&iterator, req, "a"))[0] != '\0') {

/me sighs

By: Terry Wilson (twilson) 2009-01-09 11:20:26.000-0600

So, since rewriting the SDP parser is out of scope for this, the above changes might work.

By: Terry Wilson (twilson) 2009-01-09 11:55:34.000-0600

notthematrix: also, we don't encrypt all calls just because the phone supports it because there is no standard way to offer "optional" encryption.  We will encrypt the caller's leg if encryption is offered, but we have to know whether or not to offer or not offer encryption to the callee because there is no standard way to say "encrypt this if you can" with SRTP.  Different vendors use incompatible ways to do it (and I still think it is silly...you either want a secure call, or you don't), so we just send an RTP/SAVP request or an RTP/AVP request for now until that gets sorted out by everyone.

By: frank koster (notthematrix) 2009-01-09 15:35:51.000-0600

Is tere no way to wheter to use  RTP/SAVP RTP/AVP out op the communication history of the device 2 asterisk (sip history) ?
like if you make a call from the device the asterisk will (see) what is used,
or maby just an extra option if notting else works....

By: Terry Wilson (twilson) 2009-01-09 16:31:01.000-0600

notthematrix: that just isn't the kind of decision that Asterisk should make automatically for someone.  It is certainly possible to keep that kind of list for yourself if that benefits your installation, but it isn't something that is generally useful.  It would never be coded that way in the source.  For one thing, it is possible to enable/disable SRTP support in the phones, so it would possibly be out of sync for a bit.  It would be trivial to manage yourself though, if you wanted to.

; run from a Dial with option M() so that we save the ability of the callee
[macro-set-secure]
exten => _X.,n,Set(DB(${MACRO_EXTEN}_secure)=${IF($[${CHANNEL(secure_media)}]?1:0)})

This would be a bit chattier than necessary since you'd really only need to set the DB the first time the device was called, but you could wrap it in a check first.  But the real problem is, we don't know *anything* about the call we are about to make to the callee unless it is in sip.conf.  We have to generate the invite either with, or without an encryption setting and they are mutually exclusive (for now).  So at best you could generate a list automatically, but if you don't know whether or not the phone supports encryption when you are entering it into sip.conf, then you don't need encryption on it anyway.

The *entire* problem is that there is no standards-compliant way to send a request that says "encrypt this if you can, otherwise, I don't mind if it isn't encrypted".  We can be liberal in what we accept from others, but there is no way that we can send out something that everyone will accept.  And I'm not willing to maintain multiple broken non-standard ways of achieving the goal.

It seems to me that 1) Encrypting the caller if the request contains any known method of negotiating encryption 2) Make it possible to determine whether or not the device we are about to call understands a request for encryption via SIPPEER(srtpcapable)--although I'm thinking this should be SIPPEER(encryption) now and 3) The dialplan variable for whether or not to send encrypted or not encrypted offers (both not both) should take care of most of the use cases for encryption.

The example dialplan that I made above should do opportunistic encryption as long as you have srtpcapable set in sip.conf.  Even if we made it permissive and had an option to allow RTP when we requested SRTP, most phones would just send a 488 Unacceptable Here to our request if they didn't support SRTP.

By: frank koster (notthematrix) 2009-01-09 20:33:56.000-0600

This is what my grandstream bixes send
the expect a savp header when talking crypto


<--- SIP read from TLS:98.99.11.22:2049 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 11.222.222.111:5060;branch=z9hG4bK156c3ff3;rport=5060;received=119.116.0.116
From: "0031201231234" <sip:0031201231234@11.222.222.111:5060>;tag=as1eb4d033
To: <sip:31201234321@192.168.1.108:38553;transport=tls>;tag=1091078781
Call-ID: 126c5dd4529a32973a20a05d400e65ae@11.222.222.111
CSeq: 102 INVITE
Contact: <sip:31201234321@192.168.1.108:38553;transport=tls>
Supported: replaces, path, timer
User-Agent: Grandstream HT-503  V1.1B 1.0.0.15*
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Type: application/sdp
Content-Length:   416

v=0
o=31201234321 8000 8000 IN IP4 192.168.1.108
s=SIP Call
c=IN IP4 192.168.1.108
t=0 0
m=audio 37014 RTP/SAVP 0 8 18 4 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32-36,54
a=silenceSupp:off - - - -
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:iXjPIrDcmHEJmHI4YSgquMfU/B+Ce8ObDm+jlxjC
a=fmtp:101 0-16,32-36,54
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:KK/kI8C3HrPeai+KP+TJtdGO6LjtagU6S2kUCe+x
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:/8dJ4TaZmFcNdsE8AAEgybbxV56qzFivf6MYk6wH

I changed the pulic adresees and phone numbers used in the header
but the difreces in the IP adresses are real, they differ also here but are changed to fictive valeus,

It looks like Grandstream is using and expecting SAVP
Hope this helps

By: frank koster (notthematrix) 2009-01-09 20:53:52.000-0600

this is a simple example cryted outgoing call to *69
imstresting thing is that grandstream is sending 2 crypto lines.
while asterisk is just sending 1
hope this helps


<--- SIP read from TLS:92.254.55.200:2049 --->
REGISTER sip:111.222.111.222:5060 SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:38553;branch=z9hG4bK1328680060;rport;alias
From: <sip:31201234444@111.222.111.222:5060>;tag=773952076
To: <sip:31201234444@111.222.111.222:5060>
Call-ID: 1944620384-38553-1@192.168.1.108
CSeq: 4085 REGISTER
Contact: <sip:31201234444@192.168.1.108:38553;transport=tls>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B82131B12>"
Authorization: Digest username="31201234444", realm="asterisk", nonce="5817c42f", uri="sip:111.222.111.222:5060",
response="2b32e050474413f5b293a54ef0fd90eb", algorithm=MD5
Max-Forwards: 70
User-Agent: Grandstream HT-503  V1.1B 1.0.0.15*
Supported: path
Expires: 60
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0


<------------->
--- (14 headers 0 lines) ---
Sending to 92.254.55.200 : 2049 (NAT)
mastermetals2*CLI>
<--- Transmitting (NAT) to 92.254.55.200:2049 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 192.168.1.108:38553;branch=z9hG4bK1328680060;alias;received=92.254.55.200;rport=2049
From: <sip:31201234444@111.222.111.222:5060>;tag=773952076
To: <sip:31201234444@111.222.111.222:5060>;tag=as6d37965a
Call-ID: 1944620384-38553-1@192.168.1.108
CSeq: 4085 REGISTER
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="07eb5f17"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '1944620384-38553-1@192.168.1.108' in 32000 ms (Method: REGISTER)
mastermetals2*CLI>
<--- SIP read from TLS:92.254.55.200:2049 --->
REGISTER sip:111.222.111.222:5060 SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:38553;branch=z9hG4bK341609338;rport;alias
From: <sip:31201234444@111.222.111.222:5060>;tag=773952076
To: <sip:31201234444@111.222.111.222:5060>
Call-ID: 1944620384-38553-1@192.168.1.108
CSeq: 4086 REGISTER
Contact: <sip:31201234444@192.168.1.108:38553;transport=tls>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B82131B12>"
Authorization: Digest username="31201234444", realm="asterisk", nonce="07eb5f17", uri="sip:111.222.111.222:5060",
response="53981646897112ad403fc65054e31049", algorithm=MD5
Max-Forwards: 70
User-Agent: Grandstream HT-503  V1.1B 1.0.0.15*
Supported: path
Expires: 60
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0


<------------->
--- (14 headers 0 lines) ---
Sending to 92.254.55.200 : 2049 (NAT)
Reliably Transmitting (NAT) to 92.254.55.200:2049:
OPTIONS sip:31201234444@192.168.1.108:38553;transport=tls SIP/2.0
Via: SIP/2.0/TLS 187.111.222.48:5060;branch=z9hG4bK57ef7488;rport
Max-Forwards: 70
From: "Unknown" <sip:Unknown@187.111.222.48:5060>;tag=as569d62cc
To: <sip:31201234444@192.168.1.108:38553;transport=tls>
Contact: <sip:Unknown@187.111.222.48:5060;transport=TLS>
Call-ID: 1350c93d5f862e2c6029fd233808b3e4@187.111.222.48
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Date: Sat, 10 Jan 2009 02:43:40 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Content-Length: 0


---
mastermetals2*CLI>
<--- Transmitting (NAT) to 92.254.55.200:2049 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.168.1.108:38553;branch=z9hG4bK341609338;alias;received=92.254.55.200;rport=2049
From: <sip:31201234444@111.222.111.222:5060>;tag=773952076
To: <sip:31201234444@111.222.111.222:5060>;tag=as6d37965a
Call-ID: 1944620384-38553-1@192.168.1.108
CSeq: 4086 REGISTER
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Expires: 60
Contact: <sip:31201234444@192.168.1.108:38553;transport=tls>;expires=60
Date: Sat, 10 Jan 2009 02:43:40 GMT
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '1944620384-38553-1@192.168.1.108' in 32000 ms (Method: REGISTER)
mastermetals2*CLI>
<--- SIP read from TLS:92.254.55.200:2049 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 187.111.222.48:5060;branch=z9hG4bK57ef7488;rport=5060;received=111.222.111.222
From: "Unknown" <sip:Unknown@187.111.222.48:5060>;tag=as569d62cc
To: <sip:31201234444@192.168.1.108:38553;transport=tls>;tag=1156601697
Call-ID: 1350c93d5f862e2c6029fd233808b3e4@187.111.222.48
CSeq: 102 OPTIONS
Supported: replaces, path, timer
User-Agent: Grandstream HT-503  V1.1B 1.0.0.15*
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0


<------------->
--- (10 headers 0 lines) ---
mastermetals2*CLI>
<--- SIP read from TLS:92.254.55.200:2049 --->
INVITE sip:*69@111.222.111.222:5060 SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:38553;branch=z9hG4bK1252606461;rport;alias
From: "31201234444" <sip:31201234444@111.222.111.222:5060>;tag=1698805902
To: <sip:*69@111.222.111.222:5060>
Call-ID: 2021476396-38553-39@192.168.1.108
CSeq: 380 INVITE
Contact: <sip:31201234444@192.168.1.108:38553;transport=tls>
Max-Forwards: 70
User-Agent: Grandstream HT-503  V1.1B 1.0.0.15*
Privacy: none
P-Asserted-Identity: "31201234444" <sip:31201234444@111.222.111.222:5060>
Supported: replaces, path, timer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Type: application/sdp
Accept: application/sdp, application/dtmf-relay
Content-Length:   610

v=0
o=31201234444 8000 8000 IN IP4 192.168.1.108
s=SIP Call
c=IN IP4 192.168.1.108
t=0 0
m=audio 45962 RTP/SAVP 0 8 4 18 2 97 103 102 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:103 AAL2-G726-40/8000
a=rtpmap:102 G729E/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32-36,54
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9PN7RsLNlxQ1v8PBXHt6Kmzmq2CZz8VinczDwr++
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:rLOxJ/lz9ZGIKlBL66zHZdczS4KT5FFYR+8lCrHk

<------------->
--- (16 headers 21 lines) ---
 == Using SIP RTP TOS bits 184
 == Using SIP RTP CoS mark 5
Sending to 92.254.55.200 : 2049 (NAT)
Using INVITE request as basis request - 2021476396-38553-39@192.168.1.108
Found peer '31201234444' for '31201234444' from 92.254.55.200:2049

<--- Reliably Transmitting (NAT) to 92.254.55.200:2049 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 192.168.1.108:38553;branch=z9hG4bK1252606461;alias;received=92.254.55.200;rport=2049
From: "31201234444" <sip:31201234444@111.222.111.222:5060>;tag=1698805902
To: <sip:*69@111.222.111.222:5060>;tag=as7e102d4a
Call-ID: 2021476396-38553-39@192.168.1.108
CSeq: 380 INVITE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="250842ac"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '2021476396-38553-39@192.168.1.108' in 6400 ms (Method: INVITE)
mastermetals2*CLI>
<--- SIP read from TLS:92.254.55.200:2049 --->
ACK sip:*69@111.222.111.222:5060 SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:38553;branch=z9hG4bK1252606461;rport;alias
From: "31201234444" <sip:31201234444@111.222.111.222:5060>;tag=1698805902
To: <sip:*69@111.222.111.222:5060>;tag=as7e102d4a
Call-ID: 2021476396-38553-39@192.168.1.108
CSeq: 380 ACK
Content-Length: 0


<------------->
--- (7 headers 0 lines) ---
mastermetals2*CLI>
<--- SIP read from TLS:92.254.55.200:2049 --->
INVITE sip:*69@111.222.111.222:5060 SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:38553;branch=z9hG4bK183764387;rport;alias
From: "31201234444" <sip:31201234444@111.222.111.222:5060>;tag=1698805902
To: <sip:*69@111.222.111.222:5060>
Call-ID: 2021476396-38553-39@192.168.1.108
CSeq: 381 INVITE
Contact: <sip:31201234444@192.168.1.108:38553;transport=tls>
Authorization: Digest username="31201234444", realm="asterisk", nonce="250842ac", uri="sip:*69@111.222.111.222:5060",
response="17a73c6df8187ca057f070f519caf23d", algorithm=MD5
Max-Forwards: 70
User-Agent: Grandstream HT-503  V1.1B 1.0.0.15*
Privacy: none
P-Asserted-Identity: "31201234444" <sip:31201234444@111.222.111.222:5060>
Supported: replaces, path, timer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Type: application/sdp
Accept: application/sdp, application/dtmf-relay
Content-Length:   610

v=0
o=31201234444 8000 8000 IN IP4 192.168.1.108
s=SIP Call
c=IN IP4 192.168.1.108
t=0 0
m=audio 45962 RTP/SAVP 0 8 4 18 2 97 103 102 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:103 AAL2-G726-40/8000
a=rtpmap:102 G729E/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32-36,54
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9PN7RsLNlxQ1v8PBXHt6Kmzmq2CZz8VinczDwr++
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:rLOxJ/lz9ZGIKlBL66zHZdczS4KT5FFYR+8lCrHk

<------------->
--- (17 headers 21 lines) ---
Sending to 92.254.55.200 : 2049 (NAT)
Using INVITE request as basis request - 2021476396-38553-39@192.168.1.108
Found peer '31201234444' for '31201234444' from 92.254.55.200:2049
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 4
Found RTP audio format 18
Found RTP audio format 2
Found RTP audio format 97
Found RTP audio format 103
Found RTP audio format 102
Found RTP audio format 101
Peer audio RTP is at port 192.168.1.108:45962
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Found audio description format G723 for ID 4
Found audio description format G729 for ID 18
Found audio description format G726-32 for ID 2
Found audio description format iLBC for ID 97
Found unknown media description format AAL2-G726-40 for ID 103
Found unknown media description format G729E for ID 102
Found audio description format telephone-event for ID 101
Capabilities: us - 0x110f (g723|gsm|ulaw|alaw|g729|g722), peer - audio=0xd0d (g723|ulaw|alaw|g726|g729|ilbc)/video=0x0 (nothing)/text=0x0 (nothing),
combined - 0x10d (g723|ulaw|alaw|g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 192.168.1.108:45962
Looking for *69 in klant-31-123-123456 (domain 111.222.111.222)
list_route: hop: <sip:31201234444@192.168.1.108:38553;transport=tls>

<--- Transmitting (NAT) to 92.254.55.200:2049 --->
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 192.168.1.108:38553;branch=z9hG4bK183764387;alias;received=92.254.55.200;rport=2049
From: "31201234444" <sip:31201234444@111.222.111.222:5060>;tag=1698805902
To: <sip:*69@111.222.111.222:5060>
Call-ID: 2021476396-38553-39@192.168.1.108
CSeq: 381 INVITE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:*69@187.111.222.48:5060;transport=TLS>
Content-Length: 0


<------------>
   -- Executing [*69@klant-31-123-123456:1] Goto("SIP/31201234444-71cde4c8", "from-internal,*69,1") in new stack
   -- Goto (from-internal,*69,1)
   -- Executing [*69@from-internal:1] Goto("SIP/31201234444-71cde4c8", "app-calltrace-perform,s,1") in new stack
   -- Goto (app-calltrace-perform,s,1)
   -- Executing [s@app-calltrace-perform:1] Answer("SIP/31201234444-71cde4c8", "") in new stack
Audio is at 187.111.222.48 port 19236
Adding codec 0x8 (alaw) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x100 (g729) to SDP
Adding codec 0x1 (g723) to SDP
Adding non-codec 0x1 (telephone-event) to SDP

By: frank koster (notthematrix) 2009-01-09 20:58:00.000-0600

To: <sip:*69@111.222.111.222:5060>;tag=as17e0f7b2
Call-ID: 2021476396-38553-39@192.168.1.108
CSeq: 381 INVITE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:*69@187.111.222.48:5060;transport=TLS>
Content-Type: application/sdp
Content-Length: 455

v=0
o=root 1485261276 1485261276 IN IP4 187.111.222.48
s=Asterisk PBX
c=IN IP4 187.111.222.48
t=0 0
m=audio 19236 RTP/SAVP 8 0 18 4 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:b0KfjEls63OJY3cYFyEpQHlvDeCWc+ee9ry8BDLW

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

By: frank koster (notthematrix) 2009-01-10 06:58:20.000-0600

this might help a bit

the discription here is how it is expected to work...

http://wiki.snom.com/Settings/user_savp


   * Description: This setting is effective only when RTP encryption (SRTP) is also enabled and is used to specify whether the use of the RTP/SAVP profile by the phone should be off (for backward compatibility), optional or mandatory.
         o When this setting is set to "mandatory" the phone will offer and accept only SDPs that contain m= lines with an audio profile of RTP/SAVP.
         o When this setting is set to "optional", the phone will offer SDPs containing two m= lines, one with an audio profile of RTP/SAVP the other with an audio profile of RTP/AVP and it will accept SDPs containing m= lines with either profile. The RTP/SAVP profile, being the preferred one, is listed first.
         o Since some SIP proxies cannot handle RTP/SAVP profiles or multiple m= lines this setting may also be turned off. In this case the phone will send SDPs containing RTP/AVP audio profiles only. Whether or not the crypto attribute is included depends on whether RTP encryption is on or off.
         o Note: When RTP encryption is turned off this setting has no effect.</p>

   * Valid values: <off>, <optional>, <mandatory>
   * Default value: off

By: frank koster (notthematrix) 2009-01-10 07:00:52.000-0600

so send a second line first m=RTP/SAVP then m=RTP/AVP

my gtandstream send 2 keys 1 is for highgrade encryption i think and 1 for low grade encryption old export rules...
old voip PABX systems backward compatability.

By: Terry Wilson (twilson) 2009-01-10 12:38:52.000-0600

notthematrix: you misunderstand me.  I understand how the various phone implementations work, but they are non-standard and not all compatible with each other.  Each phones method violates RFCs in one way or another and the Snom method will not work when calling a polycom, etc.  I am not going to implement flags for tracking each nonstandard way to handle this in Asterisk (i.e. snomsrtp, grandstreamsrtp, polycomsrtp, etc.).  Since there is no way to properly offer "optional encryption", I am not supporting it.

By: frank koster (notthematrix) 2009-01-11 07:28:20.000-0600

oke sorry , tryed to help here , but biside this wikipedia link I could not find mutch usable info eighter.



By: Terry Wilson (twilson) 2009-01-11 10:18:06.000-0600

No problem.  I wish everyone was as attentive to this bug.  :-)

By: frank koster (notthematrix) 2009-01-11 17:13:18.000-0600

Oke so now I gues the best way is when TLS is used atomaticly enable srtp for the device.
since I dont know any devices supporting tls and not SRTP but for completion you could leave the rtpcapable= option in , butr let it default to rtpcapable=yes when TLS is used...

By: Terry Wilson (twilson) 2009-01-11 17:20:20.000-0600

notthematrix:
Not everyone who has phones that use tls or support encryption will want to use it on any/all calls. Enabling encryption will have a fairly significant performance impact, so the idea is to let people decide for themselves what calls to allow it on.  It isn't Asterisk's job to determine what people want to do.  That is why all of the stuff with the dialplan variables, etc. were implemented (at least I assume, since I didn't originally write any of it).  I don't think we will *ever* make encryption automatic on an outbound call.  It will be determined via the dialplan and enabled by the user based on the information that is made available to the dialplan.

Is there a particular use case that you are trying to implement that isn't currently capable?  I'm having trouble understanding what it is that you are wanting done.  But, I'm a little slow sometimes.  :-)

By: frank koster (notthematrix) 2009-01-11 18:01:44.000-0600

I understand the preformance inpact problem.
But what i suggest is to default to rtpcapable=yes
when the device uses TLS to register , since 99% wants to use SRTP when TLS is used annyway.
for the ones that dont they can always set srtpcapable=no
the same options in the dailplan offcource but when default when a device registers with TLS is set to rtpcapable=YES
It wil save space in configuration files.
since only the ones who dont want srtp need to add srtpcapable=no
an other option is to make the option usesrtpwhentls= yes | no
this could then be placed in the [general] section of sip.conf for a general setting for all devices.
thinking about this the most liberal option would be "Use srtp when tls yes / no"
usesrtpwhentls= yes | no  
wil solve all needs in one setting for most poeple.
if this can be put in the [general] section of sip.conf most I think poeple would be happy.



By: phsultan (phsultan) 2009-01-12 07:34:34.000-0600

otherwiseguy: as a response to your note http://bugs.digium.com/view.php?id=5413#97314

The proposed change should indeed fix the problem encountered with SNOM and Aastra phones that under certain configuration send RTP/AVP along with a=crypto lines as SDP.

Even though I don't have any access to these phones for the moment, and therefore can't confirm that it actually works, I strongly feel like it's fine :)

Thanks!

By: frank koster (notthematrix) 2009-01-27 18:37:44.000-0600

Any news in SRTP development world?
F.E when wil it be merged in trunk?
Just intrested to see if it gets somewere ;)

By: Leif Madsen (lmadsen) 2009-01-27 21:16:31.000-0600

notthematrix:  work is progressing, and the answer to when it will be merged is, "soon"

By: nivio (nivio) 2009-02-13 10:51:06.000-0600

I tried patch asterisk 1.4.23.1 with srtp, but I had errors

patching file build_tools/menuselect-deps.in
Hunk #1 succeeded at 13 (offset 2 lines).
Hunk #2 FAILED at 32.
1 out of 2 hunks FAILED -- saving rejects to file build_tools/menuselect-deps.in.rej
patching file channels/chan_sip.c
Hunk #1 succeeded at 150 with fuzz 2 (offset 5 lines).
Hunk #2 succeeded at 217 with fuzz 2 (offset 6 lines).
Hunk #3 FAILED at 1131.
Hunk #4 succeeded at 1564 with fuzz 2 (offset -221 lines).
Hunk ASTERISK-1 succeeded at 3029 with fuzz 1 (offset -508 lines).
Hunk ASTERISK-2 FAILED at 3253.
Hunk ASTERISK-3 FAILED at 5082.
Hunk ASTERISK-4 FAILED at 5156.
Hunk ASTERISK-5 FAILED at 5185.
Hunk ASTERISK-6 succeeded at 5430 (offset -444 lines).
Hunk ASTERISK-7 succeeded at 5438 (offset -444 lines).
Hunk ASTERISK-8 succeeded at 5520 (offset -427 lines).
Hunk ASTERISK-9 succeeded at 5653 with fuzz 1 (offset -400 lines).
Hunk ASTERISK-10 FAILED at 6758.
Hunk ASTERISK-11 FAILED at 6816.
Hunk ASTERISK-12 FAILED at 6907.
Hunk ASTERISK-13 succeeded at 6902 with fuzz 2 (offset -512 lines).
Hunk ASTERISK-14 FAILED at 6921.
Hunk ASTERISK-15 succeeded at 18737 (offset -150 lines).
Hunk ASTERISK-16 FAILED at 18926.
Hunk ASTERISK-17 succeeded at 18847 with fuzz 2 (offset -373 lines).
10 out of 21 hunks FAILED -- saving rejects to file channels/chan_sip.c.rej
patching file channels/Makefile
Hunk #1 succeeded at 112 (offset 9 lines).
patching file channels/sdp_crypto.c
patching file channels/sdp_crypto.h
patching file channels/sdp_mikey.c
patching file channels/sdp_mikey.h
patching file channels/sip_srtp.c
patching file channels/sip_srtp.h
patching file configure.ac
Hunk #1 succeeded at 186 (offset -8 lines).
Hunk #2 FAILED at 210.
Hunk #3 succeeded at 1130 (offset 391 lines).
Hunk #4 succeeded at 1361 (offset 383 lines).
1 out of 4 hunks FAILED -- saving rejects to file configure.ac.rej
patching file CREDITS
Hunk #1 succeeded at 142 (offset -3 lines).
can't find file to patch at input line 1347
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -urN -x _darcs -x .svn -x '*~' upstream/include/asterisk/aes_internal.h local/include/asterisk/aes_internal.h
|--- upstream/include/asterisk/aes_internal.h 2007-06-10 10:56:24.000000000 +0200
|+++ local/include/asterisk/aes_internal.h 2007-06-10 11:07:45.000000000 +0200
--------------------------
File to patch:

By: nivio (nivio) 2009-02-13 10:52:27.000-0600

I tried patch asterisk 1.6.0.5 with srtp, but I had errors

patching file build_tools/menuselect-deps.in
Hunk #1 FAILED at 11.
Hunk #2 FAILED at 30.
2 out of 2 hunks FAILED -- saving rejects to file build_tools/menuselect-deps.in.rej
patching file channels/chan_sip.c
Hunk #1 succeeded at 177 with fuzz 2 (offset 32 lines).
Hunk #2 succeeded at 241 (offset 30 lines).
Hunk #3 FAILED at 1155.
Hunk #4 succeeded at 2069 (offset 284 lines).
Hunk ASTERISK-1 succeeded at 4266 with fuzz 1 (offset 729 lines).
Hunk ASTERISK-2 succeeded at 4517 with fuzz 1 (offset 756 lines).
Hunk ASTERISK-3 FAILED at 6346.
Hunk ASTERISK-4 FAILED at 6420.
Hunk ASTERISK-5 FAILED at 6449.
Hunk ASTERISK-6 succeeded at 6924 (offset 1050 lines).
Hunk ASTERISK-7 succeeded at 6932 (offset 1050 lines).
Hunk ASTERISK-8 succeeded at 7014 with fuzz 1 (offset 1067 lines).
Hunk ASTERISK-9 succeeded at 7131 with fuzz 1 (offset 1078 lines).
Hunk ASTERISK-10 FAILED at 8236.
Hunk ASTERISK-11 succeeded at 8386 (offset 1170 lines).
Hunk ASTERISK-12 succeeded at 8477 with fuzz 2 (offset 1170 lines).
Hunk ASTERISK-13 succeeded at 8587 (offset 1173 lines).
Hunk ASTERISK-14 FAILED at 8606.
Hunk ASTERISK-15 succeeded at 22289 (offset 3402 lines).
Hunk ASTERISK-16 succeeded at 22444 (offset 3368 lines).
Hunk ASTERISK-17 succeeded at 22630 with fuzz 2 (offset 3410 lines).
6 out of 21 hunks FAILED -- saving rejects to file channels/chan_sip.c.rej
patching file channels/Makefile
Hunk #1 succeeded at 92 (offset -11 lines).
patching file channels/sdp_crypto.c
patching file channels/sdp_crypto.h
patching file channels/sdp_mikey.c
patching file channels/sdp_mikey.h
patching file channels/sip_srtp.c
patching file channels/sip_srtp.h
patching file configure.ac
Hunk #1 FAILED at 194.
Hunk #2 succeeded at 259 with fuzz 1 (offset 41 lines).
Hunk #3 succeeded at 1506 with fuzz 1 (offset 767 lines).
Hunk #4 FAILED at 1745.
2 out of 4 hunks FAILED -- saving rejects to file configure.ac.rej
patching file CREDITS
Hunk #1 FAILED at 145.
1 out of 1 hunk FAILED -- saving rejects to file CREDITS.rej
patching file include/asterisk/aes_internal.h
patching file include/asterisk/autoconfig.h.in
Hunk #1 succeeded at 394 with fuzz 2 (offset 138 lines).
Hunk #2 succeeded at 793 with fuzz 2 (offset 291 lines).
patching file include/asterisk/mikey.h
patching file include/asterisk/rtp.h
Hunk #2 FAILED at 318.
1 out of 2 hunks FAILED -- saving rejects to file include/asterisk/rtp.h.rej
patching file main/cryptostub.c
Hunk #1 succeeded at 27 with fuzz 2 (offset -3 lines).
Hunk #2 succeeded at 68 (offset -3 lines).
patching file main/rtp.c
Hunk #1 succeeded at 89 (offset -6 lines).
Hunk #2 succeeded at 104 (offset -6 lines).
Hunk #3 FAILED at 174.
Hunk #4 succeeded at 1037 (offset 3 lines).
Hunk ASTERISK-1 succeeded at 1621 with fuzz 1 (offset 8 lines).
Hunk ASTERISK-2 succeeded at 2804 (offset 61 lines).
Hunk ASTERISK-3 succeeded at 3204 (offset 53 lines).
Hunk ASTERISK-4 FAILED at 3289.
Hunk ASTERISK-5 succeeded at 4014 (offset 95 lines).
2 out of 9 hunks FAILED -- saving rejects to file main/rtp.c.rej
patching file makeopts.in
Hunk #1 succeeded at 114 with fuzz 2 (offset 12 lines).
Hunk #2 succeeded at 195 with fuzz 2 (offset 36 lines).
patching file res/Makefile
Hunk #1 succeeded at 37 (offset 4 lines).
patching file res/mikey.cc
patching file res/mikey.h
patching file res/res_mikey.c
patching file res/res_srtp.c

By: Terry Wilson (twilson) 2009-02-13 11:12:13.000-0600

Yes, the code for srtp is found at http://svn.digium.com/svn/asterisk/team/group/srtp.  It is based off of, and kept up to date with, trunk.  There will never be a version for 1.4, 1.6.0, or 1.6.1.  1.6.2 or 1.6.3 is a possibility.

By: munny (munnymun) 2009-03-04 08:27:14.000-0600

I'mavery new to Asterisk and interested in getting SRTP work with Eyebeam. I have 1.6.0.3 installed on Fedora 10. I got both working with SIP/TLS but not with SRTP using SDES. Asterisk said 'unsupported codec type' in the debug.

I've been reading this post and googled around but not able to completely understand everything. I did install libSRTP and check out http://svn.digium.com/svn/asterisk/team/group/srtp but got error when patch -p0 < ast_srtp_depend.patch

I also saw the discussion about the 'trunk' version. I don't know what means compared to the Asterisk I installed using yum.

Could you advise how an Asterisk newbie like me could make SRTP working on my system?

Thanks!

By: frank koster (notthematrix) 2009-03-04 08:32:52.000-0600

munnymun
you can get the source using svn
svn checkout svn.digium.com/svn/asterisk/team/group/srtp  srtp



By: munny (munnymun) 2009-03-04 08:59:14.000-0600

notthematrix,
Yes that's what i did.

#svn checkout svn.digium.com/svn/asterisk/team/group/srtp

Then I..

#cd srtp
#wget "http://bugs.digium.com/file_download.php?file_id=10773&type=bug" -O ast_srtp_depend.patch
#patch -p0 < ast_srtp_depend.patch

And got this error

patching file build_tools/menuselect-deps.in
Hunk #1 FAILED at 28.
1 out of 1 hunk FAILED -- saving rejects to file build_tools/menuselect-deps.in.rej
patching file res/res_srtp.c
Hunk #1 FAILED at 29.
1 out of 1 hunk FAILED -- saving rejects to file res/res_srtp.c.rej

Then in my extensions.conf, i have..

exten => 2000,1,Set(_SIP_SRTP_SDES=1)
exten => 2000,2,Set(_SIPSRTP=enable)
exten => 2000,3,Set(_SIPSRTP_CRYPTO=enable)
exten => 2000,4,Dial(SIP/2000)

Can't make SRTP(using SDES) call.

Appreciate your help here.



By: frank koster (notthematrix) 2009-03-04 09:04:13.000-0600

well you dont need anny patch if you have this brance :)
its all in there because this is the srtp dev brance :)

By: munny (munnymun) 2009-03-04 09:15:46.000-0600

So...
#svn checkout svn.digium.com/svn/asterisk/team/group/srtp is the only thing you need to do to make Asterisk works with SRTP? Very cool!

If so, that means there is something wrong with my sip.conf or extensions.conf then.

my sip.conf

[2000]
type=friend
username=2000
secret=123456
host=dynamic
context=test
transport=tls
[2001]
type=friend
username=2001
secret=123456
host=dynamic
context=test
transport=tls

my extensions.conf

exten => 2000,1,Set(_SIP_SRTP_SDES=1)
exten => 2000,2,Set(_SIPSRTP=enable)
exten => 2000,3,Set(_SIPSRTP_CRYPTO=enable)
exten => 2000,4,Dial(SIP/2000)
exten => 2001,1,Set(_SIP_SRTP_SDES=1)
exten => 2001,2,Set(_SIPSRTP=enable)
exten => 2001,3,Set(_SIPSRTP_CRYPTO=enable)
exten => 2001,4,Dial(SIP/2001)

The two endpoints are Eyebeam 1.5. They are both registered over TLS. Could you tell what could be wrong with these two conf files that prevents Asterisk to accept SDP with SDES?

I can provide SIP trace if needed.

Thanks!

By: Jing Jiang (jjiang) 2009-03-12 13:58:47

I am trying to build libmcrypto for testing srtp, but I coouldn't directly get source code from minisip. Is minisip project still alive? If not, what should I do to make asterisk to support srtp?

By: Terry Wilson (twilson) 2009-03-12 14:24:30

libmcrypto is no longer required as we don't support mikey key exchange, instead relying on TLS for signaling encryption, and libsrtp handles the media portions.

By: Jing Jiang (jjiang) 2009-03-12 14:31:37

If so, libmutil, libmnetutil, and libmikey aren't needed either, right?

By: Terry Wilson (twilson) 2009-03-12 14:36:07

correct

By: munny (munnymun) 2009-03-12 15:59:15

has anyone successfully implemented SDES on Asterisk with Eyebeam 1.5? i've tried changing things but still got 'unsupported codec' back from Asterisk. may be it doesn't support?

By: Ognjen Palija (misk0) 2009-03-13 08:27:24

I have problem with compiling:

  [LD] res_srtp.o -> res_srtp.so
/usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/bin/ld: /usr/lib/libsrtp.a(srtp.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/lib/libsrtp.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [res_srtp.so] Error 1
make: *** [res] Error 2

Any help? ideas? I think I didn't have any problem with compiling libsrtp

By: Andreas Anderson (aanderson) 2009-04-07 06:15:48

Bump... Is 1.6.3 still the integration target for this beast?

By: deti (deti) 2009-04-07 10:50:05

Same compile problem here on 64bit Ubuntu 8.04.
Had to download libsrtp and configure it manually by using this command:

CFLAGS="-Wall -O4 -fexpensive-optimizations -funroll-loops -fPIC" ./configure

After that a normal 'make' should result in a successful build.

Before installing make sure there is no libsrtp package left from your distribution.



By: Marek Cervenka (cervajs) 2009-04-09 04:02:07

compile&testing howto updated http://www.voip-info.org/wiki/view/Asterisk+SRTP

update: added table for phones compatibility



By: Leif Madsen (lmadsen) 2009-04-09 10:26:40

I've reset this to target version for 1.6.5.0 which is probably more realistic at this point. If the situation changes that permits this to get in earlier, I will update the target accordingly.

By: Terry Wilson (twilson) 2009-04-09 10:32:11

I have the code up on reviewboard, and have addressed the issues the mmichelson found on a cursory glance.  As far as I know, the code is finished at this point.  Since there is a lot of code here, I need more reviewers before this can be merged!

By: Kristijan Vrban (kristijan) 2009-04-13 21:45:07

hello twilson, for doing real world testing with the srtp code, i search a method to use the srtp code with latest trunk. but my effort to merge the /team/group/srtp branch into latest trunk ended in a gigantic Conflict. or perhaps iam doning something wrong?

To help testing the srtp code, it would be a great convenience if you can give a instruction on howto merge the srtp code into a working copy of trunk, because the /team/group/srtp brache seems again very out of sync with trunk.

UPDATE:
ok, i found the diff from: http://reviewboard.digium.com/r/191/diff/raw/
i will try this with latest trunk



By: Terry Wilson (twilson) 2009-04-14 00:49:54

As several comments and the description have now pointed out, the code is located at https://svn.digium.com/svn/asterisk/team/group/srtp.  No merging required.

By: Silvia Menendez (uc25393) 2009-04-14 11:31:37

Hello all, I'm trying to use SRTP in Asterisk with a Twinkle phone. I've done all the steps given in http://www.voip-info.org/wiki/view/Asterisk+SRTP. I've built the SRTP library and then I've get asterisk from https://svn.digium.com/svn/asterisk/team/group/srtp and I've built it. Then I've modified my sip.conf and my extension.conf in this way

sip.conf

[9000]
type=friend
qualify=yes
secret=guessthis
nat=no
host=dynamic
canreinvite=no
context=phones
srtpcapable=yes

extension.conf

exten => 9000,1,Set(_SIP_SRTP_SDES=1)
exten => 9000,n,Set(_SIPSRTP=enable)
exten => 9000,n,Set(_SIPSRTP_CRYPTO=enable)
exten => 9000,n,Dial(SIP/9000,30,Tt)
exten => 9000,n,Hangup()

I don't know how to view if the call is encrypted or no. Asterisk don't return any message about if the call is encrypted or no.I've used the wireshark to view the frames but I can't view nothing about crypto.

Thank you in advance

By: Kristijan Vrban (vrban) 2009-04-14 12:10:14

[Kristijan wrote (by a mistake if have to accounts)]
i know that the srtp code is the team/group/srtp branch, i allready used it. but the reason i ask, is because the srtp branch is very out of sync with trunk. as an example diff any bigger app like app_queue with latest trunk to see that the srtp branch is far away from being sync with trunk. also rtp is now rtp_engine etcetera.

thats why i ask about a way to get the srtp code into a current trunk.

so i tried the srtp diff from the reviewboard with latest trunk, but many bigger failed hunks are to solve. and before i try to do it myself, i wanted to ask if there allready is any progress to get the srtp branch again in sync with trunk?



By: Marek Cervenka (cervajs) 2009-04-14 12:14:37

to: uc25393
check again http://www.voip-info.org/wiki/view/Asterisk+SRTP and try with echo application

i'm tested aastra 57i fw 2.5.0.82,udp - srtp works!
net dump looks like
15.963537 x.x.x.x -> y.y.y.y SRTP PT=ITU-T G.711 PCMA, SSRC=0x52B6274E, Seq=14198, Time=214264558
15.968667 y.y.y.y -> x.x.x.x SRTP PT=ITU-T G.711 PCMA, SSRC=0x3AAC8277, Seq=3195, Time=78560

in SDP packet ACK
sdp.media_attr == "crypto:1 AES_CM_128_HMAC_SHA1_80 inline:npMkqkz+EfTsQTIRMYs0Z1NsASvwa2NsrhzbHGXN"
sdp.media_attribute.field == "crypto"
sdp.media_attribute.value == "1 AES_CM_128_HMAC_SHA1_80 inline:npMkqkz+EfTsQTIRMYs0Z1NsASvwa2NsrhzbHGXN"

UPDATE:
grandstream GXP2020 fw 1.1.6.44 - srtp works
twinkle 1.4.2 - not working (offering zrtp, not srtp)
linksys spa-941 fw 5.1.8 - srtp/SDES not supported
Eyebeam 1.5.19.5 - srtp works



By: Terry Wilson (twilson) 2009-04-14 18:59:56

vrban: yeah, the rtp_engine commit that lately happened thoroughly broke the SRTP branch which normally automerges with trunk changes.  I've been working most of the day to resolve, but it is quite a bit of work.

By: Silvia Menendez (uc25393) 2009-04-15 05:21:48

Is there a free softphone that support srtp?? I was looking for it but I couldn't find it.

By: Klaus (kla960) 2009-04-15 07:35:55

You can try phonerlite. It supports SIP over UDP, TCP and TLS and also SRTP. At the moment I alway get an SIP 488 error if I try to make a call using srtp.

http://www.phonerlite.de/index_en.htm

By: Marek Cervenka (cervajs) 2009-04-17 06:55:27

srtp is working with three major products(tested by me) aastra,grandstream,counterpath eyebeam

please reconsider changing target back to 1.6.3.0
thanks

By: Kristijan Vrban (vrban) 2009-04-18 14:51:13

hi, i just uploaded the srtp patch based on the latest srtp source to use with 1.6.2 until the srtp branch is back in sync with trunk. and always be aware, it's just for testing.

@kla960 the PhonerLite dont write "SAVP" in the m=audio 5062 RTP/AVP 8 0 2 3 97 110 111 9 101 line in the sdp. Thats why you get the SIP 488 error

By: Andreas Anderson (aanderson) 2009-04-19 04:24:13

thanks a lot, i've tried your patch, but i think it's incomplete, ie the res_srtp.c is not created and can't be selected in menuselect...

...would be very cool, if we had a patch for a "stable version" (muahahah ;-)) chances that people will test it will rise ;-)

By: Marek Cervenka (cervajs) 2009-04-19 04:49:19

to aanderson:
do you have installed srtp library from http://srtp.sf.net ?

check howto at http://www.voip-info.org/wiki/view/Asterisk+SRTP

By: Andreas Anderson (aanderson) 2009-04-19 04:59:18

thanks, yes i have, the team-branch does work, i was trying to use vrban's patch against 1.6.2, but that patch seem's incomplete...

By: Kristijan Vrban (vrban) 2009-04-19 11:14:08

@cervajs and aanderson

yes, all new files are missing in my patch, i used svn diff without svn add before... i make a new one.

By: Kristijan Vrban (vrban) 2009-04-19 12:19:43

ok, try srtp_ast-1.6.2_v3.patch should be complete now

By: Klaus (kla960) 2009-04-21 03:50:45

@vrban the PhonerLite dont write "SAVP" in the m=audio 5062 RTP/AVP 8 0 2 3 97 110 111 9 101 line in the sdp. Thats why you get the SIP 488 error

that's of course the srtp is set allways optional in phonerlite.

By: Kristijan Vrban (vrban) 2009-04-21 05:22:25

@kla960 talking about Phoner is a bit off-topic here, but the Phoner author can make that AVP/SAVP issue optional. for example the snom phones. there you can choose to set AVP or SAVP. Iam not sure what the RFC say about this. check:
http://www.ietf.org/rfc/rfc4566.txt

By: Klaus (kla960) 2009-04-21 16:28:23

You can aktivate no SAVP in the Phonerlite beta. Now it works!!!

By: Leif Madsen (lmadsen) 2009-04-21 21:15:49

Moving back to target for 1.6.3.0, but that doesn't really mean much of anything; it'll depend when the reviews are complete, and when the developers determine this is ready to actually be merged.

By: Marek Cervenka (cervajs) 2009-04-22 16:11:28

linksys 922 firmware 6.1.5(a) works ok
settings:
SIP -> srtp method: s-descriptor
User -> secure call settings: yes

By: Kristijan Vrban (vrban) 2009-04-22 16:48:43

for any reason g_srtp_res->destroy(rtp->srtp); was missing in ast_rtp_destroy/rtp.c in the srtp branch. so i re-added it from the original srtp patch, the four years old one :) (must be by far now the oldest patch here in mantis that is open)

so i uploaded the srtp_missing_free.patch for the srtp branch and to use with my 1.6.2 srtp patch.



By: Leif Madsen (lmadsen) 2009-04-23 13:11:33

I'd like to clean up the attachments on this bug. What do we actually still need here?

By: Kristijan Vrban (vrban) 2009-04-23 14:11:59

@lmadsen
if you want to clean up some attachments, then delete the logs (txt and gz)
and the srtp_ast-1.6.2_v2.patch

please not delete:
the old original patches
srtp_ast-1.6.2_v3.patch
srtp_missing_free.patch

By: Klaus (kla960) 2009-04-30 13:14:52

I tried an aastra phone with optional enabled srtp. It's the same result as seen with the phonerlite softphone. The aastra phone don't write "SAVP" to the sdp message. So Ithink you have to add same code to handle optional srtp.

By: Terry Wilson (twilson) 2009-05-05 09:04:38

Right now the branch is out of sync with trunk after file's rtp-engine changes.  I started trying to get things fixed, but it was fairly involved and I never got it working.  I haven't had time to work on it in a while.  I'm not sure when I'll have the time to look at it again as I've got two other fairly big projects I'm working on.  I would be super-excited if someone could bring the srtp branch back up to date with trunk.

By: Jing Jiang (jjiang) 2009-05-15 11:54:32

When I did my test, I saw SRTP - with null encryption. What reason does Asterisk server to determine to use null encryption?

By: Andreas Anderson (aanderson) 2009-06-02 14:58:35

some time again... someone has some patches to sync this up with trunk, and is this still on track for 1.6.3?

By: Terry Wilson (twilson) 2009-06-02 15:16:39

I have seen no patches to sync it up yet,

By: frank koster (notthematrix) 2009-06-13 04:59:58

any news here?
when will srtp be official?
or is it dead again?

By: Andreas Anderson (aanderson) 2009-06-14 13:38:36

there where some heavy changes in the rtp stuff so this is out of sync and at the moment noone has (provided) a patch to get it back in sync, if someone can help, please do! This is (imho) one of the most important features and one of the oldest patches ever...

By: frank koster (notthematrix) 2009-06-14 17:02:13

that is very sad maby someone can provide a patch against 1.6.1?
so it can atleased be used in some way...
because this looks like dead project again :(
and a lot of poeple coding for.....

By: Terry Wilson (twilson) 2009-06-15 09:18:09

I'm not sure it is dead...I just don't have very much time to be able to work on it now.  And the rtp-engine changes means there is a bit of work to do.  This is one of those times when I really hope some community member somewhere can pick up the slack and come up with a patch that merges this up to trunk--because other than that, I'd say it is pretty much ready to go.

For an example of where to begin with the changes, look at the original rtp_engine commit and look at the changes to channel drivers and res_rtp_asterisk.c.  To get the patch, svn diff -c186078 http://svn.digium.com/svn/asterisk/trunk

By: Andreas Anderson (aanderson) 2009-06-26 03:46:41

Maybe someone who monitors this bug has missed the posting on asterisk-dev

===========================================================================

The time to get the SRTP branch merged to trunk is upon us! One of the oldest
issues in the Asterisk issue tracker (issue number 5413,
https://issues.asterisk.org/view.php?id=5413) is nearly ready to get merged to
trunk, which means it could find itself in the next major release of Asterisk,
most likely Asterisk 1.6.3.0. However, some work is still required before we
can get it merged.

Terry Wilson has, until recently, been working on the issue getting it ready to
be committed, and has performed all the updates required from the reviewboard
review (https://reviewboard.asterisk.org/r/191/) and the current code for SRTP
is sitting in a group branch
(http://svn.digium.com/svn/asterisk/team/group/srtp/).

Since Terry has been pulled away from SRTP to work on a couple of other larger
projects, he has not been able to update the SRTP branch to be in sync with
trunk after the rtp-engine commits. This is where you come in!

We're asking for help from the community to provide a patch that will get the
SRTP work brought back up to date so that it can get merged. A note from Terry
gives some information on how to get started, "For an example of where to begin
with the changes, look at the original rtp_engine commit and look at the changes
to channel drivers and res_rtp_asterisk.c. To get the patch,
svn diff -c186078 http://svn.digium.com/svn/asterisk/trunk".

Once you've got the patch ready for review, please attach it to the original
issue on the Asterisk issue tracker at
https://issues.asterisk.org/view.php?id=5413

Thanks!
Leif Madsen
Asterisk issue marshal

===========================================================================

By: Leif Madsen (lmadsen) 2009-06-29 11:31:38

I'm changing this to feedback since we need someone from the community to step up and get this branch updated to trunk per the note by aanderson (originally sent by me to the asterisk-dev mailing list).

By: Andreas Anderson (aanderson) 2009-07-21 06:59:53

Gentleman, is there any way for a non-programmer to help getting this into trunk?

There are still multiple bountys on voip-info.org open, so this would be the chance to cash in ;)

At the moment noone in the community seems to be able to update this for trunk/1.6.3, so what would it take to get someone from digium to do this?

By: Terry Wilson (twilson) 2009-07-21 07:45:55

I'm working on it.  I have things where they compile and load.  Still need to do some testing to make sure the code still actually does something before I overwrite the known working code in the srtp branch.  It is a busy time for me right now as I'm having to focus on Skype For Asterisk this week, though.

By: Terry Wilson (twilson) 2009-08-06 09:15:11

Because I'm not going to overwrite a working version of SRTP with one that doesn't work.  Also, no one in the community has been even remotely willing to do anything with the code on this bug--even after repeated requests.  I should be able to work on getting things finished up fairly soon, but have been working on Skype For Asterisk  lately and it has taken all of my time.  Now that the beta release is out and things are starting to calm down I should have some time to actually finish this up.

By: frank koster (notthematrix) 2009-09-08 17:50:54

Any news on this subject?
will there be a working patch for 1.6.2 final????
wil there be a udateted CVS?
anny news / development at all?

By: Leif Madsen (lmadsen) 2009-09-08 18:32:59

notthematrix: the status is exactly the same as it was and has been since twilson commented on what the status is.

This work will not be going into 1.6.2 -- it will only go into trunk, and thus the next branch after it has been committed to trunk.

There will not be a backport to 1.6.2 unless someone from the community steps up and decides to create a backport patch.

twilson will update the issue as soon as he has the time, or whenever someone from the community is able to step up and move this issue forward.

By: Stefan Tichy (st) 2009-09-29 13:11:50

It's an attempt to backport srtp branch to 1.6.2

Asterisk has aes_encrypt and aes_decrypt in ./main/aescrypt.c . Same function names are used in libsrtp. If HAVE_CRYPTO is set the asterisk function should not be compiled. Maybe aescrypt should include ./include/asterisk/autoconfig.h?

Have replaced Snom firmware 7.3.7 by 7.3.26. Now for each encrypted outgoing call I get:
rtp.c:1774 ast_rtp_read: RTP Read error: Success.  Hanging up.

Currently no idea. Will try to find out more.

Incoming calls seem to work without problems and outgoing calls did work before I updated the snom. Even though it might not be snoms fault.

By: frank koster (notthematrix) 2009-10-07 18:47:12

@sf
please let me know when you got a working (backport patch) for 1.6.2 so we can wait out when it will be implemented in trunk....
if you have a link to the patch I would be very happy.

By: Stefan Tichy (st) 2009-10-14 17:20:20

Currently I have a problem with my Snom 360 and this srtp branch

Snom 360 (7.3.26) tries to make a call to Asterisk (SVN-group-srtp-r183146-/trunk)

Dialplan application answer fails:

 DEBUG[9036] rtp.c: Got RTCP report of 68 bytes

 DEBUG[9036] res_srtp.c: SRTP unprotect: authentication failure

 WARNING[9036] rtp.c: RTP Read error: Success.  Hanging up.

 DEBUG[9036] channel.c: Hangup of channel SIP/snom2-08caa980 detected in answer routine


Is it necessary to hangup a call if the decryption of just one rtp paket fails? This is what is done at the moment. If I change this to ignore such pakets outgoing calls do work, but it is probably not a good idea just to ignore errors.



By: Stefan Tichy (st) 2009-10-20 12:04:15

@notthematrix

just uploaded what I have and currently use for testing. There are open issues but maybe it is of some use anyway.

By: frank koster (notthematrix) 2009-10-20 12:10:49

Hi sf
Cant find the link when I look at the patches....
might be because of the license rules?
annyway if yoy would like you can send me patches or links at notthematrix (at) .... hotmail.com
Kind regards

By: Leif Madsen (lmadsen) 2009-10-21 11:00:50

He would still get a license -- it doesn't matter what it is associated with. Signing of the license is independent of what it is being submitted for.

By: Leif Madsen (lmadsen) 2009-10-21 11:01:44

FYI, patches appear to be available for download now that the license has been accepted.

By: frank koster (notthematrix) 2009-10-21 14:01:48

@lmadsen
sorry tought it had to do with it.....
annyway its avalble now...
I use grandstream devices see if I have the same problems as sf has....
keep you guys informed...

By: frank koster (notthematrix) 2009-10-21 15:12:18

@sf
Oke tested it with my grandstream ata-50x...
when i dial out i get whitenoise on my phone... speaker
SRTP mode is FORCED....
sound from caller ----->> callee works corectley
sound from callee to caller is white noise.
it does not matter if i install the test patch the white noise stays.
dailing in accepts the call but gets noice from the called party (grandstream ht-50x)
looks leke somthing goes wrong with key exchange?
one channel does and one does not work...
looks like somthing with key exchange goes wrong?



By: Leif Madsen (lmadsen) 2009-11-09 08:27:50.000-0600

The community at large is welcome to submit the updated patch as per twilsons notes at:

https://issues.asterisk.org/view.php?id=5413#104203

and

https://issues.asterisk.org/view.php?id=5413#106398

along with my quote from the mailing list in

https://issues.asterisk.org/view.php?id=5413#107017

SRTP was not moved at all in the roadmap. Version 1.6.3 was simply renamed 1.8 as per the discussion at AstriCon and the mailing lists (see the emails regarding the new release structure by Russell Bryant). SRTP was always scheduled for the next major release, and nothing has changed here.

If the community so desperately requires SRTP functionality, they are welcome to get involved to update this current code to the latest trunk. Otherwise, it will be updated by a developer as time and resources permit.

Someone can attempt to get this backported to 1.6.2 or earlier if they wish, but there will not be any official or semi-official patches provided as new functionality does not go into existing branches, as has been the policy since 1.2.

By: John Todd (jtodd) 2009-11-11 10:48:21.000-0600

For what it's worth (little? something?) I've added the SRTP header documentation that I found in an archive here from Polycom.  I don't know if it is compatible with this method, but might be illuminating from the perspective of multi-vendor compatibility.

By: umberto amorevoli (umberto71) 2009-11-23 05:24:48.000-0600

Hi, I need to start to develope the "key lifetime" in sdp_crypto. Does anybody know a a starting point or some documents about it ?
At this time asterisk puts out this message:
ast_log(LOG_NOTICE, "Crypto life time unsupported: %s\n", attr);
..
many thanks

By: Leif Madsen (lmadsen) 2009-12-21 09:56:12.000-0600

Marking this as Confirmed. This issue will move forward as time and development resources permit. Anyone from the community who wishes to move this forward is welcome to do so. Please read the comments around here:  https://issues.asterisk.org/bug_change_status_page.php#107017 for more information on how you can move this forward. Thanks!

By: frank koster (notthematrix) 2010-02-17 17:58:30.000-0600

Is there any news on a svn synced realese of this brand by twilson?
anny indication date? anny news?

By: Terry Wilson (twilson) 2010-02-17 22:39:20.000-0600

I've got a lot of the code merged over in http://origsvn.digium.com/svn/asterisk/team/group/srtp_reboot but it is still in flux. The plan is to have everything finished before 1.8 is released.

By: frank koster (notthematrix) 2010-02-21 07:26:38.000-0600

Hi twilon
tanx for the info we are very happy the project is alive again... :)
but iam also want to tell that we found an issue with the grandstream ht-50x devices.
In the old version http://svn.digium.com/svn/asterisk/team/group/srtp
grandstream and forced SRTP worked very well.
but when we tried the new version you get white noise all the time..
Wat has changed?
We are willing to test etc see the diffrence , we also have some good contacts with the grandstream dev team.
So it must be possible to fix this and let the ht-50x SRTP work well with asterisk 1.8
If neded we have equipent like a mannaged switch etc.
hope you can fix this problem.

By: Terry Wilson (twilson) 2010-02-21 15:23:35.000-0600

Everything is still moving around a lot with the code. The dialplan functions are all different, there are no SIPSRTP channel variables, etc. So things aren't quite expected to work right now. I hope to have things settled down in the next couple of weeks.

By: Terry Wilson (twilson) 2010-03-02 19:15:08.000-0600

notthematrix: the bug that you noticed with grandstreams should be fixed in the latest srtp_reboot.

If a call comes in with an SRTP offer, it should be encrypted.

If a call is made to a peer that has "encryption=yes" in sip.conf, then the call will be offered with SRTP and fail otherwise. If it fails, the HANGUPCAUSE will be 58 (for now) and you can catch the error in the dialplan and handle it however you wish (play an error, dial a copy of the peer without encryption enabled, etc.)

You can check whether a channel has encrypted signaling with CHANNEL(secure_signaling) and CHANNEL(secure_media)

You can force any outgoing request initiated by a channel to have security features via Set(CHANNEL(secure_bridge_signaling)=1) and Set(CHANNEL(secure_bridge_media)=1) or clear the necessity by setting them to 0.

An example of one phone calling another and requesting that the call have secure signaling and media, but falling back to insecure for failure would look something like:
; Set secure signaling and media
exten => _600X,1,Set(CHANNEL(secure_bridge_signaling)=1)
exten => _600X,n,Set(CHANNEL(secure_bridge_media)=1)

; Display the settings for secure signaling and media
exten => _600X,n,NoOp(Bridge signaling: ${CHANNEL(secure_bridge_signaling)})
exten => _600X,n,NoOp(Bridge media: ${CHANNEL(secure_bridge_signaling)})

; Make the outbound dial attempt and check for encryption-related failure
exten => _600X,n,Dial(SIP/${EXTEN})
exten => _600X,n,GotoIf($["${HANGUPCAUSE}" = "58"]?encrypt_fail)
exten => _600X,n,Hangup

; Turn off the encryption requirement and redial
exten => _600X,n(encrypt_fail),Set(CHANNEL(secure_bridge_signaling)=0)
exten => _600X,n,Set(CHANNEL(secure_bridge_media)=0)
exten => _600X,n,Dial(SIP/${EXTEN})
exten => _600X,n,Hangup



By: frank koster (notthematrix) 2010-03-02 19:19:24.000-0600

@twilson
Tank you for the info!
I will check it tonight/tomorrow :)

By: frank koster (notthematrix) 2010-03-03 09:25:23.000-0600

@twilson ,here some report.
No still white noise. with SVN-group-srtp_reboot-r250289-/trunk
The grandstream ht-503 is in SRTP forced mode so it sould always request a srtp encrypted call when placing a call.
When I played with the old 1.6.2 rc3 patch I had the same problem.
channel asterisk to grandstream (speaker) was white noise and channel grandstream (mike) to asterisk worked oke.

 

we have it working properly with version SVN-group-srtp-r176603-/trunk

so tere might be something changed what is not liked.
Best regards Frank

here a working sip debug. of  SVN-group-srtp-r176603-/trunk

<--- SIP read from TLS:92.254.1.100:2050 --->
INVITE sip:*66@87.222.43.11:443;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:54261;branch=z9hG4bK1448223259;rport;alias
From: <sip:788103@87.222.43.11:443;user=phone>;tag=613547299
To: <sip:*66@87.222.43.11:443;user=phone>
Call-ID: 2074233693-54261-2@192.168.1.108
CSeq: 10 INVITE
Contact: <sip:788103@192.168.1.108:54261;transport=tls;user=phone>
Max-Forwards: 70
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Privacy: none
P-Asserted-Identity: <sip:788103@87.222.43.11:443;user=phone>
Supported: replaces, path, timer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Type: application/sdp
Accept: application/sdp, application/dtmf-relay
Content-Length:   631

v=0
o=788103 8000 8000 IN IP4 192.168.1.108
s=SIP Call
c=IN IP4 192.168.1.108
t=0 0
m=audio 44802 RTP/SAVP 0 8 4 18 2 97 102 100 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:2 G726-32/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:102 G729E/8000
a=rtpmap:100 AAL2-G726-16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32-36,54
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:jov/A+BXlrWC54k48n7UUQ5RLymQhWlWOOzWff+R
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:r40cr5D8BiayiA07wP+6lFDI5X/xdQRazDxHorpG

<------------->
--- (16 headers 22 lines) ---
 == Using SIP RTP TOS bits 184
 == Using SIP RTP CoS mark 5
Sending to 92.254.1.100 : 2050 (NAT)
Using INVITE request as basis request - 2074233693-54261-2@192.168.1.108
Found peer '788103' for '788103' from 92.254.1.100:2050
mastermetals2*CLI>
<--- Reliably Transmitting (NAT) to 92.254.1.100:2050 --->
SIP/2.0 401 Unauthorized
v: SIP/2.0/TLS 192.168.1.108:54261;branch=z9hG4bK1448223259;alias;received=92.254.1.100;rport=2050
f: <sip:788103@87.222.43.11:443;user=phone>;tag=613547299
t: <sip:*66@87.222.43.11:443;user=phone>;tag=as3801be1b
i: 2074233693-54261-2@192.168.1.108
CSeq: 10 INVITE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
k: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="027011d3"
l: 0


<------------>
Scheduling destruction of SIP dialog '2074233693-54261-2@192.168.1.108' in 128000 ms (Method: INVITE)
mastermetals2*CLI>
<--- SIP read from TLS:92.254.1.100:2050 --->
ACK sip:*66@87.222.43.11:443;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:54261;branch=z9hG4bK1448223259;rport;alias
From: <sip:788103@87.222.43.11:443;user=phone>;tag=613547299
To: <sip:*66@87.222.43.11:443;user=phone>;tag=as3801be1b
Call-ID: 2074233693-54261-2@192.168.1.108
CSeq: 10 ACK
Content-Length: 0


<------------->
--- (7 headers 0 lines) ---
mastermetals2*CLI>
<--- SIP read from TLS:92.254.1.100:2050 --->
INVITE sip:*66@87.222.43.11:443;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:54261;branch=z9hG4bK638909050;rport;alias
From: <sip:788103@87.222.43.11:443;user=phone>;tag=613547299
To: <sip:*66@87.222.43.11:443;user=phone>
Call-ID: 2074233693-54261-2@192.168.1.108
CSeq: 11 INVITE
Contact: <sip:788103@192.168.1.108:54261;transport=tls;user=phone>
Authorization: Digest username="788103", realm="asterisk", nonce="027011d3", uri="sip:*66@87.222.43.11:443;user=phone", response="fbff718527e37c840a040636d6010563", algorithm=MD5
Max-Forwards: 70
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Privacy: none
P-Asserted-Identity: <sip:788103@87.222.43.11:443;user=phone>
Supported: replaces, path, timer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Type: application/sdp
Accept: application/sdp, application/dtmf-relay
Content-Length:   631

v=0
o=788103 8000 8000 IN IP4 192.168.1.108
s=SIP Call
c=IN IP4 192.168.1.108
t=0 0
m=audio 44802 RTP/SAVP 0 8 4 18 2 97 102 100 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:2 G726-32/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:102 G729E/8000
a=rtpmap:100 AAL2-G726-16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32-36,54
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:jov/A+BXlrWC54k48n7UUQ5RLymQhWlWOOzWff+R
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:r40cr5D8BiayiA07wP+6lFDI5X/xdQRazDxHorpG

<------------->
--- (17 headers 22 lines) ---
Sending to 92.254.1.100 : 2050 (NAT)
Using INVITE request as basis request - 2074233693-54261-2@192.168.1.108
Found peer '788103' for '788103' from 92.254.1.100:2050
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 4
Found RTP audio format 18
Found RTP audio format 2
Found RTP audio format 97
Found RTP audio format 102
Found RTP audio format 100
Found RTP audio format 101
Peer audio RTP is at port 192.168.1.108:44802
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Found audio description format G723 for ID 4
Found audio description format G729 for ID 18
Found audio description format G726-32 for ID 2
Found audio description format iLBC for ID 97
Found audio description format G729E for ID 102
Found audio description format AAL2-G726-16 for ID 100
Found audio description format telephone-event for ID 101
Capabilities: us - 0x10d (g723|ulaw|alaw|g729), peer - audio=0x2d0d (g723|ulaw|alaw|g726|g729|ilbc|siren7)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x10d (g723|ulaw|alaw|g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 192.168.1.108:44802
Looking for *66 in klant-31-123-123456 (domain 87.222.43.11)
list_route: hop: <sip:788103@192.168.1.108:54261;transport=tls;user=phone>

<--- Transmitting (NAT) to 92.254.1.100:2050 --->
SIP/2.0 100 Trying
v: SIP/2.0/TLS 192.168.1.108:54261;branch=z9hG4bK638909050;alias;received=92.254.1.100;rport=2050
f: <sip:788103@87.222.43.11:443;user=phone>;tag=613547299
t: <sip:*66@87.222.43.11:443;user=phone>
i: 2074233693-54261-2@192.168.1.108
CSeq: 11 INVITE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
k: replaces, timer
m: <sip:*66@87.222.43.11:443;transport=TLS>
l: 0


<------------>
   -- Executing [*66@klant-31-123-123456:1] Goto("SIP/788103-040bd5c8", "from-internal,*66,1") in new stack
   -- Goto (from-internal,*66,1)
   -- Executing [*66@from-internal:1] Answer("SIP/788103-040bd5c8", "") in new stack
Audio is at 87.222.43.11 port 12552
Adding codec 0x8 (alaw) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x100 (g729) to SDP
Adding codec 0x1 (g723) to SDP
Adding non-codec 0x1 (telephone-event) to SDP

<--- Reliably Transmitting (NAT) to 92.254.1.100:2050 --->
SIP/2.0 200 OK
v: SIP/2.0/TLS 192.168.1.108:54261;branch=z9hG4bK638909050;alias;received=92.254.1.100;rport=2050
f: <sip:788103@87.222.43.11:443;user=phone>;tag=613547299
t: <sip:*66@87.222.43.11:443;user=phone>;tag=as20e26413
i: 2074233693-54261-2@192.168.1.108
CSeq: 11 INVITE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
k: replaces, timer
m: <sip:*66@87.222.43.11:443;transport=TLS>
c: application/sdp
l: 455

v=0
o=root 1644478234 1644478234 IN IP4 87.222.43.11
s=Asterisk PBX
c=IN IP4 87.222.43.11
t=0 0
m=audio 12552 RTP/SAVP 8 0 18 4 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:atQZFygtW/TTsGpFZFv/eX2MCnQN60FyibA+XAct

<------------>
mastermetals2*CLI>
<--- SIP read from TLS:92.254.1.100:2050 --->
ACK sip:*66@87.222.43.11:443;transport=TLS SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:54261;branch=z9hG4bK75050974;rport
From: <sip:788103@87.222.43.11:443;user=phone>;tag=613547299
To: <sip:*66@87.222.43.11:443;user=phone>;tag=as20e26413
Call-ID: 2074233693-54261-2@192.168.1.108
CSeq: 11 ACK
Contact: <sip:788103@192.168.1.108:54261;transport=tls;user=phone>
Max-Forwards: 70
Supported: replaces, path, timer
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0


<------------->
--- (12 headers 0 lines) ---
   -- Executing [*66@from-internal:2] Wait("SIP/788103-040bd5c8", "1") in new stack
   -- Executing [*66@from-internal:3] Macro("SIP/788103-040bd5c8", "user-callerid,") in new stack
   -- Executing [s@macro-user-callerid:1] Set("SIP/788103-040bd5c8", "AMPUSER=788103") in new stack
   -- Executing [s@macro-user-callerid:2] GotoIf("SIP/788103-040bd5c8", "0?report") in new stack
   -- Executing [s@macro-user-callerid:3] ExecIf("SIP/788103-040bd5c8", "1?Set(REALCALLERIDNUM=788103)") in new stack
   -- Executing [s@macro-user-callerid:4] Set("SIP/788103-040bd5c8", "AMPUSER=788103") in new stack
   -- Executing [s@macro-user-callerid:5] Set("SIP/788103-040bd5c8", "AMPUSERCIDNAME=test") in new stack
   -- Executing [s@macro-user-callerid:6] GotoIf("SIP/788103-040bd5c8", "0?report") in new stack
   -- Executing [s@macro-user-callerid:7] Set("SIP/788103-040bd5c8", "AMPUSERCID=788103") in new stack
   -- Executing [s@macro-user-callerid:8] Set("SIP/788103-040bd5c8", "CALLERID(all)="test" <788103>") in new stack
   -- Executing [s@macro-user-callerid:9] GotoIf("SIP/788103-040bd5c8", "0?continue") in new stack
   -- Executing [s@macro-user-callerid:10] Set("SIP/788103-040bd5c8", "__TTL=64") in new stack
   -- Executing [s@macro-user-callerid:11] GotoIf("SIP/788103-040bd5c8", "1?continue") in new stack
   -- Goto (macro-user-callerid,s,18)
   -- Executing [s@macro-user-callerid:18] NoOp("SIP/788103-040bd5c8", "Using CallerID "test" <788103>") in new stack
   -- Executing [*66@from-internal:4] DBdel("SIP/788103-040bd5c8", "CP/788103") in new stack
   -- DBdel: family=CP, key=788103
   -- DBdel: Error deleting key from database.
   -- Executing [*66@from-internal:5] Playback("SIP/788103-040bd5c8", "privacy-your-callerid-is&activated") in new stack
   -- <SIP/788103-040bd5c8> Playing 'privacy-your-callerid-is.alaw' (language 'en')
   -- <SIP/788103-040bd5c8> Playing 'activated.alaw' (language 'en')
   -- Executing [*66@from-internal:6] Macro("SIP/788103-040bd5c8", "hangupcall,") in new stack
   -- Executing [s@macro-hangupcall:1] ResetCDR("SIP/788103-040bd5c8", "w") in new stack
   -- Executing [s@macro-hangupcall:2] NoCDR("SIP/788103-040bd5c8", "") in new stack
   -- Executing [s@macro-hangupcall:3] GotoIf("SIP/788103-040bd5c8", "1?skiprg") in new stack
   -- Goto (macro-hangupcall,s,6)
   -- Executing [s@macro-hangupcall:6] GotoIf("SIP/788103-040bd5c8", "1?skipblkvm") in new stack
   -- Goto (macro-hangupcall,s,9)
   -- Executing [s@macro-hangupcall:9] GotoIf("SIP/788103-040bd5c8", "1?theend") in new stack
   -- Goto (macro-hangupcall,s,11)
   -- Executing [s@macro-hangupcall:11] Hangup("SIP/788103-040bd5c8", "") in new stack
 == Spawn extension (macro-hangupcall, s, 11) exited non-zero on 'SIP/788103-040bd5c8' in macro 'hangupcall'
 == Spawn extension (from-internal, *66, 6) exited non-zero on 'SIP/788103-040bd5c8'
   -- Executing [h@from-internal:1] Macro("SIP/788103-040bd5c8", "hangupcall") in new stack
   -- Executing [s@macro-hangupcall:1] ResetCDR("SIP/788103-040bd5c8", "w") in new stack
   -- Executing [s@macro-hangupcall:2] NoCDR("SIP/788103-040bd5c8", "") in new stack
   -- Executing [s@macro-hangupcall:3] GotoIf("SIP/788103-040bd5c8", "1?skiprg") in new stack
   -- Goto (macro-hangupcall,s,6)
   -- Executing [s@macro-hangupcall:6] GotoIf("SIP/788103-040bd5c8", "1?skipblkvm") in new stack
   -- Goto (macro-hangupcall,s,9)
   -- Executing [s@macro-hangupcall:9] GotoIf("SIP/788103-040bd5c8", "1?theend") in new stack
   -- Goto (macro-hangupcall,s,11)
   -- Executing [s@macro-hangupcall:11] Hangup("SIP/788103-040bd5c8", "") in new stack
 == Spawn extension (macro-hangupcall, s, 11) exited non-zero on 'SIP/788103-040bd5c8' in macro 'hangupcall'
 == Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/788103-040bd5c8'
Scheduling destruction of SIP dialog '2074233693-54261-2@192.168.1.108' in 128000 ms (Method: ACK)
set_destination: Parsing <sip:788103@192.168.1.108:54261;transport=tls;user=phone> for address/port to send to
set_destination: set destination to 192.168.1.108, port 54261
Reliably Transmitting (NAT) to 92.254.1.100:2050:
BYE sip:788103@192.168.1.108:54261;transport=tls;user=phone SIP/2.0
v: SIP/2.0/TLS 87.222.43.11:443;branch=z9hG4bK0e42916a;rport
Max-Forwards: 70
f: <sip:*66@87.222.43.11:443;user=phone>;tag=as20e26413
t: <sip:788103@87.222.43.11:443;user=phone>;tag=613547299
i: 2074233693-54261-2@192.168.1.108
CSeq: 102 BYE
User-Agent: Asterisk PBX
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
l: 0


---
mastermetals2*CLI>
<--- SIP read from TLS:92.254.1.100:2050 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 87.222.43.11:443;branch=z9hG4bK0e42916a;rport=443
From: <sip:*66@87.222.43.11:443;user=phone>;tag=as20e26413
To: <sip:788103@87.222.43.11:443;user=phone>;tag=613547299
Call-ID: 2074233693-54261-2@192.168.1.108
CSeq: 102 BYE
Contact: <sip:788103@192.168.1.108:54261;transport=tls;user=phone>
Supported: replaces, path, timer
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0

Only ip nubers and (788103) was diffrent number , to anonymize the log.


here the whitenoise log , of the current version SVN-group-srtp_reboot-r250289

OPTIONS sip:788103@192.168.1.108:54589;transport=tls;user=phone SIP/2.0
v: SIP/2.0/TLS 87.222.43.12:443;branch=z9hG4bK3e226472;rport
Max-Forwards: 70
f: "Unknown" <sip:Unknown@87.222.43.12:443>;tag=as654ff079
t: <sip:788103@192.168.1.108:54589;transport=tls;user=phone>
m: <sip:Unknown@87.222.43.12:443;transport=TLS>
i: 047baddc5ec3c7be0044e6f64f363021@87.222.43.12
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Date: Wed, 03 Mar 2010 01:47:57 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
k: replaces, timer
l: 0


---
mastermetals1*CLI>
<--- SIP read from TLS:92.254.11.254:2050 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 87.222.43.12:443;branch=z9hG4bK3e226472;rport=443
From: "Unknown" <sip:Unknown@87.222.43.12:443>;tag=as654ff079
To: <sip:788103@192.168.1.108:54589;transport=tls;user=phone>;tag=273863356
Call-ID: 047baddc5ec3c7be0044e6f64f363021@87.222.43.12
CSeq: 102 OPTIONS
Supported: replaces, path, timer
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0


<------------->
--- (10 headers 0 lines) ---
mastermetals1*CLI>
<--- SIP read from TLS:92.254.11.254:2050 --->
REGISTER sip:87.222.43.12:443 SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:54589;branch=z9hG4bK993758837;rport;alias
From: <sip:788103@87.222.43.12:443;user=phone>;tag=1347247709
To: <sip:788103@87.222.43.12:443;user=phone>
Call-ID: 864877769-54589-1@192.168.1.108
CSeq: 2046 REGISTER
Contact: <sip:788103@192.168.1.108:54589;transport=tls;user=phone>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B82131B12>"
Authorization: Digest username="788103", realm="asterisk", nonce="71a06e64", uri="sip:87.222.43.12:443", response="149ab028eef9b4253cb764058fefde74", algorithm=MD5
Max-Forwards: 70
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Supported: path
Expires: 120
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0


<------------->
--- (14 headers 0 lines) ---
mastermetals1*CLI>
<--- Transmitting (NAT) to 92.254.11.254:2050 --->
SIP/2.0 401 Unauthorized
v: SIP/2.0/TLS 192.168.1.108:54589;branch=z9hG4bK993758837;alias;received=92.254.11.254;rport=2050
f: <sip:788103@87.222.43.12:443;user=phone>;tag=1347247709
t: <sip:788103@87.222.43.12:443;user=phone>;tag=as2bd3f71a
i: 864877769-54589-1@192.168.1.108
CSeq: 2046 REGISTER
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
k: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="4566cd50"
l: 0


<------------>
Scheduling destruction of SIP dialog '864877769-54589-1@192.168.1.108' in 32000 ms (Method: REGISTER)
mastermetals1*CLI>
<--- SIP read from TLS:92.254.11.254:2050 --->
REGISTER sip:87.222.43.12:443 SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:54589;branch=z9hG4bK2047545965;rport;alias
From: <sip:788103@87.222.43.12:443;user=phone>;tag=1347247709
To: <sip:788103@87.222.43.12:443;user=phone>
Call-ID: 864877769-54589-1@192.168.1.108
CSeq: 2047 REGISTER
Contact: <sip:788103@192.168.1.108:54589;transport=tls;user=phone>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B82131B12>"
Authorization: Digest username="788103", realm="asterisk", nonce="4566cd50", uri="sip:87.222.43.12:443", response="4034bec2c25737a4e56a80fe5a8f2dae", algorithm=MD5
Max-Forwards: 70
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Supported: path
Expires: 120
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0


<------------->
--- (14 headers 0 lines) ---
Sending to 92.254.11.254 : 2050 (NAT)
Reliably Transmitting (NAT) to 92.254.11.254:2050:
OPTIONS sip:788103@192.168.1.108:54589;transport=tls;user=phone SIP/2.0
v: SIP/2.0/TLS 87.222.43.12:443;branch=z9hG4bK1cd63b4a;rport
Max-Forwards: 70
f: "Unknown" <sip:Unknown@87.222.43.12:443>;tag=as6f2c96ef
t: <sip:788103@192.168.1.108:54589;transport=tls;user=phone>
m: <sip:Unknown@87.222.43.12:443;transport=TLS>
i: 13eeecb256b362f8433cf0e461ab2b19@87.222.43.12
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Date: Wed, 03 Mar 2010 01:47:57 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
k: replaces, timer
l: 0


---
mastermetals1*CLI>
<--- Transmitting (NAT) to 92.254.11.254:2050 --->
SIP/2.0 200 OK
v: SIP/2.0/TLS 192.168.1.108:54589;branch=z9hG4bK2047545965;alias;received=92.254.11.254;rport=2050
f: <sip:788103@87.222.43.12:443;user=phone>;tag=1347247709
t: <sip:788103@87.222.43.12:443;user=phone>;tag=as2bd3f71a
i: 864877769-54589-1@192.168.1.108
CSeq: 2047 REGISTER
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
k: replaces, timer
Expires: 120
m: <sip:788103@192.168.1.108:54589;transport=tls;user=phone>;expires=120
Date: Wed, 03 Mar 2010 01:47:57 GMT
l: 0


<------------>
Scheduling destruction of SIP dialog '864877769-54589-1@192.168.1.108' in 32000 ms (Method: REGISTER)
mastermetals1*CLI>
<--- SIP read from TLS:92.254.11.254:2050 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 87.222.43.12:443;branch=z9hG4bK1cd63b4a;rport=443
From: "Unknown" <sip:Unknown@87.222.43.12:443>;tag=as6f2c96ef
To: <sip:788103@192.168.1.108:54589;transport=tls;user=phone>;tag=701204345
Call-ID: 13eeecb256b362f8433cf0e461ab2b19@87.222.43.12
CSeq: 102 OPTIONS
Supported: replaces, path, timer
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0


<------------->
--- (10 headers 0 lines) ---
Really destroying SIP dialog '047baddc5ec3c7be0044e6f64f363021@87.222.43.12' Method: OPTIONS
Really destroying SIP dialog '13eeecb256b362f8433cf0e461ab2b19@87.222.43.12' Method: OPTIONS
mastermetals1*CLI>
<--- SIP read from TLS:92.254.11.254:2050 --->
INVITE sip:*68@87.222.43.12:443;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:54589;branch=z9hG4bK1734955060;rport;alias
From: <sip:788103@87.222.43.12:443;user=phone>;tag=1797763342
To: <sip:*68@87.222.43.12:443;user=phone>
Call-ID: 229730171-54589-7@192.168.1.108
CSeq: 60 INVITE
Contact: <sip:788103@192.168.1.108:54589;transport=tls;user=phone>
Max-Forwards: 70
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Privacy: none
P-Asserted-Identity: <sip:788103@87.222.43.12:443;user=phone>
Supported: replaces, path, timer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Type: application/sdp
Accept: application/sdp, application/dtmf-relay
Content-Length:   631

v=0
o=788103 8000 8000 IN IP4 192.168.1.108
s=SIP Call
c=IN IP4 192.168.1.108
t=0 0
m=audio 53432 RTP/SAVP 0 8 4 18 2 97 102 100 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:2 G726-32/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:102 G729E/8000
a=rtpmap:100 AAL2-G726-16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32-36,54
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:6lXR6Qk1NqvSrpH53b8cvei9h84XgPbQRRGaU82U
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:arfpO6HzcNeeQoUvO2LuVx/XFKalLCac/Gytlr96

<------------->
--- (16 headers 22 lines) ---
Using INVITE request as basis request - 229730171-54589-7@192.168.1.108
Found peer '788103' for '788103' from 92.254.11.254:2050
mastermetals1*CLI>
<--- Reliably Transmitting (NAT) to 92.254.11.254:2050 --->
SIP/2.0 401 Unauthorized
v: SIP/2.0/TLS 192.168.1.108:54589;branch=z9hG4bK1734955060;alias;received=92.254.11.254;rport=2050
f: <sip:788103@87.222.43.12:443;user=phone>;tag=1797763342
t: <sip:*68@87.222.43.12:443;user=phone>;tag=as6adf1547
i: 229730171-54589-7@192.168.1.108
CSeq: 60 INVITE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
k: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="0ded9599"
l: 0


<------------>
Scheduling destruction of SIP dialog '229730171-54589-7@192.168.1.108' in 6400 ms (Method: INVITE)
mastermetals1*CLI>
<--- SIP read from TLS:92.254.11.254:2050 --->
ACK sip:*68@87.222.43.12:443;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:54589;branch=z9hG4bK1734955060;rport;alias
From: <sip:788103@87.222.43.12:443;user=phone>;tag=1797763342
To: <sip:*68@87.222.43.12:443;user=phone>;tag=as6adf1547
Call-ID: 229730171-54589-7@192.168.1.108
CSeq: 60 ACK
Content-Length: 0


<------------->
--- (7 headers 0 lines) ---
mastermetals1*CLI>
<--- SIP read from TLS:92.254.11.254:2050 --->
INVITE sip:*68@87.222.43.12:443;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:54589;branch=z9hG4bK668750409;rport;alias
From: <sip:788103@87.222.43.12:443;user=phone>;tag=1797763342
To: <sip:*68@87.222.43.12:443;user=phone>
Call-ID: 229730171-54589-7@192.168.1.108
CSeq: 61 INVITE
Contact: <sip:788103@192.168.1.108:54589;transport=tls;user=phone>
Authorization: Digest username="788103", realm="asterisk", nonce="0ded9599", uri="sip:*68@87.222.43.12:443;user=phone", response="e8243ed929c8905de14c524b43626273", algorithm=MD5
Max-Forwards: 70
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Privacy: none
P-Asserted-Identity: <sip:788103@87.222.43.12:443;user=phone>
Supported: replaces, path, timer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Type: application/sdp
Accept: application/sdp, application/dtmf-relay
Content-Length:   631

v=0
o=788103 8000 8000 IN IP4 192.168.1.108
s=SIP Call
c=IN IP4 192.168.1.108
t=0 0
m=audio 53432 RTP/SAVP 0 8 4 18 2 97 102 100 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:2 G726-32/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:102 G729E/8000
a=rtpmap:100 AAL2-G726-16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32-36,54
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:6lXR6Qk1NqvSrpH53b8cvei9h84XgPbQRRGaU82U
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:arfpO6HzcNeeQoUvO2LuVx/XFKalLCac/Gytlr96

<------------->
--- (17 headers 22 lines) ---
Sending to 92.254.11.254 : 2050 (NAT)
Using INVITE request as basis request - 229730171-54589-7@192.168.1.108
Found peer '788103' for '788103' from 92.254.11.254:2050
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 4
Found RTP audio format 18
Found RTP audio format 2
Found RTP audio format 97
Found RTP audio format 102
Found RTP audio format 100
Found RTP audio format 101
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Found audio description format G723 for ID 4
Found audio description format G729 for ID 18
Found audio description format G726-32 for ID 2
Found audio description format iLBC for ID 97
Found audio description format G729E for ID 102
Found audio description format AAL2-G726-16 for ID 100
Found audio description format telephone-event for ID 101
Capabilities: us - 0x10d (g723|ulaw|alaw|g729), peer - audio=0x2d0d (g723|ulaw|alaw|g726|g729|ilbc|siren7)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x10d (g723|ulaw|alaw|g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 192.168.1.108:53432
Looking for *68 in klant-31-123-123456 (domain 87.222.43.12)
list_route: hop: <sip:788103@192.168.1.108:54589;transport=tls;user=phone>
mastermetals1*CLI>
<--- Transmitting (NAT) to 92.254.11.254:2050 --->
SIP/2.0 100 Trying
v: SIP/2.0/TLS 192.168.1.108:54589;branch=z9hG4bK668750409;alias;received=92.254.11.254;rport=2050
f: <sip:788103@87.222.43.12:443;user=phone>;tag=1797763342
t: <sip:*68@87.222.43.12:443;user=phone>
i: 229730171-54589-7@192.168.1.108
CSeq: 61 INVITE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
k: replaces, timer
m: <sip:*68@87.222.43.12:443;transport=TLS>
l: 0


<------------>
   -- Executing [*68@klant-31-123-123456:1] Goto("SIP/788103-00000005", "from-internal,*68,1") in new stack
   -- Goto (from-internal,*68,1)
   -- Executing [*68@from-internal:1] NoOp("SIP/788103-00000005", "Bridge signaling: ") in new stack
   -- Executing [*68@from-internal:2] NoOp("SIP/788103-00000005", "Bridge media: ") in new stack
   -- Executing [*68@from-internal:3] Wait("SIP/788103-00000005", "1") in new stack
   -- Executing [*68@from-internal:4] Answer("SIP/788103-00000005", "") in new stack
Audio is at 87.222.43.12 port 19784
Adding codec 0x8 (alaw) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x100 (g729) to SDP
Adding codec 0x1 (g723) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
mastermetals1*CLI>
<--- Reliably Transmitting (NAT) to 92.254.11.254:2050 --->
SIP/2.0 200 OK
v: SIP/2.0/TLS 192.168.1.108:54589;branch=z9hG4bK668750409;alias;received=92.254.11.254;rport=2050
f: <sip:788103@87.222.43.12:443;user=phone>;tag=1797763342
t: <sip:*68@87.222.43.12:443;user=phone>;tag=as08af6e14
i: 229730171-54589-7@192.168.1.108
CSeq: 61 INVITE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
k: replaces, timer
m: <sip:*68@87.222.43.12:443;transport=TLS>
c: application/sdp
l: 457

v=0
o=root 2136709363 2136709363 IN IP4 87.222.43.12
s=Asterisk PBX
c=IN IP4 87.222.43.12
t=0 0
m=audio 19784 RTP/SAVP 8 0 18 4 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:YXreDqKfG+DLsPDdtKES5z6pSCkbb6WKVLW+17ng

<------------>
mastermetals1*CLI>
<--- SIP read from TLS:92.254.11.254:2050 --->
ACK sip:*68@87.222.43.12:443;transport=TLS SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:54589;branch=z9hG4bK240260884;rport
From: <sip:788103@87.222.43.12:443;user=phone>;tag=1797763342
To: <sip:*68@87.222.43.12:443;user=phone>;tag=as08af6e14
Call-ID: 229730171-54589-7@192.168.1.108
CSeq: 61 ACK
Contact: <sip:788103@192.168.1.108:54589;transport=tls;user=phone>
Max-Forwards: 70
Supported: replaces, path, timer
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0


<------------->
--- (12 headers 0 lines) ---
   -- Executing [*68@from-internal:5] Macro("SIP/788103-00000005", "user-callerid,") in new stack
   -- Executing [s@macro-user-callerid:1] Set("SIP/788103-00000005", "AMPUSER=788103") in new stack
   -- Executing [s@macro-user-callerid:2] GotoIf("SIP/788103-00000005", "0?report") in new stack
   -- Executing [s@macro-user-callerid:3] ExecIf("SIP/788103-00000005", "1?Set(REALCALLERIDNUM=788103)") in new stack
   -- Executing [s@macro-user-callerid:4] Set("SIP/788103-00000005", "AMPUSER=") in new stack
   -- Executing [s@macro-user-callerid:5] Set("SIP/788103-00000005", "AMPUSERCIDNAME=") in new stack
   -- Executing [s@macro-user-callerid:6] GotoIf("SIP/788103-00000005", "1?report") in new stack
   -- Goto (macro-user-callerid,s,9)
   -- Executing [s@macro-user-callerid:9] GotoIf("SIP/788103-00000005", "0?continue") in new stack
   -- Executing [s@macro-user-callerid:10] Set("SIP/788103-00000005", "__TTL=64") in new stack
   -- Executing [s@macro-user-callerid:11] GotoIf("SIP/788103-00000005", "1?continue") in new stack
   -- Goto (macro-user-callerid,s,18)
   -- Executing [s@macro-user-callerid:18] NoOp("SIP/788103-00000005", "Using CallerID "device" <788103>") in new stack
   -- Executing [*68@from-internal:6] Set("SIP/788103-00000005", "DB(CP/)=ENABLED") in new stack
   -- Executing [*68@from-internal:7] Playback("SIP/788103-00000005", "privacy-your-callerid-is&de-activated") in new stack
   -- <SIP/788103-00000005> Playing 'privacy-your-callerid-is.alaw' (language 'en')
   -- <SIP/788103-00000005> Playing 'de-activated.alaw' (language 'en')
   -- Executing [*68@from-internal:8] Macro("SIP/788103-00000005", "hangupcall,") in new stack
   -- Executing [s@macro-hangupcall:1] ResetCDR("SIP/788103-00000005", "w") in new stack
   -- Executing [s@macro-hangupcall:2] NoCDR("SIP/788103-00000005", "") in new stack
   -- Executing [s@macro-hangupcall:3] GotoIf("SIP/788103-00000005", "1?skiprg") in new stack
   -- Goto (macro-hangupcall,s,6)
   -- Executing [s@macro-hangupcall:6] GotoIf("SIP/788103-00000005", "1?skipblkvm") in new stack
   -- Goto (macro-hangupcall,s,9)
   -- Executing [s@macro-hangupcall:9] GotoIf("SIP/788103-00000005", "1?theend") in new stack
   -- Goto (macro-hangupcall,s,11)
   -- Executing [s@macro-hangupcall:11] Hangup("SIP/788103-00000005", "") in new stack
 == Spawn extension (macro-hangupcall, s, 11) exited non-zero on 'SIP/788103-00000005' in macro 'hangupcall'
 == Spawn extension (from-internal, *68, 8) exited non-zero on 'SIP/788103-00000005'
   -- Executing [h@from-internal:1] Macro("SIP/788103-00000005", "hangupcall") in new stack
   -- Executing [s@macro-hangupcall:1] ResetCDR("SIP/788103-00000005", "w") in new stack
   -- Executing [s@macro-hangupcall:2] NoCDR("SIP/788103-00000005", "") in new stack
   -- Executing [s@macro-hangupcall:3] GotoIf("SIP/788103-00000005", "1?skiprg") in new stack
   -- Goto (macro-hangupcall,s,6)
   -- Executing [s@macro-hangupcall:6] GotoIf("SIP/788103-00000005", "1?skipblkvm") in new stack
   -- Goto (macro-hangupcall,s,9)
   -- Executing [s@macro-hangupcall:9] GotoIf("SIP/788103-00000005", "1?theend") in new stack
   -- Goto (macro-hangupcall,s,11)
   -- Executing [s@macro-hangupcall:11] Hangup("SIP/788103-00000005", "") in new stack
 == Spawn extension (macro-hangupcall, s, 11) exited non-zero on 'SIP/788103-00000005' in macro 'hangupcall'
 == Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/788103-00000005'
Scheduling destruction of SIP dialog '229730171-54589-7@192.168.1.108' in 6400 ms (Method: INVITE)
set_destination: Parsing <sip:788103@192.168.1.108:54589;transport=tls;user=phone> for address/port to send to
set_destination: set destination to 192.168.1.108, port 54589
Reliably Transmitting (NAT) to 92.254.11.254:2050:
BYE sip:788103@192.168.1.108:54589;transport=tls;user=phone SIP/2.0
v: SIP/2.0/TLS 87.222.43.12:443;branch=z9hG4bK0659ee6d;rport
Max-Forwards: 70
f: <sip:*68@87.222.43.12:443;user=phone>;tag=as08af6e14
t: <sip:788103@87.222.43.12:443;user=phone>;tag=1797763342
i: 229730171-54589-7@192.168.1.108
CSeq: 102 BYE
User-Agent: Asterisk PBX
Proxy-Authorization: Digest username="788103", realm="asterisk", algorithm=MD5, uri="87.222.43.12", nonce="", response="36cb4d85b80aec9a89c3e3eb1736be73"
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
l: 0


---
mastermetals1*CLI>
<--- SIP read from TLS:92.254.11.254:2050 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 87.222.43.12:443;branch=z9hG4bK0659ee6d;rport=443
From: <sip:*68@87.222.43.12:443;user=phone>;tag=as08af6e14
To: <sip:788103@87.222.43.12:443;user=phone>;tag=1797763342
Call-ID: 229730171-54589-7@192.168.1.108
CSeq: 102 BYE
Contact: <sip:788103@192.168.1.108:54589;transport=tls;user=phone>
Supported: replaces, path, timer
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0


<------------->
--- (11 headers 0 lines) ---
SIP Response message for INCOMING dialog BYE arrived

By: Terry Wilson (twilson) 2010-03-03 09:35:46.000-0600

I too am using a grandstream with SRTP forced, and whether I make a call to or from it I don't get the whitenoise anymore.

Can you verify that sip_get_rtp_peer() in channels/chan_sip.c has the lines:
   } else if (ast_test_flag(&global_jbconf, AST_JB_FORCED) || p->srtp) {
               res = AST_RTP_GLUE_RESULT_FORBID;
   }

(particularly the || p->srtp) and recompile and try again and give me the debug output from the srtp_reboot try?

By: frank koster (notthematrix) 2010-03-03 09:43:39.000-0600

yes I found theese lines...

       if (ast_test_flag(&p->flags[0], SIP_DIRECT_MEDIA | SIP_DIRECT_MEDIA_NAT)) {
               res = AST_RTP_GLUE_RESULT_REMOTE;
       } else if (ast_test_flag(&global_jbconf, AST_JB_FORCED) || p->srtp) {
               res = AST_RTP_GLUE_RESULT_FORBID;
       }

By: frank koster (notthematrix) 2010-03-03 10:10:49.000-0600

@twilson
here the NEW output.
as you requested :)

<--- SIP read from TLS:92.254.55.200:2050 --->
INVITE sip:*66@87.251.43.124:443;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:51280;branch=z9hG4bK818032521;rport;alias
From: <sip:31251788103@87.251.43.124:443;user=phone>;tag=1150824446
To: <sip:*66@87.251.43.124:443;user=phone>
Call-ID: 237371426-51280-5@192.168.1.108
CSeq: 40 INVITE
Contact: <sip:31251788103@192.168.1.108:51280;transport=tls;user=phone>
Max-Forwards: 70
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Privacy: none
P-Asserted-Identity: <sip:31251788103@87.251.43.124:443;user=phone>
Supported: replaces, path, timer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Type: application/sdp
Accept: application/sdp, application/dtmf-relay
Content-Length:   631

v=0
o=31251788103 8000 8000 IN IP4 192.168.1.108
s=SIP Call
c=IN IP4 192.168.1.108
t=0 0
m=audio 36774 RTP/SAVP 0 8 4 18 2 97 102 100 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:2 G726-32/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:102 G729E/8000
a=rtpmap:100 AAL2-G726-16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32-36,54
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:5Nx9/l0cXF/rQ9zCthJnod6m//F8r67o956ZvYct
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:A2wKgGpnnMbGiAqjSsC1smGUWGCF1BAzvAfSVcRZ

<------------->
--- (16 headers 22 lines) ---
Using INVITE request as basis request - 237371426-51280-5@192.168.1.108
Found peer '31251788103' for '31251788103' from 92.254.55.200:2050

<--- Reliably Transmitting (NAT) to 92.254.55.200:2050 --->
SIP/2.0 401 Unauthorized
v: SIP/2.0/TLS 192.168.1.108:51280;branch=z9hG4bK818032521;alias;received=92.254.55.200;rport=2050
f: <sip:31251788103@87.251.43.124:443;user=phone>;tag=1150824446
t: <sip:*66@87.251.43.124:443;user=phone>;tag=as25f1b441
i: 237371426-51280-5@192.168.1.108
CSeq: 40 INVITE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
k: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="3e7c7408"
l: 0


<------------>
Scheduling destruction of SIP dialog '237371426-51280-5@192.168.1.108' in 6400 ms (Method: INVITE)
mastermetals1*CLI>
<--- SIP read from TLS:92.254.55.200:2050 --->
ACK sip:*66@87.251.43.124:443;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:51280;branch=z9hG4bK818032521;rport;alias
From: <sip:31251788103@87.251.43.124:443;user=phone>;tag=1150824446
To: <sip:*66@87.251.43.124:443;user=phone>;tag=as25f1b441
Call-ID: 237371426-51280-5@192.168.1.108
CSeq: 40 ACK
Content-Length: 0


<------------->
--- (7 headers 0 lines) ---
mastermetals1*CLI>
<--- SIP read from TLS:92.254.55.200:2050 --->
INVITE sip:*66@87.251.43.124:443;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:51280;branch=z9hG4bK1231987690;rport;alias
From: <sip:31251788103@87.251.43.124:443;user=phone>;tag=1150824446
To: <sip:*66@87.251.43.124:443;user=phone>
Call-ID: 237371426-51280-5@192.168.1.108
CSeq: 41 INVITE
Contact: <sip:31251788103@192.168.1.108:51280;transport=tls;user=phone>
Authorization: Digest username="31251788103", realm="asterisk", nonce="3e7c7408", uri="sip:*66@87.251.43.124:443;user=phone", response="27167da0f1433490b60c72c9e6f04941", algorithm=MD5
Max-Forwards: 70
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Privacy: none
P-Asserted-Identity: <sip:31251788103@87.251.43.124:443;user=phone>
Supported: replaces, path, timer
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Type: application/sdp
Accept: application/sdp, application/dtmf-relay
Content-Length:   631

v=0
o=31251788103 8000 8000 IN IP4 192.168.1.108
s=SIP Call
c=IN IP4 192.168.1.108
t=0 0
m=audio 36774 RTP/SAVP 0 8 4 18 2 97 102 100 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:2 G726-32/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=rtpmap:102 G729E/8000
a=rtpmap:100 AAL2-G726-16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16,32-36,54
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:5Nx9/l0cXF/rQ9zCthJnod6m//F8r67o956ZvYct
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:A2wKgGpnnMbGiAqjSsC1smGUWGCF1BAzvAfSVcRZ

<------------->
--- (17 headers 22 lines) ---
Sending to 92.254.55.200 : 2050 (NAT)
Using INVITE request as basis request - 237371426-51280-5@192.168.1.108
Found peer '31251788103' for '31251788103' from 92.254.55.200:2050
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 4
Found RTP audio format 18
Found RTP audio format 2
Found RTP audio format 97
Found RTP audio format 102
Found RTP audio format 100
Found RTP audio format 101
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Found audio description format G723 for ID 4
Found audio description format G729 for ID 18
Found audio description format G726-32 for ID 2
Found audio description format iLBC for ID 97
Found audio description format G729E for ID 102
Found audio description format AAL2-G726-16 for ID 100
Found audio description format telephone-event for ID 101
Capabilities: us - 0x10d (g723|ulaw|alaw|g729), peer - audio=0x2d0d (g723|ulaw|alaw|g726|g729|ilbc|siren7)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x10d (g723|ulaw|alaw|g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 192.168.1.108:36774
Looking for *66 in klant-31-123-123456 (domain 87.251.43.124)
list_route: hop: <sip:31251788103@192.168.1.108:51280;transport=tls;user=phone>
mastermetals1*CLI>
<--- Transmitting (NAT) to 92.254.55.200:2050 --->
SIP/2.0 100 Trying
v: SIP/2.0/TLS 192.168.1.108:51280;branch=z9hG4bK1231987690;alias;received=92.254.55.200;rport=2050
f: <sip:31251788103@87.251.43.124:443;user=phone>;tag=1150824446
t: <sip:*66@87.251.43.124:443;user=phone>
i: 237371426-51280-5@192.168.1.108
CSeq: 41 INVITE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
k: replaces, timer
m: <sip:*66@87.251.43.124:443;transport=TLS>
l: 0


<------------>
   -- Executing [*66@klant-31-123-123456:1] Goto("SIP/31251788103-00000006", "from-internal,*66,1") in new stack
   -- Goto (from-internal,*66,1)
   -- Executing [*66@from-internal:1] Answer("SIP/31251788103-00000006", "") in new stack
Audio is at 87.251.43.124 port 17750
Adding codec 0x8 (alaw) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x100 (g729) to SDP
Adding codec 0x1 (g723) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
mastermetals1*CLI>
<--- Reliably Transmitting (NAT) to 92.254.55.200:2050 --->
SIP/2.0 200 OK
v: SIP/2.0/TLS 192.168.1.108:51280;branch=z9hG4bK1231987690;alias;received=92.254.55.200;rport=2050
f: <sip:31251788103@87.251.43.124:443;user=phone>;tag=1150824446
t: <sip:*66@87.251.43.124:443;user=phone>;tag=as0443c618
i: 237371426-51280-5@192.168.1.108
CSeq: 41 INVITE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
k: replaces, timer
m: <sip:*66@87.251.43.124:443;transport=TLS>
c: application/sdp
l: 455

v=0
o=root 949742278 949742278 IN IP4 87.251.43.124
s=Asterisk PBX
c=IN IP4 87.251.43.124
t=0 0
m=audio 17750 RTP/SAVP 8 0 18 4 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:bW3qflnmvFJLgSW63DbwZX90CFmDyEpsd8I2LT7J

<------------>
mastermetals1*CLI>
<--- SIP read from TLS:92.254.55.200:2050 --->
ACK sip:*66@87.251.43.124:443;transport=TLS SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:51280;branch=z9hG4bK296795156;rport
From: <sip:31251788103@87.251.43.124:443;user=phone>;tag=1150824446
To: <sip:*66@87.251.43.124:443;user=phone>;tag=as0443c618
Call-ID: 237371426-51280-5@192.168.1.108
CSeq: 41 ACK
Contact: <sip:31251788103@192.168.1.108:51280;transport=tls;user=phone>
Max-Forwards: 70
Supported: replaces, path, timer
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0


<------------->
--- (12 headers 0 lines) ---
   -- Executing [*66@from-internal:2] Wait("SIP/31251788103-00000006", "1") in new stack
   -- Executing [*66@from-internal:3] Macro("SIP/31251788103-00000006", "user-callerid,") in new stack
   -- Executing [s@macro-user-callerid:1] Set("SIP/31251788103-00000006", "AMPUSER=31251788103") in new stack
   -- Executing [s@macro-user-callerid:2] GotoIf("SIP/31251788103-00000006", "0?report") in new stack
   -- Executing [s@macro-user-callerid:3] ExecIf("SIP/31251788103-00000006", "1?Set(REALCALLERIDNUM=31251788103)") in new stack
   -- Executing [s@macro-user-callerid:4] Set("SIP/31251788103-00000006", "AMPUSER=") in new stack
   -- Executing [s@macro-user-callerid:5] Set("SIP/31251788103-00000006", "AMPUSERCIDNAME=") in new stack
   -- Executing [s@macro-user-callerid:6] GotoIf("SIP/31251788103-00000006", "1?report") in new stack
   -- Goto (macro-user-callerid,s,9)
   -- Executing [s@macro-user-callerid:9] GotoIf("SIP/31251788103-00000006", "0?continue") in new stack
   -- Executing [s@macro-user-callerid:10] Set("SIP/31251788103-00000006", "__TTL=64") in new stack
   -- Executing [s@macro-user-callerid:11] GotoIf("SIP/31251788103-00000006", "1?continue") in new stack
   -- Goto (macro-user-callerid,s,18)
   -- Executing [s@macro-user-callerid:18] NoOp("SIP/31251788103-00000006", "Using CallerID "device" <31251788103>") in new stack
   -- Executing [*66@from-internal:4] DBdel("SIP/31251788103-00000006", "CP/") in new stack
   -- DBdel: family=CP, key=
   -- DBdel: Error deleting key from database.
   -- Executing [*66@from-internal:5] Playback("SIP/31251788103-00000006", "privacy-your-callerid-is&activated") in new stack
   -- <SIP/31251788103-00000006> Playing 'privacy-your-callerid-is.alaw' (language 'en')
   -- <SIP/31251788103-00000006> Playing 'activated.alaw' (language 'en')
   -- Executing [*66@from-internal:6] Macro("SIP/31251788103-00000006", "hangupcall,") in new stack
   -- Executing [s@macro-hangupcall:1] ResetCDR("SIP/31251788103-00000006", "w") in new stack
   -- Executing [s@macro-hangupcall:2] NoCDR("SIP/31251788103-00000006", "") in new stack
   -- Executing [s@macro-hangupcall:3] GotoIf("SIP/31251788103-00000006", "1?skiprg") in new stack
   -- Goto (macro-hangupcall,s,6)
   -- Executing [s@macro-hangupcall:6] GotoIf("SIP/31251788103-00000006", "1?skipblkvm") in new stack
   -- Goto (macro-hangupcall,s,9)
   -- Executing [s@macro-hangupcall:9] GotoIf("SIP/31251788103-00000006", "1?theend") in new stack
   -- Goto (macro-hangupcall,s,11)
   -- Executing [s@macro-hangupcall:11] Hangup("SIP/31251788103-00000006", "") in new stack
 == Spawn extension (macro-hangupcall, s, 11) exited non-zero on 'SIP/31251788103-00000006' in macro 'hangupcall'
 == Spawn extension (from-internal, *66, 6) exited non-zero on 'SIP/31251788103-00000006'
   -- Executing [h@from-internal:1] Macro("SIP/31251788103-00000006", "hangupcall") in new stack
   -- Executing [s@macro-hangupcall:1] ResetCDR("SIP/31251788103-00000006", "w") in new stack
   -- Executing [s@macro-hangupcall:2] NoCDR("SIP/31251788103-00000006", "") in new stack
   -- Executing [s@macro-hangupcall:3] GotoIf("SIP/31251788103-00000006", "1?skiprg") in new stack
   -- Goto (macro-hangupcall,s,6)
   -- Executing [s@macro-hangupcall:6] GotoIf("SIP/31251788103-00000006", "1?skipblkvm") in new stack
   -- Goto (macro-hangupcall,s,9)
   -- Executing [s@macro-hangupcall:9] GotoIf("SIP/31251788103-00000006", "1?theend") in new stack
   -- Goto (macro-hangupcall,s,11)
   -- Executing [s@macro-hangupcall:11] Hangup("SIP/31251788103-00000006", "") in new stack
 == Spawn extension (macro-hangupcall, s, 11) exited non-zero on 'SIP/31251788103-00000006' in macro 'hangupcall'
 == Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/31251788103-00000006'
Scheduling destruction of SIP dialog '237371426-51280-5@192.168.1.108' in 6400 ms (Method: INVITE)
set_destination: Parsing <sip:31251788103@192.168.1.108:51280;transport=tls;user=phone> for address/port to send to
set_destination: set destination to 192.168.1.108, port 51280
Reliably Transmitting (NAT) to 92.254.55.200:2050:
BYE sip:31251788103@192.168.1.108:51280;transport=tls;user=phone SIP/2.0
v: SIP/2.0/TLS 87.251.43.124:443;branch=z9hG4bK6f54fabc;rport
Max-Forwards: 70
f: <sip:*66@87.251.43.124:443;user=phone>;tag=as0443c618
t: <sip:31251788103@87.251.43.124:443;user=phone>;tag=1150824446
i: 237371426-51280-5@192.168.1.108
CSeq: 102 BYE
User-Agent: Asterisk PBX
Proxy-Authorization: Digest username="31251788103", realm="asterisk", algorithm=MD5, uri="87.251.43.124", nonce="", response="36cb4d85b80aec9a89c3e3eb1736be73"
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
l: 0


---
mastermetals1*CLI>
<--- SIP read from TLS:92.254.55.200:2050 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 87.251.43.124:443;branch=z9hG4bK6f54fabc;rport=443
From: <sip:*66@87.251.43.124:443;user=phone>;tag=as0443c618
To: <sip:31251788103@87.251.43.124:443;user=phone>;tag=1150824446
Call-ID: 237371426-51280-5@192.168.1.108
CSeq: 102 BYE
Contact: <sip:31251788103@192.168.1.108:51280;transport=tls;user=phone>
Supported: replaces, path, timer
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0


<------------->
--- (11 headers 0 lines) ---
SIP Response message for INCOMING dialog BYE arrived
Really destroying SIP dialog '237371426-51280-5@192.168.1.108' Method: INVITE
Reliably Transmitting (NAT) to 92.254.55.200:2050:
OPTIONS sip:31251788103@192.168.1.108:51280;transport=tls;user=phone SIP/2.0
v: SIP/2.0/TLS 87.251.43.124:443;branch=z9hG4bK2efeb8f9;rport
Max-Forwards: 70
f: "Unknown" <sip:Unknown@87.251.43.124:443>;tag=as5d582010
t: <sip:31251788103@192.168.1.108:51280;transport=tls;user=phone>
m: <sip:Unknown@87.251.43.124:443;transport=TLS>
i: 3547b99d7a4becd56c3d6c0341b73a25@87.251.43.124
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Date: Wed, 03 Mar 2010 16:08:04 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
k: replaces, timer
l: 0


---
mastermetals1*CLI>
<--- SIP read from TLS:92.254.55.200:2050 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 87.251.43.124:443;branch=z9hG4bK2efeb8f9;rport=443
From: "Unknown" <sip:Unknown@87.251.43.124:443>;tag=as5d582010
To: <sip:31251788103@192.168.1.108:51280;transport=tls;user=phone>;tag=1598626929
Call-ID: 3547b99d7a4becd56c3d6c0341b73a25@87.251.43.124
CSeq: 102 OPTIONS
Supported: replaces, path, timer
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0


<------------->
--- (10 headers 0 lines) ---
mastermetals1*CLI>
<--- SIP read from TLS:92.254.55.200:2050 --->
REGISTER sip:87.251.43.124:443 SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:51280;branch=z9hG4bK11023348;rport;alias
From: <sip:31251788103@87.251.43.124:443;user=phone>;tag=1970777137
To: <sip:31251788103@87.251.43.124:443;user=phone>
Call-ID: 1562417533-51280-1@192.168.1.108
CSeq: 2030 REGISTER
Contact: <sip:31251788103@192.168.1.108:51280;transport=tls;user=phone>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B82131B12>"
Authorization: Digest username="31251788103", realm="asterisk", nonce="2c37f64b", uri="sip:87.251.43.124:443", response="dd43fdc1b25dadc7b82d0e525c6eb471", algorithm=MD5
Max-Forwards: 70
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Supported: path
Expires: 120
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0


<------------->
--- (14 headers 0 lines) ---
mastermetals1*CLI>
<--- Transmitting (NAT) to 92.254.55.200:2050 --->
SIP/2.0 401 Unauthorized
v: SIP/2.0/TLS 192.168.1.108:51280;branch=z9hG4bK11023348;alias;received=92.254.55.200;rport=2050
f: <sip:31251788103@87.251.43.124:443;user=phone>;tag=1970777137
t: <sip:31251788103@87.251.43.124:443;user=phone>;tag=as5eb1410a
i: 1562417533-51280-1@192.168.1.108
CSeq: 2030 REGISTER
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
k: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="234309ec"
l: 0


<------------>
Scheduling destruction of SIP dialog '1562417533-51280-1@192.168.1.108' in 32000 ms (Method: REGISTER)
mastermetals1*CLI>
<--- SIP read from TLS:92.254.55.200:2050 --->
REGISTER sip:87.251.43.124:443 SIP/2.0
Via: SIP/2.0/TLS 192.168.1.108:51280;branch=z9hG4bK109093412;rport;alias
From: <sip:31251788103@87.251.43.124:443;user=phone>;tag=1970777137
To: <sip:31251788103@87.251.43.124:443;user=phone>
Call-ID: 1562417533-51280-1@192.168.1.108
CSeq: 2031 REGISTER
Contact: <sip:31251788103@192.168.1.108:51280;transport=tls;user=phone>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B82131B12>"
Authorization: Digest username="31251788103", realm="asterisk", nonce="234309ec", uri="sip:87.251.43.124:443", response="ea7907d8e3b45eb63708ab53998f366f", algorithm=MD5
Max-Forwards: 70
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Supported: path
Expires: 120
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0


<------------->
--- (14 headers 0 lines) ---
Sending to 92.254.55.200 : 2050 (NAT)
Reliably Transmitting (NAT) to 92.254.55.200:2050:
OPTIONS sip:31251788103@192.168.1.108:51280;transport=tls;user=phone SIP/2.0
v: SIP/2.0/TLS 87.251.43.124:443;branch=z9hG4bK6f033c81;rport
Max-Forwards: 70
f: "Unknown" <sip:Unknown@87.251.43.124:443>;tag=as47a0d79e
t: <sip:31251788103@192.168.1.108:51280;transport=tls;user=phone>
m: <sip:Unknown@87.251.43.124:443;transport=TLS>
i: 014717b27c4e9f2f0fed05ba3f13ea3b@87.251.43.124
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Date: Wed, 03 Mar 2010 16:08:04 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
k: replaces, timer
l: 0


---
mastermetals1*CLI>
<--- Transmitting (NAT) to 92.254.55.200:2050 --->
SIP/2.0 200 OK
v: SIP/2.0/TLS 192.168.1.108:51280;branch=z9hG4bK109093412;alias;received=92.254.55.200;rport=2050
f: <sip:31251788103@87.251.43.124:443;user=phone>;tag=1970777137
t: <sip:31251788103@87.251.43.124:443;user=phone>;tag=as5eb1410a
i: 1562417533-51280-1@192.168.1.108
CSeq: 2031 REGISTER
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
k: replaces, timer
Expires: 120
m: <sip:31251788103@192.168.1.108:51280;transport=tls;user=phone>;expires=120
Date: Wed, 03 Mar 2010 16:08:04 GMT
l: 0


<------------>
Scheduling destruction of SIP dialog '1562417533-51280-1@192.168.1.108' in 32000 ms (Method: REGISTER)
mastermetals1*CLI>
<--- SIP read from TLS:92.254.55.200:2050 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 87.251.43.124:443;branch=z9hG4bK6f033c81;rport=443
From: "Unknown" <sip:Unknown@87.251.43.124:443>;tag=as47a0d79e
To: <sip:31251788103@192.168.1.108:51280;transport=tls;user=phone>;tag=488688169
Call-ID: 014717b27c4e9f2f0fed05ba3f13ea3b@87.251.43.124
CSeq: 102 OPTIONS
Supported: replaces, path, timer
User-Agent: Grandstream HT-503  V1.1B 1.0.1.57
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0

By: Terry Wilson (twilson) 2010-03-03 10:17:05.000-0600

oh, I wonder if you either have directmedia=yes or canreinvite=yes... if you take out the || p->srtp that I mentioned above and instead change things to this:

if (p->srtp) {
   res = AST_RTP_GLUE_RESULT_FORBID;
} else if (ast_test_flag(&p->flags[0], SIP_DIRECT_MEDIA | SIP_DIRECT_MEDIA_NAT)) {
   res = AST_RTP_GLUE_RESULT_REMOTE;
} else if (ast_test_flag(&global_jbconf, AST_JB_FORCED)) {
   res = AST_RTP_GLUE_RESULT_FORBID;
}

and let me know if it fixes it for you.

By: frank koster (notthematrix) 2010-03-03 10:30:55.000-0600

have canreinvite=no
I directmedia=yes did not work.
with directmedia=yes not in sip.conf did not work ehther.
I removed || p->srtp
still white noise.
Iam using use random port on my grandstream ht-503.
this is bacausese we communicate with countrys were voip is blocked.

By: frank koster (notthematrix) 2010-03-03 10:49:29.000-0600

@twilson
if you need more info let me know.

By: Terry Wilson (twilson) 2010-03-03 11:22:30.000-0600

actually, looking more closely at the debug output, you aren't making an outbound call, just calling in and listening to a sound file. This has always worked for me even without any fixes, so I'm a little confused as to why it hasn't been working for you.

The only difference is that I'm not using TLS on my grandstream (GXP2000 the firmware currently on it doesn't support it), but that shouldn't be effecting the encrypted audio.

By: Terry Wilson (twilson) 2010-03-03 12:45:27.000-0600

I have discovered the issue. I have constantssrc=yes in sip.conf which was masking the problem.  If you set constantssrc=yes, I believe it will fix things for you.  I'll make a fix that doesn't require changing that setting.

By: frank koster (notthematrix) 2010-03-03 21:06:41.000-0600

the source change removing  
|| p->srtp
and constantssrc=yes does the trick for me...

By: Hemanshu Patel (hemanshurpatel) 2010-03-05 00:30:26.000-0600

hi, i had started following SRTP via http://www.voip-info.org/wiki/view/Asterisk+SRTP page.

I am using grandstream gvx3140 with latest firmware 1.0.3.X i guess.
Initially they were not making calls, i mean asterisk was not allowing call, as GS was sending xxxxxxx|2^32 as last thing in crypto value...where asterisk was saying lifetime support is not allowed.....

Then i commented that part, and applied few more hacks, and make asterisk doing SRTP Proxy work. Which initially wasnt allowed as SIPSRTP is set.
So as on now with GS gxv3140 SRTP is working nice.
got lot of info on this page itself.

But have few doubts...as far as proxying is concerned SRTP is working. but is i want my media to pass through asterisk as in case of LI, asterisk is not making calls.

Problem of lifetime support is an issue, and if i comment that portion and go ahead then asterisk forward new crypt value without |2^32 at end to other device... and Grandstream at other end send 48X something saying pls chose diff vocoder....

How can i make astersik handle SRTP as well....with |2^32 stuff in end.... coz i need this as well for LI.
Any inputs will be appreciated.

Cheers
Hemanshu

By: Hemanshu Patel (hemanshurpatel) 2010-03-08 07:14:04.000-0600

as far as handling SRTP data by asterisk is concerned i could make only audio calls....
it gives 488 in case when i enable video.
With video it fails.but it works nice with audio.
can anyone help in finding the solution with video.
i had also implement the same logic with asterisk 1.4.0, in that not even audio works if i ask asterisk to handle to data. Proxying thing work great.

By: Hemanshu Patel (hemanshurpatel) 2010-03-09 02:40:17.000-0600

one more thing.....
this branch that we are using encodes SRTP only or what?
i mean i can see that my Grandstream gvx3140 sends crypto tags two times one after audio parameters and one for video parameters, while asterisk include only one tag....
Is anyone following this page? and having same issues.....

By: Hemanshu Patel (hemanshurpatel) 2010-03-09 07:14:11.000-0600

i was referring audio only in previous post
we encrypt audio only and no video?

By: Terry Wilson (twilson) 2010-03-09 08:37:23.000-0600

I have code that I thought would handle video, but if it doesn't, then I'll have to look at it. It isn't something I've tested because I have no video phones.

By: Hemanshu Patel (hemanshurpatel) 2010-03-09 22:24:37.000-0600

thanks twilson for replying....
lolz...someone is maintaining at least....

Well when i use both my grandstream video phones with kamailio for getting working log of sip message flow for making it work with asterisk.... i got that kamailio was forwarding both crypto message, for audio as well as for video.... while in our case asterisk forwards only one crypto message.... and so my other grandstream phone was discarding the message as it is asked to go fot SRTP forcefully and it was receving a SDP packet where protocol was SAVP but still there was no a=crypto tag after video's h264 tag....

i applied modifications and make asterisk also proxying the sip message even in case of SRTP, and it works great, but when i asked astersik to handle the SRTP data, after adding the hacks so that call was established by adding one more crypto tag for video as well...
but in this case i am getting audio only....for first few frames i am getting video as well and then suddenly it started giving message as below:

[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication failure                                                    
[Mar 10 09:51:47] DEBUG[3371]: res_srtp.c:397 res_srtp_unprotect: SRTP unprotect: authentication  failure                                                    


now how can authentication work for first say 2 to 6 frames(just estimate...), and then authentication failure....
Any idea about it?

By: Avi Krivorot (krivorot) 2010-03-16 14:05:09

Will this new feature work with Microsoft OCS? I tried the latest patch (asterisk-1.6.2.0-rc3-srtp.patch) and i am getting some errors regarding crypto lifetime:

sdp_crypto_process: Crypto life time unsupported

Call Details:

Connected to Asterisk 1.6.2.0-rc3 currently running on fedora10 (pid = 29437)

[Mar 16 15:02:08] NOTICE[2219]: sdp_crypto.c:232 sdp_crypto_process: Crypto life time unsupported: crypto:1 AES_CM_128_HMAC_SHA1_80 inline:m69ssM1LEXML1/7GZ0cd7bPWGt5UnnVswQ9EiIN8|2^31|1:1
[Mar 16 15:02:08] NOTICE[2219]: sdp_crypto.c:242 sdp_crypto_process: SRTP crypto offer not acceptable
[Mar 16 15:02:08] NOTICE[2219]: sdp_crypto.c:232 sdp_crypto_process: Crypto life time unsupported: crypto:2 AES_CM_128_HMAC_SHA1_80 inline:XgxEn1IZDTVqKE7S0eYakaNBw2z1qnB+D9znoiUo|2^31
[Mar 16 15:02:08] NOTICE[2219]: sdp_crypto.c:242 sdp_crypto_process: SRTP crypto offer not acceptable
[Mar 16 15:02:08] WARNING[2219]: chan_sip.c:8403 process_sdp: Can't provide secure audio requested in SDP offer

By: Leif Madsen (lmadsen) 2010-03-16 14:20:05

Update the branch location in the information at the top. For those of you testing, please use the updated branch location in the description at the top of this issue.

http://origsvn.digium.com/svn/asterisk/team/group/srtp_reboot

By: Leif Madsen (lmadsen) 2010-03-16 14:21:36

krivorot: please use the branch in the above note, and not the patches.

By: Avi Krivorot (krivorot) 2010-03-16 14:53:36

The link is not working, should it be http://svn...

thanks Imadsen.

By: Avi Krivorot (krivorot) 2010-03-16 15:42:12

I am getting the same error with the svn version:

Connected to Asterisk SVN-group-srtp_reboot-r252779-/trunk currently running on fedora10 (pid = 23362)

[Mar 16 16:39:59] NOTICE[23435]: sip/sdp_crypto.c:238 sdp_crypto_process: Crypto life time unsupported: crypto:1 AES_CM_128_HMAC_SHA1_80 inline:UbCjOvvXWKN44fvzNQHK6Fdso+a2k4+b5LHVIrtK|2^31|1:1
[Mar 16 16:39:59] NOTICE[23435]: sip/sdp_crypto.c:248 sdp_crypto_process: SRTP crypto offer not acceptable
[Mar 16 16:39:59] NOTICE[23435]: sip/sdp_crypto.c:238 sdp_crypto_process: Crypto life time unsupported: crypto:2 AES_CM_128_HMAC_SHA1_80 inline:RYpLrjw/JiXx9vDMBfFcfvrNXSGajM4NbVOeu68k|2^31
[Mar 16 16:39:59] NOTICE[23435]: sip/sdp_crypto.c:248 sdp_crypto_process: SRTP crypto offer not acceptable
[Mar 16 16:39:59] WARNING[23435]: chan_sip.c:7079 process_sdp: Can't provide secure audio requested in SDP offer

By: Leif Madsen (lmadsen) 2010-03-16 16:08:40

Oops, thought I had updated that link, but I guess it didn't take. Link updated.

By: Hemanshu Patel (hemanshurpatel) 2010-03-17 01:30:19

Further to my testing..i put so many debugging info into code.
and now i amazed seeing that for stream few frames are authenticated successfully and few frames are failed, even though srtp_t session is same.

see here

ar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f0010f40  with Session:?{??                      
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:398 res_srtp_unprotect: Hemanshu: Unprotecting failed srtp:f0010f40 with Session:?{??                            
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:398 res_srtp_unprotect: Hemanshu: Unprotecting failed srtp:f0010f40 with Session:?{??                            
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f0010f40  with Session:?{??                      
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:398 res_srtp_unprotect: Hemanshu: Unprotecting failed srtp:f0010f40 with Session:?{??                            
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f0010f40  with Session:?{??                      
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f0010f40  with Session:?{??                      
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:398 res_srtp_unprotect: Hemanshu: Unprotecting failed srtp:f0010f40 with Session:?{??                            
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f000e450  with Session:??                        
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f00080c0  with Session:?|??                      
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f000e450  with Session:??                        
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f0010f40  with Session:?{??                      
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f000e450  with Session:??                        
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:398 res_srtp_unprotect: Hemanshu: Unprotecting failed srtp:f0010f40 with Session:?{??                            
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:398 res_srtp_unprotect: Hemanshu: Unprotecting failed srtp:f0010f40 with Session:?{??                            
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f0010f40  with Session:?{??                      
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:398 res_srtp_unprotect: Hemanshu: Unprotecting failed srtp:f0010f40 with Session:?{??                            
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f000e450  with Session:??                        
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f000e450  with Session:??                        
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:398 res_srtp_unprotect: Hemanshu: Unprotecting failed srtp:f0010f40 with Session:?{??                            
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f000e450  with Session:??                        
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f000e450  with Session:??                        
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f000e450  with Session:??                        
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:398 res_srtp_unprotect: Hemanshu: Unprotecting failed srtp:f0010f40 with Session:?{??                            
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f000e450  with Session:??                        
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:398 res_srtp_unprotect: Hemanshu: Unprotecting failed srtp:f000abf0 with Session:??                              
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f00080c0  with Session:?|??                      
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f000abf0  with Session:0r??                      
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f00080c0  with Session:?|??                      
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:398 res_srtp_unprotect: Hemanshu: Unprotecting failed srtp:f000abf0 with Session:0r??                            
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f00080c0  with Session:?|??                      
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f000abf0  with Session:0r??                      
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f00080c0  with Session:?|??                      
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f000abf0  with Session:0r??                      
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f00080c0  with Session:?|??                      
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:398 res_srtp_unprotect: Hemanshu: Unprotecting failed srtp:f000abf0 with Session:0r??                            
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f00080c0  with Session:?|??                      
[Mar 17 11:52:22] DEBUG[28454]: res_srtp.c:403 res_srtp_unprotect: Hemanshu: Unprotecting successfull srtp:f000abf0  with Session:0r??              


Check the address of srtp and session stuff, for some frames they are successful and for some they are not.

is this phone's issue?
what could be the problem?
From server end i am not seeing any problem as such, and i dont have any other phones apart from GrandStream to test SRTP stuff.

By: Hemanshu Patel (hemanshurpatel) 2010-03-17 01:33:33

any these frames are video frames, all audio frames are unprotected successfully, its only video frames where asterisk gives unprotecting failed message.

By: Terry Wilson (twilson) 2010-03-22 18:37:45

hemanshurpatel: I have made an update which *may* fix video for you, but I think it is a bit hacky and may need some more work. Could you update your srtp_reboot checkout and try again? Thanks.

krivorot: Currently specifying the key lifetime is not supported. I'm not sure whether it will be supported before we commit or not. You can try to remove the continue; line after the log message you are getting in channels/sip/sdp_crypto.c around line239 and see how your client works until we can add support for it.

By: Hemanshu Patel (hemanshurpatel) 2010-03-22 23:59:22

hi twilson
What you are doing is using the same a_crypto tag two times for audio and video. I have already tried this and even created a complete new v_crypto tag.
in both cases result was same as above.

in channel/chan_sip.c line no 25086 in function call
sdp_crypto_process(p->srtp->crypto, a, p->rtp)

Now this function will set the crypto for audio rtp session only and so the ssrc value which is used to identify the encrypted session.
But when sip_rtp_read function is called, it passes p->rtp and p->vrtp for audio and video. now as we setup crypto for p->rtp only in your case, video packets wont work.i havent test this new srtp_reboot, just was going through code.

By: Terry Wilson (twilson) 2010-03-23 08:03:55

hemanshurpatel: yeah, I was pretty sure that was the case...but I thought I might get lucky somehow. I'll go ahead and add real support for multiple sessions.

By: Terry Wilson (twilson) 2010-03-24 21:18:00

hermanshurpatel: Ok, I've tried to implement multi-session support for the srtp_reboot branch. Testing was done to make sure that a normal SRTP call would go through, but
I don't have any video phones that support SRTP that don't crash when I make an SRTP call, so no promises
yet that this completely works. Can you test?

By: Hemanshu Patel (hemanshurpatel) 2010-03-25 23:12:29

yeah sure twilson...
but i am bit occupied till this weekend, so will be able to test after that only.
thanks for adding the support.
i also had added support for another line and so my calls with video were going through....not i need to see that the video packets should also get authenticated/unprotecting.
as in my case audio works great and video bit choppy....
any ways will let u know once i finish testing

By: Hemanshu Patel (hemanshurpatel) 2010-03-29 00:53:10

Problem..problem....problem

Mar 30 11:21:12] WARNING[13502]: res_rtp_asterisk.c:1957 ast_rtp_read: RTP Read error: Success. Hanging up.

By: Terry Wilson (twilson) 2010-04-22 12:19:38

hemanshurpatel: could you turn on debug logging and give me the error that occurs? It should look like "SRTP unprotect: error msg". Most likely just before the WARNING you showed.

By: Terry Wilson (twilson) 2010-04-26 16:04:27

hemanshurpatel: could you also post a packet capture for the call that fails (assuming you aren't also using TLS) in addition to that debug output?

By: Terry Wilson (twilson) 2010-04-27 17:03:41

hemanshurpatel: I just tested with a Poylcom VVX-1500 and SRTP audio + SRTP video appears to work fine for it.

By: savage1985 (savage1985) 2010-04-29 01:22:03

HI  what is the diffrences between srtp_mikey ,srtp_reboot and srtp in
http://svn.asterisk.org/svn/asterisk/team/group/ ?

if i want test srtp feature ,any changes are needed in extensions.conf and sip.conf ?

thank u very much!

By: Terry Wilson (twilson) 2010-04-29 09:13:17

save1985: use srtp_reboot. srtp_mikey is there for historical purposes. if your phone calls in with an SRTP offer, Asterisk will set up the call with encryption if possible. If you want to check via the dialplan whether a call has encrypted signaling or media, you can check with CHANNEL(secure_signaling) and CHANNEL(secure_media). If you want to force any outgoing channels to have secure signaling and media, you can use Set(CHANNEL(secure_bridge_signaling)=1) and Set(CHANNEL(secure_bridge_media)=1). If you want all calls to and from a particular SIP peer to be encrypted, you can put "encryption=yes" in sip.conf.

By: savage1985 (savage1985) 2010-04-29 21:27:04

3ks, another question , where should i set CHANNEL(secure_signaling) and CHANNEL(secure_media )  ,in extensions.conf or sip.conf

By: Terry Wilson (twilson) 2010-04-29 23:24:54

You don't set CHANNEL(secure_signaling/media), they are read-only. You can set CHANNEL(secure_bridge_signaling/media). They are dialplan functions and are used in extensions.conf. Signaling will be secure in SIP by nature of setting up TLS (which is left as an exercise to the reader--google it).

By: joels (joels) 2010-05-01 06:49:33

Tested with several Nokia models and eyebeam 1.5.19.4 using
Asterisk SVN-group-srtp_reboot-r259968M-/trunk

Nokia E72 with Firmware 31.023 TLS & SRTP perfect.
Nokia E72 <-> Nokia E72  TLS & SRTP perfect.
Nokia E72 <-> eyebeam and vice versa perfect.



By: Leif Madsen (lmadsen) 2010-05-04 12:34:07

Huh! I didn't realize the Nokia firmware supported SRTP and TLS! I will certainly have to try this now! Thanks Joels!

By: joels (joels) 2010-05-04 13:21:00

If you need further info, don't hesitate ;-)

It's a good one, isn't it!

By: joels (joels) 2010-05-05 01:24:10

Call from a Nokia E72 (31.023) -> eyeBeam:

<--- SIP read from TLS:86.96.229.88:55324 --->
INVITE sips:5553000@sec.maeg.com;user=phone SIP/2.0
Route: <sips:sec.maeg.com:6000;lr;transport=TCP>
Via: SIP/2.0/TLS 192.168.178.104:5060;branch=z9hG4bK3b632jceelhc6trv07mgkmi;rport
From: <sip:5553001@sec.maeg.com>;tag=9ai528m7n9hc642907mg
To: <sips:5553000@sec.maeg.com;user=phone>
Contact: <sips:4cWDAREngqRPezacKC47@192.168.178.104;transport=TCP>
Supported: precondition,100rel,timer,sec-agree
CSeq: 3096 INVITE
Call-ID: yflivjE3oIccB07J2B7_JOYGHFZeU9
Allow: UPDATE,PRACK,SUBSCRIBE,REFER,NOTIFY,INVITE,ACK,CANCEL,OPTIONS,BYE
User-Agent: Nokia RM-530 031.023 00-BD-3A-00-10-8C
Expires: 120
Privacy: None
Session-Expires: 300
Max-Forwards: 70
Content-Type: application/sdp
Accept-Language: de
Content-Length: 524

v=0
o=5553001 63441302944196250 63441302944196250 IN IP4 192.168.178.104
s=-
c=IN IP4 192.168.178.104
t=0 0
m=audio 16384 RTP/SAVP 8 18 98
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:VGI3Y2N5ZUFhM015UnZTZ0VnakVXeWJXdjRJQWhV
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:ZVBBUmhWQlc2SWJzTWl5Ml9Hc1psMFRBZEc0Q3VS
a=curr:sec e2e none
a=des:sec optional e2e sendrecv
a=rtpmap:8 PCMA/8000
a=ptime:20
a=maxptime:200
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:98 telephone-event/8000
a=fmtp:98 0-15

<------------->
--- (18 headers 18 lines) ---
Sending to 86.96.229.88 : 5060 (no NAT)
Using INVITE request as basis request - yflivjE3oIccB07J2B7_JOYGHFZeU9
Found peer '5553001' for '5553001' from 86.96.229.88:55324
81-89-105-60*CLI>
<--- Reliably Transmitting (NAT) to 86.96.229.88:55324 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 192.168.178.104:5060;branch=z9hG4bK3b632jceelhc6trv07mgkmi;received=86.96.229.88;rport=55324
From: <sip:5553001@sec.maeg.com>;tag=9ai528m7n9hc642907mg
To: <sips:5553000@sec.maeg.com;user=phone>;tag=as59fd410d
Call-ID: yflivjE3oIccB07J2B7_JOYGHFZeU9
CSeq: 3096 INVITE
Server: MAEG TLS SEC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="maeg.com", nonce="6ae9216f"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog 'yflivjE3oIccB07J2B7_JOYGHFZeU9' in 32000 ms (Method: INVITE)
81-89-105-60*CLI>
<--- SIP read from TLS:86.96.229.88:55324 --->
ACK sips:5553000@sec.maeg.com;user=phone SIP/2.0
Via: SIP/2.0/TLS 192.168.178.104:5060;branch=z9hG4bK3b632jceelhc6trv07mgkmi;rport
Route: <sips:sec.maeg.com:6000;lr;transport=TCP>
From: <sip:5553001@sec.maeg.com>;tag=9ai528m7n9hc642907mg
To: <sips:5553000@sec.maeg.com;user=phone>;tag=as59fd410d
Call-ID: yflivjE3oIccB07J2B7_JOYGHFZeU9
CSeq: 3096 ACK
Supported: sec-agree
Max-Forwards: 70
Content-Length: 0


<------------->
--- (10 headers 0 lines) ---
81-89-105-60*CLI>
<--- SIP read from TLS:86.96.229.88:55324 --->
INVITE sips:5553000@sec.maeg.com;user=phone SIP/2.0
Route: <sips:sec.maeg.com:6000;lr;transport=TCP>
Via: SIP/2.0/TLS 192.168.178.104:5060;branch=z9hG4bKrvljqrmjo82unjm3e0p77j3;rport
From: <sip:5553001@sec.maeg.com>;tag=9ai528m7n9hc642907mg
To: <sips:5553000@sec.maeg.com;user=phone>
Contact: <sips:4cWDAREngqRPezacKC47@192.168.178.104;transport=TCP>
Supported: precondition,100rel,timer,sec-agree
CSeq: 3097 INVITE
Call-ID: yflivjE3oIccB07J2B7_JOYGHFZeU9
Allow: UPDATE,PRACK,SUBSCRIBE,REFER,NOTIFY,INVITE,ACK,CANCEL,OPTIONS,BYE
User-Agent: Nokia RM-530 031.023 00-BD-3A-00-10-8C
Expires: 120
Privacy: None
Session-Expires: 300
Max-Forwards: 70
Authorization: Digest realm="maeg.com",nonce="6ae9216f",algorithm=MD5,username="5553001",uri="sips:5553000@sec.maeg.com;user=phone",response="ee9ec3e329301a764d7b54cf61d08586"
Content-Type: application/sdp
Accept-Language: de
Content-Length: 524

v=0
o=5553001 63441302944196250 63441302944196250 IN IP4 192.168.178.104
s=-
c=IN IP4 192.168.178.104
t=0 0
m=audio 16384 RTP/SAVP 8 18 98
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:VGI3Y2N5ZUFhM015UnZTZ0VnakVXeWJXdjRJQWhV
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:ZVBBUmhWQlc2SWJzTWl5Ml9Hc1psMFRBZEc0Q3VS
a=curr:sec e2e none
a=des:sec optional e2e sendrecv
a=rtpmap:8 PCMA/8000
a=ptime:20
a=maxptime:200
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:98 telephone-event/8000
a=fmtp:98 0-15

<------------->
--- (19 headers 18 lines) ---
Sending to 86.96.229.88 : 55324 (NAT)
Using INVITE request as basis request - yflivjE3oIccB07J2B7_JOYGHFZeU9
Found peer '5553001' for '5553001' from 86.96.229.88:55324
Found RTP audio format 8
Found RTP audio format 18
Found RTP audio format 98
Found audio description format PCMA for ID 8
Found audio description format G729 for ID 18
Found audio description format telephone-event for ID 98
Capabilities: us - 0x8 (alaw), peer - audio=0x108 (alaw|g729)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x8 (alaw)
Non-codec capabilities (dtmf): us - 0x0 (nothing), peer - 0x1 (telephone-event|), combined - 0x0 (nothing)
Peer audio RTP is at port 192.168.178.104:16384
Looking for 5553000 in from-sip (domain sec.maeg.com)
list_route: hop: <sips:4cWDAREngqRPezacKC47@192.168.178.104;transport=TCP>
81-89-105-60*CLI>
<--- Transmitting (NAT) to 86.96.229.88:55324 --->
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 192.168.178.104:5060;branch=z9hG4bKrvljqrmjo82unjm3e0p77j3;received=86.96.229.88;rport=55324
From: <sip:5553001@sec.maeg.com>;tag=9ai528m7n9hc642907mg
To: <sips:5553000@sec.maeg.com;user=phone>
Call-ID: yflivjE3oIccB07J2B7_JOYGHFZeU9
CSeq: 3097 INVITE
Server: MAEG TLS SEC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Require: timer
Session-Expires: 300;refresher=uas
Contact: <sip:5553000@65.49.14.19;transport=TLS>
Content-Length: 0


<------------>
Audio is at 65.49.14.19 port 27064
Adding codec 0x8 (alaw) to SDP
Reliably Transmitting (NAT) to 86.96.229.88:50093:
INVITE sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b SIP/2.0
Via: SIP/2.0/TLS 65.49.14.19:5061;branch=z9hG4bK16f800a2;rport
Max-Forwards: 70
From: "Jochen E72 TLS UNCC" <sip:5553001@sec.maeg.com>;tag=as4ef71c16
To: <sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b>
Contact: <sip:5553001@65.49.14.19;transport=TLS>
Call-ID: 035b2c465a81dd720d193f00012f7e7d@sec.maeg.com
CSeq: 102 INVITE
User-Agent: MAEG TLS SEC
Date: Wed, 05 May 2010 06:08:40 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 280

v=0
o=MAEG 569318442 569318442 IN IP4 65.49.14.19
s=MAEG TLS
c=IN IP4 65.49.14.19
t=0 0
m=audio 27064 RTP/SAVP 8
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:4lyVB4wPy9uP1olUfUDmRyGNC+u8wGxNWLMtnl70

---
81-89-105-60*CLI>
<--- SIP read from TLS:86.96.229.88:50093 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 65.49.14.19:5061;branch=z9hG4bK16f800a2;rport=5061
Contact: <sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b>
To: <sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b>;tag=1e0be518
From: "Jochen E72 TLS UNCC"<sip:5553001@sec.maeg.com>;tag=as4ef71c16
Call-ID: 035b2c465a81dd720d193f00012f7e7d@sec.maeg.com
CSeq: 102 INVITE
User-Agent: eyeBeam release 1102q stamp 51814
Content-Length: 0


<------------->
--- (9 headers 0 lines) ---
81-89-105-60*CLI>
<--- Transmitting (NAT) to 86.96.229.88:55324 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 192.168.178.104:5060;branch=z9hG4bKrvljqrmjo82unjm3e0p77j3;received=86.96.229.88;rport=55324
From: <sip:5553001@sec.maeg.com>;tag=9ai528m7n9hc642907mg
To: <sips:5553000@sec.maeg.com;user=phone>;tag=as48b920d0
Call-ID: yflivjE3oIccB07J2B7_JOYGHFZeU9
CSeq: 3097 INVITE
Server: MAEG TLS SEC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Require: timer
Session-Expires: 300;refresher=uas
Contact: <sip:5553000@65.49.14.19;transport=TLS>
Content-Length: 0


<------------>
81-89-105-60*CLI>
<--- SIP read from TLS:86.96.229.88:50093 --->



<------------->
81-89-105-60*CLI>
<--- SIP read from TLS:86.96.229.88:50093 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 65.49.14.19:5061;branch=z9hG4bK16f800a2;rport=5061
Contact: <sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b>
To: <sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b>;tag=1e0be518
From: "Jochen E72 TLS UNCC"<sip:5553001@sec.maeg.com>;tag=as4ef71c16
Call-ID: 035b2c465a81dd720d193f00012f7e7d@sec.maeg.com
CSeq: 102 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: eyeBeam release 1102q stamp 51814
Content-Length: 217

v=0
o=- 8 2 IN IP4 192.168.178.63
s=CounterPath eyeBeam 1.5
c=IN IP4 192.168.178.63
t=0 0
m=audio 19038 RTP/SAVP 8
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:0CpsUAIJO2Ww0QMEE9UkDtZQ9+FOPrJTVnLjVQsS
a=sendrecv

<------------->
--- (11 headers 8 lines) ---
Found RTP audio format 8
Capabilities: us - 0x8 (alaw), peer - audio=0x8 (alaw)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x8 (alaw)
Non-codec capabilities (dtmf): us - 0x0 (nothing), peer - 0x0 (nothing), combined - 0x0 (nothing)
Peer audio RTP is at port 192.168.178.63:19038
list_route: hop: <sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b>
set_destination: Parsing <sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b> for address/port to send to
set_destination: set destination to 86.96.229.88, port 50093
Transmitting (NAT) to 86.96.229.88:50093:
ACK sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b SIP/2.0
Via: SIP/2.0/TLS 65.49.14.19:5061;branch=z9hG4bK76b0b58b;rport
Max-Forwards: 70
From: "Jochen E72 TLS UNCC" <sip:5553001@sec.maeg.com>;tag=as4ef71c16
To: <sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b>;tag=1e0be518
Contact: <sip:5553001@65.49.14.19;transport=TLS>
Call-ID: 035b2c465a81dd720d193f00012f7e7d@sec.maeg.com
CSeq: 102 ACK
User-Agent: MAEG TLS SEC
Content-Length: 0


---
Audio is at 65.49.14.19 port 30144
Adding codec 0x8 (alaw) to SDP

<--- Reliably Transmitting (NAT) to 86.96.229.88:55324 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.168.178.104:5060;branch=z9hG4bKrvljqrmjo82unjm3e0p77j3;received=86.96.229.88;rport=55324
From: <sip:5553001@sec.maeg.com>;tag=9ai528m7n9hc642907mg
To: <sips:5553000@sec.maeg.com;user=phone>;tag=as48b920d0
Call-ID: yflivjE3oIccB07J2B7_JOYGHFZeU9
CSeq: 3097 INVITE
Server: MAEG TLS SEC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Require: timer
Session-Expires: 300;refresher=uas
Contact: <sip:5553000@65.49.14.19;transport=TLS>
Content-Type: application/sdp
Content-Length: 280

v=0
o=MAEG 809561325 809561325 IN IP4 65.49.14.19
s=MAEG TLS
c=IN IP4 65.49.14.19
t=0 0
m=audio 30144 RTP/SAVP 8
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:rqDJHu7XQpTyamgsQeoA9KkgTOfbGOLHvW87nyD9

<------------>
81-89-105-60*CLI>
<--- SIP read from TLS:86.96.229.88:55324 --->
ACK sip:5553000@65.49.14.19;transport=TLS SIP/2.0
Via: SIP/2.0/TLS 192.168.178.104:5060;branch=z9hG4bKtrcnhoia12oprjm3qlh3cs3;rport
To: <sips:5553000@sec.maeg.com;user=phone>;tag=as48b920d0
From: <sip:5553001@sec.maeg.com>;tag=9ai528m7n9hc642907mg
Call-ID: yflivjE3oIccB07J2B7_JOYGHFZeU9
CSeq: 3097 ACK
Supported: sec-agree
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INVITE,ACK,CANCEL,OPTIONS,BYE
Max-Forwards: 70
Authorization: Digest realm="maeg.com",nonce="6ae9216f",algorithm=MD5,username="5553001",uri="sips:5553000@sec.maeg.com;user=phone",response="ee9ec3e329301a764d7b54cf61d08586"
Content-Length: 0


<------------->
--- (11 headers 0 lines) ---
[May  5 06:09:00] NOTICE[30684]: res_rtp_asterisk.c:2128 ast_rtp_read: Unknown RTP codec 120 received from '86.96.229.88'
81-89-105-60*CLI>
<--- SIP read from TLS:86.96.229.88:55324 --->
BYE sip:5553000@65.49.14.19;transport=TLS SIP/2.0
Via: SIP/2.0/TLS 192.168.178.104:5060;branch=z9hG4bKqkiv8sk20phc73vsv576rsl;rport
To: <sips:5553000@sec.maeg.com;user=phone>;tag=as48b920d0
From: <sip:5553001@sec.maeg.com>;tag=9ai528m7n9hc642907mg
Call-ID: yflivjE3oIccB07J2B7_JOYGHFZeU9
CSeq: 3098 BYE
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,INVITE,ACK,CANCEL,OPTIONS,BYE
Max-Forwards: 70
Content-Length: 0


<------------->
--- (9 headers 0 lines) ---
Sending to 86.96.229.88 : 55324 (NAT)

<--- Transmitting (NAT) to 86.96.229.88:55324 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.168.178.104:5060;branch=z9hG4bKqkiv8sk20phc73vsv576rsl;received=86.96.229.88;rport=55324
From: <sip:5553001@sec.maeg.com>;tag=9ai528m7n9hc642907mg
To: <sips:5553000@sec.maeg.com;user=phone>;tag=as48b920d0
Call-ID: yflivjE3oIccB07J2B7_JOYGHFZeU9
CSeq: 3098 BYE
Server: MAEG TLS SEC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '035b2c465a81dd720d193f00012f7e7d@sec.maeg.com' in 18112 ms (Method: INVITE)
set_destination: Parsing <sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b> for address/port to send to
set_destination: set destination to 86.96.229.88, port 50093
Reliably Transmitting (NAT) to 86.96.229.88:50093:
BYE sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b SIP/2.0
Via: SIP/2.0/TLS 65.49.14.19:5061;branch=z9hG4bK10e987bd;rport
Max-Forwards: 70
From: "Jochen E72 TLS UNCC" <sip:5553001@sec.maeg.com>;tag=as4ef71c16
To: <sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b>;tag=1e0be518
Call-ID: 035b2c465a81dd720d193f00012f7e7d@sec.maeg.com
CSeq: 103 BYE
User-Agent: MAEG TLS SEC
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


---
81-89-105-60*CLI>
<--- SIP read from TLS:86.96.229.88:50093 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 65.49.14.19:5061;branch=z9hG4bK10e987bd;rport=5061
Contact: <sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b>
To: <sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b>;tag=1e0be518
From: "Jochen E72 TLS UNCC"<sip:5553001@sec.maeg.com>;tag=as4ef71c16
Call-ID: 035b2c465a81dd720d193f00012f7e7d@sec.maeg.com
CSeq: 103 BYE
User-Agent: eyeBeam release 1102q stamp 51814
Content-Length: 0


<------------->
--- (9 headers 0 lines) ---
Really destroying SIP dialog '035b2c465a81dd720d193f00012f7e7d@sec.maeg.com' Method: INVITE
Really destroying SIP dialog 'yflivjE3oIccB07J2B7_JOYGHFZeU9' Method: BYE
81-89-105-60*CLI>
<--- SIP read from TLS:86.96.229.88:50093 --->



<------------->
Reliably Transmitting (NAT) to 86.96.229.88:50093:
OPTIONS sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b SIP/2.0
Via: SIP/2.0/TLS 65.49.14.19:5061;branch=z9hG4bK3497fb47;rport
Max-Forwards: 70
From: "asterisk" <sip:asterisk@sec.maeg.com>;tag=as4f0d4c84
To: <sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b>
Contact: <sip:asterisk@65.49.14.19;transport=TLS>
Call-ID: 2343369555c993812d027d3b58728dac@sec.maeg.com
CSeq: 102 OPTIONS
User-Agent: MAEG TLS SEC
Date: Wed, 05 May 2010 06:09:15 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


---
81-89-105-60*CLI>
<--- SIP read from TLS:86.96.229.88:50093 --->
SIP/2.0 200 OK
Via: SIP/2.0/TLS 65.49.14.19:5061;branch=z9hG4bK3497fb47;rport=5061
Contact: <sip:192.168.178.63:41141;transport=TLS>
To: <sip:5553000@86.96.229.88:50093;transport=TLS;rinstance=ce2ef0e4a7a3494b>;tag=a6647e1e
From: "asterisk"<sip:asterisk@sec.maeg.com>;tag=as4f0d4c84
Call-ID: 2343369555c993812d027d3b58728dac@sec.maeg.com
CSeq: 102 OPTIONS
Accept: application/sdp
Accept-Language: en
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: eyeBeam release 1102q stamp 51814
Content-Length: 0


<------------->
--- (12 headers 0 lines) ---
81-89-105-60*CLI>
<--- SIP read from TLS:86.96.229.88:50093 --->
SUBSCRIBE sip:5553000@sec.maeg.com:5061 SIP/2.0
Via: SIP/2.0/TLS 192.168.178.63:41141;branch=z9hG4bK-d8754z-e87db67f1474f45a-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:5553000@86.96.229.88:50093;transport=TLS>
To: "MAEG ENCRYPTED"<sip:5553000@sec.maeg.com:5061>
From: "MAEG ENCRYPTED"<sip:5553000@sec.maeg.com:5061>;tag=0d216377
Call-ID: NDQ5MTU5MmZiM2VlMjk2YjY4ZjYzNWJjZWI5MTczMDk.
CSeq: 1 SUBSCRIBE
Expires: 300
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: eyeBeam release 1102q stamp 51814
Event: message-summary
Content-Length: 0


<------------->
--- (13 headers 0 lines) ---
Creating new subscription
Sending to 86.96.229.88 : 41141 (no NAT)
list_route: hop: <sip:5553000@86.96.229.88:50093;transport=TLS>
Found peer '5553000' for '5553000' from 86.96.229.88:50093

<--- Transmitting (NAT) to 86.96.229.88:50093 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 192.168.178.63:41141;branch=z9hG4bK-d8754z-e87db67f1474f45a-1---d8754z-;received=86.96.229.88;rport=50093
From: "MAEG ENCRYPTED"<sip:5553000@sec.maeg.com:5061>;tag=0d216377
To: "MAEG ENCRYPTED"<sip:5553000@sec.maeg.com:5061>;tag=as5bec72bd
Call-ID: NDQ5MTU5MmZiM2VlMjk2YjY4ZjYzNWJjZWI5MTczMDk.
CSeq: 1 SUBSCRIBE
Server: MAEG TLS SEC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="maeg.com", nonce="3e0e64a3"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog 'NDQ5MTU5MmZiM2VlMjk2YjY4ZjYzNWJjZWI5MTczMDk.' in 17920 ms (Method: SUBSCRIBE)
Really destroying SIP dialog '2343369555c993812d027d3b58728dac@sec.maeg.com' Method: OPTIONS
81-89-105-60*CLI>
<--- SIP read from TLS:86.96.229.88:50093 --->
SUBSCRIBE sip:5553000@sec.maeg.com:5061 SIP/2.0
Via: SIP/2.0/TLS 192.168.178.63:41141;branch=z9hG4bK-d8754z-0a5ca014d30f4762-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:5553000@86.96.229.88:50093;transport=TLS>
To: "MAEG ENCRYPTED"<sip:5553000@sec.maeg.com:5061>
From: "MAEG ENCRYPTED"<sip:5553000@sec.maeg.com:5061>;tag=0d216377
Call-ID: NDQ5MTU5MmZiM2VlMjk2YjY4ZjYzNWJjZWI5MTczMDk.
CSeq: 2 SUBSCRIBE
Expires: 300
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: eyeBeam release 1102q stamp 51814
Authorization: Digest username="5553000",realm="maeg.com",nonce="3e0e64a3",uri="sip:5553000@sec.maeg.com:5061",response="8d8381f5cdca8138a8e8f5219d58991f",algorithm=MD5
Event: message-summary
Content-Length: 0


<------------->
--- (14 headers 0 lines) ---
Creating new subscription
Sending to 86.96.229.88 : 50093 (NAT)
Found peer '5553000' for '5553000' from 86.96.229.88:50093

<--- Transmitting (NAT) to 86.96.229.88:50093 --->
SIP/2.0 404 Not found (no mailbox)
Via: SIP/2.0/TLS 192.168.178.63:41141;branch=z9hG4bK-d8754z-0a5ca014d30f4762-1---d8754z-;received=86.96.229.88;rport=50093
From: "MAEG ENCRYPTED"<sip:5553000@sec.maeg.com:5061>;tag=0d216377
To: "MAEG ENCRYPTED"<sip:5553000@sec.maeg.com:5061>;tag=as5bec72bd
Call-ID: NDQ5MTU5MmZiM2VlMjk2YjY4ZjYzNWJjZWI5MTczMDk.
CSeq: 2 SUBSCRIBE
Server: MAEG TLS SEC
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

By: joels (joels) 2010-05-05 04:22:29

Nokia's info:

• RFC 2246 The TLS Protocol Version 1.0:
o SIP stack does not support incoming TLS connections. Thus proxies/registrars must support persistent TLS connections and be able to use existing connections to deliver SIP requests to the clients (connection reuse).
o The following cipher suites may be used when setting up the TLS connection for SIP:
a. TLS_RSA_WITH_AES_256_CBC_SHA
b. TLS_RSA_WITH_AES_128_CBC_SHA
c. TLS_RSA_WITH_3DES_EDE_CBC_SHA
d. TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
e. TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
f. TLS_RSA_WITH_RC4_128_SHA
g. TLS_RSA_WITH_RC4_128_MD5
h. TLS_RSA_WITH_DES_CBC_SHA
i. TLS_DHE_DSS_WITH_DES_CBC_SHA
j. TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
k. TLS_RSA_EXPORT_WITH_RC4_40_MD5
l. TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
m. TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
• RFC 3262 Reliability of Provisional Responses in the Session Initiation Protocol (SIP):
o Secure VoIP session establishment using security preconditions uses provisional responses sent by the UAS before the UAC has sent the SIP message "PRACK". Implementation follows RFC 3262 to achieve end-to-end reliability in transmitting such responses. Non-100 provisional responses are sent reliably if the initial INVITE request contained either a SUPPORTED or REQUIRE header field with the option tag "100rel".
• RFC 3711 The Secure Real-Time Transport Protocol (SRTP):
o The SRTP use is signaled by either having defined secure RTP transport "RTP/SAVP" in an SDP media line or a=crypto as a media attribute in an SDP document. "RTP/SAVPF" is not supported.
o Implementation supports RTP/RTCP stream authentication and encryption with replay protection according to RFC 3711:
a. Same master key is shared with RTP/RTCP streams.
b. Section 8.1.1 Use of the <From, To> for re-keying is not supported.
• RFC 4568 Session Description Protocol Security Descriptions for Media Streams:
o SDP attribute "crypto" is used to signal and negotiate cryptographic parameters for media streams. This negotiation is secured by TLS.
o Implementation supports security descriptions according to RFC 4568 with the following restrictions:
Implementation Specifications for Nokia S60 VoIP 17
Forum.Nokia.com
a. The following crypto suites are supported: AES_CM_128_HMAC_SHA1_80 (offered as default), F8_128_HMAC_SHA1_80 (supported if offered in the initial INVITE), AES_CM_128_HMAC_SHA1_32 (supported if offered in the initial INVITE).
b. The following session parameters are supported: KDR.
c. The following session parameters are not supported: UNENCRYPTED_SRTCP, UNENCRYPTED_SRTP, UNAUTHENTICATED_SRTP, FEC_ORDER, FEC_KEY, WSH.
d. Re-keying is not recommended for IP telephony. Thus the optional lifetime field of the SRTP key parameter is not supported. Key rotation based on MKI is neither supported, though the MKI field in the SRTP key parameter is accepted if only one inline key parameter is provided with a=crypto attribute.
e. Section 6.4.2. Sharing cryptographic contexts among Sessions or SSRCs is not supported.
f. Section 7.1.4. Modifying the session: Only key parameters can be modified during the session. Initially negotiated crypto suite must remain the same through all session modifications. If new offer cannot be accepted, the old crypto parameters remain in place.
• RFC 5027 Security Preconditions for Session Description Protocol Media Streams:
o The negotiation of cryptographic parameters when establishing a secure VoIP session may take use of security preconditions, as defined in RFC 5027. The only supported precondition type is "sec". All the precondition attributes ("curr", "des", "conf") are supported as are all the precondition tags (strength, status, and direction). Strength is set as "optional" in the initial INVITE to increase interoperability with other vendors since security preconditions as a concept is published as a draft at this stage. When an offer with preconditions is received, the strength is increased to "mandatory" to prevent clipping effect and ghost calls from happening. Security descriptions may also be negotiated without using security preconditions if the other party does not support the concept.

By: savage1985 (savage1985) 2010-05-13 00:18:33

res_rtp_asterisk.so => (Asterisk RTP Stack)
Illegal instruction
while start asterisk on Linux debian121 2.6.21.1-bigsmp #1 SMP Sun Apr 29 04:38:52 CST 2007 i686 GNU/Linux

but start successfully on another machine
with info
res_rtp_asterisk.so => (Asterisk RTP Stack)
   -- Loaded PUBLIC key 'iaxtel'
   -- Loaded PUBLIC key 'freeworlddialup'


what is the reason  ???

By: iscario (iscario) 2010-05-16 02:01:42

Hi,
I gonna try to set-up srtp (and sip-tls too). Would it be possible to have a short dialplan as example ? and a sip.conf too ? (just the options which are needed to support srtp would be necessary of course)
Plus, I would like to know what sip client you use (which is able to support srtp) : i read that minisip was named in this page, but the windows installer has vanished from their website... Do you have another one to advice which support both tls and srtp ?
Thank you.

By: Digium Subversion (svnbot) 2010-06-08 00:29:09

Repository: asterisk
Revision: 268894

U   trunk/CHANGES
U   trunk/build_tools/menuselect-deps.in
U   trunk/channels/chan_iax2.c
U   trunk/channels/chan_sip.c
U   trunk/channels/sip/dialplan_functions.c
A   trunk/channels/sip/include/sdp_crypto.h
U   trunk/channels/sip/include/sip.h
A   trunk/channels/sip/include/srtp.h
A   trunk/channels/sip/sdp_crypto.c
A   trunk/channels/sip/srtp.c
U   trunk/configure
U   trunk/configure.ac
U   trunk/doc/tex/asterisk.tex
A   trunk/doc/tex/secure-calls.tex
U   trunk/funcs/func_channel.c
U   trunk/include/asterisk/autoconfig.h.in
U   trunk/include/asterisk/frame.h
U   trunk/include/asterisk/global_datastores.h
A   trunk/include/asterisk/res_srtp.h
U   trunk/include/asterisk/rtp_engine.h
U   trunk/main/asterisk.exports.in
U   trunk/main/channel.c
U   trunk/main/global_datastores.c
U   trunk/main/rtp_engine.c
U   trunk/makeopts.in
U   trunk/res/res_rtp_asterisk.c
A   trunk/res/res_srtp.c
A   trunk/res/res_srtp.exports.in

------------------------------------------------------------------------
r268894 | twilson | 2010-06-08 00:29:08 -0500 (Tue, 08 Jun 2010) | 17 lines

Add SRTP support for Asterisk

After 5 years in mantis and over a year on reviewboard, SRTP support is finally
being comitted. This includes generic CHANNEL dialplan functions that work for
getting the status of whether a call has secure media or signaling as defined
by the underlying channel technology and for setting whether or not a new
channel being bridged to a calling channel should have secure signaling or
media. See doc/tex/secure-calls.tex for examples.

Original patch by mikma, updated for trunk and revised by me.

(closes issue ASTERISK-5267)
Reported by: mikma
Tested by: twilson, notthematrix, hemanshurpatel

Review: https://reviewboard.asterisk.org/r/191/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=268894