SRTP with Kamailio Signalling

[QMS-CG]

rtpengine version the issue has been seen with

mr12.2.1.3

Used distribution and its version

RHEL 8

Linux kernel version used

4.18.0-348.el8.x86_64

Expected behaviour you didn't see

Hi,

I am trying to setup SRTP to flow from the RTPEngine to an oracle SBC. The SBC is setup correctly to receive SRTP and I see in the SDP between them that crypto is being negotiated. The a=media line also includes RTP/SAVP but when performing a wireshark trace I see normal RTP flowing to the SBC.

Additional program output to the terminal or logs illustrating the issue

INVITE from RTPEngine to SBC SDP:
a=extmap-allow-mixed
a=msid-semantic:  WMS c2565e54-98bb-4bd8-9f6f-6ed20e90185f
m=audio 16848 RTP/SAVP 111 63 0 8 13 110 126
c=IN IP4 172.16.1.100
a=mid:0
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
a=rtcp-fb:111 transport-cc
a=rtpmap:63 red/48000/2
a=fmtp:63 111/111
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:126 telephone-event/8000
a=ssrc:2198946705 cname:Glcu48G75Xu9Koir
a=ssrc:2198946705 msid:c2565e54-98bb-4bd8-9f6f-6ed20e90185f c416114b-65a6-49aa-8d5c-0bb049d17550
a=msid:c2565e54-98bb-4bd8-9f6f-6ed20e90185f c416114b-65a6-49aa-8d5c-0bb049d17550
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendrecv
a=rtcp:16849
a=rtcp-mux
a=crypto:1 AEAD_AES_256_GCM inline:Ygb/RY4gTdHS3xOKU2jP8rNxvb11plwSqAZZvhM3NnLpe73W+nrS3dXgRL8
a=crypto:2 AEAD_AES_128_GCM inline:CsMk7RX9eBvexYe7TyGvJzucJCbK/Pw1g2omSg
a=crypto:3 AES_256_CM_HMAC_SHA1_80 inline:hMIje4Hx2WyePm1QGy79IYDhj08ds29ktDVgHRTk7Y2FIffcOs7QwHnBJ/altw
a=crypto:4 AES_256_CM_HMAC_SHA1_32 inline:p21c4TgK1bFlyfceonDE6osdjI//nr2Vgpli6TKRRJIHSZ7IC9QSmZBVL9d+QQ
a=crypto:5 AES_192_CM_HMAC_SHA1_80 inline:0SlpuJR0K02J7D0CyPyu4ldZtlUtmwukZc+M3lKkgp0LyWL1+/Q
a=crypto:6 AES_192_CM_HMAC_SHA1_32 inline:Rq5H3AiCdOvpMAhzbaYtognagaZEO9tHFoFN3YbAAXMhhP5PvZo
a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:eLU/DBXKUHVLW8Si622SngNZYkItxDV9XsMwQhNw
a=crypto:8 AES_CM_128_HMAC_SHA1_32 inline:L3oknSotlpw9YY0cGZCOjMbcGdSgSwj15AlffZnl
a=crypto:9 F8_128_HMAC_SHA1_80 inline:ODo9zm2YZ4iRSH3PYduWpTxEubzUIObjQyzT2nuX
a=crypto:10 F8_128_HMAC_SHA1_32 inline:2o+Pd0xwYmnbdVF8B4JF9G4+qETeLtZPb57C3OWh
a=crypto:11 NULL_HMAC_SHA1_80 inline:vaVMKy8t9V9ubCdzMif64sR2SlcG9jgdEVCxGnwd
a=crypto:12 NULL_HMAC_SHA1_32 inline:ceNg88nEFOb9AU+3Qd+jSxkgMRiO45w6tYBVZBxb
a=setup:actpass
a=fingerprint:sha-256 F7:EF:61:79:DA:45:5A:45:65:A5:03:78:D1:F5:B4:A2:F2:4B:57:19:8B:08:76:CE:E4:C6:74:52:0A:F0:93:FE
a=tls-id:17db7ca5102f9289cf3f193b59a71159

183 back from SBC:
t=0 0
m=audio 29950 RTP/SAVP 111 110
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:110 telephone-event/8000
a=ssrc:2820590149 cname:2820590149@redwoodtech.com
a=sendrecv
a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:5IsZD2DBIN2N8SRSEOIdnNuX7F5PS6r8lLPL4ZS1

I have been using these RTPEngine flags in the offer: "trust-address replace-origin replace-session-connection ICE=remove port-latching rtcp-mux-accept RTP/SAVP SDES-authenticated_srtp SDES-encrypted_srtcp SDES-encrypted_srtp direction=ext direction=int"

[rfuchs]

The Github issue tracker is not a support forum and there's no indication that this is a bug. Use the mailing list if you have questions about usage.