Subject: [MMUSIC] FW: I-D Action:draft-stiemerling-rtsp-announce-01.txt

From: "Martin Stiemerling" <[email-masked]>
Date: Thu, 6 Mar 2008 16:32:30 +0100

Hi all,

This is an updated version of the RTSP 2.0 ANNOUNCE draft. The draft has been discussed during the last IETF meeting, but the WG didn't find a conclusion yet.

The draft argues for introducing semantics for two explicit RTSP server to client asynchronous notifications:
- one for end-of-stream and
- one for end-of-session. 

There is already some embedded end-of-session in RFC 2326bis but it is a bit hidden in REDIRECT. 

I'm still in favour of adding a new method to RTSP 2.0 (ANNOUNCE or any other name) that is used to convey these two asynchronous notifications. 

Any comment?

Thanks,

  Martin

[email-masked]   <== NEW ADDRESS

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014  

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Monday, February 25, 2008 10:15 AM
> To: [email-masked]
> Subject: I-D Action:draft-stiemerling-rtsp-announce-01.txt 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 	Title           : RTSP 2.0 Asynchronous Notification
> 	Author(s)       : T. Ura, et al.
> 	Filename        : draft-stiemerling-rtsp-announce-01.txt
> 	Pages           : 16
> 	Date            : 2008-02-25
> 
> Some IPTV deployments that are using the Real Time Streaming Protocol
> (RTSP) require the ability of the server to notify clients 
> about asynchronous events occurring during an RTSP session.  
> Current deployments typically use the ANNOUNCE method of RTSP 
> 1.0 for sending such asynchronous events from a server to 
> clients by using some proprietary extensions.  However, the 
> ANNOUNCE method has been removed from the current RTSP 2.0 
> draft, leaving the new specification without a mechanism for 
> sending asynchronous messages from the server.  This memo 
> describes a use case for such an asynchronous message and 
> proposes a new RTSP 2.0 method.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-stiemerling-rtsp-ann
> ounce-01.txt
> 
> To remove yourself from the I-D Announcement list, send a 
> message to [email-masked] with the word 
> unsubscribe in the body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then
> 	"get draft-stiemerling-rtsp-announce-01.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-stiemerling-rtsp-announce-01.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Thu, 6 Mar 2008 11:16:27 -0500

Hi:

I second this.  I am completely in favour of adding a method o RTSP 2.0
to provide for a mechanism for asynchronous notifications.  IMHO, it
should stay ANNOUNCE.  Changing it to something else will be just
changing for the sake of change.

One of the questions that come to mind is the following

1.  RTSP specifically in both 1.0 and 2.0 disavow the notion of a
persistent connection.
2.  This draft mandates that the connections should be persistent
between client and server for ANNOUNCE to work.

To make ANNOUNCE a core method and then say that we have to not conform
to one of its basic tenets is, in my mind a philosophical conundrum.

In one particular implementation where we tried not to have persistent
connections, we actually ended up having a RTSP listener on the client
for a call back by the server for asynch notifications and added that
into the sdp with something like the following

m=control 6160 TCP RTSP 
c=IN IP4 172.16.3.170

In the sdp as a separate block so the server could talk back for
asynchronous notifications.

That is open for discussion obviously.

Regards

Sam

___
Sam Ganesan
Distinguished member, Technical Staff
Advanced Engineering
On Demand Solutions, Motorola
Tel:   978 264-7921
Mob: 978 328-7132
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Martin Stiemerling
Sent: Thursday, March 06, 2008 10:33 AM
To: [email-masked]
Subject: [MMUSIC] FW: I-D Action:draft-stiemerling-rtsp-announce-01.txt

Hi all,

This is an updated version of the RTSP 2.0 ANNOUNCE draft. The draft has
been discussed during the last IETF meeting, but the WG didn't find a
conclusion yet.

The draft argues for introducing semantics for two explicit RTSP server
to client asynchronous notifications:
- one for end-of-stream and
- one for end-of-session. 

There is already some embedded end-of-session in RFC 2326bis but it is a
bit hidden in REDIRECT. 

I'm still in favour of adding a new method to RTSP 2.0 (ANNOUNCE or any
other name) that is used to convey these two asynchronous notifications.

Any comment?

Thanks,

  Martin

NEC Laboratories Europe - Network Research Division NEC Europe Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
Registered in England 2832014  

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> (RTSP) require the ability of the server to notify clients about 
> asynchronous events occurring during an RTSP session.
> Current deployments typically use the ANNOUNCE method of RTSP 1.0 for 
> sending such asynchronous events from a server to clients by using 
> some proprietary extensions.  However, the ANNOUNCE method has been 
> removed from the current RTSP 2.0 draft, leaving the new specification

> without a mechanism for sending asynchronous messages from the server.

> This memo describes a use case for such an asynchronous message and 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of

> the message.
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.
>

---

From: Joe Pallas <[email-masked]>
Date: Thu, 6 Mar 2008 09:37:54 -0800

> 1.  RTSP specifically in both 1.0 and 2.0 disavow the notion of a

I don't know what leads you to that conclusion.  Certainly it can't  
be the text in section 10.2 of rfc2326bis that says, "A persistent  
connection MAY be used for all transactions between the server and  
client, including messages for multiple RTSP sessions.  However a  
persistent connection MAY also be closed after a few message exchanges."

Persistent connections are clearly allowed, and I think any  
reasonable person would say they are preferred if asynchronous server  
messages like ANNOUNCE (or whatever it might be called) are to be used.

> for a call back by the server for asynch notifications

Just when you thought the NAT problem couldn't get any worse ....  I  
would strongly oppose an approach that requires the server to be able  
to make a TCP connection to the client.  The difficulties in getting  
that to work through a firewall are overwhelming.

joe

---

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Thu, 6 Mar 2008 12:42:54 -0500

In line 

Sam

-----Original Message-----
From: Joe Pallas [mailto:[email-masked]] On Behalf Of Joe Pallas
Sent: Thursday, March 06, 2008 12:38 PM
To: Ganesan Sam-W00184
Cc: Martin Stiemerling; [email-masked]
Subject: Re: [MMUSIC] FW: I-D
Action:draft-stiemerling-rtsp-announce-01.txt

> 1.  RTSP specifically in both 1.0 and 2.0 disavow the notion of a 

I don't know what leads you to that conclusion.  Certainly it can't be
the text in section 10.2 of rfc2326bis that says, "A persistent
connection MAY be used for all transactions between the server and
client, including messages for multiple RTSP sessions.  However a
persistent connection MAY also be closed after a few message exchanges."

Persistent connections are clearly allowed, and I think any reasonable
person would say they are preferred if asynchronous server messages like
ANNOUNCE (or whatever it might be called) are to be used.

[Sam]
Yes they are allowed, I never said not... But here is the text that led
me to make that statement

	There is no notion of an RTSP connection in the protocol.
Instead,
   an RTSP server maintains a session labeled by an identifier to
   associate groups of media streams and their states.  An RTSP session
   is not tied to a transport-level connection such as a TCP connection.
   During a session, a client may open and close multiple reliable
   transport connections to the server to issue RTSP requests for that
   session.

Just when you thought the NAT problem couldn't get any worse ....  I
would strongly oppose an approach that requires the server to be able to
make a TCP connection to the client.  The difficulties in getting that
to work through a firewall are overwhelming.

[Sam]
The reason I put it out there is because of the NAT problem.  In the
implementation I was looking at it was a closed network.  Yes I am aware
of the issue and I think it needs to be addressed...

joe

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 07 Mar 2008 09:39:16 +0000

> I'm still in favour of adding a new method to RTSP 2.0 (ANNOUNCE or any other name) that is used to convey these two asynchronous notifications. 

Hi,

I am also supporting to add a new method for end-of-stream notification. 
I would discourage against using Announce due to both the confusion 
around RTSP/1.0 Announce and the propreitary extensions existing.

In general I think overloading is a bad practice that RTSP 1.0 has 
suffered greately from. By having RTSP 2.0 being clear that it is likely 
that new methods will be defined for different extensions purposes. Thus 
having a very generic method name for end-of-stream notification seems 
to be bad practice.

When it comes to end-of-session I think we should take a second look on 
what so far is defined. And work from that. If that is overloaded and 
found to have short comming we should fix that in the best possible way.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Martin Stiemerling" <[email-masked]>
Date: Fri, 7 Mar 2008 14:01:20 +0100

Hi Sam, 

> From: Ganesan Sam-W00184 [mailto:[email-masked]] 
> Sent: Thursday, March 06, 2008 5:16 PM
> To: Martin Stiemerling; [email-masked]
> Subject: RE: [MMUSIC] FW: I-D 
> I second this.  I am completely in favour of adding a method 
> o RTSP 2.0 to provide for a mechanism for asynchronous 
> notifications.  IMHO, it should stay ANNOUNCE.  Changing it 
> to something else will be just changing for the sake of change.
> 
> 1.  RTSP specifically in both 1.0 and 2.0 disavow the notion 
> of a persistent connection.

Well, RTSP 2.0 does not disallow persistent connections. 

> 2.  This draft mandates that the connections should be 
> persistent between client and server for ANNOUNCE to work.

Right. However, mandates is too strong. It just says that in order to get this working, client and server do need an open and running TCP connection. Otherwise, the server has no means to send the asynchronous notification to the client. 

> 
> To make ANNOUNCE a core method and then say that we have to 
> not conform to one of its basic tenets is, in my mind a 
> philosophical conundrum.
> 
> In one particular implementation where we tried not to have 
> persistent connections, we actually ended up having a RTSP 
> listener on the client for a call back by the server for 
> asynch notifications and added that into the sdp with 
> something like the following
> 
> m=control 6160 TCP RTSP
> c=IN IP4 172.16.3.170
> 
> In the sdp as a separate block so the server could talk back 
> for asynchronous notifications.
> 

As you said, for closed deployments it is one choice but I don't see this a general choice for the Internet (e.g., NATs, firewalls). 

Thanks,

  Martin

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Martin Stiemerling
> Subject: [MMUSIC] FW: I-D 
> This is an updated version of the RTSP 2.0 ANNOUNCE draft. 
> The draft has been discussed during the last IETF meeting, 
> but the WG didn't find a conclusion yet.
> 
> The draft argues for introducing semantics for two explicit 
> RTSP server to client asynchronous notifications:
> I'm still in favour of adding a new method to RTSP 2.0 
> (ANNOUNCE or any other name) that is used to convey these two 
> NEC Laboratories Europe - Network Research Division NEC 
> Europe Limited | Registered Office: NEC House, 1 Victoria 
> Road, London W3 6BL | Registered in England 2832014  
> 
> message to 
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: Joe Pallas <[email-masked]>
Date: Fri, 7 Mar 2008 06:37:00 -0800

On Mar 7, 2008, at 5:01 AM, Martin Stiemerling wrote:

> Right. However, mandates is too strong. It just says that in order  
> to get this working, client and server do need an open and running  
> TCP connection. Otherwise, the server has no means to send the  
> asynchronous notification to the client.

One thing I think should be included is some discussion about how the  
server associates a TCP connection with an RTSP session.  Obviously,  
the TCP connection that a SETUP request comes in on would be used for  
that session while the connection is active.  If that connection is  
terminated before the session is torn down, and a client establishes  
a new TCP connection before the session times out, the server needs  
to recognize that the new connection is associated with that session.

This doesn't need to be complicated: the last connection that  
received a request with the session-id should probably be the  
connection associated with the session, and the client can achieve  
this by sending a keep-alive style SET_PARAMETER.  But saying so  
explicitly might be a good idea.

