RTP Engine Recording Daemon recording duration coming greater than call duration in some cases #1874
Comments
|
It's probably due to timestamp skews of one of RTP sources. SSRC 0473e089 in your pcap seems to have problems keeping its clock in sync. For example between packets 546 and 620: 1.4 seconds have passed, but the RTP timestamp increased only by 160, which corresponds to 0.02 seconds. This gap has to be made up somehow when writing the audio to file. Then between packets 684 and 726, the timestamp increased by 17680, corresponding to 2.21 seconds, but only 0.8 seconds real time have elapsed, now bringing the clock skew back again. Again this discrepancy has to be accounted for somehow when writing audio to file. So ultimately the RTP source is to blame for this. You can see this when analysing the RTP stream in Wireshark. Of course the recording daemon could detect this and try to do a better job at compensating for it, but at the moment it doesn't. |
|
Hi rfuchs, Thanks for the reply. Can you please confirm the following:
Thanks in advance for helping out. |
The synchronisation between the two audio sources in the mixed output file will likely be wrong.
No that has nothing to do with the duration of recordings. |
|
@rfuchs , Thanks for the reply. by actual recording content, I meant that the actual audio data, I mean I can understand due to packets coming delay causing this issue. Also regarding 2nd point, what can I do to solve that? can you please tell me? shall I use –output-mixed-per-media? I asked because in the logs I can see that it was related to SDP and that's why maybe rtpengine recording daemon was facing issue to record the call? Thanks in advance for helping me out. |
|
@rfuchs , I was able to restore the recording with pcap file as it had the recording which had call and recording duration difference |
|
@rfuchs, can you please check out the logs #1871. As I also saw this in the logs of rtpengine-recording: |
|
This is unrelated to this issue. Use the mailing list for general support questions. |
|
Okay thanks. Will post there |
rtpengine version the issue has been seen with
Version: 13.1.0.0+0~mr13.1.0.0 git-master-f3aa776
Used distribution and its version
Debian 10
Linux kernel version used
5.10.0-0.deb10.16-amd64
CPU architecture issue was seen on (see
uname -m)x86_64
Expected behaviour you didn't see
No response
Unexpected behaviour you saw
Recording duration coming greater than call duration
Steps to reproduce the problem
No response
Additional program output to the terminal or logs illustrating the issue
Anything else?
As I have shared 2 call logs above from syslog. For both I am facing issue of having recording duration greater than call duration.
Note: This is not happening for all calls and also we are using kernel module to kernelize stream so that recording daemon can record calls. And also I have replaced IP addresses to dummy ones for security reasons. I cannot reproduce this, it happened suddenly and if it happens again then will share logs for the same too. Also it is to be noted that #1871 was created for SDP issue and I that is why it was causing recording and call duration difference and it has huge difference like 8 sec recording duration and call was like 133 secs something. But the Call 1 had same SDP issue but this time recording duration was greater than call duration. Can you please tell me what is the issue and how can be fixed. And If I talk about Call 2 everything seems normal based on the logs but it had recording duration had 47 secs whereas call duration was 39 secs. I do not have pcap and metadata file for Call 2.
Here is the PCAP file generated by rtpengine for Call 1:
call_1_issue.zip
Here is the configuration for rtpengine-recording:
Here is the configuration for rtpengine service:
Here is rtpengine metadata for Call 1:
The text was updated successfully, but these errors were encountered: