[MMUSIC] RTSP 2.0: Seek-style RAP and conditional execution

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Hi,
(as document author)

During the WG last call I received this comment from two different
individuals.

Logged tracker issue:
https://sourceforge.net/tracker/?func=detail&aid=2890240&group_id=23194&atid=377744

> When using seek-style RAP and repositioning in a playing media: If the RAPs
> are far enough from each other a repositioning request may actually result
> in a media point that is further back the current play position. Thus,
> desired if the repositioning only happened under the condition that the
> client will receive media closer to the desired point.
> 
> Example:
> -- Playback time is at t=15 seconds.
> -- User drags marker forward to seek to t=20 seconds
> -- Client issues the seek (PLAY with appropriate Range)
> -- Server responds starting with a RAP at t=13 seconds;
> our seek forward has made us go backwards!
> 
> The commenters notice it that it would be desirable that the seek only
> happen if playing point gets closer to the desired target.
> 
> Proposals to solve this could be a new seek-style that is conditional.
> Another one is too make the normal on conditional. The question is how to
> indicate why things has happened in a certain way, and how to handle the
> response so this is clear. 

After some thought I think it makes sense to create two different
seek-styles for RAP, one that is conditional and that is not. The reason
is that some clients may aggressively flush its buffer or have a
situation where it needs to really go to a RAP despite that the playing
point was closer to the requested position than the RAP.

Thus if create a new RAP policy, which here will call RAPcond. Then it
would work such that the server when receiving a request will compare
the RAP closet prior to the desired point expressed in the Range header
with the current play-point. If the RAP is closer, than it will 200 ok
and deliver that. However, if the current playing point is closer then
the server could respond with a error message. Thus indicating that it
will continue with the previous request. The error class here isn't
obvious, but I guess a 4xx as we have other pre-conditioned errors here.
Maybe 466 "Media precondition not meet". I don't think 412 fits the bill
as it talks about the resource not being the correct one.

Feedback appreciated.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------