Subject: [MMUSIC] Issues with disambiguating RTCP RR by a RTSP Server

From: "Venna, Nagarjuna" <[email-masked]>
Date: Tue, 20 Aug 2002 11:08:43 -0400

This mail is a follow-up on a discussion I had with Darwin Streaming Server
developers on the DSS mailing list. 

Background:

DSS implements a timeout mechanism to drop RTSP sessions if a client appears
to be dead. A client is deemed to be "alive" if it has sent a RTCP Reception
Report in the past n seconds (I believe n is about 100 secs). When the
server is streaming a live session, DSS uses a single port pair for media
and control packets for all clients and expects to receive RTCP RR on that
port (specified as part of "server_port" in Transport Header of SETUP
response). DSS uses the source address/source port of the RTCP packet to
identify the client and update its status tables. 

Issues:

My understanding of an RTP session (Section 3 and Section 5.2 of RFC 1889)
is that it is entirely determined by the destination address and destination
port. Source Port should not matter when looking at an RTP packet. The above
strategy used by DSS has problems with multicast sessions because the client
has to come with a control packet whose source port is actually chosen by
the server. In addition, the "client_port" parameter in the Transport header
of a RTSP SETUP message only specifies where the client is willing to
receive media and control data. The spec does not say anything about where
the client is going to send its control data from.

Looking at the client SSRC should be the correct solution. As the clients do
not send any media packets, the server has no way of knowing what the SSRC
is. There is also no guarantee that the SSRC across clients is going to be
unique. So, the larger question is how does a server identify who it is
receiving a RTCP report from when it does not receive any media packets.

I do not know of a good way to solve this problem. Please let me know if I'm
missing something. If not, a possible solution follows.

Possible Solution:

The only way to guarantee SSRC's that the clients use in RTCP will be unique
is to let the server generate them and tell the clients during session
setup. I would think the right place is to send "client_ssrc" in the
RTP-Info header of the PLAY response from the server. 

The server SSRC is sent to the client in the Transport header of SETUP
response. I'm not really sure why it is here instead of in the RTP-Info
Header in the PLAY response. If there is a good reason to do this, then the
"client_ssrc" header can also be sent in the SETUP response.

Thanks,
nagarjuna

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