Subject: Re: [MMUSIC] RTSP multicast question.

From: Magnus Westerlund <[email-masked]>
Date: Mon, 04 Aug 2008 14:56:52 +0200

Yedidia Amit skrev:
> Thank you for your detaild answers, but I think you missed the point.
> 
> I am using RTSP as media configuration delivery mechanism, as Magnus wrote, since I want to be able to use standard clients (QuickTime, VLC)
> I want than no changes should be done at the client side (otherwise I would developed a full proprietary protocol).
> 
> My goal is that a standard client will be able to communicate with my server and receive configuration as it would do with any other RTSP based media server.
>>From that point of view is there a prolem with my proposed approach?
> 
> Thank you again.
> Amit.

The problem with your approach is that Describe is stateless. Only SETUP 
creates RTSP sessions. Then there is the question of keep-alive. 
Everything in RTSP is built around the RTSP session concept. Thus unless 
one creates an RTSP session Teardown doesn't have any context to operate on.

Secondary, the problem with standard RTSP is that the meaning of RTSP 
SETUP with Transport header specifying a destination of a multicast 
group is ambiguous. As I see there are two alternative semantics:

1. Please setup media delivery to this provided multicast group. Thus 
RTSP is the multicast group owners way of controlling media being 
delivered to the media delivery channel.

2. Bind a client to a pre-existing multicast delivery channel to allow 
for extended unicast signalling around the provided media. Where the 
RTSP client gets a state but many operation are not allowed due to 
restricted permissions for a regular client.

I think it would be good to figure this out in the context of RTSP 2.0.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 4 Aug 2008 16:04:29 +0300

On Thursday 31 July 2008 21:05:49 ext Yedidia Amit, you wrote:
> I am using RTSP as media configuration delivery mechanism, as Magnus wrote,
> since I want to be able to use standard clients (QuickTime, VLC) I want
> than no changes should be done at the client side (otherwise I would
> developed a full proprietary protocol).

If you put a multicast address in the c= line(s) and proper (non-zero) port 
numbers in the m= line(s), VLC will try to setup the media using multicast, 
as normal (DESCRIBE, SETUP, PLAY...). I assume Quicktime does the same.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Yedidia Amit" <[email-masked]>
Date: Mon, 4 Aug 2008 16:16:24 +0300

Magnus,

I agree with the ambiguity that SETUP method should cause in multicast scenarios.
This is exactly the case described in RFC2326 Appendix A (section A.1 and A.2) come to resolve:

About client state (A.1 pg. 76):
"If no explicit SETUP is required for the object (for example, it is available via a multicast group),
state begins at Ready. In this case, there are only two states, Ready and Playing. The client also
changes state from Playing/Recording to Ready when the end of the requested range is reached."  

About server state (A.2 pg. 78):
"If no explicit SETUP is required for the object, the state starts at
Ready and there are only two states, Ready and Playing.

Which means that session may be created by the server witout explicit SETUP command, (maybe by some internal configuration).

Do you agree?

Regards,

Amit Yedidia
Elbit System Ltd.

Email: [email-masked]
Tel: 972-4-8318905
----------------------------------------------------------

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Monday, August 04, 2008 3:57 PM
To: Yedidia Amit
Cc: HAAS Christian; [email-masked]
Subject: Re: [MMUSIC] RTSP multicast question.

Cheers

Magnus Westerlund

The information in this e-mail transmission contains proprietary and business 
sensitive information.  Unauthorized interception of this e-mail may constitute 
a violation of law. If you are not the intended recipient, you are hereby 
notified that any review, dissemination, distribution or duplication of this 
communication is strictly prohibited. You are also asked to contact the sender 
by reply email and immediately destroy all copies of the original message.
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 04 Aug 2008 16:46:08 +0200

> Which means that session may be created by the server witout explicit SETUP command, (maybe by some internal configuration).

I would say that this is just an example of one more case of RFC 2326 
brokenness. Yes, re-reading the text that exist around session IDs 
indicate that the RTSP session could be generated in other ways than 
using SETUP. However, how this is accomplished or how one actually can 
use that state isn't specified. There is one hint that dynamic RTSP URIs 
could be used to indicate a specific session. But, nothing is specified 
that makes this implementable. Open issues that I directly see are:

- How to go from a URI to a session ID header?

- In which methods that one can use this and how the operations affect 
the state machine?

- What happens to the session identified when one does Teardown?

I would also like to point out that using the same session ID for 
multiple clients are not allowed according to this text in section 12.37:

    Note that a session identifier identifies a RTSP session across
    transport sessions or connections. Control messages for more than one
    RTSP URL may be sent within a single RTSP session. Hence, it is
    possible that clients use the same session for controlling many
    streams constituting a presentation, as long as all the streams come
    from the same server. (See example in Section 14). However, multiple
    "user" sessions for the same URL from the same client MUST use
    different session identifiers.

So I would still say that there only exist an embryo to potential 
solutions for what you want to do. And if you expect RTSP 1.0 clients to 
do something like this then I wouldn't expect interoperability. I would 
be surprised if any has the functionality.

As I see it the right way forward would be to discuss this in the 
context of changes and extensions to RTSP 2.0 that would allow what you 
want to be worked into a coherent behavior.

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 04 Aug 2008 16:47:17 +0200

> as normal (DESCRIBE, SETUP, PLAY...). I assume Quicktime does the same.

In other words request that the streaming sever deliver media to the 
specified multicast group?

Cheers

Magnus Westerlund

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 4 Aug 2008 18:02:42 +0300

Le lundi 4 août 2008 17:47:17 Magnus Westerlund, vous avez écrit :
> >> I am using RTSP as media configuration delivery mechanism, as Magnus
> >> wrote, since I want to be able to use standard clients (QuickTime, VLC)
> >> I want than no changes should be done at the client side (otherwise I
> >> would developed a full proprietary protocol).
> >
> > If you put a multicast address in the c= line(s) and proper (non-zero)
> > port numbers in the m= line(s), VLC will try to setup the media using
> > multicast, as normal (DESCRIBE, SETUP, PLAY...). I assume Quicktime does
> > the same.
>

Yes. At least, that's how I recall Live555 RTSP stack works (that being the 
RTSP client stack in VLC at the moment). In yet other words, the server 
(configuration) decides whether and to which group to send multicast to.

In theory, I suppose RTSP client could just try to setup multicast by default, 
and fallback to unicast... but that involve the client agent "computing" 
an "appropriate" multicast group, whatever that means. Sounds brittle :(

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: "HAAS Christian" <[email-masked]>
Date: Mon, 4 Aug 2008 17:10:05 +0200

Hello!

I have to point out one paragraph since it puzzles me a bit - if not even
throws over my view of RTSP so far :)

>    different session identifiers.

I'd have read this paragraph (and others) that controlling one stream from
several different clients is indeed possible - especially with the first
sentence.;
For example, in RFC 2326, 1.1 'Invitation of a media server to a conference':
"... Several parties in the conference may take turns 'pushing the remote
control buttons' ".
So far I have interpreted RTSP to be a control mechanism that allows sharing
of the controls [for shared resources, such as multicast streams, where this
makes sense].
How the session identifier is distributed was out of the scope, but that I'd
have SDP considered for.

I interpreted the last sentence of your quoted paragraph with respect to
multiple dedicated streams. When starting a RealPlayer twice for example on
the same host, requesting the same file will generate two streams (two
sessions).

This was the base of my second idea for our use case to have all clients keep
alive the one session the server controls; and the session identifier I'd
have taken from SDP (for example the 's' field).

Regards,
ch
____________________________________________________
Christian Haas
Team DIVOS, Software Engineer
FREQUENTIS AG

Innovationsstraße 1, 1100 Vienna, Austria
Phone   +43-1-811 50 - 8353
Mobile   +43-664-60 850 - 8353
Fax       +43-1-811 50 - 77 8353
Web      www.frequentis.com
E-Mail    [email-masked]
 
Handelsgericht Wien (Vienna Commercial Court): FN 72115 b
DVR 0364797, ATU 14715600
____________________________________________________
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser E-Mail sind nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 04 Aug 2008 17:37:26 +0200

> have taken from SDP (for example the 's' field).

Well, then this is one more example of the inconsistencies of RFC 2326.

Having multiple client instances control the same session may be of 
interest, but it is not a thought through solution as one needs to 
ensure consistent handling of the RTSP state and provide a working 
security model for this. Something that I would claim is not in place in 
either RFC 2326 or in the RTSP 2.0 draft.

If you go read RTSP 2.0 it says in section 3.4 (version 18):

    If one has an established conference or group session, it is possible
    to have an RTSP server distribute media to the whole group.
    Transmission to the group is simplest when controlled by a single
    participant or leader of the conference.  Shared control might be
    possible, but would require further investigation and possibly
    extensions.

Cheers

Magnus Westerlund

---

From: "Yedidia Amit" <[email-masked]>
Date: Mon, 4 Aug 2008 21:39:32 +0300

Thank you all for your comments.
Now lets consider again the following scenario:
One media server which manage multiple live streams only - all the streams are sent by multicast to the local network.
Several clients (e.g. VLC) who send DESCRIBE receive SDP with the multicast details.
What is stopping them to receive the stream properly.( Even if they send SETUP and PLAY they will be answered with 200 ok)
All other controls are not relevant for this case (like PAUSE will not be supported -since this is live multicast)
What is wrong with that? Don't forget that I control the server to do whatever I want.

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Monday, August 04, 2008 6:37 PM
To: HAAS Christian
Cc: Yedidia Amit; [email-masked]
Subject: Re: [MMUSIC] RTSP multicast question.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 05 Aug 2008 11:26:19 +0200

Yedidia Amit skrev:
> What is wrong with that? 

Clearly using RTSP to retrieve the SDP with all the details it needs are 
workable. However, here we get to the issues:

A client that retrives a SDP with filled in c= lines to a multicast 
address. What should they do? I don't think we have a clear standardized 
behavior here. At least two alternatives exist:

1. Stop with RTSP and simple use the SDP, like RTSP describe was SAP or 
one downloaded the SDP in HTTP or received it over email.

2. Use RTSP to perform SETUP on the media streams.

If one do 2 then one comes to the next question:

3. How does I separate this case A) when I simply want to indicate that 
I am listing to a multicast group that I can't affect from B) where I 
want to ask the server to please deliver the media to a multicast group 
of my choice. To me both A) and B) are valid use cases.

4. What does it mean to perform PLAY on a multicast group where you will 
receive media as soon as you perform the IGMP join?

5. Are there well defined signaling to have the client understand that 
sending PAUSE will not do anything. Sure trying and failing will carry 
that message, but unless the client is aware of these cases he might 
think everything is broken and take error recovery actions.

The main point I like to make is that we clearly can support some use 
cases around multicast with RTSP. However, it needs to be written up in 
such a way that clients and servers are interoperable. I also think it 
will need to be motivated correctly because otherwise client implementor 
will not understand why they should care for a case where the client use 
SETUP as way of registering its listing to the multicast group.

If you can contribute this in draft specification text to RTSP 2.0 we 
clearly can have the WG consider to add it. I personally would like to 
see it written up. But I have enough to work on the RTSP 2.0 core that I 
don't going to branch out to cover this.

Cheers

Magnus Westerlund

---

From: "Yedidia Amit" <[email-masked]>
Date: Wed, 6 Aug 2008 11:06:58 +0300

> don't going to branch out to cover this.

I think that this is exactly the difference bewteen the two options you
mentioned in Q3.

When the multicast is controlled by the server/other client, a DESCRIBE
is enough for the client to get all 
The connection details and join the multicast. Since the stream is not
controlled by him, it is obviuos that control methods like:
SETUP,PAUSE, TEARDOWN are not needed and should be ignored by the
server.
However if the client want to setup a NEW multicast stream, then he must
use the SETUP method, since this is the only command to set a new
stream.
I think it should be obvious that in muticast scenarios only the
master/creator of the stream can control it.
I agree there is a lack of special method to tell the server that a new
listener has joined. Which is exactly my problem.
Maybe PLAY without SETUP can be a solution....

BTW,I will honored to help with the RTSP 2.0.

---

From: Ross Finlayson <[email-masked]>
Date: Wed, 13 Aug 2008 23:20:00 -0700

>Clearly using RTSP to retrieve the SDP with all the details it needs 
>are workable. However, here we get to the issues:
>
>address. What should they do? I don't think we have a clear 
>standardized behavior here. At least two alternatives exist:
>
>1. Stop with RTSP and simple use the SDP, like RTSP describe was SAP 
>or one downloaded the SDP in HTTP or received it over email.
>
>3. How does I separate this case A) when I simply want to indicate 
>that I am listing to a multicast group that I can't affect from B) 
>where I want to ask the server to please deliver the media to a 
>multicast group of my choice. To me both A) and B) are valid use 
>cases.

Yes.  Note, BTW, that case A) is what is already described as an 
example in section 14.4 of RFC 2326 (RTSP 1.0); it's also the 
"Multicast, server chooses address" option described in section 1.6. 
So there's really nothing weird or unusual about this.  Several 
existing clients (including VLC and QuickTime Player) support this, 
and have done so for years.  It continues to baffle me that so many 
people think that RTSP is used only for playing unicast streams, when 
there both documentation and widespread use to the contrary.

As for how to do case B), once again RTSP 2326 gives an answer - in 
section 12.39, where - in the description of the "destination" 
parameter, it says:
	"The client may specify the multicast address with the 
destination parameter."
I.e., a client could specify its chosen multicast address using the 
"destination" parameter in the "Transport:" header in the RTSP 
"SETUP" request.  However, I don't know of any clients that support 
this, and there are probably few (if any) servers that support it, 
because of the potential for denial-of-service attacks (an issue 
which is also described in section 12.39).

>4. What does it mean to perform PLAY on a multicast group where you 
>will receive media as soon as you perform the IGMP join?

In this case the "PLAY" operation is really just a no-op (although 
the client might still find some information in the "PLAY" response 
useful - e.g., the "Range:" header could be used to indicate the 
stream's duration, in case such information was not already present 
in the SDP description (a "t=..." line)).

>The main point I like to make is that we clearly can support some 
>use cases around multicast with RTSP.

Yes, we clearly can, and in fact already do :-)

>  However, it needs to be written up in such a way that clients and 
>servers are interoperable. I also think it will need to be motivated 
>correctly because otherwise client implementor will not understand 
>why they should care for a case where the client use SETUP as way of 
>registering its listing to the multicast group.

Yes, I agree.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/