Subject: [MMUSIC] Review of Section 10 - RTSP Feature table

From: Gayathri Ramakrishnan <[email-masked]>
Date: Thu, 27 Jun 2002 11:32:26 +0530

Hi,

Attached is the reviewed Section 10 of the
RTSP Feature matrix.  Comments for some of
them are included inline.

I also have some general queries (see
towards the end of the doc). Pl clarify 
the same.

Thanks,
Gayathri
-- 
We pause, to soar higher.
http://cdn.hcltech.com

SRV=Server
PRY=Proxy
CLT=Client

Keys for requirements explicitly callout
M=MUST
MN=MUST NOT
SD=SHOULD
SDN=SHOULD NOT
SL=SHALL
SLN=SHALL NOT
MAY=MAY
NA=NOT APPLICABLE
OPT=OPTIONAL
REQ=REQUIRED
REC=RECOMMENDED

Keys for requirements implicitly callout
m=must
mn=must not
sd=should
sdn=should not
sl=shall
sln=shall not
may=may
na=not applicable
opt=optional
req=required
rec=recommended

Other Keys
desc=describe
para=parameter
mthd=method
recd=recording
conf=conference
info=information
pres=presentation
attr=attribute
app=application
init=initialization
id=identifier
req=required
diff=different
avail=available
sync=synchronize
auth=authenticate

  LINE FEATURE SUMMARY                         SECTION         SRV PRY CLT
  1656request may be issued at any time       10.1 OPTIONS    may may may
      **Proxy may be able to send OPTIONS
        request on behalf of the client or
	on its own in case of multicast??
  1657It does not influence SRV state.        10.1 OPTIONS    must info info
  1688retrieves desc.                         10.2 DESCRIBE   info info info
  1690Accept header to specify desc. formats  10.2 DESCRIBE   na    may  may
  1691SRV responds withdesc.                  10.2 DESCRIBE   must  -    -
  1692reply-response pair constitutes media   10.2 DESCRIBE   init init init
      ** The RFC could be modified to call
         this as request-response pair.
  1721MUST contain all media init.            10.2 DESCRIBE   M    M     M
  1722info. for resource(s)it describes       10.2 DESCRIBE   req  -    -
  1723fromsource or than DESCRIBE             10.2 DESCRIBE   may  may  may
  1724containscomplete set of media init.     10.2 DESCRIBE   may  may  may
  1725CLT SHOULD use those para.              10.2 DESCRIBE   SD   SD   SD
  1729of media indirection.                   10.2 DESCRIBE   SDN  SDN  SDN
      ** Could be changed to
      ** SHOULD NOT DESCResp of media 
      ** indirection
  1732  unambiguous means of knowing          10.2 DESCRIBE   -  req  req
  1742contain all media init. for set of strea10.2 DESCRIBE
  1743discouraging use of DESCRIBE for media i10.2 DESCRIBE   rec rec rec
  1744avoid looping problems                  10.2 DESCRIBE   must must must
  1747  Media init. isrequirement             10.2 DESCRIBE   req req req
  1748does not dictatemust be done            10.2 DESCRIBE   m   m  m
  1752  * via RTSP's DESCRIBE mthd;           10.2 DESCRIBE   may  may  may
  1753  * via some or protocol (HTTP, email at10.2 DESCRIBE   may  may  may
  1754  * via command line or standard input  10.2 DESCRIBE   may  may  may
  1759recommendedminimal SRVs support         10.2 DESCRIBE   rec rec rec
  1760recommendedminimal CLTs support         10.2 DESCRIBE   rec rec rec
  1761acceptsmedia init. file                 10.2 DESCRIBE   rec rec rec
  1762  from standard input, command line, and10.2 DESCRIBE   rec rec rec
  1769posts desc.                             10.3 ANNOUNCE   must must must
  1770media object identified by request URL  10.3 ANNOUNCE   must must must
  1771updates session desc.                   10.3 ANNOUNCE   must must must
  1775whole pres desc. should be sent         10.3 ANNOUNCE   sd   sd   sd
  1776rarther than just additional components 10.3 ANNOUNCE

  1813request forURI specifies transport mecha10.4 SETUP      m    m    m 
  1815can issue a SETUP request for a                         may  may  may 
      stream that is already playing 
  1816 Server MAY allow                       10.4 SETUP      MAY  na   na 
    *** Here 1815 condition is split into 
    *** two different conditions. 
  1816If it does not allow this, it MUST respo10.4 SETUP      MAY  MAY  MAY 
      error "455 mthd Not Valid In State" 
    *** This condition could be combined 
    *** with 1817. Is there any specific 
    *** reason to say both MUST and MAY for 
    *** this case? Or MMAY should be 
    *** interpreted differently. 
  1818intervening firewalls,CLT must indicate 10.4 SETUP      na   m    m 
  1822  Since SETUP includes all transport ini10.4 SETUP      na   m    m 
  1828specifies transport para. acceptable    10.4 SETUP      req  req  req 
  1829CLT for data transmission               10.4 SETUP      n/a  req  req 
  1830transport para. selected by SRV.        10.4 SETUP      req  req  na 
  1843SRV generates session id.s              10.4 SETUP      m    na   na 
  1845 SRV MUST bundle setup request          10.4 SETUP      M    na   na 
  1854return error "459 agg. Operation Not All10.4 SETUP      M    ?    na 
  1859tells SRV to start sending data         10.5 PLAY       m    m    m 
  1861SETUP requests have been acknowledged   10.5 PLAY       na   MN   MN 
    *** Could this condition be considered 
    *** as explicit callout MUSTNOT. 
  1864positions normal play time to beginning 10.5 PLAY       m    na   m 
  1865delivers stream data until end          10.5 PLAY       m    m    na 
  1866requests may be pipelined (queued)      10.5 PLAY       may  na   na 
  1867MIUST queue PLAY requests to be executed10.5 PLAY       M    M    M 
  1869delayed until first has been completed. 10.5 PLAY       m    na   na 
  1871allows precise editing.                 10.5 PLAY       info info info 
  1895PLAY request without Range header legal 10.5 PLAY       m    m    m 
  1896beginning unless stream has been paused 10.5 PLAY       m    m    na 
  1897paused via PAUSE, stream delivery resume10.5 PLAY       m    m    na 
  1899can be used by CLT to test SRV liveness.10.5 PLAY       may  may  may 
  1910containt time parameter                 10.5 PLAY       may  may  may 
  1911specifies time in UTC                   10.5 PLAY       sd   sd   sd 
  1912msgreceived after specified time        10.5 PLAY       m    na   na 
  1913aid sync of streams obtained from 
     diff sources.                            10.5 PLAY       may  may  may 
    *** 1913 and 1914 together indicates 
    *** sync. So they could be combined. 
  1916SRV replies with actual range           10.5 PLAY       m    m    na 
  1918 resp range may differ from requested 
       range                                  10.5 PLAY       may  may  may 
    *** This line could be included instead 
    *** of 'allignment of requested range 
    *** to valid frame' 
  1920current position returned in reply      10.5 PLAY       m    ?    na 
  1921unit range in reply same as in request. 10.5 PLAY       req  req  na 
  1923pres automatically pause                10.5 PLAY       m    m    na 
  1941live desirable to use clock units:      10.5 PLAY       rec  rec  rec 
  1952only supporting playback MUST support np10.5 PLAY       M    M    M 
  1953MAY support clock and smpte formats.    10.5 PLAY       MAY  MAY  MAY 

  1968stream delivery to be interrupted       10.6 PAUSE      m    m    m
      ** Capability of the client to stop
      ** stream delivery has been
      ** interpreted as an implicit 'must'
      ** for client
  1970playback and recd ofstream halted       10.6 PAUSE      m    m    m
  1973group halted                            10.6 PAUSE      m    m    m
  1974sync of tracks MUST                     10.6 PAUSE      M    M    M
  1975SRV resources are kept                  10.6 PAUSE      MAY  MAY  MAY
  1976session and free resources after being p10.6 PAUSE      sd   sd   sd
  1977specified with timeout parameter of Sess10.6 PAUSE      sd   sd   sd
  1990request may contain Range header        10.6 PAUSE      may  may  may
  1992pause point must contain one value      10.6 PAUSE      M    M    M
      ** This could be changed to an explicit
      ** MUST in the RFC too.
  1993normal play time for stream set to pause10.6 PAUSE      m    m    m
  1995pause effective encounting timepoint    10.6 PAUSE      m    m    m
  1997If time outside ? error "457 Invalid Ran10.6 PAUSE      M    M    M
  1999starts at pause point, not played or rec10.6 PAUSE      
  2000Range header missing, interrupted immedi10.6 PAUSE      m    m    m
  2002pause point set to current normal play t10.6 PAUSE      m    m    m
  2004request discards all queued PLAY        10.6 PAUSE      m    m    m
  2005point in media stream MUST be maintained10.6 PAUSE      M    M    M
  2006subsequent PLAY resumes pause point.    10.6 PAUSE      m    m    m
  2032If SRV sent data beyond Range header    10.6 PAUSE      
  2033PLAY would still resume at point in time10.6 PAUSE      m    m    m
  2034assumed CLT has discarded data          10.6 PAUSE      m    m    m
  2035ensures continuous pause/play cycling   10.6 PAUSE      info info info
      ** Another keyword called 'conclusion'
      ** could be included in the list which
      ** can be used for this case.
  2039stops stream delivery for given URI,    10.7 TEARDOWN   m    m    m
  2040freeing resources associated            10.7 TEARDOWN   m    m    m
  2041URI is pres URI session id. invalid     10.7 TEARDOWN   m    m    m
  2043all transport defined session desc.     10.7 TEARDOWN
  2044SETUP request before played again.      10.7 TEARDOWN   m    m    m
  2055retrieves value specified in URI        10.8 GET_PARAME req  req  req
  2057content of reply left to implementation 10.8 GET_PARAME Left to the application
  2058no entity body may test liveness ("ping"10.8 GET_PARAME may  may  may

  2093requests value for a URI                10.9 SET_PARAME req  req req
  2096contain single parameter to determine re10.9 SET_PARAME SD  SD   SD
  2098several act if all para. successfully   10.9 SET_PARAME M   M    M
  2100allow to set repeatedly to same value   10.9 SET_PARAME M   M    M
  2101disallow changing parameter values.     10.9 SET_PARAME MAY MAY  MAY
  2103transport para. set with SETUP          10.9 SET_PARAME M   M    M
  2109split in fine-grained for error indicati10.9 SET_PARAME may may  may
  2111an atomic settings is desirable         10.9 SET_PARAME opt opt  opt
  2147informs CLT connect another SRV         10.10 REDIRECT  m   m    m
  2148mandatory header Location               10.10 REDIRECT  m   m    m
  2150Range indicates redirection takes effect10.10 REDIRECT  may may  may
  2152continue send receive TEARDOWN request  10.10 REDIRECT  M   M    M
  2153SETUP new session at designated host    10.10 REDIRECT  M   M    M
  2166recd range according desc.              10.11 RECORD    m   m    m
  2167timestamp reflects start and end time   10.11 RECORD    sd  sd   sd
  2168no time range given use start or end tim10.11 RECORD    req req  req
  2170If started, commence recd immediately.  10.11 RECORD    m   m    m
  2172recorded data under the request-uri     10.11 RECORD    opt opt  opt
      ** that the server optionally
      ** uses the user specified uri
  2172recorded data request or another URI    10.11 RECORD    m   m    m
      ** The server must record either in the
      ** uri location mentioned by the user
      ** or another uri

  2174not use request URI response 201        10.11 RECORD    SD  SD   SD
  2175describes status of request             10.11 RECORD    SD  SD   SD 
  2176refers new resource and Location        10.11 RECORD    SD  SD   SD 
  2178media SRV supporting recd of live press 10.11 RECORD    M   M    M
  2179recd live must support clock range forma10.11 RECORD    M   M    M
      ** The above two lines can be combined
      ** into a single line.
      ** A media server supporting recording
      ** of live presentations MUST support the
      ** clock range format

  2201interleave RTSP mthds and stream data   10.12 Interleav may may  may  
  2202interleaving should generally avoided   10.12 Interleav sd  sd   sd
  2204SHOULD be used RTSP carried over TCP.   10.12 Interleav SD  SD   SD
  2206encapsulated by an ASCII dollar sign    10.12 Interleav m   m    m
  2207followed byone-byte channel id.,        10.12 Interleav m   m    m
  2208followed by length of binary data       10.12 Interleav m   m    m
  2209two-byte integer in network byte order  10.12 Interleav m   m    m
  2210stream data immediately without CRLF    10.12 Interleav m   m    m
  2211Each $ block contains one upper-layer   10.12 Interleav m   m    m
  2214channel id.defined in Transport header  10.12 Interleav infoinfo info
  2217When RTP, RTCP msgs are interleaved     10.12 Interleav sd  sd   sd
  2219RTCP sent first avail higher than RTP   10.12 Interleav sd  sd   sd 
  2220MAY request RTCP packets another channel10.12 Interleav MAY MAY  MAY
  2221two channels in interleaved of Transport10.12 Interleav req req  req
  2224RTCP sync two or more streams           10.12 Interleav req req  req 
  2226tunnel RTP/RTCP through TCP connection  10.12 Interleav infoinfo info
  2227transfer onto UDP                       10.12 Interleav sd  sd   sd

Some general comments / queries :

 1.A PLAY request without a Range header is legal. It starts playing a 
   stream from the beginning unless the stream has been paused. If a 
   stream has been paused via PAUSE, stream delivery resumes at the 
   pause point. If a stream is playing, such a PLAY request causes no 
   further action and can be used by the client to test server liveness.

   Lets consider this scenario 
	* The client wants to play the entire movie once again. 
	immediately after the first PLAY is over 
	* It sends a PLAY request without the Range header 
	while the first PLAY is still playing. 

In this case it would be treated as a 'ping' to test the 
server liveliness. Is it possible to have a machanism 
to differentiate between the request that could be 
used as a 'ping' and a request to play the entire movie 
once again??

BTW, What is meant by precise editing? 

2. Is it possible for a 'PAUSE' request to contain a Range header with the
   value (i.e pause point) greater than the value that has actually been
   played out ?

   For eg. if a 'PLAY' has been issued for range '10 - 20' and media has
   played say upto '15' then, is it possible by any of the media client to 
   send a 'PAUSE' request with a 'Range' header value of '18' ???

   If the above is possible and is valid, then once the 'PAUSE' request for
   the above is recd., do we finish playing the media upto '18' and then 
   pause ???

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 27 Jun 2002 08:54:40 +0200

Hi,

Lets start with the general comments.

>server liveliness. Is it possible to have a mechanism 
The use of PLAY for pinging the server about liveness will be 
deprecated. Instead the other methods for this should be use, RTCP, 
PING, SET_PARAMETER, or OPTIONS.

We are currently leaning towards removing queued play. This is primarily 
due to lacking any valid use case for queued play. Without queued play 
you can't request the movie again until it has played to end and the 
client issues a PAUSE followed by a PLAY.

>BTW, What is meant by precise editing? 
I believe the mentioning of precise editing was due to the fact that you 
could by a series of play requests could create an edited version of 
 the media (requires queued play).

>   value (i.e pause point) greater than the value that has actually been
Yes, as long as it contains a range which is part of the range that 
actually is requested to be played.

>   the above is recd., do we finish playing the media upto '18' and then 
Yes, you are correct. This is exactly what is possible with PAUSE with 
range header.

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic