Possibilities of URL

Chip Sharp chsharp at CISCO.COM
Wed Sep 13 10:09:18 EDT 2000


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

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 at PACKETIZER.COM]
Sent: Tuesday, September 12, 2000 11: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 port.

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

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.


For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

More information about the sg16-avd mailing list