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

From: Thomas Zeng <[email-masked]>
Date: Wed, 19 Mar 2003 11:14:36 -0800

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?

- thomas

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Mar 2003 06:15:57 +0100

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.

>recommended but not required by 1889), a report block is included in the RR

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. 

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.

Best Regards

Magnus Westerlund 

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