Subject: [MMUSIC] RTSP: m=, a=control, and RTP sources

From: Go Hori <[email-masked]>
Date: Fri, 11 Oct 2002 14:32:59 -0700 (PDT)

Hello all RTSP fans!

I came across a corner case when RTSP is controlling a RTP live conference.  
Please consider a gateway app which listens to SIP/RTP live conference on
one side and talks RTSP/RTP to the other side, and a new source join the
RTP session on SIP side.  Now a RTSP client needs to issue an SETUP for
this source to be able to listen to it.

The main problem in above example is an ambiguity in the use of m= line
and a=control: attribute in RTSP.  It makes most sense to think that m=
line represents a RTP session.  a=control:, on the other hand, is an
identifier assigned to a source in RTP session so RTSP client can issue a
SETUP request.

One way to solve this is for a RTSP server to send ANNOUNCE when a new 
source joins the RTP session; thus, a client can send SETUP for it.

However, it would be nice in some cases if a single a=control: can control
a whole RTP session rather than just one source, and let RTP stack deal
with dynamic nature of its own protocol.  

I'd like to get some feedback on this issue.
Thanks,
Go

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Oct 2002 14:01:32 +0200

Hi Go,

See comments below:

>with dynamic nature of its own protocol.  
This is one way of solving this gateway case. There exist at least two 
other possibilities.
1. The gateway mixes the different sources. So the output on the RTSP 
side is sent from the gateways SSRC. To show the original source either 
CSRC can be used or be added as part of the media.
2. Use multiple SSRCs in the packet stream with their original source ID 
to id the sources.

Using either of 1 or 2 seems better than Go's alternative. This way the 
server does not need to do any announcements unless some other session 
related parameter, e.g. the use codecs, are changed. In my opinion the 
alternative 2 is best. However it put some requirement on codec 
management in the client.

Unless you have a need to control receiving from each participant 
individually you don't need control ID's for each participant. Also this 
seems more to be something a Media Resource Control Protocol should be 
able to handle. Also changing the connection between a=control and RTP 
sessions would have massive backwards compatibility issues. So I 
strongly suggest that we don't go this road. Any work in this direction 
should rather be on a Media Resource Control Protocol. IF that protocol 
is extensions to RTSP or new protocol is another question.

However this brings up another RTSP problem. The specification says that each media stream can only have one source. This depending on the definition of source, may make solution 2 impossible. Only allowing for a single SSRC will also prevent using the suggested RTP retransmission (RTX) scheme using SSRC multiplexing. This seems to be the best way of doing RTX for streaming applications. But allowing for multiple media sources also has implications for the clients media codec handling. So I would propose that this is clarified in RTSP and a solution is found that allows RTSP to inform the client of what to expect. 

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]

---

From: Go Hori <[email-masked]>
Date: Mon, 14 Oct 2002 14:04:56 -0700 (PDT)

Hi Magnus,

comments inline.  

> 2. Use multiple SSRCs in the packet stream with their original source ID 

Im not quite sure what 2) means...SETUP for multiple SSRCs?

> management in the client.

I also don't like ANNOUNCE, either :)

> individually you don't need control ID's for each participant. Also this 

Right, that's the motivation behind my proposal.  

> is extensions to RTSP or new protocol is another question.

We could positively signal the new semantics.   

> 
> However this brings up another RTSP problem. The specification says that 
> each media stream can only have one source. This depending on the 
> definition of source, may make solution 2 impossible. Only allowing for 
> a single SSRC will also prevent using the suggested RTP retransmission 
> (RTX) scheme using SSRC multiplexing. This seems to be the best way of 

Not necessary.  A setup sequence will be the same as in the case for port
multiplexing except that original stream and RTX stream are in the same
RTP session.

> doing RTX for streaming applications. But allowing for multiple media 
> sources also has implications for the clients media codec handling. So I 
> would propose that this is clarified in RTSP and a solution is found 
> that allows RTSP to inform the client of what to expect. 

Agreed.  This is the core of the problem.  SETUP allocates resources for a
"source" (whatever it may be).  Im in the favor of issuing one SETUP for
two SSRCs (original and RTX strams).  But, I would also think if SETUP for
two SSRCs is allowed, so should multiple SSRCs unless we introduce a
notion of dependent SSRC that is not by itself constitute a media
stream...

Go

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Oct 2002 11:23:15 +0200

Hi Go,

I think we are on the same page so I will try to summarize. Please 
comment if you don't agree with something. 

We have a problem in RTSP when a media stream needs to contain multiple 
RTP SSRCs. This can't be expressed today clearly.

When one is only interested in controlling the media and not each 
individual source the following scenarios should be supported:
A SINGLE SETUP request can result in one of the following:
1. A media stream with a single SSRC.
2. A media stream with retransmission with SSRC multiplexing. This 
requires a SSRC for the original and one for the retransmission packets. 
It is an advantage if both can be explicitly signalled, but is no 
requirement.
3. Live session with any number of participants and unlimited use of 
dynamic chosen SSRCs.

Due to clients capability the different scenarios need to be explicitly 
signaled. Scenario 2 will be that from an SDP description and support of 
retransmission will be signaled by requesting AVPF in the transport 
header. However today there exist no way to signal if it is scenario 1 
or 3. So this needs to be resolved in a nice backwards compatible way. I 
think that support for 3 can require support for any extra signaling 
while scenario 1 must work without any extra parts.

By doing all these scenarios with a single SETUP per media stream we 
keep the signaling to a minimum and avoid further requirements on SDP. 
It might be advantageous in the future to create a SDP attribute 
declaring the streams type. 

If one desires to control the individual source one either declare 
individual media streams for each source. This will require use of 
ANNOUNCE in dynamic settings. The alternative would be to create a new 
media resource control protocol which is suited for this. However I 
don't see real need to solve this problem in standard RTSP better than 
by using ANNOUNCE.

Regards

Magnus

-- 

Magnus Westerlund

---

From: Go Hori <[email-masked]>
Date: Tue, 15 Oct 2002 11:23:12 -0700 (PDT)

Hi Magnus,

This sounds great!  Thanks for the summary. 
Go