Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
fDestRTCPPort calculation
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

fDestRTCPPort calculation



Hi

It seems that in APIModules/QTSSReflectorModule/ReflectorStream.cpp
the fDestRTCPPort calculated in ReflectorSocket::ProcessPacket
is wrong.

This is the actual code for that:

// Check to see if we need to set the remote RTCP address
// for this stream. This will be necessary if the source is unicast.
if ((theRemoteAddr != 0) && (theSender->fStream->fDestRTCPAddr == 0))
{
// If the source is multicast, this shouldn't be necessary
Assert(!SocketUtils::IsMulticastIPAddr(theSender->fStream- >fStreamInfo.fDestIPAddr));
Assert(theRemotePort != 0);
theSender->fStream->fDestRTCPAddr = theRemoteAddr;
theSender->fStream->fDestRTCPPort = theRemotePort;


		// RTCPs are always on odd ports, so check to see if this port is an
		// RTP port, and if so, just add 1.

		if (!(theRemotePort & 1))
			theSender->fStream->fDestRTCPPort++;
	}

But since the test is only checking "theRemoteAddr" and "fDestRTCPAddr"
this condition is also true when the packet is NOT a RTCP packet!

Since the RTP packets comes before the RTCP packet the calculated
port will simply be the theRemotePort of the broadcast (6972) and not the
theRemotePort of the reciever-report-request packet (6973).


Because this port is an EVEN port it will be corrected in the same
block. So nobody notice when 6972 got corrected to 6973.

So it looks like this code works only by accident ;)

So far so good!

But when you are behind a NAT the original theRemotePort 6972 got
translated to 50430 for example. Then the code would use 50431
as fDestRTCPPort which is plainly wrong.

To avoid that you should also test for "thePacket->IsRTCP()".
So you make sure you use the correct theRemotePort for fDestRTCPPort.
Then the NAT can correctly identify the packet and can translate
it back to 6973.

new code:

// Check to see if we need to set the remote RTCP address
// for this stream. This will be necessary if the source is unicast.
if ((theRemoteAddr != 0) && (theSender->fStream->fDestRTCPAddr == 0) && (thePacket->IsRTCP()))
{
// If the source is multicast, this shouldn't be necessary
Assert(!SocketUtils::IsMulticastIPAddr(theSender->fStream- >fStreamInfo.fDestIPAddr));
Assert(theRemotePort != 0);
theSender->fStream->fDestRTCPAddr = theRemoteAddr;
theSender->fStream->fDestRTCPPort = theRemotePort;


		// RTCPs are always on odd ports, so check to see if this port is an
		// RTP port, and if so, just add 1.

		if (!(theRemotePort & 1))
			theSender->fStream->fDestRTCPPort++;
	}

So my last three bugfixes (two on other mails) make it possible
to see the number of user in the Broadcaster.app even when the
machine is little-endian and/or behind a NAT.

Denis

PS: maybe some code should handle what happens if the NATed adress is also even.
But that never happened to me in a dozen tests.
_______________________________________________
streaming-server-developers mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/streaming-server-developers
Do not post admin requests to the list. They will be ignored.





Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.