[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] RTSP: PLAY_NOTIFY
Hi Christian,
stiemerling at nw.neclab.eu
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: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On
> Behalf Of HAAS Christian
> Sent: Tuesday, November 04, 2008 10:37 AM
> To: mmusic at ietf.org
> Subject: [MMUSIC] RTSP: PLAY_NOTIFY
>
> Hello!
>
> Regarding the PLAY_NOTIFY method I wonder why it needs to be called
> PLAY_NOTIFY, and not simply NOTIFY;
>
> The actual meaning of the message is derived from the "Notify-Reason"
> header - an already neutral name - and its values. The context of the
> operation is already referenced both through the media control (PLAY)
> and/or the "Request-Status" header, which references the original
> request in question (also, PLAY).
It is a matter of taste, but the name was chosen to avoid confusion about
in which context this method can be used.
>
> What I'm having in mind are later extensions, such as the dedicated
> RECORD feature which as well might require the server to notify the
> client of an event (like: disk full). Instead of creating another new
> method RECORD_NOTIFY I'd simply like to reuse the existing NOTIFY with
> Notify-Reason and put in a new reason value.
Well, there is of course always space for extensions but the current
documented use case is in draft-stiemerling-rtsp-announce. A future use
case does not help, as there are many of them ;)
Anyhow, the semantics of PLAY_NOTIFY are somewhat depend on the PLAY
status and in other yet defined states we do not need an asynchronous
notification.
Martin
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic