[Asterisk-code-review] chan_unistim: Fix RTP port byte order for big-endian arch (...asterisk[13])

Sean Bright asteriskteam at digium.com
Fri Aug 16 07:27:45 CDT 2019


Sean Bright has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/12747 )

Change subject: chan_unistim: Fix RTP port byte order for big-endian arch
......................................................................


Patch Set 1: Code-Review-1

(1 comment)

I know nothing about this protocol, but based on Wireshark's dissector, I see nothing different between the 4 ports being assigned in this block:

https://github.com/wireshark/wireshark/blob/master/plugins/epan/unistim/packet-unistim.c#L2272-L2284

So I feel like we should be changing all of them or none of them, but I will defer to someone with a better understanding of the protocol.

https://gerrit.asterisk.org/#/c/12747/1/channels/chan_unistim.c 
File channels/chan_unistim.c:

https://gerrit.asterisk.org/#/c/12747/1/channels/chan_unistim.c@2769 
PS1, Line 2769: 		buffsend[24] = (htons(us.sin_port) & 0xff00) >> 8;
              : 			buffsend[25] = (htons(us.sin_port) & 0x00ff);
So I assume the previous code was using the mask & shift to try and emulate htons()? I guess?

It would be much cleaner to use put_unaligned_uint16() here:

 put_unaligned_uint16(&buffsend[24], htons(us.sin_port));

And why wouldn't we perform the same operation on the 3 other ports here?



-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/12747
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: 13
Gerrit-Change-Id: I9a9ca7f26e31a67bbbceff12923baa10dfb8a3be
Gerrit-Change-Number: 12747
Gerrit-PatchSet: 1
Gerrit-Owner: Igor Goncharovsky <igor.goncharovsky at gmail.com>
Gerrit-Reviewer: Friendly Automation
Gerrit-Reviewer: Sean Bright <sean.bright at gmail.com>
Gerrit-Comment-Date: Fri, 16 Aug 2019 12:27:45 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20190816/139285f3/attachment-0001.html>


More information about the asterisk-code-review mailing list