Subject: [MMUSIC] New I-D on RTSP MODIFY Method submitted

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Thu, 2 Sep 2010 01:06:30 +0800

Hi all

I just submitted an I-D title "RTSP MODIFY Method" for enabling transfer
and sharing of RTSP based streaming sessions. The URL for the draft is
http://www.ietf.org/id/draft-avasarala-mmusic-rtsp-modify-00.txt.

Please review and comment.

Regards
Ranjit

---

From: "HAAS Christian" <[email-masked]>
Date: Thu, 2 Sep 2010 10:15:17 +0200

Hello Ranjit!

I've read through the draft and while I like the core idea behind it, I see
several problems with the described approach - or at least, have several
questions :)

While it is mentioned that an active session is the prerequisite for this
method, the examples and parts of the text only rely on the request URI; Yet
it must be the session that is shared or transferred.

Consider a proxy representing two clients for the same resource (two
different sessions) and one wants to 'invite' another client to his session.
To tell the two clients apart, the method must indicate the session ID.

What is the difference between "Share" and "Transfer" ? To me, a Transfer is
like a Share operation, where the originating client releases its control as
soon as possible.

What is actually transferred, and what is to be shared? I guess session
parameters such as playback position and speed will be copied for the new
client. In a shared session, when one client pauses, the other client has a
paused state, too? If that is all the case, then I guess both clients operate
on the same session ID, but that has some more implications. This topic is
not covered at all.

> The RTSP server upon receiving the MODIFY request from the

> source device would use any available mechanism to indicate to the

> destination device about a pending session request.

This text is a little bit too vague to me - First and foremost, how are error
conditions handled? The server immediately responds to the originating
client, while in the background notifies the second client (somehow?). What
if the second client doesn't respond - or acknowledges the invitation, but
does not setup any stream?

While it is clear that in the first draft the details are not fleshed out,
I'm mainly missing the description of the full use-case(s) that are to be
addressed.

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Avasarala Ranjit-A20990
Sent: Mittwoch, 01. September 2010 19:07
To: [email-masked]
Subject: [MMUSIC] New I-D on RTSP MODIFY Method submitted

Hi all 

I just submitted an I-D title "RTSP MODIFY Method" for enabling transfer and
sharing of RTSP based streaming sessions. The URL for the draft is
http://www.ietf.org/id/draft-avasarala-mmusic-rtsp-modify-00.txt
<http://www.ietf.org/id/draft-avasarala-mmusic-rtsp-modify-00.txt> .

Regards 
Ranjit

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 3 Sep 2010 13:11:10 +0800

Hi Christian
 
Thanks for the comments. My reply inline <Ranjit>
 
Regards
Ranjit

________________________________

From: HAAS Christian [mailto:[email-masked]] 
Sent: Thursday, September 02, 2010 1:45 PM
To: Avasarala Ranjit-A20990; [email-masked]
Subject: RE: [MMUSIC] New I-D on RTSP MODIFY Method submitted

Hello Ranjit!

I've read through the draft and while I like the core idea behind it, I see several problems with the described approach - or at least, have several questions :)

While it is mentioned that an active session is the prerequisite for this method, the examples and parts of the text only rely on the request URI; Yet it must be the session that is shared or transferred.

Consider a proxy representing two clients for the same resource (two different sessions) and one wants to 'invite' another client to his session. To tell the two clients apart, the method must indicate the session ID. 

<Ranjit> True. it is the session that will actually be transferred or shared. So the MODIFY method would have the same Request URI as the SETUP, while the Require header would convey

what needs to be done - like Transfer or share. Then the Target header would convey the destination address. Yes the MODIFY method would have Session ID also. 

What is the difference between "Share" and "Transfer" ? To me, a Transfer is like a Share operation, where the originating client releases its control as soon as possible. 

<Ranjit> Sharing is two devices seeing the same thing while transfer would be tranferring the session E.g say Alice is watching a Live vide, she may want to share the same Live video session

with Bob. So now both Alice and Bob would be viewing the same Live video. But say Alice is watching the Live video on her mobile and on coming home, she would like to watch it on her TV. So

here she would "Transfer" the session from her mobile to TV. Once Transferred, the Live video would be on TV and not on mobile.  

What is actually transferred, and what is to be shared? I guess session parameters such as playback position and speed will be copied for the new client. In a shared session, when one client pauses, the other client has a paused state, too? If that is all the case, then I guess both clients operate on the same session ID, but that has some more implications. This topic is not covered at all. 

<Ranjit> The content session is actually transferred or shared.  In case of shared, the sessions would be different, so when one pauses, other need not be in Paused state. yes I did not cover that topic in the I-D. would incorporate that in the next version. 

> destination device about a pending session request.

This text is a little bit too vague to me - First and foremost, how are error conditions handled? The server immediately responds to the originating client, while in the background notifies the second client (somehow?). What if the second client doesn't respond - or acknowledges the invitation, but does not setup any stream?  

<Ranjit> Actually here I intended to propose one or two mechanisms - (1) The RTSP server using SETUP to setup connection with the new device. But this would mean making SETUP bidirectional and is a new enhancement to RTSP SETUP altogether. (2) Another approach I thought was that if RTSP server had the capability  to send IM, it could send the IM with the content

link to the new device and that device would send RTSP SETUP to the server to setup the connection.

Which one do u think is feasible?

While it is clear that in the first draft the details are not fleshed out, I'm mainly missing the description of the full use-case(s) that are to be addressed. 

<Ranjit> Agree. 

Regards,

ch

____________________________________________________
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: [email-masked] [mailto:[email-masked]] On Behalf Of Avasarala Ranjit-A20990
Sent: Mittwoch, 01. September 2010 19:07
To: [email-masked]
Subject: [MMUSIC] New I-D on RTSP MODIFY Method submitted

Hi all 

I just submitted an I-D title "RTSP MODIFY Method" for enabling transfer and sharing of RTSP based streaming sessions. The URL for the draft is http://www.ietf.org/id/draft-avasarala-mmusic-rtsp-modify-00.txt <http://www.ietf.org/id/draft-avasarala-mmusic-rtsp-modify-00.txt> .

Regards 
Ranjit

---

From: "HAAS Christian" <[email-masked]>
Date: Fri, 3 Sep 2010 13:09:30 +0200

Hello again!

From: Avasarala Ranjit-A20990 [mailto:[email-masked]] 
> > What is the difference between "Share" and "Transfer" ? To me, a Transfer
is like a Share operation,

> > where the originating client releases its control as soon as possible. 

> <Ranjit> Sharing is two devices seeing the same thing while transfer would
be tranferring the session

> E.g say Alice is watching a Live vide, she may want to share the same Live
video session with Bob.

> So now both Alice and Bob would be viewing the same Live video. But say
Alice is watching the

> Live video on her mobile and on coming home, she would like to watch it on
her TV.

> So here she would "Transfer" the session from her mobile to TV.

> Once Transferred, the Live video would be on TV and not on mobile.  

Ok, but combined with your comment that actions in one session do not affect
the other (Pause, ...) I still see no difference between sharing and
transferring in respect to the session content. For the server it is
irrelevant whether the second client is operated by another user or the
same...

For a shared session where Alice introduced Bob and Alice drops her session
after some minutes with content still left for Bob, is this then an implicit
Transfer? Or is the session from Bob to be dropped from the server in this
case?

Could it be that the actual 'thing' to be inherited to another client is the
'right' to access given resource?

With "Share" I want to allow a resource, which only I am allowed to access,
to be accessed by a second client (pending the right to do this kind of
operation).

With "Transfer" I want to use a different client to access the resource (or,
more precisely, have another client impersonate me and my rights).

Or, leaving the sidetrack on permissions aside and tackling the whole topic
from a different angle:

What if Alice would send an invitation (i.e. via SIP) to Bob directly,
stating the parameters that effectively clone the session of Alice, i.e.,
resource, playback position, speed, ... and Bob starts the session by
himself?

>From the viewpoint of the server, just a second client with specific
parameters regarding a resource establishes a connection.

I'm sorry, it seems like I haven't understood the actual use-cases
enabled/provided with this extension.

Regards,

ch

 

Hi all 

Regards 
Ranjit

---

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Fri, 3 Sep 2010 11:57:45 -0400

I have a more fundamental question about sharing even more than protocol.  I see the underlying voice-type thinking under this sharing transfer mechanism to mimic a call transfer.  Generally voice on a voice call is not governed by content rights and licensing and other mundane and boring things that actually pay the content creator/owner.  It is far from that in the video world.  In the TV world, when you buy a on-demand video, what you are buying the right to play that movie for a given period of time by a given user that actually goes to pay the operator who carries it and who in turn pays the content owner.  

This breaks the ownership paradigm completely.  Until that question is addressed as well as how do you verify the identity of the transferred-to party etc., this will have a very tough row to hoe

I am not trying to be a PITA but these are legitimate concerns on my part

Regards

Sam

__

Sam Ganesan Ph. D.

Distinguished member, Technical Staff

Motorola On Demand Video Solutions

80 Central Street, Boxborough, MA 01719

tel:+1 978 2647921

mail:[email-masked]

From: [email-masked] [mailto:[email-masked]] On Behalf Of HAAS Christian
Sent: Friday, September 03, 2010 7:10 AM
To: Avasarala Ranjit-A20990; [email-masked]
Subject: Re: [MMUSIC] New I-D on RTSP MODIFY Method submitted

Hello again!

> > What is the difference between "Share" and "Transfer" ? To me, a Transfer is like a Share operation,

> <Ranjit> Sharing is two devices seeing the same thing while transfer would be tranferring the session

> E.g say Alice is watching a Live vide, she may want to share the same Live video session with Bob.

> So now both Alice and Bob would be viewing the same Live video. But say Alice is watching the

> Live video on her mobile and on coming home, she would like to watch it on her TV.

> Once Transferred, the Live video would be on TV and not on mobile.  

Ok, but combined with your comment that actions in one session do not affect the other (Pause, ...) I still see no difference between sharing and transferring in respect to the session content. For the server it is irrelevant whether the second client is operated by another user or the same...

For a shared session where Alice introduced Bob and Alice drops her session after some minutes with content still left for Bob, is this then an implicit Transfer? Or is the session from Bob to be dropped from the server in this case?

Could it be that the actual 'thing' to be inherited to another client is the 'right' to access given resource?

With "Share" I want to allow a resource, which only I am allowed to access, to be accessed by a second client (pending the right to do this kind of operation).

With "Transfer" I want to use a different client to access the resource (or, more precisely, have another client impersonate me and my rights).

Or, leaving the sidetrack on permissions aside and tackling the whole topic from a different angle:

What if Alice would send an invitation (i.e. via SIP) to Bob directly, stating the parameters that effectively clone the session of Alice, i.e., resource, playback position, speed, ... and Bob starts the session by himself?

>From the viewpoint of the server, just a second client with specific parameters regarding a resource establishes a connection.

I'm sorry, it seems like I haven't understood the actual use-cases enabled/provided with this extension.

Regards,

ch

 

Hi all 

Regards 
Ranjit

---

From: "Severa, Michael J (Mike)" <[email-masked]>
Date: Fri, 3 Sep 2010 11:00:23 -0500

Interesting discussion..

I think it would be helpful to be much more explict about what 'sharing' and 'transfering' a stream really mean.  I also think it is unclear whether the goal is to transfer the RTSP channel or the RTP channel, or both.

Personally, I think RTSP may already support both sharing and transfering (using my own definitions) the RTP stream, but it may not be intentional.. (or at least not fully specified..)  I also think it may be possible to have an implementation that transparently allowed sharing or transfering the RTSP stream, just not explicitly. Whether that should be allowed almost seems like a policy question of the RTSP server implementation, more than an RTSP protocol question. Anyway..

RTSP already allows separating the RTSP and RTP 'clients' using the destination (1.0) or dest_addr (2.0) field of the Transport header. Although the spec recommends against sending RTP to a different machine than RTSP, this is exactly how SIP does it, and it's not explicitly illegal (I hope). A SETUP request can be used to update these transport parameters, which of course means these could be updated to 'transfer' the RTP stream to a different destination. This, of course, requires that the 'new' client is involved in the process somehow (it must choose its ports).

Syntactiacally speaking, it is possible to have multiple instances of this field in a transport-spec item. And in fact, 2.0 even acknowledges this by mentioning that 'the usage of multiple destination to distribute a single media to multiple entities is unspecified.'  To me, this means it is currently possible to 'share' an RTP stream using a particular semantic for multiple destination fields (there are likely some other complexities related to things like RTCP and SSRC that I'm glossing over).

Again, perhaps I am not quite getting the use-case either, but it feels like these things are already possible, or at least nearly so..

thanks,

Mike

Sent: Friday, September 03, 2010 4:10 AM

Hello again!

Regards,
ch

E-Mail    [email-masked]<mailto:[email-masked]>

Hi all

I just submitted an I-D title "RTSP MODIFY Method" for enabling transfer and sharing of RTSP based streaming sessions. The URL for the draft is http://www.ietf.org/id/draft-avasarala-mmusic-rtsp-modify-00.txt.

Regards
Ranjit

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Sat, 4 Sep 2010 00:42:44 +0800

Hi Christian
 
My comments <Ranjit>
 
Regards
Ranjit

From: HAAS Christian [mailto:[email-masked]] 
Sent: Friday, September 03, 2010 4:40 PM
To: Avasarala Ranjit-A20990; [email-masked]
Subject: RE: [MMUSIC] New I-D on RTSP MODIFY Method submitted

Hello again!

<Ranjit> By "Transfer" it would be from Device1 to Device2 and Device1 would be dropped. While in "Share" it would be both Device1 and Device2 in the session with Server managing 2 different sessions - Session1 between Device1 and Server while Session2 is between Device2 and Server.  While in Transfer, the session between Device1 and Server would be terminated while the session between Server and Device2 would be active. 

<Ranjit> True. here I intend to include the rights as well. The first device (Device1) would be able to either 'Transfer" or "Share" the session only if the second device (Device2) has rights to access the content (else the transfer or share request should fail - Server could check this). 

>From the viewpoint of the server, just a second client with specific parameters regarding a resource establishes a connection. 

<Ranjit> SIP would work if the devices and server would support SIP. But many RTSP based devices may not support SIP. 

Regards,

ch

 

Hi all 

Regards 
Ranjit