Subject: RE: [AVT] Server RTCP RR demultiplexing when one port is used to receive RR s from lots of clients

From: Thomas Zeng <[email-masked]>
Date: Thu, 20 Mar 2003 09:38:02 -0800

Thanks for your comments, Magnus. My answers inlined.

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Wednesday, March 19, 2003 9:16 PM
To: Thomas Zeng
Cc: [email-masked]'; [email-masked]'
Subject: Re: [AVT] Server RTCP RR demultiplexing when one port is used
to receive RR s from lots of clients

Hi Thomas,

When we are talking about demultiplexing of multiple RTP session on the 
same server port I have a different view. First the demultiplexing is 
not based on the SSRC but on the source IP address and port. An RTP 
session between two entities can be defined by the two end points 
address and ports. Assumes that data is sent and received on the same 
port. By strictly defining the RTP session with these two 4-tuples of 
 client address and port and server address and port for RTP and RTCP 
makes it possible to have separate SSRC spaces for each client. As not 
being one who have actually implemented this, I still guess that this 
how it has been done in a lot of servers out there. This solution of 
course does not work when one come to cases where the clients address is 
not known.

[TZ] The last case (when Server is in the open, and Clinet is  behind a NAT)
is what I am talking about. 

Thomas Zeng wrote:

>Hi Steve:
>
>As promised, I went back to  double checke RFC1889.
>
>It is said in section 6.1:
>
>	"SR or RR: The first RTCP packet in the compound packet must always
>be a report packet to facilitate header validation as described in Appendix
>A.2. This is true even if no data has been sent nor received, in which case
>an empty RR is sent, and even if the only other RTCP packet in the compound
>packet is a BYE."
>
>Now when a compound RTCP packet arrives in the server's RTCP port,  if RC
>(Report Count) is not zero, the server's SSRC must be present. Hence server
>is able to uniquely determine client's identity (since server is capable of
>asisgn unique Sender SSRC for each client).
>You are right that there is a trick involved: even if no data is received
>from the server, RC is set to 1 (instead of zero which seems to be
>recommended but not required by 1889), a report block is included in the RR
>with zero bytes/packets.
>Do you see any problem?
>

I see some problems with this. You assume that the client gets the SSRC of
the server through signaling (RTSP). However RTP has not seen the SSRC yet.
This creates problems with the implementations. A RTCP implementation
creates the RTCP receiver report blocks based on the implementations
internal state. This state is normally populated based on incoming traffic.
Therefore having the client create a state for the server that is not based
on received traffic will requires implementation work. 

[TZ]  Here Server SSRC happens to be in the RTP header. Hence client can use
RTP header to obtain server SSRC if client has received at least one RTP for
the session. If it has not but has received Setup response, it then can use
SSRC obtained from there. Yes, it is not nice because RTP implementation is
prefered not to have dependencies on the control protocol. However, RTP
implementation must somehow obtain server's RTCP receive address and port,
anyway,
from no where but the control protocol.  Adding SSRC to the list of
dependencies isn't a new breach of the rule.

Secondly, their is a problem with the report block. To include a report
block you must include the extended sequence number as being the last packet
seen plus the roll over counter. This creates problems as the client RTP
implementation has so far not seen any packet. So sending a report block
does in fact lie. I see this as an problem. This may certainly have issues
with the RTP/RTCP implementations.

[TZ] Yes, I agree with you on this one. Fortunately, since not only the
highest SeqNum but also the total number bytes received are  0, there is no
confusion.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt