]> git.ipfire.org Git - thirdparty/asterisk.git/commit
chan_sip: Don't refuse calls with "optional crypto"; fall back to RTP. 29/3829/1
authorWalter Doekes <walter+github@wjd.nu>
Tue, 6 Sep 2016 07:41:06 +0000 (09:41 +0200)
committerWalter Doekes <walter+asterisk@wjd.nu>
Tue, 6 Sep 2016 07:55:59 +0000 (02:55 -0500)
commit9b59ebee2fbe6fff9e7db6f125830c64abc8a47a
tree8ca0e98db2c54a6c72775507c3073b2f2824fef3
parentf33ccbdf86e8057b53801923b21adf76a396ab79
chan_sip: Don't refuse calls with "optional crypto"; fall back to RTP.

Certain SNOM phones send so-called "optional crypto" in their SDP body.
Regular SRTP setup looks like this:

    m=audio 64620 RTP/SAVP 8 0 9 99 3 18 4 101
    a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:...

SNOM-style "optional crypto" looks like this:

    m=audio 61438 RTP/AVP 8 0 9 99 3 18 4 101
    a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:...

A crypto line is supplied, but the m-line does not have SAVP.

When res_srtp.so is *not* loaded, then chan_sip.so treats the optional
crypto as regular RTP, but when res_srtp.so *is* loaded, it refuses the
incoming call with the following message:

    WARNING: process_sdp: Failed to receive SDP offer/answer with
    required SRTP crypto attributes for audio

For platforms that want to start providing SRTP this presents a
compatibility problem.

This changeset lets chan_sip handle the SDP as if no crypto-line was
supplied: i.e. accept the call as regular RTP, just like it did before
res_srtp was loaded.

Now you'll get this informative warning instead:

    WARNING: Ignoring crypto attribute in SDP because RTP transport is
    insecure

ASTERISK-23989 #close
Reported by: Olle Johansson

Change-Id: I91a15ae05a0296e398d6b65f53bb11afde1d80e2
channels/chan_sip.c