RTP port for sending media

Francois Audet audet at NORTELNETWORKS.COM
Thu Sep 14 13:20:41 EDT 2000

I am not sure it would help NAT devices. Couldn't a sender "fake" the RTP
sender port by inserting another value?

More commonly, I would believe that the port would typically be set to "0"?
RFC 768 (UDP) says:

Source Port is an optional field, when meaningful, it indicates the port
of the sending  process,  and may be assumed  to be the port  to which a
reply should  be addressed  in the absence of any other information.  If
not used, a value of zero is inserted.

-----Original Message-----
From: Paul E. Jones [mailto:paulej at PACKETIZER.COM]
Sent: Tuesday, September 12, 2000 9:20 AM
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

So, if you have a line like this in the INVITE message:
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.


----- Original Message -----
From: Anatoli  <mailto:alevine at radvision.com> Levine
To: Paul E. Jones <mailto:paulej at packetizer.com>
Cc: h323implementors at imtc.org <mailto:h323implementors at imtc.org>
Sent: Tuesday, September 12, 2000 9:37 AM
Subject: Re: RTP port for sending media


when you are transmitting, you can probably can use any port, but the
problem is that usually it make sense to use the same RTP port for both
receive and transmit - in this case if you will use a random RTP port you
will violate the rules. Another dangerous thing is that we don 't know what
assumptions can firewall vendors make, so we can run into trouble with this
also ( if assumption will be made from the 2501 port number). I would
suggest that we will make it clear in the standard that two consequent port
numbers would be used for RTP/RTCP in any case.


"Paul E. Jones" wrote:

Folks, I have a question... I thought this was clear, but perhaps it is not.
Suppose I send an OLC proposing a channel to be opened and I provide my RTCP
port in the mediaControlChannel field.  Say, 2501. H.245 states in B.3.1:

The mediaChannel indicates a transportAddress to be used for the logical
channel. When the transport is unicast, mediaChannel is not present in the
OpenLogicalChannel forwardLogicalChannelParameters, but may be present in
the reverseLogicChannelParameters.

Is it safe to assume, then, that I will send my media to you from the port
2500, or am I at liberty to send my RTP data to you using any port I choose?
My understanding was that I was obligated to transmit media from port 2500,
since I indicated that the RTCP port was 2501. Thanks,Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000914/61529eba/attachment-0001.htm>

More information about the sg16-avd mailing list