[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] RTSP multicast question.
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:Christian.Haas at frequentis.com]
Sent: Thursday, July 31, 2008 4:54 PM
To: Magnus Westerlund; Yedidia Amit
Cc: mmusic at ietf.org
Subject: RE: [MMUSIC] RTSP multicast question.
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 christian.haas at frequentis.com
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: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On Behalf Of
Magnus Westerlund
Sent: Donnerstag, 31. Juli 2008 15:07
To: Yedidia Amit
Cc: mmusic at ietf.org
Subject: Re: [MMUSIC] RTSP multicast question.
Yedidia Amit skrev:
> 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.
>
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
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: magnus.westerlund at ericsson.com
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
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
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic