SDP - SRTP Crypto Value Update issue

I have an Asterisk 20 LTS with PJSIP instance. On a call scenario where Asterisk sends out an INVITE with session expires at 1800 and session refresher set to UAC which is the asterisk instance.

The SDP has SRTP crypto set up.

Initial SDP from Asterisk’s outgoing INVITE:

Session Description Protocol
    Session Description Protocol Version (v): 0
    Owner/Creator, Session Id (o): - 1343603766 1343603766 IN IP4 X.X.X.X
    Connection Information (c): IN IP4 X.X.X.X
    Time Description, active time (t): 0 0
    Media Description, name and address (m): audio 29488 RTP/SAVP 8 0 18 101
    Media Attribute (a): crypto:1 AES_CM_128_HMAC_SHA1_80 inline:cbZMfYj9Q8r5xU6R+azKrtBwHQ+GKy09mRFSADX5
    Media Attribute (a): rtpmap:8 PCMA/8000
    Media Attribute (a): rtpmap:0 PCMU/8000
    Media Attribute (a): rtpmap:18 G729/8000
    Media Attribute (a): fmtp:18 annexb=no
    Media Attribute (a): rtpmap:101 telephone-event/8000
    Media Attribute (a): fmtp:101 0-16
    Media Attribute (a): ptime:20
    Media Attribute (a): maxptime:140
    Media Attribute (a): sendrecv

at 900 second, Asterisk sends a 2nd SIP INVITE with below SDP:

Session Description Protocol
    Session Description Protocol Version (v): 0
    Owner/Creator, Session Id (o): - 1343603766 1343603767 IN IP4 X.x.x.x
    Connection Information (c): IN IP4 X.x.x.x
    Time Description, active time (t): 0 0
    Media Description, name and address (m): audio 29488 RTP/SAVP 8 101
    Media Attribute (a): crypto:1 AES_CM_128_HMAC_SHA1_80 inline:cbZMfYj9Q8r5xU6R+azKrtBwHQ+GKy09mRFSADX5
    Media Attribute (a): rtpmap:8 PCMA/8000
    Media Attribute (a): rtpmap:101 telephone-event/8000
    Media Attribute (a): fmtp:101 0-16
    Media Attribute (a): ptime:20
    Media Attribute (a): maxptime:140
    Media Attribute (a): sendrecv

As you can see crypto field is unchanged however, my understanding from RFC:

Each master key and salt MUST be a cryptographically random number and MUST be unique to the entire SDP message.

I expect here Asterisk to update the crypto as the SDP codec list is changing.

Is my interpretation of the RFC correct? How can we explain the Asterisk behavior.

The codec list and SRTP are independent. What you’re referring to is re-keying which is not required on a re-INVITE. Some platforms allow you to enable it, we don’t have an option for it. The line you are referring to is in reference to other SDES SRTP media streams within the SDP, each one must be unique.

1 Like