[Home]

Summary:ASTERISK-19609: SRTP to RTP bridging with two crypto lines in SDP does not work
Reporter:Denis (xaled)Labels:
Date Opened:2012-03-30 11:15:06Date Closed:2015-02-25 16:02:33.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/SRTP Core/RTP
Versions:1.8.10.1 Frequency of
Occurrence		Constant
Related
Issues:
is related toASTERISK-24002 No audio after WebRTC callee resumes call from hold
Environment:Attachments:( 0) full.log
Description:There are some issues with bridging incoming SRTP call with two crypto line in SDP to an outgoing RTP call.

If I dial from a pbx the demo-congrats extension in the asterisk, then SRTP works and I can hear the demo sound.

If I dial from a pbx an extension that gets dialed out to another sip channel, then the session gets established, but not SRTP/RTP flows through asterisk. I can see PBX sending SRTP, but no SRTP comes from asterisk to the PBX and no RTP at all on the dial out side.

If I disable SRTP on the pbx and dial out, then bridging works just fine.

It seams like asterisk can hanle two crypto line when calling internal demo-congrats extension, but can not bridge such call.

{noformat}
Incoming call from a PBX to asterisk with two crypto lines:
<--- SIP read from TLS:10.62.150.23:49827 --->
INVITE sip:+12345678@10.62.150.68;user=phone SIP/2.0
FROM: "user"<sip:+87654321@pbx.ngn.local;user=phone>;epid=89E6832516;tag=f834316a34
TO: <sip:+12345678@10.62.150.68;user=phone>
CSEQ: 17940 INVITE
CALL-ID: 1374c9e4-8c72-4e19-898f-f928cfda3934
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 10.62.150.23:49827;branch=z9hG4bK38dcd6e3
CONTACT: <sip:pbx.ngn.local:5067;transport=Tls;ms-opaque=f3721e55bc7f9ef9>
CONTENT-LENGTH: 523
SUPPORTED: 100rel
CONTENT-TYPE: application/sdp
ALLOW: ACK
Allow: CANCEL,BYE,INVITE,PRACK,UPDATE

v=0
o=- 164 1 IN IP4 10.62.150.23
s=session
c=IN IP4 10.62.150.23
b=CT:1000
t=0 0
m=audio 49188 RTP/SAVP 97 101 13 0 8
c=IN IP4 10.62.150.23
a=rtcp:49189
a=label:Audio
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:D/WNrgIRlJGl/eNZLSThRIVb7LwMm6DMw+Uj6yfm|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:Q8Fp7ixgaQoY4oCSzPjIUm0Hp8ORT3Jw0KVX7mVA|2^31
a=sendrecv
a=rtpmap:97 RED/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ptime:20
<------------->


[Mar 30 18:02:44] DEBUG[15515] sip/sdp_crypto.c: SRTP policy activated
[Mar 30 18:02:44] DEBUG[15515] chan_sip.c: Processing media-level (audio) SDP a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:D/WNrgIRlJGl/eNZLSThRIVb7LwMm6DMw+Uj6yfm|2^31|1:1... OK.
[Mar 30 18:02:44] DEBUG[15515] chan_sip.c: We've already processed a crypto attribute, skipping 'crypto:2 AES_CM_128_HMAC_SHA1_80 inline:Q8Fp7ixgaQoY4oCSzPjIUm0Hp8ORT3Jw0KVX7mVA|2^31'
[Mar 30 18:02:44] DEBUG[15515] chan_sip.c: Processing media-level (audio) SDP a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:Q8Fp7ixgaQoY4oCSzPjIUm0Hp8ORT3Jw0KVX7mVA|2^31... UNSUPPORTED.

<--- Reliably Transmitting (no NAT) to 10.62.150.23:49827 --->
SIP/2.0 200 OK^M
Via: SIP/2.0/TLS 10.62.150.23:49827;branch=z9hG4bK38dcd6e3;received=10.62.150.23^M
From: "user"<sip:+12345678@pbx.ngn.local;user=phone>;epid=89E6832516;tag=f834316a34^M
To: <sip:+87654321@10.62.150.68;user=phone>;tag=as6a1debea^M
Call-ID: 1374c9e4-8c72-4e19-898f-f928cfda3934^M
CSeq: 17940 INVITE^M
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH^M
Supported: replaces, timer^M
Contact: <sip:+87654321@10.62.150.68:5067;transport=TLS>^M
Content-Type: application/sdp^M
Content-Length: 347^M
^M
v=0^M
o=root 698426991 698426992 IN IP4 10.62.150.68^M
s=session^M
c=IN IP4 10.62.150.68^M
t=0 0^M
m=audio 19264 RTP/SAVP 8 101^M
a=rtpmap:8 PCMA/8000^M
a=rtpmap:101 telephone-event/8000^M
a=fmtp:101 0-16^M
a=silenceSupp:off - - - -^M
a=ptime:20^M
a=sendrecv^M
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:si8OjhGNpsinTR2T6M4WGtC/Zd2o83b6zosXRiO2^M

