[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] FW: I-D Action:draft-stiemerling-rtsp-announce-01.txt
Hi Sam,
> -----Original Message-----
> From: Ganesan Sam-W00184 [mailto:sam.ganesan at motorola.com]
> Sent: Thursday, March 06, 2008 5:16 PM
> To: Martin Stiemerling; mmusic at ietf.org
> Subject: RE: [MMUSIC] FW: I-D
> Action:draft-stiemerling-rtsp-announce-01.txt
>
> 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.
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.
>
> That is open for discussion obviously.
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
>
>
> Regards
>
> Sam
>
> ___
> Sam Ganesan
> Distinguished member, Technical Staff
> Advanced Engineering
> On Demand Solutions, Motorola
> Tel: 978 264-7921
> Mob: 978 328-7132
> sam.ganesan at motorola.com
>
>
> -----Original Message-----
> From: mmusic-bounces at ietf.org
> [mailto:mmusic-bounces at ietf.org] On Behalf Of Martin Stiemerling
> Sent: Thursday, March 06, 2008 10:33 AM
> To: mmusic at ietf.org
> 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
>
> stiemerling at nw.neclab.eu <== 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: i-d-announce-bounces at ietf.org
> > [mailto:i-d-announce-bounces at ietf.org] On Behalf Of
> > Internet-Drafts at ietf.org
> > Sent: Monday, February 25, 2008 10:15 AM
> > To: i-d-announce at ietf.org
> > 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
> > i-d-announce-request at ietf.org 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:
> > mailserv at ietf.org.
> > 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.
> >
>
stiemerling at nw.neclab.eu <== 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
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic