RTSP multicast question.

[Yedidia Amit-2]

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: amit.yedidia@...

Tel: [phone]

----------------------------------------------------------

 

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@...
https://www.ietf.org/mailman/listinfo/mmusic

[Rémi Denis-Courmont-6]

On Wednesday 30 July 2008 18:02:33 Yedidia Amit, you wrote:
> All other commands (SETUP,PLAY) will be supported as no-op for interop.
>
> Is that possible by the standard point of view?

Not that I know.

> Is such approach will be
> supported by standard clients (QuickTime, VLC etc...)

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
_______________________________________________
mmusic mailing list
mmusic@...
https://www.ietf.org/mailman/listinfo/mmusic

[Magnus Westerlund]

Yedidia Amit skrev:

> 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…)
>
>

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 [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@...
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic@...
https://www.ietf.org/mailman/listinfo/mmusic

[Yedidia Amit-2]

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.

Email: amit.yedidia@...
Tel: [phone]
----------------------------------------------------------


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

On Wednesday 30 July 2008 18:02:33 Yedidia Amit, you wrote:
> All other commands (SETUP,PLAY) will be supported as no-op for interop.
>
> Is that possible by the standard point of view?

Not that I know.

> Is such approach will be
> supported by standard clients (QuickTime, VLC etc...)

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

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@...
https://www.ietf.org/mailman/listinfo/mmusic

[Magnus Westerlund]

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 [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@...
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic@...
https://www.ietf.org/mailman/listinfo/mmusic

[Christian Haas]

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   [phone] - 8353
Mobile   [phone] - 8353
Fax       [phone] - 77 8353
Web      www.frequentis.com
E-Mail    christian.haas@...
 
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@... [mailto:mmusic-bounces@...] On Behalf Of
Magnus Westerlund
Sent: Donnerstag, 31. Juli 2008 15:07
To: Yedidia Amit
Cc: mmusic@...
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 [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@...
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic@...
https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic@...
https://www.ietf.org/mailman/listinfo/mmusic

[Yedidia Amit-2]

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@...]
Sent: Thursday, July 31, 2008 4:54 PM
To: Magnus Westerlund; Yedidia Amit
Cc: mmusic@...
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   [phone] - 8353
Mobile   [phone] - 8353
Fax       [phone] - 77 8353
Web      www.frequentis.com
E-Mail    christian.haas@...
 
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@... [mailto:mmusic-bounces@...] On Behalf Of
Magnus Westerlund
Sent: Donnerstag, 31. Juli 2008 15:07
To: Yedidia Amit
Cc: mmusic@...
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 [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@...
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic@...
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@...
https://www.ietf.org/mailman/listinfo/mmusic

[Magnus Westerlund]

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 [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@...
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic@...
https://www.ietf.org/mailman/listinfo/mmusic

[Rémi Denis-Courmont-7]

On Thursday 31 July 2008 21:05:49 ext Yedidia Amit, you wrote:
> 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).

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
mmusic@...
https://www.ietf.org/mailman/listinfo/mmusic

[Yedidia Amit-2]

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: amit.yedidia@...
Tel: [phone]
----------------------------------------------------------


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

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 [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: 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
mmusic@...
https://www.ietf.org/mailman/listinfo/mmusic

[Magnus Westerlund]

Yedidia Amit skrev:

> 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?

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

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

[Magnus Westerlund]

Rémi Denis-Courmont skrev:

> On Thursday 31 July 2008 21:05:49 ext Yedidia Amit, you wrote:
>> 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).
>
> 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.
>

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

Cheers

Magnus Westerlund

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

[Rémi Denis-Courmont-6]

Le lundi 4 août 2008 17:47:17 Magnus Westerlund, vous avez écrit :

> Rémi Denis-Courmont skrev:
> > On Thursday 31 July 2008 21:05:49 ext Yedidia Amit, you wrote:
> >> 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).
> >
> > 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.
>
> In other words request that the streaming sever deliver media to the
> specified multicast group?

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/
_______________________________________________
mmusic mailing list
mmusic@...
https://www.ietf.org/mailman/listinfo/mmusic

[Christian Haas]

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 :)

From: Magnus Westerlund [mailto:magnus.westerlund@...]

> 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.

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   [phone] - 8353
Mobile   [phone] - 8353
Fax       [phone] - 77 8353
Web      www.frequentis.com
E-Mail    christian.haas@...
 
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.


_______________________________________________
mmusic mailing list
mmusic@...
https://www.ietf.org/mailman/listinfo/mmusic

[Magnus Westerlund]

HAAS Christian skrev:

> 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 :)
>
> From: Magnus Westerlund [mailto:magnus.westerlund@...]
>> 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