[Home]

Summary:ASTERISK-22675: Asterisk refuses correct RTP/AVP with optional encryption
Reporter:klaus3000 (klaus3000)Labels:
Date Opened:2013-10-10 09:12:28Date Closed:2015-03-14 23:57:52
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/SRTP
Versions:11.5.1 Frequency of
Occurrence
Constant
Related
Issues:
duplicatesASTERISK-18201 Asterisk should fall back to AVP when SRTP module is not loaded and both SAVP and AVP have been offered
is duplicated byASTERISK-23989 [patch]SDP offer/answer fails if crypto keys added to non-crypto offer
Environment:Attachments:
Description:Asterisk receives an INVITE from Blink:

{noformat}
INVITE sip:echo@83.136.32.165:4343 SIP/2.0
Record-Route: <sip:83.136.32.159;lr=on;ftag=a25a6db049c34fa5bb8805dee3d46aa2;relay=yes;nat=caller>
Via: SIP/2.0/UDP 83.136.32.159;branch=z9hG4bK4a92.27b2ea15.0
Via: SIP/2.0/UDP 198.19.188.196:62329;received=63.133.202.2;rport=62329;branch=z9hG4bKPj0f5d2851846d46db9520756755856edc
Max-Forwards: 16
From: "Klaus Darilion" <sip:klaus.darilion@labs.nic.at>;tag=a25a6db049c34fa5bb8805dee3d46aa2
To: <sip:8001@labs.nic.at>
Contact: <sip:klaus.darilion@labs.nic.at;alias=63.133.202.2~62329~1;gr=urn:uuid:2847198f-3fd0-421d-9619-50c2e744af33>
Call-ID: c46dde8cba7044539c84829ea6975f96
CSeq: 16406 INVITE
Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER
Supported: 100rel, replaces, norefersub, gruu
User-Agent: Blink 0.5.0 (Windows)
Content-Type: application/sdp
Content-Length: 579
X-Info: (83.136.32.159:30067) Enforcing NAT traversal for local caller
X-Info: (83.136.32.159:30067) Enforcing symmetric response routing

v=0
o=- 3590409414 3590409414 IN IP4 83.136.32.159
s=Blink 0.5.0 (Windows)
c=IN IP4 198.19.188.196
t=0 0
m=audio 11000 RTP/AVP 108 99 98 9 0 8 96
c=IN IP4 83.136.32.159
a=rtcp:11001
a=rtpmap:108 opus/48000
a=rtpmap:99 speex/32000
a=rtpmap:98 speex/16000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-15
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:y3I9RSOpehl6UG/pMX1CaNeSak1cKOocNdElKqXX
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:ZIfBn8Ph00X7eEgD9Y/Ixaj0Kjgv3SiFnlPlqi9E
a=sendrecv
a=nortpproxy:yes
{noformat}

The SDP uses the RTP/AVP profile, but adds a=crypto lines. This means: "RTP is fine, but if you also support SRTP when can make SRTP too".

Regardless of the "encryption=..." setting, Asterisk refuses this call with:
"We are requesting SRTP for audio, but they responded without it!"

Asterisk should accept the call and use RTP if encryption=no or use SRTP if encryption=yes.

Even better would be if encryption= also allows "yes, if possible". This would allow SRTP calls with fallback to RTP.
Comments:By: Matt Jordan (mjordan) 2013-10-14 12:27:50.277-0500

I agree, although I still find optional encryption to be silly.

By: Dmitriy Serov (Demon) 2013-10-23 15:03:10.157-0500

I hope patch from ASTERISK-22005 can help.
And it helps: outgoing call with forced "on" client (CSipSimple) SRTP and encryption=no is successefull!
BUT: But incoming calls rejected with cause 58 and warning "chan_sip.c:10512 process_sdp: We are requesting SRTP for audio, but they responded without it!"
I still don't have optional encryption :(

By: klaus3000 (klaus3000) 2013-10-24 03:12:29.604-0500

1. We have to differentiate between bugs and new features. This ticket is about the bug:

With encryption=no, Asterisk must accept a call with AVP and always must setup the audio without encryption. This means, that the crypto attributes must be ignored. An incoming SDP with SAVP must be rejcted. Even if optional encryption would be nice it must not be activated when encryption=no. There are plenty of reasons why someone may decide to have all calls unencrypted (e.g. recording on external devices, legal stuff ...).

If optional encryption is added as a new feature, we must have a dedicated setting for it (eg: encryption=optional)

By: Matt Jordan (mjordan) 2015-03-14 20:10:30.708-0500

Closing this out to ASTERISK-23989, as Olle provided a patch to {{chan_sip}} for this issue.