srtp crypto context last_index reset every second by callmaster thread

[mclazarus]

In continuing to investigate the issue we were experiencing and discussing in Issue 102: #102

We found that every second the call.c:callmaster_timer() function was changing the last_index to the value it had when the stream was kernelized.

You can see that on this line: https://github.com/sipwise/rtpengine/blob/master/daemon/call.c#L1439

This causes a timing issue with packet processing. There are parts of the rtp.c:packet_index() function which estimates the index where the difference is so wide that the last_index will freeze.

For example if the difference between the last_index put in place by the callmaster_timer() is between 0x8000 and 0x10000 the last_index will not be updated for 16000 packets. This could cause the ROC to increment on the far end but not on the rtpengine end resulting in an inability for the packets to be decrypted properly.

This modifying of the last_index by the callmaster thread appears to be completely wrong and when we commented it out we were able to have a call that would last longer than 20 minutes and not have any encryption issues between rtpengine and chrome. Looking back through the history of the call.c file it's unclear if this needs to be there at all anymore as it seems the last_index management is completely handled by rtp.c. If it's being used to time redis updates, it seems like you'd get one update per second per call.

[mclazarus]

cc: @marcantonio

[rfuchs]

Could it be that you don't actually have the iptables rules in place to facilitate kernel-mode packet forwarding?

[mclazarus]

Ack. Yes, thank you. Once we started making test builds to track the issue we screwed up the iptables rules. I'm retesting in kernel space now.

[rfuchs]

This is why there's a particular comment in callmaster_timer() :)

/* XXX this only works if the kernel module actually gets to see the packets. */

[mclazarus]

Yes. Thanks. At the time I didn't understand exactly how the kernelizing/unkernelizing worked. I have a much better idea now. I'm going to close this issue.