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
----- Original Message ----- From: Anatoli Levine To: Paul E. Jones Cc: h323implementors@imtc.org Sent: Tuesday, September 12, 2000 9:37 AM Subject: Re: RTP port for sending media
Paul, 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.
Anatoli
"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
Paul,
We have a mix of implementations. Indeed, an obscure feature in the sockets interface has caused interoperability problems with vendors who used the connect() call followed by calls to send() and write() for UDP media streams instead of just calling sendto() and recvfrom() without connect(). If one uses connect() on a UDP socket, only datagrams sent by the remote entity from the same port as the port on which one connected are passed up through the stack. This means that if the remote entity sends on a different port than on what it receives, all of its sent datagrams are discarded. The symptom that vendors who are using connect() experience during interop testing is two-way media with some vendors but one-way media with others. The vendors with which they have two-way media are sending and receiving on the same port; the vendors with one-way media are sending and receiving on different ports. H.323 imposes no restrictions on what ports one may send from.
In summary, 1. we cannot require that one send and receive on the same port because this would break existing compliant entities and 2. DON'T USE CONNECT()!!! :-)
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: ITU-SG16@MAILBAG.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
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
participants (2)
-
Paul E. Jones -
Paul Long