On 11/18/2014 08:29 PM, Juha Heinanen wrote:

Richard,

Enclosed find syslog that includes rtgpengine log at level 7 and also pcap of the call. I made re-invite from baresip to sems once I saw this in syslog:

Nov 19 03:22:14 rautu rtpengine[29718]: [5315d797a9a5e7ce port 50761] DTLS-SRTP successfully negotiated

I didn't include the to this message due to the pcap.

Looking at your logs, I think what happened is that you've included the "trust-address" flag in the original answer, but haven't included it in the answer to the re-invite. This means that in the second answer, rtpengine erroneously saw a different endpoint than before (using the source address of the SIP packet), in response to this it also opened a new endpoint on its own side, which was then sent to the DTLS-SRTP client. This client then saw the new endpoint and correctly started a new DTLS connection, meanwhile rtpengine was still using the old keys and (I'm guessing) neither expected nor processed the new DTLS handshake, thus en/decrypted SRTP using the old keys, resulting in mangled RTP packets.

So the short-term fix would be to include trust-address to avoid switching endpoints. As for DTLS restarts in rtpengine, this is something that I was just working on and DTLS restarts on changed endpoints should be working soon.

cheers