Asterisk
  1. Asterisk
  2. ASTERISK-22675

Asterisk refuses correct RTP/AVP with optional encryption

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 11.5.1
    • Target Release Version/s: None
    • Component/s: Channels/chan_sip/SRTP
    • Security Level: None
    • Labels:
      None
    • Frequency of Occurrence:
      Constant

      Description

      Asterisk receives an INVITE from Blink:

      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
      

      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.

        Issue Links

          Activity

          Hide
          Matt Jordan added a comment -

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

          Show
          Matt Jordan added a comment - I agree, although I still find optional encryption to be silly.
          Hide
          Dmitriy Serov added a comment - - edited

          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

          Show
          Dmitriy Serov added a comment - - edited 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
          Hide
          klaus3000 added a comment -

          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)

          Show
          klaus3000 added a comment - 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)
          Hide
          Matt Jordan added a comment -

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

          Show
          Matt Jordan added a comment - Closing this out to ASTERISK-23989 , as Olle provided a patch to chan_sip for this issue.

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development