Subject: [MMUSIC] RTSP multicast question.

From: "Yedidia Amit" <[email-masked]>
Date: Wed, 30 Jul 2008 18:02:33 +0300

Dear experts,

I am planning a sytems which had a great delay problem, so I want to
reduce the set of RTSP commands needed to establish a connection.
The system sends multicast video but only if there at least one
subscriber.

My approach is to use the DESCRIBE and TEARDOWN  commands only.

On the first DESCRIBE, the server will initate a multicast session and
return its connection details to the client (in SDP format).
Any other DESCRIBE will receive the same sdp. All DESCRIBE commands
increment an internal counter by 1.

Client who wish to disconnect sends TEARDOWN. It will decrement the
counter by 1. If the counter is 0 the multicast will be stoppped.

All other commands (SETUP,PLAY) will be supported as no-op for interop.

Is that possible by the standard point of view? Is such approach will be
supported by standard clients (QuickTime, VLC etc...)

Regards,

Amit Yedidia
Elbit System Ltd.

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

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: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 30 Jul 2008 18:10:48 +0300

On Wednesday 30 July 2008 18:02:33 Yedidia Amit, you wrote:
> Is that possible by the standard point of view?

Not that I know.

> Is such approach will be 

VLC supports the (from Amino? IIRC) x-playNow SETUP undocumented proprietary 
extension on the server-side, but I would not recommend it. Besides, VLC does 
not reference count multicast RTSP (it streams all the time, even if there's 
no client).

-- 
Rémi Denis-Courmont

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 30 Jul 2008 19:40:11 +0100

Yedidia Amit skrev:
> The system sends multicast video but only if there at least one subscriber.
> 
> supported by standard clients (QuickTime, VLC etc…)
> 
> 

In RTSP 2.0 (draft-ietf-mmusic-rfc2326bis) there is the pipelined 
request that allows one to send all setup and the play request in a 
single sequence without waiting for any response.

This has also been defined by 3GPP for RTSP 1.0 in 3GPP TS 26.234.

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: "Yedidia Amit" <[email-masked]>
Date: Thu, 31 Jul 2008 07:58:09 +0300

Let me be more clear.
I am developing the server side, and I want to be able to work with standard clients.

In RFC2326 Appenix A, it is mentioned that on multicast session an explicit SETUP is not required.
For my understanding in that case PLAY is also not required since after the DESCRIBE reply the client got all it needs, and the clients don't actually control the stream.

All I am adding in my server side is to count PLAY/TEARDOWN commands to maintain a listener counter.
I don't understand why this approach may not apply to the RFC2326 requirements.

Regards,

Amit Yedidia
Elbit System Ltd.

-----Original Message-----
From: Rémi Denis-Courmont [mailto:[email-masked]] 
Sent: Wednesday, July 30, 2008 6:11 PM
To: [email-masked]
Cc: Yedidia Amit
Subject: Re: [MMUSIC] RTSP multicast question.

Not that I know.

-- 
Rémi Denis-Courmont

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 31 Jul 2008 14:06:30 +0100

> I don't understand why this approach may not apply to the RFC2326 requirements.

Ahaa, that made things much clearer. You simply are using RTSP as media 
configuration deliver mechanism, like SAP or HTTP could do.

There is no support in RTSP today for your usage. The problem with RTSP 
in this use cases is that the SETUP and play/pause and teardown doesn't 
affect the media delivery. That makes it not clear cut that RTSP is the 
most appropriate mechanism for simply saying, I am joining, I am 
leaving. I have not thought about how appropriate there would be to add 
something like this as an extension.

Cheers

Magnus Westerlund

---

From: "HAAS Christian" <[email-masked]>
Date: Thu, 31 Jul 2008 15:54:05 +0200

Hello!

In my opinion, the use case can be covered with RTSP - if you look at the
things a slightly different way (Please correct me if my view is wrong ;)

First I'll summarize what I understood from the requirements:
A server has a multicast stream that is available to anyone, all the time
(the server is always in the state Playing). To save resources, the actual
stream is sent only after the first client registers for it and stopped after
the last one left.

I'd have the DESCRIBE method not change the servers client count - it's
simply the question 'What do you have?'.
Instead, the client count is a sort of state at the server, and I'd have this
state changed with a SETUP/TEARDOWN pair per client. When using timeouts with
the established session, the TEARDOWN can be omitted. The Transport header in
the SETUP would simply state "RTP/AVP;multicast" - all other parameters
default to those from SDP.

Admittedly, there is a difference to the RFC in the sense that after the
session has been 'created', it is already in the state Playing.

Thinking a bit further I'll take a different approach: There is already one
RTSP 'session' - the one that the server created by itself (since it is
always in the state Playing). I'd then go ahead and require the clients to
keep this only one session alive (identifier is taken from SDP). The amount
of hosts that is keeping this session alive is the amount of listeners. When
the server is the only one, it stops streaming.
Still, this requires some handiwork on the client, but it looks like to be
covered by RTSP...

So far for my first post on this list :)
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. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Magnus Westerlund
Sent: Donnerstag, 31. Juli 2008 15:07
To: Yedidia Amit
Cc: [email-masked]
Subject: Re: [MMUSIC] RTSP multicast question.

Yedidia Amit skrev:
> For my understanding in that case PLAY is also not required since after the
DESCRIBE reply the client got all it needs, and the clients don't actually
control the stream.

Cheers

Magnus Westerlund

---

From: "Yedidia Amit" <[email-masked]>
Date: Thu, 31 Jul 2008 21:05:49 +0300

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.

-----Original Message-----
From: HAAS Christian [mailto:[email-masked]] 
Sent: Thursday, July 31, 2008 4:54 PM
To: Magnus Westerlund; Yedidia Amit
Cc: [email-masked]
Subject: RE: [MMUSIC] RTSP multicast question.

Hello!

 

-----Original Message-----

Cheers

Magnus Westerlund