提交 5f7e111f authored 作者: Nimrod Astrahan's avatar Nimrod Astrahan

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
上级 193e584e
......@@ -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);
......
Markdown 格式
0%
您添加了 0 到此讨论。请谨慎行事。
请先完成此评论的编辑!
注册 或者 后发表评论