<------------>
[Mar 30 18:02:52] DEBUG[15516][C-00000006] chan_sip.c: Trying to put 'SIP/2.0 200' onto TLS socket destined for 10.62.150.23:49827
[Mar 30 18:02:52] DEBUG[15516][C-00000006] features.c: bridge answer set, chan answer set
[Mar 30 18:02:52] DEBUG[15516][C-00000006] features.c: Removing dialed interfaces datastore on SIP/dialout-00000009 since we're bridging
{noformat}

for SRTP to work with life_time parameter I commented out following lines in sdp_crypto.c:

{code}
//                      if (lifetime) {
//                              ast_log(LOG_NOTICE, "Crypto life time unsupported: %s\n", attr);
//                              continue;
//                      }
{code}

Aterisk version: Asterisk SVN-trunk-r360886M
Comments:By: Matt Jordan (mjordan) 2012-03-30 11:29:46.504-0500

Asterisk does not support multiple crypto lines.  This is not a bug - its not something it supports at this time.  Implementing this support would be a new feature.  As such, I'm inclined to close this out as a feature request, unless there is some reason why this should be considered a bug.  Since Asterisk does not process the second crypto key, it does not surprise me that there are issues processing calls if the UA that sent two keys expected Asterisk to be using both of them (although, I'm not even really sure what that implies, since only a single key would be used to protect/unprotect a single RTP stream).

I'm not sure what UA is sending multiple crypto attributes, but if you can, you should configure it to not do so.
By: Denis (xaled) 2012-03-30 11:52:40.046-0500

Thanks for the quck reply.

If this would be a feature muliple crypto lines would not work in the scenario that I described with calling the asterisk demo extension ;)

It seams like the separate call leg handling for multiple crypto lines is working, but not the bridging bewteen the call legs. That is why I put it as a bug.

unfortunately the pbx can not be reconfigured. This would be the first thing I would do.

There is nothing wrong with multiple crypto lines as it is up to the UAS to pick one crypto line up. Asterisk does it actually correctly in the demo scenario I described.

Thanks,
Denis


By: Denis (xaled) 2012-04-02 16:10:31.398-0500

All the separate parts for bridging SRTP with multiple crypto lines in SDP to RTP are there:

1) Asterisk can handle multiple crypto lines - SRTP call from pbx to internal demo-congrats extension works.

2) RTP call from outside over asterisk to the SRTP pbx also works. Asterisk sends only one crypto line to the pbx.

Asterisk can bridge SRTP-RTP and can handle multiple crypto lines when calling internal demo.
It looks like some parameters get lost in translation during bridging of SRTP-RTP with multiple crypto lines. All the functionality is there.
By: Matt Jordan (mjordan) 2012-04-02 16:26:41.962-0500

I'm assuming by 'demo-congrats' you mean you have the default 's' extension in [demo], as delivered with extensions.conf.sample.

In that particular case, nothing is actually bridged.  There is no other channel that the SIP channel is bridged with - audio is merely passed to the SIP channel, where it is protected using one of the two keys that Asterisk arbitrarily picked, and passed out.  The fact that this doesn't break does not mean that the reverse is true and that having multiple crypto lines is something Asterisk supports.

As it is, please attach a DEBUG log with sip set debug on illustrating the problem.  If we can determine that there is something else at work here, we'll look at this issue.
By: Denis (xaled) 2012-04-03 11:48:41.810-0500

Yes I used demo-congrats from the samples.

I do understand, that in case of demo-congrats extension nothing is bridged. What I was trying to point out is that in the case of demo-congrats asterisk handles multiple crypto lines well and I can hear the welcome sample at the PBX client.

This shows that asterisk can handle multiple crypto lines if not bridged and can bridge if there is a single crypto line. And this means that all functionality is already there, but it gets stuck somewhere in the middle.

I'll make the debug log in a second.

Thanks!
By: Denis (xaled) 2012-04-03 12:06:45.314-0500

[Apr  3 18:51:40] WARNING[24574][C-00000002] res_srtp.c: SRTP unprotect failed with: authentication failure 110

This warnings come form the pbx sending unencrypted RTCP.
By: José Luis Millán (jmillan) 2012-11-09 07:52:33.939-0600

Hi all,

This issue arises now using WebRTC, where multiple crypto lines are offered. Canary version of Chrome does it and it will do in next stable releases (And guess all other coming web browser implementations). Perhaps is time to 'fix'/'feature' multiple key management?

Any other debug information needed?



By: Joshua C. Colp (jcolp) 2012-11-09 08:02:12.657-0600

