[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MMUSIC] Review of Section 10 - RTSP Feature table
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 ???