#9 Incorrect padding calculation in GenBye()

[Scott Miller]

RTCP padding calculation for the BYE message in thebridge's GenBye() function appears to be incorrect. RFC3550 (page 51) says that the reason message padding is separate from the padding indicated by the P bit in the RTCP header. Wireshark seems to agree.

If it's not crashing anything it's probably not a big deal, but I'm using thebridge as a reference as I'm creating my own EchoLink client implementation so I'm hoping to resolve any ambiguity, and I also want ot be sure that thebridge is OK with reasons that don't include a trailing null, since the RFC says they shouldn't have one unless padding is needed.

[Skip Hansen]

Hi Scott,

It's clear that Echolink is based on RTP, RTCP etc, but that was never stated. Echolink is a copy of an older Ham radio linking project called iLink and the protocol was considered a secret. EchoLink and thebridge, etc were based on reverse enginerring the over the air protocol, not RFCs or any other documentation. All I can say is that "it works", if changes were make to make it RFC compliant it may well stop working. Additionally I'm no longer developing this code and I'm no longer active on Echolink.

BTW Good luck with your project!

[Scott Miller]

Thanks Skip. It's certainly not a show stopper, just one of several things I wish there was some kind of definitive answer for. Jonathan hasn't been able to give me much beyond "read the source code for theBridge" and "read the RFCs".

If I start crashing clients, I'll deal with that when the time comes. It looks like some of the padding was selected for the sake of encryption, but of course we're not using encryption in EchoLink.