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

From: "Venna, Nagarjuna" <[email-masked]>
Date: Wed, 21 Aug 2002 18:05:27 -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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 23 Aug 2002 10:32:04 +0200

Hi, Nagarjuna

See comments below.

>receiving a RTCP report from when it does not receive any media packets.
I can agree that there are some difficulties in identifying the client 
based on RTCP reports and knowing for sure how to connect that with the 
RTSP session. However it seem that they have taken a reasonable solution.

The problem with multicast that a receiver must use the ports that the 
server decides on is also true for receiving the data. So unless you can 
get these port and receive the data on you neither has any problem with 
sending reports.

 From what you write in the background paragraph I can't determine if 
they are using a port pair per each RTP session or if they share port 
pair over multiple RTP sessions. Having a single RTP session on each 
port pair makes this problem much simpler and is according to RTP 
specification. If DSS tries to have multiple RTP session on a port pair 
this makes the problem much more difficult. However I understand that 
one might try for such a solution to allow the server to have many RTSP 
session simultaneous.

Having a single RTP session on each port pair solves this problem almost 
completely. Receiving a RTCP report on the control port can somewhat 
simplified be directly interpreted as the client (unicast) or some 
client (multicast) is alive and the RTSP session shall be kept alive. To 
prevent that somebody else is keeping a session alive the address should 
be checked so it comes from the receiver of the media. The client port 
can also be used in the match to remove any doubt that the sender is 
another client due to NAT or multi-user hosts. This requires that the 
client sends its report from its receiver ports. However I don't see 
that as a limitation, I would in fact strongly recommend it. It is in 
accordance whit how the designers of RTP thought it should be done, it 
is also a requirement if one wants to transmit RTCP messages from behind 
certain kinds of NATs. In multicast the client does not have a problem 
with this type of attack as it can discontinue delivery of media by 
leaving the multicast group. There exist other problems with RTSP 
security regarding multicast and rights to invite a server into a 
multicast group but they do not effect this problem.

A reason why not the clients SSRC itself should be connected into the 
RTSP keep alive mechanism is that it might change due to collision. It 
is rather unlikely in the case of unicast and if the server send the 
SSRC it will use I would say it is zero. In multicast this probability 
goes up especially due to bad implementations that does not use the 
complete number space when doing randomizations or don't do random SSRC. 
Therefore the SSRC can change (also the server's) and the RTP mechanism 
is definitely capable of coping with this.

Another problem with SSRC is that it gives no information about who the 
sender is, it is simply a administrative number that is used to connect 
different pieces of information together within RTP/RTCP. To identify 
the source of a report packet it is much more giving to look at sender 
adress/port and the CNAME.

Having multiple RTP sessions onto the same port pair create problems. As 
each session has its own SSRC space the risk of collision increase with 
the number of sessions. These are also not going away as they do not 
trigger any RTP collision resolving mechanism. Therefore this does not 
work when a multicast session is involved. It might work with multiple 
unicast sessions by matching the packets adress/port from the RTSP setup 
process. But I would not recommended it.  

>"client_ssrc" header can also be sent in the SETUP response.
As the SSRC is a rather permanent identifier in a RTP session it should 
be given when the RTP session is created and that is as a result of the 
SETUP request. The RTP-info header is not the right place as this header 
is sent for every PLAY response. However I don't see a reason why the 
server should be setting the clients SSRC. First, it can't be used in 
multicast. In unicast I don't see how it gives any advantage at all.

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]