Paul,
H.323 has never placed any requirements on the send port--it never even mentions the send, or source, port. Many entities therefore justifiably use "random" send ports, so there is no way we can now place requirements on this.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, September 12, 2000 11:20 AM To: Anatoli Levine Cc: h323implementors@imtc.org; ITU-SG16@mailbag.cps.intel.com Subject: Re: RTP port for sending media
Anatoli, et al,
I agree that it would be very helpful for NAT devices or other equipment to be able to safely rely on receiving media from the specified RTP port that is one lower than the RTCP port advertised in the original OLC message. I thought that was the expected behavior when using RTP/RTCP, but recent discussions with folks working on SIP is that "no, that's not necessarily true." Apparently, it is believed that a SIP device may send RTP from any port.
So, if you have a line like this in the INVITE message: m= to indicate a bi-directional media flow, the RTP address is interpreted only as the "receive" address. But then I questioned, "what about the fact that the associated RTCP port (next odd port) is used for receiving RR packets.. would that not suggest that the RTP port for sending is also the same port specified in this 'm=' line?"
The answer was 'no'. So this made me curious about H.323 implementations.
Do we need to clarify that the RTP port used to send data associated with the RTCP address in an OLC is the next lower port (even) number, or do we have implementations out there that send RTP traffic from and random port, irrespective of the RTCP port put in the forwardLogicalChannelParameters of the OLC message? If the latter is the case, I think we need to state this clearly, too.
Thanks, Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com