[Spce-user] rtpengine: does it ignore SRTP(SDES) with re-INVITEs?

[Richard Fuchs]

On 2017-12-08 01:39 AM, Anthony Alba wrote:
> I suspect the answer is yes; I just want to confirm that this is the
> expected behaviour.
>
> Scenario:
>
> UAC: make SRTP call
> sends INVITE:  rtpengine_manage() called in kamailio
>
> UAC: call on hold
> sends INVITE (a=sendonly) with new SDES (SRTP): rtpengine_manage()
> called in kamailio
>
> UAC: resumes call
> sends INVITE with new SDES (SRTP): rtpengine_manage() called in kamailio
>
> It seems that the first set of SDES are used throughout the call and
> everything just works: the UACs are PJSIP (they don't seem to honor
> the changing SDES), rtpengine also doesn't seemed to care about the
> supposed "change" in SDES as stats gathering still works, and there
> are no complaints that SRTCP failed to decrypt.
>
> I.e., if UACs honored SDES change and rtpengine didn't, then I would
> expect SRTCP to fail (for stats gathering). Conversely, if UACs
> ignored new crypto and rtpengine didn't then SRTCP should also fail.
>
> If seems that both PJSIP and rtpengine ignore mid-dialog SDES changes.
> Can I confirm that it is the expected behaviour for rtpengine?
AFAIK (working off memory here) a change in SDES must always be honoured 
by the clients involved. In other words, when one client sends out a new 
SDP with changed SDES parameters, it would expect this change to take 
effect immediately and the receiving client would also update its 
parameters immediately. Pretty sure that this is what rtpengine does and 
I would expect PJSIP to do the same. I'm not sure why you would expect 
anything else.

Cheers