[asterisk-commits] res rtp asterisk: Trim trailing byte off of SDES packet (asterisk[15.0])

[SVN commits to the Asterisk project]

Joshua Colp has submitted this change and it was merged. ( https://gerrit.asterisk.org/6601 )

Change subject: res_rtp_asterisk: Trim trailing byte off of SDES packet
......................................................................

res_rtp_asterisk: Trim trailing byte off of SDES packet

This could have been fixed by subtracting 1 from the final value of
'len' but the way the packet was being constructed was confusing so I
took the opportunity to (I think) make it more clear.

We were sending 1 extra byte at the end of the SDES RTCP packet which
caused Chrome to complain (in its debug log):

    Too little data (1 byte) remaining in buffer to parse
    RTCP header (4 bytes).

We now send the correct number of bytes.

Change-Id: I9dcf087cdaf97da0374ae0acb7d379746a71e81b
---
M res/res_rtp_asterisk.c
1 file changed, 29 insertions(+), 5 deletions(-)

Approvals:
  Joshua Colp: Looks good to me, but someone else must approve; Approved for Submit
  George Joseph: Looks good to me, approved



diff --git a/res/res_rtp_asterisk.c b/res/res_rtp_asterisk.c
index 8f66a0a..7bb9152 100644
--- a/res/res_rtp_asterisk.c
+++ b/res/res_rtp_asterisk.c
@@ -3763,6 +3763,7 @@
 	RAII_VAR(struct ast_json *, message_blob, NULL, ast_json_unref);
 	int res;
 	int len = 0;
+	uint16_t sdes_packet_len_bytes, sdes_packet_len_rounded;
 	struct timeval now;
 	unsigned int now_lsw;
 	unsigned int now_msw;
@@ -3770,7 +3771,7 @@
 	unsigned int lost_packets;
 	int fraction_lost;
 	struct timeval dlsr = { 0, };
-	unsigned char bdata[512] = "";
+	unsigned char bdata[AST_UUID_STR_LEN + 128] = ""; /* More than enough */
 	int rate = rtp_get_rate(rtp->f.subclass.format);
 	int ice;
 	struct ast_sockaddr remote_address = { { 0, } };
@@ -3850,12 +3851,35 @@
 	put_unaligned_uint32(rtcpheader, htonl((2 << 30) | (rtcp_report->reception_report_count << 24)
 					| ((sr ? RTCP_PT_SR : RTCP_PT_RR) << 16) | ((len/4)-1)));
 
-	put_unaligned_uint32(rtcpheader + len, htonl((2 << 30) | (1 << 24) | (RTCP_PT_SDES << 16) | (2 + (AST_UUID_STR_LEN / 4))));
+	sdes_packet_len_bytes =
+		4 + /* RTCP Header */
+		4 + /* SSRC */
+		1 + /* Type (CNAME) */
+		1 + /* Text Length */
+		AST_UUID_STR_LEN /* Text and NULL terminator */
+		;
+
+	/* Round to 32 bit boundary */
+	sdes_packet_len_rounded = (sdes_packet_len_bytes + 3) & ~0x3;
+
+	put_unaligned_uint32(rtcpheader + len, htonl((2 << 30) | (1 << 24) | (RTCP_PT_SDES << 16) | ((sdes_packet_len_rounded / 4) - 1)));
 	put_unaligned_uint32(rtcpheader + len + 4, htonl(rtcp_report->ssrc));
-	put_unaligned_uint16(rtcpheader + len + 8, htonl(0x01 << 24));
-	put_unaligned_uint16(rtcpheader + len + 9, htonl(AST_UUID_STR_LEN << 24));
+	rtcpheader[len + 8] = 0x01; /* CNAME */
+	rtcpheader[len + 9] = AST_UUID_STR_LEN - 1; /* Number of bytes of text */
 	memcpy(rtcpheader + len + 10, rtp->cname, AST_UUID_STR_LEN);
-	len += 12 + AST_UUID_STR_LEN;
+	len += 10 + AST_UUID_STR_LEN;
+
+	/* Padding - Note that we don't set the padded bit on the packet. From
+	 * RFC 3550 Section 6.5:
+	 *
+	 *    No length octet follows the null item type octet, but additional null
+	 *    octets MUST be included if needed to pad until the next 32-bit
+	 *    boundary.  Note that this padding is separate from that indicated by
+	 *    the P bit in the RTCP header.
+	 *
+	 * These bytes will already be zeroed out during array initialization.
+	 */
+	len += (sdes_packet_len_rounded - sdes_packet_len_bytes);
 
 	if (rtp->bundled) {
 		ast_rtp_instance_get_remote_address(instance, &remote_address);

-- 
To view, visit https://gerrit.asterisk.org/6601
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: 15.0
Gerrit-MessageType: merged
Gerrit-Change-Id: I9dcf087cdaf97da0374ae0acb7d379746a71e81b
Gerrit-Change-Number: 6601
Gerrit-PatchSet: 1
Gerrit-Owner: Sean Bright <sean.bright at gmail.com>
Gerrit-Reviewer: George Joseph <gjoseph at digium.com>
Gerrit-Reviewer: Jenkins2
Gerrit-Reviewer: Joshua Colp <jcolp at digium.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-commits/attachments/20170928/d7202da0/attachment-0001.html>