joe

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 7 Mar 2008 17:01:03 +0200

> to recognize that the new connection is associated with that session.

That's a pretty good point. Then again, perhaps clients that care about 
ANNOUNCE could simply be required to keep the session open, and servers that 
support ANNOUNCE must not timeout RTSP connections that have one or more 
session "associated" to them (yeah I know in theory there is currently no 
association).

One innocent and clueless question is, why does RTSP allow non-permanent 
connections? One bad reason could be to save server resources - scaling many 
TCP connections is not such a big deal on server-grade operating systems 
nowadays, and many (most?) RTSP clients use persistent connections anyway.
I suppose one good reason may be support for media handovers... ?

When it comes to end-of-stream notification, we could perhaps use an in-band 
mechanism? not sure if RTCP BYE is valid there, but something similar could. 
Also for connection-oriented media, the server could simply reset the 
connection.

> explicitly might be a good idea.

Is Session: valid for OPTIONS requests?

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 07 Mar 2008 15:33:51 +0000

> I suppose one good reason may be support for media handovers... ?

To be robust against faults is definitely part of the answer. It also 
enables support for client movement, and hand-over of the control to 
other parties.

But, in reality connections should really be persistent.

> Also for connection-oriented media, the server could simply reset the 

As discussed both RTCP BYE and reset of connections are not appropriate 
as a client may directly after media have completed a media delivery 
request a new media delivery. Thus having indicated that you not any 
longer are using the SSRC (RTCP BYE) requires on to create a new 
synchronization context, thus potentially reducing media quality.

> Is Session: valid for OPTIONS requests?

Yes, it may be included.

Cheers

Magnus Westerlund

---

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Tue, 18 Mar 2008 15:14:26 -0400

I was thinking about the ANNOUNCE style notification and a second case where the server may have to notify the client of a change is stream format change in terms of say frame rate.  I know it is a hypothetical but it might be worth thinking about as a second case as well

Sam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Friday, March 07, 2008 10:34 AM
To: Rémi Denis-Courmont
Cc: Martin Stiemerling; [email-masked]
Subject: Re: [MMUSIC] FW: I-D Action:draft-stiemerling-rtsp-announce-01.txt

Rémi Denis-Courmont skrev:
> That's a pretty good point. Then again, perhaps clients that care 
> about ANNOUNCE could simply be required to keep the session open, and 
> servers that support ANNOUNCE must not timeout RTSP connections that 
> have one or more session "associated" to them (yeah I know in theory 
> there is currently no association).
> 
> One innocent and clueless question is, why does RTSP allow 
> non-permanent connections? One bad reason could be to save server 
> resources - scaling many TCP connections is not such a big deal on 
> server-grade operating systems nowadays, and many (most?) RTSP clients use persistent connections anyway.

To be robust against faults is definitely part of the answer. It also enables support for client movement, and hand-over of the control to other parties.

> When it comes to end-of-stream notification, we could perhaps use an 
> in-band mechanism? not sure if RTCP BYE is valid there, but something similar could.

As discussed both RTCP BYE and reset of connections are not appropriate as a client may directly after media have completed a media delivery request a new media delivery. Thus having indicated that you not any longer are using the SSRC (RTCP BYE) requires on to create a new synchronization context, thus potentially reducing media quality.

Yes, it may be included.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Mar 2008 09:51:56 +0100

> I was thinking about the ANNOUNCE style notification and a second case where the server may have to notify the client of a change is stream format change in terms of say frame rate.  I know it is a…

I think frame rate is a bad example as all the video codecs I know 
supports such changes without signalling. But I assume you mean cases 
where the media configuration information changes, i.e. classic RFC 2326 
Announce with a new SDP or so. What I think was missing in the 2326 was 
the lack of synchronization information on when new configurations do 
apply within already setup streams. You also get into the problem of 
having the number of streams change due to this, which will require 
further RTSP SETUP messages to establish the communication.

Cheers

Magnus Westerlund