From 5f7e111f79dd1a965aa956da7495485f52b0a1cc Mon Sep 17 00:00:00 2001 From: Nimrod Astrahan Date: Tue, 27 Jan 2015 18:13:04 +0200 Subject: [PATCH] Fix source fraction always 0 in RTCP events Without the value for source fraction, applications relying on RTCP events for making changes to FS behaviour or even for logging get false information. With this change the value for source fraction is passed along in RTCP events correctly. To my current understanding, as the value for fraction in the RTCP packet is represented by 8 bits according to the spec, calling `ntohl` on it will always zero it out. Fixed by removing the call. FS-7203 #resolve --- src/switch_rtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/switch_rtp.c b/src/switch_rtp.c index 4ad259cce3..d5dc6b0f79 100644 --- a/src/switch_rtp.c +++ b/src/switch_rtp.c @@ -6207,7 +6207,7 @@ SWITCH_DECLARE(switch_status_t) switch_rtcp_zerocopy_read_frame(switch_rtp_t *rt for (i = 0; i < (int)rtp_session->rtcp_recv_msg_p->header.count && i < MAX_REPORT_BLOCKS ; i++) { struct switch_rtcp_report_block* report = (struct switch_rtcp_report_block*) (rtp_session->rtcp_recv_msg_p->body + (sizeof(struct switch_rtcp_sr_head) + (i * sizeof(struct switch_rtcp_report_block)))); frame->reports[i].ssrc = ntohl(report->ssrc); - frame->reports[i].fraction = (uint8_t)ntohl(report->fraction); + frame->reports[i].fraction = report->fraction; frame->reports[i].lost = ntohl(report->lost); frame->reports[i].highest_sequence_number_received = ntohl(report->highest_sequence_number_received); frame->reports[i].jitter = ntohl(report->jitter);