No other information is required and I just tried the latest Canary - it doesn't offer multiple crypto lines for me. Not to say they won't eventually do that.
By: Matt Jordan (mjordan) 2012-11-09 08:21:59.455-0600

This issue is actually improperly named.  Asterisk can handle multiple crypto lines in later release of 1.8.  When I originally commented on this issue, that wasn't the case.

The reason why the issue reporter's scenario doesn't work is because the crypto offer included a crypto lifetime.  Asterisk does not support crypto lifetime, and rejects offers that provide it.

The lifetime problem is why this issue is not closed.


By: José Luis Millán (jmillan) 2012-11-10 07:02:52.047-0600

My apologies. JsSIP (www.jssip.net) + Asterisk 11 running environments just stopped working with the last releases of chrome Canary and Dev and I though this could be the cause.

Joshua, 25.0.1321.0 canary (MacOS) does, in our machines at least, generate multiple crypto lines in the offer. Anyway I will come back and open a new issue if I can determine that the problem is in Asterisk. At this moment I really don't know where the problem is.

Thanks a lot.
By: Joshua C. Colp (jcolp) 2012-11-10 07:06:16.932-0600

SDP verification went into Canary and Dev which I think has introduced a regression exposed by the rather simplistic SDP that Asterisk returns. I have an issue open about it here:

http://code.google.com/p/webrtc/issues/detail?id=1079&colspec=ID%20Pri%20Mstone%20ReleaseBlock%20Area%20Status%20Owner%20Summary&start=200
By: José Luis Millán (jmillan) 2012-11-10 07:08:32.970-0600

Thanks a million. I wasn't aware of such issue.
By: Joshua C. Colp (jcolp) 2012-11-10 07:10:36.631-0600

If you could try to isolate it further that would be much appreciated. I've thrown some changes into the SDP answer just to see what would happen but no change.
By: José Luis Millán (jmillan) 2012-11-10 07:14:11.882-0600

I will do some tests, of course. Great.
By: José Luis Millán (jmillan) 2012-11-10 09:01:53.534-0600

Calling browser to browser, I have deleted the 'ssrc' lines from the response before setting the remoteDescription and voilà; no media. It seems they are more strict now in the response. Lets see their comments to the issue you opened.
By: Joshua C. Colp (jcolp) 2012-11-10 09:04:09.986-0600

Would you mind adding that useful info to the issue?
By: José Luis Millán (jmillan) 2012-11-10 09:08:58.624-0600

Of course. It's done
By: Olle Johansson (oej) 2013-04-29 07:56:30.732-0500

The SIP message above has an a=rtcp attribute. Does asterisk properly support that?
By: Olle Johansson (oej) 2013-09-05 04:24:52.411-0500

What is the status of this old issue?
By: Matt Jordan (mjordan) 2015-02-25 16:02:26.167-0600

I don't think this issue is a bug.
# I've tested with older models of phones that offer multiple crypto keys and - as I mentioned earlier in the history here - that works (and has worked for some time).
# Browsers no longer offer SDES-SRTP, since that's a MUST NOT implement in WebRTC. So we're unlikely to know what happened there at this point (or care).

As it is, I'm going to go ahead and close this out as "Can't Reproduce". If that happens to not be the case, and someone can reproduce an issue where an offer with multiple keys bridged with another channel causes a loss of audio, please comment on the issue and I'll be happy to re-open it.
By: Alex A. Welzl (awelzl) 2015-03-11 06:46:26.035-0500

The issue is reproducible – at least in Asterisk 1.8. We were facing the same behaviour. Our phones are being configured using TLS/SRTP towards the Asterisk whereas external calls are being terminated via UDP/RTP to the carrier. Internal calls worked without any issues, external calls had sometimes problems as described in that issue earlier. Sometimes, that was the real trouble! By switching back the phones to non-encrypted communication, it worked without any trouble – but that was not a solution.

After deep investigation with wireshark and perfect assistance from our carrier, we found out that if the carrier’s RTP stream starts very quick after the 200OK (connect) and there was no early media possibility before, because of missing 183 with sdp (as this was not generated at the destination PBX), we are facing the RTP issue again. We are talking about some milliseconds too early here. As a quick fix, our carrier configured “a pause” on his side and waits until Asterisk starts sending RTP packets. The downside of the hotfix is that T.38 faxes won’t work.
Message Flow:

Asterisk                                Carrier

               Invite->
               <-100 Trying
               <-200 OK with SDP
               ACK->


So please start re-investigating the issue.

By: Joshua C. Colp (jcolp) 2015-03-11 06:49:53.865-0500

Asterisk 1.8 is no longer a supported branch. If it's occurring in a supported branch (11 and above) and debug information, wireshark, etc can be provided then a new issue should be opened.