Subject: [MMUSIC] RTSP(RFC2326) even # of server_port

From: "Jae-Hwan Kim" <[email-masked]>
Date: Thu, 12 May 2005 12:04:18 +0900

Dear experts,

I am not sure if this has already been discussed, I want to ask you the
usage of the even number of server_port.

I found a RTSP player sending RTCP packet to the even number of
server_port and the content is the same as one to odd, so it causes a
bunch of ICMP destination unreachable packets. I don't know why it sends
it but I think sending RTCP to even number is risky and I concern it
wastes the bandwidth and affects b=RR stuffs and so on.

In RTSP session, only one RTP from server to client exists. So we can
assume the RTP from client to server is undefined. 

However, some notion in RFC2326 is somewhat ambiguous.

................................

(page 61 of RFC2326)

server_port:

          This parameter provides the unicast RTP/RTCP port pair on

          which the server has chosen to receive media data and control

          information.  It is specified as a range, e.g.,

          server_port=3456-3457.

.................................

Also I searched the 2326bis, but I failed to get an answer. 

However, with the above assumption, I guess the usage of even number of
server_port should be ignored because RTSP defines only one way RTP, and
server_port field should be a form of range or at least even because
RFC1889 and RFC3550 requires an even-odd port pairs for RTP session.

What do you think of this situation? Should we allow RTCP packet for RTP
port? 

Kind Regards,

Jae-Hwan Kim

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 May 2005 18:32:32 +0200

Hi Jae-Hwan Kim,

> wastes the bandwidth and affects b=RR stuffs and so on.

Sending of RTCP to an even port shall only be done when it is explicitly 
signaled. If not explicitly defined, then it shall be sent to the next 
odd port number of the indicated RTP port.

> However, some notion in RFC2326 is somewhat ambiguous.

Yes, RFC 2326 is not clear.

> Also I searched the 2326bis, but I failed to get an answer. 

I think this was quite clear. Please review appendix B1.2 in version 09 
where the following text is written:

    When using the "source", "destination", "client_port", and
    "server_port" the packets are be addressed in the following way for
    media playback:

         o RTP/UDP packet from the server to the client SHALL be sent to
           the address specified in the "destination" parameter and first
           even port number given in client_port range. If only an RTP
           port is to be specified, then only that even port number SHALL
           be given, i.e. no range including an odd number SHALL be used.

         o The server SHOULD send its RTP/UDP packets from the address
           specified in "source" parameter and from the first even port
           number specified in "server_port" parameter.

         o When the range specified in the "client_port" parameter
           contains at least two port numbers, the RTCP/UDP packets from
           server to client SHALL be sent to the address specified in the
           "destination" parameter and using the first odd port number
           belonging to the range specified in the client_port parameter.

         o The Server SHOULD send its RTCP/UDP packets from the address
           specified in "source" parameter and from the first odd port
           number greater than the RTP port number specified in
           "server_port" parameter.

         o RTCP/UDP packets from the client to the server SHALL be sent
           to the address specified in the "source" parameter and first
           odd port number greater than the RTP port number given in
           server_port range.

         o The client SHOULD send its RTCP/UDP packets from the address
           specified in "destination" parameter and from the first odd
           port number specified in client_port" parameter.

> RFC1889 and RFC3550 requires an even-odd port pairs for RTP session.

The server_port needs to be an even-odd range to specify that the RTCP 
shall be sent to the odd port on the server side.

> What do you think of this situation? Should we allow RTCP packet for RTP

No, to me it sounds that either you doesn't specify the server_port as a 
range or the client misinterprets the signalling. However it may be a 
good idea to receive any packets that arrive on the RTP server port and 
simply discard them.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Randell Jesup <[email-masked]>
Date: 12 May 2005 15:16:59 -0400

>What do you think of this situation? Should we allow RTCP packet for RTP

        Well, the stipulation from 3550 and 1889 that RTP is even, RTCP is
RTP+1 (and therefor odd) is not enforcable on a real-world system that
includes a NAT.  You can't even guarantee that RTCP = RTP+1, which is why
SDP added an a=rtcp:<port> so you can directly specify the RTCP port.
Some NATs will preserve port numbers, or at least even/odd-ness, but
others will not preserve oddness if there's a conflict, and some won't
preserve anything or put the ports together.  Basically a NAT can
and sometimes does map a port to any external port number it wants.

        I'm not entirely sure what you're reporting, so I won't try
to answer the rest of your question.

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 May 2005 21:29:46 +0200

Hi Randal,

> SDP added an a=rtcp:<port> so you can directly specify the RTCP port.

Which is also being fixed in 2326bis.

> and sometimes does map a port to any external port number it wants.

However this should not be an issue for servers that are deployed on the 
Internet with public IP addresses. The NAT would only result in that the 
destination ports for the media flow will be not following the even odd 
rule. It can even result in non continuous port numbers. This is 
definitely one of the issues with NATs.

Cheers

Magnus Westerlund