crypto and fingerprint attributes not stripped during SRTP->RTP conversion

[Ivan Ribakov]

I have RTPEngine configured to terminate SRTP. I have also recently added support for OSRTP. Since then I'm observing a strange behaviour where in some cases incoming SRTP+SDES offer is converted to an OSRTP (as opposed to plain RTP) offer on the other side. I say "in some cases" because I've only observed this in a test deployment, but I'm unable to reproduce it locally with SIPp. Am I missing anything obvious here? Any pointers as to what might be causing this behaviour? It's also driving me nuts that I'm unable to reproduce it locally.

Problem statement:

Given: 

- RTPEngine mr12.5.1.1

- Kamailio 6.0.2

- SDP offer with RTP/SAVP and a=crypto attributes

- Kamailio rtpengine_manage() call with "transport-protocol": "RTP/AVP" and "flags": [ "OSRTP-offer", "OSRTP-accept" ]

Expected behaviour:

- Rewritten SDP offer with RTP/AVP and no crypto/fingerprint attributes

Actual behaviour:

- Rewritten SDP offer with RTP/AVP AND crypto/fingerprint attributes

Logs

Attached below. The reason answer never arrives is because downstream FS is not configured to support DTLS/SDES so the call is stuck in ringing.

[Richard Fuchs]

What you're seeing is an OSRTP offer, which looks exactly like this and is created because you've instructed rtpengine to do so. Omit the OSRTP offer flag and you should see what you're expecting.

Cheers

--
You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rtpengine/d4dc6e44-c903-4a38-af2b-f8762523ff3cn%40googlegroups.com.