MMUSIC Working Group                                      H. Schulzrinne
Internet-Draft                                       Columbia University
Obsoletes: RFC 2326                                               A. Rao
(if approved)                                                      Cisco
Intended status: Standards Track                                  A. Rao
Expires: May 7, 2009                                               Cisco                             R. Lanphier
Expires: September 10, 2009
                                                           M. Westerlund
                                                             Ericsson AB
                                                    M. Stiemerling (Ed.)
                                                                     NEC
                                                        November 3, 2008
                                                           March 9, 2009

                Real Time Streaming Protocol 2.0 (RTSP)
                    draft-ietf-mmusic-rfc2326bis-19
                    draft-ietf-mmusic-rfc2326bis-20

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of which he BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or she is aware
   have been IETF Contributions published or will made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be disclosed, modified outside the IETF Standards Process, and any
   derivative works of which he or she becomes
   aware will it may not be disclosed, in accordance with Section 6 of BCP 79. created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 7, September 10, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This memorandum defines RTSP version 2.0 which is a revision of the
   Proposed Standard obsoletes RTSP version
   1.0 which is defined in RFC 2326.

   The Real Time Streaming Protocol, or RTSP, is an application-level
   protocol for setup and control over of the delivery of data with real-time
   properties.  RTSP provides an extensible framework to enable
   controlled, on-demand delivery of real-time data, such as audio and
   video.  Sources of data can include both live data feeds and stored
   clips.  This protocol is intended to control multiple data delivery
   sessions, provide a means for choosing delivery channels such as UDP,
   multicast UDP and TCP, and provide a means for choosing delivery
   mechanisms based upon RTP (RFC 3550).

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   9  11
     1.1.   Scope and Background . . . . . . . .   Notes on Copyright . . . . . . . . . .   9
     1.2.   RTSP Specificication Update . . . . . . . . .  11
   2.  Protocol Overview . . . . .  10
     1.3.   Notational Conventions . . . . . . . . . . . . . . . . .  10
     1.4.   Terminology  13
     2.1.   Content Description  . . . . . . . . . . . . . . . . . .  13
     2.2.   Session Establishment  . . . .  11
     1.5.   Media Properties . . . . . . . . . . . . .  14
     2.3.   Playback Control . . . . . . .  14
       1.5.1.   Random Access . . . . . . . . . . . . .  15
     2.4.   Session Parameter Manipulations  . . . . . .  15
       1.5.2.   Retention . . . . . .  17
     2.5.   Media Delivery . . . . . . . . . . . . . . .  15
       1.5.3.   Content Modifications . . . . . .  17
       2.5.1.   Media Delivery Manipulations . . . . . . . . .  16
       1.5.4.   Mapping to the Attributes . . .  18
     2.6.   Session Maintenance and Termination  . . . . . . . . . .  16
   2.  20
     2.7.   Extending RTSP Introduction . . . . . . . . . . . . . . . . . . . . . .  17
     2.1.   Protocol Properties  . . .  21
   3.  Document Conventions  . . . . . . . . . . . . . . .  17
     2.2.   RTSP's Relationship to HTTP . . . . .  23
     3.1.   Notational Conventions . . . . . . . . .  18
     2.3.   Extending RTSP . . . . . . . .  23
     3.2.   Terminology  . . . . . . . . . . . . .  19
     2.4.   Overall Operation . . . . . . . . .  23
   4.  Protocol Parameters . . . . . . . . . .  20
     2.5.   RTSP States . . . . . . . . . . .  27
     4.1.   RTSP Version . . . . . . . . . . .  21
     2.6.   Relationship with Other Protocols . . . . . . . . . . .  22
   3.  27
     4.2.   RTSP Use Cases  . . . . . . . . . . . . . . . . . . . IRI and URI . . . .  23
     3.1.   On-demand Playback of Stored Content . . . . . . . . . .  23
     3.2.   Unicast distribution of Live Content . . . . . .  27
     4.3.   Session Identifiers  . . . .  24
     3.3.   On-demand Playback using Multicast . . . . . . . . . . .  25
     3.4.   Inviting an RTSP server into a conference . . .  29
     4.4.   SMPTE Relative Timestamps  . . . .  25
     3.5.   Live Content using Multicast . . . . . . . . . . .  29
     4.5.   Normal Play Time . . .  26
   4.  Protocol Parameters . . . . . . . . . . . . . . . . .  30
     4.6.   Absolute Time  . . . .  28
     4.1.   RTSP Version . . . . . . . . . . . . . . . . .  31
     4.7.   Feature-tags . . . . .  28
     4.2.   RTSP IRI and URI . . . . . . . . . . . . . . . . .  31
     4.8.   Message Body Tags  . . .  28
     4.3.   Session Identifiers . . . . . . . . . . . . . . . .  31
     4.9.   Media Properties . .  30
     4.4.   SMPTE Relative Timestamps . . . . . . . . . . . . . . .  30
     4.5.   Normal Play Time . . .  32
       4.9.1.   Random Access  . . . . . . . . . . . . . . . . .  30
     4.6.   Absolute Time . .  33
       4.9.2.   Retention  . . . . . . . . . . . . . . . . . . .  31
     4.7.   Feature-tags . .  33
       4.9.3.   Content Modifications  . . . . . . . . . . . . . . .  33
       4.9.4.   Supported Scale Factors  . . . . .  31
     4.8.   Entity Tags . . . . . . . . .  34
       4.9.5.   Mapping to the Attributes  . . . . . . . . . . . . .  32  34
   5.  RTSP Message  . . . . . . . . . . . . . . . . . . . . . . . .  33  35
     5.1.   Message Types  . . . . . . . . . . . . . . . . . . . . .  33  35
     5.2.   Message Headers  . . . . . . . . . . . . . . . . . . . .  34  36
     5.3.   Message Body . . . . . . . . . . . . . . . . . . . . . .  34  36
     5.4.   Message Length . . . . . . . . . . . . . . . . . . . . .  34  37
   6.  General Header Fields . . . . . . . . . . . . . . . . . . . .  35  38
   7.  Request . . . . . . . . . . . . . . . . . . . . . . . . . . .  36  39
     7.1.   Request Line . . . . . . . . . . . . . . . . . . . . . .  36  39
     7.2.   Request Header Fields  . . . . . . . . . . . . . . . . .  38  41
   8.  Response  . . . . . . . . . . . . . . . . . . . . . . . . . .  40  43
     8.1.   Status-Line  . . . . . . . . . . . . . . . . . . . . . .  40  43
       8.1.1.   Status Code and Reason Phrase  . . . . . . . . . . .  40  43
     8.2.   Response Header Fields Headers . . . . . . . . . . . . . . . . .  43
   9.  Entity . . .  46
   9.  Message Body  . . . . . . . . . . . . . . . . . . . . . . . .  46  49
     9.1.   Entity   Message Body Header Fields . . . . . . . . . . . . . . . . . .  46  49
     9.2.   Entity   Message Body . . . . . . . . . . . . . . . . . . . . . .  47  50
   10. Connections . . . . . . . . . . . . . . . . . . . . . . . . .  48  51
     10.1.  Reliability and Acknowledgements . . . . . . . . . . . .  48  51
     10.2.  Using Connections  . . . . . . . . . . . . . . . . . . .  49  52
     10.3.  Closing Connections  . . . . . . . . . . . . . . . . . .  50  54
     10.4.  Timing Out Connections and RTSP Messages . . . . . . . .  51  55
     10.5.  Showing Liveness . . . . . . . . . . . . . . . . . . . .  51  55
     10.6.  Use of IPv6  . . . . . . . . . . . . . . . . . . . . . .  52  56
   11. Capability Handling . . . . . . . . . . . . . . . . . . . . .  53  57
   12. Pipelining Support  . . . . . . . . . . . . . . . . . . . . .  55  59
   13. Method Definitions  . . . . . . . . . . . . . . . . . . . . .  56  60
     13.1.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . .  57  61
     13.2.  DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . .  58  62
     13.3.  SETUP  . . . . . . . . . . . . . . . . . . . . . . . . .  60  64
       13.3.1.  Changing Transport Parameters  . . . . . . . . . . .  63  67
     13.4.  PLAY . . . . . . . . . . . . . . . . . . . . . . . . . .  64  68
       13.4.1.  General Usage  . . . . . . . . . . . . . . . . . . .  64  68
       13.4.2.  Aggregated Sessions  . . . . . . . . . . . . . . . .  68  72
       13.4.3.  Updating current PLAY Requests . . . . . . . . . . .  68  73
       13.4.4.  Playing On-Demand Media  . . . . . . . . . . . . . .  70  74
       13.4.5.  Playing Dynamic On-Demand Media  . . . . . . . . . .  71  75
       13.4.6.  Playing Live Media . . . . . . . . . . . . . . . . .  71  75
       13.4.7.  Playing Live with Recording  . . . . . . . . . . . .  72  76
       13.4.8.  Playing Live with Time-Shift . . . . . . . . . . . .  72  76
     13.5.  PLAY_NOTIFY  . . . . . . . . . . . . . . . . . . . . . .  73  77
       13.5.1.  End-of-Stream  . . . . . . . . . . . . . . . . . . .  74  78
       13.5.2.  Media-Properties-Update  . . . . . . . . . . . . . .  75  79
       13.5.3.  Scale-Change . . . . . . . . . . . . . . . . . . . .  76  80
     13.6.  PAUSE  . . . . . . . . . . . . . . . . . . . . . . . . .  77  81
     13.7.  TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . .  79  84
       13.7.1.  Client to Server . . . . . . . . . . . . . . . . . .  84
       13.7.2.  Server to Client . . . . . . . . . . . . . . . . . .  85
     13.8.  GET_PARAMETER  . . . . . . . . . . . . . . . . . . . . .  80  86
     13.9.  SET_PARAMETER  . . . . . . . . . . . . . . . . . . . . .  81  87
     13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . .  82  89
   14. Embedded (Interleaved) Binary Data  . . . . . . . . . . . . .  86  92
   15. Status Code Definitions . . . . . . . . . . . . . . . . . . .  88  94
     15.1.  Success 1xx  . . . . . . . . . . . . . . . . . . . . . .  88  94
       15.1.1.  100 Continue . . . . . . . . . . . . . . . . . . . .  88  94
     15.2.  Success 2xx  . . . . . . . . . . . . . . . . . . . . . .  88  94
       15.2.1.  200 OK . . . . . . . . . . . . . . . . . . . . . . .  88  94
     15.3.  Redirection 3xx  . . . . . . . . . . . . . . . . . . . .  88  94
       15.3.1.  300 Multiple Choices . . . . . . . . . . . . . . . .  89
       15.3.2.  301 Moved Permanently  . . . . . . . . . . . . . . .  89
       15.3.3.  95
       15.3.2.  302 Found  . . . . . . . . . . . . . . . . . . . . .  89
       15.3.4.  95
       15.3.3.  303 See Other  . . . . . . . . . . . . . . . . . . .  89
       15.3.5.  95
       15.3.4.  304 Not Modified . . . . . . . . . . . . . . . . . .  89
       15.3.6.  95
       15.3.5.  305 Use Proxy  . . . . . . . . . . . . . . . . . . .  90  96
     15.4.  Client Error 4xx . . . . . . . . . . . . . . . . . . . .  90  96
       15.4.1.  400 Bad Request  . . . . . . . . . . . . . . . . . .  90  96
       15.4.2.  405 Method Not Allowed  401 Unauthorized . . . . . . . . . . . . . . .  90
       15.4.3.  451 Parameter Not Understood . . .  96
       15.4.3.  402 Payment Required . . . . . . . . .  90
       15.4.4.  452 reserved . . . . . . .  97
       15.4.4.  403 Forbidden  . . . . . . . . . . . . .  90
       15.4.5.  453 Not Enough Bandwidth . . . . . .  97
       15.4.5.  404 Not Found  . . . . . . . .  91
       15.4.6.  454 Session Not Found . . . . . . . . . . .  97
       15.4.6.  405 Method Not Allowed . . . .  91
       15.4.7.  455 Method Not Valid in This State . . . . . . . . .  91
       15.4.8.  456 Header Field . .  97
       15.4.7.  406 Not Valid for Resource Acceptable . . . . . .  91
       15.4.9.  457 Invalid Range . . . . . . . . . . .  97
       15.4.8.  407 Proxy Authentication Required  . . . . . .  91
       15.4.10. 458 Parameter Is Read-Only . . .  98
       15.4.9.  408 Request Timeout  . . . . . . . . . .  91
       15.4.11. 459 Aggregate Operation Not Allowed . . . . . .  98
       15.4.10. 410 Gone . .  91
       15.4.12. 460 Only Aggregate Operation Allowed . . . . . . . .  91
       15.4.13. 461 Unsupported Transport . . . . . . . . . . . .  98
       15.4.11. 411 Length Required  .  92
       15.4.14. 462 Destination Unreachable . . . . . . . . . . . .  92
       15.4.15. 463 Destination Prohibited . . .  98
       15.4.12. 412 Precondition Failed  . . . . . . . . . .  92
       15.4.16. 464 Data Transport Not Ready Yet . . . .  99
       15.4.13. 413 Request Message Body Too Large . . . . . .  92
       15.4.17. 465 Notification Reason Unknown . . .  99
       15.4.14. 414 Request-URI Too Long . . . . . . .  92
       15.4.18. 470 Connection Authorization Required . . . . . . .  92
       15.4.19. 471 Connection Credentials not accepted  99
       15.4.15. 415 Unsupported Media Type . . . . . .  93
       15.4.20. 472 Failure to establish secure connection . . . . .  93
     15.5.  Server Error 5xx . .  99
       15.4.16. 451 Parameter Not Understood . . . . . . . . . . . .  99
       15.4.17. 452 reserved . . . . . .  93
       15.5.1.  551 Option not supported . . . . . . . . . . . . . .  93
   16. Header Field Definitions  99
       15.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 100
       15.4.19. 454 Session Not Found  . . . .  94
     16.1.  Accept . . . . . . . . . . . 100
       15.4.20. 455 Method Not Valid in This State . . . . . . . . . 100
       15.4.21. 456 Header Field Not Valid for Resource  . . . . . 103
     16.2.  Accept-Credentials . 100
       15.4.22. 457 Invalid Range  . . . . . . . . . . . . . . . . . 100
       15.4.23. 458 Parameter Is Read-Only . 103
     16.3.  Accept-Encoding . . . . . . . . . . . . 100
       15.4.24. 459 Aggregate Operation Not Allowed  . . . . . . . . 104
     16.4.  Accept-Language 100
       15.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 100
       15.4.26. 461 Unsupported Transport  . . . . . . . . . . . . 104
     16.5.  Accept-Ranges . 101
       15.4.27. 462 Destination Unreachable  . . . . . . . . . . . . 101
       15.4.28. 463 Destination Prohibited . . . . . . . . 104
     16.6.  Allow . . . . . 101
       15.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 101
       15.4.30. 465 Notification Reason Unknown  . . . . . . . . . . 105
     16.7. 101
       15.4.31. 470 Connection Authorization Required  . . . . . . . 101
       15.4.32. 471 Connection Credentials not accepted  . . . . . . 102
       15.4.33. 472 Failure to establish secure connection . . . . . 102
     15.5.  Server Error 5xx . . . 105
     16.8.  Bandwidth  . . . . . . . . . . . . . . . . . . 102
       15.5.1.  500 Internal Server Error  . . . . . 105
     16.9.  Blocksize . . . . . . . . 102
       15.5.2.  501 Not Implemented  . . . . . . . . . . . . . . . 105
     16.10. Cache-Control . 102
       15.5.3.  502 Bad Gateway  . . . . . . . . . . . . . . . . . . 102
       15.5.4.  503 Service Unavailable  . . 106
     16.11. Connection . . . . . . . . . . . . 102
       15.5.5.  504 Gateway Timeout  . . . . . . . . . . . 108
     16.12. Connection-Credentials . . . . . 103
       15.5.6.  505 RTSP Version Not Supported . . . . . . . . . . . 103
       15.5.7.  551 Option not supported . 108
     16.13. Content-Base . . . . . . . . . . . . . 103
   16. Header Field Definitions  . . . . . . . . . 109
     16.14. Content-Encoding . . . . . . . . . 104
     16.1.  Accept . . . . . . . . . . . 109
     16.15. Content-Language . . . . . . . . . . . . . . 113
     16.2.  Accept-Credentials . . . . . . 109
     16.16. Content-Length . . . . . . . . . . . . . 114
     16.3.  Accept-Encoding  . . . . . . . . 110
     16.17. Content-Location . . . . . . . . . . . . 114
     16.4.  Accept-Language  . . . . . . . . 110
     16.18. Content-Type . . . . . . . . . . . . 115
     16.5.  Accept-Ranges  . . . . . . . . . . 110
     16.19. CSeq . . . . . . . . . . . 116
     16.6.  Allow  . . . . . . . . . . . . . . . 110
     16.20. Date . . . . . . . . . . . . . . . . 116
     16.7.  Authorization  . . . . . . . . . . 110
     16.21. ETag . . . . . . . . . . . 117
     16.8.  Bandwidth  . . . . . . . . . . . . . . . 111
     16.22. Expires . . . . . . . . 118
     16.9.  Blocksize  . . . . . . . . . . . . . . . . 111
     16.23. From . . . . . . . 118
     16.10. Cache-Control  . . . . . . . . . . . . . . . . . . . 112
     16.24. If-Match . . 118
     16.11. Connection . . . . . . . . . . . . . . . . . . . . . . 112
     16.25. If-Modified-Since . 121
     16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 121
     16.13. Content-Base . 112
     16.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 113
     16.27. Last-Modified 122
     16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 122
     16.15. Content-Language . 113
     16.28. Location . . . . . . . . . . . . . . . . . . . 123
     16.16. Content-Length . . . . . 113
     16.29. Media-Properties . . . . . . . . . . . . . . . . 124
     16.17. Content-Location . . . . 113
     16.30. Media-Range . . . . . . . . . . . . . . . . 124
     16.18. Content-Type . . . . . . 115
     16.31. Notify-Reason . . . . . . . . . . . . . . . . 124
     16.19. CSeq . . . . . 115
     16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 115
     16.33. Proxy-Authenticate . . 125
     16.20. Date . . . . . . . . . . . . . . . . . 116
     16.34. Proxy-Authorization . . . . . . . . . 125
     16.21. Expires  . . . . . . . . . 117
     16.35. Proxy-Require . . . . . . . . . . . . . . . 126
     16.22. From . . . . . . 117
     16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 117
     16.37. Public 127
     16.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 127
     16.24. If-Modified-Since  . 118
     16.38. Range . . . . . . . . . . . . . . . . . . 128
     16.25. If-None-Match  . . . . . . . 119
     16.39. Referer . . . . . . . . . . . . . . 128
     16.26. Last-Modified  . . . . . . . . . . 120
     16.40. Retry-After . . . . . . . . . . . 129
     16.27. Location . . . . . . . . . . . 120
     16.41. Request-Status . . . . . . . . . . . . . 130
     16.28. Media-Properties . . . . . . . . 120
     16.42. Require . . . . . . . . . . . . 130
     16.29. Media-Range  . . . . . . . . . . . . 121
     16.43. RTP-Info . . . . . . . . . . 132
     16.30. MTag . . . . . . . . . . . . . . 122
     16.44. Scale . . . . . . . . . . . . 132
     16.31. Notify-Reason  . . . . . . . . . . . . . 123
     16.45. Seek-Style . . . . . . . . 133
     16.32. Pipelined-Requests . . . . . . . . . . . . . . . 124
     16.46. Speed . . . . 133
     16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 134
     16.34. Proxy-Authorization  . . 125
     16.47. Server . . . . . . . . . . . . . . . . 134
     16.35. Proxy-Require  . . . . . . . . . 126
     16.48. Session . . . . . . . . . . . . 135
     16.36. Proxy-Supported  . . . . . . . . . . . . 126
     16.49. Supported . . . . . . . . 135
     16.37. Public . . . . . . . . . . . . . . . 127
     16.50. Timestamp . . . . . . . . . . 136
     16.38. Range  . . . . . . . . . . . . . 127
     16.51. Transport . . . . . . . . . . . . 137
     16.39. Referer  . . . . . . . . . . . 128
     16.52. Unsupported . . . . . . . . . . . . . 138
     16.40. Retry-After  . . . . . . . . . 134
     16.53. User-Agent . . . . . . . . . . . . . 139
     16.41. Request-Status . . . . . . . . . . 134
     16.54. Vary . . . . . . . . . . . 139
     16.42. Require  . . . . . . . . . . . . . . . 134
     16.55. Via . . . . . . . . . 139
     16.43. RTP-Info . . . . . . . . . . . . . . . . . 135
     16.56. WWW-Authenticate . . . . . . . 140
     16.44. Scale  . . . . . . . . . . . . . 135
   17. Proxies . . . . . . . . . . . . 142
     16.45. Seek-Style . . . . . . . . . . . . . . . 136
     17.1.  Proxies and Protocol Extensions . . . . . . . . 143
     16.46. Speed  . . . . 137
   18. Caching . . . . . . . . . . . . . . . . . . . . . 145
     16.47. Server . . . . . . 139
   19. Security Framework . . . . . . . . . . . . . . . . . . . 145
     16.48. Session  . . 140
     19.1.  RTSP and HTTP Authentication . . . . . . . . . . . . . . 140
     19.2.  RTSP over TLS . . . . . . . . 146
     16.49. Supported  . . . . . . . . . . . . . 140
     19.3.  Security and Proxies . . . . . . . . . . 147
     16.50. Terminate-Reason . . . . . . . . 141
       19.3.1.  Accept-Credentials . . . . . . . . . . . . 147
     16.51. Timestamp  . . . . . 142
       19.3.2.  User approved TLS procedure . . . . . . . . . . . . 143
   20. Syntax . . . . . . 148
     16.52. Transport  . . . . . . . . . . . . . . . . . . . . . 145
     20.1.  Base Syntax . . 148
     16.53. Unsupported  . . . . . . . . . . . . . . . . . . . . 145
     20.2.  RTSP Protocol Definition . . 155
     16.54. User-Agent . . . . . . . . . . . . . . 147
       20.2.1.  Generic Protocol elements . . . . . . . . . 155
     16.55. Vary . . . . 147
       20.2.2.  Message Syntax . . . . . . . . . . . . . . . . . . . 150
       20.2.3.  Header Syntax . . . 156
     16.56. Via  . . . . . . . . . . . . . . . . 154
     20.3.  SDP extension Syntax . . . . . . . . . . 157
     16.57. WWW-Authenticate . . . . . . . . 162
   21. Security Considerations . . . . . . . . . . . . 157
   17. Proxies . . . . . . . 163
     21.1.  Remote denial of Service Attack . . . . . . . . . . . . 165
   22. IANA Considerations . . . . . . . . 158
     17.1.  Proxies and Protocol Extensions  . . . . . . . . . . . . 159
   18. Caching . 167
     22.1.  Feature-tags . . . . . . . . . . . . . . . . . . . . . . 167
       22.1.1.  Description . . . . 161
     18.1.  Validation Model (HTTP)  . . . . . . . . . . . . . . . . 167
       22.1.2.  Registering New Feature-tags with IANA 162
       18.1.1.  Last-Modified Dates  . . . . . . . 168
       22.1.3.  Registered entries . . . . . . . . . 163
       18.1.2.  Message Body Tag Cache Validators  . . . . . . . . 168
     22.2.  RTSP Methods . 163
       18.1.3.  Weak and Strong Validators . . . . . . . . . . . . . 163
       18.1.4.  Rules for When to Use Entity Tags and
                Last-Modified Dates  . . . . . . . . 168
       22.2.1.  Description . . . . . . . . 166
       18.1.5.  Non-validating Conditionals  . . . . . . . . . . . . 168
       22.2.2.  Registering New Methods with IANA 167
     18.2.  Invalidation After Updates or Deletions (HTTP) . . . . . 167
   19. Security Framework  . . . . 168
       22.2.3.  Registered Entries . . . . . . . . . . . . . . . . . 169
     22.3.
     19.1.  RTSP Status Codes and HTTP Authentication . . . . . . . . . . . . . . 169
     19.2.  RTSP over TLS  . . . . . 169
       22.3.1.  Description . . . . . . . . . . . . . . . . 169
     19.3.  Security and Proxies . . . . 169
       22.3.2.  Registering New Status Codes with IANA . . . . . . . 169
       22.3.3.  Registered Entries . . . . . . . 170
       19.3.1.  Accept-Credentials . . . . . . . . . . 169
     22.4.  RTSP Headers . . . . . . . 171
       19.3.2.  User approved TLS procedure  . . . . . . . . . . . . 172
   20. Syntax  . . . 169
       22.4.1.  Description . . . . . . . . . . . . . . . . . . . . 169
       22.4.2.  Registering New Headers with IANA . . . . 175
     20.1.  Base Syntax  . . . . . 170
       22.4.3.  Registered entries . . . . . . . . . . . . . . . . . 170
     22.5.  Accept-Credentials 175
     20.2.  RTSP Protocol Definition . . . . . . . . . . . . . . . . 177
       20.2.1.  Generic Protocol elements  . . . 171
       22.5.1.  Accept-Credentials policies . . . . . . . . . . 177
       20.2.2.  Message Syntax . . 171
       22.5.2.  Accept-Credentials hash algorithms . . . . . . . . . 171
     22.6.  Cache-Control  Cache Directive Extensions . . . . . . . 172
     22.7.  Media Properties . 180
       20.2.3.  Header Syntax  . . . . . . . . . . . . . . . . . . . 172
       22.7.1.  Description 184
     20.3.  SDP extension Syntax . . . . . . . . . . . . . . . . . . 193
   21. Security Considerations . . 173
       22.7.2.  Registration Rules . . . . . . . . . . . . . . . . . 173
       22.7.3.  Registered Values  . . . . 194
     21.1.  Remote denial of Service Attack  . . . . . . . . . . . . 196
   22. IANA Considerations . 173
     22.8.  Notify-Reason header . . . . . . . . . . . . . . . . . . 173
       22.8.1.  Description . . 198
     22.1.  Feature-tags . . . . . . . . . . . . . . . . . . 173
       22.8.2.  Registration Rules . . . . 198
       22.1.1.  Description  . . . . . . . . . . . . . 173
       22.8.3.  Registered Values . . . . . . . 198
       22.1.2.  Registering New Feature-tags with IANA . . . . . . . 199
       22.1.3.  Registered entries . . . 174
     22.9.  Range header formats . . . . . . . . . . . . . . 199
     22.2.  RTSP Methods . . . . 174
     22.10. RTP-Info header parameters . . . . . . . . . . . . . . . 174
       22.10.1. Desctiption . . . 199
       22.2.1.  Description  . . . . . . . . . . . . . . . . . 174
       22.10.2. Registration Rules . . . 199
       22.2.2.  Registering New Methods with IANA  . . . . . . . . . 199
       22.2.3.  Registered Entries . . . . . 175
       22.10.3. Registered Values . . . . . . . . . . . . 200
     22.3.  RTSP Status Codes  . . . . . 175
     22.11. Seek-Style Policies . . . . . . . . . . . . . . 200
       22.3.1.  Description  . . . . 175
       22.11.1. Description . . . . . . . . . . . . . . . . 200
       22.3.2.  Registering New Status Codes with IANA . . . . 175
       22.11.2. Registration Rules . . . 200
       22.3.3.  Registered Entries . . . . . . . . . . . . . . 175
       22.11.3. Registered Values . . . 200
     22.4.  RTSP Headers . . . . . . . . . . . . . . 176
     22.12. Transport Header Registries . . . . . . . . 200
       22.4.1.  Description  . . . . . . 176
       22.12.1. Transport Protocol Specification . . . . . . . . . . 176
       22.12.2. Transport modes . . . . 200
       22.4.2.  Registering New Headers with IANA  . . . . . . . . . 201
       22.4.3.  Registered entries . . . . . 177
       22.12.3. Transport Parameters . . . . . . . . . . . . 201
     22.5.  Accept-Credentials . . . . 178
     22.13. URI Schemes . . . . . . . . . . . . . . . 202
       22.5.1.  Accept-Credentials policies  . . . . . . . 178
       22.13.1. The rtsp URI Scheme . . . . . 202
       22.5.2.  Accept-Credentials hash algorithms . . . . . . . . . 202
     22.6.  Cache-Control  Cache Directive Extensions  . . 178
       22.13.2. The rtsps URI Scheme . . . . . 203
     22.7.  Media Properties . . . . . . . . . . . 179
       22.13.3. The rtspu URI Scheme . . . . . . . . . 203
       22.7.1.  Description  . . . . . . . 180
     22.14. SDP attributes . . . . . . . . . . . . . 204
       22.7.2.  Registration Rules . . . . . . . . 181
     22.15. Media Type Registration for text/parameters . . . . . . 182
   23. References . . . 204
       22.7.3.  Registered Values  . . . . . . . . . . . . . . . . . 204
     22.8.  Notify-Reason header . . . . . 184
     23.1.  Normative References . . . . . . . . . . . . . 204
       22.8.1.  Description  . . . . . 184
     23.2.  Informative References . . . . . . . . . . . . . . . 204
       22.8.2.  Registration Rules . . 186
   Appendix A.  Examples . . . . . . . . . . . . . . . 204
       22.8.3.  Registered Values  . . . . . . . 189
     A.1.   Media on Demand (Unicast) . . . . . . . . . . 205
     22.9.  Range header formats . . . . . 189
     A.2.   Media on Demand using Pipelining . . . . . . . . . . . . 193
     A.3.   Media on Demand (Unicast) . 205
     22.10. Terminate-Reason Header  . . . . . . . . . . . . . . 195
     A.4.   Single Stream Container Files . . 205
       22.10.1. Redirect Reasons . . . . . . . . . . . 199
     A.5.   Live Media Presentation Using Multicast . . . . . . . 205
       22.10.2. Terminate-Reason Header Parameters . 201
     A.6.   Capability Negotiation . . . . . . . . 206
     22.11. RTP-Info header parameters . . . . . . . . . 202
   Appendix B.  RTSP Protocol State Machine . . . . . . 206
       22.11.1. Description  . . . . . . 204
     B.1.   States . . . . . . . . . . . . . . 206
       22.11.2. Registration Rules . . . . . . . . . . . 204
     B.2.   State variables . . . . . . 206
       22.11.3. Registered Values  . . . . . . . . . . . . . . 204
     B.3.   Abbreviations . . . 206
     22.12. Seek-Style Policies  . . . . . . . . . . . . . . . . . . 204
     B.4.   State Tables 207
       22.12.1. Description  . . . . . . . . . . . . . . . . . . . . 207
       22.12.2. Registration Rules . . 205
   Appendix C.  Media Transport Alternatives . . . . . . . . . . . . 210
     C.1.   RTP . . . 207
       22.12.3. Registered Values  . . . . . . . . . . . . . . . . . 207
     22.13. Transport Header Registries  . . . . . . 210
       C.1.1.   AVP . . . . . . . . 207
       22.13.1. Transport Protocol Specification . . . . . . . . . . 208
       22.13.2. Transport modes  . . . . . . 210
       C.1.2.   AVP/UDP . . . . . . . . . . . . 209
       22.13.3. Transport Parameters . . . . . . . . . . 210
       C.1.3.   AVPF/UDP . . . . . . 209
     22.14. URI Schemes  . . . . . . . . . . . . . . . . 211
       C.1.4.   SAVP/UDP . . . . . . 210
       22.14.1. The rtsp URI Scheme  . . . . . . . . . . . . . . . . 212
       C.1.5.   SAVPF/UDP 210
       22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 211
       22.14.3. The rtspu URI Scheme . . . . . 212
       C.1.6.   RTCP usage with RTSP . . . . . . . . . . . 212
     22.15. SDP attributes . . . . . 212
     C.2.   RTP over TCP . . . . . . . . . . . . . . . . 212
     22.16. Media Type Registration for text/parameters  . . . . . . 213
       C.2.1.   Interleaved RTP over TCP
   23. References  . . . . . . . . . . . . . . 213
       C.2.2.   RTP over independent TCP . . . . . . . . . . . 215
     23.1.  Normative References . . . 213
       C.2.3.   Handling Media Clock Time Jumps in the RTP Media
                Layer . . . . . . . . . . . . . . . 215
     23.2.  Informative References . . . . . . . . 217
       C.2.4.   Handling RTP Timestamps after PAUSE . . . . . . . . 220
       C.2.5.   RTSP / RTP Integration . 217
   Appendix A.  Examples . . . . . . . . . . . . . . 223
       C.2.6.   Scaling with RTP . . . . . . . . 219
     A.1.   Media on Demand (Unicast)  . . . . . . . . . . 223
       C.2.7.   Maintaining NPT synchronization with RTP
                timestamps . . . . . 219
     A.2.   Media on Demand using Pipelining . . . . . . . . . . . . 222
     A.3.   Media on Demand (Unicast)  . . . . 223
       C.2.8.   Continuous Audio . . . . . . . . . . . 225
     A.4.   Single Stream Container Files  . . . . . . . 223
       C.2.9.   Multiple Sources in an RTP Session . . . . . . 229
     A.5.   Live Media Presentation Using Multicast  . . . 223
       C.2.10.  Usage of SSRCs and the RTCP BYE Message During an
                RTSP Session . . . . . 231
     A.6.   Capability Negotiation . . . . . . . . . . . . . . . 223
     C.3.   Future Additions . . 232
   Appendix B.  RTSP Protocol State Machine  . . . . . . . . . . . . 234
     B.1.   States . . . . . . 224
   Appendix D.  Use of SDP for RTSP Session Descriptions . . . . . . 225
     D.1.   Definitions . . . . . . . . . . . . . 234
     B.2.   State variables  . . . . . . . . . 225
       D.1.1.   Control URI . . . . . . . . . . . 234
     B.3.   Abbreviations  . . . . . . . . . 225
       D.1.2.   Media Streams . . . . . . . . . . . . 234
     B.4.   State Tables . . . . . . . 226
       D.1.3.   Payload Type(s) . . . . . . . . . . . . . . . 235
   Appendix C.  Media Transport Alternatives . . . 227
       D.1.4.   Format-Specific Parameters . . . . . . . . . 240
     C.1.   RTP  . . . . 227
       D.1.5.   Directionality of media stream . . . . . . . . . . . 227
       D.1.6.   Range of Presentation . . . . . . . . . . . 240
       C.1.1.   AVP  . . . . 228
       D.1.7.   Time of Availability . . . . . . . . . . . . . . . . 229
       D.1.8.   Connection Information . . . . 240
       C.1.2.   AVP/UDP  . . . . . . . . . . . 229
       D.1.9.   Entity Tag . . . . . . . . . . . 240
       C.1.3.   AVPF/UDP . . . . . . . . . . 229
     D.2.   Aggregate Control Not Available . . . . . . . . . . . . 230
     D.3.   Aggregate Control Available 241
       C.1.4.   SAVP/UDP . . . . . . . . . . . . . . 230
     D.4.   RTSP external SDP delivery . . . . . . . . 242
       C.1.5.   SAVPF/UDP  . . . . . . . . 231
   Appendix E.  Text format for Parameters . . . . . . . . . . . . . 233
   Appendix F.  Requirements for Unreliable Transport of 242
       C.1.6.   RTCP usage with RTSP . . . 234
   Appendix G.  Backwards Compatibility Considerations . . . . . . . 236
     G.1.   Play Request in Play mode . . . . . . 242
     C.2.   RTP over TCP . . . . . . . . . . . 236
     G.2.   Using Persistent Connections . . . . . . . . . . . 243
       C.2.1.   Interleaved RTP over TCP . . . 236
   Appendix H.  Open Issues . . . . . . . . . . . 244
       C.2.2.   RTP over independent TCP . . . . . . . . . 237
   Appendix I.  Changes . . . . . 244
     C.3.   Handling Media Clock Time Jumps in the RTP Media Layer . 248
     C.4.   Handling RTP Timestamps after PAUSE  . . . . . . . . . . 251
     C.5.   RTSP / RTP Integration . . . . . . 238
   Appendix J.  Acknowledgements . . . . . . . . . . . 253
     C.6.   Scaling with RTP . . . . . . . 245
     J.1.   Contributors . . . . . . . . . . . . . 253
     C.7.   Maintaining NPT synchronization with RTP timestamps  . . 254
     C.8.   Continuous Audio . . . . . . . 245
   Appendix K.  RFC Editor Consideration . . . . . . . . . . . . . 254
     C.9.   Multiple Sources in an RTP Session . 247
   Authors' Addresses . . . . . . . . . . 254
     C.10.  Usage of SSRCs and the RTCP BYE Message During an
            RTSP Session . . . . . . . . . . . . . 248
   Intellectual Property and Copyright Statements . . . . . . . . . 249

1.  Introduction

1.1.  Scope and Background

   This memo defines version 2.0 of the Real Time Streaming Protocol
   (RTSP 2.0) which is an application-level protocol for control over
   the delivery 254
     C.11.  Future Additions . . . . . . . . . . . . . . . . . . . . 255
   Appendix D.  Use of data with real-time properties, typically streaming
   media.  Streaming media is, for instance, video on demand or audio
   live streaming.  Put simply, RTSP acts as a "network remote control" SDP for multimedia servers, as you know it from your TV set.

   The protocol operates between RTSP 2.0 clients and servers, but also
   supports the usage of RTSP 2.0 proxies between clients and servers.
   Basically, clients can request information about streaming media from
   setranrvers, by asking for a description Session Descriptions . . . . . . 256
     D.1.   Definitions  . . . . . . . . . . . . . . . . . . . . . . 256
       D.1.1.   Control URI  . . . . . . . . . . . . . . . . . . . . 256
       D.1.2.   Media Streams  . . . . . . . . . . . . . . . . . . . 257
       D.1.3.   Payload Type(s)  . . . . . . . . . . . . . . . . . . 258
       D.1.4.   Format-Specific Parameters . . . . . . . . . . . . . 258
       D.1.5.   Directionality of the media or use media
   description provided externally.  Based on the media description
   clients can request to play out the media, pause it, or stop it
   completely, as known from a regular TV remote control.  The requested media can consist stream . . . . . . . . . . . 258
       D.1.6.   Range of multiple audio and video streams that are
   delivered as a time-synchronized streams from servers to clients.

   This memorandum describes the use Presentation  . . . . . . . . . . . . . . . 259
       D.1.7.   Time of Availability . . . . . . . . . . . . . . . . 260
       D.1.8.   Connection Information . . . . . . . . . . . . . . . 260
       D.1.9.   Message Body Tag . . . . . . . . . . . . . . . . . . 260
     D.2.   Aggregate Control Not Available  . . . . . . . . . . . . 261
     D.3.   Aggregate Control Available  . . . . . . . . . . . . . . 261
     D.4.   RTSP over a reliable connection
   based transport level protocol, such as TCP.  For security, TLS over
   a connection oriented transport is supported.

   There is no dependency on an special RTSP connection in the protocol.
   Instead, an external SDP delivery . . . . . . . . . . . . . . . 262
   Appendix E.  RTSP server maintains a session labeled by an identifier
   to associate groups Use Cases . . . . . . . . . . . . . . . . . . . 264
     E.1.   On-demand Playback of media streams and their states.  An RTSP
   session is not tied to a transport-level connection such as a TCP
   connection.  During a session, a client may open and close multiple
   reliable transport connections to the server to issue RTSP requests
   for that session.

   The set Stored Content . . . . . . . . . . 264
     E.2.   Unicast Distribution of streams to be controlled in Live Content . . . . . . . . . . 265
     E.3.   On-demand Playback using Multicast . . . . . . . . . . . 266
     E.4.   Inviting an RTSP session is defined by
   a presentation description.  This memorandum does not define server into a conference  . . . . . . . 266
     E.5.   Live Content using Multicast . . . . . . . . . . . . . . 267
   Appendix F.  Text format for the presentation description.  However Parameters . . . . . . . . . . . . . 269
   Appendix D describes how
   SDP [RFC4566] is used for this purpose.  The streams controlled by
   RTSP may use RTP [RFC3550] G.  Requirements for their data transport, but the
   operation Unreliable Transport of RTSP does not depend on the transport mechanism used to
   carry continuous media.  RTSP is intentionally similar  . . . 270
   Appendix H.  Backwards Compatibility Considerations . . . . . . . 272
     H.1.   Play Request in syntax and
   operation to HTTP/1.1 [RFC2616] so that extension mechanisms to HTTP
   may also be applied to RTSP.

   The RTSP 2.0 protocol supports the following operations:

   Retrieval of media from media server:  The client can either request
         a presentation description via RTSP DESCRIBE, HTTP or some
         other method.  If the presentation is being multicast, the
         presentation description contains the multicast addresses and
         ports to be used for the continuous media.  If the presentation
         is to be sent only to the client via unicast, Play mode  . . . . . . . . . . . . . . . 272
     H.2.   Using Persistent Connections . . . . . . . . . . . . . . 272
   Appendix I.  Open Issues  . . . . . . . . . . . . . . . . . . . . 273
   Appendix J.  Changes  . . . . . . . . . . . . . . . . . . . . . . 274
   Appendix K.  Acknowledgements . . . . . . . . . . . . . . . . . . 281
     K.1.   Contributors . . . . . . . . . . . . . . . . . . . . . . 281
   Appendix L.  RFC Editor Consideration . . . . . . . . . . . . . . 283
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 284

1.  Introduction

   This memo defines version 2.0 of the client
         provides Real Time Streaming Protocol
   (RTSP 2.0).  RTSP 2.0 is an application-level protocol for setup and
   control over the destination.

   Invitation delivery of data with real-time properties,
   typically streaming media.  Streaming media is, for instance, video
   on demand or audio live streaming.  Put simply, RTSP acts as a
   "network remote control" for multimedia servers, as you know it from
   your TV set.

   The protocol operates between RTSP 2.0 clients and servers, but also
   supports the usage of proxies placed between clients and servers.
   Clients can request information about streaming media server to from servers,
   by asking for a conference:  A description of the media server can be
         "invited" to join an existing conference to play back or use media
         into description
   provided externally.  Then establish the presentation.  This mode is useful, media delivery protocol to
   be used for example, in
         distributed teaching applications.  Several parties in the
         conference may take turns "pushing media streams described by the media description.
   Clients can then request to play out the media, pause it, or stop it
   completely, as known from a regular TV remote control buttons".
         Note: This functionality will require RTSP external application
         level functionality.

   RTSP requests may be handled by proxies, tunnels control.  The requested
   media can consist of multiple audio and caches video streams that are
   delivered as in
   HTTP/1.1 [RFC2616].

1.2.  RTSP Specificication Update

   This memorandum specifies a time-synchronized streams from servers to clients.

   RTSP 2.0 which is an update replacement of RTSP 1.0, a
   proposed standard defined in [RFC2326].  The goal of this version is
   to correct the many flaws 1.0 [RFC2326] that have been identified in obsoletes that
   specification.  This protocol is based on RTSP 1.0 since
   its publication.  The corrections are such that but not backwards
   compatibility was impossible.  Thus a new version was deemed the most
   appropriate solution to get a more functional protocol.  There are no
   plans to revise RTSP 1.0.  Appendix I catalogs
   compatible other than in the changes of this basic version negotiation mechanism.
   The changes are documented in relation to RTSP 1.0. Appendix J.  There are many reasons why
   RTSP 2.0 as specified in this memo has reduced functionality compared
   to can't be backwards compatible with RTSP 1.0 and aims at specifying the RTSP core, functionality and
   rules for extensions, and basic interaction with but some of the media delivery
   protocol RTP [RFC3550].

   Any other functionality would need
   main ones are; that most header that needed to be published as extension
   documents.  This specification provides rules for such extensions and
   defines registries to avoid naming collisions.

1.3.  Notational Conventions

   Since some of extensible didn't
   define the definitions and allowed syntax are identical to HTTP/1.1,
   this specification only points to the section where they are defined
   rather than copying it.  For brevity, [HX.Y] is to be taken to refer
   to Section X.Y preventing safe deployment of extensions;
   the current HTTP/1.1 specification ([RFC2616]).

   All changed behavior of the mechanisms specified in this document are described PLAY method when received in both
   prose and playing
   state; changed behavior of the Augmented Backus-Naur form (ABNF) described in detail
   in [RFC5234].

   Indented extensibility model and smaller-type paragraphs are used its mechanism;
   the change of syntax for some headers.  The summary is that there is
   so many small details that changing version become necessary to provide informative
   background
   enable clarification and motivation. consistent behavior.

   This document is intended to give readers who were
   not involved with the formulation of structured in the specification way that it begins with an
   understanding
   overview of why things are the way they are in RTSP.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", protocol operations and "OPTIONAL" its functions in this an informal
   way.  Then a set of definitions of used terms and document are to be interpreted as described in [RFC2119].

   The word, "unspecified"
   conventions is used to indicate functionality or features
   that are not defined in this introduced.  Then comes the actual protocol
   specification.  Such  In the appendix some functionality
   cannot be used in a standardized manner without further definition in
   an extension specification that isn't core
   RTSP defined, but still important to enable some usage, like RTP and
   SDP usage with RTSP.

1.4.  Terminology

   Some  This is followed by a number of informational
   parts discussing the terminology changes, use cases, different considerations or
   motivations.

1.1.  Notes on Copyright

   The IETF has been adopted from HTTP/1.1 [RFC2616].
   Terms not listed here are defined as new IPR contributor rules in HTTP/1.1.

   Aggregate control:  The concept of controlling multiple streams using
      a single timeline, generally maintained by the server.  A client,
      for example, uses aggregate control when it issues a single play
      or pause message to simultaneously control both the audio and
      video [RFC5378], which
   results in a movie.  A session which is under aggregate control changed model of copyright.  The baseline is
      referred that "The
   IETF Trust and the IETF must obtain the right to publish an IETF
   Contribution as an aggregated session.

   Aggregate control URI:  The URI used in RFC or an RTSP request Internet-Draft from the Contributors."
   (taken from Section 3.1 of [RFC5378]).

   This memo has plenty of text taken from [RFC2326] and thus the
   associated copyright.  Magnus Westerlund has solicited the authors of
   [RFC2326] and this memo to refer transfer the copyright to the new model,
   i.e., to the IETF trust and control an aggregated session.  It normally, but the IETF.  Most of the authors have
   responded and transferred their copyright.  However, not always,
      corresponds to all of them
   have.  This is the presentation URI specified in first reason for the session
      description. currently used boiler plate
   (and thus the current status), i.e., with pre5378Trust200902.  See Section 13.3
   also this document [IETF-Trust-License-Policy] for more information.

   Conference:  A multiparty, multimedia presentation, where "multi"
      implies greater than or equal to one.

   Client:  The client requests media service

   Furthermore, this memo does contain text that has been copied and
   modified from the media server.

   Connection:  A transport layer virtual circuit established between
      two programs for the purpose of communication.

   Container file:  A file which may contain multiple media streams
      which often constitutes a presentation when played together.  The
      concept [RFC2616].  Older versions of a container file is this memo solely linked
   to the particular places.  Linking to the HTTP/1.1 specification was
   not embedded in appropriate anymore, as the protocol.
      However, text was not fitting to RTSP servers may offer aggregate control on the media
      streams within these files.

   Continuous media:  Data where there 2.0
   needs and had to be adapted.  Thus text copied from HTTP/1.1 is still
   under copyright prior to [RFC5378].

2.  Protocol Overview

   This section provides a timing relationship between
      source and sink; that is, informative overview of the sink needs to reproduce different
   mechanisms in the timing
      relationship that existed at RTSP 2.0 protocol.  This to enable a high level
   understanding before getting into all the source.  The most common examples different details.  In case
   of continuous media are audio and motion video.  Continuous media
      can be real-time (interactive or conversational), where there is a
      "tight" timing relationship between source conflict with this description and sink, or streaming
      (playback), where the relationship is less strict.

   Entity:  The information transferred as later sections, the payload of later
   sections take precedence.  For more information about considered use
   cases for RTSP see Appendix E.

   RTSP 2.0 is a bi-directional request or
      response.  An entity consists of meta-information in and response protocol that first
   establish a context including content resources (the media) and then
   controls the form delivery of
      entity-header fields and these content in resources from the form server to
   the client.  RTSP has 3 fundamental parts of an entity-body, as interest, Session
   Establishment, Playback Control and its extensibility model, that is
   described in Section 9.

   Feature-tag:  A tag representing below.  It is also is based on some assumptions on existing
   functionality that also will be touched upon to provide a certain set of functionality, i.e. complete
   solution for client controlled real-time media delivery.

   RTSP uses text based messages that may contain a feature.

   IRI:  Internationalized Resource Identifier, is the same as an URI, binary message body.
   The RTSP messages starts with the exception a method line that it allows characters from identify the whole
      Universal Character Set (Unicode/ISO 10646), rather than method,
   the US-
      ASCII only.  See [RFC3987] for more information.

   Live:  Normally used protocol and version and the resource to describe act on.  Following the
   method line follows a presentation or session with media
      coming from an ongoing event. number of RTSP headers.  This generally results in part is ended by
   two consecutive control line feed (CRLF) character pairs.  The
   message body if present follows the
      session having an unbound or only loosely defined duration, two CRLF and
      sometimes no seek operations the bodies length
   are possible.

   Media initialization:  Datatype/codec specific initialization.  This
      includes such things as clock rates, color tables, etc.  Any
      transport-independent information which is required described by a message header.  RTSP messages are sent over a
   reliable transport protocol between client and server.  RTSP 2.0
   requires clients and servers to implement TCP and TLS over TCP as
   mandatory transport for playback of a media stream occurs in the media initialization
      phase of stream setup.

   Media parameter:  Parameter specific RTSP messages.

2.1.  Content Description

   RTSP exist to a provide access to multi-media content, however it tries
   to be agnostic to the media type that may be
      changed before or during stream playback.

   Media server:  The server providing playback services for one or more
      media streams.  Different media streams within a presentation may
      originate from different media servers.  A media server may reside
      on the same host or on a different host from which the
      presentation actual media delivery
   protocol that is invoked.

   Media server indirection:  Redirection of used.  To enable a media client to implement a
      different media server.

   (Media) stream:  A single media instance, e.g., an audio stream or a
      video stream as well as a single whiteboard or shared application
      group.  When using RTP, a stream consists of all RTP and RTCP
      packets created by a source within complete
   system, an RTP session.

   Message:  The basic unit of RTSP communication, consisting of a
      structured sequence of octets matching external mechanism for describing the syntax defined in
      Section 20 content and transmitted over a connection or a connectionless
      transport.

   Non-Aggregated Control:  Control of a single media stream.  This the
   delivery protocol(s) is
      only possible in used.  RTSP sessions with a single media.

   Participant:  Member of a conference.  A participant may be a
      machine, e.g., a playback server.

   Presentation:  A set assumes that this either
   delivered completely out of one bands or more streams presented can be delivered as single data
   object upon the clients request using the DESCRIBE method
   (Section 13.2).

   Parameters that commonly have to be included in the client
      as a complete Content
   Description are the following:

   o  Number of media feed and described streams

   o  The resource identifier for each media stream/resource that is to
      be controlled by a presentation
      description as defined below.  Presentations with more than one RTSP
   o  The protocol that each media stream is to be delivered over

   o  Transport protocol parameters that are often handled in not negotiated or varies
      with each client

   o  Media encoding information enabling client to correctly decode it
      upon reception

   o  An aggregate control resource identifier

   RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media
   resources and aggregates under aggregate common control.

   Presentation description:  A presentation description contains
      information about

   This specification describes in Appendix D how one or more media streams within a presentation,
      such as the set of encodings, network addresses and information
      about the content.  Other IETF protocols such as uses SDP ([RFC4566])
      use the term "session" [RFC4566]
   for a presentation. Content Description

2.2.  Session Establishment

   The presentation
      description may take several different formats, including but not
      limited to RTSP client can request the establishment of an RTSP session
   after having used the content description to determine which media
   streams are available, and also which media delivery protocol format, SDP.

   Response:  An RTSP response.  If an HTTP response is meant, that is
      indicated explicitly.

   Request:  An used
   and their particular resource identifiers.  The RTSP request.  If an HTTP request is meant, that session is
      indicated explicitly.

   Request-URI:  The URI used in a request to indicate
   common context between the resource on
      which client and the request server that consist of one
   or more media resource that is to be performed.

   RTSP agent:  Refers to either an RTSP client, under common playback control.

   The client creates an RTSP server, or session by sending an
      RTSP Proxy.  In this specification, there are many capabilities
      that are common to these three entities such as request using the capability
   SETUP method (Section 13.3) to
      send requests or receive responses. the server.  In the SETUP request the
   client also includes all the transport parameter necessary to enable
   the media delivery protocol to function in the "Transport" header
   (Section 16.52).  This term will be used when
      describing functionality that is applicable includes parameters are pre-established by the
   content description but necessary for any middlebox to all three of these
      entities.

   RTSP session:  A stateful abstraction upon which correctly
   handle the main control
      methods of RTSP operate.  An RTSP session is media delivery protocol.  The Transport header in a server entity; it
      is created, maintained and destroyed by
   request may contain multiple alternatives for media delivery to
   enable the server.  It server to select what is
      established by preferred some an prioritized
   list.  However, RTSP server upon builds on that the completion client can select a small
   number of alternatives based on the content description.

   The server will determine if the media resource is available upon
   receiving a successful SETUP request (when a 200 OK response is sent) and is labelled
      with a session identifier at that time.  The session exists until
      timed out by if any of the server or explicitly removed by a TEARDOWN
      request.  An RTSP session transport parameter
   specifications are acceptable.  If that is a stateful entity; successful, an RTSP server
      maintains an explicit session state machine (see Appendix A) where
      most state transitions are triggered by client requests.  The
      existence of a
   session implies the existence of state about context is created and the
      session's media streams relevant parameters and their respective transport mechanisms.
      A given session can have one or more media streams associated with
      it. state is
   stored.  An RTSP server uses identifier is created for the RTSP session to aggregate control over
      multiple media streams.

   Transport initialization:  The negotiation of transport information
      (e.g., port numbers, transport protocols) between the client and included
   in the server.

   URI:  Universal Resource Identifier, see [RFC3986].  The URIs used response in
      RTSP are generally URLs as they give a location for the resource.
      As URLs are Session header (Section 16.48).  The SETUP
   response message includes a subset Transport header that specifies which of URIs, they will be referred to as URIs to
      cover also
   the cases when an RTSP URI would not be an URL.

   URL:  Universal Resource Locator, is an URI alternatives that are selected and any parameters which identifies the
      resource through its primary access mechanism, rather than
      identifying the resource by name or by some other attribute(s) of
   server is required to fill in.

   A SETUP request that resource.

1.5.  Media Properties

   When references an existing RTSP handles session but
   identifies a new media it resource is important to consider the different
   properties a request to add that media instance for playback can have.  This
   specification considers
   resource under common control with the below listed already present media properties
   resources in its
   protocol operations.  They are derived from the differencies between
   a number of supported usages.

   On-demand:  Media that has an aggregated session.  A client can expect this to work
   for all media resources under RTSP control within a fixed (given) duration that doesn't
      change during the life time of multi-media
   content.  However, aggregating resources from different content are
   likely to be refused by the server.  The RTSP session and are known at
      the time of the creation of the session.  It as aggregate is expected that the
      content of
   referenced by the media will not change, aggregate control URI, even if the representation,
      i.e encoding, quality, etc, may change.  Generally one can seek
      within RTSP session
   only contains a single media.

   To avoid an extra round trip in the media i.e. randomly access any range session establishment of
   aggregated RTSP sessions, RTSP 2.0 supports pipelined requests.  The
   client uses client selected identifier in the media
      stream Pipelined-Requests
   header to playback.

   Dynamic On-demand:  This is a variation of instruct the on-demand case where
      external methods are used server to manipulate the actual content of the
      media setup for bind multiple requests together as
   if they included the RTSP session. session identifier.

   The main example is where a
      playlist determines SETUP response also provides additional information about the content
   established sessions in couple of the session.

   Live:  Live media represents different headers.  The Media-
   Properties header include a progressing content stream (such as
      broadcast TV) where the duration may or may not be known.  It is
      not seakable, only number of properties that apply for the content presently being delivered can be
      accessed.

   Live with Recording:  A Live stream
   aggregate that is combined with a server
      side capability to store valuable when doing playback control and retain
   configuring user interface.  The Accept-Ranges header inform the content of
   client about which range formats that the live
      session for random access playback within server supports with these
   media resources.  The Media-Range header inform the part of client about the already
      recorded content.  The actual behavior
   time range of the media stream is currently available.

2.3.  Playback Control

   Having established an RTSP session one can start controlling the
   media playback.  The basic operations are very
      much depending on simple starting media
   delivery using the retention policy PLAY method (Section 13.4) or halt it by the PAUSE
   method (Section 13.6).  PLAY also allows for positioning where in the
   media stream.
      Either the server will be able to capture should deliver from if the complete media
      stream, support such
   operation.  The positioning is done using the Range header
   (Section 16.38) that support several different time formats, Normal
   Play Time (Section 4.5), SMPTE Timestamps (Section 4.4) or it will have absolute
   time (Section 4.6).  The Range header does also allow the client to
   specify a limitation in how much will position where playback should end, thus allowing a
   specific interval to be retained. played back.

   The media range will dynamically change as support for positioning/searching within a content depends on the session progress.
      For servers with
   contents media properties.  Content exist in a limited amount number of storage available for
      recording, different
   types, like on-demand, live, and live content being recorded.  Even
   within these categories there will be a sliding window that goes forwards while
      data are differences in how the content is made available
   generated and content distributed that is older than the
      limitation will affects how it can be discarded.

   Considering accessed for
   playback.  The properties applicable for the above usages one get RTSP session are
   provided by the following media properties
   and their different instance values.

1.5.1. server in the SETUP response using the Media-
   Properties header (Section 16.28).  These are expressed using one or
   several attributes that are independent such as, Random Access

   Random Access, i.e. that
   express if one positioning can request happen at all or if only limited to
   rewinding from start, and if possible what granularity that can be
   expected.  Another aspect possible to express if the playback point is
   moved from one point in content will
   change during the media duration to another.  The following
   different values are considered:

   Random Access:  Yes the media are seekable to any out of a large
      number lifetime of points within the media.  Due to media encoding
      limitations a particular point may not be reachable, but seeking
      to session.  While on-demand content
   will provided in its completeness from the beginning, a point close live stream
   being recorded while one watches it results in the content growing in
   duration as the session goes on.  There also exist content that is
   dynamically built by another protocol than RTSP and thus also changes
   in steps during the session but not continuously.  When content is enabled.  A floating point number
   recorded there are cases where not the complete content is maintained
   only the last hour for example.  All of
      seconds may these properties results in
   the need for mechanisms that will be provied to express discussed below.

   When the worst case distance between
      random client access points.

   Return To Start:  Seeking on-demand content that is only possible to begining of perform
   random access in the
      content.

   No seeking:  Seeking is not possible at all.

1.5.2.  Retention

   Media may have different retention policy client can issue the PLAY request for any point
   in place that affect the
   operation on content between the media.  The following different media retention
   policies are envisioned start and taken into consideration where
   applicable.

   Unlimited: the end.  The media server will not be removed as long as
   deliver media from the RTSP session
      are closest random access point prior to the
   requested point and indicate that in existence.

   Time Limited:  The media its PLAY response.  If the
   client issues a pause the delivery will at least not be removed before given
      wall clock time.  After that time it may or may not be available
      any more.

   Duration limited:  Each indiviudal unit of halted and the media point at
   which the server stopped will be retained
      for reported back in the specified duration.

1.5.3.  Content Modifications

   There response.  The
   client can later resume by a PLAY request without a range header.
   When the server is also about to completed the question PLAY request by delivering
   the end of how the content may change during time
   for or the requested range the server will send a give media resource:

   Unmutable:  The
   PLAY_NOTIFY request indicating this.

   When playing live content of with no extra functions, such as recording,
   the media client will not change, even if the
      representation, i.e encoding, quality, etc, may change.

   Dynamic:  Between explicit updates receive the media from the server after having sent a
   PLAY request that is what happens now.  Seeking in such content will is
   not change, working as the server does not store it, but only forwards it
   from the content may change due to external methods source of the session.  Thus delivery continues until the
   client sends a PAUSE request, tears down the session or triggers,
      such as playlists.

   Time Progressing:  As times progress new the content
   ends.

   For live sessions that are being recorded the client will become
      available.  If need to
   keep track of how the content also is retained it recording progress.  Upon session establishment
   the client will become longer
      and longer as everything between learn the start point and current duration of the point in
      currently being made available can be accessed.

1.5.4.  Mapping to recording from the Attributes

   This section exemplifies how one would map
   Media-Range header.  As the above listed usages to recording is ongoing the properties and their values.

   On-demand:  Random Access: Random Access=5s, Content Modifications:
      Unmutable, Retention: unlimted or time limited.

   Dynamic On-demand:  Random Access: Random Access=3s, Content
      Modifications: Dynamic, Retention: unlimted or time limited.

   Live:  Random Access: No seeking, Content Modifications: Time
      Progressing, Retention: Duration limited=0.0s

   Live with Recording:  Random Access: Random Access=3s, Content
      Modifications: Time Progressing, Retention: Duration limited=2H

2.  RTSP Introduction

2.1.  Protocol Properties

   RTSP has the following properties:

   Extendable:  New methods and parameters can be easily added content grows in
   direct relation to RTSP.

   Secure:  RTSP re-uses web security mechanisms, either at the
      transport level (TLS, [RFC5246]) or within the protocol itself.
      All HTTP authentication mechanisms such as basic ([RFC2616]) and
      digest authentication ([RFC2617]) are directly applicable.

   Transport-independent:  RTSP does not preclude the use of unreliable
      datagram protocol (UDP) ([RFC0768]) as it would be possible passed time.  Therefore, each server's
   response to
      implement application-level reliability.  The use of a
      connectionless datagram protocol such as UDP requires additional
      definition that may be provided as extensions to PLAY request will contain the core RTSP
      specification. current Media-Range
   header.  The reliable stream protocol TCP ([RFC0793]) and server should also send regularly every 5 minutes the secured reliable stream protocol TLS over TCP [RFC5246] are
   current media range in a PLAY_NOTIFY request.  If the currently defined transport protocols for RTSP messages.

   Media-delivery protocol independent:  The operation of RTSP does not
      depend on live
   transmission ends the transport mechanism used to carry continuous media.
      While most real-time media will use RTP as Server must send a transport protocol,
      RTSP does not preclude PLAY_NOTIFY request with the use of other protocols such as MPEG-2
      [ISO.13818-1.2000].  The use of other protocols requires
      additional definition
   updated Media-Properties indicating that may be provided as extensions to the
      core RTSP specification.

   Multi-server capable:  Each media stream within content stopped being a presentation can
      reside on
   recorded live session and instead become a different server. on-demand content.  The client automatically
      establishes several concurrent control sessions with
   request also contains the different final media servers.  Media synchronization in those cases is performed
      at range.  While the transport level.

   Separation of stream control and conference initiation:  Stream
      control is divorced from inviting a media server live delivery
   continues the client can request to a conference.
      In particular, SIP [RFC3261] play what is delivered just now
   by using the NPT timescale symbol "now", or H.323 [ITU.H323.1996] may be used
      to invite a server to it can request a conference; however, specific
   point in the exact procedures
      are unspecified.

   Suitable available content by an explicit range request for professional applications:  RTSP supports frame- level
      accuracy through SMPTE time stamps to allow remote digital
      editing.

   Presentation description neutral:  The protocol does not impose a
      particular presentation description or metafile format and can
      convey that
   point.  If the type requested point is outside of format to be used.  However, the presentation
      description is required available interval
   the server will adjust the position to contain the closest available point,
   i.e., either at least one RTSP URI.

   Proxy and firewall friendly:  The protocol should be readily handled
      by both application and transport-layer (SOCKS [RFC1961])
      firewalls. the beginning or the end.

   A firewall may need to understand special case of recording is where the SETUP method to
      open recording is not retained
   longer than a "hole" for specific time period, thus as the media stream.

   HTTP-friendly:  Where sensible, RTSP reuses HTTP concepts, so that live delivery
   continues the existing infrastructure client can be reused.  This infrastructure
      includes PICS (Platform for Internet Content Selection
      [W3C.REC-PICS-services] [W3C.REC-PICS-labels]) access any media within a moving window that
   covers for associating
      labels with content.  However, RTSP does not just add methods example "now" to
      HTTP since controlling continuous media requires server "now" minus 1 hour.  A client that pause
   on a specific point within the content may not retrieve the content
   anymore, if the client waits long enough before resuming the pause
   point, as the content may no longer be available.  In this case the
   pause point will adjusted to the end of the available media.

2.4.  Session Parameter Manipulations

   A session may have additional state in
      most cases.

   Appropriate or functionality that effects how
   the server control:  If a or client can start a stream, treats the session, content, how it needs
      to functions,
   or feedback on how well the session works.  Such extensions are not
   defined in this specification, but may be able done in various extensions.
   RTSP has two methods used to stop a stream.  Servers should not start streaming retrieve parameter values or to clients set them
   on either the client or the server: GET_PARAMETER (Section 13.8) or
   SET_PARAMETER (Section 13.9).  These methods are carrying the
   parameters in such a way that clients cannot stop message body of the stream.

   Transport negotiation:  The client appropriate format.  One can negotiate the transport method
      prior also
   use certain type of headers to actually query state with the GET_PARAMETER
   method.  As an example clients needing to process know the current Media-
   Range for a continuous media stream.

2.2.  RTSP's Relationship to HTTP

   RTSP is intentionally similar in syntax time-progressing session can use the GET_PARAMETER method
   and operation to HTTP/1.1
   [RFC2616] so that extension mechanisms to HTTP include the media-range.  Also synchronization information using
   the combination of RTP-Info and Range can in some cases also be applied to RTSP.  However, RTSP differs in a number of important
   aspects from HTTP:

      * requested.

   RTSP introduces 2.0 does not have a number strong mechanism for providing negotiation
   of new methods which headers or parameters and has a different their formats that can be used.
   The protocol identifier.

      *  RTSP has the notion of will indicate headers or parameters that it doesn't
   support if tried.  But determination a session built into the protocol.

      *  An RTSP server priori of what is available
   needs to maintain state be done through out-of-band mechanism, like in almost all cases, as
         opposed to the stateless nature session
   description, or through the usage of HTTP.

      *  Both an feature tags (Section 4.7).

2.5.  Media Delivery

   The delivery of media to the RTSP server and client can issue requests.

      *  Data is usually carried out-of-band by a different protocol.
         Session descriptions returned in done with a DESCRIBE response (see
         Section 13.2) and interleaving protocol
   outside of RTP with RTSP and this protocol is determined during the session
   establishment.  This document specifies how media is delivered with
   RTP over UDP, TCP are
         exceptions to this rule (see Section 14).

      * or the RTSP is defined control connection.  Additional
   protocols may be specified in the future based on demand.

   The usage of RTP as media delivery protocol does requires some
   additional information to use ISO 10646 (UTF-8) rather than ISO
         8859-1, consistent with HTML internationalization efforts
         [RFC2070].

      * function well.  The Request-URI always PLAY responses contains the absolute URI.  Because
   synchronization information to enable reliable and timely deliver of
         backward compatibility with
   how a historical blunder, HTTP/1.1
         [RFC2616] carries only the absolute path client should synchronize different sources in the request different
   RTP sessions.  It also provides a mapping between RTP timestamps and
         puts
   the host name in a separate header field.
         This makes "virtual hosting" easier, where a single host with
         one IP address hosts several document trees.

2.3.  Extending RTSP

   Since not all media servers have content time scale.  When the same functionality, media
   servers by necessity will support different sets of requests.  For
   example:

   o  A server may not be capable of seeking (absolute positioning) if
      it is to support live events only.

   o  Some servers may not support setting stream parameters and thus
      not support GET_PARAMETER and SET_PARAMETER.

   o  Some server may support an RTSP extension.

   It is up to notifying the creators of presentation descriptions not to ask client
   about the
   impossible end of a server.  This situation is similar in HTTP/1.1
   [RFC2616], where the methods described in [H19.5] are not likely to
   be supported across all servers.

   RTSP can be extended in three ways, listed here in order of PLAY request using the
   magnitude PLAY_NOTIFY, the request
   include information about which the last RTP packets are for each
   stream.  Thus enabling correct handling of changes supported:

   o  Existing methods can be extended with new parameters, e.g.
      headers, as long as these parameters can be safely ignored by the
      recipient.  If buffer drainage at the client needs negative acknowledgement when a
      method extension
   end.

2.5.1.  Media Delivery Manipulations

   The basic playback functionality of RTSP is not supported, to request content for a tag corresponding
   particular range to the
      extension may be added in the field of the Require or Proxy-
      Require headers (see Section 16.35).

   o  New methods can be added.  If the recipient of the message does
      not understand delivered to the request, it MUST respond with error code 501
      (Not Implemented) so client in a pace that enables
   playback as intended by the sender creator.  However, RTSP can avoid using this method
      again.  A client may also use the OPTIONS method
   manipulate how this delivery is done to inquire about
      methods supported by the server. client in two ways.

   Scale:  The server MUST list ratio of media content time delivered per unit playback
      time.

   Speed:  The ratio of playback time delivered per unit of wallclock
      time.

   So both affects the methods media delivery per time unit.  However, they are
   manipulating two independent time scales and the effects are possible
   to combine.

   Scale is used for fast forward or slow motion control as it supports using changes
   the Public response header.

   o  A new version amount of the protocol can content timescale that should be defined, allowing almost all
      aspects (except the position played back per time
   unit.  Scale > 1.0, means fast forward, e.g.  Scale=2.0 results in
   that 2 seconds of the protocol version number) to
      change.  A new version content is played back every second of playback.
   Scale = 1.0 is the protocol MUST be registered through
      an IETF standard track document.

   The basic capability discovery mechanism default value that is used if no Scale is
   specified, i.e. playback at the contents original rate.  Scale values
   between 0 and 1.0 is providing for slow motion.  Scale can be used
   negative to both discover
   support allow for a certain feature and to ensure that a feature reverse playback in either regular pace (Scale
   = -1.0) or fast backwards (Scale < -1.0) or slow motion backwards
   (-1.0 < Scale < 0).  Scale = 0 is
   available when performing a request.  For detailed explanation of
   this see Section 11.

2.4.  Overall Operation

   Each presentation equal to pause and media stream is identified by an RTSP URI.  The
   overall presentation and not allowed.

   In most cases the properties realization of scale means server side manipulation
   of the media to ensure that the presentation
   is composed of are defined by a presentation description file, the
   format of which client can actually play it back.
   These media manipulation and when they are needed are highly media
   type dependent.  Lets exemplify with two common media types audio and
   video.

   It is outside very difficult to modify the scope playback rate of this specification.  The
   presentation description file may be obtained audio.  A maximum
   of 10-30% is possible by changing the client using
   HTTP or other means such as email pitch-rate of speech.  Music
   goes out of tune if one tries to manipulate the playback rate by
   resampling it.  This is a well known problem and may not necessarily be stored
   on audio is commonly
   muted or played back in short segments with skips to keep up with the media server.
   current playback point.

   For video is possible to manipulate the purposes number of this specification, a presentation description frames that is
   assumed
   displayed per second.  But the rendering capabilities are often
   limited to describe one or more presentations, each of which
   maintains a common time axis.  For simplicity of exposition certain frame rates.  The decoding, handling capabilities
   and
   without loss bitrate of generality, it is assumed that received encoded content also limits the presentation
   description contains exactly number of
   frames that can be delivered.  Therefore when providing fast forward
   one such presentation.  A presentation
   may contain several media streams.

   The presentation description file contains generally picks a description subset of the media
   streams making up the presentation, including their encodings,
   language, and other parameters that enable the client to choose frames from the
   most appropriate combination of media.  In this presentation
   description, each media stream that is individually controllable by
   RTSP is identified by an RTSP URI, which points original content
   to be displayed.  However, the media server
   handling that particular media stream and names video encoding methods use will
   commonly limit the stream stored possibilities on which frames that server.  Several media streams can be located on different
   servers; for example, audio chosen
   and video streams can still be split across
   servers for load sharing.  The description also enumerates which
   transport methods decoded by the server is capable of.

   Besides receiver.

   Due to the media parameters, the network destination address and
   port need to restrictions a particular content will commonly be determined.  Several modes
   restricted to a limited set of operation can be
   distinguished:

   Unicast:  The media is transmitted possible scale ratios.  To handle this
   correctly, RTSP has mechanism to indicate the source of supported Scale ratios
   for the RTSP request content.  To support aggregated or dynamic content where this
   may change during the requested destination, with ongoing session and dependent on the port number chosen by location
   within the
      client.  Alternatively, content a mechanism for updating the media is transmitted on properties and
   the same
      reliable stream as RTSP.

   Multicast, server chooses address:  The media server picks current used scale factor exist.

   Speed affects how much of the
      multicast address and port.  This playback timeline that is the typical case for delivered in
   a live
      or near-media-on-demand transmission. given wallclock period.  The address default is provided by Speed = 1 which is to
   deliver at the session description.

   Multicast, client chooses address:  If same rate the server media is to participate
      in an existing multicast conference, consumed.  Speed > 1 means that
   the multicast address, port receiver will get content faster than it regularly would consume
   it.  Speed < 1 means that delivery is slower than the regular media
   rate.  Speed values of 0 or lower has no meaning and encryption key are given by not allowed.
   This mechanism enables two general functionalities.  Client side
   scale operations, i.e. the conference description,
      established by means outside client receives all the scope of this specification, frames and makes
   the adjustment to the playback locally.  The second usage is to
   control delivery for
      example by a SIP created conference.

2.5.  RTSP States

   RTSP controls buffering of media.  By specifying a stream which may be sent via speed over
   1.0 the client can build up the amount of playback time it has
   present in its buffers to a separate protocol,
   independent level that is sufficient for its needs.

   A naive implementation of Speed would only affect the control channel.  For example, RTSP control may be
   transported transmission
   schedule of the media and has a clear impact on the needed bandwidth.
   This would result in the data rate being proportional to the speed
   factor.  Speed = 1.5, i.e. 50% faster than normal delivery, will then
   result in a TCP connection while 50% increase in the media data transport rate.  If that can be
   supported or not depends solely on the underlaying network path.
   Scale may also have some impact on the required bandwidth due to the
   manipulation of the content in the new playback schedule.  An example
   is conveyed via
   UDP.  Thus, data delivery continues even if no RTSP requests fast forward where only the independently decodable intra frames
   are
   received by included in the media server.  Also, during its lifetime stream.  This usage of only intra frames
   increase the data rate significantly compared to a single
   media stream may normal sequence
   with the same number of frames where most frames will be controlled by RTSP requests issued sequentially
   on different TCP connections.  Therefore, encoded
   using prediction.

   This potential increase of the server data rate needs to
   maintain "session state" to be able to correlate RTSP requests with a
   stream. handled by the
   media sender.  The state transitions are described in Appendix A.

   Many methods client has requested that the media is delivered
   in RTSP do not contribute to state. a specific way, which should be honored.  However, the
   following play a central role in defining media
   sender can not ignore if the allocation and usage of
   stream resources on network path between the server: SETUP, PLAY, PAUSE, REDIRECT, sender and
   TEARDOWN.

   SETUP:  Causes the server to allocate resources for a stream and
      create an RTSP session.

   PLAY:  Starts data transmission on a stream allocated via SETUP.

   PAUSE:  Temporarily halts a stream without freeing server resources.

   REDIRECT:  Indicates
   receiver can't handle the resulting media stream.  In that case the session should
   media stream needs to be moved adapted to a new server
      or location

   TEARDOWN:  Frees fit the available resources associated with of
   the stream.  The RTSP
      session ceases path.  This can result in that media quality has be reduced due
   to exist on the server.

   RTSP methods delivery modifications that contribute to state use the Session header field
   (Section 16.49) client has requested.

   The need for bitrate adaptation becomes especially problematic in
   regards to identify Speed.  If the RTSP session whose state is being
   manipulated.  The server generates session identifiers in response target is to
   SETUP requests (Section 13.3).

2.6.  Relationship with Other Protocols

   RTSP has some overlap in functionality with HTTP.  It also fill up the buffer then the
   client may
   interact with HTTP in not want to do that at the initial contact with streaming content
   will often be made through a web page.  The current protocol
   specification aims cost of reduced quality.  If
   you like to allow different hand-off points between a web
   server and do local playout changes then you may actually require
   that the media server implementing RTSP.  For example, requested speed is honored.  To resolve this issue the
   presentation description usage
   of speed specifies a range so that both usages can be retrieved using HTTP or RTSP, which
   reduces round trips in web-browser-based scenarios, yet also allows
   for stand alone RTSP servers and clients which do not rely on HTTP at
   all.  However, RTSP differs fundamentally from HTTP in that most data
   delivery takes place out-of-band in a different protocol.  HTTP supported.  The
   server is an
   asymmetric protocol where request to use as high as possible speed value within the client issues requests and
   range if the server
   responds.  In RTSP, both bandwidth is insufficient for the upper bound.  As long
   as the media client and media server can issue
   requests.  RTSP requests are also stateful; they may set parameters
   and continue to control maintain a speed value within the range it shall
   not change the media stream long after quality, instead modify the request has
   been acknowledged.

   Re-using HTTP functionality has advantages speed value in at least two areas,
   namely security and proxies.  The requirements are very similar, so
   having the ability
   response to adopt HTTP work on caches, proxies and
   authentication is valuable.

   RTSP assumes available bandwidth.  Only if the existence of a presentation description format that
   can express both static and temporal properties of a presentation
   containing several media streams.  Session Description Protocol (SDP)
   [RFC4566] is generally server becomes unable
   to maintain the format of choice; however, RTSP is not lower bound to it.  For data delivery, most real-time media will use RTP as
   a transport protocol.  While RTSP works well with RTP, speed value does it is not tied need to RTP.

3.  RTSP Use Cases

   This section describes modify the most important and considered use cases
   for RTSP.  They are listed in descending order of importance in
   regards
   media quality to ensuring that all necessary functionality is present. maintain the lower bound speed value.

   This specification only fully supports usage of functionality enables the two first.  Also
   in these first two cases, there are special cases local scaling implementation to use a
   tight or exceptions that
   are not supported without extensions, e.g. the redirection of media even a range where lower bound equals upper bound to another address than
   identify that it requires the controlling entity.

3.1.  On-demand Playback of Stored Content

   An RTSP capable server stores content suitable for being streamed to
   a client.  A client desiring playback deliver the requested amount
   of any media time per delivery time independent of the stored content
   uses RTSP how much it needs to set up
   adapt the media transport required quality to deliver fit within the
   desired content.  RTSP available path bandwidth.
   For buffer refilling it is then used suitable to initiate, halt use a range with a reasonable
   span and manipulate
   the actual transmission (playout) of with a lower bound at the content.  RTSP is also
   required nominal media rate like 1.0 - 2.5.
   If one likes to provide necessary description and synchronization
   information for reduce the content.

   The above high level description can be broken down into a number of
   functions buffer one specifies an upper bound that RTSP needs
   is below 1.0 to be capable of.

   Presentation Description:  Provide initialization information about force the presentation (content); for example, which server to deliver slower than nominal media codecs are
         needed for the content.  Other information
   rate.

2.6.  Session Maintenance and Termination

   The session context that has been established is important
         includes the number of media stream the presentation contains,
         the transport protocols used for kept alive by having
   the media streams, and
         identifiers for these media streams. client show liveness.  This information is
         required before setup of the content done in two main ways:

   o  Media transport protocol keep-alive.  RTCP is possible and to
         determine if the client is even capable of using the content.

         This information need not be sent using RTSP; other external
         protocols can be used to transmit the transport presentation
         descriptions.  Two good examples are the use of HTTP [RFC2616]
         or email to fetch or receive presentation descriptions like SDP
         [RFC4566]

   Setup:  Set up some or all of when
      using RTP.

   o  Any RTSP request referencing the media streams in a presentation.
         The setup itself consist of selecting session context.

   Section 10.5 discusses the protocol methods for media
         transport and showing liveness in more
   depth.  If the necessary parameters client fails to show liveness for more than the protocol, like
         addresses and ports.

   Control of Transmission:  After the necessary media streams have been
   established the client can request session timeout value (normally 60 seconds) the server to start
         transmitting
   may terminate the content.  The client must context.  Other values may be allowed to start
         or stop selected by the transmission
   server through the inclusion of the content at arbitrary times. timeout parameter in the session
   header.

   The session context is normally terminated by the client must also be able by sending a
   TEARDOWN request to start the transmission at any
         point in the timeline of server referencing the presentation.

   Synchronization:  For aggregated control
   URI.  An individual media transport protocols like RTP [RFC3550] it
         might resource can be beneficial to carry synchronization information within
         RTSP.  This removed from a session
   context by a TEARDOWN request referencing that particular media
   resource.  And if all media resources are removed from a session
   context the session context is also terminated.

   A client may be due to either keep the lack of inter-media
         synchronization within session alive indefinitely if allowed by the protocol itself, or
   server, however it is recommend to release the potential
         delay before session context when
   extended periods of time without media delivery activity has passed.
   It can re-establish the synchronization session context if required later.  One issue
   is established (which that what is extended periods of time is dependent on the
         case for RTP when using RTCP).

   Termination:  Terminate the established contexts.

   For this use case there are a number server
   and its usage.  Because of assumptions about how that it
   works.  These are:

   On-Demand content:  The content is stored at recommended that the client
   terminate the session before 10*times the session timeout value has
   passed.  A server and can be
         accessed at may terminate the session after one session timeout
   period without any time during client activity beyond keep-alive.  When a time period when server
   terminates the session context it is intended
         to be available.

   Independent sessions: does that by sending a TEARDOWN
   request indicating the reason why.

   A server is capable of serving a number of
         clients simultaneously, including from can also request that the same piece of
         content client tear down the session and
   re-establish it at different points in that presentations time-line.

   Unicast Transport:  Content an alternative server when needed for each individual client is transmitted
         to them maintenance
   by using unicast traffic.

   It the REDIRECT method.  The Terminate-Reason header is also possible used to redirect
   indicate when and why.  The Location header indicates where it should
   connect if there are an alternative server available.  When the media traffic
   deadline expires the server simply stop providing service.  So to
   achieve a different
   destination than that of clean closure the entity controlling client will need to initiate session
   termination prior to the traffic.
   However, allowing this without appropriate mechanisms for checking
   that deadline.  In case the destination approves of this allows server has no other
   server to redirect and likes to close the session for distributed denial
   of service attacks (DDoS).

3.2.  Unicast distribution of Live Content

   This maintenance it
   shall use cases the TEARDOWN method with a Terminate-Reason header.

2.7.  Extending RTSP

   RTSP is similar quite a versatile protocol which supports extensions in many
   different directions.  Even this core specification contains several
   blocks of functionality that are optional to the above on-demand content implement.  The use case (see
   Section 3.1)
   and need for the difference protocol deployment is what should determine what
   gets implemented.  Allowing for extension makes it possible for RTSP
   to reach out to additional usages.  However, extensions will affect
   the nature interoperability of the content itself.
   Live content is continuously distributed as protocol and therefore it becomes available from
   a source; i.e., the main difference from on-demand is important
   that one starts
   distributing content before the end of it has become available to can be done in a structured way.

   The client can learn the
   server.

   In many cases servers capability through the consumer usage of live content is only interested in
   consuming what is actually happens "now"; i.e., very similar to
   broadcast TV.  However in this case it is assumed that there exist no
   broadcast or multicast channel to the users,
   OPTIONS method (Section 13.1) and instead the server
   functions as a distribution node, sending the same content to
   multiple receivers, using unicast traffic between server and client.
   This unicast traffic Supported header
   (Section 16.49).  It can also try and the transport parameters are individually
   negotiated for each receiving client.

   Another aspect of live content is possibly fail by using new
   methods or require that it often has a very limited
   time of availability, as it is only is available for particular features are supported using the duration
   Require or Proxy-Require header.

   The RTSP protocol in itself can be extended in three ways, listed
   here in order of the event the content covers.  An example magnitude of such a live content
   could changes supported:

   o  Existing methods can be a music concert which lasts 2 hour and starts at a
   predetermined time.  Thus there is need to announce when and extended with new parameters, for how example,
      headers, as long as these parameters can be safely ignored by the live content
      recipient.  If the client needs negative acknowledgement when a
      method extension is available.

   In some cases, not supported, a tag corresponding to the server providing live content
      extension may be saving some
   or all of the content to allow clients to pause added in the stream and resume
   it from field of the paused point, Require or to "rewind" and play continuously from a
   point earlier than Proxy-
      Require headers (see Section 16.35).

   o  New methods can be added.  If the live point.  Hence, this use case recipient of the message does
      not
   necessarily exclude playing from other than the live point of understand the
   stream, playing request, it must respond with scales other than 1.0, etc.

3.3.  On-demand Playback error code 501
      (Not Implemented) so that the sender can avoid using Multicast

   It is possible to this method
      again.  A client may also use RTSP to request that media be delivered the OPTIONS method to a
   multicast group.  The entity setting up inquire about
      methods supported by the session (the controller)
   will then control when and what media is delivered to the group.
   This use case has some potential for denial of service attacks by
   flooding a multicast group.  Therefore, a mechanism is needed to
   indicate that server.  The server must list the group actually accepts methods
      it supports using the traffic from Public response header.

   o  A new version of the RTSP
   server.

   An open issue in this use case is how one ensures that protocol can be defined, allowing almost all receivers
   listening to
      aspects (except the multicast or broadcast receives position of the session
   presentation configuring protocol version number) to
      change.  A new version of the receivers.  This memo has protocol must be registered through
      an IETF standard track document.

   The basic capability discovery mechanism can be used to rely on both discover
   support for a
   external solution certain feature and to solve this issue.

3.4.  Inviting an RTSP server into ensure that a conference

   If one has an established conference or group session, it feature is possible
   to have an RTSP server distribute
   available when performing a request.  For detailed explanation of
   this see Section 11.

   New media delivery protocols may be added and negotiated at session
   establishment, in addition to the whole group.
   Transmission extension to the group is simplest when controlled by a single
   participant or leader core protocol.
   Certain type of the conference.  Shared control might protocol manipulations can be
   possible, but would require further investigation done through parameter
   formats using SET_PARAMETER and possibly
   extensions.

   This use case assumes that there exists either multicast or GET_PARAMETER.

3.  Document Conventions

3.1.  Notational Conventions

   Since a
   conference focus that redistribute media few of the definitions are identical to all participants.

   This use case HTTP/1.1, this
   specification only points to the section where they are defined
   rather than copying it.  For brevity, [HX.Y] is intended to be able taken to handle the following
   scenario: A conference leader or participant (hereafter called the
   controller) has some pre-stored content on an RTSP server that he
   wants refer
   to share with Section X.Y of the group.  The controller sets up an RTSP
   session at current HTTP/1.1 specification ([RFC2616]).

   All the streaming server for mechanisms specified in this content document are described in both
   prose and retrieves the
   session description for the content.  The destination for the media
   content is set Augmented Backus-Naur form (ABNF) described in detail
   in [RFC5234].

   Indented and smaller-type paragraphs are used to the shared multicast group or conference focus.

   When desired by the controller, he/she can start provide informative
   background and stop motivation.  This is intended to give readers who were
   not involved with the
   transmission formulation of the media to specification an
   understanding of why things are the conference group.

   There way they are several issues with in RTSP.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this use case
   document are to be interpreted as described in [RFC2119].

   The word, "unspecified" is used to indicate functionality or features
   that are not solved by defined in this core specification for RTSP:

   Denial of service:  To avoid an RTSP server from being an unknowing
         participant specification.  Such functionality
   cannot be used in a denial of service attack the server needs to
         be able standardized manner without further definition in
   an extension specification to verify the destination's acceptance RTSP.

3.2.  Terminology

   Aggregate control:  The concept of the media.
         Such controlling multiple streams using
      a mechanism to verify single timeline, generally maintained by the approval of received media does
         not yet exist; instead, only policies can be used, which can be
         made server.  A client,
      for example, uses aggregate control when it issues a single play
      or pause message to work in controlled environments.

   Distributing simultaneously control both the presentation description to all participants audio and
      video in the
   group:  To enable a media receiver to correctly decode the content
         the media configuration information needs to be distributed
         reliably to all participants.  This will most likely require
         support from an external protocol.

   Passing movie.  A session which is under aggregate control of the session:  If it is desired
      referred to pass as an aggregated session.

   Aggregate control of
         the RTSP session between the participants, some support will be
         required by URI:  The URI used in an external protocol RTSP request to refer to exchange state information
      and possibly floor control of who is controlling the RTSP an aggregated session.

   If there interest in this use case, further work is required on the
   necessary extensions.

3.5.  Live Content using Multicast

   This use case in its simplest form does  It normally, but not require any use of RTSP
   at all; this is what multicast conferences being announced with SAP
   [RFC2974] and SDP are intended to handle.  However in use cases where
   more advanced features like access control always,
      corresponds to the multicast session
   are desired, RTSP could be used for session establishment.

   A client desiring to join a live multicasted media session with
   cryptographic (encryption) access control could use RTSP presentation URI specified in the
   following way.  The source of the session announces the session and
   gives all interested an RTSP URI.
      description.  See Section 13.3 for more information.

   Client:  The client connects to the server
   and requests media service from the presentation description, allowing configuration for
   reception of the media.  In this step it is possible media server.

   Connection:  A transport layer virtual circuit established between
      two programs for the client
   to use secured transport and any desired level purpose of authentication; for
   example, for billing or access control.  An RTSP link also allows for
   load balancing between communication.

   Container file:  A file which may contain multiple servers.

   If these were media streams
      which often constitutes a presentation when played together.  The
      concept of a container file is not embedded in the only goals, they could be achieved by simply using
   HTTP. protocol.
      However, for cases RTSP servers may offer aggregate control on the media
      streams within these files.

   Continuous media:  Data where there is a timing relationship between
      source and sink; that is, the sender likes sink needs to keep track of
   each individual receiver reproduce the timing
      relationship that existed at the source.  The most common examples
      of a session, continuous media are audio and possibly use the session
   as a side channel for distributing key-updates motion video.  Continuous media
      can be real-time (interactive or other information
   on conversational), where there is a per-receiver basis,
      "tight" timing relationship between source and sink, or streaming
      (playback), where the full relationship is less strict.

   Feature-tag:  A tag representing a certain set of receivers functionality, i.e.
      a feature.

   IRI:  Internationalized Resource Identifier, is not know
   prior to the session start, the state establishment that RTSP
   provides can be beneficial.  In this case a client would establish same as an
   RTSP session for this multicast group URI,
      with the RTSP server.  The RTSP
   server will not transmit any media, but instead will point to exception that it allows characters from the
   multicast group.  The client and server will be able to keep whole
      Universal Character Set (Unicode/ISO 10646), rather than the
   session alive US-
      ASCII only.  See [RFC3987] for as long as the receiver participates more information.

   Live:  Normally used to describe a presentation or session with media
      coming from an ongoing event.  This generally results in the
      session
   thus enabling, having an unbound or only loosely defined duration, and
      sometimes no seek operations are possible.

   Media initialization:  Datatype/codec specific initialization.  This
      includes such things as clock rates, color tables, etc.  Any
      transport-independent information which is required by a client
      for example, the server to push updates to playback of a media stream occurs in the client.

   This use case will most likely not be able media initialization
      phase of stream setup.

   Media parameter:  Parameter specific to a media type that may be implemented without
   some extensions to
      changed before or during stream playback.

   Media server:  The server providing playback services for one or more
      media streams.  Different media streams within a presentation may
      originate from different media servers.  A media server may reside
      on the server-to-client push mechanism.  Here same host or on a different host from which the
   PLAY_NOTIFY method (see Section 13.5) with
      presentation is invoked.

   (Media) stream:  A single media instance, e.g., an audio stream or a suitable extension could
   provide clear benefits.

4.  Protocol Parameters

4.1.  RTSP Version

   HTTP specification section [H3.1] applies, with "HTTP" replaced by
   "RTSP".  This specification defines version 2.0
      video stream as well as a single whiteboard or shared application
      group.  When using RTP, a stream consists of RTSP.

4.2.  RTSP IRI and URI

   RTSP 2.0 defines and registers three URI schemas "rtsp", "rtsps" all RTP and
   "rtspu". RTCP
      packets created by a source within an RTP session.

   Message:  The usage basic unit of the last, "rtspu", is unspecified in RTSP 2.0,
   and is defined here to register and reserve communication, consisting of a
      structured sequence of octets matching the URI scheme that is syntax defined in RTSP 1.0.
      Section 20 and transmitted over a connection or a connectionless
      transport.

   Message Body:  The "rtspu" scheme indicates undefined
   transport information transferred as the payload of a
      request or response.  An message body consists of meta-information
      in the RTSP messages over unreliable transport (UDP).  The
   syntax form of "rtsp" message-header and "rtsps" URIs has been changed from RTSP 1.0.

   This specification also defines content in the format form of the RTSP IRI [RFC3987]
   that can be used an
      message-body, as RTSP resource identifiers and locators, described in web
   pages, user interfaces, on paper, etc.  However, the RTSP request
   message format only allows usage Section 9.

   Non-Aggregated Control:  Control of a single media stream.

   Presentation:  A set of one or more streams presented to the absolute URI format.  The
   RTSP IRI format SHALL use the rules client
      as a complete media feed and transformation for IRIs described by a presentation
      description as defined below.  Presentations with more than one
      media stream are often handled in [RFC3987].  This way RTSP 2.0 URIs for request can be
   produced from an RTSP IRI.

   The RTSP IRI and URI are both syntax restricted compared to under aggregate control.

   Presentation description:  A presentation description contains
      information about one or more media streams within a presentation,
      such as the
   generic syntax defined in [RFC3986] set of encodings, network addresses and RFC [RFC3987]:

   o  An absolute URI requires the authority part; i.e., a host identity
      must be provided.

   o  Parameters in information
      about the path element are prefixed with content.  Other IETF protocols such as SDP ([RFC4566])
      use the reserved
      separator ";". term "session" for a presentation.  The presentation
      description may take several different formats, including but not
      limited to the session description protocol format, SDP.

   Response:  An RTSP URI and IRI response.  If an HTTP response is case sensitive, with the exception of those
   parts meant, that [RFC3986] and [RFC3987] defines as case-insensitive; for
   example, the scheme and host part.

   The fragment identifier is used as defined in sections 3.5 and 4.3 of
   [RFC3986], i.e. the fragment
      indicated explicitly.

   Request:  An RTSP request.  If an HTTP request is to be stripped from the meant, that is
      indicated explicitly.

   Request-URI:  The URI by the
   requestor and not included used in the request.  The user agent also needs a request to interpret the value of indicate the fragment based resource on the media type
      which the request relates to; i.e., the media type indicated in Content-Type
   header in the response to DESCRIBE.

   The syntax of any URI query string is unspecified and responder
   (usually the server) specific.  The query is, from the requestor's
   perspective, an opaque string and needs to be handled as such.

   The URI scheme "rtsp" requires performed.

   RTSP agent:  Refers to either an RTSP client, an RTSP server, or an
      RTSP proxy.  In this specification, there are many capabilities
      that commands are issued via a
   reliable protocol (within common to these three entities such as the Internet, TCP), while capability to
      send requests or receive responses.  This term will be used when
      describing functionality that is applicable to all three of these
      entities.

   RTSP session:  A stateful abstraction upon which the scheme
   "rtsps" identifies main control
      methods of RTSP operate.  An RTSP session is a reliable transport using secure transport (TLS
   [RFC5246], see (Section 19).

   For server entity; it
      is created, maintained and destroyed by the scheme "rtsp", if no port number server.  It is provided in
      established by an RTSP server upon the authority
   part completion of the URI port number 554 SHALL be used.  For the scheme
   "rtsps", the TCP port 322 a successful
      SETUP request (when a 200 OK response is registered sent) and SHALL be assumed.

   A presentation or a stream is identified by labelled
      with a textual media
   identifier, using session identifier at that time.  The session exists until
      timed out by the character set and escape conventions of URIs
   [RFC3986].  URIs may refer to a stream server or explicitly removed by a TEARDOWN
      request.  An RTSP session is a stateful entity; an aggregate RTSP server
      maintains an explicit session state machine (see Appendix A) where
      most state transitions are triggered by client requests.  The
      existence of streams;
   i.e., a presentation.  Accordingly, requests described in
   (Section 13) can apply to either the whole presentation or an
   individual stream within session implies the presentation.  Note that some request
   methods existence of state about the
      session's media streams and their respective transport mechanisms.
      A given session can only be applied have one or more media streams associated with
      it.  An RTSP server uses the session to streams, not presentations, aggregate control over
      multiple media streams.

   Transport initialization:  The negotiation of transport information
      (e.g., port numbers, transport protocols) between the client and vice
   versa.

   For example,
      the RTSP server.

   URI:

      rtsp://media.example.com:554/twister/audiotrack

   may identify the audio stream within the presentation "twister",
   which can be controlled via  Universal Resource Identifier, see [RFC3986].  The URIs used in
      RTSP requests issued over are generally URLs as they give a TCP
   connection to port 554 location for the resource.
      As URLs are a subset of host media.example.com.

   Also, URIs, they will be referred to as URIs to
      cover also the cases when an RTSP URI:

      rtsp://media.example.com:554/twister URI would not be an URL.

   URL:  Universal Resource Locator, is an URI which identifies the presentation "twister", which may be composed
      resource through its primary access mechanism, rather than
      identifying the resource by name or by some other attribute(s) of audio
   and video streams, but could also be something else like a random
   media redirector.
      that resource.

4.  Protocol Parameters

4.1.  RTSP Version

   This does not imply specification defines version 2.0 of RTSP.

   RTSP uses a standard way "<major>.<minor>" numbering scheme to reference streams in URIs. indicate versions
   of the protocol.  The presentation description defines protocol versioning policy is intended to allow
   the hierarchical
      relationships in sender to indicate the presentation format of a message and the URIs its capacity for
   understanding further RTSP communication, rather than the individual
      streams.  A presentation description may name a stream "a.mov" and features
   obtained via that communication.  No change is made to the whole presentation "b.mov".

   The path components version
   number for the addition of message components which do not affect
   communication behavior or which only add to extensible field values.

   The <minor> number is incremented when the RTSP URI are opaque changes made to the client and
   protocol add features which do not imply any particular file system structure for change the server.

      This decoupling also allows presentation descriptions general message parsing
   algorithm, but which may add to be used
      with non-RTSP media control protocols simply by replacing the
      scheme in message semantics and imply
   additional capabilities of the URI.

4.3.  Session Identifiers

   Session identifiers are strings sender.  The <major> number is
   incremented when the format of any arbitrary length but with a
   minimum length message within the protocol is
   changed.  The version of 8 characters.  A session identifier an RTSP message is indicated by an RTSP-
   Version field in the first line of the message.  Note that the major
   and minor numbers MUST be chosen
   cryptographically random (see [RFC4086]) treated as separate integers and MUST that each
   MAY be at least 8
   characters long (can contain incremented higher than a maximum of 48 bits of entropy) to make
   guessing it more difficult.  It single digit.  Thus, RTSP/2.4 is RECOMMENDED that it contains 128
   bits of entropy, i.e. approxamitely 22 characters from a high quality
   generator. (see Section 21.)  However, it needs to be noted that the
   session identifier does not provide any security against session
   hijacking unless it
   lower version than RTSP/2.13, which in turn is kept confidential between client, server lower than RTSP/12.3.
   Leading zeros MUST be ignored by recipients and
   trusted proxies.

4.4.  SMPTE Relative Timestamps

   A SMPTE relative timestamp expresses time relative MUST NOT be sent.

4.2.  RTSP IRI and URI

   RTSP 2.0 defines and registers three URI schemes "rtsp", "rtsps" and
   "rtspu".  The usage of the last, "rtspu", is unspecified in RTSP 2.0,
   and is defined here to register and reserve the start URI scheme that is
   defined in RTSP 1.0.  The "rtspu" scheme indicates undefined
   transport of the clip.  Relative timestamps are expressed as SMPTE time codes for
   frame-level access accuracy. RTSP messages over unreliable transport (UDP).  The time code
   syntax of "rtsp" and "rtsps" URIs has been changed from RTSP 1.0.

   This specification also defines the format

      hours:minutes:seconds:frames.subframes,

   with of the origin at RTSP IRI [RFC3987]
   that can be used as RTSP resource identifiers and locators, in web
   pages, user interfaces, on paper, etc.  However, the start RTSP request
   message format only allows usage of the clip. absolute URI format.  The default smpte
   RTSP IRI format
   is "SMPTE 30 drop" format, with frame rate is 29.97 frames per
   second.  Other SMPTE codes MAY MUST use the rules and transformation for IRIs
   defined in [RFC3987].  This way RTSP 2.0 URIs for request can be supported (such as "SMPTE 25")
   through
   produced from an RTSP IRI.

   The RTSP IRI and URI are both syntax restricted compared to the use of alternative use of "smpte-type".  For SMPTE 30,
   generic syntax defined in [RFC3986] and RFC [RFC3987]:

   o  An absolute URI requires the "frames" field authority part; i.e., a host identity
      must be provided.

   o  Parameters in the time value can assume path element are prefixed with the values 0 through
   29. reserved
      separator ";".

   The difference between 30 RTSP URI and 29.97 frames per second IRI is handled
   by dropping case sensitive, with the first two frame indices (values 00 and 01) exception of every
   minute, except every tenth minute.  If the frame those
   parts that [RFC3986] and [RFC3987] defines as case-insensitive; for
   example, the subframe
   values are zero, they may be omitted.  Subframes are measured scheme and host part.

   The fragment identifier is used as defined in one-
   hundredth sections 3.5 and 4.3 of a frame.

   Examples:

     smpte=10:12:33:20-
     smpte=10:07:33-
     smpte=10:07:00-10:07:33:05.01
     smpte-25=10:07:00-10:07:33:05.01

4.5.  Normal Play Time

   Normal play time (NPT) indicates
   [RFC3986], i.e. the stream absolute position
   relative fragment is to be stripped from the beginning of IRI by the presentation,
   requester and not to be confused
   with included in the Network Time Protocol (NTP) [RFC1305].  The timestamp
   consists of a decimal fraction. request URI.  The part left user agent needs
   to interpret the value of the decimal may be
   expressed fragment based on the media type the
   request relates to; i.e., the media type indicated in Content-Type
   header in either seconds or hours, minutes, and seconds.  The part
   right of the decimal point measures fractions of a second.

   The beginning of a presentation corresponds response to 0.0 seconds.  Negative
   values are not defined. DESCRIBE.

   The special constant "now" syntax of any URI query string is defined as unspecified and responder
   (usually the
   current instant of a live event.  It MAY only be used for live
   events, server) specific.  The query is, from the requester's
   perspective, an opaque string and SHALL NOT needs to be used for on-demand (i.e., non-live) content.

   NPT is defined handled as in DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is
   the clock the viewer associates such.
   Please note that relative URI with a program.  It is often
   digitally displayed on a VCR.  NPT advances normally when in normal
   play mode (scale = 1), advances at a faster rate when in fast scan
   forward (high positive scale ratio), decrements when in scan reverse
   (high negative scale ratio) and is fixed in pause mode.  NPT is
   (logically) equivalent to SMPTE time codes."

   Examples:

     npt=123.45-125
     npt=12:05:35.3-
     npt=now-

      The syntax conforms to ISO 8601 [ISO.8601.2000].  The npt-sec
      notation is optimized for automatic generation, the npt-hhmmss
      notation for consumption by human readers.  The "now" constant
      allows clients queries are difficult to request handle
   due to receive the live feed rather than RFC 3986 relative URI handling rules.  Any change of the
      stored or time-delayed version.  This is needed since neither
      absolute time nor zero time are appropriate for this case.

4.6.  Absolute Time

   Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps,
   path element using UTC (GMT).  Fractions of a second may be indicated.

   Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
   UTC:

     19961108T143720.25Z

4.7.  Feature-tags

   Feature-tags are unique identifiers used to designate features in
   RTSP.  These tags are used relative URI results in Require (Section 16.42), Proxy-Require
   (Section 16.35), Proxy-Supported (Section 16.36), and Unsupported
   (Section 16.52) header fields.

   A feature-tag definition MUST indicate which combination the stripping of clients,
   servers or proxies they applies to. the
   query.  Which means the relative part needs to contain the query.

   The creator of URI scheme "rtsp" requires that commands are issued via a new RTSP feature-tag should either prefix
   reliable protocol (within the
   feature-tag with Internet, TCP), while the scheme
   "rtsps" identifies a reverse domain name (e.g.,
   "com.example.mynewfeature" reliable transport using secure transport (TLS
   [RFC5246], see (Section 19).

   For the scheme "rtsp", if no port number is an apt name for a feature whose
   inventor can provided in the authority
   part of the URI port number 554 MUST be reached at "example.com"), or register used.  For the new
   feature-tag with scheme
   "rtsps", the Internet Assigned Numbers Authority (IANA) (see
   IANA Section 22).

   The usage of feature-tags TCP port 322 is further described in Section 11 that
   deals with capability handling.

4.8.  Entity Tags

   Entity tags are opaque strings that are used to compare two entities
   from the same resource, for example in caches registered and MUST be assumed.

   A presentation or to optimize setup
   after a redirect.  Further explanation stream is present in [H3.11].  For an
   explanation identified by a textual media
   identifier, using the character set and escape conventions of how URIs
   [RFC3986].  URIs may refer to compare entity tags see [H13.3].  Entity tags
   can be carried in the ETag header (see Section 16.21) a stream or an aggregate of streams;
   i.e., a presentation.  Accordingly, requests described in SDP (see
   Appendix D.1.9).

   Entity tags are used in RTSP
   (Section 13) can apply to make some methods conditional.  The
   methods are made conditional through either the inclusion of headers, see
   Section 16.24 and Section 16.26. whole presentation or an
   individual stream within the presentation.  Note that RTSP entity tags apply some request
   methods can only be applied to streams, not presentations, and vice
   versa.

   For example, the complete presentation; i.e., both RTSP URI:

      rtsp://media.example.com:554/twister/audiotrack

   may identify the session description and audio stream within the
   individual media streams.  Thus entity tags presentation "twister",
   which can be used to verify at
   setup time after controlled via RTSP requests issued over a redirect that the same session description applies TCP
   connection to port 554 of host media.example.com.

   Also, the media at the new location using the If-Match header.

5.  RTSP Message RTSP is a text-based protocol and uses URI:

      rtsp://media.example.com:554/twister

   identifies the ISO 10646 character set in
   UTF-8 encoding (RFC 3629 [RFC3629]).  Lines SHALL presentation "twister", which may be terminated by
   CRLF.

      Text-based protocols make it easier to add optional parameters in
      a self-describing manner.  Since the number composed of parameters audio
   and the
      frequency of commands is low, processing efficiency is video streams, but could also be something else like a random
   media redirector.

      This does not imply a
      concern.  Text-based protocols, if done carefully, also allow easy
      implementation of research prototypes standard way to reference streams in scripting languages such
      as Tcl, Visual Basic and Perl. URIs.
      The ISO 10646 character set avoids tricky character set switching,
   but is invisible to presentation description defines the application as long as US-ASCII is being
   used.  This is also hierarchical
      relationships in the encoding used presentation and the URIs for RTCP [RFC3550].  ISO 8859-1
   translates directly into Unicode with the individual
      streams.  A presentation description may name a high-order octet stream "a.mov" and
      the whole presentation "b.mov".

   The path components of zero.
   ISO 8859-1 characters with the most-significant bit set RTSP URI are
   represented as 1100001x 10xxxxxx.  (See RFC 3629 [RFC3629])

   Requests contain methods, the object opaque to the method is operating upon client and
   parameters to further describe do
   not imply any particular file system structure for the method.  Methods are idempotent
   unless otherwise noted.  Methods are server.

      This decoupling also designed allows presentation descriptions to require little
   or no state maintenance at the be used
      with non-RTSP media server.

5.1.  Message Types

   RTSP messages consist of requests from client to server or server to
   client and responses in control protocols simply by replacing the reverse direction.  Request Section 7 and
   Response Section 8 messages use
      scheme in the generic message format URI.

4.3.  Session Identifiers

   Session identifiers are strings of RFC 822
   [9] for transferring entities (the payload any arbitrary length but with a
   minimum length of the message).  Both
   types 8 characters.  A session identifier MUST be chosen
   cryptographically random (see [RFC4086]) and MUST be at least 8
   characters long (can contain a maximum of message consist 48 bits of a start-line, zero or entropy) to make
   guessing it more header fields
   (also known as "headers"), an empty line (i.e., a line with nothing
   preceding the CRLF) indicating the end difficult.  It is RECOMMENDED that it contains 128
   bits of the header fields, and
   possibly entropy, i.e. approximately 22 characters from a message-body.

   generic-message = start-line
                   *(message-header CRLF)
                     CRLF
                   [ message-body ]
   start-line = Request-Line | Status-Line

   In high quality
   generator. (see Section 21.)  However, it needs to be noted that the interest of robustness, servers SHOULD ignore
   session identifier does not provide any empty
   line(s) received where a Request-Line security against session
   hijacking unless it is expected.  In other words,
   if the kept confidential between client, server is reading the protocol stream at and
   trusted proxies.

4.4.  SMPTE Relative Timestamps

   A SMPTE relative timestamp expresses time relative to the beginning start of a
   message and receives a CRLF first, it should ignore
   the CRLF.

5.2.  Message Headers

   See [H4.2].

   Unknown message headers SHALL be ignored by a RTSP server or client.
   An RTSP Proxy SHALL forward unknown message headers.  Message headers
   defined outside of this specification that clip.  Relative timestamps are required to be
   interpret by expressed as SMPTE time codes for
   frame-level access accuracy.  The time code has the RTSP agent will need to use feature tags
   (Section 4.7) and include it in format

      hours:minutes:seconds:frames.subframes,

   with the appropriate Require
   (Section 16.42) or Proxy-Require (Section 16.35) header.

5.3.  Message Body

   See [H4.3].

   Unlike HTTP, origin at the presence start of a message-body in either a request or a
   response MUST be signaled by the inclusion of a Content-Length header
   field (see Section 16.16).

5.4.  Message Length

   When a message body clip.  The default SMPTE format
   is included "SMPTE 30 drop" format, with a message, frame rate is 29.97 frames per
   second.  Other SMPTE codes MAY be supported (such as "SMPTE 25")
   through the length use of that
   body is determined by one alternative use of "smpte-type".  For SMPTE 30,
   the following (in order of precedence):

   1.  Any response message which MUST NOT include a message body (such
       as "frames" field in the 1xx, 204, time value can assume the values 0 through
   29.  The difference between 30 and 304 responses) 29.97 frames per second is always terminated handled
   by dropping the first empty line after the header fields, regardless two frame indices (values 00 and 01) of every
   minute, except every tenth minute.  If the
       entity-header fields present in frame and the message.  (Note: An empty
       line is subframe
   values are zero, they may be omitted.  Subframes are measured in one-
   hundredth of a line with nothing preceding frame.

   Examples:

     smpte=10:12:33:20-
     smpte=10:07:33-
     smpte=10:07:00-10:07:33:05.01
     smpte-25=10:07:00-10:07:33:05.01

4.5.  Normal Play Time

   Normal play time (NPT) indicates the CRLF.)

   2.  If a Content-Length header field (Section 16.16) is present, its
       value in bytes represents stream absolute position
   relative to the length beginning of the message-body.  If
       this header field is presentation, not present, a value to be confused
   with the Network Time Protocol (NTP) [RFC1305].  The timestamp
   consists of zero is assumed.

   Unlike an HTTP message, an RTSP message MUST contain a Content-Length
   header field whenever it contains a message body.  Note that RTSP
   does not support decimal fraction.  The part left of the HTTP/1.1 "chunked" transfer coding (see
   [H3.6.1]).

      Given decimal may be
   expressed in either seconds or hours, minutes, and seconds.  The part
   right of the moderate length decimal point measures fractions of a second.

   The beginning of a presentation descriptions returned,
      the server should always be able corresponds to determine its length, even if
      it is generated dynamically, making the chunked transfer encoding
      unnecessary.

6.  General Header Fields

   See [H4.5], except that the Pragma, Trailer, Transfer-Encoding,
   Upgrade, and Warning headers 0.0 seconds.  Negative
   values are not defined.  RTSP further defines

   The special constant "now" is defined as the CSeq, Pipelined-Requests, Proxy-Supported current instant of a
   live event.  It MAY only be used for live events, and Timestamp headers.
   The general headers are listed MUST NOT be
   used for on-demand (i.e., non-live) content.

   NPT is defined as in Table 1:

                +--------------------+--------------------+
                | Header Name        | Defined DSM-CC [ISO.13818-6.1995]: "Intuitively, NPT is
   the clock the viewer associates with a program.  It is often
   digitally displayed on a VCR.  NPT advances normally when in Section |
                +--------------------+--------------------+
                | Cache-Control      | Section 16.10      |
                |                    |                    |
                | Connection         | Section 16.11      |
                |                    |                    |
                | CSeq               | Section 16.19      |
                |                    |                    |
                | Date               | Section 16.20      |
                |                    |                    |
                | Media-Properties   | Section 16.29      |
                |                    |                    |
                | Media-Range        | Section 16.30      |
                |                    |                    |
                | Pipelined-Requests | Section 16.32      |
                |                    |                    |
                | Proxy-Supported    | Section 16.36      |
                |                    |                    |
                | Seek-Style         | Section 16.45      |
                |                    |                    |
                | Supported          | Section 16.49      |
                |                    |                    |
                | Timestamp          | Section 16.50      |
                |                    |                    |
                | Via                | Section 16.55      |
                +--------------------+--------------------+

                 Table 1: The general headers used normal
   play mode (scale = 1), advances at a faster rate when in RTSP

7.  Request

   A fast scan
   forward (high positive scale ratio), decrements when in scan reverse
   (high negative scale ratio) and is fixed in pause mode.  NPT is
   (logically) equivalent to SMPTE time codes."

   Examples:

     npt=123.45-125
     npt=12:05:35.3-
     npt=now-

      The syntax conforms to ISO 8601 [ISO.8601.2000].  The npt-sec
      notation is optimized for automatic generation, the npt-hhmmss
      notation for consumption by human readers.  The "now" constant
      allows clients to request message uses to receive the format outlined below regardless of live feed rather than the
   direction
      stored or time-delayed version.  This is needed since neither
      absolute time nor zero time are appropriate for this case.

4.6.  Absolute Time

   Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps,
   using UTC (GMT).  Fractions of a request, client second may be indicated.

   Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
   UTC:

     19961108T143720.25Z

4.7.  Feature-tags

   Feature-tags are unique identifiers used to server designate features in
   RTSP.  These tags are used in Require (Section 16.42), Proxy-Require
   (Section 16.35), Proxy-Supported (Section 16.36), and Unsupported
   (Section 16.53) header fields.

   A feature-tag definition MUST indicate which combination of clients,
   servers or server to client:

   o  Request line, containing proxies they applies to.

   The creator of a new RTSP feature-tag should either prefix the method to
   feature-tag with a reverse domain name (e.g.,
   "com.example.mynewfeature" is an apt name for a feature whose
   inventor can be applied to reached at "example.com"), or register the resource, new
   feature-tag with the identifier Internet Assigned Numbers Authority (IANA) (see
   IANA Section 22).

   The usage of feature-tags is further described in Section 11 that
   deals with capability handling.

4.8.  Message Body Tags

   Message body tags are opaque strings that are used to compare two
   message bodies from the same resource, and the protocol version for example in use;

   o  Zero caches or more Header lines, that to
   optimize setup after a redirect.  Message body tags can be of carried in
   the following types:
      general (Section 6), request (Section 7.2), MTag header (see Section 16.30) or entity
      (Section 9.1);

   o  One empty line (CRLF) to indicate the end in SDP (see Appendix D.1.9).

   A message body tag MUST be unique across all versions of the header section;

   o  Optionally all message
   bodies associated with a particular resource.  A given message body (entity), consisting of one or more
      lines.
   tag value MAY be used for message body obtained by requests on
   different URIs.  The length use of the same message body tag value in bytes is indicated
   conjunction with message bodies obtained by
      the Content-Length entity header.

7.1.  Request Line

   The request line provides the key information about the request: what
   method, requests on what resources and using which different
   URIs does not imply the equivalence of those message bodies

   Message body tags are used in RTSP version. to make some methods conditional.
   The methods
   that are defined by this specification are listed in Table 2.

                  +---------------+--------------------+
                  | Method        | Defined in Section |
                  +---------------+--------------------+
                  | DESCRIBE      | Section 13.2       |
                  |               |                    |
                  | GET_PARAMETER | Section 13.8       |
                  |               |                    |
                  | OPTIONS       | Section 13.1       |
                  |               |                    |
                  | PAUSE         | Section 13.6       |
                  |               |                    |
                  | PLAY          | Section 13.4       |
                  |               |                    |
                  | PLAY_NOTIFY   | Section 13.5       |
                  |               |                    |
                  | REDIRECT      | Section 13.10      |
                  |               |                    |
                  | SETUP         | Section 13.3       |
                  |               |                    |
                  | SET_PARAMETER | made conditional through the inclusion of headers,
   see Section 13.9       |
                  |               |                    |
                  | TEARDOWN      | 16.23 and Section 13.7       |
                  +---------------+--------------------+

                         Table 2: The RTSP Methods

   The syntax of the 16.25.  Note that RTSP request line is the following:

      <Method> <Request-URI> <RTSP-Version> CRLF

   Note: This syntax cannot be freely changed in future versions of
   RTSP.  This line needs message body
   tags apply to remain parsable by older RTSP
   implementations since it indicates the RTSP version of the message.

   In contrast to HTTP/1.1 [RFC2616], RTSP requests identify complete presentation; i.e., both the
   resource through an absolute RTSP URI (scheme, host, session
   description and port) (see
   Section 4.2) rather than just the absolute path.

      HTTP/1.1 requires servers individual media streams.  Thus message body tags
   can be used to understand verify at setup time after a redirect that the absolute URI, but
      clients are supposed same
   session description applies to use the Host request media at the new location using
   the If-Match header.  This

4.9.  Media Properties

   When RTSP handles media it is
      purely needed for backward-compatibility with HTTP/1.0 servers, a
      consideration that does not apply important to RTSP.

   An asterisk "*" consider the different
   properties a media instance for playback can be used instead of an absolute URI have.  This
   specification considers the below listed media properties in its
   protocol operations.  They are derived from the
   Request-URI part to indicate differences between a
   number of supported usages.

   On-demand:  Media that the request does not apply to has a
   particular resource, but to fixed (given) duration that doesn't
      change during the server or proxy itself, and is only
   allowed when life time of the request method does not necessarily apply to a
   resource.

   For example:

      OPTIONS * RTSP/2.0

   An OPTIONS in this form will determine RTSP session and are known at
      the capabilities time of the server
   or creation of the proxy session.  It is expected that first receives the request.  If
      content of the capability media will not change, even if the representation,
      i.e encoding, quality, etc, may change.  Generally one can seek
      within the media i.e. randomly access any range of the specific server needs media
      stream to be determined, without regard playback.

   Dynamic On-demand:  This is a variation of the on-demand case where
      external methods are used to manipulate the
   capability actual content of an intervening proxy, the server should be addressed
   explicitly with an absolute URI that contains
      media setup for the server's address.

   For example:

      OPTIONS rtsp://example.com RTSP/2.0

7.2.  Request Header Fields

   The RTSP headers in Table 3 can be included in session.  The main example is where a request, as request
   headers, to modify the specifics of
      playlist determines the request.  Some content of these
   headers may also be used in the response to session.

   Live:  Live media represents a request, progressing content stream (such as response
   headers, to modify
      broadcast TV) where the specifics of a response (Section 8.2).

                +--------------------+--------------------+
                | Header             | Defined in Section |
                +--------------------+--------------------+
                | Accept             | Section 16.1       |
                |                    |                    |
                | Accept-Credentials | Section 16.2       |
                |                    |                    |
                | Accept-Encoding    | Section 16.3       |
                |                    |                    |
                | Accept-Language    | Section 16.4       |
                |                    |                    |
                | Authorization      | Section 16.7       |
                |                    |                    |
                | Bandwidth          | Section 16.8       |
                |                    |                    |
                | Blocksize          | Section 16.9       |
                |                    |                    |
                | From               | Section 16.23      |
                |                    |                    |
                | If-Match           | Section 16.24      |
                |                    |                    |
                | If-Modified-Since  | Section 16.25      |
                |                    |                    |
                | If-None-Match      | Section 16.26      |
                |                    |                    |
                | Notify-Reason      | Section 16.31      |
                |                    |                    |
                | Proxy-Require      | Section 16.35      |
                |                    |                    |
                | Range              | Section 16.38      |
                |                    |                    |
                | Referer            | Section 16.39      |
                |                    |                    |
                | Request-Status     | Section 16.41      |
                |                    |                    |
                | Require            | Section 16.42      |
                |                    |                    |
                | Scale              | Section 16.44      |
                |                    |                    |
                | Session            | Section 16.48      |
                |                    |                    |
                | Speed              | Section 16.46      |
                |                    |                    |
                | Supported          | Section 16.49      |
                |                    |                    |
                | Transport          | Section 16.51      |
                |                    |                    |
                | User-Agent         | Section 16.53      |
                +--------------------+--------------------+

                     Table 3: The RTSP request headers

   Detailed headers definition are provided in Section 16.

   New request headers duration may or may not be defined.  If the receiver of the request known.  It is required to understand the request header,
      not seekable, only the request MUST
   include a corresponding feature tag in content presently being delivered can be
      accessed.

   Live with Recording:  A Live stream that is combined with a Require or Proxy-Require
   header server
      side capability to ensure store and retain the processing content of the header. actually happens.

8.  Response

   [H6] applies except that HTTP-Version is replaced by RTSP-Version.
   Also, RTSP defines additional status codes and does not define some live
      session for random access playback within the part of the HTTP codes. already
      recorded content.  The valid response codes and actual behavior of the methods they can media stream is very
      much depending on the retention policy for the media stream.
      Either the server will be used with are listed in Table 4.

   After receiving and interpreting able to capture the complete media
      stream, or it will have a request message, limitation in how much will be retained.
      The media range will dynamically change as the recipient
   responds session progress.
      For servers with an RTSP response message.

8.1.  Status-Line

   The first line of a Response message is the Status-Line, consisting limited amount of the protocol version followed by storage available for
      recording, there will be a numeric status code sliding window that goes forwards while
      data is made available and content that is older than the
   textual phrase associated with
      limitation will be discarded.

   Considering the status code, with each element
   separated by SP characters.  No CR or LF is allowed except in above usages one get the
   final CRLF sequence.

   <RTSP-Version> SP <Status-Code> SP <Reason-Phrase> CRLF

8.1.1.  Status Code following media properties
   and Reason Phrase

   The Status-Code element their different instance values.

4.9.1.  Random Access

   Random Access, i.e. if one can request that the playback point is a 3-digit integer result code of
   moved from one point in the
   attempt media duration to understand and satisfy another.  The following
   different values are considered:

   Random Access:  Yes the request.  These codes media are fully
   defined in Section 15.  The Reason-Phrase is intended seekable to give any out of a short
   textual description large
      number of points within the Status-Code.  The Status-Code is intended
   for use media.  Due to media encoding
      limitations a particular point may not be reachable, but seeking
      to a point close by automata and the Reason-Phrase is intended for enabled.  A floating point number of
      seconds may be provided to express the human
   user.  The client worst case distance between
      random access points.

   Return To Start:  Seeking is not required only possible to examine or display the Reason-
   Phrase.

   The first digit beginning of the Status-Code defines the class of response.
   The last two digits do
      content.

   No seeking:  Seeking is not possible at all.

4.9.2.  Retention

   Media may have any categorization role.  There are 5
   values for different retention policy in place that affect the first digit:

   1xx:  Informational - Request received, continuing process

   2xx:  Success -
   operation on the media.  The action was successfully received, understood, following different media retention
   policies are envisioned and
         accepted

   3rr:  Redirection - Further action needs to be taken in order to
         complete into consideration where
   applicable.

   Unlimited:  The media will not be removed as long as the request

   4xx:  Client Error - RTSP session
      is in existence.

   Time Limited:  The request contains bad syntax media will at least not be removed before given
      wallclock time.  After that time it may or cannot may not be
         fulfilled
   5xx:  Server Error - The server failed to fulfill an apparently valid
         request

   The available
      any more.

   Duration limited:  Each individual values unit of the numeric status codes defined media will be retained
      for
   RTSP/2.0, and an example set the specified duration.

4.9.3.  Content Modifications

   There is also the question of corresponding Reason-Phrases, are
   presented in Table 4. how the content may change during time
   for a give media resource:

   Immutable:  The reason phrases listed here are only
   recommended; they content of the media will not change, even if the
      representation, i.e encoding, quality, etc, may be replaced by local equivalents without
   affecting change.

   Dynamic:  Between explicit updates the protocol.  Note that RTSP adopts most HTTP/1.1
   [RFC2616] status codes and adds RTSP-specific status codes starting
   at x50 to avoid conflicts with newly defined HTTP status codes.

   RTSP status codes are extensible.  RTSP applications are media content will not required
   to understand change,
      but the meaning of all registered status codes, though content may change due to external methods or triggers,
      such
   understanding is obviously desirable.  However, applications MUST
   understand the class of any status code, as indicated by playlists.

   Time Progressing:  As times progress new content will become
      available.  If the first
   digit, content also is retained it will become longer
      and treat any unrecognized response longer as everything between the start point and the point in
      currently being equivalent to made available can be accessed.

4.9.4.  Supported Scale Factors

   The content is often limiting the
   x00 status code possible rates of scale that class, can be
   supported when delivering the media.  To enable the client to know
   what values or ranges of scale operations that the whole content or
   the current position supports a media properties attribute for this
   is defined.  It contains a list with the exception values and/or ranges that an
   unrecognized response MUST NOT
   are supported.  The attribute is named "Scales".  It may be cached.  For example, if an
   unrecognized status code updated
   at any point in the content due to content consisting of 431 is received spliced
   pieces or content being dynamically updated by out of bands
   mechanisms.

4.9.5.  Mapping to the client, it can
   safely assume that there was something wrong Attributes

   This section exemplifies how one would map the above listed usages to
   the properties and their values.

   On-demand:  Random Access: Random Access=5s, Content Modifications:
      Immutable, Retention: unlimited or time limited.

   Dynamic On-demand:  Random Access: Random Access=3s, Content
      Modifications: Dynamic, Retention: unlimited or time limited.

   Live:  Random Access: No seeking, Content Modifications: Time
      Progressing, Retention: Duration limited=0.0s

   Live with its request Recording:  Random Access: Random Access=3s, Content
      Modifications: Time Progressing, Retention: Duration limited=2H

5.  RTSP Message

   RTSP is a text-based protocol and
   treat uses the response as if ISO 10646 character set in
   UTF-8 encoding (RFC 3629 [RFC3629]).  Lines MUST be terminated by
   CRLF.

      Text-based protocols make it had received easier to add optional parameters in
      a 400 status code.  In self-describing manner.  Since the number of parameters and the
      frequency of commands is low, processing efficiency is not a
      concern.  Text-based protocols, if done carefully, also allow easy
      implementation of research prototypes in scripting languages such
   cases, user agents SHOULD present
      as TCL, Visual Basic and Perl.

   The ISO 10646 character set avoids tricky character set switching,
   but is invisible to the user application as long as US-ASCII is being
   used.  This is also the entity returned encoding used for RTCP [RFC3550].  ISO 8859-1
   translates directly into Unicode with a high-order octet of zero.
   ISO 8859-1 characters with the response, since that entity most-significant bit set are
   represented as 1100001x 10xxxxxx.  (See RFC 3629 [RFC3629])

   Requests contain methods, the object the method is likely operating upon and
   parameters to include human-
   readable information which will explain further describe the unusual status.

    +------+----------------------------------------+-----------------+
    | Code | Reason                                 | Method          |
    +------+----------------------------------------+-----------------+
    | 100  | Continue                               | all             |
    |      |                                        |                 |
    |      |                                        |                 |
    | 200  | OK                                     | all             |
    |      |                                        |                 |
    |      |                                        |                 |
    | 300 method.  Methods are idempotent
   unless otherwise noted.  Methods are also designed to require little
   or no state maintenance at the media server.

5.1.  Message Types

   RTSP messages consist of requests from client to server or server to
   client and responses in the reverse direction.  Request Section 7 and
   Response Section 8 messages use the generic message format of RFC 822
   [9] for transferring entities (the payload of the message).  Both
   types of message consist of a start-line, zero or more header fields
   (also known as "headers"), an empty line (i.e., a line with nothing
   preceding the CRLF) indicating the end of the header, and possibly a
   message-body.

   generic-message = start-line
                   *(message-header CRLF)
                     CRLF
                   [ message-body ]
   start-line = Request-Line | Status-Line

   In the interest of robustness, servers SHOULD ignore any empty
   line(s) received where a Request-Line is expected.  In other words,
   if the server is reading the protocol stream at the beginning of a
   message and receives a CRLF first, it should ignore the CRLF.

5.2.  Message Headers

   RTSP header fields (see Section 16) include general-header, request-
   header, response-header, and entity-header fields.

   The order in which header fields with differing field names are
   received is not significant.  However, it is "good practice" to send
   general-header fields first, followed by request-header or response-
   header fields, and ending with the entity-header fields.

   Multiple Choices                       | all             |
    |      |                                        |                 |
    | 301  | Moved Permanently                      | all             |
    |      |                                        |                 |
    | 302  | Found                                  | all             |
    |      |                                        |                 |
    | 303  | See Other                              | all             |
    |      |                                        |                 |
    | 305  | Use message-header fields with the same field-name MAY be
   present in a message if and only if the entire field-value for that
   header field is defined as a comma-separated list [i.e., #(values)].
   It MUST be possible to combine the multiple header fields into one
   "field-name: field-value" pair, without changing the semantics of the
   message, by appending each subsequent field-value to the first, each
   separated by a comma.  The order in which header fields with the same
   field-name are received is therefore significant to the
   interpretation of the combined field value, and thus a proxy MUST NOT
   change the order of these field values when a message is forwarded.

   Unknown message headers MUST be ignored by a RTSP server or client.
   An RTSP Proxy                              | all             |
    |      |                                        |                 |
    |      |                                        |                 |
    | 400  | Bad Request                            | all             |
    |      |                                        |                 |
    | 401  | Unauthorized                           | all             |
    | 402  | Payment Required                       | all             |
    |      |                                        |                 |
    | 403  | Forbidden                              | all             |
    |      |                                        |                 |
    | 404  | Not Found                              | all             |
    |      |                                        |                 |
    | 405  | MUST forward unknown message headers.  Message headers
   defined outside of this specification that are required to be
   interpret by the RTSP agent will need to use feature tags
   (Section 4.7) and include it in the appropriate Require
   (Section 16.42) or Proxy-Require (Section 16.35) header.

5.3.  Message Body

   The message-body (if any) of an RTSP message is used to carry further
   information for a particular resource associated with the request or
   response.  An example for a message body is the Session Description
   Protocol (SDP).

   The presence of a message-body in either a request or a response MUST
   be signaled by the inclusion of a Content-Length header (see
   Section 16.16).

   The presence of a message-body in a request is signaled by the
   inclusion of a Content-Length header field in the RTSP message.  A
   message-body MUST NOT be included in a request or response if the
   specification of the particular method (see Method Not Allowed                     | all             |
    |      |                                        |                 |
    | 406  | Not Acceptable                         | all             |
    |      |                                        |                 | Definitions
   (Section 13)) does not allow sending an message body.  A server
   SHOULD read and forward a message-body on any request; if the request
   method does not include defined semantics for a message body, then
   the message-body SHOULD be ignored when handling the request..

5.4.  Message Length

   When a message body is included with a message, the length of that
   body is determined by one of the following (in order of precedence):

   1.  Any response message which MUST NOT include a message body (such
       as the 1xx, 204, and 304 responses) is always terminated by the
       first empty line after the header fields, regardless of the
       message-header fields present in the message.  (Note: An empty
       line is a line with nothing preceding the CRLF.)

   2.  If a Content-Length header(Section 16.16) is present, its value
       in bytes represents the length of the message-body.  If this
       header field is not present, a value of zero is assumed.

   Unlike an HTTP message, an RTSP message MUST contain a Content-Length
   header whenever it contains a message body.  Note that RTSP does not
   support the HTTP/1.1 "chunked" transfer coding (see [H3.6.1]).

      Given the moderate length of presentation descriptions returned,
      the server should always be able to determine its length, even if
      it is generated dynamically, making the chunked transfer encoding
      unnecessary.

6.  General Header Fields

   The general headers are listed in Table 1:

                +--------------------+--------------------+
                | 407 Header Name        | Proxy Authentication Required Defined in Section | all
                +--------------------+--------------------+
                | Cache-Control      | Section 16.10      |
                |                    |                    | 408
                | Request Timeout Connection         | all Section 16.11      |
                |                    |                    |
                | CSeq               | 410 Section 16.19      | Gone
                | all                    |                    |
                | Date               | Section 16.20      |
                | 411                    | Length Required                    | all
                | Media-Properties   | Section 16.28      |
                |                    |                    | 412
                | Precondition Failed Media-Range        | DESCRIBE, SETUP Section 16.29      |
                |                    |                    |
                | Pipelined-Requests | 413 Section 16.32      | Request Entity Too Large
                | all                    |                    |
                | Proxy-Supported    | Section 16.36      |
                | 414                    | Request-URI Too Long                    | all
                | Seek-Style         | Section 16.45      |
                |                    |                    | 415
                | Unsupported Media Type Supported          | all Section 16.49      |
                |                    |                    |
                | Timestamp          | 451 Section 16.51      | Parameter Not Understood
                | SET_PARAMETER                    |                    |
                | Via                | Section 16.56      |
                +--------------------+--------------------+

                 Table 1: The general headers used in RTSP

7.  Request

   A request message uses the format outlined below regardless of the
   direction of a request, client to server or server to client:

   o  Request line, containing the method to be applied to the resource,
      the identifier of the resource, and the protocol version in use;

   o  Zero or more Header lines, that can be of the following types:
      general (Section 6), request (Section 7.2), or message
      body(Section 9.1);

   o  One empty line (CRLF) to indicate the end of the header section;

   o  Optionally a message-body, consisting of one or more lines.  The
      length of the message body in bytes is indicated by the Content-
      Length message header.

7.1.  Request Line

   The request line provides the key information about the request: what
   method, on what resources and using which RTSP version.  The methods
   that are defined by this specification are listed in Table 2.

                  +---------------+--------------------+
                  | 452 Method        | reserved Defined in Section | n/a
                  +---------------+--------------------+
                  | DESCRIBE      | Section 13.2       |
                  |               |                    | 453
                  | Not Enough Bandwidth GET_PARAMETER | SETUP Section 13.8       |
                  |               |                    |
                  | OPTIONS       | 454 Section 13.1       | Session Not Found
                  | all               |                    |
                  | PAUSE         | Section 13.6       |
                  | 455               | Method Not Valid In This State                    | all
                  | PLAY          | Section 13.4       |
                  |               |                    | 456
                  | Header Field Not Valid PLAY_NOTIFY   | all Section 13.5       |
                  |               |                    |
                  | REDIRECT      | 457 Section 13.10      | Invalid Range
                  | PLAY, PAUSE               |                    |
                  | SETUP         | Section 13.3       |
                  |               | 458                    | Parameter Is Read-Only
                  | SET_PARAMETER | Section 13.9       |
                  |               |                    |
                  | 459 TEARDOWN      | Aggregate Operation Not Allowed Section 13.7       | all
                  +---------------+--------------------+

                         Table 2: The RTSP Methods

   The syntax of the RTSP request line is the following:

      <Method> <Request-URI> <RTSP-Version> CRLF

   Note: This syntax cannot be freely changed in future versions of
   RTSP.  This line needs to remain parsable by older RTSP
   implementations since it indicates the RTSP version of the message.

   In contrast to HTTP/1.1 [RFC2616], RTSP requests identify the
   resource through an absolute RTSP URI (scheme, host, and port) (see
   Section 4.2) rather than just the absolute path.

      HTTP/1.1 requires servers to understand the absolute URI, but
      clients are supposed to use the Host request header.  This is
      purely needed for backward-compatibility with HTTP/1.0 servers, a
      consideration that does not apply to RTSP.

   An asterisk "*" can be used instead of an absolute URI in the
   Request-URI part to indicate that the request does not apply to a
   particular resource, but to the server or proxy itself, and is only
   allowed when the request method does not necessarily apply to a
   resource.

   For example:

      OPTIONS * RTSP/2.0

   An OPTIONS in this form will determine the capabilities of the server
   or the proxy that first receives the request.  If the capability of
   the specific server needs to be determined, without regard to the
   capability of an intervening proxy, the server should be addressed
   explicitly with an absolute URI that contains the server's address.

   For example:

      OPTIONS rtsp://example.com RTSP/2.0

7.2.  Request Header Fields

   The RTSP headers in Table 3 can be included in a request, as request
   headers, to modify the specifics of the request.  Some of these
   headers may also be used in the response to a request, as response
   headers, to modify the specifics of a response (Section 8.2).

                +--------------------+--------------------+
                | Header             | Defined in Section |
                +--------------------+--------------------+
                | Accept             | Section 16.1       | 460
                | Only Aggregate Operation Allowed                    | all                    |
                | Accept-Credentials | Section 16.2       |
                |                    | 461                    | Unsupported Transport
                | all Accept-Encoding    | Section 16.3       |
                |                    |                    |
                | 462 Accept-Language    | Destination Unreachable Section 16.4       | all
                |                    |                    |
                | Authorization      | Section 16.7       | 463
                | Destination Prohibited                    | SETUP                    |
                | Bandwidth          | Section 16.8       |
                |                    | 464                    | Data Transport Not Ready Yet
                | PLAY Blocksize          | Section 16.9       |
                |                    |                    |
                | 465 From               | Section 16.22      | Notification Reason Unknown
                | PLAY_NOTIFY                    |                    |
                | If-Match           | Section 16.23      |
                | 470                    | Connection Authorization Required                    | all
                | If-Modified-Since  | Section 16.24      |
                |                    |                    | 471
                | Connection Credentials not accepted If-None-Match      | all Section 16.25      |
                |                    |                    |
                | Notify-Reason      | 472 Section 16.31      | Failure to establish secure connection
                | all                    |                    |
                | Proxy-Require      | Section 16.35      |
                |                    |                    |
                | Range              | Section 16.38      | 500
                | Internal Server Error                    | all                    |
                | Terminate-Reason   | Section 16.50      |
                |                    | 501                    | Not Implemented
                | all Referer            | Section 16.39      |
                |                    |                    |
                | 502 Request-Status     | Bad Gateway Section 16.41      | all
                |                    |                    |
                | Require            | Section 16.42      | 503
                | Service Unavailable                    | all                    |
                | Scale              | Section 16.44      |
                |                    | 504                    | Gateway Timeout
                | all Session            | Section 16.48      |
                |                    |                    |
                | 505 Speed              | Section 16.46      |
                |                    |                    |
                | RTSP Version Not Supported          | all Section 16.49      |
                |                    |                    |
                | Transport          | 551 Section 16.52      | Option not support
                | all                    |
    +------+----------------------------------------+-----------------+                    |
                | User-Agent         | Section 16.54      |
                +--------------------+--------------------+

                     Table 4: Status codes and their usage with RTSP methods

8.2.  Response Header Fields 3: The response-header fields allow the RTSP request recipient to pass
   additional information about the response which cannot be placed headers

   Detailed headers definition are provided in
   the Status-Line.  These header fields give information about the
   server and about further access to the resource identified by the
   Request-URI.  All headers currently classified as response headers
   are listed in Table 5.

              +------------------------+--------------------+
              | Header                 | Defined in Section |
              +------------------------+--------------------+
              | Accept-Credentials     | Section 16.2       |
              |                        |                    |
              | Accept-Ranges          | Section 16.5       |
              |                        |                    |
              | Connection-Credentials | Section 16.12      |
              |                        |                    |
              | ETag                   | Section 16.21      |
              |                        |                    |
              | Location               | Section 16.28      |
              |                        |                    |
              | Proxy-Authenticate     | Section 16.33      |
              |                        |                    |
              | Public                 | Section 16.37      |
              |                        |                    |
              | Range                  | Section 16.38      |
              |                        |                    |
              | Retry-After            | Section 16.40      |
              |                        |                    |
              | RTP-Info               | Section 16.43      |
              |                        |                    |
              | Scale                  | Section 16.44      |
              |                        |                    |
              | Session                | Section 16.48      |
              |                        |                    |
              | Server                 | Section 16.47      |
              |                        |                    |
              | Speed                  | Section 16.46      |
              |                        |                    |
              | Transport              | Section 16.51      |
              |                        |                    |
              | Unsupported            | Section 16.52      |
              |                        |                    |
              | Vary                   | Section 16.54      |
              |                        |                    |
              | WWW-Authenticate       | Section 16.56      |
              +------------------------+--------------------+

                    Table 5: The RTSP response 16.

   New request headers

   Response-header field names can may be extended reliably only in
   combination with a change in the protocol version.  However defined.  If the usage receiver of feature-tags in the request allows the responding party
   is required to learn
   the capability of understand the receiver of request header, the response.  New request MUST
   include a corresponding feature tag in a Require or experimental Proxy-Require
   header fields MAY be given to ensure the semantics processing of response-header fields if
   all parties in the communication recognize them to be response-header
   fields.  Unrecognized header fields in responses are treated as
   entity-header fields.

9.  Entity

   Request and header.

8.  Response messages MAY transfer an entity if not otherwise
   restricted by the

   After receiving and interpreting a request method or message, the recipient
   responds with an RTSP response status code.  An entity
   consists of entity-header fields message.  The final response is
   exactly one message, and an entity-body, although some final responses will only include are any using the entity-headers.

   The SET_PARAMETER and GET_PARAMETER request and response, and
   DESCRIBE response MAY have an entity.  All
   code classes from the list; 2xx, 3xx, 4xx and 5xx classes.  Only for
   responses MAY
   also have an entity.

   In this section, both sender and recipient refer to either using the client response code class 1xx, is it allowed to send
   one or more 1xx response messages prior to the server, depending on who sends final response
   message.

   The valid response codes and who receives the entity.

9.1.  Entity Header Fields

   Entity-header fields define meta-information about the entity-body
   or, if no body is present, about the resource identified by the
   request.  The entity header fields methods they can be used with are
   listed in Table 6.

                 +------------------+--------------------+
                 | Header           | Defined 4.

8.1.  Status-Line

   The first line of a Response message is the Status-Line, consisting
   of the protocol version followed by a numeric status code and the
   textual phrase associated with the status code, with each element
   separated by SP characters.  No CR or LF is allowed except in the
   final CRLF sequence.

   <RTSP-Version> SP <Status-Code> SP <Reason-Phrase> CRLF

8.1.1.  Status Code and Reason Phrase

   The Status-Code element is a 3-digit integer result code of the
   attempt to understand and satisfy the request.  These codes are fully
   defined in Section 15.  The Reason-Phrase is intended to give a short
   textual description of the Status-Code.  The Status-Code is intended
   for use by automata and the Reason-Phrase is intended for the human
   user.  The client is not required to examine or display the Reason-
   Phrase.

   The first digit of the Status-Code defines the class of response.
   The last two digits do not have any categorization role.  There are 5
   values for the first digit:

   1xx:  Informational - Request received, continuing process

   2xx:  Success - The action was successfully received, understood, and
         accepted

   3rr:  Redirection - Further action needs to be taken in order to
         complete the request
   4xx:  Client Error - The request contains bad syntax or cannot be
         fulfilled

   5xx:  Server Error - The server failed to fulfill an apparently valid
         request

   The individual values of the numeric status codes defined for
   RTSP/2.0, and an example set of corresponding Reason-Phrases, are
   presented in Table 4.  The reason phrases listed here are only
   recommended; they may be replaced by local equivalents without
   affecting the protocol.  Note that RTSP adopts most HTTP/1.1
   [RFC2616] status codes and adds RTSP-specific status codes starting
   at x50 to avoid conflicts with newly defined HTTP status codes.

   RTSP status codes are extensible.  RTSP applications are not required
   to understand the meaning of all registered status codes, though such
   understanding is obviously desirable.  However, applications MUST
   understand the class of any status code, as indicated by the first
   digit, and treat any unrecognized response as being equivalent to the
   x00 status code of that class, with the exception that an
   unrecognized response MUST NOT be cached.  For example, if an
   unrecognized status code of 431 is received by the client, it can
   safely assume that there was something wrong with its request and
   treat the response as if it had received a 400 status code.  In such
   cases, user agents SHOULD present to the user the message body
   returned with the response, since that message body is likely to
   include human-readable information which will explain the unusual
   status.

    +------+----------------------------------------+-----------------+
    |
                 +------------------+--------------------+
                 | Allow            | Section 16.6       |
                 |                  |                    |
                 | Content-Base     | Section 16.13      | Code | Reason                                 | Method          |
    +------+----------------------------------------+-----------------+
    | Content-Encoding 100  | Section 16.14 Continue                               | all             |
    |      |                                        | Content-Language                 | Section 16.15
    |      |                                        |                 |
    | Content-Length 200  | Section 16.16 OK                                     | all             |
    |      |                                        | Content-Location                 | Section 16.17
    |      |                                        |                 |
    | Content-Type 301  | Section 16.18 Moved Permanently                      | all             |
    |      |                                        | Expires                 | Section 16.22
    | 302  | Found                                  | all             |
    | Last-Modified      | Section 16.27                                        |
                 +------------------+--------------------+

                     Table 6: The RTSP entity headers

   The extension-header mechanism allows additional entity-header fields
   to be defined without changing the protocol, but these fields cannot
   be assumed to be recognizable by the recipient.  Unrecognized header
   fields SHOULD be ignored by the recipient and forwarded by proxies.

9.2.  Entity Body

   See [H7.2] with the addition that an RTSP message with an entity body
   MUST include the Content-Type and Content-Length headers.

10.  Connections

   RTSP requests can be transmitted using the two different connection
   scenarios listed below:

   o  persistent - a transport connection is used for several request/
      response transactions;

   o  transient - a transport connection is used for a single request/
      response transaction.

   RFC 2326 attempted to specify an optional mechanism for transmitting
   RTSP messages in connectionless mode over a transport protocol such
   as UDP.  However, it was not specified in sufficient detail to allow
   for interoperable implementations.                 |
    | 304  | Not Modified                           | all             |
    |      |                                        |                 |
    | 305  | Use Proxy                              | all             |
    |      |                                        |                 |
    |      |                                        |                 |
    | 400  | Bad Request                            | all             |
    | 401  | Unauthorized                           | all             |
    |      |                                        |                 |
    | 402  | Payment Required                       | all             |
    |      |                                        |                 |
    | 403  | Forbidden                              | all             |
    |      |                                        |                 |
    | 404  | Not Found                              | all             |
    |      |                                        |                 |
    | 405  | Method Not Allowed                     | all             |
    |      |                                        |                 |
    | 406  | Not Acceptable                         | all             |
    |      |                                        |                 |
    | 407  | Proxy Authentication Required          | all             |
    |      |                                        |                 |
    | 408  | Request Timeout                        | all             |
    |      |                                        |                 |
    | 410  | Gone                                   | all             |
    |      |                                        |                 |
    | 411  | Length Required                        | all             |
    |      |                                        |                 |
    | 412  | Precondition Failed                    | DESCRIBE, SETUP |
    |      |                                        |                 |
    | 413  | Request Message Body Too Large         | all             |
    |      |                                        |                 |
    | 414  | Request-URI Too Long                   | all             |
    |      |                                        |                 |
    | 415  | Unsupported Media Type                 | all             |
    |      |                                        |                 |
    | 451  | Parameter Not Understood               | SET_PARAMETER   |
    |      |                                        |                 |
    | 452  | reserved                               | n/a             |
    |      |                                        |                 |
    | 453  | Not Enough Bandwidth                   | SETUP           |
    |      |                                        |                 |
    | 454  | Session Not Found                      | all             |
    |      |                                        |                 |
    | 455  | Method Not Valid In an attempt to reduce
   complexity and scope, and due to lack of interest, RTSP 2.0 does This State         | all             |
    |      |                                        |                 |
    | 456  | Header Field Not Valid                 | all             |
    |      |                                        |                 |
    | 457  | Invalid Range                          | PLAY, PAUSE     |
    |      |                                        |                 |
    | 458  | Parameter Is Read-Only                 | SET_PARAMETER   |
    |      |                                        |                 |
    | 459  | Aggregate Operation Not Allowed        | all             |
    |      |                                        |                 |
    | 460  | Only Aggregate Operation Allowed       | all             |
    |      |                                        |                 |
    | 461  | Unsupported Transport                  | all             |
    |      |                                        |                 |
    | 462  | Destination Unreachable                | all             |
    |      |                                        |                 |
    | 463  | Destination Prohibited                 | SETUP           |
    |      |                                        |                 |
    | 464  | Data Transport Not Ready Yet           | PLAY            |
    |      |                                        |                 |
    | 465  | Notification Reason Unknown            | PLAY_NOTIFY     |
    |      |                                        |                 |
    | 470  | Connection Authorization Required      | all             |
    |      |                                        |                 |
    | 471  | Connection Credentials not
   attempt accepted    | all             |
    |      |                                        |                 |
    | 472  | Failure to define a mechanism for supporting RTSP over UDP or other
   connectionless transport protocols.  A side-effect of this is that
   RTSP requests SHALL NOT be sent to multicast groups since no establish secure connection can be established | all             |
    |      |                                        |                 |
    |      |                                        |                 |
    | 500  | Internal Server Error                  | all             |
    |      |                                        |                 |
    | 501  | Not Implemented                        | all             |
    |      |                                        |                 |
    | 502  | Bad Gateway                            | all             |
    |      |                                        |                 |
    | 503  | Service Unavailable                    | all             |
    |      |                                        |                 |
    | 504  | Gateway Timeout                        | all             |
    |      |                                        |                 |
    | 505  | RTSP Version Not Supported             | all             |
    |      |                                        |                 |
    | 551  | Option not support                     | all             |
    +------+----------------------------------------+-----------------+

          Table 4: Status codes and their usage with a specific receiver in multicast
   environments.

   Certain RTSP headers, such as methods

8.2.  Response Headers

   The response-header allow the CSeq header (Section 16.19), which
   may appear to be relevant only request recipient to connectionless transport scenarios
   are still retained and must pass additional
   information about the response which cannot be implemented according to placed in the
   specification.  In Status-
   Line.  This header give information about the case of CSeq, it is quite useful for matching
   responses server and about
   further access to requests if the requests resource identified by the Request-URI.  All
   headers currently classified as response headers are pipelined (see Section 12).
   It is also useful listed in proxies for keeping track of the different
   requests when aggregating several client requests on a single TCP
   connection.

10.1.  Reliability and Acknowledgements

   When
   Table 5.

              +------------------------+--------------------+
              | Header                 | Defined in Section |
              +------------------------+--------------------+
              | Accept-Credentials     | Section 16.2       |
              |                        |                    |
              | Accept-Ranges          | Section 16.5       |
              |                        |                    |
              | Connection-Credentials | Section 16.12      |
              |                        |                    |
              | MTag                   | Section 16.30      |
              |                        |                    |
              | Location               | Section 16.27      |
              |                        |                    |
              | Proxy-Authenticate     | Section 16.33      |
              |                        |                    |
              | Public                 | Section 16.37      |
              |                        |                    |
              | Range                  | Section 16.38      |
              |                        |                    |
              | Retry-After            | Section 16.40      |
              |                        |                    |
              | RTP-Info               | Section 16.43      |
              |                        |                    |
              | Scale                  | Section 16.44      |
              |                        |                    |
              | Session                | Section 16.48      |
              |                        |                    |
              | Server                 | Section 16.47      |
              |                        |                    |
              | Speed                  | Section 16.46      |
              |                        |                    |
              | Transport              | Section 16.52      |
              |                        |                    |
              | Unsupported            | Section 16.53      |
              |                        |                    |
              | Vary                   | Section 16.55      |
              |                        |                    |
              | WWW-Authenticate       | Section 16.57      |
              +------------------------+--------------------+

                    Table 5: The RTSP messages are transmitted using reliable transport
   protocols, they MUST NOT response headers

   Response-headers names can be retransmitted at extended reliably only in combination
   with a change in the RTSP protocol level.
   Instead, the implementation must rely on version.  However the underlying transport to
   provide reliability.  The RTSP implementation may use any indication
   of reception acknowledgement usage of feature-
   tags in the message from request allows the underlying
   transport protocols responding party to optimize learn the RTSP behavior.

      If both
   capability of the underlying reliable transport such as TCP and receiver of the RTSP
      application retransmit requests, each packet loss or message loss
      may result in two retransmissions.  The receiver typically cannot
      take advantage of the application-layer retransmission since the
      transport stack will not deliver the application-layer
      retransmission before the first attempt has reached the receiver.
      If the packet loss is caused by congestion, multiple
      retransmissions at different layers will exacerbate the
      congestion.

   Lack of acknowledgement of an RTSP request should response.  New or experimental
   header MAY be handled within given the constraints semantics of response-header if all parties
   in the connection timeout considerations described
   below (Section 10.4).

10.2.  Using Connections

   A TCP transport can communication recognize them to be used for both persistent connections (for
   several message exchanges) response-header.

   Unrecognized headers in responses are treated as message-headers.

9.  Message Body

   Request and transient connections (for Response messages MAY transfer a single message exchange).  Implementations of this specification MUST
   support RTSP over TCP.  The scheme of the RTSP URI (Section 4.2)
   indicates the default port that body if not
   otherwise restricted by the server request method or response status code.
   An message body consists of message-header fields and an message-
   body, although some responses will listen on.

   A server MUST handle both persistent only include the message-headers.

   The SET_PARAMETER and transient connections.

      Transient connections facilitate mechanisms for fault tolerance.
      They also allow for application layer mobility.  A server GET_PARAMETER request and
      client pair that support transient connections can survive the
      loss of a TCP connection; e.g., due to a NAT timeout.  When the
      client has discovered that the TCP connection has been lost, it
      can set up a new one when there is need to communicate again.

   A persistent connection MAY be used for all transactions between the
   server response, and client, including messages for multiple RTSP sessions.
   However a persistent connection
   DESCRIBE response MAY also be closed after a few have an message exchanges.  For example, a client may use a persistent
   connection for the initial SETUP body.  All 4xx and PLAY 5xx
   responses MAY also have an message exchanges in a
   session body.

   In this section, both sender and then close the connection.  Later, when the client wishes recipient refer to send a new request, such as a PAUSE for the session, a new
   connection would be opened.  This connection may either be transient
   or persistent.

   An RTSP agent SHOULD NOT have more than one connection to the server
   at any given point.  If a client
   or proxy handles multiple RTSP
   sessions on the same server, it SHOULD use only one connection for
   managing those sessions.

      This saves connection resources depending on the server.  It also reduces
      complexity by who sends and enabling who receives the server to maintain less state message
   body.

9.1.  Message Body Header Fields

   message-header fields define meta-information about
      its sessions and connections.

   Unlike HTTP, RTSP allows a server to send requests to a client.
   However, this can be supported only if a client establishes a
   persistent connection with the server.  In cases where a persistent
   connection does not exist between a server and its client, due to the
   lack of a signalling channel the server may be forced to drop an RTSP
   session without notifying the client.  An example of such a case message-body
   or, if no body is
   when present, about the server desires to send a REDIRECT request for an RTSP
   session resource identified by the
   request.  The message body header fields are listed in Table 6.

                 +------------------+--------------------+
                 | Header           | Defined in Section |
                 +------------------+--------------------+
                 | Allow            | Section 16.6       |
                 |                  |                    |
                 | Content-Base     | Section 16.13      |
                 |                  |                    |
                 | Content-Encoding | Section 16.14      |
                 |                  |                    |
                 | Content-Language | Section 16.15      |
                 |                  |                    |
                 | Content-Length   | Section 16.16      |
                 |                  |                    |
                 | Content-Location | Section 16.17      |
                 |                  |                    |
                 | Content-Type     | Section 16.18      |
                 |                  |                    |
                 | Expires          | Section 16.21      |
                 |                  |                    |
                 | Last-Modified    | Section 16.26      |
                 +------------------+--------------------+

                  Table 6: The RTSP message body headers

   The extension-header mechanism allows additional message-header
   fields to be defined without changing the client protocol, but is not able to do so because it these fields
   cannot
   reach be assumed to be recognizable by the client.

      Without a persistent connection between recipient.  Unrecognized
   header fields SHOULD be ignored by the client recipient and forwarded by
   proxies.

9.2.  Message Body

   RTSP message with an message body MUST include the Content-Type and
   Content-Length headers if a message body is included.

   When an message body is included with a message, the server, data type of
   that body is determined via the header fields Content-Type and
   Content- Encoding.

   Content-Type specifies the media server has no reliable way type of reaching the client.
      Also, this is underlying data.
   Content-Encoding may be used to indicate any additional content
   codings applied to the only way data, usually for the purpose of data
   compression, that requests from a server to its
      client are likely to traverse firewalls.

   In light a property of the above, it requested resource.  There is RECOMMENDED that clients use persistent
   connections whenever possible.  A client that supports persistent
   connections MAY "pipeline" its requests (see Section 12).

10.3.  Closing Connections

   The client MAY close a connection at any point when
   no outstanding
   request/response transactions exist for any RTSP session being
   managed through the connection. default encoding.

   The server, however, SHOULD NOT
   close Content-Length of a connection until all message is the length of the message-body.

10.  Connections

   RTSP sessions being managed through requests can be transmitted using the two different connection have been timed out (Section 16.48).  A server SHOULD NOT
   close
   scenarios listed below:

   o  persistent - a transport connection immediately after responding to is used for several request/
      response transactions;

   o  transient - a session-level
   TEARDOWN request transport connection is used for the last RTSP session being controlled through
   the connection.  Instead, it should wait a single request/
      response transaction.

   RFC 2326 attempted to specify an optional mechanism for transmitting
   RTSP messages in connectionless mode over a reasonable amount of
   time transport protocol such
   as UDP.  However, it was not specified in sufficient detail to allow
   for the client interoperable implementations.  In an attempt to receive the TEARDOWN response, take
   appropriate action, reduce
   complexity and initiate the connection closing.  The server
   SHOULD wait at least 10 seconds after sending the TEARDOWN response
   before closing the connection.

      This is scope, and due to ensure that the client has time lack of interest, RTSP 2.0 does not
   attempt to issue define a SETUP mechanism for a
      new session on the existing connection after having torn the last
      one down. 10 seconds should give the client ample opportunity get
      its message to the server. supporting RTSP over UDP or other
   connectionless transport protocols.  A server SHOULD NOT close the connection directly as a result side-effect of
   responding this is that
   RTSP requests MUST NOT be sent to a request multicast groups since no
   connection can be established with an error code. a specific receiver in multicast
   environments.

   Certain error responses RTSP headers, such as "460 Only Aggregate Operation
      Allowed" the CSeq header (Section 15.4.12) 16.19), which
   may appear to be relevant only to connectionless transport scenarios
   are used for negotiating capabilities
      of a server with respect still retained and must be implemented according to content or other factors. the
   specification.  In such
      cases, the case of CSeq, it is inefficient quite useful for the server matching
   responses to close a connection on
      an error response.  Also, such behavior would prevent
      implementation of advanced/special types of requests or result in
      extra overhead for if the client when testing requests are pipelined (see Section 12).
   It is also useful in proxies for new features.  On
      the flip side, keeping connections open after sending an error
      response poses a Denial track of Service security risk (Section 21).

   If a server closes a connection while the client is attempting to
   send a new request, the different
   requests when aggregating several client will have to close its current
   connection, establish requests on a new connection and send its request over the
   new single TCP
   connection.

   An

10.1.  Reliability and Acknowledgements

   When RTSP message should not be terminated by closing the connection.
   Such a message MAY be considered to messages are transmitted using reliable transport
   protocols, they MUST NOT be incomplete by retransmitted at the receiver and
   discarded.  An RTSP message is properly terminated as defined in
   Section 5.

10.4.  Timing Out Connections and protocol level.
   Instead, the implementation must rely on the underlying transport to
   provide reliability.  The RTSP Messages

   Receivers implementation may use any indication
   of a request (responder) SHOULD respond reception acknowledgement of the message from the underlying
   transport protocols to requests in a
   timely manner even when a optimize the RTSP behavior.

      If both the underlying reliable transport such as TCP is used.
   Similarly, and the sender RTSP
      application retransmit requests, each packet loss or message loss
      may result in two retransmissions.  The receiver typically cannot
      take advantage of a request (requestor) SHOULD wait for a
   sufficient time for a response before concluding that the responder application-layer retransmission since the
      transport stack will not be acting upon its request.

   A responder SHOULD respond to all requests within 5 seconds.  If deliver the
   responder recognizes that processing of a request will take longer
   than 5 seconds, it SHOULD send a 100 (Continue) response as soon as
   possible.  It SHOULD continue sending a 100 response every 5 seconds
   thereafter until it is ready to send application-layer
      retransmission before the final response to first attempt has reached the
   requestor.  After sending a 100 response, receiver.
      If the receiver MUST send a
   final response indicating packet loss is caused by congestion, multiple
      retransmissions at different layers will exacerbate the success or failure
      congestion.

   Lack of acknowledgement of an RTSP request should be handled within
   the request.

   A requestor SHOULD wait at least 10 seconds for a response before
   concluding that constraints of the responder will not connection timeout considerations described
   below (Section 10.4).

10.2.  Using Connections

   A TCP transport can be responding to its request.
   After receiving a 100 response, the requestor SHOULD continue waiting used for further responses.  If more than 10 seconds elapses without
   receiving any response, the requestor MAY assume that the responder
   is unresponsive both persistent connections (for
   several message exchanges) and abort the connection.

   A requestor SHOULD wait longer than 10 seconds for transient connections (for a response if it
   is experiencing significant transport delays on its connection to the
   responder. single
   message exchange).  Implementations of this specification MUST
   support RTSP over TCP.  The requestor is capable scheme of determining the RTT of RTSP URI (Section 4.2)
   indicates the
   request/response cycle using default port that the Timestamp header (Section 16.50) in
   any RTSP request.

10.5.  Showing Liveness

   The server will listen on.

   A server MUST handle both persistent and transient connections.

      Transient connections facilitate mechanisms for showing liveness fault tolerance.
      They also allow for application layer mobility.  A server and
      client pair that support transient connections can survive the
      loss of a TCP connection; e.g., due to a NAT timeout.  When the
      client is, any RTSP
   request with has discovered that the TCP connection has been lost, it
      can set up a Session header, if RTP & RTCP new one when there is need to communicate again.

   A persistent connection is RECOMMENDED be used an RTCP message,
   or through any other used media protocol capable of indicating
   liveness of for all transactions
   between the server and client, including messages for multiple RTSP client.  It is RECOMMENDED that
   sessions.  However a persistent connection MAY be closed after a few
   message exchanges.  For example, a client does
   not wait to may use a persistent
   connection for the last second of initial SETUP and PLAY message exchanges in a
   session and then close the timeout before trying connection.  Later, when the client wishes
   to send a
   liveness message.  The RTSP message may be lost or when using
   reliable protocols, new request, such as TCP, a PAUSE for the message session, a new
   connection would be opened.  This connection may take some time to
   arrive safely at the receiver.  To show liveness between RTSP request
   issued to accomplish other things, the following mechanisms can either be
   used, in descending order of preference:

   RTCP: If RTP is used for media transport RTCP transient
   or persistent.

   An RTSP agent SHOULD be used.  If
         RTCP is used NOT have more than one connection to report transport statistics, it SHALL also work
         as keep alive.  The server can determine the client by used
         network address and port together with the fact that the server
   at any given point.  If a client
         is reporting or proxy handles multiple RTSP
   sessions on the servers SSRC(s).  A downside of using RTCP
         is that same server, it SHOULD use only gives statistical guarantees to reach one connection for
   managing those sessions.

      This saves connection resources on the server.  However that probability is so low that it can be
         ignored in most cases.  For example, a session with 60 seconds
         timeout  It also reduces
      complexity by and enough bitrate assigned enabling the server to RTCP messages maintain less state about
      its sessions and connections.

   RTSP allows a server to send a
         message from client requests to server on average every 5 seconds.  That a client.  However, this can
   be supported only if a client have for establishes a network persistent connection
   with 5 % packet loss, the probability server.  In cases where a persistent connection does not
   exist between a server and its client, due to fail showing liveness sign in that session within the
         timeout interval of 2.4*E-16.  In sessions with shorter timeout
         times, or much higher packet loss, or small RTCP bandwidths
         SHOULD also use any lack of a
   signalling channel the mechanisms below.

   SET_PARAMETER:  When using SET_PARAMETER for keep alive, no body
         SHOULD server may be included.  This method forced to silently discard RTSP
   messages, and may even drop an RTSP session without notifying the
   client.  An example of such a case is when the RECOMMENDED RTSP method server desires to use in send
   a REDIRECT request only intended for an RTSP session to perform keep-alive.

   OPTIONS:  This method does also work.  However the client but is not able
   to do so because it causes cannot reach the client.  A server that attempt
   to send a request to a client that has no connection currently to perform more unnecessary processing and result in bigger
         responses than necessary for the task.  The reason
   server SHOULD discard the request directly, it MAY queue it for this is
         that later
   delivery.  However, if the server needs queue the request it should when
   adding additional requests to determine what capabilities the queue ensure to remove older
   requests that are
         associated with now redundant.

      Without a persistent connection between the client and the server,
      the media resource server has no reliable way of reaching the client.
      Because the likely failure of server to correctly populate client established
      connections the
         Public and Allow headers. server will not even attempt establishing any
      connection.

   The timeout parameter MAY be included in a SETUP response, client and SHALL
   NOT be included in requests.  The server uses it to indicate to the sending requests can be asynchronous events.
   To avoid deadlock situations both client how long the and server is prepared MUST be able to wait between
   send and receive requests simultaneously.  As an RTSP commands response may be
   queue up for transmission, reception or other signs of life before closing processing behind the session due peer
   RTSP agent's own requests, all RTSP agents are required to lack have a
   certain capability of
   activity (see below and Appendix B). handling outstanding messages.  The issue is
   that outstanding requests may timeout despite them being processed by
   the peer due to the response is measured caught in
   seconds, with a default of 60 seconds.  The length of the session
   timeout SHALL NOT be changed in queue behind a established session.

10.6.  Use of IPv6

   Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326).  RTSP
   2.0 has been updated for explicit IPv6 support.  Implementations number
   of
   RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers.

11.  Capability Handling

   This section describes request that the available capability handling mechanism
   which allows RTSP agent is processing but that take some time
   to be extended.  Extensions to complete.  To avoid this version of the
   protocol are basically done in two ways.  First, new headers problem an RTSP agent is recommended to
   buffer incoming messages locally so that any response messages can be
   added.  Secondly, new methods
   processed immediately upon reception.  If responses are separated
   from requests and directly forwarded for processing can not only the
   result be added.  The capability handling
   mechanism is designed to handle both cases.

   When a method is added, used immediately, the involved parties can use the OPTIONS
   method to discover wether it is supported.  This is done by issuing a
   OPTIONS state associated with that
   outstanding request to the other party.  Depending can also be released.  However, buffering a
   number of requests on the URI it will
   either apply in regards to receiving RTSP agent consumes resources and
   enables a certain media resource, resource exhaustion attack on the whole server
   in general, agent.  Therefore this
   buffer should be limited so that an unreasonable number of requests
   or simply the next hop.  The OPTIONS response MUST
   contain a Public header which declares all methods supported for the
   indicated resource.

   It total message size is not necessary to use OPTIONS allowed to discover support of a method,
   the client could simply try the method.  If consume the receiver of receiving agents
   resources.  In most APIs having the
   request does not support receiving agent stop reading from
   the method it TCP socket will respond with an error
   code indicating result in TCP's window being clamped.  Thus
   forcing the buffering on the method is either not implemented (501) or
   does not apply for sending agent when the resource (405).  The choice between load is larger
   than expected.  However, as both RTSP message sizes and frequency may
   be changed in the two
   discovery methods depends future by protocol extension an agent should be
   careful against taking harsher measurements against a potential
   attack.  When under attack an RTSP agent can close TCP connections
   and release state associated with that TCP connection.

   To provide some guidance on what is reasonable the requirements of the service.

   Feature-Tags following
   guidelines are defined given.  An RTSP agent should not have more than 10
   outstanding requests per RTSP session.  An RTSP agent should not have
   more than 10 outstanding requests that aren't related to handle functionality additions an RTSP
   session or that are
   not new methods.  Each feature-tag represents a certain block of
   functionality.  The amount requesting to create an RTSP session.

   In light of functionality the above, it is RECOMMENDED that a feature-tag
   represents can vary significantly. clients use persistent
   connections whenever possible.  A feature-tag can client that supports persistent
   connections MAY "pipeline" its requests (see Section 12).

10.3.  Closing Connections

   The client MAY close a connection at any point when no outstanding
   request/response transactions exist for example
   represent any RTSP session being
   managed through the functionality connection.  The server, however, SHOULD NOT
   close a single connection until all RTSP header provides.  Another
   feature-tag can represent much more functionality, such as the
   "play.basic" feature-tag which represents the minimal playback
   implementation.

   Feature-tags are used to determine wether sessions being managed through the client,
   connection have been timed out (Section 16.48).  A server or proxy
   supports the functionality that is necessary to achieve the desired
   service.  To determine support of SHOULD NOT
   close a feature-tag, several different
   headers can be used, each explained below:

   Supported:  The supported header is used connection immediately after responding to determine a session-level
   TEARDOWN request for the complete
         set last RTSP session being controlled through
   the connection.  Instead, it should wait for a reasonable amount of functionality that both
   time for the client to receive the TEARDOWN response, take
   appropriate action, and server have. initiate the connection closing.  The
         intended usage server
   SHOULD wait at least 10 seconds after sending the TEARDOWN response
   before closing the connection.

      This is to determine before one needs ensure that the client has time to use issue a
         functionality that it is supported.  It can be used in any
         method, however OPTIONS is the most suitable one as it at the
         same time determines all methods that are implemented.  When
         sending SETUP for a request
      new session on the requestor declares all its capabilities
         by including all supported feature-tags.  This results in that existing connection after having torn the receiver learns last
      one down. 10 seconds should give the requestors feature support.  The
         receiver then includes client ample opportunity get
      its set of features in the response.

   Proxy-Supported:  The Proxy-Supported header is used similar message to the
         Supported header, but instead of giving the supported
         functionality of the client or server.

   A server it provides both the
         requestor and SHOULD NOT close the responder connection directly as a view result of what functionality the
         proxy chain between the two supports.  Proxies are required
   responding to
         add this header whenever the Supported header is present, but
         proxies may independently of the requestor add it.

   Require:  The Require header can be included in any a request where the
         end-point, i.e. the client with an error code.

      Certain error responses such as "460 Only Aggregate Operation
      Allowed" (Section 15.4.25) are used for negotiating capabilities
      of a server with respect to content or server, other factors.  In such
      cases, it is required to understand
         the feature to correctly perform the request.  This can, inefficient for
         example, be a SETUP request where the server is required to
         understand close a certain parameter to be able to set up the media
         delivery correctly.  Ignoring this parameter connection on
      an error response.  Also, such behavior would not have prevent
      implementation of advanced/special types of requests or result in
      extra overhead for the
         desired effect and is not acceptable.  Therefore client when testing for new features.  On
      the end-point
         receiving flip side, keeping connections open after sending an error
      response poses a request containing Denial of Service security risk (Section 21).

   If a Require MUST negatively
         acknowledge any feature that it does not understand and not
         perform the request.  The response in cases where features are
         not supported are 551 (Option Not Supported).  Also the
         features that are not supported are given in the Unsupported
         header in server closes a connection while the response.

   Proxy-Require:  This method has client is attempting to
   send a new request, the same purpose and workings as
         Require except that it only applies client will have to proxies close its current
   connection, establish a new connection and not send its request over the end-
         point.  Features that needs to
   new connection.

   An RTSP message should not be supported terminated by both proxies and
         end-point needs closing the connection.
   Such a message MAY be considered to be included in both incomplete by the Require receiver and Proxy-
         Require header.

   Unsupported:  This header
   discarded.  An RTSP message is used properly terminated as defined in
   Section 5.

10.4.  Timing Out Connections and RTSP Messages

   Receivers of a 551 error response, request (responder) SHOULD respond to
         indicate which feature(s) that was not supported.  Such requests in a
         response
   timely manner even when a reliable transport such as TCP is only the result of used.
   Similarly, the usage sender of a request (requester) SHOULD wait for a
   sufficient time for a response before concluding that the Require and/or
         Proxy-Require header where one or more feature where responder
   will not
         supported.  This information allows the requestor be acting upon its request.

   A responder SHOULD respond to make all requests within 5 seconds.  If the
         best
   responder recognizes that processing of situations a request will take longer
   than 5 seconds, it SHOULD send a 100 (Continue) response as soon as
   possible.  It SHOULD continue sending a 100 response every 5 seconds
   thereafter until it knows which features are not
         supported.

12.  Pipelining Support

   Pipelining is a general method ready to improve performance send the final response to the
   requester.  After sending a 100 response, the receiver MUST send a
   final response indicating the success or failure of request the request.

   A requester SHOULD wait at least 10 seconds for a response protocols by allowing before
   concluding that the requesting entity responder will not be responding to have its request.
   After receiving a 100 response, the requester SHOULD continue waiting
   for further responses.  If more than one request outstanding 10 seconds elapses without
   receiving any response, the requester MAY assume that the responder
   is unresponsive and send them over abort the same persistent connection.  For RTSP where the relative order of requests will
   matter

   A requester SHOULD wait longer than 10 seconds for a response if it
   is important experiencing significant transport delays on its connection to maintain the order
   responder.  The requester is capable of determining the requests.
   Because RTT of this the the responding entity SHALL process
   request/response cycle using the incoming
   requests Timestamp header (Section 16.51) in their sending order.  The sending order can be determined
   by
   any RTSP request.

      10 seconds was chosen for the CSeq header and its sequence number.  For following reasons.  It gives TCP
      time to perform a couple of retransmissions, even if operating on
      default values.  It is short enough that users may not abandon the delivery
   order will
      process themselves.  However, it should be the same as the sending order.  The processing noted that 10 seconds
      can be aggressive on certain type of networks.  The 5 seconds
      value for 1xx messages is half the
   request SHALL also have been finished timeout giving a reasonable
      change of successful delivery before processing the next
   request from timeout happens on the same entity.
      requestor side.

10.5.  Showing Liveness

   The responses MUST be sent in the
   order the requests was processed.

   RTSP 2.0 has extended support mechanisms for pipelining compared to showing liveness of the client is, any RTSP 1.0.
   The major improvement
   request with a Session header, if RTP & RTCP is to allow all requests to setup and initiate used an RTCP message,
   or through any other used media playback to be pipelined after each other.  This is
   accomplished by the utilization protocol capable of indicating
   liveness of the Pipelined-Requests header (see
   Section 16.32).  This header allows RTSP client.  It is RECOMMENDED that a client does
   not wait to request that two or
   more requests is the last second of the timeout before trying to send a
   liveness message.  The RTSP message may be processed in lost or when using
   reliable protocols, such as TCP, the same RTSP session context
   which message may take some time to
   arrive safely at the first receiver.  To show liveness between RTSP request creates.  In
   issued to accomplish other words a client things, the following mechanisms can request
   that two or more be
   used, in descending order of preference:

   RTCP: If RTP is used for media streams are set-up and then played without
   needing transport RTCP SHOULD be used.  If
         RTCP is used to wait for a single response.  This speeds up report transport statistics, it MUST also work
         as keep alive.  The server can determine the initial
   startup time for an RTSP session client by used
         network address and port together with at least one RTT.

   If a pipelined request builds the fact that the client
         is reporting on the succesful completion servers SSRC(s).  A downside of one or
   more prior requests using RTCP
         is that it only gives statistical guarantees to reach the requestor must verify
         server.  However that all requests were
   executed as expected.  A common example will probability is so low that it can be two SETUP requests
         ignored in most cases.  For example, a session with 60 seconds
         timeout and enough bitrate assigned to RTCP messages to send a PLAY request.  In case one of the SETUP fails unexpectedly, the
   PLAY request can still be succesfully executed.  However, not as
   expected by the requesting
         message from client as only to server on average every 5 seconds.  That
         client have for a single media instead network with 5 % packet loss, the probability
         to fail showing liveness sign in that session within the
         timeout interval of
   two will be played. 2.4*E-16.  In this case sessions with shorter timeout
         times, or much higher packet loss, or small RTCP bandwidths
         SHOULD also use any of the client can send a PAUSE
   request, correct mechanisms below.

   SET_PARAMETER:  When using SET_PARAMETER for keep alive, no body
         SHOULD be included.  This method is the failing SETUP request and then RECOMMENDED RTSP method
         to use in request only intended to perform keep-alive.

   OPTIONS:  This method is also usable, but it causes the server to be
   played.

13.  Method Definitions
         perform more unnecessary processing and result in bigger
         responses than necessary for the task.  The method indicates what reason is that the
         server needs to be performed on determine the capabilities associated with the
         media resource
   identified by to correctly populate the Request-URI. Public and Allow
         headers.

   The method name is case-sensitive.
   New methods may timeout parameter MAY be defined included in the future.  Method names SHALL NOT
   start with a $ character (decimal 24) SETUP response, and MUST
   NOT be included in requests.  The server uses it to indicate to the
   client how long the server is prepared to wait between RTSP commands
   or other signs of life before closing the session due to lack of
   activity (see below and Appendix B).  The timeout is measured in
   seconds, with a token as defined
   by default of 60 seconds.  The length of the ABNF [RFC5234] session
   timeout MUST NOT be changed in a established session.

10.6.  Use of IPv6

   Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326).  RTSP
   2.0 has been updated for explicit IPv6 support.  Implementations of
   RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers.

11.  Capability Handling

   This section describes the syntax chapter Section 20.  The methods available capability handling mechanism
   which allows RTSP to be extended.  Extensions to this version of the
   protocol are summarized basically done in Table 7.

   +---------------+-----------+--------+--------------+---------------+
   | two ways.  First, new headers can be
   added.  Secondly, new methods can be added.  The capability handling
   mechanism is designed to handle both cases.

   When a method        | direction | object | Server req.  | Client req.   |
   +---------------+-----------+--------+--------------+---------------+
   | DESCRIBE      | C -> S    | P,S    | recommended  | recommended   |
   |               |           |        |              |               |
   | GET_PARAMETER | C -> S    | P,S    | optional     | optional      |
   |               |           |        |              |               |
   |               | S -> C    |        |              |               |
   |               |           |        |              |               |
   | OPTIONS       | C -> S    | P,S    | R=Req,       | Sd=Req, R=Opt |
   |               |           |        | Sd=Opt       |               |
   |               |           |        |              |               |
   |               | S -> C    |        |              |               |
   |               |           |        |              |               |
   | PAUSE         | C -> S    | P,S    | required     | required      |
   |               |           |        |              |               |
   | PLAY          | C -> S    | P,S    | required     | required      |
   |               |           |        |              |               |
   | PLAY_NOTIFY   | S -> C    | P,S    | required     | required      |
   |               |           |        |              |               |
   | REDIRECT      | S -> C    | P,S    | optional     | required      |
   |               |           |        |              |               |
   | SETUP         | C -> S    | S      | required     | required      |
   |               |           |        |              |               |
   | SET_PARAMETER | C -> S    | P,S    | required     | optional      |
   |               |           |        |              |               |
   |               | S -> C    |        |              |               |
   |               |           |        |              |               |
   | TEARDOWN      | C -> S    | P,S    | required     | required      |
   +---------------+-----------+--------+--------------+---------------+

   Table 7: Overview of RTSP methods, their direction, and what objects
     (P: presentation, S: stream) they operate on. Legend: R=Respond,
                   Sd=Send, Opt: Optional, Req: Required
      Note on Table 7: GET_PARAMETER is recommended, but not required.
      For example, a fully functional server added, the involved parties can be built use the OPTIONS
   method to deliver
      media without any parameters.  SET_PARAMETER discover whether it is required however
      due to its usage for keep-alive.  PAUSE supported.  This is now required due done by issuing
   a OPTIONS request to
      that it is the only way of getting out of other party.  Depending on the state machines play
      state without terminating URI it will
   either apply in regards to a certain media resource, the whole session.

   If an RTSP agent does server
   in general, or simply the next hop.  The OPTIONS response MUST
   contain a Public header which declares all methods supported for the
   indicated resource.

   It is not necessary to use OPTIONS to discover support of a particular method, it MUST return
   501 (Not Implemented) and
   the requesting RTSP agent, in turn, SHOULD
   NOT client could simply try this the method.  If the receiver of the
   request does not support the method again for it will respond with an error
   code indicating the given agent / resource combination.
   An RTSP proxy whos main function method is to log or audit and either not modify
   transport implemented (501) or media handling in any way MAY forward RTSP messages with
   unknown methods.  Note, does
   not apply for the proxy stil needs to perform resource (405).  The choice between the minimal
   required processing, like adding two
   discovery methods depends on the Via header.

13.1.  OPTIONS

   The semantics requirements of the RTSP OPTIONS method is equivalent service.

   Feature-Tags are defined to handle functionality additions that are
   not new methods.  Each feature-tag represents a certain block of the
   HTTP OPTIONS method described in [H9.2].  In RTSP however, OPTIONS is
   bi-directional, in
   functionality.  The amount of functionality that a client feature-tag
   represents can request it to a server and vice
   versa. vary significantly.  A client MUST implement feature-tag can for example
   represent the capability to send an OPTIONS
   request and a server or functionality a proxy MUST implement single RTSP header provides.  Another
   feature-tag can represent much more functionality, such as the capability to
   respond
   "play.basic" feature-tag which represents the minimal playback
   implementation.

   Feature-tags are used to an OPTIONS request.  The determine whether the client, server or
   proxy MAY also
   implement the converse of their required capability.

   An OPTIONS request may be issued at any time.  Such a request does
   not modify the session state.  However, it may prolong supports the session
   lifespan (see below).  The URI in an OPTIONS request determines functionality that is necessary to achieve the
   scope
   desired service.  To determine support of the request and the corresponding response.  If the Request-
   URI refers to a specific media resource on a given host, the scope feature-tag, several
   different headers can be used, each explained below:

   Supported:  This header is
   limited used to determine the complete set of methods supported for
         functionality that media resource by
   the indicated RTSP agent.  A Request-URI with only the host address
   limits the scope both client and server have.  The intended
         usage is to the specified RTSP agent's general capabilities
   without regard determine before one needs to any specific media.  If the Request-URI is an
   asterisk ("*"), the scope use a functionality
         that it is limited to the general capabilities of
   the next hop (i.e. the RTSP agent in direct communication with the
   request sender).

   Regardless of scope of the request, the Public header MUST always supported.  It can be
   included used in the any method, however
         OPTIONS response listing is the most suitable one as it at the same time
         determines all methods that are
   supported implemented.  When sending a
         request the requester declares all its capabilities by
         including all supported feature-tags.  This results in that the responding RTSP agent.  In addition, if
         receiver learns the scope requesters feature support.  The receiver
         then includes its set of features in the request response.

   Proxy-Supported:  This header is limited used similar to a media resource, the Allow header MUST be
   included in the response to enumerate Supported
         header, but instead of giving the set supported functionality of methods that are
   allowed for that resource unless
         the set client or server it provides both the requester and the
         responder a view of methods completely
   matches what functionality the set in proxy chain between
         the Public header.  If two supports.  Proxies are required to add this header
         whenever the given resource Supported header is not
   available, present, but proxies may
         independently of the RTSP agent SHOULD return an appropriate response code
   such as 3rr or 4xx. requester add it.

   Require:  The Supported header MAY can be included in the any request where the end-
         point, i.e. the client or server, is required to query understand the set of features that are supported by
         feature to correctly perform the
   responding RTSP agent.

   The OPTIONS method can request.  This can, for
         example, be used to keep an RTSP session alive.
   However, it is not a SETUP request where the preferred means of session keep-alive
   signalling, see Section 16.48.  An OPTIONS request intended for
   keeping alive an RTSP session MUST include the Session header with
   the associated session ID.  Such server is required to
         understand a request SHOULD also use certain parameter to be able to set up the media
   or the aggregated control URI as the Request-URI.

   Example:

     C->S:  OPTIONS * RTSP/2.0
            CSeq: 1
            User-Agent: PhonyClient/1.2
            Require:
            Proxy-Require: gzipped-messages
            Supported: play.basic

     S->C:  RTSP/2.0 200 OK
            CSeq: 1
            Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
            Supported: play.basic, implicit-play, gzipped-messages
            Server: PhonyServer/1.1

   Note that some of
         delivery correctly.  Ignoring this parameter would not have the feature-tags in Require
         desired effect and Proxy-Require are
   fictional features.

13.2.  DESCRIBE

   The DESCRIBE method is used to retrieve not acceptable.  Therefore the description of a
   presentation or media object from end-point
         receiving a server.  The Request-URI of the
   DESCRIBE request identifies containing a Require MUST negatively
         acknowledge any feature that it does not understand and not
         perform the media resource of interest. request.  The
   client MAY include response in cases where features are
         not supported are 551 (Option Not Supported).  Also the Accept
         features that are not supported are given in the Unsupported
         header in the request to list response.

   Proxy-Require:  This header has the
   description formats same purpose and workings as
         Require except that it understands.  The server SHALL respond
   with a description of only applies to proxies and not the requested resource end-
         point.  Features that needs to be supported by both proxies and return
         end-point needs to be included in both the
   description Require and Proxy-
         Require header.

   Unsupported:  This header is used in a 551 error response, to
         indicate which features were not supported.  Such a response is
         only the entity result of the response.  The DESCRIBE reply-
   response pair constitutes the media initialization phase usage of RTSP.

   Example:

     C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
           CSeq: 312
           User-Agent: PhonyClient 1.2
           Accept: application/sdp, application/example

     S->C: RTSP/2.0 200 OK
           CSeq: 312
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer 1.1
           Content-Base: rtsp://server.example.com/fizzle/foo/
           Content-Type: application/sdp
           Content-Length: 358

           v=0
           o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46
           s=SDP Seminar
           i=A Seminar on the session description protocol
           u=http://www.example.com/lectures/sdp.ps
           e=seminar@example.com (Seminar Management)
           c=IN IP4 0.0.0.0
           a=recvonly
           a=control:*
           t=2873397496 2873404696
           m=audio 3456 RTP/AVP 0
           a=control:audio
           m=video 2232 RTP/AVP 31
           a=control:video

   The DESCRIBE response SHOULD contain all media initialization Require and/or Proxy-
         Require header where one or more feature where not supported.
         This information for allows the resource(s) that it describes.  Servers SHOULD
   NOT use requester to make the DESCRIBE response best of
         situations as it knows which features are not supported.

12.  Pipelining Support

   Pipelining is a means general method to improve performance of media indirection request
   response protocols by
   having allowing the description point at another server, instead usage of 3rr
   responses are recommended.

      By forcing a DESCRIBE response requesting entity to contain all media initialization
      for have more
   than one request outstanding and send them over the set same persistent
   connection.  For RTSP where the relative order of streams that requests will
   matter it describes, and discouraging is important to maintain the use order of DESCRIBE for media indirection, any looping problems can be
      avoided that might have resulted from other approaches.

   Media initialization is a requirement for any RTSP-based system, but the RTSP specification does not dictate that requests.
   Because of this is required to be
   done via the DESCRIBE method.  There are three ways that an RTSP
   client may receive initialization information:

   o  via an RTSP DESCRIBE request

   o  via some other protocol (HTTP, email attachment, etc.)
   o  via some form of a user interface

   If a client obtains a valid description from an alternate source, the
   client MAY use this description for initialization purposes without
   issuing a DESCRIBE request for responding entity MUST process the same media.

   It is RECOMMENDED that minimal servers support incoming
   requests in their sending order.  The sending order can be determined
   by the DESCRIBE method, CSeq header and highly recommended that minimal clients support its sequence number.  For TCP the ability to
   act delivery
   order will be the same as "helper applications" that accept a media initialization file
   from a user interface, and/or other means that are appropriate to the
   operating environment sending order.  The processing of the clients.

13.3.  SETUP

   The SETUP
   request for an URI specifies MUST also have been finished before processing the transport mechanism to be
   used for next
   request from the streamed media. same entity.  The SETUP method may responses MUST be used sent in two
   different cases; Create an RTSP session and change the transport
   parameters of already set up media stream.  SETUP can be used in all
   three states; INIT, and READY, for both purposes and in PLAY to
   change
   order the transport parameters.  There is also a third possibile
   usage requests was processed.

   RTSP 2.0 has extended support for the SETUP method which pipelining compared to RTSP 1.0.
   The major improvement is not specified in this memo:
   adding a media to a session.  Using SETUP allow all requests to add setup and initiate
   media playback to an existing
   session, when the session is in PLAY state, be pipelined after each other.  This is unspecified.

   The Transport header, see Section 16.51, specifies the transport
   parameters acceptable to the client for data transmission; the
   response will contain the transport parameters selected
   accomplished by the
   server. utilization of the Pipelined-Requests header (see
   Section 16.32).  This header allows the a client to enumerate in descending order of
   preference the transport mechanisms and parameters acceptable to it,
   while the server can select the most appropriate.  It is expected request that two or
   more requests are processed in the same RTSP session description format used will enable context which
   the client to
   select first request creates.  In other words a limited number possible configurations client can request that
   two or more media streams are offered to
   the server set-up and then played without needing
   to choose from.  All transport related parameters shall be
   included in wait for a single response.  This speeds up the Transport header, initial startup
   time for an RTSP session with at least one RTT.

   If a pipelined request builds on the use successful completion of other headers for this
   purpose is discouraged due to middleboxes, such as firewalls one or NATs.

   For
   more prior requests the benefit of any intervening firewalls, requester must verify that all requests were
   executed as expected.  A common example will be two SETUP requests
   and a client SHALL indicate PLAY request.  In case one of the known transport parameters, even if it has no influence over
   these parameters, for example, where SETUP fails unexpectedly, the server advertises a fixed
   multicast address
   PLAY request can still be successfully executed.  However, not as destination.

      Since SETUP includes all transport initialization information,
      firewalls and other intermediate network devices (which need this
      information) are spared the more arduous task of parsing
   expected by the
      DESCRIBE response, which has been reserved for media
      initialization.

   The requesting client SHALL include the Accept-Ranges header in the request
   indicating all supported unit formats in the Range header.  This
   allows the server to know which format it may use in future session
   related responses, such as PLAY response without any range in the
   request.  If the client does not support a time format necessary for
   the presentation the server SHALL respond using 456 (Header Field Not
   Valid for Resource) and include the Accept-Ranges header with the
   range unit formats supported for the resource.

   In only a SETUP response the server SHALL include the Accept-Ranges header
   (see Section 16.5) to indicate which time formats that are acceptable
   to use for this single media resource.

   The SETUP response 200 OK SHALL include the Media-Properties header
   (see Section 16.29 ).  The combination of the parameters of the
   Media-Properties header indicate the nature instead of
   two will be played.  In this case the content present in
   the session (see also Section 1.5).  For example, client can send a live stream with
   time shifting is indicated by

   o  Random Access set to Random-Access,

   o  Content Modifications set to Time Progressing,

   o  Retention set to Time-Duration (with specific recording window
      time value).

   The SETUP response 200 OK SHALL include the Media-Range header (see
   Section 16.30) if PAUSE
   request, correct the media is Time-Progressing.

   A basic example for SETUP:

     C->S: failing SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
           CSeq: 302
           Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
                      RTP/AVP/TCP;unicast;interleaved=0-1
           Accept-Ranges: NPT, UTC
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 302
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer 1.1
           Session: 47112344;timeout=60
           Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/
                      "192.0.2.53:4589"; src_addr="192.0.2.241:6256"/
                      "192.0.2.241:6257"; ssrc=2A3F93ED
           Accept-Ranges: NPT
           Media-Properties: Random-Access=3.2, Time-Progressing,
                             Time-Duration=3600.0
           Media-Range: npt=0-2893.23

   In the above example the client wants request and then request it to create an RTSP session
   containing the media resource "rtsp://example.com/foo/bar/baz.rm". be
   played.

13.  Method Definitions

   The transport parameters acceptable to the client method indicates what is either RTP/AVP/
   UDP (UDP per default) to be received on client port 4588 and 4589 or
   RTP/AVP interleaved performed on the RTSP control channel.  The server selects
   the RTP/AVP/UDP transport and adds the ports it will send and
   received RTP and RTCP from, and the RTP SSRC that will be used resource
   identified by the
   server. Request-URI.  The server MUST generate a session identifier in response to a
   successful SETUP request, unless a SETUP request to a server includes
   a session identifier, method name is case-sensitive.
   New methods may be defined in which case the server MUST bundle this setup
   request into the existing session (aggregated session) or return
   error 459 (Aggregate Operation Not Allowed) (see Section 15.4.11).
   An Aggregate control URI future.  Method names MUST be used to control an aggregated
   session.  This URI NOT
   start with a $ character (decimal 24) and MUST be different from the stream control URIs of a token as defined
   by the individual media streams included ABNF [RFC5234] in the aggregate. syntax chapter Section 20.  The
   Aggregate control URI is to be specified by the session description
   if the server supports aggregated control and aggregated control is
   desired for the session.  However even if aggregated control is
   offered the client MAY chose to not set up the session in aggregated
   control.  If an Aggregate control URI is not specified methods
   are summarized in the session
   description, it is normally an indication that non-aggregated control
   should be used.  The Table 7.

   +---------------+-----------+--------+--------------+---------------+
   | method        | direction | object | Server req.  | Client req.   |
   +---------------+-----------+--------+--------------+---------------+
   | DESCRIBE      | C -> S    | P,S    | recommended  | recommended   |
   |               |           |        |              |               |
   | GET_PARAMETER | C -> S    | P,S    | optional     | optional      |
   |               |           |        |              |               |
   |               | S -> C    |        |              |               |
   |               |           |        |              |               |
   | OPTIONS       | C -> S    | P,S    | R=Req,       | Sd=Req, R=Opt |
   |               |           |        | Sd=Opt       |               |
   |               |           |        |              |               |
   |               | S -> C    |        |              |               |
   |               |           |        |              |               |
   | PAUSE         | C -> S    | P,S    | required     | required      |
   |               |           |        |              |               |
   | PLAY          | C -> S    | P,S    | required     | required      |
   |               |           |        |              |               |
   | PLAY_NOTIFY   | S -> C    | P,S    | required     | required      |
   |               |           |        |              |               |
   | REDIRECT      | S -> C    | P,S    | optional     | required      |
   |               |           |        |              |               |
   | SETUP         | C -> S    | S      | required     | required      |
   |               |           |        |              |               |
   | SET_PARAMETER | C -> S    | P,S    | required     | optional      |
   |               |           |        |              |               |
   |               | S -> C    |        |              |               |
   |               |           |        |              |               |
   | TEARDOWN      | C -> S    | P,S    | required     | required      |
   |               |           |        |              |               |
   |               | S -> C    |        | required     | required      |
   +---------------+-----------+--------+--------------+---------------+

   Table 7: Overview of media streams in an aggregate which has
   not been given an aggregated control URI RTSP methods, their direction, and what objects
     (P: presentation, S: stream) they operate on. Legend: R=Respond,
                   Sd=Send, Opt: Optional, Req: Required
      Note on Table 7: GET_PARAMETER is unspecified.

      While the session ID sometimes has enough information for
      aggregate control of recommended, but not required.
      For example, a session, the Aggregate control URI is still
      important for some methods such as SET_PARAMETER where the control
      URI enables the resource in question to fully functional server can be easily identified.  The
      Aggregate control URI is also useful for proxies, enabling them built to
      route the request deliver
      media without any parameters.  SET_PARAMETER is required however
      due to the appropriate server, and its usage for logging,
      where it keep-alive.  PAUSE is useful now required due to note the actual resource
      that a request was
      operating on.

   A session will exist until it is either removed by a TEARDOWN request
   or is timed-out by the server.  The server MAY remove a session that
   has not demonstrated liveness signs from only way of getting out of the client(s) within a
   certain timeout period.  The default timeout value is 60 seconds; state machines play
      state without terminating the
   server MAY set this to whole session.

   If an RTSP agent does not support a different value particular method, it MUST return
   501 (Not Implemented) and indicate so in the
   timeout field of the Session header requesting RTSP agent, in the SETUP response.  For
   further discussion see Section 16.48.  Signs of liveness turn, SHOULD
   NOT try this method again for an RTSP
   session are:

   o  Any the given agent / resource combination.
   An RTSP request from a client(s) which includes a Session header
      with that session's ID.

   o  If RTP proxy who's main function is used as a to log or audit and not modify
   transport for the underlying media streams, an
      RTCP sender or receiver report from the client(s) for any of the media streams handling in that any way MAY forward RTSP session.  RTCP Sender Reports may for
      example be received in sessions where messages with
   unknown methods.  Note, the server proxy still needs to perform the minimal
   required processing, like adding the Via header.

13.1.  OPTIONS

   The semantics of the RTSP OPTIONS method is invited into a
      conference session and similar to that of the
   HTTP OPTIONS method described in [H9.2].  In RTSP however, OPTIONS is as valid for keep-alive.

   If
   bi-directional, in that a SETUP client can request on it to a session fails for any reason, the session
   state, as well as transport server and other parameters for associated
   streams SHALL remain unchanged from their values as if the SETUP
   request had never been received by the server.

13.3.1.  Changing Transport Parameters vice
   versa.  A client MAY issue a SETUP MUST implement the capability to send an OPTIONS
   request for and a stream that is already set
   up server or playing in a proxy MUST implement the session capability to change transport parameters, which a
   respond to an OPTIONS request.  The client, server or proxy MAY allow.  If it also
   implement the converse of their required capability.

   An OPTIONS request may be issued at any time.  Such a request does
   not allow changing of parameters, modify the session state.  However, it
   MUST respond with error 455 (Method Not Valid In This State).
   Reasons to support changing transport parameters, is to allow for
   application layer mobility may prolong the session
   lifespan (see below).  The URI in an OPTIONS request determines the
   scope of the request and flexibility to utilize the best
   available transport as it becomes available. corresponding response.  If the Request-
   URI refers to a client receives specific media resource on a
   455 when trying to change transport parameters while given host, the server scope is in
   play state, it MAY try
   limited to put the server in ready state using PAUSE,
   before issuing the SETUP request again.  If also that fails the
   changing set of transport parameters will require methods supported for that media resource by
   the client
   performs a TEARDOWN of indicated RTSP agent.  A Request-URI with only the affected media and then setting it up
   again.  In aggregated session avoiding tearing down all host address
   limits the media at scope to the same time will avoid specified RTSP agent's general capabilities
   without regard to any specific media.  If the creation of a new session.

   All transport parameters MAY be changed.  However Request-URI is an
   asterisk ("*"), the primary usage
   expected scope is limited to either change transport protocol completely, like
   switching from Interleaved TCP mode to UDP or vise versa or change
   delivery address.

   In a SETUP response for a request to change the transport parameters
   while in Play state, general capabilities of
   the server SHALL include next hop (i.e. the Range to indicate
   from what point RTSP agent in direct communication with the new transport parameters are used.  Further, if
   RTP is used for delivery,
   request sender).

   Regardless of scope of the server SHALL also include request, the RTP-Info Public header to indicate from what timestamp and RTP sequence number the
   change has taken place.  If both RTP-Info and Range is MUST always be
   included in the OPTIONS response listing the "rtp_time" parameter and range MUST be for methods that are
   supported by the
   corresponding time, i.e. be used in responding RTSP agent.  In addition, if the same way as for PLAY to
   ensure scope of
   the correct synchronization information request is available.

   If the transport parameters change while in PLAY state results in limited to a
   change of synchronization related information, for example changing
   RTP SSRC, media resource, the server Allow header MUST provide be
   included in the SETUP response the necessary
   synchronization information.  However the server is RECOMMENDED to
   avoid changing enumerate the synchronization information if possible.

13.4.  PLAY

   This section describes set of methods that are
   allowed for that resource unless the usage set of methods completely
   matches the PLAY method in general, for
   aggregated sessions, and set in different usage scenarios.

13.4.1.  General Usage the Public header.  If the given resource is not
   available, the RTSP agent SHOULD return an appropriate response code
   such as 3rr or 4xx.  The PLAY method tells Supported header MAY be included in the server
   request to start sending data via query the
   mechanism specified in SETUP and which part set of the media should be
   played out.  PLAY requests features that are valid when supported by the
   responding RTSP agent.

   The OPTIONS method can be used to keep an RTSP session alive.
   However, it is in READY or
   PLAY states.  A PLAY not the preferred means of session keep-alive
   signalling, see Section 16.48.  An OPTIONS request intended for
   keeping alive an RTSP session MUST include a the Session header to
   indicate which session with
   the associated session ID.  Such a request applies to.

   Upon receipt of the PLAY request, SHOULD also use the server SHALL position media
   or the
   normal play time to aggregated control URI as the beginning Request-URI.

   Example:

     C->S:  OPTIONS * RTSP/2.0
            CSeq: 1
            User-Agent: PhonyClient/1.2
            Require:
            Proxy-Require: gzipped-messages
            Supported: play.basic

     S->C:  RTSP/2.0 200 OK
            CSeq: 1
            Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
            Supported: play.basic, implicit-play, gzipped-messages
            Server: PhonyServer/1.1

   Note that some of the range specified feature-tags in the
   received Range header Require and delivers stream data until Proxy-Require are
   fictional features.

13.2.  DESCRIBE

   The DESCRIBE method is used to retrieve the end description of the
   range if given, a
   presentation or until media object from a new PLAY request is received, else to the
   end server.  The Request-URI of the
   DESCRIBE request identifies the media is reached.  To allow for precise composition
   multiple ranges resource of interest.  The
   client MAY be specified include the Accept header in one PLAY Request.  The range
   values are valid if all given ranges are part of any media within the
   aggregate.  If request to list the
   description formats that it understands.  The server MUST respond
   with a given range value points outside description of the media, requested resource and return the
   response SHALL be
   description in the 457 (Invalid Range) error code. message body of the response.  The below example will first play seconds 10 through 15, then,
   immediately following, seconds 20 to 25, and finally seconds 30
   through DESCRIBE reply-
   response pair constitutes the end. media initialization phase of RTSP.

   Example:

     C->S: PLAY rtsp://audio.example.com/audio DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
           CSeq: 835
           Session: 12345678
           Range: npt=10-15, npt=20-25, npt=30-
           Seek-Style: RAP 312
           User-Agent: PhonyClient/1.2

   See PhonyClient 1.2
           Accept: application/sdp, application/example

     S->C: RTSP/2.0 200 OK
           CSeq: 312
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer 1.1
           Content-Base: rtsp://server.example.com/fizzle/foo/
           Content-Type: application/sdp
           Content-Length: 358

           v=0
           o=mhandley 2890844526 2890842807 IN IP4 192.0.2.46
           s=SDP Seminar
           i=A Seminar on the session description of the PAUSE request protocol
           u=http://www.example.com/lectures/sdp.ps
           e=seminar@example.com (Seminar Management)
           c=IN IP4 0.0.0.0
           a=recvonly
           a=control:*
           t=2873397496 2873404696
           m=audio 3456 RTP/AVP 0
           a=control:audio
           m=video 2232 RTP/AVP 31
           a=control:video

   The DESCRIBE response SHOULD contain all media initialization
   information for further examples.

   A PLAY request without a Range header is legal.  It SHALL start
   playing a stream from the beginning (npt=0-) unless the stream has
   been paused or is currently playing.  If a stream has been paused via
   PAUSE, stream delivery resumes at resource(s) that it describes.  Servers SHOULD
   NOT use the pause point.  If DESCRIBE response as a stream is
   currently playing, the new PLAY begins at the current stream
   position.  The stream SHALL play until the end means of media indirection by
   having the media.  The
   Range header MUST NOT contain a time parameter.  The description point at another server, instead usage of time in
   PLAY method has been deprecated.  If a request with time parameter is
   received the server SHOULD respond with 3rr
   responses are recommended.

      By forcing a 457 (Invalid Range) DESCRIBE response to
   indicate contain all media initialization
      for the set of streams that it describes, and discouraging the time parameter use
      of DESCRIBE for media indirection, any looping problems can be
      avoided that might have resulted from other approaches.

   Media initialization is a requirement for any RTSP-based system, but
   the RTSP specification does not supported.  If no range dictate that this is
   specified in the request, the start position SHALL still required to be returned
   in the reply.  If
   done via the medias that DESCRIBE method.  There are part of three ways that an aggregate has
   different lengths, the PLAY RTSP
   client may receive initialization information:

   o  via an RTSP DESCRIBE request SHALL be performed as long as the
   given range is

   o  via some other protocol (HTTP, email attachment, etc.)
   o  via some form of a user interface

   If a client obtains a valid description from an alternate source, the
   client MAY use this description for any media, initialization purposes without
   issuing a DESCRIBE request for example the longest same media.
   Media will be sent whenever it

   It is available for RECOMMENDED that minimal servers support the given play-out
   point.

   A client desiring to play DESCRIBE method,
   and highly recommended that minimal clients support the ability to
   act as "helper applications" that accept a media initialization file
   from the beginning MUST send a
   PLAY request with a Range header pointing at user interface, and/or other means that are appropriate to the beginning, e.g.
   npt=0-.  If a PLAY
   operating environment of the clients.

13.3.  SETUP

   The SETUP request is received without a Range header when
   media delivery has stopped at for an URI specifies the end, transport mechanism to be
   used for the server SHOULD respond with
   a 457 "Invalid Range" error response.  In that response the current
   pause point streamed media.  The SETUP method may be used in a Range header SHALL two
   different cases; Create an RTSP session and change the transport
   parameters of already set up media stream.  SETUP can be included.

   All range specifiers used in this specification allow all
   three states; INIT, and READY, for ranges with
   unspecified begin times (e.g. "npt=-30").  When used both purposes and in a PLAY
   request, the server treats this as a request to start/resume playback
   from
   change the current pause point, ending at transport parameters.  There is also a third possible
   usage for the end time SETUP method which is not specified in the
   Range header.  If the pause point is located later than the given end
   value, this memo:
   adding a 457 (Invalid Range) response SHALL be given.

   Server MUST include media to a "Range" header session.  Using SETUP to add media to an existing
   session, when the session is in any PLAY response. state, is unspecified.

   The
   response MUST use Transport header, see Section 16.52, specifies the same format as media
   transport parameters acceptable to the request's range header
   contained.  If no Range header was in client for data transmission;
   the request, response will contain the format used in
   any previous PLAY request within transport parameters selected by the session SHOULD be used.  If no
   format has been indicated in a previous request
   server.  This allows the server MAY use
   any time format supported by client to enumerate in descending order of
   preference the media transport mechanisms and indicated in parameters acceptable to it,
   while the Accept-
   Ranges header in server can select the SETUP respone. most appropriate.  It is RECOMMENDED expected
   that NPT is the session description format used if supported by will enable the media.

   For any error response client to
   select a PLAY request, the server's response
   depends on the current session state.  If limited number possible configurations that are offered to
   the session is server to choose from.  All transport related parameters shall be
   included in ready
   state, the current pause-point is returned.  For time-progressing
   content where Transport header, the pause-point moves with real-time use of other headers for this
   purpose is discouraged due to limited
   retention, the current resume point is returned. middleboxes, such as firewalls or NATs.

   For sessions in
   playing state, the current playout point and the remaining parts benefit of
   the range request is returned.

   A PLAY response MAY include any intervening firewalls, a header(s) carrying synchronization
   information.  As the information necessary is dependent on client MUST indicate
   the media known transport format, further rules specifying the header and its usage
   is needed.  For RTP the RTP-Info header is specified, see
   Section 16.43, and used in the following example.

   Here is a simple example parameters, even if it has no influence over
   these parameters, for a single audio stream example, where the client
   requests the media starting from 3.52 seconds and to the end.  The server sends advertises a 200 OK response with the actual play time (equal to
   the requested in this case) fixed
   multicast address as destination.

      Since SETUP includes all transport initialization information,
      firewalls and other intermediate network devices (which need this
      information) are spared the RTP-Info header that contains more arduous task of parsing the
   necessary parameters
      DESCRIBE response, which has been reserved for media
      initialization.

   The client MUST include the RTP stack.

   C->S: PLAY rtsp://example.com/audio RTSP/2.0
         CSeq: 836
         Session: 12345678
         Range: npt=3.52-
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 836
         Date: Thu, 23 Jan 1997 15:35:06 GMT
         Server: PhonyServer 1.0
         Range: npt=3.52-324.39
         RTP-Info:url="rtsp://example.com/audio"
            ssrc=0D12F123:seq=14783;rtptime=2345962545

   S->C: RTP Packet TS=2345962545 => NPT=3.52
         Duration=4.15 seconds

   For media with random-acces properties, Accept-Ranges header in the server MUST reply with request
   indicating all supported unit formats in the actual range that will be played back, i.e. for which duration
   any media (having content at this time) is delivered. Range header.  This may
   differ from
   allows the requested server to know which format it may use in future session
   related responses, such as PLAY response without any range if alignment of in the requested range
   to valid frame boundaries is required for
   request.  If the media source.  Note
   that some media streams in an aggregate may need to be delivered from
   even earlier points.  Also, some media format have client does not support a very long
   duration per individual data unit, therefore it might be time format necessary for
   the client to parse the data unit, and select where to start.
   The client can express its desired handling by presentation the server by
   including MUST respond using 456 (Header Field Not
   Valid for Resource) and include the Seek-Style Accept-Ranges header (Section 16.45) in with the PLAY request,
   if desired.

   In
   range unit formats supported for the following example resource.

   In a SETUP response the client receives server MUST include the first media packet Accept-Ranges header
   (see Section 16.5) to indicate which time formats that stretches all are acceptable
   to use for this media resource.

   The SETUP response 200 OK MUST include the way up and past Media-Properties header
   (see Section 16.28 ).  The combination of the requested playtime.  Thus,
   it is parameters of the client's decision if to render to
   Media-Properties header indicate the user nature of the content present in
   the session (see also Section 4.9).  For example, a live stream with
   time between
   3.52 and 7.05, or to skip it.  In most cases it shifting is probably most
   suitable indicated by

   o  Random Access set to not render that Random-Access,

   o  Content Modifications set to Time Progressing,

   o  Retention set to Time-Duration (with specific recording window
      time period. value).

   The SETUP response 200 OK MUST include the Media-Range header (see
   Section 16.29) if the media is Time-Progressing.

   A basic example for SETUP:

     C->S: PLAY rtsp://example.com/audio SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
           CSeq: 836
         Session: 12345678
         Range: npt=7.05- 302
           Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
                      RTP/AVP/TCP;unicast;interleaved=0-1
           Accept-Ranges: NPT, UTC
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 836 302
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer 1.0
         Range: npt=3.52-
         RTP-Info:url="rtsp://example.com/audio"
            ssrc=0D12F123:seq=14783;rtptime=2345962545

   S->C: RTP Packet TS=2345962545 => NPT=3.52
         Duration=4.15 seconds

   After playing 1.1
           Session: 47112344;timeout=60
           Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/
                      "192.0.2.53:4589"; src_addr="192.0.2.241:6256"/
                      "192.0.2.241:6257"; ssrc=2A3F93ED
           Accept-Ranges: NPT
           Media-Properties: Random-Access=3.2, Time-Progressing,
                             Time-Duration=3600.0
           Media-Range: npt=0-2893.23

   In the desired range, above example the presentation does NOT transition client wants to create an RTSP session
   containing the READY state, media delivery simply stops.  A PAUSE request
   MUST be issued before resource "rtsp://example.com/foo/bar/baz.rm".
   The transport parameters acceptable to the stream enters client is either RTP/AVP/
   UDP (UDP per default) to be received on client port 4588 and 4589 or
   RTP/AVP interleaved on the READY state.  A PLAY
   request while RTSP control channel.  The server selects
   the stream is still in RTP/AVP/UDP transport and adds the PLAYING state is legal, ports it will send and
   can
   received RTP and RTCP from, and the RTP SSRC that will be issued without an intervening PAUSE request.  Such a request
   SHALL replace the current PLAY action with the new one requested,
   i.e. being handle the same as used by the
   server.

   The server MUST generate a session identifier in response to a
   successful SETUP request, unless a SETUP request was received to a server includes
   a session identifier, in ready
   state.  In the which case the first time range in Range header has a open
   start time (-endtime), the server SHALL continue MUST bundle this setup
   request into the existing session (aggregated session) or return
   error 459 (Aggregate Operation Not Allowed) (see Section 15.4.24).
   An Aggregate control URI MUST be used to play control an aggregated
   session.  This URI MUST be different from where
   it currently was until the specified end point.  This is useful to
   change ongoing playback to play another sequence, or end at another
   point than stream control URIs of
   the individual media streams included in the previous request. aggregate.  The following example plays
   Aggregate control URI is to be specified by the whole presentation starting at SMPTE
   time code 0:10:20 until session description
   if the end of server supports aggregated control and aggregated control is
   desired for the clip.  Note: The RTP-Info
   headers has been broken into several lines session.  However even if aggregated control is
   offered the client MAY chose to fit not set up the page.

   C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0
         CSeq: 833
         Session: 12345678
         Range: smpte=0:10:20-
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 833
         Date: Thu, 23 Jan 1997 15:35:06 GMT
         Server: PhonyServer 1.0
         Range: smpte=0:10:22-0:15:45
         RTP-Info:url="rtsp://example.com/twister.en"
            ssrc=0D12F123:seq=14783;rtptime=2345962545

   For playing back a recording of a live presentation, session in aggregated
   control.  If an Aggregate control URI is not specified in the session
   description, it may is normally an indication that non-aggregated control
   should be
   desirable to use clock units:
   C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0
         CSeq: 835
         Session: 12345678
         Range: clock=19961108T142300Z-19961108T143520Z
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 835
         Date: Thu, 23 Jan 1997 15:35:06 GMT
         Server:PhonyServer 1.0
         Range: clock=19961108T142300Z-19961108T143520Z
         RTP-Info:url="rtsp://example.com/meeting.en"
            ssrc=0D12F123:seq=53745;rtptime=484589019

13.4.2.  Aggregated Sessions

   PLAY requests can operate on sessions controlling a single used.  The SETUP of media and
   on aggregated sessions controlling multiple media.

   In streams in an aggregated session the PLAY request MUST contain aggregate which has
   not been given an aggregated control URI.  A server SHALL responde with error 460 (Only Aggregate
   Operation Allowed) if the client PLAY Request-URI URI is unspecified.

      While the session ID sometimes carries enough information for one
      aggregate control of a session, the
   media.  The media Aggregate control URI is still
      important for some methods such as SET_PARAMETER where the control
      URI enables the resource in an aggregate SHALL question to be played in sync.  If a
   client wants individual easily identified.  The
      Aggregate control of URI is also useful for proxies, enabling them to
      route the media it needs request to use separate
   RTSP sessions the appropriate server, and for each media.

   For aggregated sessions logging,
      where it is useful to note the initial SETUP request (creating actual resource that a
   session) request was
      operating on.

   A session will exist until it is followed either removed by one or more additional SETUP request, a PLAY TEARDOWN request MAY be pipelined after those additional SETUP requests
   without awaiting their responses.  This procedure can reduce
   or is timed-out by the
   delay from start of session establishment until media play-out has
   started with one round trip time.  However an client needs to be
   aware server.  The server MAY remove a session that using
   has not demonstrated liveness signs from the client(s) within a
   certain timeout period.  The default timeout value is 60 seconds; the
   server MAY set this procedure will result to a different value and indicate so in the playout
   timeout field of the
   server state established at Session header in the time SETUP response.  For
   further discussion see Section 16.48.  Signs of processing liveness for an RTSP
   session are:

   o  Any RTSP request from a client(s) which includes a Session header
      with that session's ID.

   o  If RTP is used as a transport for the PLAY, i.e.,
   after underlying media streams, an
      RTCP sender or receiver report from the processing client(s) for any of all the requests prior to the PLAY request
      media streams in
   the pipeline.  This that RTSP session.  RTCP Sender Reports may not for
      example be received in sessions where the intended one due to failure of any
   of the prior requests.  However server is invited into a client easily determine this based
      conference session and is as valid for keep-alive.

   If a SETUP request on a session fails for any reason, the responses session
   state, as well as transport and other parameters for associated
   streams MUST remain unchanged from those requests.  In case of failure the client
   can halt their values as if the media playout using PAUSE and try to establish SETUP
   request had never been received by the
   intended state again before issuing another PLAY request.

13.4.3.  Updating current PLAY Requests

   Clients can server.

13.3.1.  Changing Transport Parameters

   A client MAY issue PLAY a SETUP request while the for a stream that is In PLAYING state
   and thus updating their request.  The possibility already set
   up or playing in the session to replace change transport parameters, which a
   current PLAY request
   server MAY allow.  If it does not allow changing of parameters, it
   MUST respond with a new one replaces the following RTSP 1.0
   functions based on PLAY in play state:

   o  The queued play functionality described in RFC 2326 [RFC2326] error 455 (Method Not Valid In This State).
   Reasons to support changing transport parameters, is
      removed to allow for
   application layer mobility and multiple ranges can be used flexibility to achieve a similar
      functionality in combination with utilize the possibility to replace
      previous play messages.

   o  The use of PLAY for keep-alive signaling, i.e.  PLAY request
      without best
   available transport as it becomes available.  If a range header client receives a
   455 when trying to change transport parameters while the server is in PLAY
   play state, has also been deprecated.
      Instead a client can use, SET_PARAMETER (recommended) or OPTIONS
      (allowed) for keep alive.

   The important difference compared it MAY try to a PLAY request put the server in ready state is using PAUSE,
   before issuing the handling SETUP request again.  If also that fails the
   changing of transport parameters will require that the current playpoint and how client
   performs a TEARDOWN of the range header in
   request is constructed.  The session is actively playing affected media and then setting it up
   again.  In aggregated session avoiding tearing down all the playpoint will be moving making media at
   the exact same time a request will
   take action is hard to predict.  Depending on how avoid the PLAY header
   appears two different cases exist: total replacement or continuation.
   A total replacement is signalled by having creation of a new session.

   All transport parameters MAY be changed.  However the first range
   specification have an explicit start value, e.g. npt=45- primary usage
   expected is to either change transport protocol completely, like
   switching from Interleaved TCP mode to UDP or
   npt=45-60, vise versa or change
   delivery address.

   In a SETUP response for a request to change the transport parameters
   while in which case Play state, the server stops playout at the current
   playout point and then starts delivering media according to MUST include the Range
   header.  This is equivalent to having indicate
   from what point the client first send a PAUSE
   and then a new play request that isn't based on transport parameters are used.  Further, if
   RTP is used for delivery, the pause point.  In server MUST also include the case of continuation RTP-Info
   header to indicate from what timestamp and RTP sequence number the first range specifier
   change has an open taken place.  If both RTP-Info and Range is included in
   the response the "rtp_time" parameter and start point and a explict stop value (Z), e.g. npt=-60, which indicate that
   it SHALL convert in the range specifier being played prior to this Range
   header MUST be for the corresponding time, i.e. be used in the same
   way as for PLAY
   request (X to Y) into (X to Z) and continue as this was ensure the request
   originally played.  For both total replacement and continuation correct synchronization information is
   available.

   If the transport parameters change while in PLAY request SHALL remove any additional range specifiers present state results in a
   change of synchronization related information, for example changing
   RTP SSRC, the server MUST provide in the previous request and add any that SETUP response the necessary
   synchronization information.  However the server is present in RECOMMENDED to
   avoid changing the new synchronization information if possible.

13.4.  PLAY
   request.

   An example

   This section describes the usage of this behavior. the PLAY method in general, for
   aggregated sessions, and in different usage scenarios.

13.4.1.  General Usage

   The PLAY method tells the server has received requests to
   play ranges 10 to 15 start sending data via the
   mechanism specified in SETUP and then 13 to 20 (that is, overlapping ranges).
   If which part of the new media should be
   played out.  PLAY requests are valid when the session is in READY or
   PLAY states.  A PLAY request arrives at MUST include a Session header to
   indicate which session the server 4 seconds after request applies to.

   Upon receipt of the
   previous one, it will take effect while PLAY request, the server plays the first
   range (10-15).  Thus changing MUST position the behavior of this range to continue
   to normal
   play time to 25 seconds, i.e. the equivalent single request would be
   PLAY with range: npt=10-25.  Note that beginning of the second range (13-20) is
   deleted specified in the received
   Range header and never comes into effect.  If delivers stream data until the end of the range if
   given, or until a new PLAY request would
   arrive as is received, else to the second range end of
   the media is reached.  If not Range header is present in the first PLAY
   request was playing (13-20
   and shown below), then the equivalent single request would be server shall play
   with range:npt=10-15,npt=13-25.

     C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 834
           Session: 12345678
           Range: npt=10-15, npt=13-20
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 834
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer 1.0
           Range: npt=10-15, npt=13-20
           RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=5712;rtptime=934207921,
                   url="rtsp://example.com/fizzle/videotrack"
                   ssrc=789DAF12:seq=57654;rtptime=2792482193
           Session: 12345678

     C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 835
           Session: 12345678
           Range: npt=-25
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 835
           Date: Thu, 23 Jan 1997 15:35:09 GMT
           Server: PhonyServer 1.0
           Range: npt=14-25
           RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=5712;rtptime=934239921,
                   url="rtsp://example.com/fizzle/videotrack"
                   ssrc=789DAF12:seq=57654;rtptime=2792842193
           Session: 12345678

13.4.4.  Playing On-Demand Media

   On-demand media is indicated by from current pause point until the content end
   of media.  The pause point defaults at start to the Media-Properties
   header in beginning of the SETUP response by (see also Section 16.29):

   o  Random-Access property
   media.  For media that is time-progressing and has no retention, the
   pause point will always be set equal to Random Acces;

   o  Content Modifications NPT "now", i.e. current
   playback point.  The pause point may also be set to unmutable;

   o  Retetion set Unlimited or Time-Limited.

   Playing on-demand media follows the general usage as described a particular
   point in
   Section 13.4.1.

13.4.5.  Playing Dynamic On-Demand Media

   Dynamic on-demand the media is indicated by the content of the Media-
   Properties header in the SETUP response by (see also PAUSE method, see Section 16.29):

   o  Random-Access set to Random Access;

   o  Content Modifications set to dynamic;

   o  Retetion set unlimited or Time-Limited.

   Playing on-demand 13.6.  The pause
   point for media follows the general usage as described in
   Section 13.4.1 as long as that is currently playing is equal to the current
   media has not been changed.

   There are ways for the client to get informed about changed of position.  For time-progressing media
   resources in play state, with time-limited
   retention, if the resource was changed.  The client
   will receive pause point represents a PLAY_NOTIFY request with Notify-Reason header set to
   media-properties-update (see Section 13.5.2.  The client can use position that is older
   than what is retained by the
   value of server, the Media-Range pause point will be moved to decide further actions, if
   the Media-
   Range header oldest retained.

   What range values is present in valid depends on the PLAY_NOTIFY request.  The second way
   is type of content.  For
   content that isn't time progressing the client issues a GET_PARAMETER request without a body but
   including a Media-Range header.  The 200 OK response SHALL include range value is valid if the current Media-Range header (see Section 16.30).

13.4.6.  Playing Live Media

   Live
   given range is part of any media within the aggregate.  In other
   words the valid media range for the aggregate is indicated by the content super-set of all
   of the Media-Properties header media components in the SETUP response by (see also Section 16.29):

   o  Random-Access set to no-seeking;

   o  Content Modifications set to Time-Progressing;

   o  Retetion with Time-Duration set to 0.0.

   For live aggregate.  If a given range value
   points outside of the media, the SETUP response 200 OK SHALL MUST be the 457 (Invalid
   Range) error code and include the Media-
   Range Media-Range header (see Section 16.30).

   A client MAY send PLAY requests without (Section 16.29)
   with the Range header, if valid range for the
   request include media.  For time progressing content
   where the Range header it SHALL use client request a symbolic value
   representing "now". start point prior to what is retained, the
   start point is adjusted to the oldest retained content.  For NPT a start
   point that range specification is "npt=now-".
   The server SHALL include beyond the Range header in media front edge, i.e. beyond the response and it MUST
   indicate a explict time current
   value and not a symbolic value.  In other
   words npt=now- is not a valid to use in for "now", the respone.  Instead server shall adjust the
   time since session start is recommended expressed as an open
   interval, e.g. "npt=96.23-".  An absolute time value (clock) for to the
   corresponding time MAY be given, i.e. "clock=20030213T143205Z-".
   current front edge.  The
   UTC clock format SHOULD only be used if client has shown support for
   it.

13.4.7.  Playing Live with Recording

   Certain Range headers end point value may point
   beyond the current media edge.  In that case the server may offer recording services of live sessions to
   their clients.  This recording would normally be shall deliver
   media from the begining requested (and possibly adjusted) start point until
   the provided end-point, or the end of the media session.  Clients can randomly access is reached prior to
   the media between now
   and specified stop point.  Please note that if one simply want to
   play from a particular start point until the begining end of the media session.  This live using an
   Range header with an implicit stop point is recommended.

   For media with
   recording random access properties a client may express its
   preference on which policy for start point selection the server shall
   use.  This is indicated done by including the content of the Media-Properties Seek-Style header (Section 16.45)
   in the SETUP response by (see also Section 16.29):

   o  Random-Access set to random-access;

   o  Content Modifications set to Time-Progressing;

   o  Retetion set PLAY request.

   A client desiring to Time-limited or Unlimited

   The SETUP response 200 OK SHALL include play the Media-Range header (see
   Section 16.30) for this type of media.  For live media with recording from the beginning MUST send a
   PLAY request with a Range header indicates the current playback time in pointing at the beginning, e.g.
   npt=0-.  If a PLAY request is received without a Range header when
   media and delivery has stopped at the Media Range indicates end, the currently available media window around server SHOULD respond with
   a 457 "Invalid Range" error response.  In that response the current time.  This window can cover recorded content
   pause point in the past
   (seen from current time a Range header MUST be included.

   All range specifiers in the media) or recorded content this specification allow for ranges with
   implicit start point (e.g. "npt=-30").  When used in a PLAY request,
   the
   future (seen server treats this as a request to start/resume playback from the
   current pause point, ending at the end time specified in the media).  The server adjusts Range
   header.  If the
   play pause point to the requested border of the window, if is located later than the client
   requests given end
   value, a 457 (Invalid Range) response MUST be given.

   The below example will play point that is located outside seconds 10 through 25.  It also request
   the recording windows,
   e.g., if requested server to far deliver media from the first Random Access Point prior
   to the indicated start point.

     C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0
           CSeq: 835
           Session: 12345678
           Range: npt=10-25
           Seek-Style: RAP
           User-Agent: PhonyClient/1.2

   Server MUST include a "Range" header in any PLAY response, even if no
   Range header was present in the past, request.  The response MUST use the server selects
   same format as the oldest request's range header contained.  If no Range
   header was in the recording.  The considerations request, the format used in any previous PLAY
   request within the session SHOULD be used.  If no format has been
   indicated in Section 13.5.3 apply,
   if a client requests playback at Scale (Section 16.44) values other
   than 1.0 (Normal playback rate) while playing live media with
   recording.

13.4.8.  Playing Live with Time-Shift

   Certain media previous request the server may offer time-shift services to their clients.
   This MAY use any time shift records a fixed interval in the past, i.e., a sliding
   window recording mechanism, but not past this interval.  Clients can
   randomly access format
   supported by the media between now and the interval.  This live
   media with recording is indicated by the content of in the Media-
   Properties Accept-Ranges header in
   the SETUP response response.  It is RECOMMENDED that NPT is used if supported
   by (see also Section 16.29):

   o  Random-Access set to random-access;

   o  Content Modifications set to Time-Progressing;

   o  Retetion set to Time-Duration and a value indicating the recording
      interval (>0).

   The SETUP response 200 OK SHALL include the Media-Range header (see
   Section 16.30) for this type of media.

   For live media with recording
   the Range header indicates the current time in the media and the
   Media Range indicates any error response to a window around PLAY request, the current time.  This window
   can cover recorded content in server's response
   depends on the past (seen from current time in session state.  If the
   media) or recorded content session is in ready
   state, the future (seen from current time in
   the media).  The server adjusts pause-point is returned using Range header with
   the play pause point to as the requested
   border of explicit start-point and an implicit end-
   point.  For time-progressing content where the window, if pause-point moves with
   real-time due to limited retention, the client requests a play current pause point that is
   located outside the recording windows, e.g., if requested to far
   returned.  For sessions in playing state, the past, current playout point
   and the server selects remaining parts of the oldest range in the recording.  The
   considerations in Section 13.5.3 apply, if a client requests playback
   at Scale (Section 16.44) values other than 1.0 (Normal playback rate)
   while playing live request is returned.  For any
   media with time-shift.

13.5.  PLAY_NOTIFY

   The PLAY_NOTIFY method is issued by a server to inform a client about
   an ansynchronous event for a session in play state.  The Session retention longer than 0 seconds the currently valid Media-
   Range header MUST shall also be presented included in the response.

   A PLAY response MAY include a PLAY_NOTIFY request and indicates header(s) carrying synchronization
   information.  As the
   scope of information necessary is dependent on the request.  Sending of PLAY_NOTIFY requests requires a
   persistent connection between server media
   transport format, further rules specifying the header and client, otherwise there its usage
   is
   no way for needed.  For RTP the server to send this request method to RTP-Info header is specified, see
   Section 16.43, and used in the client.

   PLAY_NOTIFY following example.

   Here is a simple example for a single audio stream where the client
   requests have an end-to-end (i.e. server to client)
   scope, as they carry the Session header, media starting from 3.52 seconds and apply only to the given
   session. end.  The client SHOULD immediately return
   server sends a 200 OK response to the
   server.

   PLAY_NOTIFY requests MAY be used with a message body, depending on
   the value of the Notify-Reason header.  It actual play time which is described in 10
   m prior (3.51) and the
   particular section for each Notify-Reason if a message body is used.
   However, currently there is no Notify-Reason RTP-Info header that allows using a
   message body.  There is contains the need to obey some limitations, when
   adding new Notify-Reasons that intend to use a message body: necessary
   parameters for the RTP stack.
   C->S: PLAY rtsp://example.com/audio RTSP/2.0
         CSeq: 836
         Session: 12345678
         Range: npt=3.52-
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 836
         Date: Thu, 23 Jan 1997 15:35:06 GMT
         Server: PhonyServer 1.0
         Range: npt=3.51-324.39
         Seek-Style: First-Prior
         RTP-Info:url="rtsp://example.com/audio"
            ssrc=0D12F123:seq=14783;rtptime=2345962545

   S->C: RTP Packet TS=2345962545 => NPT=3.51
         Duration=0.16 seconds

   The server can send any type of message body, but it is not ensured reply with the actual start point that will be delivered.
   This may differ from the client can understand requested range if alignment of the received message body.  This
   requested range to valid frame boundaries is related required for the media
   source.  Note that some media streams in an aggregate may need to DESCRIBE (seeSection 13.2 ), but there be
   delivered from even earlier points.  Also, some media format have a
   very long duration per individual data unit, therefore it might be
   necessary for the client can state its
   acceptable message bodies by using the Accept header.  In case of
   PLAY_NOTIFY, to parse the data unit, and select where to
   start.  The server does not know shall also indicate which message bodies are
   understood policy it uses for
   selecting the actual start point by including a Seek-Style header.

   In the client.

   The Notify-Reason header (see Section 16.31) specifies following example the reason why client receives the server sends first media packet
   that stretches all the PLAY_NOTIFY request.  This is extensible way up and new
   reasons MAY be added in past the future.  In case requested playtime.  Thus,
   it is the client does not
   understand client's decision if to render to the reason for user the notification it SHALL respond with an
   465 (Notification Reason Unknown) (Section 15.4.17) error code.
   Servers can send PLAY_NOTIFY with these types:

   o  end-of-stream (see Section 13.5.1);

   o  media-properties-update (see Section 13.5.2);

   o time between
   3.52 and scale-change (see Section 13.5.3).

13.5.1.  End-of-Stream

   A PLAY_NOTIFY request with Notify-Reason header set 7.05, or to end-of-stream
   indicates the end of skip it.  In most cases it is probably most
   suitable to not render that time period.
   C->S: PLAY rtsp://example.com/audio RTSP/2.0
         CSeq: 836
         Session: 12345678
         Range: npt=7.05-      User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 836
         Date: Thu, 23 Jan 1997 15:35:06 GMT
         Server: PhonyServer 1.0
         Range: npt=3.52-
         Seek-Style: First-Prior
         RTP-Info:url="rtsp://example.com/audio"
            ssrc=0D12F123:seq=14783;rtptime=2345962545

   S->C: RTP Packet TS=2345962545 => NPT=3.52
         Duration=4.15 seconds

   After playing the media streams has been reached or will be in desired range, the near future for presentation does NOT transition
   to the given session aggregate.  The READY state, media delivery simply stops.  A PAUSE request SHALL
   NOT
   MUST be issued unless before the server is in stream enters the playing READY state.  The end of  A PLAY
   request while the media stream delivery notification may is still in the PLAYING state is legal, and
   can be for either succesful
   completion of issued without an intervening PAUSE request.  Such a request
   MUST replace the current PLAY request currently action with the new one requested, i.e.
   being served or indicate
   some error resulting handle the same as the request was received in failure to complete ready state.  In
   the request.  The
   Request-Status case the range in Range header (Section 16.41) SHALL be included has a implicit start time
   (-endtime), the server MUST continue to indicate
   which request play from where it currently
   was until the notification specified end point.  This is for and its completion status. useful to change end at
   another point than in the previous request.

   The
   message response status codes (Section 8.1.1) are used following example plays the whole presentation starting at SMPTE
   time code 0:10:20 until the end of the clip.  Note: The RTP-Info
   headers has been broken into several lines to indicate
   how fit the page.

   C->S: PLAY request concluded.  In case rtsp://audio.example.com/twister.en RTSP/2.0
         CSeq: 833
         Session: 12345678
         Range: smpte=0:10:20-
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 833
         Date: Thu, 23 Jan 1997 15:35:06 GMT
         Server: PhonyServer 1.0
         Range: smpte=0:10:22-0:15:45
         Seek-Style: Next
         RTP-Info:url="rtsp://example.com/twister.en"
            ssrc=0D12F123:seq=14783;rtptime=2345962545

   For playing back a PLAY_NOTIFY was issues
   prior recording of a live presentation, it may be
   desirable to the actual completion use clock units:
   C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0
         CSeq: 835
         Session: 12345678
         Range: clock=19961108T142300Z-19961108T143520Z
         User-Agent: PhonyClient/1.2

   S->C: RTSP/2.0 200 OK
         CSeq: 835
         Date: Thu, 23 Jan 1997 15:35:06 GMT
         Server: PhonyServer 1.0
         Range: clock=19961108T142300Z-19961108T143520Z
         Seek-Style: Next
         RTP-Info:url="rtsp://example.com/meeting.en"
            ssrc=0D12F123:seq=53745;rtptime=484589019

13.4.2.  Aggregated Sessions

   PLAY requests can operate on sessions controlling a single media and some
   on aggregated sessions controlling multiple media.

   In an aggregated session the PLAY request MUST contain an aggregated
   control URI.  A server MUST response with error occured resulting in
   that 460 (Only Aggregate
   Operation Allowed) if the previosuly sent was client PLAY Request-URI is for one of the
   media.  The media in error a new Notification an aggregate MUST be sent
   including played in sync.  If a
   client wants individual control of the correct status media it needs to use separate
   RTSP sessions for each media.

   For aggregated sessions where the completion and all initial SETUP request (creating a
   session) is followed by one or more additional
   information.

   PLAY_NOTIFY SETUP request, a PLAY
   request MAY be pipelined after those additional SETUP requests
   without awaiting their responses.  This procedure can reduce the
   delay from start of session establishment until media play-out has
   started with Notify-Reason header set to end-of-stream
   MUST include one round trip time.  However, a Range header.  The Range header indicates the point client needs to be
   aware that using this procedure will result in the stream or streams where delivery was/are ending with playout of the
   timescale that has been used by
   server state established at the client in time of processing the PLAY, i.e.,
   after the processing of all the requests prior to the PLAY request being
   fulfilled.  For normal play time it is in
   the pipeline.  This may not alllowed be the intended one due to use "now" as
   server do know failure of any
   of the real ending time prior requests.  However a client easily determine this based
   on the responses from those requests.  In case of failure the client
   can halt the media stream playout using PAUSE and now
   carries no information to determine what has/will be delivered.  When
   end-of-stream notifications are issued prior try to having sent establish the last
   media packets, this is evident as
   intended state again before issuing another PLAY request.

13.4.3.  Updating current PLAY Requests

   Clients can issue PLAY request while the end time stream is in the Range header PLAYING state
   and thus updating their request.

   The important difference compared to a PLAY request in ready state is
   beyond
   the handling of the current time in play point and how the range header in
   request is constructed.  The session is actively playing media being received by and
   the client,
   e.g., npt=-15, if npt is currently at 14.2 seconds.

   If RTP is used as media transport, a RTP-Info header MUST play point will be
   included, and moving making the RTP-Info exact time a request will
   take action is hard to predict.  Depending on how the PLAY header MUST indicate
   appears two different cases exist: total replacement or continuation.
   A total replacement is signalled by having the last sequence
   number first range
   specification have an explicit start value, e.g. npt=45- or
   npt=45-60, in which case the seq parameter.

   A PLAY_NOTIFY request with Notify-Reason header set server stops playout at the current
   playout point and then starts delivering media according to end-of-stream
   MUST NOT carry a message body. the Range
   header.  This example request notifies is equivalent to having the client about first send a future end-of-stream
   event:

     S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 854
           Notify-Reason: end-of-stream
           Request-Status: cseq=853 status=200 reason="OK"
           Range: npt=-145
           RTP-Info:url="rtsp://example.com/audio"
              ssrc=0D12F123:seq=14783;rtptime=2345962545
           Session: uZ3ci0K+Ld-M

     C->S: RTSP/2.0 200 OK
           CSeq: 854
           User-Agent: PhonyClient/1.2

13.5.2.  Media-Properties-Update

   A PLAY_NOTIFY PAUSE
   and then a new play request with Notify-Reason header set to media-
   properties-update indicates an update of that isn't based on the media properties for pause point.  In
   the
   given session (see Section 16.29) and/or case of continuation the available media first range
   that can be played as indicated by Media-Range (Section 16.30).
   PLAY_NOTIFY requests with Notify-Reason header set to media-
   properties-update MUST include a Media-Properties and Date header specifier has an implicit
   start point and
   SHOULD include a Media-Range header.

   This notification SHALL be sent for media that are time-progressing
   every time a event happens explicit stop value (Z), e.g. npt=-60, which
   indicate that changes the basis for making
   estimations on how it MUST convert the media range progress.  In addition it is
   RECOMMENDED that specifier being played prior
   to this PLAY request (X to Y) into (X to Z) and continue as this was
   the request originally played.

   An example of this behavior.  The server sends these notification every 5 minutes
   for time-progressing content has received requests to ensure
   play ranges 10 to 15.  If the long term stability of new PLAY request arrives at the
   client estimation and allowing for clock skew detection by server
   4 seconds after the
   client.  Requests for previous one, it will take effect while the just mentioned reasons SHALL include Media-
   Range header to provide current Media duration and
   server still plays the Range header
   to indicate first range (10-15).  Thus changing the current playing point and any remaining parts
   behavior of this range to continue to play to 25 seconds, i.e. the
   requsted range.

   A PLAY_NOTIFY
   equivalent single request would be PLAY with Notify-Reason header set to media-
   properties-update MUST NOT carry a message body.

     S->C: PLAY_NOTIFY range: npt=10-25.

     C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
           Date: Tue, 14 Apr 2008 15:48:06 GMT
           CSeq: 854
           Notify-Reason: media-properties-update 834
           Session: uZ3ci0K+Ld-M
           Media-Properties: Time-Progressing,
                 Time-Limited=20080415T153919.36Z, Random-Access=5.0
           Media-Range: npt=0-1:37:21.394 12345678
           Range: npt=1:15:49.873-

     C->S: npt=10-15
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 854 834
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer 1.0
           Range: npt=10-15
           Seek-Style: Next
           RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=5712;rtptime=934207921,
                   url="rtsp://example.com/fizzle/videotrack"
                   ssrc=789DAF12:seq=57654;rtptime=2792482193
           Session: 12345678

     C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 835
           Session: 12345678
           Range: npt=-25
           User-Agent: PhonyClient/1.2

13.5.3.  Scale-Change

   When a client request playback at Scale (Section 16.44) values other
   than

     S->C: RTSP/2.0 200 OK
           CSeq: 835
           Date: Thu, 23 Jan 1997 15:35:09 GMT
           Server: PhonyServer 1.0 (Normal playback rate) then the server may be forced to
   changed the rate.  For time progressing
           Range: npt=14-25
           Seek-Style: Next
           RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=5712;rtptime=934239921,
                   url="rtsp://example.com/fizzle/videotrack"
                   ssrc=789DAF12:seq=57654;rtptime=2792842193
           Session: 12345678

13.4.4.  Playing On-Demand Media

   On-demand media with some retention,
   i.e. is indicated by the server stores already sent content, a client requesting to
   play with Scale values larger than 1 may catch up with front end content of the media.  The server will be unable to continue provide content at
   Scale larger than 1 as content only made available by Media-Properties
   header in the server at
   Scale=1.  Another case SETUP response by (see also Section 16.28):

   o  Random-Access property is when Scale < 1 and the set to Random Access;

   o  Content Modifications set to Immutable;

   o  Retention set Unlimited or Time-Limited.

   Playing on-demand media retention is
   time_duration limited.  In this case the playback point can reach the follows the oldest media unit available, and further playback at this scale
   becomes impossible general usage as there will be no described in
   Section 13.4.1.

13.4.5.  Playing Dynamic On-Demand Media

   Dynamic on-demand media available.  To avoid
   having is indicated by the client loose any media, content of the scale will need Media-
   Properties header in the SETUP response by (see also Section 16.28):

   o  Random-Access set to be adjusted Random Access;

   o  Content Modifications set to the same rate which the dynamic;

   o  Retention set Unlimited or Time-Limited.

   Playing on-demand media is removed from follows the storage buffer,
   commonly scale=1.0.

   To minimize impact on playback general usage as described in any of the above cases
   Section 13.4.1 as long as the server
   SHALL modify media has not been changed.

   There are ways for the playback properties and set Scale client to a supportable
   value (commonly 1.0) and continue delivery get informed about changed of media
   resources in play state, if the media.  When doing
   this modification it MUST send resource was changed.  The client
   will receive a PLAY_NOTIFY message request with the Notify-
   Reason Notify-Reason header set to "Scale-Change".
   media-properties-update (see Section 13.5.2.  The request SHALL contain a
   Range header with client can use the media time where
   value of the change took effect, a
   Scale header with Media-Range to decide further actions, if the new value in use, Session Media-
   Range header with is present in the ID
   for PLAY_NOTIFY request.  The second way
   is that the session it applies to and client issues a Date header with GET_PARAMETER request without a body but
   including a Media-Range header.  The 200 OK response MUST include the server wall
   clock time of
   current Media-Range header (see Section 16.29).

13.4.6.  Playing Live Media

   Live media is indicated by the change.  For time progressing content also the
   Media-Range and of the Media-Properties at this point in time SHALL be
   included.

   For media streams being delivered using RTP also a RTP-Info header
   SHALL be included.  It MUST contain
   in the rtptime parameter SETUP response by (see also Section 16.28):

   o  Random-Access set to no-seeking;

   o  Content Modifications set to Time-Progressing;

   o  Retention with a
   value corresponding Time-Duration set to 0.0.

   For live media, the point of change in that media and
   optionally SETUP response 200 OK MUST include the sequence number. Media-
   Range header (see Section 16.29).

   A PLAY_NOTIFY client MAY send PLAY requests without the Range header, if the
   request with Notify-Reason include the Range header set to "Scale-Change" it MUST NOT carry use a message body.

     S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
           Date: Tue, 14 Apr 2008 15:48:06 GMT
           CSeq: 854
           Notify-Reason: scale-change
           Session: uZ3ci0K+Ld-M
           Media-Properties: Time-Progressing,
                 Time-Limited=20080415T153919.36Z, Random-Access=5.0
           Media-Range: npt=0-1:37:21.394
           Range: npt=1:37:21.394-
           Scale: 1
           RTP-Info: url="rtsp://example.com/fizzle/foo/audio"
               ssrc=0D12F123:rtptime=2345962545

     C->S: RTSP/2.0 200 OK
           CSeq: 854
           User-Agent: PhonyClient/1.2

13.6.  PAUSE symbolic value
   representing "now".  For NPT that range specification is "npt=now-".
   The PAUSE request causes the stream delivery to immediately be
   interrupted (halted).  A PAUSE request server MUST be done either with include the
   aggregated control URI for aggregated sessions, resulting Range header in all
   media being halted, or the media URI for non-aggregated sessions.
   Any attempt to do muting of a single media with response and it MUST
   indicate an PAUSE request explicit time value and not a symbolic value.  In other
   words npt=now- is not a valid to use in
   an aggregated the response.  Instead the
   time since session SHALL start is recommended expressed as an open
   interval, e.g. "npt=96.23-".  An absolute time value (clock) for the
   corresponding time MAY be responded given, i.e. "clock=20030213T143205Z-".  The
   UTC clock format can only be used if client has shown support for it
   using the Accept-Ranges header.

13.4.7.  Playing Live with error 460 (Only
   Aggregate Operation Allowed).  After resuming playback,
   synchronization Recording

   Certain media server may offer recording services of the tracks MUST live sessions to
   their clients.  This recording would normally be maintained.  Any server
   resources are kept, though servers MAY close from the session beginning
   of the media session.  Clients can randomly access the media between
   now and free
   resources after being paused for the duration specified beginning of the media session.  This live media with
   recording is indicated by the
   timeout parameter content of the Session Media-Properties header
   in the SETUP message.

   Example:

     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 834
           Session: 12345678
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 response by (see also Section 16.28):

   o  Random-Access set to random-access;

   o  Content Modifications set to Time-Progressing;

   o  Retention set to Time-limited or Unlimited

   The SETUP response 200 OK
           CSeq: 834
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Range: npt=45.76-

   The PAUSE request causes stream delivery to be interrupted
   immediately on receipt MUST include the Media-Range header (see
   Section 16.29) for this type of media.  For live media with recording
   the message Range header indicates the current playback time in the media and
   the pause point is set to Media-Range header indicates the currently available media window
   around the current point time.  This window can cover recorded content in
   the presentation.  That pause point past (seen from current time in the media
   stream needs to be maintained.  A subsequent PLAY request without
   Range header SHALL resume media) or recorded content in
   the future (seen from current time in the pause point and play until media
   end. media).  The pause server adjusts
   the play point after any PAUSE request SHALL be returned to the
   client by adding a Range header with what remains unplayed requested border of the
   PLAY request's ranges, i.e. including all window, if the remaining ranges part
   of multiple range specification.  For media with random access
   properties If one desires to resume playing client
   requests a ranged request, one
   simply includes the Range header from play point that is located outside the PAUSE response.  Any play-
   request including symbolic values, such as recording windows,
   e.g., if requested to far in the NPT timescale's "now"
   MUST be resolved into past, the actual stream position where server selects the pause
   point is.  For example a Play request with a oldest
   range specification of
   "npt=now-" will need to be responded with an explicit value such as
   "npt=157.321-".  For media that is time-progressing and has retention
   duration=0 the follow-up PLAY request to start media delivery again,
   will need to use "npt=now-" and not the answer in the pause-respone.
     C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 834
           Session: 12345678
           Range: npt=10-30
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 834
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer 1.0
           Range: npt=10-30
           RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=5712;rtptime=934207921,
                   url="rtsp://example.com/fizzle/videotrack"
                   ssrc=4FAD8726:seq=57654;rtptime=2792482193
           Session: 12345678

   After 11 seconds, i.e. recording.  The considerations in Section 13.5.3 apply,
   if a client requests playback at 21 seconds into the presentation:
     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 835
           Session: 12345678
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 835
           Date: 23 Jan 1997 15:35:09 GMT
           Server: PhonyServer Scale (Section 16.44) values other
   than 1.0
           Range: npt=21-30
           Session: 12345678
   If (Normal playback rate) while playing live media with
   recording.

13.4.8.  Playing Live with Time-Shift

   Certain media server may offer time-shift services to their clients.
   This time shift records a client issues fixed interval in the past, i.e., a PAUSE request and sliding
   window recording mechanism, but not past this interval.  Clients can
   randomly access the server acknowledges media between now and
   enters the READY state, interval.  This live
   media with recording is indicated by the proper server response, if content of the player
   issues another PAUSE, is still 200 OK. Media-
   Properties header in the SETUP response by (see also Section 16.28):

   o  Random-Access set to random-access;

   o  Content Modifications set to Time-Progressing;
   o  Retention set to Time-Duration and a value indicating the
      recording interval (>0).

   The SETUP response 200 OK response MUST include the Range Media-Range header (see
   Section 16.29) for this type of media.  For live media with recording
   the current pause point.  See examples
   below:

     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 834
           Session: 12345678
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 834
           Session: 12345678
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Range: npt=45.76-98.36

     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 835
           Session: 12345678
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 835
           Session: 12345678
           Date: 23 Jan 1997 15:35:07 GMT
           Range: npt=45.76-98.36

13.7.  TEARDOWN

   The TEARDOWN client to server request stops Range header indicates the stream delivery for current time in the given URI, freeing media and the resources associated with it.  A TEARDOWN
   request MAY be performed on either an aggregated or
   Media Range indicates a media control
   URI.  However some restrictions apply depending on window around the current state.
   The TEARDOWN request SHALL contain a Session header indicating what
   session time.  This window
   can cover recorded content in the request applies to.

   A TEARDOWN using past (seen from current time in the aggregated control URI
   media) or recorded content in the media URI future (seen from current time in
   the media).  The server adjusts the play point to the requested
   border of the window, if the client requests a
   session under non-aggregated control (single media session) MAY be
   done in any state (Ready, and Play).  A successful request SHALL
   result in play point that media delivery is immediately halted and
   located outside the session
   state is destroyed.  This SHALL be indicated through recording windows, e.g., if requested too far in
   the lack of a
   Session header past, the server selects the oldest range in the response.

   A TEARDOWN using a media URI recording.  The
   considerations in an aggregated session MAY only be
   done in Ready state.  Such Section 13.5.3 apply, if a request only removes the indicated client requests playback
   at Scale (Section 16.44) values other than 1.0 (Normal playback rate)
   while playing live media
   stream and associated resources from the session.  This may result in
   that with time-shift.

13.5.  PLAY_NOTIFY

   The PLAY_NOTIFY method is issued by a session returns to non-aggregated control, due server to that it only
   contains inform a client about
   an asynchronously event for a single media after the requests completion.  A session
   that will exist after in play state.  The Session
   header MUST be presented in a PLAY_NOTIFY request and indicates the processing
   scope of the TEARDOWN request SHALL in request.  Sending of PLAY_NOTIFY requests requires a
   persistent connection between server and client, otherwise there is
   no way for the response server to that TEARDOWN send this request contain a Session header.  Thus method to the presence of client.

   PLAY_NOTIFY requests have an end-to-end (i.e. server to client)
   scope, as they carry the Session header indicates header, and apply only to the receiver of the given
   session.  The client SHOULD immediately return a response if to the session is still existing or has been removed.

   Example:

     C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 892
           Session: 12345678
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 892
           Server: PhonyServer 1.0

13.8.  GET_PARAMETER

   The GET_PARAMETER request retrieves
   server.

   PLAY_NOTIFY requests MAY be used with a message body, depending on
   the value of any specified
   parameter or parameters for a presentation or stream specified in the
   URI.  If the Session header Notify-Reason header.  It is present described in a request, the value of
   particular section for each Notify-Reason if a
   parameter MUST be retrieved in the specified session context.  There
   exist two ways of specifying the parameters to retrive.  The first message body is
   by including headers that has been defined such used.
   However, currently there is no Notify-Reason that you can use them
   for this purpose.  Header for allows using a
   message body.  There is in this purpose should allow empty, or
   stripped value parts to avoid having case a need to specify bogus data obey some limitations
   when
   indicating the desire adding new Notify-Reasons that intend to retrive use a value. message body: The succesful completion
   server can send any type of message body, but it is not ensured that
   the request should also be evident from any filled out values in client can understand the response.  The Media-Range header (Section 16.30) is one such
   header.  The other received message body.  This is related
   to specify a body (entity) that lists DESCRIBE (seeSection 13.2 ), but in this particular case the
   parameter(s) that
   client can state its acceptable message bodies by using the Accept
   header.  In the case of PLAY_NOTIFY, the server does not know which
   message bodies are desirable to retrieve. understood by the client.

   The Content-Type Notify-Reason header
   (Section 16.18) is used to specify which format (see Section 16.31) specifies the entity has.

   The method reason why
   the server sends the PLAY_NOTIFY request.  This is extensible and new
   reasons MAY also be used without a body (entity) or any header
   that request parameters for keep-alive purpose.  Any request that is
   successful, i.e., a 200 OK response is received, then the keep-alive
   timer has been updated.  Any non-required header present added in such a
   request may or may not been processed.  Normaly the presence of
   filled out values in future.  In case the header will be indication that client does not
   understand the header
   has been processed.  However, reason for cases when this is difficult to
   determine, the notification it is recommended MUST respond with an
   465 (Notification Reason Unknown) (Section 15.4.30) error code.
   Servers can send PLAY_NOTIFY with these types:

   o  end-of-stream (see Section 13.5.1);

   o  media-properties-update (see Section 13.5.2);

   o  scale-change (see Section 13.5.3).

13.5.1.  End-of-Stream

   A PLAY_NOTIFY request with Notify-Reason header set to use a feature-tag end-of-stream
   indicates the completion or near completion of the PLAY request and
   the Require
   header.  Due to this reason it is usually easier if any parameters to ending delivery of the media stream(s).  The request MUST NOT be retrieved are sent in
   issued unless the body, rather than using any header.

   Parameters specified within server is in the body playing state.  The end of the message must all
   media stream delivery notification may be
   understood by used to indicate either a
   successful completion of the PLAY request receiving agent.  If one currently being served, or more parameters
   are not understood a 451 (Parameter Not Understood) SHALL
   to indicate some error resulting in failure to complete the request.
   The Request-Status header (Section 16.41) MUST be sent
   including a body listing these parameters that wasn't understood.  If
   all parameters are understood their value included to
   indicate which request the notification is filled in for and returned
   in the response its completion
   status.  The message body.

   Example:

     S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 431
           Content-Type: text/parameters
           Session: 12345678
           Content-Length: 26
           User-Agent: PhonyClient/1.2

           packets_received
           jitter

     C->S: RTSP/2.0 200 OK
           CSeq: 431
           Content-Length: 38
           Content-Type: text/parameters

           packets_received: 10
           jitter: 0.3838

13.9.  SET_PARAMETER

   This method requests response status codes (Section 8.1.1) are used
   to set indicate how the value PLAY request concluded.  The sender of a parameter or a set
   PALY_NOTIFY can issue an updated PALY_NOTIFY, in the case of
   parameters for a presentation or stream specified by the URI.  The
   method MAY also be used without
   PLAY_NOTIFY sent with wrong information.  For instance, a body (entity).  It is PLAY_NOTIFY
   was issued before reaching the
   RECOMMENDED method to use end-of-stream, but some error occurred
   resulting in request sent for that the sole purpose of
   updating previously sent PLAY_NOTIFY contained a wrong
   time when the keep-alive timer.  If stream will end.  In this request is successful, i.e. case a
   200 OK response is received, then new PLAY_NOTIFY MUST
   be sent including the keep-alive timer has been
   updated.  Any non-required header present in such a request may or
   may not been processed.  To allow a client to determine if any such correct status for the completion and all
   additional information.

   PLAY_NOTIFY requests with Notify-Reason header has been processed, it is necessary set to use end-of-stream
   MUST include a feature tag Range header and the Require header.  Due to this reason it Scale header if the scale value
   is RECOMMENDED that any
   parameters are sent not 1.  The Range header indicates the point in the body, rather than using any header.

   A request stream or
   streams where delivery is RECOMMENDED to only contain a single parameter to allow ending with the client to determine why a particular request failed.  If timescale that was used by
   the
   request contains several parameters, server in the PLAY response for the request being fulfilled.  The
   server MUST only act on NOT use the
   request if all of the parameters can be set successfully.  A server
   MUST allow a parameter to be set repeatedly to "now" constant in the same value, but Range header; it
   MAY disallow changing parameter values.  If MUST
   use the receiver of actual numeric end position in the
   request does not understand or cannot locate a parameter, error 451
   (Parameter Not Understood) SHALL be used.  In proper timescale.  When
   end-of-stream notifications are issued prior to having sent the case a parameter last
   media packets, this is
   not allowed to change, evident as the error code end time in the Range header is 458 (Parameter Is Read-
   Only).  The response body SHALL contain only
   beyond the parameters that have
   errors.  Otherwise no body SHALL be returned.

   Note: transport parameters for current time in the media stream MUST only be set with being received by the SETUP command.

      Restricting setting transport parameters to SETUP client,
   e.g., npt=-15, if npt is for the
      benefit of firewalls. currently at 14.2 seconds.  The parameters are split in a fine-grained fashion Scale header
   is to be included so that there
      can be more meaningful error indications.  However, it may make
      sense to allow the setting of several parameters is evident if an atomic
      setting the media time scale is desirable.  Imagine device control where
   moving backwards and/or have a non-default pace.

   If RTP is used as media transport, a RTP-Info header MUST be
   included, and the client
      does not want RTP-Info header MUST indicate the camera to pan unless it can also tilt to last sequence
   number in the
      right angle at seq parameter.

   A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream
   MUST NOT carry a message body.

   This example request notifies the same time.

   Example:

     C->S: SET_PARAMETER client about a future end-of-stream
   event:

     S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 421
           User-Agent: PhonyClient/1.2
           Content-length: 20
           Content-type: text/parameters

           barparam: barstuff

     S->C: 854
           Notify-Reason: end-of-stream
           Request-Status: cseq=853 status=200 reason="OK"
           Range: npt=-145
           RTP-Info:url="rtsp://example.com/audio"
              ssrc=0D12F123:seq=14783;rtptime=2345962545
           Session: uZ3ci0K+Ld-M

     C->S: RTSP/2.0 451 Parameter Not Understood 200 OK
           CSeq: 421
           Content-length: 10
           Content-type: text/parameters

           barparam: barstuff

13.10.  REDIRECT

   The REDIRECT method is issued 854
           User-Agent: PhonyClient/1.2

13.5.2.  Media-Properties-Update

   A PLAY_NOTIFY request with Notify-Reason header set to media-
   properties-update indicates an update of the media properties for the
   given session (see Section 16.28) and/or the available media range
   that can be played as indicated by a server Media-Range (Section 16.29).
   PLAY_NOTIFY requests with Notify-Reason header set to inform media-
   properties-update MUST include a client Media-Properties and Date header and
   SHOULD include a Media-Range header.

   This notification MUST be sent for media that it
   required to connect to another server location to access are time-progressing
   every time an event happens that changes the resource
   indicated by basis for making
   estimations on how the Request-URI.  The presence of media range progress.  In addition it is
   RECOMMENDED that the Session header in
   a REDIRECT request indicates server sends these notifications every 5 minutes
   for time-progressing content to ensure the scope long term stability of the request,
   client estimation and determines allowing for clock skew detection by the specific semantics of
   client.  Requests for the request.

   A REDIRECT request with a Session just mentioned reasons MUST include Media-
   Range header has end-to-end (i.e. server to client) scope provide current Media duration and applies only to the given session.  Any
   intervening proxies SHOULD NOT disconnect Range header
   to indicate the control channel while
   there are other current playing point and any remaining end-to-end sessions. parts of the
   requested range.

      The OPTIONAL Location
   header, if included in such a request, SHALL contain a complete
   absolute URI pointing recommendation for sending updates every 5 minutes is due to
      any clock skew issues.  In 5 minutes the resource to clock skew should not
      become too significant as this is not used for media playback and
      synchronization, only for determining which content is available
      to the client SHOULD
   reconnect.  Specifically, the Location SHALL NOT contain just the
   host and port. user.

   A client may receive a REDIRECT PLAY_NOTIFY request with Notify-Reason header set to media-
   properties-update MUST NOT carry a
   Session header, if and only if, an end-to-end session has been
   established.

   A client message body.

     S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
           Date: Tue, 14 Apr 2008 15:48:06 GMT
           CSeq: 854
           Notify-Reason: media-properties-update
           Session: uZ3ci0K+Ld-M
           Media-Properties: Time-Progressing,
                 Time-Limited=20080415T153919.36Z, Random-Access=5.0
           Media-Range: npt=0-1:37:21.394
           Range: npt=1:15:49.873-

     C->S: RTSP/2.0 200 OK
           CSeq: 854
           User-Agent: PhonyClient/1.2

13.5.3.  Scale-Change

   The server may receive be forced to change the rate, when a REDIRECT client request without a Session header
   playback at
   any Scale (Section 16.44) values other than 1.0 (normal
   playback rate).  For time when it has communication or a connection established progressing media with some retention, i.e.
   the server stores already sent content, a
   server.  The scope of such a request is limited client requesting to the next-hop (i.e.
   the RTSP agent in direct communication play
   with Scale values larger than 1 may catch up with the server) and applies,
   as well, to the control connection between the next-hop RTSP agent
   and the server.  A REDIRECT request without a Session header
   indicates that all sessions and pending requests being managed via front end of
   the control connection MUST be redirected. media.  The OPTIONAL Location
   header, if included in such a request, SHOULD contain an absolute URI server will then be unable to continue to provide
   with content at Scale larger than 1 as content is only made available
   by the host address server at Scale=1.  Another case is when Scale < 1 and the OPTIONAL port number of
   media retention is time-duration limited.  In this case the server
   to which playback
   point can reach the RTSP agent SHOULD reconnect.  Any intervening proxies
   SHOULD do all of oldest media unit available, and further playback
   at this scale becomes impossible as there will be no media available.
   To avoid having the following in client loose any media, the order listed:

   1.  respond scale will need to the REDIRECT request

   2.  disconnect the control channel from the requesting server

   3.  connect be
   adjusted to the server at the given host address

   4.  pass same rate which the REDIRECT request to each applicable client (typically
       those clients with an active session or an unanswered request)

      Note: The proxy media is responsible for accepting REDIRECT responses removed from its clients; these responses MUST NOT be passed on to either the original server or storage
   buffer, commonly scale = 1.0.

   Another case is when the redirected server.

   The lack content itself consist of a Location header in any REDIRECT request spliced pieces or
   is indicative
   of dynamically updated.  In these cases the server no longer being able may be required to fulfill
   change from one supported scale value (different than Scale=1.0) to
   another.  In this case the current request server will pick the closest value and
   having no alternatives for
   inform the client to continue with its normal
   operation.  It is akin to a server initiated TEARDOWN that applies
   both to sessions as well as of what it has picked.  In these case the general connection associated with
   that client.

   When media
   properties will also be sent updating the Range header is not included in supported Scale values.
   This enables a REDIRECT request, the client SHOULD perform the redirection immediately and return a
   response to adjust the server.  The server can consider the session as
   terminated and can free used Scale value.

   To minimize impact on playback in any associated state after it receives of the
   successful (2xx) response.  The server MAY close above cases the signalling
   connection upon receiving server
   MUST modify the response playback properties and the client SHOULD close
   the signalling connection after sending the 2xx response.  The
   exception set Scale to this is when the client has several sessions on the
   server being managed by a supportable
   value and continue delivery the given signalling connection.  In media.  When doing this
   case, the client SHOULD close the connection when modification
   it has received and
   responded to REDIRECT requests for all the sessions managed by the
   signalling connection.

   If the OPTIONAL Range header is included in MUST send a REDIRECT request, it
   indicates when PLAY_NOTIFY message with the redirection takes effect. Notify-Reason header set
   to "scale-change".  The range value request MUST be
   an open ended single value, e.g. npt=59-, indicating contain a Range header with the play out
   media time when redirection SHALL occur.  Alternatively, where the change took effect, a range Scale header with the new
   value in use, Session header with the ID for the session it applies
   to and a
   time= parameter indicates Date header with the wall clock server wallclock time by when of the redirection
   MUST take place.  When change.
   For time progressing content also the time= parameter is present in Media-Range and the range,
   any range value Media-
   Properties at this point in time MUST be ignored even though it included.  The Media-
   Properties header MUST be syntactically
   correct.  To allow a client included if the scale change was due to determine the
   content changing what scale values that redirect time without is supported.

   For media streams being time synchronized with the server, the server SHALL include delivered using RTP also a
   Date RTP-Info header in
   MUST be included.  It MUST contain the request.  When rtptime parameter with a value
   corresponding to the indicated redirect point is
   reached, a client MUST issue a TEARDOWN request of change in that media and SHOULD close optionally
   also the
   signalling connection after receiving sequence number.

   A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change"
   MUST NOT carry a 2xx response. message body.

     S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
           Date: Tue, 14 Apr 2008 15:48:06 GMT
           CSeq: 854
           Notify-Reason: scale-change
           Session: uZ3ci0K+Ld-M
           Media-Properties: Time-Progressing,
                 Time-Limited=20080415T153919.36Z, Random-Access=5.0
           Media-Range: npt=0-1:37:21.394
           Range: npt=1:37:21.394-
           Scale: 1
           RTP-Info: url="rtsp://example.com/fizzle/foo/audio"
               ssrc=0D12F123:rtptime=2345962545

     C->S: RTSP/2.0 200 OK
           CSeq: 854
           User-Agent: PhonyClient/1.2

13.6.  PAUSE

   The normal
   connection considerations apply for PAUSE request causes the server.

      The differentiation of REDIRECT requests with and without range
      headers is stream delivery to allow for clear and explicit state handling.  As immediately be
   interrupted (halted).  A PAUSE request MUST be done either with the
      state
   aggregated control URI for aggregated sessions, resulting in all
   media being halted, or the server needs media URI for non-aggregated sessions.
   Any attempt to be kept until the point do muting of
      redirection, the handling becomes more clear if the client is
      required to TEARDOWN the session at the redirect point.

   If the REDIRECT a single media with an PAUSE request times out following the rules in Section 10.4
   an aggregated session MUST be responded with error 460 (Only
   Aggregate Operation Allowed).  After resuming playback,
   synchronization of the tracks MUST be maintained.  Any server
   resources are kept, though servers MAY terminate close the session or transport connection that
   would be redirected by and free
   resources after being paused for the request.  This is a safeguard against
   misbehaving clients that refuses to respond to a REDIRECT request.
   That should not provide any benefit.

   After a REDIRECT duration specified with the
   timeout parameter of the Session header in the SETUP message.

   Example:

     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 834
           Session: 12345678
          User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 834
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Range: npt=45.76-

   The PAUSE request has been processed, a client that wants to
   continue causes stream delivery to send or receive media for be interrupted
   immediately on receipt of the resource identified by message and the
   Request-URI will have pause point is set to establish a new session with the designated
   host.  If
   the URI given current point in the Location header is a valid resource
   URI, a client SHOULD issue a DESCRIBE request for presentation.  That pause point in the URI.

      Note: The media resource indicated by the Location header can
   stream needs to be
      identical, slightly different or totally different.  This is maintained.  A subsequent PLAY request without
   Range header resume from the
      reason why a new DESCRIBE pause point and play until media end.

   The pause point after any PAUSE request SHOULD MUST be issued.

   If the Location header contains only a host address, returned to the
   client MAY
   assume that by adding a Range header with what remains unplayed of the
   PLAY request's range.  For media on the new server is identical with random access properties, if
   one desires to resume playing a ranged request, one simply includes
   the media on
   the old server, i.e. all media configuration information Range header from the old
   session is still valid except for PAUSE response and include the host address.  However Seek-Style
   header with the
   usage of conditional SETUP using ETag identifiers are RECOMMENDED to
   verify Next policy in the assumption.

   This example PLAY request.  For media that is
   time-progressing and has retention duration=0 the follow-up PLAY
   request redirects traffic for this session to start media delivery again, will need to use "npt=now-"
   and not the new
   server at answer in the given absolute time:

     S->C: REDIRECT pause-response.

     C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 732
           Location: rtsp://s2.example.com:8001
           Range: npt=0- ;time=19960213T143205Z 834
           Session: uZ3ci0K+Ld-M

     C->S: 12345678
           Range: npt=10-30
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 732 834
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Server: PhonyServer 1.0
           Range: npt=10-30
           Seek-Style: First-Prior
           RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
                   ssrc=0D12F123:seq=5712;rtptime=934207921,
                   url="rtsp://example.com/fizzle/videotrack"
                   ssrc=4FAD8726:seq=57654;rtptime=2792482193
           Session: 12345678

   After 11 seconds, i.e. at 21 seconds into the presentation:
     C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 835
           Session: 12345678
           User-Agent: PhonyClient/1.2

14.  Embedded (Interleaved) Binary Data

   In order to fulfill certain requirements on

     S->C: RTSP/2.0 200 OK
           CSeq: 835
           Date: 23 Jan 1997 15:35:09 GMT
           Server: PhonyServer 1.0
           Range: npt=21-30
           Session: 12345678

   If a client issues a PAUSE request and the network side, e.g. in
   conjunction with network address translators that block RTP traffic
   over UDP, it may be necessary to interleave RTSP messages and media
   stream data.  This interleaving should generally be avoided unless
   necessary since it complicates client and server operation acknowledges and
   imposes additional overhead.  Also head of line blocking may cause
   problems.  Interleaved binary data SHOULD only be used if RTSP is
   carried over TCP.

   Stream data such as RTP packets is encapsulated by an ASCII dollar
   sign (24 decimal), followed by a one-byte channel identifier,
   followed by the length of the encapsulated binary data as a binary,
   two-byte integer in network byte order.  The stream data follows
   immediately afterwards, without a CRLF, but including the upper-layer
   protocol headers.  Each $ block SHALL contain exactly one upper-layer
   protocol data unit, e.g., one RTP packet.
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | "$" = 24      | Channel ID    | Length in bytes               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      : Length number of bytes of binary data                         :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The channel identifier is defined in the Transport header with the
   interleaved parameter (Section 16.51).

   When
   enters the transport choice is RTP, RTCP messages are also interleaved
   by READY state, the proper server over the TCP connection.  The usage of RTCP messages is
   indicated by including a range containing a second channel in the
   interleaved parameter of response, if the Transport header, see Section 16.51.  If
   RTCP player
   issues another PAUSE, is used, packets SHALL be sent on the first available channel
   higher than the RTP channel. still 200 OK.  The channels are bi-directional and
   therefore RTCP traffic are sent on the second channel in both
   directions.

      RTCP is sometime needed for synchronization when two or more
      streams are interleaved in such a fashion.  Also, this provides a
      convenient way to tunnel RTP/RTCP packets through 200 OK response MUST
   include the TCP control
      connection when required by Range header with the network configuration and transfer
      them onto UDP when possible. current pause point.  See examples
   below:

     C->S: SETUP rtsp://example.com/bar.file PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 2
           Transport: RTP/AVP/TCP;unicast;interleaved=0-1
           Accept-Ranges: NPT, SMPTE, UTC 834
           Session: 12345678
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 2 834
           Session: 12345678
           Date: Thu, 05 Jun 23 Jan 1997 18:57:18 15:35:06 GMT
           Transport: RTP/AVP/TCP;unicast;interleaved=5-6
           Session: 12345678
           Accept-Ranges: NPT
           Range: npt=45.76-98.36

     C->S: PLAY rtsp://example.com/bar.file PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 3 835
           Session: 12345678
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 3 835
           Session: 12345678
           Date: Thu, 05 Jun 23 Jan 1997 18:59:15 15:35:07 GMT
           RTP-Info: url="rtsp://example.com/bar.file"
             ssrc=0D12F123:seq=232433;rtptime=972948234
           Range: npt=0-56.8

     S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
     S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
     S->C: $006{2 byte length}{"length" bytes  RTCP packet}

15.  Status Code Definitions

   Where applicable, HTTP status [H10] codes are reused.  Status codes
   that have npt=45.76-98.36

13.7.  TEARDOWN

13.7.1.  Client to Server

   The TEARDOWN client to server request stops the same meaning are not repeated here.  See Table 4 stream delivery for a
   listing of which status codes may be returned by which requests.  All
   error messages, 4xx and 5xx
   the given URI, freeing the resources associated with it.  A TEARDOWN
   request MAY return be performed on either an aggregated or a body containing further
   information about media control
   URI.  However some restrictions apply depending on the error.

15.1.  Success 1xx

15.1.1.  100 Continue

   See, [H10.1.1].

15.2.  Success 2xx

15.2.1.  200 OK

   See, [H10.2.1].

15.3.  Redirection 3xx

   The notation "3rr" indicates response codes from 300 to 399 inclusive
   which are meant for redirection. current state.
   The response code 304 is excluded
   from this set, as it is not used for redirection.

   See [H10.3] for definition of status code 300 to 305.  However
   comments are given for some to how they apply to RTSP.

   Within RTSP, redirection may be used for load balancing or
   redirecting stream requests to a server topologically closer to the
   client.  Mechanisms to determine topological proximity are beyond the
   scope of this specification.

   A 3rr code MAY be used to respond to any request.  It is RECOMMENDED
   that they are used if necessary before TEARDOWN request MUST contain a Session header indicating what
   session is established, i.e.
   in response to DESCRIBE or SETUP.  However in cases where a server is
   not able to send a REDIRECT request to the client, the server MAY
   need to resort to request applies to.

   A TEARDOWN using 3rr responses to inform a client with a
   established session about the need for redirecting aggregated control URI or the session.  If
   an 3rr response is received for an request media URI in relation to a
   established session, the client SHOULD send a TEARDOWN
   session under non-aggregated control (single media session) MAY be
   done in any state (Ready, and Play).  A successful request for
   the session, MUST
   result in that media delivery is immediately halted and MAY reestablish the session using the resource
   state is destroyed.  This MUST be indicated by the Location.

   If the through the Location lack of a
   Session header is used in a response it SHALL contain an
   absolute URI pointing out the response.

   A TEARDOWN using a media resource the client is redirected
   to, the URI SHALL NOT in an aggregated session MAY only contain the host name.

15.3.1.  300 Multiple Choices

   See [H10.3.1].

15.3.2.  301 Moved Permanently

   The be
   done in Ready state.  Such a request resource are moved permanently and resides now at the URI
   given by only removes the location header.  The user client SHOULD redirect
   automatically to indicated media
   stream and associated resources from the given URI. session.  This response MUST NOT contain a
   message-body.  The Location header MUST be included may result in
   that a session returns to non-aggregated control, due to that it only
   contains a single media after the response.

15.3.3.  302 Found

   The requested resource resides temporarily at requests completion.  A session
   that will exist after the URI given by processing of the
   Location header.  The Location header TEARDOWN request MUST be included in
   the
   response.  This response is intended to be used for many types of
   temporary redirects; e.g., load balancing.  It is RECOMMENDED that TEARDOWN request contain a Session header.  Thus
   the server set presence of the reason phrase to something more meaningful than
   "Found" in these cases.  The user client SHOULD redirect
   automatically Session header indicates to the given URI.  This receiver of the
   response MUST NOT contain a
   message-body.

   This example shows a client being redirected to a different server: if the session is still existing or has been removed.

   Example:

     C->S: SETUP TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 2
           Transport: RTP/AVP/TCP;unicast;interleaved=0-1
           Accept-Ranges: NPT, SMPTE, UTC 892
           Session: 12345678
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 302 Try Other Server 200 OK
           CSeq: 2
           Location: rtsp://s2.example.com:8001/fizzle/foo

15.3.4.  303 See Other

   This status code SHALL NOT be used in RTSP.  However, it was allowed 892
           Server: PhonyServer 1.0

13.7.2.  Server to use Client

   The server can send TEARDOWN requests in RTSP 1.0 (RFC 2326).

15.3.5.  304 Not Modified

   If the server to client has performed a conditional DESCRIBE or SETUP (see
   Section 16.25) and
   direction to indicate that the requested resource server has not been modified, forced to terminate
   the
   server SHOULD send a 304 response. ongoing session.  This response MUST NOT contain a
   message-body.

   The response MUST include the following header fields:

   o  Date

   o  ETag and/or Content-Location, if the header(s) would may happen for several reasons such as,
   server maintenance without available backup, or session have been
      sent
   inactive for extended periods of time.  The reason is provided in a 200 response to the same request.

   o  Expires, Cache-Control, and/or Vary, if the field-value might
      differ from
   Terminate-Reason header (Section 16.50).

   When a RTSP client has maintained a RTSP session that sent in any previous response for the same
      variant.

   This response otherwise is independent
   inactive for an extended period of time the DESCRIBE and SETUP requests. server may reclaim the
   resources.  That is, is done by issuing a 304 response REDIRECT request with the
   Terminate-Reason set to DESCRIBE does NOT imply that "Session-Timeout".  This MAY be done when the resource
   content is unchanged (only
   client has been inactive in the RTSP session description) and a 304
   response to SETUP does NOT imply that for more than one
   Session Timeout period (Section 16.48).  However, the resource description server is
   unchanged.
   RECOMMENDED to not perform this operation until an extended period of
   inactivity has passed.  The ETag time period is considered extended when
   it is 10 times the Session Timeout period.  Consideration of the
   application of the server and If-Match headers may its content should be used performed when
   configuring what is considered as extended periods of time.

   In case the server needs to stop provide service to link the
   DESCRIBE established
   sessions and SETUP their is no server to point at in this manner.

15.3.6.  305 Use Proxy

   See [H10.3.6].

15.4.  Client Error 4xx

15.4.1.  400 Bad Request

   The a REDIRECT request could not
   TEARDOWN shall be understood by used to terminate the session.  This method can
   also be used when non-recoverable internal errors have happened and
   the server due has no other option then to malformed
   syntax.  The client SHOULD NOT repeat the request without
   modifications [H10.4.1].  If terminate the sessions.

   The TEARDOWN request does not have a CSeq header, is normally done on the server session aggregate
   control URI and MUST NOT include a CSeq in the response.

15.4.2.  405 Method Not Allowed following headers; Session and
   Terminate-Reason headers.  The method specified in the request is not allowed for only applies to the resource session
   identified by in the Request-URI. Session header.  The response MUST server may include an Allow
   header containing a list of valid methods for the requested resource.
   This status code is also message
   to the client's user with the "user-msg" parameter.

   The TEARDOWN request may alternatively be used if done on the wild card URI *
   and without any session header.  The scope of such a request attempts is
   limited to use a
   method not indicated during SETUP.

15.4.3.  451 Parameter Not Understood

   The recipient of the request does not support one or more parameters
   contained next-hop (i.e. the RTSP agent in direct communication
   with the request.  When returning this error message server) and applies, as well, to the
   sender SHOULD return a entity body containing control connection
   between the offending
   parameter(s).

15.4.4.  452 reserved next-hop RTSP agent and the server.  This error code was removed from RFC 2326 [RFC2326] request
   indicates that all sessions and is obsolete.

15.4.5.  453 Not Enough Bandwidth

   The pending requests being managed via
   the control connection are terminated.  Any intervening proxies
   SHOULD do all of the following in the order listed:

   1.  respond to the TEARDOWN request was refused because there was insufficient bandwidth.
   This may,

   2.  disconnect the control channel from the requesting server

   3.  pass the TEARDOWN request to each applicable client (typically
       those clients with an active session or an unanswered request)

      Note: The proxy is responsible for example, accepting TEARDOWN responses
      from its clients; these responses MUST NOT be passed on to either
      the result original server or the redirected server.

13.8.  GET_PARAMETER

   The GET_PARAMETER request retrieves the value of any specified
   parameter or parameters for a resource reservation
   failure.

15.4.6.  454 Session Not Found

   The RTSP session identifier presentation or stream specified in the
   URI.  If the Session header is missing,
   invalid, or has timed out.

15.4.7.  455 Method Not Valid present in This State

   The client or server cannot process this request a request, the value of a
   parameter MUST be retrieved in its current
   state.  The response SHALL contain an Allow header the specified session context.  There
   are two ways of specifying the parameters to make error
   recovery possible.

15.4.8.  456 be retrieved.  The first
   is by including headers which have been defined such that you can use
   them for this purpose.  Header Field Not Valid for Resource

   The server could not act on a required request header.  For example,
   if PLAY contains this purpose should allow empty,
   or stripped value parts to avoid having to specify bogus data when
   indicating the Range header field but desire to retrieve a value.  The successful completion
   of the stream does not allow
   seeking.  This error message may request should also be used for specifying when the
   time format evident from any filled out values in Range is impossible for
   the resource.  In that case
   the Accept-Ranges response.  The Media-Range header SHALL be returned (Section 16.29) is one such
   header.  The other is to inform specify a message body that lists the client of
   which format(s)
   parameter(s) that are allowed.

15.4.9.  457 Invalid Range desirable to retrieve.  The Range value given Content-Type header
   (Section 16.18) is out of bounds, e.g., beyond the end of used to specify which format the
   presentation.

15.4.10.  458 Parameter Is Read-Only message body has.

   The parameter to headers that MAY be set by SET_PARAMETER can used for retrieving their current value using
   GET_PARAMETER are:

   o  Accept-Ranges

   o  Media-Range

   o  Media-Properties

   o  Range

   o  RTP-Info
   The method MAY also be read but not
   modified.  When returning this error message the sender SHOULD return used without a entity message body containing or any header that
   request parameters for keep-alive purpose.  Any request that is
   successful, i.e., a 200 OK response is received, then the offending parameter(s).

15.4.11.  459 Aggregate Operation Not Allowed

   The requested method keep-alive
   timer has been updated.  Any non-required header present in such a
   request may or may not be applied on been processed.  Normally the URI presence of
   filled out values in question since the header will be indication that the header
   has been processed.  However, for cases when this is difficult to
   determine, it is an aggregate (presentation) URI.  The method may be applied on recommended to use a media URI.

15.4.12.  460 Only Aggregate Operation Allowed

   The requested method may not be applied on feature-tag and the URI in question since Require
   header.  Due to this reason it is not an aggregate control (presentation) URI.  The method may usually easier if any parameters to
   be
   applied on retrieved are sent in the aggregate control URI.

15.4.13.  461 Unsupported Transport

   The Transport field did not contain a supported transport
   specification.

15.4.14.  462 Destination Unreachable

   The data transmission channel could not body, rather than using any header.

   Parameters specified within the body of the message must all be established because
   understood by the
   client address could request receiving agent.  If one or more parameters
   are not understood a 451 (Parameter Not Understood) MUST be reached. sent
   including a body listing these parameters that wasn't understood.  If
   all parameters are understood their value is filled in and returned
   in the response message body.

   Example:

     S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 431
           Content-Type: text/parameters
           Session: 12345678
           Content-Length: 26
           User-Agent: PhonyClient/1.2

           packets_received
           jitter

     C->S: RTSP/2.0 200 OK
           CSeq: 431
           Content-Length: 38
           Content-Type: text/parameters

           packets_received: 10
           jitter: 0.3838

13.9.  SET_PARAMETER

   This error will most likely be method requests to set the result value of a client attempt to place an invalid dest_addr parameter in or a set of
   parameters for a presentation or stream specified by the Transport field.

15.4.15.  463 Destination Prohibited URI.  The data transmission channel was not established because
   method MAY also be used without a message body.  It is the server
   prohibited access
   RECOMMENDED method to use in request sent for the client address.  This error sole purpose of
   updating the keep-alive timer.  If this request is most likely successful, i.e. a
   200 OK response is received, then the result of keep-alive timer has been
   updated.  Any non-required header present in such a request may or
   may not been processed.  To allow a client attempt to redirect media traffic determine if any such
   header has been processed, it is necessary to another
   destination with use a dest_addr parameter in feature tag and
   the Transport Require header.

15.4.16.  464 Data Transport Not Ready Yet

   The data transmission channel  Due to the media destination is not yet
   ready for carrying data.  However the responding entity still expects
   that the data transmission channel will be established at this point
   in time.  Note however that this may result in a permanent failure
   like 462 "Destination Unreachable".

   An example when this error may occur reason it is RECOMMENDED that any
   parameters are sent in the case body, rather than using any header.

   A request is RECOMMENDED to only contain a single parameter to allow
   the client sends a
   PLAY request to determine why a particular request failed.  If the
   request contains several parameters, the server prior to ensuring that MUST only act on the TCP connections
   negotiated for carrying media data was successful established (In
   violation
   request if all of this specification).  The the parameters can be set successfully.  A server would use this error
   code
   MUST allow a parameter to indicate that the requested action could not be performed due set repeatedly to the failure same value, but it
   MAY disallow changing parameter values.  If the receiver of completing the connection establishment.

15.4.17.  465 Notification Reason Unknown

   The client has received a PLAY_NOTIFY (Section 13.5) with a Notify-
   Reason header (Section 16.31) indicates
   request does not understand or cannot locate a reson that are unknown parameter, error 451
   (Parameter Not Understood) MUST be used.  In the case a parameter is
   not allowed to change, the client.

15.4.18.  470 Connection Authorization Required

   The secured connection attempt need user or client authorization
   before proceeding.  The next hops certificate error code is included in this 458 (Parameter Is Read-
   Only).  The response body MUST contain only the parameters that have
   errors.  Otherwise no body MUST be returned.

   Note: transport parameters for the media stream MUST only be set with
   the SETUP command.

      Restricting setting transport parameters to SETUP is for the
      benefit of firewalls.

      The parameters are split in a fine-grained fashion so that there
      can be more meaningful error indications.  However, it may make
      sense to allow the Accept-Credentials header.

15.4.19.  471 Connection Credentials setting of several parameters if an atomic
      setting is desirable.  Imagine device control where the client
      does not accepted

   When performing want the camera to pan unless it can also tilt to the
      right angle at the same time.

   Example:

     C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 421
           User-Agent: PhonyClient/1.2
           Content-length: 20
           Content-type: text/parameters

           barparam: barstuff

     S->C: RTSP/2.0 451 Parameter Not Understood
           CSeq: 421
           Content-length: 10
           Content-type: text/parameters

           barparam: barstuff

13.10.  REDIRECT

   The REDIRECT method is issued by a secure connection over multiple connections, server to inform a
   intermediary has refused client that the
   service provided will be terminated and where a corresponding service
   can provided instead.  This happens for different reasons.  One is
   that the server is being administrated such that it must stop
   providing service.  Thus the client is required to connect to another
   server location to access the next hop and carry out resource indicated by the Request-URI.

   The REDIRECT request due SHALL contain a Terminate-Reason header
   (Section 16.50) to unacceptable credentials inform the client of the reason for the used policy.

15.4.20.  472 Failure request.
   Additional parameters related to establish secure connection

   A proxy fails the reason may also be included.
   The intention here is to establish a secure connection allow an server administrator to do a
   controlled shutdown of the next hop RTSP
   agent.  This is primarily caused by a fatal failure at server.  That requires sufficient
   time to inform all entities having associated state with the TLS
   handshake, server
   and for example due them to perform a controlled migration from this server not accepting any cipher suits.

15.5.  Server Error 5xx

15.5.1.  551 Option not supported to a
   fall back server.

   A feature-tag given in REDIRECT request with a Session header has end-to-end (i.e. server
   to client) scope and applies only to the Require or given session.  Any
   intervening proxies SHOULD NOT disconnect the Proxy-Require fields was
   not supported. control channel while
   there are other remaining end-to-end sessions.  The Unsupported REQUIRED Location
   header SHALL be returned stating MUST contain a complete absolute URI pointing to the
   feature for resource
   to which there is no support.

16.  Header Field Definitions

       +---------------+----------------+--------+---------+------+
       | method        | direction      | object | acronym | Body |
       +---------------+----------------+--------+---------+------+
       | DESCRIBE      | C -> S         | P,S    | DES     | r    |
       |               |                |        |         |      |
       | GET_PARAMETER | C -> S, S -> C | P,S    | GPR     | R,r  |
       |               |                |        |         |      |
       | OPTIONS       | C -> S         | P,S    | OPT     |      |
       |               |                |        |         |      |
       |               | S -> C         |        |         |      |
       |               |                |        |         |      |
       | PAUSE         | C -> S         | P,S    | PSE     |      |
       |               |                |        |         |      |
       | PLAY          | C -> S         | P,S    | PLY     |      |
       |               |                |        |         |      |
       | PLAY_NOTIFY   | S -> C         | P,S    | PNY     | R    |
       |               |                |        |         |      |
       | REDIRECT      | S -> C         | P,S    | RDR     |      |
       |               |                |        |         |      |
       | SETUP         | C -> S         | S      | STP     |      |
       |               |                |        |         |      |
       | SET_PARAMETER | C -> S, S -> C | P,S    | SPR     | R,r  |
       |               |                |        |         |      |
       | TEARDOWN      | C -> S         | P,S    | TRD     |      |
       +---------------+----------------+--------+---------+------+

   Table 8: Overview of RTSP methods, their direction, the client SHOULD reconnect.  Specifically, the Location
   MUST NOT contain just the host and what objects
   (P: presentation, S: stream) they operate on. Body notes if port.  A client may receive a method
       is allowed to carry body and in which direction, R = Request,
   r=response. Note: It is allowed for all error messages 4xx
   REDIRECT request with a Session header, if and 5xx to
                                have only if, an end-to-end
   session has been established.

   A client may receive a body

   The general syntax for header fields is covered in Section 5.2.  This
   section lists the full set of REDIRECT request without a Session header fields along at
   any time when it has communication or a connection established with notes on
   meaning, and usage. a
   server.  The syntax definition for header fields are
   present in Section 20.2.3.  Throughout this section, we use [HX.Y] to
   refer to Section X.Y scope of such a request is limited to the current HTTP/1.1 specification RFC 2616
   [RFC2616].  Examples of each header field are given.

   Information about header fields next-hop (i.e.
   the RTSP agent in relation to methods direct communication with the server) and proxy
   processing is summarized in Table 9, Table 10, Table 11, applies
   to all sessions controlled, as well as the control connection between
   the next-hop RTSP agent and
   Table 12.

   The "where" column describes the server.  A REDIRECT request without a
   Session header indicates that all sessions and response types in which pending requests being
   managed via the header field can control connection MUST be used.  Values in this column are:

   R:    header field may only appear in requests;

   r:    header field may only appear redirected.  The REQUIRED
   Location header, if included in responses;

   2xx, 4xx, etc.:  A numerical value or range indicates response codes such a request, SHOULD contain an
   absolute URI with which only the header field can be used;

   c:    header field is copied from host address and the request OPTIONAL port number
   of the server to which the response.

   An empty entry RTSP agent SHOULD reconnect.  Any
   intervening proxies SHOULD do all of the following in the "where" column indicates that order
   listed:

   1.  respond to the header field
   may be present in both requests and responses.

   The "proxy" column describes REDIRECT request

   2.  disconnect the operations a proxy may perform on a
   header field.  An empty proxy column indicates that control channel from the proxy SHALL
   NOT do any changes requesting server

   3.  connect to that header, all allowed operations are
   explicitly stated:

   a:    A proxy can add or concatenate the header field if not present.

   m:    A proxy can modify server at the given host address
   4.  pass the REDIRECT request to each applicable client (typically
       those clients with an existing header field value.

   d:    A proxy can delete a header field value.

   r:    A active session or an unanswered request)

      Note: The proxy needs to is responsible for accepting REDIRECT responses
      from its clients; these responses MUST NOT be able passed on to read either
      the header field, and thus
         this header field cannot be encrypted.

   The rest of original server or the columns relate to redirected server.

   When the presence of server lacks any alternative server and needs to terminate a header field
   session or all sessions the TEARDOWN request SHALL be used instead.

   When no Terminate-Reason "time" parameter are included in a
   method.  The method names when abbreviated, are according to Table 8:

   c:    Conditional; requirements on the header field depend on REDIRECT
   request, the
         context of client SHALL perform the message.

   m:    The header field is mandatory.

   m*:   The header field SHOULD be sent, but clients/servers need to be
         prepared redirection immediately and
   return a response to receive messages without that header field.

   o:    The header field is optional.

   *: the server.  The header field is SHALL be present if server shall consider the message body is not
         empty.  See Section 16.16, Section 16.18
   session as terminated and Section 5.3 for
         details.

   -:    The header field is not applicable.

   "Optional" means that a Client/Server MAY include can free any associated state after it
   receives the header field in
   a request or successful (2xx) response.  The Client/Server behavior when server MAY close the
   signalling connection upon receiving
   such headers varies, for some it may ignore the header field, in
   other case it is request to process response and the header.  This client
   SHOULD close the signalling connection after sending the 2xx
   response.  The exception to this is regulated by when the method and header descriptions.  Example of such headers that
   require processing are client has several
   sessions on the Require and Proxy-Require header fields
   discussed in Section 16.42 and Section 16.35.  A "mandatory" header
   field MUST be present in a request, and MUST be understood server being managed by the
   Client/Server receiving given signalling
   connection.  In this case, the request.  A mandatory response header
   field MUST be present in client SHOULD close the response, connection
   when it has received and responded to REDIRECT requests for all the header field MUST be
   understood
   sessions managed by the Client/Server processing the response.  "Not
   applicable" means that the signalling connection.

   The Terminate-Reason header field MUST NOT be present in a
   request.  If one is placed in a request by mistake, it MUST "time" parameter MAY be
   ignored by used to indicate
   the Client/Server receiving wallclock time by when the request.  Similarly, a
   header field labeled "not applicable" for redirection MUST have take place.  To
   allow a response means client to determine that redirect time without being time
   synchronized with the
   Client/Server MUST NOT place server, the server MUST include a Date header field
   in the response, request.  The client should have before the redirection time-
   line terminated the session and close the Client/Server MUST ignore control connection.  The
   server MAY simple cease to provide service when the deadline time has
   been reached, or it may issue TEARDOWN requests to the remaining
   sessions.

      The differentiation of REDIRECT requests with and without range
      header field is to allow for clear and explicit state handling.  As the
      state in the response.

   An RTSP agent SHALL ignore extension headers server needs to be kept until the point of
      redirection, the handling becomes more clear if the client is
      required to TEARDOWN the session at the redirect point.

   If the REDIRECT request times out following the rules in Section 10.4
   the server MAY terminate the session or transport connection that are
   would be redirected by the request.  This is a safeguard against
   misbehaving clients that refuses to respond to a REDIRECT request.
   That should not understood.

   The From and provide any benefit.

   After a REDIRECT request has been processed, a client that wants to
   continue to send or receive media for the resource identified by the
   Request-URI will have to establish a new session with the designated
   host.  If the URI given in the Location header fields contain an is a valid resource
   URI, a client SHOULD issue a DESCRIBE request for the URI.

      Note: The media resource indicated by the Location header can be
      identical, slightly different or totally different.  This is the
      reason why a new DESCRIBE request SHOULD be issued.

   If the URI Location header contains only a comma, or semicolon, host address, the URI MUST be enclosed in double
   quotas (").  Any URI parameters client MAY
   assume that the media on the new server is identical to the media on
   the old server, i.e. all media configuration information from the old
   session is still valid except for the host address.  However the
   usage of conditional SETUP using MTag identifiers are contained within these quotas.
   If RECOMMENDED to
   verify the URI assumption.

   This example request redirects traffic for this session to the new
   server at the given absolute time:

     S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 732
           Location: rtsp://s2.example.com:8001
           Terminate-Reason: Server-Admin ;time=19960213T143205Z
           Session: uZ3ci0K+Ld-M
           Date: Thu, 13 Feb 1996 14:30:43 GMT

     C->S: RTSP/2.0 200 OK
           CSeq: 732
           User-Agent: PhonyClient/1.2

14.  Embedded (Interleaved) Binary Data

   In order to fulfill certain requirements on the network side, e.g. in
   conjunction with network address translators that block RTP traffic
   over UDP, it may be necessary to interleave RTSP messages and media
   stream data.  This interleaving should generally be avoided unless
   necessary since it complicates client and server operation and
   imposes additional overhead.  Also head of line blocking may cause
   problems.  Interleaved binary data SHOULD only be used if RTSP is not enclosed
   carried over TCP.

   Stream data such as RTP packets is encapsulated by an ASCII dollar
   sign (24 decimal), followed by a one-byte channel identifier,
   followed by the length of the encapsulated binary data as a binary,
   two-byte integer in double quotas, any semicolon- delimited
   parameters are header-parameters, not URI parameters.

   +----------------+------+-----+-----+-----+------+-----+------+-----+
   | Header         | Wher | Pro | DES | OPT | SETU | PLA | PAUS | TRD |
   |                | e    | xy  |     |     | P    | Y   | E    |     |
   +----------------+------+-----+-----+-----+------+-----+------+-----+
   | Accept         | R    |     | o   | -   | -    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Accept-Credent | R    | r   | o   | o   | o    | o   | o    | o   |
   | ials           |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Accept-Encodin | R    | r   | o   | -   | -    | -   | -    | -   |
   | g              |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Accept-Languag | R    | r   | o   | -   | -    | -   | -    | -   |
   | e              |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Accept-Ranges  | R    | r   | -   | -   | m    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Accept-Ranges  | r    | r   | -   | -   | o    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Accept-Ranges  | 456  | r   | -   | -   | -    | o   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Allow          | r    | am  | c   | c   | c    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Allow          | 405  | am  | m   | m   | m    | m   | m    | m   |
   |                |      |     |     |     |      |     |      |     |
   | Authorization  | R    |     | o   | o   | o    | o   | o    | o   |
   |                |      |     |     |     |      |     |      |     |
   | Bandwidth      | R    |     | o   | o   | o    | o   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Blocksize      | R    |     | o   | -   | o    | o   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Cache-Control  |      | r   | o   | -   | o    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Connection     |      |     | o   | o   | o    | o   | o    | o   |
   |                |      |     |     |     |      | network byte order.  The stream data follows
   immediately afterwards, without a CRLF, but including the upper-layer
   protocol headers.  Each $ block MUST contain exactly one upper-layer
   protocol data unit, e.g., one RTP packet.
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | "$" = 24      | Channel ID    | Length in bytes               | Connection-Cre | 470, | ar  | o   | o   | o    | o   | o    | o   |
   | dentials       | 407  |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Base   | r    |     | o   | -   | -    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Content-Base   | 4xx, |     | o   | o   | o    | o   | o    | o   |
   |                | 5xx  |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Encodi | R    | r   | -   | -   | -    | -   | -    | -   |
   | ng             |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Encodi | r    | r   | o   | -   | -    | -   | -    | -   |
   | ng             |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Encodi | 4xx, | r   | o   | o   | o    | o   | o    | o   |
   | ng             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      : Length number of bytes of binary data                         :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The channel identifier is defined in the Transport header with the
   interleaved parameter (Section 16.52).

   When the transport choice is RTP, RTCP messages are also interleaved
   by the server over the TCP connection.  The usage of RTCP messages is
   indicated by including a interval containing a second channel in the
   interleaved parameter of the Transport header, see Section 16.52.  If
   RTCP is used, packets MUST be sent on the first available channel
   higher than the RTP channel.  The channels are bi-directional and
   therefore RTCP traffic are sent on the second channel in both
   directions.

      RTCP is sometime needed for synchronization when two or more
      streams are interleaved in such a fashion.  Also, this provides a
      convenient way to tunnel RTP/RTCP packets through the TCP control
      connection when required by the network configuration and transfer
      them onto UDP when possible.

     C->S: SETUP rtsp://example.com/bar.file RTSP/2.0
           CSeq: 2
           Transport: RTP/AVP/TCP;unicast;interleaved=0-1
           Accept-Ranges: NPT, SMPTE, UTC
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 2
           Date: Thu, 05 Jun 1997 18:57:18 GMT
           Transport: RTP/AVP/TCP;unicast;interleaved=5-6
           Session: 12345678
           Accept-Ranges: NPT
           Media-Properties: Random-Access=0.2, Unmutable, Unlimited

     C->S: PLAY rtsp://example.com/bar.file RTSP/2.0
           CSeq: 3
           Session: 12345678
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
           CSeq: 3
           Session: 12345678
           Date: Thu, 05 Jun 1997 18:59:15 GMT
           RTP-Info: url="rtsp://example.com/bar.file"
             ssrc=0D12F123:seq=232433;rtptime=972948234
           Range: npt=0-56.8
           Seek-Style: RAP

     S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
     S->C: $005{2 byte length}{"length" bytes data, w/RTP header}
     S->C: $006{2 byte length}{"length" bytes  RTCP packet}

15.  Status Code Definitions

   Where applicable, HTTP status [H10] codes are reused.  Status codes
   that have the same meaning are not repeated here.  See Table 4 for a
   listing of which status codes may be returned by which requests.  All
   error messages, 4xx and 5xx  |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Langua | R    | r   | -   | -   | -    | -   | -    | -   |
   | ge             |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Langua | r    | r   | o   | -   | -    | -   | -    | -   |
   | ge             |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Langua | 4xx, | r   | o   | o   | o    | o   | o    | o   |
   | ge             | 5xx  |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Length | r    | r   | *   | -   | -    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Content-Length | 4xx, | r   | *   | *   | *    | *   | *    | *   |
   |                | 5xx  |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Locati | r    |     | o   | -   | -    | -   | -    | -   |
   | on             |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Locati | 4xx, |     | o   | o   | o    | o   | o    | o   |
   | MAY return a body containing further
   information about the error.

15.1.  Success 1xx

15.1.1.  100 Continue

   The client SHOULD continue with its request.  This interim response
   is used to inform the client that the initial part of the request has
   been received and has not yet been rejected by the server.  The
   client SHOULD continue by sending the remainder of the request or, if
   the request has already been completed, ignore this response.  The
   server MUST send a final response after the request has been
   completed.

15.2.  Success 2xx

   This class of status code indicates that the client's request was
   successfully received, understood, and accepted.

15.2.1.  200 OK

   The request has succeeded.  The information returned with the
   response is dependent on             | 5xx  |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Type   | r    |     | *   | -   | -    | -   | -    | -   |
   | Content-Type   | 4xx, |     | *   | *   | *    | *   | *    | *   |
   |                | 5xx  |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | CSeq           | Rc   | rm  | m   | m   | m    | m   | m    | m   |
   |                |      |     |     |     |      |     |      |     |
   | Date           |      | am  | o   | o   | o    | o   | o    | o   |
   |                |      |     |     |     |      |     |      |     |
   | ETag           | r    | r   | o   | -   | o    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Expires        | r    | r   | o   | -   | -    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | From           | R    | r   | o   | o   | o    | o   | o    | o   |
   |                |      |     |     |     |      |     |      |     |
   | If-Match       | R    | r   | -   | -   | o    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | If-Modified-Si | R    | r   | o   | -   | o    | -   | -    | -   |
   | nce            |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | If-None-Match  | R    | r   | o   | -   | -    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Last-Modified  | r    | r   | o   | -   | -    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Location       | 3rr  |     | o   | o   | o    | o   | o    | o   |
   +----------------+------+-----+-----+-----+------+-----+------+-----+

     Table 9: Overview the method used in the request.

15.3.  Redirection 3xx

   The notation "3rr" indicates response codes from 300 to 399 inclusive
   which are meant for redirection.  The response code 304 is excluded
   from this set, as it is not used for redirection.

   Within RTSP, redirection may be used for load balancing or
   redirecting stream requests to a server topologically closer to the
   client.  Mechanisms to determine topological proximity are beyond the
   scope of RTSP header fields (A-L) related this specification.

   An 3rr code MAY be used to methods
           DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, respond to any request.  It is RECOMMENDED
   that they are used if necessary before a session is established,
   i.e., in response to DESCRIBE or SETUP.  However in cases where a
   server is not able to send a REDIRECT request to the client, the
   server MAY need to resort to using 3rr responses to inform a client
   with an established session about the need for redirecting the
   session.  If an 3rr response is received for a request in relation to
   an established session, the client SHOULD send a TEARDOWN request for
   the session, and TEARDOWN.

   +------------+-------+------+----+-----+-------+------+-------+-----+
   | Header     | Where | Prox | DE | OPT | SETUP | PLAY | PAUSE | TRD |
   |            |       | y    | S  |     |       |      |       |     |
   +------------+-------+------+----+-----+-------+------+-------+-----+
   | Media-     |       |      | -  | -   | r     | r    | r     | -   |
   | Properties |       |      |    |     |       |      |       |     |
   |            |       |      |    |     |       |      |       |     |
   | Media-     |       |      | -  | -   | r     | r    | r     | -   |
   | Range      |       |      |    |     |       |      |       |     |
   |            |       |      |    |     |       |      |       |     |
   | Pipelined- |       | amdr | -  | o   | o     | o    | o     | o   |
   | Requests   |       |      |    |     |       |      |       |     |
   |            |       |      |    |     |       |      |       |     |
   | Proxy-     | 407   | amr  | m  | m   | m     | m    | m     | m   |
   | Authentica |       |      |    |     |       |      |       |     |
   | te         |       |      |    |     |       |      |       |     |
   |            |       |      |    |     |       |      |       |     |
   | Proxy-     | R     | rd   | o  | o   | o     | o    | o     | o   |
   | Authorizat |       |      |    |     |       |      |       |     |
   | ion        |       |      |    |     |       |      |       |     |
   | Proxy-     | R     | ar   | o  | o   | o     | MAY reestablish the session using the resource
   indicated by the Location.

   If the Location header is used in a response it MUST contain an
   absolute URI pointing out the media resource the client is redirected
   to, the URI MUST NOT only contain the host name.

15.3.1.  301 Moved Permanently

   The request resource are moved permanently and resides now at the URI
   given by the location header.  The user client SHOULD redirect
   automatically to the given URI.  This response MUST NOT contain a
   message-body.  The Location header MUST be included in the response.

15.3.2.  302 Found

   The requested resource resides temporarily at the URI given by the
   Location header.  The Location header MUST be included in the
   response.  This response is intended to be used for many types of
   temporary redirects; e.g., load balancing.  It is RECOMMENDED that
   the server set the reason phrase to something more meaningful than
   "Found" in these cases.  The user client SHOULD redirect
   automatically to the given URI.  This response MUST NOT contain a
   message-body.

   This example shows a client being redirected to a different server:

     C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0
           CSeq: 2
           Transport: RTP/AVP/TCP;unicast;interleaved=0-1
           Accept-Ranges: NPT, SMPTE, UTC
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 302 Try Other Server
           CSeq: 2
           Location: rtsp://s2.example.com:8001/fizzle/foo

15.3.3.  303 See Other

   This status code MUST NOT be used in RTSP.  However, it was allowed
   to use in RTSP 1.0 (RFC 2326).

15.3.4.  304 Not Modified

   If the client has performed a conditional DESCRIBE or SETUP (see
   Section 16.24) and the requested resource has not been modified, the
   server SHOULD send a 304 response.  This response MUST NOT contain a
   message-body.

   The response MUST include the following header fields:

   o    |  Date

   o     |  MTag and/or Content-Location, if the header(s) would have been
      sent in a 200 response to the same request.

   o   |
   | Require    |       |      |    |     |       |      |       |     |
   |            |       |      |    |     |       |      |       |     |
   | Proxy-     | r     | r    | c  | c   | c     | c    | c     | c   |
   | Require    |       |      |    |     |       |      |       |     |
   |            |       |      |    |     |       |      |       |     |
   | Proxy-     | R     | amr  | c  | c   | c     | c    | c     | c   |
   |  Expires, Cache-Control, and/or Vary, if the field-value might
      differ from that sent in any previous response for the same
      variant.

   This response is independent for the DESCRIBE and SETUP requests.
   That is, a 304 response to DESCRIBE does NOT imply that the resource
   content is unchanged (only the session description) and a 304
   response to SETUP does NOT imply that the resource description is
   unchanged.  The MTag and If-Match headers may be used to link the
   DESCRIBE and SETUP in this manner.

15.3.5.  305 Use Proxy

   The requested resource MUST be accessed through the proxy given by
   the Location field.  The Location field gives the URI of the proxy.
   The recipient is expected to repeat this single request via the
   proxy. 305 responses MUST only be generated by origin servers.

15.4.  Client Error 4xx

15.4.1.  400 Bad Request

   The request could not be understood by the server due to malformed
   syntax.  The client SHOULD NOT repeat the request without
   modifications.  If the request does not have a CSeq header, the
   server MUST NOT include a CSeq in the response.

15.4.2.  401 Unauthorized

   The request requires user authentication.  The response MUST include
   a WWW-Authenticate header (Section 16.57) field containing a
   challenge applicable to the requested resource.  The client MAY
   repeat the request with a suitable Authorization header field.  If
   the request already included Authorization credentials, then the 401
   response indicates that authorization has been refused for those
   credentials.  If the 401 response contains the same challenge as the
   prior response, and the user agent has already attempted
   authentication at least once, then the user SHOULD be presented the
   entity that was given in the response, since that entity might
   include relevant diagnostic information.  HTTP access authentication
   is explained in [RFC2617].

15.4.3.  402 Payment Required

   This code is reserved for future use.

15.4.4.  403 Forbidden

   The server understood the request, but is refusing to fulfill it.
   Authorization will not help and the request SHOULD NOT be repeated.
   If the server wishes to make public why the request has not been
   fulfilled, it SHOULD describe the reason for the refusal in the
   entity.  If the server does not wish to make this information
   available to the client, the status code 404 (Not Found) can be used
   instead.

15.4.5.  404 Not Found

   The server has not found anything matching the Request-URI.  No
   indication is given of whether the condition is temporary or
   permanent.  The 410 (Gone) status code SHOULD be used if the server
   knows, through some internally configurable mechanism, that an old
   resource is permanently unavailable and has no forwarding address.
   This status code is commonly used when the server does not wish to
   reveal exactly why the request has been refused, or when no other
   response is applicable.

15.4.6.  405 Method Not Allowed

   The method specified in the request is not allowed for the resource
   identified by the Request-URI.  The response MUST include an Allow
   header containing a list of valid methods for the requested resource.
   This status code is also to be used if a request attempts to use a
   method not indicated during SETUP.

15.4.7.  406 Not Acceptable

   The resource identified by the request is only capable of generating
   response entities which have content characteristics not acceptable
   according to the accept headers sent in the request.

   The response SHOULD include an message body containing a list of
   available entity characteristics and location(s) from which the user
   or user agent can choose the one most appropriate.  The entity format
   is specified by the media type given in the Content-Type header
   field.  Depending upon the format and the capabilities of the user
   agent, selection of the most appropriate choice MAY be performed
   automatically.  However, this specification does not define any
   standard for such automatic selection.

   If the response could be unacceptable, a user agent SHOULD
   temporarily stop receipt of more data and query the user for a
   decision on further actions.

15.4.8.  407 Proxy Authentication Required

   This code is similar to 401 (Unauthorized) (Section 15.4.2), but
   indicates that the client must first authenticate itself with the
   proxy.  The proxy MUST return a Proxy-Authenticate header field
   (Section 16.33) containing a challenge applicable to the proxy for
   the requested resource.

15.4.9.  408 Request Timeout

   The client did not produce a request within the time that the server
   was prepared to wait.  The client MAY repeat the request without
   modifications at any later time.

15.4.10.  410 Gone

   The requested resource is no longer available at the server and the
   forwarding address is not known.  This condition is expected to be
   considered permanent.  If the server does not know, or has no
   facility to determine, whether or not the condition is permanent, the
   status code 404 (Not Found) SHOULD be used instead.  This response is
   cacheable unless indicated otherwise.

   The 410 response is primarily intended to assist the task of
   repository maintenance by notifying the recipient that the resource
   is intentionally unavailable and that the server owners desire that
   remote links to that resource be removed.  Such an event is common
   for limited-time, promotional services and for resources belonging to
   individuals no longer working at the server's site.  It is not
   necessary to mark all permanently unavailable resources as "gone" or
   to keep the mark for any length of time -- that is left to the
   discretion of the owner of the server.

15.4.11.  411 Length Required

   The server refuses to accept the request without a defined Content-
   Length.  The client MAY repeat the request if it adds a valid
   Content-Length header field containing the length of the message-body
   in the request message.

15.4.12.  412 Precondition Failed

   The precondition given in one or more of the request-header fields
   evaluated to false when it was tested on the server.  This response
   code allows the client to place preconditions on the current resource
   meta information (header field data) and thus prevent the requested
   method from being applied to a resource other than the one intended.

15.4.13.  413 Request Message Body Too Large

   The server is refusing to process a request because the request
   message body is larger than the server is willing or able to process.
   The server MAY close the connection to prevent the client from
   continuing the request.

   If the condition is temporary, the server SHOULD include a Retry-
   After header field to indicate that it is temporary and after what
   time the client MAY try again.

15.4.14.  414 Request-URI Too Long

   The server is refusing to service the request because the Request-URI
   is longer than the server is willing to interpret.  This rare
   condition is only likely to occur when a client has used a request
   with long query information, when the client has descended into a URI
   "black hole" of redirection (e.g., a redirected URI prefix that
   points to a suffix of itself), or when the server is under attack by
   a client attempting to exploit security holes present in some servers
   using fixed-length buffers for reading or manipulating the Request-
   URI.

15.4.15.  415 Unsupported Media Type

   The server is refusing to service the request because the entity of
   the request is in a format not supported by the requested resource
   for the requested method.

15.4.16.  451 Parameter Not Understood

   The recipient of the request does not support one or more parameters
   contained in the request.  When returning this error message the
   sender SHOULD return a message body containing the offending
   parameter(s).

15.4.17.  452 reserved

   This error code was removed from RFC 2326 [RFC2326] as it is
   obsolete.  This error code MUST NOT be used anymore.

15.4.18.  453 Not Enough Bandwidth

   The request was refused because there was insufficient bandwidth.
   This may, for example, be the result of a resource reservation
   failure.

15.4.19.  454 Session Not Found

   The RTSP session identifier in the Session header is missing,
   invalid, or has timed out.

15.4.20.  455 Method Not Valid in This State

   The client or server cannot process this request in its current
   state.  The response MUST contain an Allow header to make error
   recovery possible.

15.4.21.  456 Header Field Not Valid for Resource

   The server could not act on a required request header.  For example,
   if PLAY contains the Range header field but the stream does not allow
   seeking.  This error message may also be used for specifying when the
   time format in Range is impossible for the resource.  In that case
   the Accept-Ranges header MUST be returned to inform the client of
   which format(s) that are allowed.

15.4.22.  457 Invalid Range

   The Range value given is out of bounds, e.g., beyond the end of the
   presentation.

15.4.23.  458 Parameter Is Read-Only

   The parameter to be set by SET_PARAMETER can be read but not
   modified.  When returning this error message the sender SHOULD return
   a message body containing the offending parameter(s).

15.4.24.  459 Aggregate Operation Not Allowed

   The requested method may not be applied on the URI in question since
   it is an aggregate (presentation) URI.  The method may be applied on
   a media URI.

15.4.25.  460 Only Aggregate Operation Allowed

   The requested method may not be applied on the URI in question since
   it is not an aggregate control (presentation) URI.  The method may be
   applied on the aggregate control URI.

15.4.26.  461 Unsupported Transport

   The Transport field did not contain a supported transport
   specification.

15.4.27.  462 Destination Unreachable

   The data transmission channel could not be established because the
   client address could not be reached.  This error will most likely be
   the result of a client attempt to place an invalid dest_addr
   parameter in the Transport field.

15.4.28.  463 Destination Prohibited

   The data transmission channel was not established because the server
   prohibited access to the client address.  This error is most likely
   the result of a client attempt to redirect media traffic to another
   destination with a dest_addr parameter in the Transport header.

15.4.29.  464 Data Transport Not Ready Yet

   The data transmission channel to the media destination is not yet
   ready for carrying data.  However the responding entity still expects
   that the data transmission channel will be established at this point
   in time.  Note however that this may result in a permanent failure
   like 462 "Destination Unreachable".

   An example when this error may occur is in the case a client sends a
   PLAY request to a server prior to ensuring that the TCP connections
   negotiated for carrying media data was successful established (In
   violation of this specification).  The server would use this error
   code to indicate that the requested action could not be performed due
   to the failure of completing the connection establishment.

15.4.30.  465 Notification Reason Unknown

   This indicates that the client has received a PLAY_NOTIFY
   (Section 13.5) with a Notify-Reason header (Section 16.31) unknown to
   the client.

15.4.31.  470 Connection Authorization Required

   The secured connection attempt need user or client authorization
   before proceeding.  The next hops certificate is included in this
   response in the Accept-Credentials header.

15.4.32.  471 Connection Credentials not accepted

   When performing a secure connection over multiple connections, a
   intermediary has refused to connect to the next hop and carry out the
   request due to unacceptable credentials for the used policy.

15.4.33.  472 Failure to establish secure connection

   A proxy fails to establish a secure connection to the next hop RTSP
   agent.  This is primarily caused by a fatal failure at the TLS
   handshake, for example due to server not accepting any cipher suits.

15.5.  Server Error 5xx

   Response status codes beginning with the digit "5" indicate cases in
   which the server is aware that it has erred or is incapable of
   performing the request The server SHOULD include an entity containing
   an explanation of the error situation, and whether it is a temporary
   or permanent condition.  User agents SHOULD display any included
   entity to the user.  These response codes are applicable to any
   request method.

15.5.1.  500 Internal Server Error

   The server encountered an unexpected condition which prevented it
   from fulfilling the request.

15.5.2.  501 Not Implemented

   The server does not support the functionality required to fulfill the
   request.  This is the appropriate response when the server does not
   recognize the request method and is not capable of supporting it for
   any resource.

15.5.3.  502 Bad Gateway

   The server, while acting as a gateway or proxy, received an invalid
   response from the upstream server it accessed in attempting to
   fulfill the request.

15.5.4.  503 Service Unavailable

   The server is currently unable to handle the request due to a
   temporary overloading or maintenance of the server.  The implication
   is that this is a temporary condition which will be alleviated after
   some delay.  If known, the length of the delay MAY be indicated in a
   Retry-After header.  If no Retry-After is given, the client SHOULD
   handle the response as it would for a 500 response.

         Note: The existence of the 503 status code does not imply that
         a server must use it when becoming overloaded.  Some servers
         may wish to simply refuse the connection.

15.5.5.  504 Gateway Timeout

   The server, while acting as a proxy, did not receive a timely
   response from the upstream server specified by the URI or some other
   auxiliary server (e.g.  DNS) it needed to access in attempting to
   complete the request.

15.5.6.  505 RTSP Version Not Supported

   The server does not support, or refuses to support, the RTSP protocol
   version that was used in the request message.  The server is
   indicating that it is unable or unwilling to complete the request
   using the same major version as the client other than with this error
   message.  The response SHOULD contain an message body describing why
   that version is not supported and what other protocols are supported
   by that server.

15.5.7.  551 Option not supported

   A feature-tag given in the Require or the Proxy-Require fields was
   not supported.  The Unsupported header MUST be returned stating the
   feature for which there is no support.

16.  Header Field Definitions

       +---------------+----------------+--------+---------+------+
       | method        | direction      | object | acronym | Body |
       +---------------+----------------+--------+---------+------+
       | DESCRIBE      | C -> S         | P,S    | DES     | r    |
       |               |                |        |         |      |
       | GET_PARAMETER | C -> S, S -> C | P,S    | GPR     | R,r  |
       |               |                |        |         |      |
       | OPTIONS       | C -> S         | P,S    | OPT     |      |
       |               |                |        |         |      |
       |               | S -> C         |        |         |      |
       |               |                |        |         |      |
       | PAUSE         | C -> S         | P,S    | PSE     |      |
       |               |                |        |         |      |
       | PLAY          | C -> S         | P,S    | PLY     |      |
       |               |                |        |         |      |
       | PLAY_NOTIFY   | S -> C         | P,S    | PNY     | R    |
       |               |                |        |         |      |
       | REDIRECT      | S -> C         | P,S    | RDR     |      |
       |               |                |        |         |      |
       | SETUP         | C -> S         | S      | STP     |      |
       |               |                |        |         |      |
       | SET_PARAMETER | C -> S, S -> C | P,S    | SPR     | R,r  |
       |               |                |        |         |      |
       | TEARDOWN      | C -> S         | P,S    | TRD     |      |
       +---------------+----------------+--------+---------+------+

   Table 8: Overview of RTSP methods, their direction, and what objects
   (P: presentation, S: stream) they operate on. Body notes if a method
       is allowed to carry body and in which direction, R = Request,
   r=response. Note: It is allowed for all error messages 4xx and 5xx to
                                have a body

   The general syntax for header fields is covered in Section 5.2.  This
   section lists the full set of header fields along with notes on
   meaning, and usage.  The syntax definition for header fields are
   present in Section 20.2.3.  Throughout this section, we use [HX.Y] to
   informational refer to Section X.Y of the current HTTP/1.1
   specification RFC 2616 [RFC2616].  Examples of each header field are
   given.

   Information about header fields in relation to methods and proxy
   processing is summarized in Table 9, Table 10, Table 11, and
   Table 12.

   The "where" column describes the request and response types in which
   the header field can be used.  Values in this column are:

   R:    header field may only appear in requests;

   r:    header field may only appear in responses;

   2xx, 4xx, etc.:  A numerical value or range indicates response codes
         with which the header field can be used;

   c:    header field is copied from the request to the response.

   An empty entry in the "where" column indicates that the header field
   may be present in both requests and responses.

   The "proxy" column describes the operations a proxy may perform on a
   header field.  An empty proxy column indicates that the proxy MUST
   NOT do any changes to that header, all allowed operations are
   explicitly stated:

   a:    A proxy can add or concatenate the header field if not present.

   m:    A proxy can modify an existing header field value.

   d:    A proxy can delete a header field value.

   r:    A proxy needs to be able to read the header field, and thus
         this header field cannot be encrypted.

   The rest of the columns relate to the presence of a header field in a
   method.  The method names when abbreviated, are according to Table 8:

   c:    Conditional; requirements on the header field depend on the
         context of the message.

   m:    The header field is mandatory.

   m*:   The header field SHOULD be sent, but clients/servers need to be
         prepared to receive messages without that header field.

   o:    The header field is optional.

   *:    The header field MUST be present if the message body is not
         empty.  See Section 16.16, Section 16.18 and Section 5.3 for
         details.

   -:    The header field is not applicable.

   "Optional" means that a Client/Server MAY include the header field in
   a request or response.  The Client/Server behavior when receiving
   such headers varies, for some it may ignore the header field, in
   other case it is request to process the header.  This is regulated by
   the method and header descriptions.  Example of headers that require
   processing are the Require and Proxy-Require header fields discussed
   in Section 16.42 and Section 16.35.  A "mandatory" header field MUST
   be present in a request, and MUST be understood by the Client/Server
   receiving the request.  A mandatory response header field MUST be
   present in the response, and the header field MUST be understood by
   the Client/Server processing the response.  "Not applicable" means
   that the header field MUST NOT be present in a request.  If one is
   placed in a request by mistake, it MUST be ignored by the Client/
   Server receiving the request.  Similarly, a header field labeled "not
   applicable" for a response means that the Client/Server MUST NOT
   place the header field in the response, and the Client/Server MUST
   ignore the header field in the response.

   An RTSP agent MUST ignore extension headers that are not understood.

   The From and Location header fields contain an URI.  If the URI
   contains a comma, or semicolon, the URI MUST be enclosed in double
   quotes (").  Any URI parameters are contained within these quotes.
   If the URI is not enclosed in double quotas, any semicolon- delimited
   parameters are header-parameters, not URI parameters.

   +----------------+------+-----+-----+-----+------+-----+------+-----+
   | Header         | Wher | Pro | DES | OPT | SETU | PLA | PAUS | TRD |
   |                | e    | xy  |     |     | P    | Y   | E    |     |
   +----------------+------+-----+-----+-----+------+-----+------+-----+
   | Accept         | R    |     | o   | -   | -    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Accept-Credent | R    | r   | o   | o   | o    | o   | o    | o   |
   | ials           |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Accept-Encodin | R    | r   | o   | -   | -    | -   | -    | -   |
   | g              |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Accept-Languag | R    | r   | o   | -   | -    | -   | -    | -   |
   | e              |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Accept-Ranges  | R    | r   | -   | -   | m    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Accept-Ranges  | r    | r   | -   | -   | o    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Accept-Ranges  | 456  | r   | -   | -   | -    | o   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Allow          | r    | am  | c   | c   | c    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Allow          | 405  | am  | m   | m   | m    | m   | m    | m   |
   |                |      |     |     |     |      |     |      |     |
   | Authorization  | R    |     | o   | o   | o    | o   | o    | o   |
   |                |      |     |     |     |      |     |      |     |
   | Bandwidth      | R    |     | o   | o   | o    | o   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Blocksize      | R    |     | o   | -   | o    | o   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Cache-Control  |      | r   | o   | -   | o    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Connection     |      |     | o   | o   | o    | o   | o    | o   |
   |                |      |     |     |     |      |     |      |     |
   | Connection-Cre | 470, | ar  | o   | o   | o    | o   | o    | o   |
   | dentials       | 407  |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Base   | r    |     | o   | -   | -    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Content-Base   | 4xx, |     | o   | o   | o    | o   | o    | o   |
   |                | 5xx  |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Encodi | R    | r   | -   | -   | -    | -   | -    | -   |
   | ng             |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Encodi | r    | r   | o   | -   | -    | -   | -    | -   |
   | ng             |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Encodi | 4xx, | r   | o   | o   | o    | o   | o    | o   |
   | ng             | 5xx  |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Langua | R    | r   | -   | -   | -    | -   | -    | -   |
   | ge             |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Langua | r    | r   | o   | -   | -    | -   | -    | -   |
   | ge             |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Langua | 4xx, | r   | o   | o   | o    | o   | o    | o   |
   | ge             | 5xx  |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Length | r    | r   | *   | -   | -    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Content-Length | 4xx, | r   | *   | *   | *    | *   | *    | *   |
   |                | 5xx  |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Locati | r    |     | o   | -   | -    | -   | -    | -   |
   | on             |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Locati | 4xx, |     | o   | o   | o    | o   | o    | o   |
   | on             | 5xx  |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | Content-Type   | r    |     | *   | -   | -    | -   | -    | -   |
   | Content-Type   | 4xx, |     | *   | *   | *    | *   | *    | *   |
   |                | 5xx  |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | CSeq           | Rc   | rm  | m   | m   | m    | m   | m    | m   |
   |                |      |     |     |     |      |     |      |     |
   | Date           |      | am  | o   | o   | o    | o   | o    | o   |
   |                |      |     |     |     |      |     |      |     |
   | MTag           | r    | r   | o   | -   | o    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Expires        | r    | r   | o   | -   | -    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | From           | R    | r   | o   | o   | o    | o   | o    | o   |
   |                |      |     |     |     |      |     |      |     |
   | If-Match       | R    | r   | -   | -   | o    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | If-Modified-Si | R    | r   | o   | -   | o    | -   | -    | -   |
   | nce            |      |     |     |     |      |     |      |     |
   |                |      |     |     |     |      |     |      |     |
   | If-None-Match  | R    | r   | o   | -   | -    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Last-Modified  | r    | r   | o   | -   | -    | -   | -    | -   |
   |                |      |     |     |     |      |     |      |     |
   | Location       | 3rr  |     | o   | o   | o    | o   | o    | o   |
   +----------------+------+-----+-----+-----+------+-----+------+-----+

     Table 9: Overview of RTSP header fields (A-L) related to methods
           DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.

   +--------------+-------+------+----+----+------+------+-------+-----+
   | Header       | Where | Prox | DE | OP | SETU | PLAY | PAUSE | TRD |
   |              |       | y    | S  | T  | P    |      |       |     |
   +--------------+-------+------+----+----+------+------+-------+-----+
   | Media-       |       |      | -  | -  | r    | r    | r     | -   |
   | Properties   |       |      |    |    |      |      |       |     |
   |              |       |      |    |    |      |      |       |     |
   | Media- Range |       |      | -  | -  | r    | r    | r     | -   |
   |              |       |      |    |    |      |      |       |     |
   | Pipelined-   |       | amdr | -  | o  | o    | o    | o     | o   |
   | Requests     |       |      |    |    |      |      |       |     |
   |              |       |      |    |    |      |      |       |     |
   | Proxy-       | 407   | amr  | m  | m  | m    | m    | m     | m   |
   | Authenticate |       |      |    |    |      |      |       |     |
   |              |       |      |    |    |      |      |       |     |
   | Proxy-       | R     | rd   | o  | o  | o    | o    | o     | o   |
   | Authorizatio |       |      |    |    |      |      |       |     |
   | n            |       |      |    |    |      |      |       |     |
   |              |       |      |    |    |      |      |       |     |
   | Proxy-       | R     | ar   | o  | o  | o    | o    | o     | o   |
   | Require      |       |      |    |    |      |      |       |     |
   |              |       |      |    |    |      |      |       |     |
   | Proxy-       | r     | r    | c  | c  | c    | c    | c     | c   |
   | Require      |       |      |    |    |      |      |       |     |
   |              |       |      |    |    |      |      |       |     |
   | Proxy-       | R     | amr  | c  | c  | c    | c    | c     | c   |
   | Supported    |       |      |    |    |      |      |       |     |
   |              |       |      |    |    |      |      |       |     |
   | Proxy-       | r     |      | c  | c  | c    | c    | c     | c   |
   | Supported    |       |      |    |    |      |      |       |     |
   |              |       |      |    |    |      |      |       |     |
   | Public       | r     | admr | -  | m  | -    | -    | -     | -   |
   |              |       |      |    |    |      |      |       |     |
   | Public       | 501   | admr | m  | m  | m    | m    | m     | m   |
   |              |       |      |    |    |      |      |       |     |
   | Range        | R     |      | -  | -  | -    | o    | -     | -   |
   |              |       |      |    |    |      |      |       |     |
   | Range        | r     |      | -  | -  | c    | m    | m     | -   |
   |              |       |      |    |    |      |      |       |     |
   | Terminate-Re | R     | r    | -  | -  | -    | -    | -     | -   |
   | ason         |       |      |    |    |      |      |       |     |
   |              |       |      |    |    |      |      |       |     |
   | Referer      | R     |      | o  | o  | o    | o    | o     | o   |
   |              |       |      |    |    |      |      |       |     |
   | Request-     | R     |      | -  | -  | -    | -    | -     | -   |
   | Status       |       |      |    |    |      |      |       |     |
   |              |       |      |    |    |      |      |       |     |
   | Require      | R     |      | o  | o  | o    | o    | o     | o   |
   |              |       |      |    |    |      |      |       |     |
   | Retry-After  | 3rr,5 |      | o  | o  | o    | -    | -     | -   |
   |              | 03    |      |    |    |      |      |       |     |
   |              |       |      |    |    |      |      |       |     |
   | Retry-After  | 413   |      | o  | o  | o    | o    | o     | o   |
   |              |       |      |    |    |      |      |       |     |
   | RTP-Info     | r     |      | -  | -  | c    | c    | -     | -   |
   |              |       |      |    |    |      |      |       |     |
   | Scale        |       |      | -  | -  | -    | o    | -     | -   |
   |              |       |      |    |    |      |      |       |     |
   | Seek-Style   | R     |      | -  | -  | -    | o    | -     | -   |
   |              |       |      |    |    |      |      |       |     |
   | Seek-Style   | r     |      | -  | -  | -    | m    | -     | -   |
   |              |       |      |    |    |      |      |       |     |
   | Session      | R     | r    | -  | o  | o    | m    | m     | m   |
   |              |       |      |    |    |      |      |       |     |
   | Session      | r     | r    | -  | c  | m    | m    | m     | o   |
   |              |       |      |    |    |      |      |       |     |
   | Server       | R     | r    | -  | o  | -    | -    | -     | -   |
   | Server       | r     | r    | o  | o  | o    | o    | o     | o   |
   |              |       |      |    |    |      |      |       |     |
   | Speed        |       |      | -  | -  | -    | o    | -     | -   |
   |              |       |      |    |    |      |      |       |     |
   | Supported    | R     | amr  | o  | o  | o    | o    | o     | o   |
   |              |       |      |    |    |      |      |       |     |
   | Supported    | r     | amr  | c  | c  | c    | c    | c     | c   |
   |              |       |      |    |    |      |      |       |     |
   | Timestamp    | R     | admr | o  | o  | o    | o    | o     | o   |
   |              |       |      |    |    |      |      |       |     |
   | Timestamp    | c     | admr | m  | m  | m    | m    | m     | m   |
   |              |       |      |    |    |      |      |       |     |
   | Transport    |       | amr  | -  | -  | m    | -    | -     | -   |
   |              |       |      |    |    |      |      |       |     |
   | Unsupported  | r     |      | c  | c  | c    | c    | c     | c   |
   |              |       |      |    |    |      |      |       |     |
   | User-Agent   | R     |      | m* | m* | m*   | m*   | m*    | m*  |
   |              |       |      |    |    |      |      |       |     |
   | Vary         | r     |      | c  | c  | c    | c    | c     | c   |
   |              |       |      |    |    |      |      |       |     |
   | Via          | R     | amr  | o  | o  | o    | o    | o     | o   |
   |              |       |      |    |    |      |      |       |     |
   | Via          | c     | dr   | m  | m  | m    | m    | m     | m   |
   |              |       |      |    |    |      |      |       |     |
   | WWW-         | 401   |      | m  | m  | m    | m    | m     | m   |
   | Authenticate |       |      |    |    |      |      |       |     |
   +--------------+-------+------+----+----+------+------+-------+-----+

     Table 10: Overview of RTSP header fields (P-W) related to methods
           DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN.

   +------------------------+---------+-------+-----+-----+-----+-----+
   | Header                 | Where   | Proxy | GPR | SPR | RDR | PNY |
   +------------------------+---------+-------+-----+-----+-----+-----+
   | Accept-Credentials     | R       | r     | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Allow                  | 405     | amr   | m   | m   | m   | -   |
   |                        |         |       |     |     |     |     |
   | Authorization          | R       |       | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Bandwidth              | R       |       | -   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Blocksize              | R       |       | -   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Connection             |         |       | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Connection-Credentials | 470,407 | ar    | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Base           | R       |       | o   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Base           | r       |       | o   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Base           | 4xx,5xx |       | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Encoding       | R       | r     | o   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Encoding       | r       | r     | o   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Encoding       | 4xx,5xx | r     | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Language       | R       | r     | o   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Language       | r       | r     | o   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Language       | 4xx,5xx | r     | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Length         | R       | r     | *   | *   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Length         | r       | r     | *   | *   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Length         | 4xx,5xx | r     | *   | *   | *   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Location       | R       |       | o   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Location       | r       |       | o   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Location       | 4xx,5xx |       | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Type           | R       |       | *   | *   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Type           | r       |       | *   | *   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Type           | 4xx     |       | *   | *   | *   | -   |
   |                        |         |       |     |     |     |     |
   | CSeq                   | R,c     | mr    | m   | m   | m   | m   |
   |                        |         |       |     |     |     |     |
   | Date                   | R       | a     | o   | o   | m   | -   |
   |                        |         |       |     |     |     | Proxy-     |
   | Date                   | r       | am    | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | From                   | R       | r     | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Last-Modified          | R       | r     | -   | -   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Last-Modified          | r       | r     | o   | -   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Location               | 3rr     |       | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Location               | R       |       | -   | -   | m   | -   |
   |                        |         |       |     |     |     |     |
   | Media-Properties       |         |       | -   | -   | -   |     |
   |                        |         |       |     |     |     |     |
   | Media-Range            | R       |       | o   | -   | -   | c   |
   |                        |         |       |     |     |     |     |
   | Media-Range            | r       |       | c   | -   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Notify-Reason          | R       |       | -   | -   | -   | m   |
   |                        |         |       |     |     |     |     |
   | Pipelined-Requests     |         | amdr  | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Proxy-Authenticate     | 407     | amr   | m   | m   | m   | -   |
   |                        |         |       |     |     |     |     |
   | Proxy-Authorization    | R       | rd    | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Proxy-Require          | R       | ar    | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Proxy-Require          | r       | r     | c   | c   | c   | -   |
   |                        |         |       |     |     |     |     |
   | Proxy-Supported        | R       | amr   | c   | c   | c   | -   | Supported
   |                        |         |       |     |     |     |     |
   | Proxy-Supported        | r       |       | c   | c   | c   | -   |
   |                        |         |       |     |     |     |     |
   | Public                 | r 501     | admr  | m   | m   | m   | -   |
   +------------------------+---------+-------+-----+-----+-----+-----+

     Table 11: Overview of RTSP header fields (A-P) related to methods
         GET_PARAMETER, SET_PARAMETER, PLAY_NOTIFY, and REDIRECT.

    +------------------+-------------+-------+-----+-----+-----+-----+
    | Header           | Where       | Proxy | GPR | SPR | RDR | PNY |
    +------------------+-------------+-------+-----+-----+-----+-----+
    | Range            | R           |       | -   | -   | o   | m   |
    |                  |             |       |     |     |     |     |
    | Terminate-Reason | R           | r     | -   | -   | m   | -   |
    |                  |             |       |     |     |     |     |
    | Referer          | R           |       | o   | o   | o   | -   |
    |                  |             |       |     |     |     |     |
    | Request-Status   | R           |       | -   | -   | -   | m   |
    |                  |             |       |     |     |     |     |
    | Require          | R           | r     | o   | o   | o   | -   |
    |                  |             |       |     |     |     |     |
    | Retry-After      | 3rr,413,503 |       | o   | o   | -   | -   |
    |                  |             |       |     |     |     |     |
    | Retry-After      | 413         |       | o   | o   | Public o   | 501 o   | admr
    | m Scale            | m             | m       | m -   | m -   | m -   | c   |
    |                  |             |       |     |     |     |     |
    | Seek-Style       | Range             | R       | -   | -   | -   | -   | o
    | -                  | -             |       |     |     |     |     |
    | Session          | R           | r     | o   | o   | o   | m   |
    |                  | Range             | r       |     | -     | -     | c     | m
    | m Session          | - r           | r     | c   | c   | o   | m   |
    |                  |             |       |     |     | Referer     | R     |
    | o Server           | o R           | o r     | o   | o   | o   | -   |
    |                  |             |       |     |     |     |     |
    | Server           | Request-   | R     |      | - r           | - r     | - o   | - o   | -   | -   |
    | Status                  |             |       |     |     |     |     |
    | Supported        | R           | adrm  | o   | o   | o   | -   |
    |                  |             |       |     | Require     | R     |     | o
    | o Supported        | o r           | o adrm  | o c   | o c   | c   | -   |
    |                  |             |       |     |     |     |     |
    | Retry-Afte Timestamp        | 3rr,5 R           | adrm  | o   | o   | o   | -   | -
    | -                  |             | r       | 03     |     |     |     |
    | Timestamp        | c           | adrm  | m   | m   | m   | -   |
    |                  |             |       |     |     |     | RTP-Info     | r
    | Unsupported      | - r           | - arm   | c   | c   | - c   | -   |
    |                  |             |       |     |     |     |     |
    | User-Agent       | R           | Scale      | r     | m*  | - m*  | -   | -   | o
    | -                  | -             |       |     |     |     |     |
    | User-Agent       | r           | r     | -   | -   | Seek-Style m*  | R -   |
    | -                  | -             | -       | o     | -     | -     |     |
    | Vary             | r           |       | c   | c   | -   | -   |
    |                  | Seek-Style             | r       |     | -     | -     | -     | m
    | - Via              | - R           | amr   | o   | o   | o   | -   |
    |                  |             |       |     |     | Session     | R     | r
    | - Via              | o c           | o dr    | m   | m   | m   | -   |
    |                  |             |       |     |     |     |     |
    | WWW-Authenticate | 401         |       | m   | m   | m   | -   |
    +------------------+-------------+-------+-----+-----+-----+-----+

     Table 12: Overview of RTSP header fields (R-W) related to methods
         GET_PARAMETER, SET_PARAMETER,  PLAY_NOTIFY, and REDIRECT.

16.1.  Accept

   The Accept request-header field can be used to specify certain
   presentation description content types which are acceptable for the
   response.

   See Section 20.2.3 for the syntax.

   Example of use:
     Accept: application/example ;q=1.0, application/sdp

16.2.  Accept-Credentials

   The Accept-Credentials header is a request header used to indicate to
   any trusted intermediary how to handle further secured connections to
   proxies or servers.  See Section 19 for the usage of this header.  It
   MUST NOT be included in server to client requests.

   In a request the header MUST contain the method (User, Proxy, or Any)
   for approving credentials selected by the requester.  The method MUST
   NOT be changed by any proxy, unless it is "proxy" when a proxy MAY
   change it to "user" to take the role of user approving each further
   hop.  If the method is "User" the header contains zero or more of
   credentials that the client accepts.  The header may contain zero
   credentials in the first RTSP request to a RTSP server when using the
   "User" method.  This as the client has not yet received any
   credentials to accept.  Each credential MUST consist of one URI
   identifying the proxy or server, the hash algorithm identifier, and
   the hash over that entity's DER encoded certificate [RFC5280] in
   Base64 [RFC4648].  All RTSP clients and proxies MUST implement the
   SHA-256[FIPS-pub-180-2] algorithm for computation of the hash of the
   DER encoded certificate.  The SHA-256 algorithm is identified by the
   token "sha-256".

   The intention with allowing for other hash algorithms is to enable
   the future retirement of algorithms that are not implemented
   somewhere else than here.  Thus the definition of future algorithms
   for this purpose is intended to be extremely limited.  A feature tag
   can be used to ensure that support for the replacement algorithm
   exist.

   Example:
   Accept-Credentials:User
     "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=,
     "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M=

16.3.  Accept-Encoding

   The Accept-Encoding request-header field is similar to Accept, but
   restricts the content-codings that are acceptable in the response.

   A server tests whether a content-coding is acceptable, according to
   an Accept-Encoding field, using these rules:

   1.  If the content-coding is one of the content-codings listed in the
       Accept-Encoding field, then it is acceptable, unless it is
       accompanied by a qvalue of 0.  (As defined in section 3.9, a
       qvalue of 0 means "not acceptable.")
   2.  The special "*" symbol in an Accept-Encoding field matches any
       available content-coding not explicitly listed in the header
       field.

   3.  If multiple content-codings are acceptable, then the acceptable
       content-coding with the highest non-zero qvalue is preferred.

   4.  The "identity" content-coding is always acceptable, unless
       specifically refused because the Accept-Encoding field includes
       "identity;q=0", or because the field includes "*;q=0" and does
       not explicitly include the "identity" content-coding.  If the
       Accept-Encoding field-value is empty, then only the "identity"
       encoding is acceptable.

   If an Accept-Encoding field is present in a request, and if the
   server cannot send a response which is acceptable according to the
   Accept-Encoding header, then the server SHOULD send an error response
   with the 406 (Not Acceptable) status code.

   If no Accept-Encoding field is present in a request, the server MAY
   assume that the client will accept any content coding.  In this case,
   if "identity" is one of the available content-codings, then the
   server SHOULD use the "identity" content-coding, unless it has
   additional information that a different content-coding is meaningful
   to the client.

16.4.  Accept-Language

   The Accept-Language request-header field is similar to Accept, but
   restricts the set of natural languages that are preferred as a
   response to the request.  Note that the language specified applies to
   the presentation description and any reason phrases, but not the
   media content.

   A language tag identifies a natural language spoken, written, or
   otherwise conveyed by human beings for communication of information
   to other human beings.  Computer languages are explicitly excluded.
   The syntax and registry of RTSP 2.0 language tags is the same as that
   defined by [RFC4646].

   Each language-range MAY be given an associated quality value which
   represents an estimate of the user's preference for the languages
   specified by that range.  The quality value defaults to "q=1".  For
   example:

      Accept-Language: da, en-gb;q=0.8, en;q=0.7

   would mean: "I prefer Danish, but will accept British English and
   other types of English."  A language-range matches a language-tag if
   it exactly equals the tag, or if it exactly equals a prefix of the
   tag such that the first tag character following the prefix is "-".
   The special range "*", if present in the Accept-Language field,
   matches every tag not matched by any other range present in the
   Accept-Language field.

      Note: This use of a prefix matching rule does not imply that
      language tags are assigned to languages in such a way that it is
      always true that if a user understands a language with a certain
      tag, then this user will also understand all languages with tags
      for which this tag is a prefix.  The prefix rule simply allows the
      use of prefix tags if this is the case.

   The language quality factor assigned to a language-tag by the Accept-
   Language field is the quality value of the longest language- range in
   the field that matches the language-tag.  If no language- range in
   the field matches the tag, the language quality factor assigned is 0.
   If no Accept-Language header is present in the request, the server
   SHOULD assume that all languages are equally acceptable.  If an
   Accept-Language header is present, then all languages which are
   assigned a quality factor greater than 0 are acceptable.

16.5.  Accept-Ranges

   The Accept-Ranges request and response-header field allows indication
   of the format supported in the Range header.  The client MUST include
   the header in SETUP requests to indicate which formats it support to
   receive in PLAY and PAUSE responses, and REDIRECT requests.  The
   server MUST include the header in SETUP and 456 error responses to
   indicate the formats supported for the resource indicated by the
   request URI.  The header MAY be included in GET_PARAMETER request and
   response pairs.  The GET_PARAMETER request MUST contain a Session    | r     | r    | -  | c   | m     | m    | m     | o   |
   |            |       |      |    |     |       |      |       |     |
   | Server     | R     | r    | -  | o   | -     | -    | -     | -   |
   |            |       |      |    |     |       |      |       |     |
   | Server     | r     | r    | o  | o   | o     | o    | o     | o   |
   |            |       |      |    |     |       |      |       |     |
   | Speed      |       |      | -  | -   | -     | o    | -     | -   |
   |            |       |      |    |     |       |      |       |     |
   | Supported  | R     | amr  | o  | o   | o     | o    | o     | o   |
   |            |       |      |    |     |       |      |       |     |
   | Supported  | r     | amr  | c  | c   | c     | c    | c     | c   |
   |            |       |      |    |     |       |      |       |     |
   | Timestamp  | R     | admr | o  | o   | o     | o    | o     | o   |
   |            |       |      |    |     |       |      |       |     |
   | Timestamp  | c     | admr | m  | m   | m     | m    | m     | m   |
   |            |       |      |    |     |       |      |       |     |
   | Transport  |       | amr  | -  | -   | m     | -    | -     | -   |
   |            |       |      |    |     |       |      |       |     |
   | Unsupporte | r     |      | c  | c   | c     | c    | c     | c   |
   | d          |       |      |    |     |       |      |       |     |
   |            |       |      |    |     |       |      |       |     |
   | User-Agent | R     |      | m* | m*  | m*    | m*   | m*    | m*  |
   |            |       |      |    |     |       |      |       |     |
   | Vary       | r     |      | c  | c   | c     | c    | c     | c   |
   |            |       |      |    |     |       |      |       |     |
   | Via        | R     | amr  | o  | o   | o     | o    | o     | o   |
   |            |       |      |    |     |       |      |       |     |
   | Via        | c     | dr   | m  | m   | m     | m    | m     | m   |
   |            |       |      |    |     |       |      |       |     |
   | WWW-       |
   header to identify the session context the request are related to.
   The requester and responder will indicate their capabilities
   regarding Range formats respectively.
      Accept-Ranges: NPT, SMPTE

   The syntax is defined in Section 20.2.3.

16.6.  Allow

   The Allow message-header field lists the methods supported by the
   resource identified by the Request-URI.  The purpose of this field is
   to strictly inform the recipient of valid methods associated with the
   resource.  An Allow header field MUST be present in a 405 (Method Not
   Allowed) response.  The Allow header MUST also be present in all
   OPTIONS responses where the content of the header will not include
   exactly the same methods as listed in the Public header.

   The Allow MUST also be included in SETUP and DESCRIBE responses, if
   the methods allowed for the resource is different than the minimal
   implementation set.

   Example of use:
      Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE

16.7.  Authorization

   An RTSP client that wishes to authenticate itself with a server,
   usually, but not necessarily, after receiving a 401   |      | m  | m   | m     | m    | m     | m   |
   | Authentica |       |      |    |     |       |      |       |     |
   | te         |       |      |    |     |       |      |       |     |
   +------------+-------+------+----+-----+-------+------+-------+-----+

     Table 10: Overview response, does so
   by including an Authorization request-header field with the request.
   The Authorization field value consists of credentials containing the
   authentication information of the user agent for the realm of the
   resource being requested.

   If a request is authenticated and a realm specified, the same
   credentials SHOULD be valid for all other requests within this realm
   (assuming that the authentication scheme itself does not require
   otherwise, such as credentials that vary according to a challenge
   value or using synchronized clocks).

   When a shared cache (see Section 18) receives a request containing an
   Authorization field, it MUST NOT return the corresponding response as
   a reply to any other request, unless one of the following specific
   exceptions holds:

   1.  If the response includes the "maxage" cache-control directive,
       the cache MAY use that response in replying to a subsequent
       request.  But (if the specified maximum age has passed) a proxy
       cache MUST first revalidate it with the origin server, using the
       request-headers from the new request to allow the origin server
       to authenticate the new request.  (This is the defined behavior
       for maxage.)  If the response includes "maxage=0", the proxy MUST
       always revalidate it before re-using it.

   2.  If the response includes the "must-revalidate" cache-control
       directive, the cache MAY use that response in replying to a
       subsequent request.  But if the response is stale, all caches
       MUST first revalidate it with the origin server, using the
       request-headers from the new request to allow the origin server
       to authenticate the new request.

   3.  If the response includes the "public" cache-control directive, it
       MAY be returned in reply to any subsequent request.

16.8.  Bandwidth

   The Bandwidth request-header field describes the estimated bandwidth
   available to the client, expressed as a positive integer and measured
   in bits per second.  The bandwidth available to the client may change
   during an RTSP session, e.g., due to mobility, congestion, etc.

   Example:
     Bandwidth: 62360

16.9.  Blocksize

   The Blocksize request-header field is sent from the client to the
   media server asking the server for a particular media packet size.
   This packet size does not include lower-layer headers such as IP,
   UDP, or RTP.  The server is free to use a blocksize which is lower
   than the one requested.  The server MAY truncate this packet size to
   the closest multiple of the minimum, media-specific block size, or
   override it with the media-specific size if necessary.  The block
   size MUST be a positive decimal number, measured in octets.  The
   server only returns an error (4xx) if the value is syntactically
   invalid.

16.10.  Cache-Control

   The Cache-Control general-header field is used to specify directives
   that MUST be obeyed by all caching mechanisms along the request/
   response chain.

   Cache directives MUST be passed through by a proxy or gateway
   application, regardless of their significance to that application,
   since the directives may be applicable to all recipients along the
   request/response chain.  It is not possible to specify a cache-
   directive for a specific cache.

   Cache-Control should only be specified in a SETUP request and its
   response.  Note: Cache-Control does not govern the caching of
   responses as for HTTP, instead it applies to the media stream
   identified by the SETUP request.  The RTSP requests are generally not
   cacheable, for further information see Section 18.  Below is the
   description of the cache directives that can be included in the
   Cache-Control header.

   no-cache:  Indicates that the media stream MUST NOT be cached
         anywhere.  This allows an origin server to prevent caching even
         by caches that have been configured to return stale responses
         to client requests.  Note, there is no security function
         enforcing that the content can't be cached.

   public:  Indicates that the media stream is cacheable by any cache.

   private:  Indicates that the media stream is intended for a single
         user and MUST NOT be cached by a shared cache.  A private (non-
         shared) cache may cache the media streams.

   no-transform:  An intermediate cache (proxy) may find it useful to
         convert the media type of a certain stream.  A proxy might, for
         example, convert between video formats to save cache space or
         to reduce the amount of traffic on a slow link.  Serious
         operational problems may occur, however, when these
         transformations have been applied to streams intended for
         certain kinds of applications.  For example, applications for
         medical imaging, scientific data analysis and those using end-
         to-end authentication all depend on receiving a stream that is
         bit-for-bit identical to the original media stream.  Therefore,
         if a response includes the no-transform directive, an
         intermediate cache or proxy MUST NOT change the encoding of the
         stream.  Unlike HTTP, RTSP does not provide for partial
         transformation at this point, e.g., allowing translation into a
         different language.

   only-if-cached:  In some cases, such as times of extremely poor
         network connectivity, a client may want a cache to return only
         those media streams that it currently has stored, and not to
         receive these from the origin server.  To do this, the client
         may include the only-if-cached directive in a request.  If it
         receives this directive, a cache SHOULD either respond using a
         cached media stream that is consistent with the other
         constraints of the request, or respond with a 504 (Gateway
         Timeout) status.  However, if a group of caches is being
         operated as a unified system with good internal connectivity,
         such a request MAY be forwarded within that group of caches.

   max-stale:  Indicates that the client is willing to accept a media
         stream that has exceeded its expiration time.  If max-stale is
         assigned a value, then the client is willing to accept a
         response that has exceeded its expiration time by no more than
         the specified number of seconds.  If no value is assigned to
         max-stale, then the client is willing to accept a stale
         response of any age.

   min-fresh:  Indicates that the client is willing to accept a media
         stream whose freshness lifetime is no less than its current age
         plus the specified time in seconds.  That is, the client wants
         a response that will still be fresh for at least the specified
         number of seconds.

   must-revalidate:  When the must-revalidate directive is present in a
         SETUP response received by a cache, that cache MUST NOT use the
         entry after it becomes stale to respond to a subsequent request
         without first revalidating it with the origin server.  That is,
         the cache is required to do an end-to-end revalidation every
         time, if, based solely on the origin server's Expires, the
         cached response is stale.)

   proxy-revalidate:  The proxy-revalidate directive has the same
         meaning as the must-revalidate directive, except that it does
         not apply to non-shared user agent caches.  It can be used on a
         response to an authenticated request to permit the user's cache
         to store and later return the response without needing to
         revalidate it (since it has already been authenticated once by
         that user), while still requiring proxies that service many
         users to revalidate each time (in order to make sure that each
         user has been authenticated).  Note that such authenticated
         responses also need the public cache control directive in order
         to allow them to be cached at all.

   max-age:  When an intermediate cache is forced, by means of a max-
         age=0 directive, to revalidate its own cache entry, and the
         client has supplied its own validator in the request, the
         supplied validator might differ from the validator currently
         stored with the cache entry.  In this case, the cache MAY use
         either validator in making its own request without affecting
         semantic transparency.

   However, the choice of validator might affect performance.  The best
   approach is for the intermediate cache to use its own validator when
   making its request.  If the server replies with 304 (Not Modified),
   then the cache can return its now validated copy to the client with a
   200 (OK) response.  If the server replies with a new entity and cache
   validator, however, the intermediate cache can compare the returned
   validator with the one provided in the client's request, using the
   strong comparison function.  If the client's validator is equal to
   the origin server's, then the intermediate cache simply returns 304
   (Not Modified).  Otherwise, it returns the new entity with a 200 (OK)
   response.

16.11.  Connection

   The Connection general-header field allows the sender to specify
   options that are desired for that particular connection and MUST NOT
   be communicated by proxies over further connections.

   RTSP 2.0 proxies MUST parse the Connection header fields (P-W) related field before a
   message is forwarded and, for each connection-token in this field,
   remove any header field(s) from the message with the same name as the
   connection-token.  Connection options are signaled by the presence of
   a connection-token in the Connection header field, not by any
   corresponding additional header field(s), since the additional header
   field may not be sent if there are no parameters associated with that
   connection option.

   Message headers listed in the Connection header MUST NOT include end-
   to-end headers, such as Cache-Control.

   The use of the connection option "close" in RTSP messages SHOULD be
   limited to methods
           DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, error messages when the server is unable to recover and TEARDOWN.

   +------------------------+---------+-------+-----+-----+-----+-----+
   | Header                 | Where   | Proxy | GPR | SPR | RDR | PNY |
   +------------------------+---------+-------+-----+-----+-----+-----+
   | Accept-Credentials     | R       | r     | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Allow                  | 405     | amr   | m   | m   | m   | -   |
   |                        |         |       |     |     |     |     |
   | Authorization          | R       |       | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Bandwidth              | R       |       | -   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Blocksize              | R       |       | -   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Connection             |         |       | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   |
   therefore see it necessary to close the connection.  The reason is
   that the client has the choice of continuing using a connection
   indefinitely, as long as it sends valid messages.

16.12.  Connection-Credentials

   The Connection-Credentials response header is used to carry the chain
   of credentials of any next hop that need to be approved by the
   requester.  It MUST only be used in server to client responses.

   The Connection-Credentials header in an RTSP response MUST, if
   included, contain the credential information (in form of a list of
   certificates providing the chain of certification) of the next hop
   that an intermediary needs to securely connect to.  The header MUST
   include the URI of the next hop (proxy or server) and a base64
   [RFC4648] encoded binary structure containing a sequence of DER
   encoded X.509v3 certificates[RFC5280] .

   The binary structure starts with the number of certificates
   (NR_CERTS) included as a 16 bit unsigned integer.  This is followed
   by NR_CERTS number of 16 bit unsigned integers providing the size in
   octets of each DER encoded certificate.  This is followed by NR_CERTS
   number of DER encoded X.509v3 certificates in a sequence (chain).
   The proxy or server's certificate must come first in the structure.
   Each following certificate must directly certify the one preceding
   it.  Because certificate validation requires that root keys be
   distributed independently, the self-signed certificate which
   specifies the root certificate authority may optionally be omitted
   from the chain, under the assumption that the remote end must already
   possess it in order to validate it in any case.

   Example:

   Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC...

   Where MIIDNTCC... is a BASE64 encoding of the following structure:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | 470,407 | ar    | o   | o   | o   | -   |
   |                        |         |       |  Number of certificates       | Size of certificate #1        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Size of certificate #2        | Size of certificate #3        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       : DER Encoding of Certificate #1                                :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       : DER Encoding of Certificate #2                                :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       : DER Encoding of Certificate #3                                :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

16.13.  Content-Base           | R       |       | o   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   |

   The Content-Base           | r       |       | o   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | message-header field may be used to specify the base
   URI for resolving relative URIs within the message body.
   Content-Base: rtsp://media.example.com/movie/twister
   If no Content-Base           | 4xx,5xx |       | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | field is present, the base URI of an message body
   is defined either by its Content-Location (if that Content-Location
   URI is an absolute URI) or the URI used to initiate the request, in
   that order of precedence.  Note, however, that the base URI of the
   contents within the message-body may be redefined within that
   message-body.

16.14.  Content-Encoding       | R       | r     | o   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   |

   The Content-Encoding       | r       | r     | o   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | header field is used as a modifier to the media-
   type.  When present, its value indicates what additional content
   codings have been applied to the message body, and thus what decoding
   mechanisms must be applied in order to obtain the media-type
   referenced by the Content-Type header field.  Content-Encoding       | 4xx,5xx | r     | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | is
   primarily used to allow a document to be compressed without losing
   the identity of its underlying media type.

   The content-coding is a characteristic of the entity identified by
   the Request-URI.  Typically, the message body is stored with this
   encoding and is only decoded before rendering or analogous usage.

   However, a non-transparent proxy MAY modify the content-coding if the
   new coding is known to be acceptable to the recipient, unless the
   "no-transform" cache-control directive is present in the message.

   If the content-coding of an message body is not "identity", then the
   response MUST include a Content-Encoding entity-header that lists the
   non-identity content-coding(s) used.

   If the content-coding of an message body in a request message is not
   acceptable to the origin server, the server SHOULD respond with a
   status code of 415 (Unsupported Media Type).

   If multiple encodings have been applied to a message body, the
   content codings MUST be listed in the order in which they were
   applied.  Additional information about the encoding parameters MAY be
   provided by other header fields not defined by this specification.

16.15.  Content-Language       | R       | r     | o   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   |

   The Content-Language       | r       | r     | o   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | header field describes the natural language(s)
   of the intended audience for the enclosed message body.  Note that
   this might not be equivalent to all the languages used within the
   message body.

   Language tags are mentioned in Section 16.4.  The primary purpose of
   Content-Language       | 4xx,5xx | r     | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | is to allow a user to identify and differentiate
   entities according to the user's own preferred language.  Thus, if
   the body content is intended only for a Danish-literate audience, the
   appropriate field is

      Content-Language: da

   If no Content-Language is specified, the default is that the content
   is intended for all language audiences.  This might mean that the
   sender does not consider it to be specific to any natural language,
   or that the sender does not know for which language it is intended.

   Multiple languages MAY be listed for content that is intended for
   multiple audiences.  For example, a rendition of the "Treaty of
   Waitangi," presented simultaneously in the original Maori and English
   versions, would call for

      Content-Language: mi, en

   However, just because multiple languages are present within an entity
   does not mean that it is intended for multiple linguistic audiences.
   An example would be a beginner's language primer, such as "A First
   Lesson in Latin," which is clearly intended to be used by an English-
   literate audience.  In this case, the Content-Language would properly
   only include "en".

   Content-Language MAY be applied to any media type -- it is not
   limited to textual documents.

16.16.  Content-Length         | R       | r     | *   | *   | -   | -   |
   |                        |         |       |     |     |     |     |
   |

   The Content-Length         | r       | r     | *   | *   | -   | -   |
   |                        |         |       |     |     |     |     |
   | general-header field contains the length of the
   message body of the RTSP message (i.e. after the double CRLF
   following the last header).  Unlike HTTP, it MUST be included in all
   messages that carry a message body beyond the header portion of the
   RTSP message.  If it is missing, a default value of zero is assumed.
   Any Content-Length         | 4xx,5xx | r     | *   | *   | *   | -   |
   |                        |         |       |     |     |     |     |
   | greater than or equal to zero is a valid value.

16.17.  Content-Location

   The Content-Location header field MAY be used to supply the resource
   location for the entity enclosed in the message when that entity is
   accessible from a location separate from the requested resource's
   URI.  A server SHOULD provide a Content-Location for the variant
   corresponding to the response entity; especially in the case where a
   resource has multiple entities associated with it, and those entities
   actually have separate locations by which they might be individually
   accessed, the server SHOULD provide a Content-Location       | R       |       | o   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | for the
   particular variant which is returned.

   The Content-Location       | r       |       | o   | o   | -   | -   |
   |                        |         |       |     |     |     |     |
   | value is not a replacement for the original
   requested URI; it is only a statement of the location of the resource
   corresponding to this particular entity at the time of the request.
   Future requests MAY specify the Content-Location       | 4xx,5xx |       | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Content-Type           | R       |       | *   | *   | -   | -   |
   |                        |         |       |     |     |     |     |
   | URI as the request-
   URI if the desire is to identify the source of that particular
   entity.

   A cache cannot assume that an entity with a Content-Location
   different from the URI used to retrieve it can be used to respond to
   later requests on that Content-Location URI.  However, the Content-
   Location can be used to differentiate between multiple entities
   retrieved from a single requested resource.

   If the Content-Location is a relative URI, the relative URI is
   interpreted relative to the Request-URI.

16.18.  Content-Type           | r       |       | *   | *   | -   | -   |
   |                        |         |       |     |     |     |     |
   |

   The Content-Type           | 4xx     |       | *   | *   | *   | -   |
   |                        |         |       |     |     |     |     |
   | header indicates the media type of the message body
   sent to the recipient.  Note that the content types suitable for RTSP
   are likely to be restricted in practice to presentation descriptions
   and parameter-value types.

16.19.  CSeq                   | R,c     | mr    | m   | m   | m   | m   |
   |                        |         |       |     |     |     |     |
   |

   The CSeq general-header field specifies the sequence number for an
   RTSP request-response pair.  This field MUST be present in all
   requests and responses.  For every RTSP request containing the given
   sequence number, the corresponding response will have the same
   number.  Any retransmitted request MUST contain the same sequence
   number as the original (i.e. the sequence number is not incremented
   for retransmissions of the same request).  For each new RTSP request
   the CSeq value MUST be incremented by one.  The initial sequence
   number MAY be any number, however it is RECOMMENDED to start at 0.
   Each sequence number series is unique between each requester and
   responder, i.e. the client has one series for its request to a server
   and the server has another when sending request to the client.  Each
   requester and responder is identified with its network address.

   Proxies that aggregate several sessions on the same transport will
   regularly need to renumber the CSeq header field in requests and
   responses to fulfill the rules for the header.

   Example:
   CSeq: 239

16.20.  Date

   The Date header field represents the date and time at which the
   message was originated.  The inclusion of the Date header in RTSP
   message follows these rules:

   o  An RTSP message, sent either by the client or the server,
      containing a body MUST include a Date                   | R       | header, if the sending host
      has a     | clock;

   o   |  Clients and servers are RECOMMENDED to include a Date header in
      all other RTSP messages, if the sending host has a clock;

   o   | m   | -   |
   |                        |         |       |     |     |     |     |
   |  If the server does not have a clock that can provide a reasonable
      approximation of the current time, its responses MUST NOT include
      a Date header field.  In this case, this rule MUST be followed:
      Some origin server implementations might not have a clock
      available.  An origin server without a clock MUST NOT assign
      Expires or Last- Modified values to a response, unless these
      values were associated with the resource by a system or user with
      a reliable clock.  It MAY assign an Expires value that is known,
      at or before server configuration time, to be in the past (this
      allows "pre-expiration" of responses without storing separate
      Expires values for each resource).

   A received message that does not have a Date header field MUST be
   assigned one by the recipient if the message will be cached by that
   recipient .  An RTSP implementation without a clock MUST NOT cache
   responses without revalidating them on every use.  An RTSP cache,
   especially a shared cache, SHOULD use a mechanism, such as NTP, to
   synchronize its clock with a reliable external standard.

   The RTSP-date sent in a Date header SHOULD NOT represent a date and
   time subsequent to the generation of the message.  It SHOULD
   represent the best available approximation of the date and time of
   message generation, unless the implementation has no means of
   generating a reasonably accurate date and time.  In theory, the date
   ought to represent the moment just before the entity is generated.
   In practice, the date can be generated at any time during the message
   origination without affecting its semantic value.

16.21.  Expires

   The Expires message-header field gives a date and time after which
   the description or media-stream should be considered stale.  The
   interpretation depends on the method:

   DESCRIBE response:  The Expires header indicates a date and time
         after which the presentation description (body) SHOULD be
         considered stale.

   SETUP response:  The Expires header indicate a date and time after
         which the media stream SHOULD be considered stale.

   A stale cache entry may not normally be returned by a cache (either a
   proxy cache or an user agent cache) unless it is first validated with
   the origin server (or with an intermediate cache that has a fresh
   copy of the message body).  See Section 18 for further discussion of
   the expiration model.

   The presence of an Expires field does not imply that the original
   resource will change or cease to exist at, before, or after that
   time.

   Editor's note: The below line is contradicting, as HTTP-date also
   allows rfc850 and ASCII style (see [H3.3]);

   The format is an absolute date and time as defined by RTSP-date:

   An example of its use is
     Expires: Thu, 01 Dec 1994 16:00:00 GMT
   RTSP/2.0 clients and caches MUST treat other invalid date formats,
   especially including the value "0", as having occurred in the past
   (i.e., already expired).

   To mark a response as "already expired," an origin server should use
   an Expires date that is equal to the Date                   | r       | am    | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | header value.  To mark a
   response as "never expires," an origin server SHOULD use an Expires
   date approximately one year from the time the response is sent.
   RTSP/2.0 servers SHOULD NOT send Expires dates more than one year in
   the future.

16.22.  From                   | R       | r     | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Last-Modified          | R       | r     | -   | -   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Last-Modified          | r       | r     | o   | -   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Location               | 3rr     |       | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Location               | R       |       | -   | -   | m   | -   |
   |                        |         |       |     |     |     |     |
   | Media-Properties       |         |       | -   | -   | -   |     |
   |                        |         |       |     |     |     |     |
   | Media-Range            | R       |       | o   | -   | -   | c   |
   |                        |         |       |     |     |     |     |
   | Media-Range            | r       |       | c   | -   | -   | -   |
   |                        |         |       |     |     |     |     |
   | Notify-Reason          | R       |       | -   | -   | -   | m   |
   |                        |         |       |     |     |     |     |
   | Pipelined-Requests     |         | amdr  | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Proxy-Authenticate     | 407     | amr   | m   | m   | m   | -   |
   |                        |         |       |     |     |     |     |
   | Proxy-Authorization    | R       | rd    | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Proxy-Require          | R       | ar    | o   | o   | o   | -   |
   |                        |         |       |     |     |     |     |
   | Proxy-Require          | r       | r     | c   | c   | c   | -   |
   |                        |         |       |     |     |     |     |
   | Proxy-Supported        | R       | amr   | c   | c   | c   | -   |
   |                        |         |       |     |     |     |     |
   | Proxy-Supported        | r       |       | c   | c   | c   | -   |
   |                        |         |       |     |     |     |     |
   | Public                 | 501     | admr  | m   | m   | m   | -   |
   +------------------------+---------+-------+-----+-----+-----+-----+

     Table 11: Overview

   The From request-header field, if given, SHOULD contain an Internet
   e-mail address for the human user who controls the requesting user
   agent.  The address SHOULD be machine-usable, as defined by "mailbox"
   in [RFC1123].

   This header field MAY be used for logging purposes and as a means for
   identifying the source of invalid or unwanted requests.  It SHOULD
   NOT be used as an insecure form of access protection.  The
   interpretation of this field is that the request is being performed
   on behalf of the person given, who accepts responsibility for the
   method performed.  In particular, robot agents SHOULD include this
   header so that the person responsible for running the robot can be
   contacted if problems occur on the receiving end.

   The Internet e-mail address in this field MAY be separate from the
   Internet host which issued the request.  For example, when a request
   is passed through a proxy the original issuer's address SHOULD be
   used.

   The client SHOULD NOT send the From header field without the user's
   approval, as it might conflict with the user's privacy interests or
   their site's security policy.  It is strongly recommended that the
   user be able to disable, enable, and modify the value of this field
   at any time prior to a request.

16.23.  If-Match

   See [H14.24].

   The If-Match request-header field is especially useful for ensuring
   the integrity of the presentation description, in both the case where
   it is fetched via means external to RTSP (such as HTTP), or in the
   case where the server implementation is guaranteeing the integrity of
   the description between the time of the DESCRIBE message and the
   SETUP message.  By including the MTag given in or with the session
   description in a SETUP request, the client ensures that resources set
   up are matching the description.  A SETUP request for which the MTag
   validation check fails, MUST response using 412 (Precondition
   Failed).

   This validation check is also very useful if a session has been
   redirected from one server to another.

16.24.  If-Modified-Since

   The If-Modified-Since request-header field is used with the DESCRIBE
   and SETUP methods to make them conditional.  If the requested variant
   has not been modified since the time specified in this field, a
   description will not be returned from the server (DESCRIBE) or a
   stream will not be set up (SETUP).  Instead, a 304 (Not Modified)
   response MUST be returned without any message-body.

   An example of the field is:
     If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

16.25.  If-None-Match

   This request header can be used with one or several message body tags
   to make DESCRIBE requests conditional.  A client that has one or more
   message bodies previously obtained from the resource, can verify that
   none of those entities is current by including a list of their
   associated message body tags in the If-None-Match header field.  The
   purpose of this feature is to allow efficient updates of cached
   information with a minimum amount of transaction overhead.  As a
   special case, the value "*" matches any current entity of the
   resource.

   If any of the message body tags match the message body tag of the
   message body that would have been returned in the response to a
   similar DESCRIBE request (without the If-None-Match header) on that
   resource, or if "*" is given and any current entity exists for that
   resource, then the server MUST NOT perform the requested method,
   unless required to do so because the resource's modification date
   fails to match that supplied in an If-Modified-Since header field in
   the request.  Instead, if the request method was DESCRIBE, the server
   SHOULD respond with a 304 (Not Modified) response, including the
   cache- related header fields (A-P) related (particularly MTag) of one of the
   message bodies that matched.  For all other request methods, the
   server MUST respond with a status of 412 (Precondition Failed).

   See Section 18.1.3 for rules on how to methods
         GET_PARAMETER, SET_PARAMETER, PLAY_NOTIFY, and REDIRECT.

      +------------------+---------+-------+-----+-----+-----+-----+
      | Header           | Where   | Proxy | GPR | SPR | RDR | PNY |
      +------------------+---------+-------+-----+-----+-----+-----+
      | Range            | R       |       | -   | -   | o   | m   |
      |                  |         |       |     |     |     |     |
      | Referer          | R       |       | o   | o   | o   | -   |
      |                  |         |       |     |     |     |     |
      | Request-Status   | R       |       | -   | -   | -   | m   |
      |                  |         |       |     |     |     |     |
      | Require          | R       | r     | o   | o   | o   | -   |
      |                  |         |       |     |     |     |     |
      | Retry-After      | 3rr,503 |       | o   | o   | -   | -   |
      |                  |         |       |     |     |     |     |
      | Scale            |         |       | -   | -   | -   | c   |
      |                  |         |       |     |     |     |     |
      | Seek-Style       |         |       | -   | -   | -   | -   |
      |                  |         |       |     |     |     |     |
      | Session          | R       | r     | o   | o   | o   | m   |
      | Session          | r       | r     | c   | c   | o   | m   |
      |                  |         |       |     |     |     |     |
      | Server           | R       | r     | o   | o   | o   | -   |
      |                  |         |       |     |     |     |     |
      | Server           | r       | r     | o   | o   | -   | -   |
      |                  |         |       |     |     |     |     |
      | Supported        | R       | adrm  | o   | o   | o   | -   |
      |                  |         |       |     |     |     |     |
      | Supported        | r       | adrm  | c   | c   | c   | -   |
      |                  |         |       |     |     |     |     |
      | Timestamp        | R       | adrm  | o   | o   | o   | -   |
      |                  |         |       |     |     |     |     |
      | Timestamp        | c       | adrm  | m   | m   | m   | -   |
      |                  |         |       |     |     |     |     |
      | Unsupported      | r       | arm   | c   | c   | c   | -   |
      |                  |         |       |     |     |     |     |
      | User-Agent       | R       | r     | m*  | m*  | -   | -   |
      |                  |         |       |     |     |     |     |
      | User-Agent       | r       | r     | -   | -   | m*  | -   |
      |                  |         |       |     |     |     |     |
      | determine if two message body
   tags match.

   If none of the message body tags match, then the server MAY perform
   the requested method as if the If-None-Match header field did not
   exist, but MUST also ignore any If-Modified-Since header field(s) in
   the request.  That is, if no message body tags match, then the server
   MUST NOT return a 304 (Not Modified) response.

   If the request would, without the If-None-Match header field, result
   in anything other than a 2xx or 304 status, then the If-None-Match
   header MUST be ignored.  (See Section 18.1.4 for a discussion of
   server behavior when both If-Modified-Since and If-None-Match appear
   in the same request.)

   The meaning of "If-None-Match: *" is that the method MUST NOT be
   performed if the representation selected by the origin server (or by
   a cache, possibly using the Vary             | r       |       | c   | c   | -   | -   |
      |                  |         |       |     |     |     |     |
      | Via              | R       | amr   | o   | o   | o   | -   |
      |                  |         |       |     |     |     |     |
      | Via              | c       | dr    | m   | m   | m   | -   |
      |                  |         |       |     |     |     |     |
      | WWW-Authenticate | 401     |       | m   | m   | m   | -   |
      +------------------+---------+-------+-----+-----+-----+-----+

     Table 12: Overview mechanism, see Section 16.55)
   exists, and SHOULD be performed if the representation does not exist.
   This feature is intended to be useful in preventing races between PUT
   operations.

   The result of a request having both an If-None-Match header field and
   either an If-Match or an If-Unmodified-Since header fields is
   undefined by this specification.

16.26.  Last-Modified

   The Last-Modified message-header field indicates the date and time at
   which the origin server believes the presentation description or
   media stream was last modified.  For the method DESCRIBE, the header
   field indicates the last modification date and time of the
   description, for SETUP that of the media stream.

   An origin server MUST NOT send a Last-Modified date which is later
   than the server's time of message origination.  In such cases, where
   the resource's last modification would indicate some time in the
   future, the server MUST replace that date with the message
   origination date.

   An origin server SHOULD obtain the Last-Modified value of the entity
   as close as possible to the time that it generates the Date value of
   its response.  This allows a recipient to make an accurate assessment
   of the entity's modification time, especially if the entity changes
   near the time that the response is generated.

   RTSP servers SHOULD send Last-Modified whenever feasible.

16.27.  Location

   The Location response-header field is used to redirect the recipient
   to a location other than the Request-URI for completion of the
   request or identification of a new resource.  For 3xx responses, the
   location SHOULD indicate the server's preferred URI for automatic
   redirection to the resource.  The field value consists of a single
   absolute URI.

   Note: The Content-Location header field (Section 16.17) differs from
   Location in that the Content-Location identifies the original
   location of the entity enclosed in the request.  It is therefore
   possible for a response to contain header fields (R-W) for both Location
   and Content-Location.  Also see Section 18.2 for cache requirements
   of some methods.

16.28.  Media-Properties

   This general header is used in SETUP response or PLAY_NOTIFY requests
   to indicate the media's properties that currently are applicable to
   the RTSP session.  PLAY_NOTIFY MAY be used to modify these properties
   at any point.  However, the client SHOULD have received the update
   prior to any action related to methods
         GET_PARAMETER, SET_PARAMETER,  PLAY_NOTIFY, and REDIRECT.

16.1.  Accept the new media properties take affect.
   For aggregated sessions the Media-Properties header will be returned
   in each SETUP response.  The Accept request-header field can header received in the latest response
   is the one that applies on the whole session from this point until
   any future update.  The header MAY be used included without value in
   GET_PARAMETER requests to specify certain
   presentation description content types which are acceptable for the
   response.

   See [H14.1] server with a Session header included
   to query the current Media-Properties for syntax.

   Example of use:
     Accept: application/example ;q=1.0, application/sdp

16.2.  Accept-Credentials the session.  The Accept-Credentials responder
   MUST include the current session's media properties.

   The media properties expressed by this header is the one applicable
   to all media in the RTSP session.  So for aggregated sessions the
   header expressed the combined media-properties.  As a request result
   aggregation of media MAY result in a change of the media properties,
   and thus the content of the Media-Properties header used to indicate to
   any trusted intermediary how to handle further secured connections contained in
   subsequent SETUP responses.

   The header contains a list of property values that are applicable to
   proxies or servers.  See Section 19 for
   the usage currently setup media or aggregate of this media as indicated by the
   RTSP URI in the request.  No ordering are enforced within the header.  It
   SHALL
   Property values should be grouped into a single group that handles a
   particular orthogonal property.  Values or groups that express
   multiple properties SHOULD NOT be included used.  The list of properties that
   can be expressed MAY be extended at any time.  Unknown property
   values MUST be ignored.

   This specification defines the following 4 groups and their property
   values:

   Random Access:

      Random-Access:  Indicates that random access is possible.  May
         optionally include a floating point value in server seconds indicating
         the longest duration between any two random access points in
         the media.

      Begining-Only:  Seeking is limited to client requests.

   In a request the header SHALL contain beginning only.

      No-Seeking:  No seeking is possible.

   Content Modifications

      Immutable:  The content will not be changed during the method (User, Proxy, life-time
         of the RTSP session.

      Dynamic:  The content may be changed based on external methods or
   Any)
         triggers

      Time-Progressing  The media accessible progress as wallclock time
         progresses.

   Retention

      Unlimited:  Content will be retained for approving credentials selected the duration of the life-
         time of the RTSP session.

      Time-Limited:  Content will be retained at least until the
         specified wallclock time.  The time must be provided in the
         absolute time format specified in Section Section 4.6.

      Time-Duration  Each individual media unit is retained for at least
         the specified time duration.  This definition allows for
         retaining data with a time based sliding window.  The time
         duration is expressed as floating point number in seconds. 0.0
         is a valid value as this indicates that no data is retained in
         a time-progressing session.

   Supported Scale:

      Scales:  A quoted comma separated list of one or more decimal
         values or ranges of scale values supported by the content.  A
         range has a start and stop value separated by a colon.  A range
         indicates that the requestor. content supports fine grained selection of
         scale values.  Fine grained allows for steps at least as small
         as one tenth of a scale value.  Negative values are supported.

         The value 0 have no meaning and must not be used.

   An Example of this header for first an on-demand content and then a
   live stream without recording.

   On-demand:
   Media-Properties: Random-Access=2.5s, Unlimited, Immutable,
        Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20"

   Live stream without recording/timeshifting:
   Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0

16.29.  Media-Range

   The method
   SHALL NOT be changed by any proxy, unless it Media-Range general header is "proxy" when a proxy
   MAY change it to "user" used to take give the role range of user approving each
   further hop.  If the method is "User" media
   at the header contains zero or
   more time of credentials that sending the client accepts.  The RTSP message.  This header may contain
   zero credentials MUST be
   included in the first RTSP SETUP response, and PLAY and PAUSE response for media
   that are Time-Progressing, and PLAY and PAUSE response after any
   change for media that are Dynamic, and in PLAY_NOTIFY request that
   are sent due to a RTSP server when
   using the "User" method.  This as the client has not yet received Media-Property-Update.  Media-Range header without
   any
   credentials range specifications MAY be included in GET_PARAMETER requests to accept.  Each credential SHALL consist of one URI
   identifying the proxy or server,
   the hash algorithm identifier, and server to request the hash over that entity's DER encoded certificate [RFC5280] current range.  The server MUST in
   Base64 [RFC4648].  All RTSP clients and proxies SHALL implement this
   case include the
   SHA-256[FIPS-pub-180-2] algorithm for computation of current range at the hash time of sending the
   DER encoded certificate.  The SHA-256 algorithm is identified by the
   token "sha-256". response.

   The intention with allowing header MUST include range specifications for all time formats
   supported for other hash algorithms is to enable the future retirement of algorithms that are not implemented
   somewhere else than here.  Thus media, as indicated in Accept-Ranges header
   (Section 16.5) when setting up the definition media.  The server MAY include
   more than one range specification of future algorithms
   for this purpose is intended to be extremely limited.  A feature tag
   can be used any given time format to ensure
   indicate media that support for the replacement algorithm
   exist.

   Example:
   Accept-Credentials:User
     "rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=,
     "rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M=

16.3.  Accept-Encoding

   See [H14.3].

16.4.  Accept-Language

   See [H14.4].  Note has non-continuous range.

   For media that has the language specified applies to Time-Progressing property, the
   presentation description and any reason phrases, not Media-Range
   values will only be valid for the media
   content.

16.5.  Accept-Ranges

   The Accept-Ranges request and response-header field allows indication
   of particular point in time when it
   was issued.  As wallclock progresses so will also the format supported media range.
   However it shall be assumed that media time progress in direct
   relationship to wallclock time (with the Range header.  The client SHALL
   include exception of clock skew) so
   that a reasonably accurate estimation of the media range can be
   calculated.

16.30.  MTag

   The MTag response header MAY be included in DESCRIBE or SETUP requests to indicate which formats it
   support to receive
   responses.  The message body tags (Section 4.8) returned in PLAY and PAUSE responses, a
   DESCRIBE response, and REDIRECT
   requests.  The server SHALL include the header one in SETUP and 456 error
   responses refers to indicate the formats supported for presentation,
   i.e. both the resource
   indicated by returned session description and the request URI.
      Accept-Ranges: NPT, SMPTE media stream.
   This header allows for verification that one has the same syntax as [H14.5] and the syntax is defined
   in Section 20.2.3.  However, new range-units are defined.

16.6.  Allow

   The Allow entity-header field lists right session
   description to a media resource at the methods supported by time of the
   resource identified by SETUP request.
   However it has the Request-URI.  The purpose disadvantage that a change in any of this field is
   to strictly inform the recipient parts
   results in invalidation of valid methods associated with all the
   resource.  An Allow header field MUST be present parts.

   If the MTag is provided both inside the message body, e.g. within the
   "a=mtag" attribute in a 405 (Method Not
   Allowed) response.  See [H14.7] for syntax definition.  The Allow
   header SDP, and in the response message, then both
   tags MUST also be present identical.  It is RECOMMENDED that the MTag is primarily
   given in all OPTIONS responses where the RTSP response message, to ensure that caches can use the
   MTag without requiring content inspection.  However for session
   descriptions that are distributed outside of the header RTSP, for example using
   HTTP, etc. it will not be necessary to include exactly the same methods as
   listed message body tag in
   the Public header.

   The Allow SHALL also be included session description as specified in Appendix D.1.9.

   SETUP and DESCRIBE responses, if requests can be made conditional upon the methods allowed for MTag
   using the resource headers If-Match (Section 16.23) and If-None-Match (
   Section 16.25).

16.31.  Notify-Reason

   The Notify Reason header is different than solely used in the minimal
   implementation set.

   Example of use:
      Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE

16.7.  Authorization

   See [H14.8].

16.8.  Bandwidth

   The Bandwidth request-header field describes PLAY_NOTIFY method.
   It indicates the estimated bandwidth
   available to reason why the client, expressed as a positive integer and measured
   in bits per second. server has sent the asynchronous
   PLAY_NOTIFY request (see Section 13.5).

16.32.  Pipelined-Requests

   The bandwidth available Pipelined-Requests general header is used to the client may change
   during an RTSP session, e.g., due indicate that a
   request is to mobility, congestion, etc.

   Example:
     Bandwidth: 62360

16.9.  Blocksize be executed in the context created by previous
   requests.  The Blocksize request-header field primary usage of this header is sent from the client to allow pipelining of
   SETUP requests so that any additional SETUP request after the
   media server asking the server for a particular media packet size.
   This packet size first
   one does not include lower-layer headers such as IP,
   UDP, or RTP.  The server is free need to use wait for the session ID to be sent back to the
   requesting entity.  The header contains a blocksize which unique identifier that is lower
   than
   scoped by the one requested.  The server MAY truncate this packet size persistent connection used to send the closest multiple of the minimum, media-specific block size, or
   override it requests.

   Upon receiving a request with the media-specific size if necessary.  The block
   size Pipelined-Requests the responding
   entity MUST be look up if there exist a positive decimal number, measured in octets.  The
   server only returns binding between this Pipelined-
   Requests identifier for the current persistent connection and an error (4xx) if RTSP
   session ID.  If that exists then the value received request is syntactically
   invalid.

16.10.  Cache-Control

   The Cache-Control general-header field processed
   the same way as if it did contain the Session header with the looked
   up session ID.  If there doesn't exist a mapping and no Session
   header is used included in the request, the responding entity MUST create
   a binding upon the successful completion of a session creating
   request, i.e.  SETUP.  If the request failed to specify directives
   that create an RTSP
   session no binding MUST be obeyed by all caching mechanisms along created.  In case the request/
   response chain.

   Cache directives MUST be passed through by request contains
   both a proxy or gateway
   application, regardless of their significance to that application,
   since Session header and the directives may Pipelined-Requests header the
   Pipelined-Requests MUST be applicable to all recipients along ignored.

   Note: Based on the
   request/response chain.  It is not possible to specify a cache-
   directive for above definition at least the first request
   containing a specific cache.

   Cache-Control should only new unique Pipelined-Requests will be required to be specified in a
   SETUP request and its
   response.  Note: Cache-Control does not govern (unless the caching protocol is extended with new methods of
   responses as for HTTP, instead it applies to the media stream
   identified by the
   creating a session).  After that first one, additional SETUP request.  The RTSP requests are generally not
   cacheable, for further information see Section 18.  Below is the
   description
   or request of any type using the cache directives that can be included in RTSP session context may include the
   Cache-Control
   Pipelined-Requests header.

   no-cache:  Indicates

   For all responses to request that contained the media stream Pipelined-Requests,
   the Session header and the Pipelined-Requests MUST NOT both be cached
         anywhere.  This allows an origin server to prevent caching even
         by caches included,
   assuming that have been configured to return stale responses
         to client requests.  Note, there it is no security function
         enforcing allowed for that the content can't be cached.

   public:  Indicates response and that the media stream is cacheable by any cache.

   private:  Indicates that binding
   between the media stream is intended for a single
         user and MUST header values exist.  Pipelined-Requests SHOULD NOT be cached by a shared cache.  A private (non-
         shared) cache may cache
   used in requests after that the media streams.

   no-transform:  An intermediate cache (proxy) may find it useful to
         convert client has received the media type of a certain stream.  A proxy might, for
         example, convert between video formats to save cache space or RTSP Session
   ID.  This as using the real session ID allows the request to reduce be used
   also in cases the amount of traffic on a slow link.  Serious
         operational problems may occur, however, when these
         transformations have persistent connection has been applied to streams intended for
         certain kinds terminated and a new
   connection is needed.

   It is the sender of applications.  For example, applications the request that is responsible for
         medical imaging, scientific data analysis and those using end-
         to-end authentication all depend on receiving a stream that
   previously unused identifier within this transport connection scope
   when a new RTSP session is
         bit-for-bit identical to the original media stream.  Therefore,
         if a response includes the no-transform directive, an
         intermediate cache or proxy be created with this method.  A server
   side binding MUST NOT change be deleted upon the encoding termination of the
         stream.  Unlike HTTP, related RTSP does not provide
   session.  Note: Although this definition would allow for partial
         transformation at reusing
   previously used pipelining identifiers, this point, e.g., allowing translation into is NOT RECOMMENDED to
   allow for better error handling and logging.

   RTSP Proxies may need to translate Pipelined-Requests identifier
   values from incoming request to outgoing to allow for aggregation of
   requests onto a
         different language.

   only-if-cached:  In some cases, such persistent connection.

16.33.  Proxy-Authenticate

   The Proxy-Authenticate response-header field MUST be included as times part
   of extremely poor
         network connectivity, a client may want 407 (Proxy Authentication Required) response.  The field value
   consists of a cache to return only
         those media streams challenge that it currently has stored, indicates the authentication scheme and not
   parameters applicable to
         receive these from the origin server.  To do this, the client
         may include the only-if-cached directive in a request.  If it
         receives proxy for this directive, a cache SHOULD either respond using a
         cached media stream that Request-URI.

   The HTTP access authentication process is consistent with described in [RFC2617].
   Unlike WWW-Authenticate, the other
         constraints of Proxy-Authenticate header field applies
   only to the request, or respond with a 504 (Gateway
         Timeout) status.  However, if a group of caches is being
         operated as a unified system with good internal connectivity,
         such a request MAY current connection and SHOULD NOT be forwarded within that group of caches.

   max-stale:  Indicates that the client is willing passed on to accept a media
         stream that has exceeded its expiration time.  If max-stale is
         assigned a value, then the client is willing
   downstream clients.  However, an intermediate proxy might need to accept a
         response that has exceeded
   obtain its expiration time own credentials by no more than requesting them from the specified number of seconds.  If no value is assigned to
         max-stale, then downstream
   client, which in some circumstances will appear as if the client proxy is willing to accept a stale
         response of any age.

   min-fresh:  Indicates that
   forwarding the Proxy-Authenticate header field.

16.34.  Proxy-Authorization

   The Proxy-Authorization request-header field allows the client is willing to accept a media
         stream whose freshness lifetime is no less than
   identify itself (or its current age
         plus user) to a proxy which requires
   authentication.  The Proxy-Authorization field value consists of
   credentials containing the specified time in seconds.  That is, authentication information of the client wants
         a response that will still be fresh user
   agent for at least the specified
         number proxy and/or realm of seconds.

   must-revalidate:  When the must-revalidate directive resource being requested.

   The HTTP access authentication process is present described in a
         SETUP response received by a cache, that cache MUST NOT use [RFC2617].
   Unlike Authorization, the
         entry after it becomes stale to respond Proxy-Authorization header field applies
   only to a subsequent request
         without first revalidating it with the origin server.  That is, the cache is required to do an end-to-end revalidation every
         time, if, based solely on next outbound proxy that demanded authentication using
   the origin server's Expires, Proxy- Authenticate field.  When multiple proxies are used in a
   chain, the
         cached response Proxy-Authorization header field is stale.)

   proxy-revalidate:  The proxy-revalidate directive has the same
         meaning as consumed by the must-revalidate directive, except first
   outbound proxy that it does
         not apply to non-shared user agent caches.  It can be used on a
         response was expecting to an authenticated receive credentials.  A proxy
   MAY relay the credentials from the client request to permit the user's cache
         to store and later return next proxy
   if that is the response without needing to
         revalidate it (since it has already been authenticated once mechanism by
         that user), while still requiring which the proxies that service many
         users to revalidate each time (in order cooperatively
   authenticate a given request.

16.35.  Proxy-Require

   The Proxy-Require request-header field is used to make sure that each
         user has been authenticated).  Note indicate proxy-
   sensitive features that such authenticated
         responses also need MUST be supported by the proxy.  Any Proxy-
   Require header features that are not supported by the public cache control directive in order
         to allow them to proxy MUST be cached at all.

   max-age:  When an intermediate cache is forced,
   negatively acknowledged by means of a max-
         age=0 directive, the proxy to revalidate its own cache entry, and the client has supplied its own validator using the
   Unsupported header.  The proxy MUST use the 551 (Option Not
   Supported) status code in the request, response.  Any feature-tag included in
   the
         supplied validator might differ from Proxy-Require does not apply to the validator currently
         stored with end-point (server or client).
   To ensure that a feature is supported by both proxies and servers the cache entry.  In this case,
   tag needs to be included in also a Require header.

   See Section 16.42 for more details on the cache MAY use
         either validator mechanics of this message
   and a usage example.  See discussion in making its own request without affecting
         semantic transparency.

   However, the choice proxies section
   (Section 17.1) about when to consider that a feature requires proxy
   support.

   Example of validator might affect performance. use:
      Proxy-Require: play.basic

16.36.  Proxy-Supported

   The best
   approach is for Proxy-Supported header field enumerates all the intermediate cache to use its own validator when
   making its request.  If extensions
   supported by the server replies with 304 (Not Modified),
   then proxy using feature-tags.  The header carries the cache can return its now validated copy to
   intersection of extensions supported by the client with forwarding proxies.  The
   Proxy-Supported header MAY be included in any request by a
   200 (OK) response.  If proxy.  It
   MUST be added by any proxy if the server replies with Supported header is present in a new entity and cache
   validator, however,
   request.  When present in a request, the intermediate cache can compare receiver MUST in the returned
   validator with
   response copy the one provided received Proxy-Supported header.

   The Proxy-Supported header field contains a list of feature-tags
   applicable to proxies, as described in Section 4.7.  The list are the client's request, using the
   strong comparison function.  If
   intersection of all feature-tags understood by the client's validator is equal to proxies.  To
   achieve an intersection, the origin server's, then proxy adding the intermediate cache simply returns 304
   (Not Modified).  Otherwise, Proxy-Supported header
   includes all proxy feature-tags it returns the new entity with understands.  Any proxy receiving
   a 200 (OK)
   response.

16.11.  Connection

   See [H14.10].  The use of request with the connection option "close" in RTSP
   messages SHOULD be limited to error messages when header, checks the server is
   unable to recover list and therefore see removes any feature-
   tag it necessary to close do not support.  A Proxy-Supported header present in the
   connection.  The reason is that
   response MUST NOT be touched by the client has proxies.

   Example:

     C->P1: OPTIONS rtsp://example.com/ RTSP/2.0
            Supported: foo, bar, blech
            User-Agent: PhonyClient/1.2

    P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0
            Supported: foo, bar, blech
            Proxy-Supported: proxy-foo, proxy-bar, proxy-blech
            Via: 2.0 pro.example.com

    P2->S:  OPTIONS rtsp://example.com/ RTSP/2.0
            Supported: foo, bar, blech
            Proxy-Supported: proxy-foo, proxy-blech
            Via: 2.0 pro.example.com, 2.0 prox2.example.com

     S->C:  RTSP/2.0 200 OK
            Supported: foo, bar, baz
            Proxy-Supported: proxy-foo, proxy-blech
            Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
            Via: 2.0 pro.example.com, 2.0 prox2.example.com

16.37.  Public

   The Public response header field lists the choice set of
   continuing using a connection indefinitely, as long as it sends valid
   messages.

16.12.  Connection-Credentials

   The Connection-Credentials methods supported
   by the response sender.  This header is used applies to carry the chain
   of credentials general
   capabilities of any next hop that need the sender and its only purpose is to indicate the
   sender's capabilities to the recipient.  The methods listed may or
   may not be approved by applicable to the
   requestor.  It SHALL only Request-URI; the Allow header field
   (Section 16.6) MAY be used in server to client responses.

   The Connection-Credentials header in an RTSP response SHALL, if
   included, contain the credential information (in form of indicate methods allowed for a list of
   certificates providing the chain of certification)
   particular URI.

   Example of use:
      Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN

   In the next hop event that an intermediary needs to securely connect to.  The header MUST
   include the URI of there are proxies between the next hop (proxy or server) sender and a base64
   [RFC4648] encoded binary structure containg a sequence of DER encoded
   X.509v3 certificates[RFC5280] .

   The binary structure starts with the number
   recipient of certificates
   (NR_CERTS) included as a 16 bit unsigned integer.  This is followed
   by NR_CERTS number of 16 bit unsigned integers providing the size in
   octets of response, each DER encoded certificate.  This is followed by NR_CERTS
   number of DER encoded X.509v3 certificates in a sequence (chain).

   The intervening proxy or server's certificate must come first in the structure.
   Each following certificate must directly certify MUST modify the one preceding
   it.  Because certificate validation requires
   Public header field to remove any methods that root keys be
   distributed independently, the self-signed certificate which
   specifies are not supported via
   that proxy.  The resulting Public header field will contain an
   intersection of the root certificate authority may optionally be omitted
   from sender's methods and the chain, under methods allowed through
   by the assumption that intervening proxies.

      In general, proxies should allow all methods to transparently pass
      through from the remote end must already
   possess it in order sending RTSP agent to validate it in any case.

   Example:

   Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC...

   Where MIIDNTCC... is a BASE64 encoding of the following structure:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Number of certifcates        | Size of certificate #1        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Size of certificate #2        | Size of certificate #3        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       : DER Encoding of Certificate #1                                :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       : DER Encoding of Certificate #2                                :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       : DER Encoding of Certificate #3                                :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

16.13.  Content-Base

   The Content-Base entity-header field receiving RTSP agent,
      but there may be used to specify the base
   URI cases where this is not desirable for resolving relative URIs within a given
      proxy.  Modification of the entity.
   Content-Base: rtsp://media.example.com/movie/twister
   If no Content-Base Public response header field is present, the base URI of an entity is
   defined either by its Content-Location (if the
      intervening proxies ensures that Content-Location URI
   is the request sender gets an absolute URI) or
      accurate response indicating the URI methods that can be used on the
      target agent via the proxy chain.

16.38.  Range

   The Range header specifies a time range in PLAY (Section 13.4), PAUSE
   (Section 13.6), SETUP (Section 13.3), REDIRECT (Section 13.10), and
   PLAY_NOTIFY (Section 13.5) requests and responses.  It MAY be
   included in GET_PARAMETER request from he client to the server with
   only a Range format and no value to initiate request the request, current media
   position independent if the session is in playing or ready state in
   the included format.  The server SHALL if supporting that
   order of precedence.  Note, however, that range
   format respond with the base URI current playing point or pause point as the
   start of the
   contents within range.  If an explicit stop point was used in the entity-body may
   previous PLAY request, then that value shall be redefined within included as stop
   point.  Note that entity-
   body.

16.14.  Content-Encoding

   See [H14.11].

16.15.  Content-Language

   See [H14.12].

16.16.  Content-Length

   The Content-Length general-header field contains if the length server is currently under any type of media
   playback manipulation affecting the
   body (entity) interpretation of the message (i.e. after the double CRLF following
   the last header).  Unlike HTTP, it MUST Range, like
   Scale, that is also required to be included in all messages
   that carry body beyond any GET_PARAMETER
   response to provide complete information.

   The range can be specified in a number of units.  This specification
   defines smpte (Section 4.4), npt (Section 4.5), and clock
   (Section 4.6) range units.  While byte ranges [H14.35.1] and other
   extended units MAY be used, their behavior is unspecified since they
   are not normally meaningful in RTSP.  Servers supporting the Range
   header portion of MUST understand the message. NPT range format and SHOULD understand the
   SMPTE range format.  If it the Range header is
   missing, sent in a default value of zero is assumed.  It is interpreted
   according to [H14.13].

16.17.  Content-Location

   See [H14.14].

16.18.  Content-Type

   See [H14.17].  Note time format
   that is not understood, the content types suitable recipient SHOULD return 456 (Header Field
   Not Valid for RTSP are
   likely to be restricted in practice to presentation descriptions Resource) and
   parameter-value types.

16.19.  CSeq

   The CSeq general-header field specifies include an Accept-Ranges header
   indicating the sequence number supported time formats for an
   RTSP request-response pair.  This field MUST be present in all
   requests and responses.  For every RTSP request containing the given
   sequence number, resource.

   Example:
     Range: clock=19960213T143205Z-

   The Range header contains a range of one single range format.  A
   range is a half-open interval with a start and an end point,
   including the corresponding response will start point, but excluding the end point.  A range may
   either be fully specified with explicit values for start point and
   end point, or have either start or end point be implicit.  An
   implicit start point indicates the same
   number.  Any retransmitted request MUST contain session's pause point, and if no
   pause point is set the same sequence
   number as start of the original (i.e. content.  An implicit end point
   indicates the sequence number end of the content.  The usage of both implicit start
   and end point is not incremented
   for retransmissions of allowed in the same request).  For each new RTSP request range header, however, the
   exclusion of the range header has that meaning, i.e. from pause point
   (or start) until end of content.

      Regarding the half-open intervals; a range of A-B starts exactly
      at time A, but ends just before B. Only the CSeq value SHALL be incremented by one.  The initial sequence
   number MAY be any number, however it is RECOMMENDED to start time of a media
      unit such as a video or audio frame is relevant.  For example,
      assume that video frames are generated every 40 ms.  A range of
      10.0-10.1 would include a video frame starting at 0.
   Each sequence number series is unique between each requester 10.0 or later
      time and
   responder, i.e. the client has one series for its request to would include a server
   and video frame starting at 10.08, even
      though it lasted beyond the server has another when sending request to interval.  A range of 10.0-10.08, on
      the client.  Each
   requester other hand, would exclude the frame at 10.08.

      Please note the difference between NPT time scales' "now" and responder an
      implicit start value.  Implicit value reference the current pause-
      point.  While "now" is identified the currently ongoing time.  In a time-
      progressing session with its network address.

   Proxies that aggregate several sessions on recording (retention for some or full
      time) the same transport will
   regularly need to renumber pause point may be 2 min into the CSeq header field in requests and
   responses to fulfill session while now
      could be 1 hour into the rules for session.

   By default, range intervals increase, where the header. second point is
   larger than the first point.

   Example:
   CSeq: 239

16.20.  Date

   See [H14.18].  An RTSP message containing a body MUST include a Date
   header
       Range: npt=10-15

   However, range intervals can also decrease if the sending host has a clock.  Servers SHOULD include a
   Date header in all other RTSP messages.

16.21.  ETag

   The ETag response Scale header MAY be included in DESCRIBE or SETUP
   responses.  The entity tags (Section 4.8) returned in (see
   Section 16.44) indicates a DESCRIBE
   response, and negative scale value.  For example, this
   would be the one case when a playback in SETUP refers to the presentation, i.e. both reverse is desired.

   Example:
       Scale: -1
       Range: npt=15-10

   Decreasing ranges are still half open intervals as described above.
   Thus, for range A-B, A is closed and B is open.  In the returned session description above
   example, 15 is closed and 10 is open.  An exception to this rule is
   the media stream.  This allows
   for verification that one has case when B=0 in a decreasing range.  In this case, the right session description range is
   closed on both ends, as otherwise there would be no way to reach 0 on
   a
   media resource at the time of the SETUP request.  However it has the
   disadvantage reverse playback for formats that have such a change in any of the parts results in
   invalidation of all notion, like NPT and
   SMPTE.

   Example:
       Scale: -1
       Range: npt=15-0

   In this range both 15 and 0 are closed.

   A decreasing range interval without a corresponding negative Scale
   header is not valid.

16.39.  Referer

   The Referer request-header field allows the parts.

   If client to specify, for
   the ETag is provided both inside server's benefit, the entity, e.g. within address (URI) of the
   "a=etag" attribute in SDP, and in resource from which
   the response message, then both
   tags SHALL be identical.  It is RECOMMENDED that Request-URI was obtained (the "referrer", although the ETag header
   field is
   primarily given in the RTSP response message, misspelled.)  The URI refers to ensure that caches
   can use of the ETag without requiring content inspection.  However for
   session descriptions that are distributed outside presentation
   description, typically retrieved via HTTP.  The Referer request-
   header allows a server to generate lists of RTSP, back-links to resources
   for
   example using HTTP, interest, logging, optimized caching, etc. it will be necessary  It also allows
   obsolete or mistyped links to include the entity
   tag in be traced for maintenance.  The Referer
   field MUST NOT be sent if the session description Request-URI was obtained from a source
   that does not have its own URI, such as specified in Appendix D.1.9.

   SETUP and DESCRIBE requests can be made conditional upon input from the ETag
   using user keyboard.

   If the headers If-Match (Section 16.24) and If-None-Match (
   Section 16.26).

16.22.  Expires

   The Expires entity-header field gives value is a date and time after which the
   description or media-stream should relative URI, it SHOULD be considered stale.  The
   interpretation depends on interpreted
   relative to the method:

   DESCRIBE response: Request-URI.  The Expires header indicates URI MUST NOT include a date and time
         after which the presentation description (body) SHOULD be
         considered stale.

   SETUP response: fragment.

   See [H15.1.3] for security considerations on Referer.

16.40.  Retry-After

   The Expires header indicate Retry-After response-header field can be used with a date and time after
         which 503 (Service
   Unavailable) response to indicate how long the media stream SHOULD service is expected to
   be considered stale.

   A stale cache entry may not normally unavailable to the requesting client.  This field MAY also be returned by a cache (either a
   proxy cache or an user agent cache) unless it is first validated used
   with any 3xx (Redirection) response to indicate the origin server (or with an intermediate cache that has a fresh
   copy of minimum time the entity).  See Section 18 for further discussion of
   user-agent is asked wait before issuing the
   expiration model. redirected request.  The presence
   value of an Expires this field does not imply that the original
   resource will change or cease to exist at, before, can be either an RTSP-date or after that
   time.

   The format is an absolute date and integer number
   of seconds (in decimal) after the time as defined by HTTP-date in
   [H3.3]; it MUST be in RFC1123-date format:

   An example of its use is
     Expires: Thu, 01 the response.

   Example:
   Retry-After: Fri, 31 Dec 1994 16:00:00 1999 23:59:59 GMT

   RTSP/2.0 clients and caches MUST treat other invalid date formats,
   especially including
   Retry-After: 120

   In the value "0", as having occurred in latter example, the past
   (i.e., already expired).

   To mark a response as "already expired," an origin server should use
   an Expires date that delay is equal to the Date 2 minutes.

16.41.  Request-Status

   This request header value.  To mark a
   response as "never expires," an origin server SHOULD use an Expires
   date approximately one year from is used to indicate the end result for requests
   that takes time the response to complete, such a PLAY (Section 13.4).  It is sent.
   RTSP/2.0 servers SHOULD NOT send Expires dates more than one year sent
   in PLAY_NOTIFY (Section 13.5) with the future.

16.23.  From

   See [H14.22].

16.24.  If-Match

   See [H14.24]. end-of-stream reason to report
   how the PLAY request concluded, either in success or in failure.  The If-Match request-header field
   header carries a reference to the request is especially useful reports on using the
   CSeq number for ensuring the integrity of session indicated by the presentation description, Session header in both the case where
   it is fetched via means external
   request.  It provides both a numerical status code (according to RTSP (such as HTTP),
   Section 8.1.1) and a human readable reason phrase.

   Example:
   Request-Status: cseq=63 status=500 reason="Media data unavailable"

16.42.  Require

   The Require request-header field is used by clients or in servers to
   ensure that the
   case where other end-point supports features that are required
   in respect to this request.  It can also be used to query if the server implementation is guaranteeing
   other end-point supports certain features, however the integrity use of the description between the time of
   Supported (Section 16.49) is much more effective in this purpose.
   The server MUST respond to this header by using the DESCRIBE message and Unsupported
   header to negatively acknowledge those feature-tags which are NOT
   supported.  The response MUST use the
   SETUP message.  By including error code 551 (Option Not
   Supported).  This header does not apply to proxies, for the ETag given same
   functionality in or respect to proxies see Proxy-Require header
   (Section 16.35) with the session
   description exception of media modifying proxies.  Media
   modifying proxies due to their nature of handling media in a SETUP request, the client ensures way that resources set
   up are matching the description.  A SETUP request for which the ETag
   validation check fails, SHALL responde using 412 (Precondition
   Failed).

   This validation check
   is also very useful if similar to what a session has been
   redirected from one server, do need to understand also the
   server features to another.

16.25.  If-Modified-Since

   The If-Modified-Since request-header field is used with correctly serve the DESCRIBE
   and SETUP methods client.

      This is to make them conditional.  If sure that the requested variant
   has client-server interaction will
      proceed without delay when all features are understood by both
      sides, and only slow down if features are not been modified since the time specified understood (as in this field,
      the example below).  For a
   description will not be returned from well-matched client-server pair, the server (DESCRIBE) or
      interaction proceeds quickly, saving a
   stream will round-trip often required
      by negotiation mechanisms.  In addition, it also removes state
      ambiguity when the client requires features that the server does
      not be set up (SETUP).  Instead, a 304 understand.

   Example (Not Modified)
   response SHALL be returned without any message-body.

   An example of complete):
   C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0
           CSeq: 302
           Require: funky-feature
           Funky-Parameter: funkystuff

   S->C:   RTSP/2.0 551 Option not supported
           CSeq: 302
           Unsupported: funky-feature

   In this example, "funky-feature" is the field is:

     If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

16.26.  If-None-Match

   See [H14.26].

   This request header can be used with one or several entity tags feature-tag which indicates
   to
   make DESCRIBE requests conditional.  A new session description the client that the fictional Funky-Parameter field is
   retrieved only if another entity than required.
   The relationship between "funky-feature" and Funky-Parameter is not
   communicated via the ones already available
   would RTSP exchange, since that relationship is an
   immutable property of "funky-feature" and thus should not be included.
   transmitted with every exchange.

   Proxies and other intermediary devices MUST ignore this header.  If a
   particular extension requires that intermediate devices support it,
   the entity available for delivery is matching extension should be tagged in the one Proxy-Require field instead
   (see Section 16.35).  See discussion in the client already has, then proxies section
   (Section 17.1) about when to consider that a 304 (Not Modified) response is
   given.

16.27.  Last-Modified feature requires proxy
   support.

16.43.  RTP-Info

   The Last-Modified entity-header RTP-Info response-header field indicates the date and time at
   which the origin server believes is used to set RTP-specific
   parameters in the presentation description or
   media stream was last modified.  See [H14.29]. PLAY response.  For streams using RTP as transport
   protocol the methods
   DESCRIBE, the RTP-Info header field indicates the last modification date and
   time SHOULD be part of a 200 response to
   PLAY.

      The exclusion of the description, RTP-Info in a PLAY response for SETUP RTP
      transported media will result in that of a client needs to
      synchronize the media stream.

16.28.  Location

   See [H14.30].

16.29.  Media-Properties streams using RTCP.  This general header is used in SETUP response or PLAY_NOTIFY requests
   to indicate may have negative
      impact as the media's properties that currently are applicable RTCP can be lost, and does not need to be
      particularly timely in their arrival.  Also functionality as
      informing the RTSP session.  PLAY_NOTIFY client from which packet a seek has occurred is
      affected.

   The RTP-Info MAY be used included in SETUP responses to modify these properties
   at any point.  However, the provide
   synchronization information when changing transport parameters, see
   Section 13.3.  The RTP-Info header MAY also be included in
   GET_PARAMETER requests from client MUST have received the update
   prior to server without any action related value to
   indicate a request for this information.  In such a case the new media properties take affect.
   For aggregated sessions the Media-Properties Range
   header will MUST also be returned included in each SETUP response and the one that applies request.  The server SHALL
   respond if the session is in playing state with the response RTP-Info value
   corresponding to the last request. given Range value.

   The media properties expressed by this header is can carry the one applicable
   to all media in following parameters:

   url:  Indicates the RTSP session.  So stream URI which for aggregated sessions which the
   header expressed following RTP
         parameters correspond, this URI MUST be the combined media-properties.  As a result
   aggregation of media MAY result same used in a change of the
         SETUP request for this media properties, stream.  Any relative URI MUST use
         the Request-URI as base URI.  This parameter MUST be present.

   ssrc: The Synchronization source (SSRC) that the RTP timestamp and thus
         sequence number provide applies to.  This parameter MUST be
         present.

   seq:  Indicates the content sequence number of the Media-Properties header contained in
   subsequent SETUP responses.

   The header contains a list first packet of property values that are applicable to the currently setup media or aggregate stream
         that is direct result of media as indicated by the
   RTSP URI in the request.  No ordering are enforced within  This allows clients to
         gracefully deal with packets when seeking.  The client uses
         this value to differentiate packets that originated before the header.
   Property values should be grouped into a single group
         seek from packets that originated after the seek.  Note that handles a
   particular orthogonal property.  Values
         client may not receive the packet with the expressed sequence
         number, and instead packets with a higher sequence number, due
         to packet loss or groups that express
   multiple properties SHOULD NOT reordering.  This parameter is RECOMMENDED to
         be used. present.

   rtptime:  MUST indicate the RTP timestamp value corresponding to the
         start time value in the Range response header, or if not
         explicitly given the implied start point.  The list client uses this
         value to calculate the mapping of properties that
   can be expressed MAY RTP time to NPT or other
         media timescale.  This parameter SHOULD be extended at present to ensure
         inter-media synchronization is achieved.  There exist no
         requirement that any time.  Unknown property
   values SHALL be ignored.

   This specification defines received RTP packet will have the following 3 groups and their property
   values:

   Random Access:

      Random-Access:  Indicates that random access is possible.  May
         optionally include a floating point same RTP
         timestamp value in seconds indicating as the longest duration between any two random access points one in the media.

      Begining-Only:  Seeking is limited parameter used to the begining only.

      No-Seeking:  No seeking establish
         synchronization.

      A mapping from RTP timestamps to NTP timestamps (wallclock) is
      available via RTCP.  However, this information is possible.

   Content Modifications

      Unmutable:  The content will not be changed during the life-time
         of the RTSP session.

      Dynamic:  The content may be changed based on external methods or
         triggers

      Time-Progressing  The sufficient
      to generate a mapping from RTP timestamps to media accesible progress as wall clock time
         progresses.

   Retention

      Unlimited:  Content will be retained for the duration of
      (NPT, etc.).  Furthermore, in order to ensure that this
      information is available at the life- necessary time of (immediately at
      startup or after a seek), and that it is delivered reliably, this
      mapping is placed in the RTSP session.

      Time-Limited:  Content will be retained at least until control channel.

      In order to compensate for drift for long, uninterrupted
      presentations, RTSP clients should additionally map NPT to NTP,
      using initial RTCP sender reports to do the
         specified wall mapping, and later
      reports to check drift against the mapping.

   Example:
   Range:npt=3.25-15
   RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102;
            rtptime=12345678,url="rtsp://example.com/foo/video"
            ssrc=9A9DE123:seq=30211;rtptime=29567112

   Lets assume that Audio uses a 16kHz RTP timestamp clock time.  The time must be provided in and Video
   a 90kHz RTP timestamp clock. Then the
         absolute time format specified in Section Section 4.6.

      Time-Duration  Each individual media unit synchronization is retained for at least
   depicted in the specified following way.

   NPT    3.0---3.1---3.2-X-3.3---3.4---3.5---3.6
   Audio               PA A
   Video                  V    PV

   X: NPT time duration.  This definition allows value = 3.25, from Range header.
   A: RTP timestamp value for
         retaining data with a time based sliding window.  The time
         duration is expressed as floating point number in seconds. 0.0
         is a valid Audio from RTP-Info header (12345678).
   V: RTP timestamp value as this for Video from RTP-Info header (29567112).
   PA: RTP audio packet carrying an RTP timestamp of 12344878. Which
       corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2
   PV: RTP video packet carrying an RTP timestamp of 29573412. Which
       corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32

16.44.  Scale

   A scale value of 1 indicates that no data is retained in normal play at the normal forward
   viewing rate.  If not 1, the value corresponds to the rate with
   respect to normal viewing rate.  For example, a time-progressing session.

   An Example ratio of this header for first an on-demand content 2 indicates
   twice the normal viewing rate ("fast forward") and then a
   live stream without recording.

   On-demand:
   Media-Properties: Random-Acess=2.5s, Unlimited, Unmutable

   Live stream without recording/timeshifting:
   Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0

16.30.  Media-Range

   The Media-Range general header is used to give the range ratio of 0.5
   indicates half the media normal viewing rate.  In other words, a ratio of 2
   has content time increase at twice the time playback time.  For every
   second of sending the RTSP message.  This header SHALL elapsed (wallclock) time, 2 seconds of content will be
   included in SETUP response, and PLAY and PAUSE response for media
   that are Time-Progressing, and PLAY and PAUSE response after any
   change for
   delivered.  A negative value indicates reverse direction.  For
   certain media that are Dynamic, and in PLAY_NOTIFY request that
   are sent due to Media-Property-Update.  Media-Range header without
   any range specifications MAY transports this may require certain considerations to
   work consistent, see Appendix C.1 for description on how RTP handles
   this.

   The transmitted data rate SHOULD NOT be changed by selection of a
   different scale value.  The resulting bit-rate should be included in GET_PARAMETER requests
   reasonably close to the server to request nominal bit-rate of the current value. content for Scale =
   1.  The server SHALL in this
   case include has to actively manipulate the curent value at data when needed to
   meet the time bitrate constraints.  Implementation of sending scale changes
   depends on the response.

   The header SHALL include range specification server and media type.  For video, a server may, for all time formats
   supported
   example, deliver only key frames or selected key frames.  For audio,
   for example, it may time-scale the media, as indicated in Accept-Ranges header
   (Section 16.5) when setting up audio while preserving pitch or,
   less desirably, deliver fragments of audio, or completely mute the media.
   audio.

   The server MAY include
   more than one and content may restrict the range specification of any given time format to
   indicate media that has non-continous range.

   For media scale values that has the Time-Progressing property, the Media-Range it
   supports.  The supported values will are indicated by the Media-Properties
   header (Section 16.28).  The client SHOULD only indicate values
   indicated to be valid for the particular point in time when it
   was issued.  As wall clock progresses so will also supported.  However, as the media range.
   However it shall be assumed that media time progress in direct
   relationship to wall clock time (with values may change as the exception of clock skew) so
   that
   content progresses a reasoanbly accurate estiamation of the media range can requested value may no longer be
   calculated.

16.31.  Notify-Reason

   The Notify Reason header is solely used in the PLAY_NOTIFY method.
   It indiciates the reason why the server has sent valid when the asynchronous
   PLAY_NOTIFY
   request (see Section 13.5).

16.32.  Pipelined-Requests

   The Pipelined-Requests general header is used to indicate that arrives.  Thus an non-supported value in a request is does not
   generate an error, only forces the server to be executed in choose the context created by previous
   requests. closest
   value.  The primary usage of this header is to allow pipelining of
   SETUP requests so that any additional SETUP request after response MUST always contain the first
   one doesn't need to wait for actual scale value
   chosen by the session ID to be sent back to server.

   If the
   requesting entity.  The header contains a unique identifier that is
   scoped by server does not implement the persistent connection used possibility to send the requests.

   Upon receiving scale, it will
   not return a request Scale header.  A server supporting Scale operations for
   PLAY MUST indicate this with the Pipelined-Requests use of the responding
   entity SHALL look up if there exist "play.scale" feature-tag.

   When indicating a binding between this Pipelined-
   Requests identifier negative scale for a reverse playback, the current persistent connection and an RTSP
   session ID.  If that exist then the received request is processed the
   same way as if it did contain the Session Range
   header with the looked up
   session ID.  If there doesn't exist MUST indicate a mapping and no Session header
   is included decreasing range as described in the request, the responding entity SHALL create a
   binding upon the succesful completion
   Section 16.38.

   Example of a session creating request,
   i.e.  SETUP.  If the request failed to create an RTSP session no
   binding SHALL be created.  In case the playing in reverse at 3.5 times normal rate:
     Scale: -3.5
     Range: npt=15-10

16.45.  Seek-Style

   When a client sends a PLAY request contains both with a
   Session header and the Pipelined-Requests Range header to perform a
   random access to the Pipelined-
   Requests SHALL be ignored.

   Note: Based on media, the above definition at least client does not know if the first request
   containing a new unique Pipelined-Requests server
   will be required to be a
   SETUP request (unless pick the protocol is extended with new methods of
   creating a session).  After that first one, additional SETUP requests media samples or request of any type using the RTSP session context may include the
   Pipelined-Requests header.

   For all responses first random access point
   prior to request that contained the Pipelined-Requests, request range.  Depending on use case, the Session header client may
   have a strong preference.  To express this preference and provide the Pipelined-Requests SHALL both be included,
   assuming that it is allowed for that response and that
   client with information on how the binding
   between server actually acted on that
   preference the Seek-Style header values exist.  Pipelined-Requests SHOULD NOT is defined.

   Seek-Style is a general header that MAY be
   used included in requests after that the client has received the RTSP Session
   ID.  This as using the real session ID allows the any PLAY
   request to be used
   also in cases indicate the persistent connection client's preference for any media stream that
   has been terminated and a new
   connection is needed.

   It is the sender of random access properties.  The server MUST always include the request that is responsible
   header in any PLAY response for using a
   previously unused identifier within this transport connection scope
   when a new RTSP session is to be cretated media with this method. random access properties
   to indicate what policy was applied.  A Server that receives a
   unknown Seek-Style policy MUST ignore it and select the server
   side binding SHALL
   default policy.

   This specification defines the following seek policies that may be deleted upon
   requested:

   RAP:  Random Access Point (RAP) is the termination behavior of requesting the related
   RTSP session.  Note: Although this definition would allow for reusing
   previously used pipelining identifiers, this is NOT RECOMMENDED
      server to
   allow for better error handling locate the closest previous random access point that
      exist in the media aggregate and logging.

   RTSP Proxies may need to translate Pipelined-Requests identifier
   values deliver from incoming request to outgoing to allow for aggregation of
   requests onto that.  By requesting
      a persistent connection.

16.33.  Proxy-Authenticate

   See [H14.33].

16.34.  Proxy-Authorization

   See [H14.34].

16.35.  Proxy-Require RAP media quality will be the best possible as all media will be
      delivered from a point where full media state can be established
      in the media decoder.

   First-Prior:  The Proxy-Require request-header field is used first-prior policy will start delivery with the
      media unit that has a playout time first prior to indicate proxy-
   sensitive features the requested
      time.  For discrete media that MUST would only include media units that
      would still be supported by rendered at the proxy.  Any Proxy-
   Require header features request time.  For continuous media
      that are not supported by the proxy MUST is media that will be
   negatively acknowledged by the proxy to render during the client using requested start time
      of the
   Unsupported header. range.

   Next:  The proxy SHALL use next media units after the 551 (Option Not
   Supported) status code in provided start time of the response.  Any feature-tag included in
      range.  For continuous framed media that would mean the Proxy-Require does not apply to first next
      frame after the end-point (server or client).
   To ensure provided time.  For discrete media the first unit
      that a feature is supported by both proxies and servers the
   tag needs to be included in also a Require header.

   See Section 16.42 for more details on rendered after the mechanics of this message
   and a provided time.  The main usage example.  See discussion in the proxies section
   (Section 17.1) about is
      for this case is when the client knows it has all media up to consider a
      certain point and would like to continue delivery so that a feature requires proxy
   support.
      complete non-interrupted media playback can be achieved.  Example
      of use:
      Proxy-Require: play.basic

16.36.  Proxy-Supported

   The Proxy-Supported header field enumerates all such scenarios include switching from a broadcast/multicast
      delivery to a unicast based delivery.  This policy MUST only be
      used on the extensions
   supported by client's explicit request.

   Please note that these expressed preferences exist for optimizing the proxy using feature-tags.
   startup time or the media quality.  The header carries "Next" policy breaks the
   intersection
   normal definition of extensions supported by the forwarding proxies.  The
   Proxy-Supported header MAY be included in any request by a proxy.  It
   SHALL be added by any proxy if the Supported Range header is present in a
   request.  When present in to enable a request, client to request
   media with minimal overlap, although some may still occur for
   aggregated sessions.  RAP and First-Prior both fulfill the receiver MUST in
   requirement of providing media from the
   response copy requested range and forward.
   However, unless RAP is used, the received Proxy-Supported header. media quality for many media codecs
   using predictive methods can be severely degraded unless additional
   data is available as, for example, already buffered, or through other
   side channels.

16.46.  Speed

   The Proxy-Supported header Speed request-header field contains a list of feature-tags
   applicable to proxies, as described in Section 4.7.  The list are requests the
   intersection server to deliver
   specific amounts of all feature-tags understood by nominal media time per unit of delivery time,
   contingent on the proxies.  To
   achieve an intersection, server's ability and desire to serve the proxy adding media
   stream at the Proxy-Supported header
   includes all proxy feature-tags it understands.  Any proxy receiving given speed.  The client requests the delivery speed to
   be within a request given range with an upper and lower bound.  The server
   SHALL delivery at the header, checks highest possible speed within the list and removes any feature-
   tag it do range, but
   not support.  A Proxy-Supported header present in faster than the
   response upper-bound, for which the underlying network
   path can support the resulting transport data rates.  As long as any
   speed value within the given range can be provided the server SHALL
   NOT be touched by modify the proxies.

   Example:

     C->P1: OPTIONS rtsp://example.com/ RTSP/2.0
            Supported: foo, bar, blech
                    User-Agent: PhonyClient/1.2

    P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0
            Supported: foo, bar, blech
            Proxy-Supported: proxy-foo, proxy-bar, proxy-blech
            Via: 2.0 prox1.example.com

    P2->S:  OPTIONS rtsp://example.com/ RTSP/2.0
            Supported: foo, bar, blech
            Proxy-Supported: proxy-foo, proxy-blech
            Via: 2.0 prox1.example.com, 2.0 prox2.example.com

     S->C:  RTSP/2.0 200 OK
            Supported: foo, bar, baz
            Proxy-Supported: proxy-foo, proxy-blech
            Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
            Via: 2.0 prox1.example.com, 2.0 prox2.example.com

16.37.  Public

   The Public response header field lists media quality.  Only if the server is unable to
   delivery media at the set of methods supported speed value provided by the response sender.  This header applies to lower bound shall
   it reduce the general
   capabilities media quality.

   Implementation of the sender and its only purpose Speed functionality by the server is to OPTIONAL.
   The server can indicate its support through a feature-tag,
   play.scale.  The lack of a Speed header in the
   sender's capabilities response is an
   indication of lack of support of this functionality.

   The speed parameter values are expressed as a positive decimal value,
   e.g., a value of 2.0 indicates that data is to be delivered twice as
   fast as normal.  A speed value of zero is invalid.  The range is
   specified in the recipient. form "lower bound - upper bound".  The methods listed lower bound
   value may be smaller or equal to the upper bound.  All speeds may not
   be applicable possible to support.  Therefore the Request-URI; the Allow header field
   (section 14.7) server MAY be used modify the
   requested values to indicate methods allowed for a
   particular URI.

   Example of use:
      Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN

   In the event closest supported.  The actual supported
   speed MUST be included in the response.  Note however that there are proxies between the sender use
   cases may vary and that Speed value ranges such as 0.7 - 0.8,
   0.3-2.0, 1.0-2.5, 2.5-2.5 all has their usage.

   Example:
     Speed: 1.0 - 2.5
   Use of this header changes the
   recipient bandwidth used for data delivery.  It
   is meant for use in specific circumstances where delivery of the
   presentation at a response, each intervening proxy MUST modify higher or lower rate is desired.  The main use
   cases are buffer operations or local scale operations.  Implementors
   should keep in mind that bandwidth for the
   Public header field session may be negotiated
   beforehand (by means other than RTSP), and therefore re-negotiation
   may be necessary.  To perform Speed operations the server needs to remove any methods
   ensure that are not supported via the network path can support the resulting bit-rate.
   Thus the media transport needs to support feedback so that proxy. the server
   can react and adapt to the available bitrate.

16.47.  Server

   The resulting Public header Server response-header field will contains information about the
   software used by the origin server to handle the request.  The field
   can contain an
   intersection of multiple product tokens and comments identifying the sender's methods
   server and any significant subproducts.  The product tokens are
   listed in order of their significance for identifying the methods allowed through
   by
   application.

   Example:
   Server: PhonyServer/1.0

   If the intervening proxies.

      In general proxies should allow all methods to transparently pass response is being forwarded through from a proxy, the sending RTSP agent to proxy
   application MUST NOT modify the receiving Server response-header.  Instead, it
   SHOULD include a Via field (Section 16.56).

16.48.  Session

   The Session request-header and response-header field identifies an
   RTSP agent,
      but there may be cases where this session.  An RTSP session is not desirable for created by the server as a given
      proxy.  Modification result
   of a successful SETUP request and in the Public response header field the session
   identifier is given to the client.  The RTSP session exist until
   destroyed by a TEARDOWN, REDIRECT or timed out by the
      intervening proxies ensures that server.

   The session identifier is chosen by the request sender gets an
      accurate response indicating server (see Section 4.3) and
   MUST be returned in the methods SETUP response.  Once a client receives a
   session identifier, it MUST be included in any request related to
   that session.  This means that can be used on the
      target agent via the proxy chain.

16.38.  Range

   The Range Session header specifies a time range MUST be included in PLAY (Section 13.4), PAUSE
   (Section 13.6), SETUP (Section 13.3), REDIRECT (Section 13.10),
   a request using the following methods: PLAY, PAUSE, and
   PLAY_NOTIFY (Section 13.5) requests TEARDOWN, and responses.

   The range can
   MAY be specified included in a number of units.  This specification
   defines smpte (Section 4.4), npt (Section 4.5), SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, and clock
   (Section 4.6) range units.  While byte ranges [H14.35.1]
   REDIRECT, and other
   extended units MAY MUST NOT be used, their behavior is unspecified since they
   are not normally meaningful included in RTSP.  Servers supporting DESCRIBE.  In an RTSP response
   the Range session header MUST understand the NPT range format be included in methods, SETUP, PLAY, and SHOULD understand
   PAUSE, and MAY be included in methods, TEARDOWN, and REDIRECT, and if
   included in the
   SMPTE range format.  If request of the Range header is sent following methods it MUST also be
   included in a time format
   that is not understood, the recipient SHOULD return 456 (Header Field
   Not Valid for Resource) response, OPTIONS, GET_PARAMETER, and include SET_PARAMETER,
   and MUST NOT be included in DESCRIBE.

   Note that a session identifier identifies an Accept-Ranges header
   indicating the supported time formats RTSP session across
   transport sessions or connections.  RTSP requests for the given resource.

   The Range header MAY contain a time parameter in UTC, specifying given session
   can use different URIs (Presentation and media URIs).  Note, that
   there are restrictions depending on the
   time at session which URIs that are
   acceptable for a given method.  However, multiple "user" sessions for
   the operation is to be made effective.  This
   functionality SHALL be used only with same URI from the REDIRECT method.

   Example:
     Range: clock=19960213T143205Z-;time=19970123T143720Z same client will require use of different
   session identifiers.

      The notation session identifier is similar needed to that used distinguish several delivery
      requests for the HTTP/1.1 [RFC2616]
      byte-range header.  It allows clients to select an excerpt same URI coming from the media object, and to play from a given point to same client.

   The response 454 (Session Not Found) MUST be returned if the end as
      well as from session
   identifier is invalid.

   The header MAY include the current location session timeout period.  If not explicitly
   provided this value is set to a given point.

   Ranges 60 seconds.  As this affects how often
   session keep-alives are half-open intervals, including the first point, but
   excluding the second point.  In other words, a range needed values smaller than 30 seconds are not
   recommended.  However larger that default values can be useful in
   applications of A-B starts
   exactly at time A, RTSP that have inactive but stops just before B. Only the start established sessions for
   longer time of a
   media unit such periods.

      60 seconds was chosen as a video or audio frame is relevant.  For example,
   assume that video frames are generated every 40 ms.  A range of 10.0-
   10.1 would include a video frame starting at 10.0 or later time session timeout value due to: Resulting
      in not to frequent keep-alive messages and
   would include a video frame starting at 10.08, even though it lasted
   beyond having low sensitivity
      to variations in request response timing.  If one reduces the interval.  A range of 10.0-10.08, on
      timeout value to below 30 seconds the corresponding request
      response timeout becomes a significant part of the other hand, would
   exclude session
      timeout. 60 seconds also allows for reasonably rapid recovery of
      committed server resources in case of client failure.

16.49.  Supported

   The Supported header enumerates all the frame at 10.08.

   By default, range intervals increase, where extensions supported by the second point is
   larger than
   client or server using feature tags.  The header carries the first point.

   Example:
       Range: npt=10-15

   However, range intervals can also decrease if
   extensions supported by the Scale message sending entity.  The Supported
   header (see
   Section 16.44) indicates a negative scale value.  For example, this
   would MAY be the case when included in any request.  When present in a playback request,
   the receiver MUST respond with its corresponding Supported header.
   Note, also in reverse is desired.

   Example:
       Scale: -1
       Range: npt=15-10

   Decreasing ranges are still half open intervals as described above.
   Thus, for range A-B, A is closed 4xx and B 5xx responses is open.  In the above
   example, 15 is closed and 10 is open.  An exception to this rule is supported header included.

   The Supported header contains a list of feature-tags, described in
   Section 4.7, that are understood by the case client or server.

   Example:

     C->S:  OPTIONS rtsp://example.com/ RTSP/2.0
            Supported: foo, bar, blech
            User-Agent: PhonyClient/1.2

     S->C:  RTSP/2.0 200 OK
            Supported: bar, blech, baz

16.50.  Terminate-Reason

   The Terminate-Reason request header allows the server when B=0 in sending a decreasing range.  In this case, the range is
   closed on both ends, as otherwise there would be no way
   REDIRECT or TERMINATE request to reach 0 on provide a reverse playback reason for formats that have such a notion, like NPT the session
   termination and
   SMPTE.

   Example:
       Scale: -1
       Range: npt=15-0

   In this range both 15 any additional information.  This specification
   identifies three reasons for Redirections and 0 are closed.

   A decreasing range interval without a corresponding negative Scale
   header is not valid.

16.39.  Referer

   See [H14.36]. may be extended in the
   future:

   Server-Admin:  The URI refers server needs to that be shutdown for some
      administrative reason.

   Session-Timeout:  A client's session is kept alive for extended
      periods of time and the presentation
   description, typically retrieved via HTTP.

16.40.  Retry-After

   See [H14.37].

16.41.  Request-Status

   This request header is used server has determined that it needs to indicate
      reclaim the end result for requests resources associated with this session.

   Internal-Error  An internal error that takes time to complete, such a PLAY (Section 13.4).  It is sent
   in PLAY_NOTIFY (Section 13.5) with impossible to recover from
      has occurred forcing the end-of-stream reason server to report
   how terminate the PLAY request concluded, either in success or in failure. session.

   The
   header carries Server may provide additional parameters containing information
   around the redirect.  This specification defines the following ones.

   time:  Provides a reference to wallclock time when the request is reports on using server will stop provide
      any service.

   user-msg:  An UTF-8 text string with a message from the
   CSeq number for server to the session indicated by
      user.  This message SHOULD be displayed to the Session header in user.

16.51.  Timestamp

   The Timestamp general-header describes when the agent sent the
   request.  It provies both a numerical status code (according  The value of the timestamp is of significance only to
   Section 8.1.1) the
   agent and may use any timescale.  The responding agent MUST echo the
   exact same value and MAY, if it has accurate information about this,
   add a human readable reason phrase.

   Example:
   Request-Status: cseq=63 status=500 reason="Media data unavailable"

16.42.  Require floating point number indicating the number of seconds that has
   elapsed since it has received the request.  The Require request-header field timestamp is used by clients or servers to
   ensure that
   the other end-point supports features that are required
   in respect agent to this request.  It can also be used compute the round-trip time to query if the
   other end-point supports certain features, however responding agent so
   that it can adjust the use timeout value for retransmissions.  It also
   resolves retransmission ambiguities for unreliable transport of the
   Supported (Section 16.49) is much more effective in this purpose. RTSP.

16.52.  Transport

   The server MUST respond to this header by using the Unsupported Transport request and response header indicates which transport
   protocol is to negatively acknowledge be used and configures its parameters such as
   destination address, compression, multicast time-to-live and
   destination port for a single stream.  It sets those feature-tags which are NOT
   supported.  The response SHALL use the error code 551 (Option Not
   Supported).  This header does values not apply
   already determined by a presentation description.

   A Transport request header MAY contain a list of transport options
   acceptable to proxies, for the same
   functionality client, in respect to proxies see Proxy-Require header
   (Section 16.35) with the exception of media modifying proxies.  Media
   modifying proxies due to their nature form of handling media multiple transport
   specification entries.  Transport specifications are comma separated,
   listed in a way that
   is very similar decreasing order of preference.  Parameters may be added to what
   each transport specification, separated by a server, do need to understand also the semicolon.  The server features to correctly serve
   MUST return a Transport response-header in the client.

      This is response to make sure that indicate
   the client-server interaction will
      proceed without delay when all features are understood by both
      sides, and only slow down values actually chosen if features are any.  If not understood (as in transport specification is
   supported no transport header is returned and the example below).  For a well-matched client-server pair, request MUST be
   responded using the
      interaction proceeds quickly, saving a round-trip often required
      by negotiation mechanisms. status code 461 (Unsupported Transport)
   (Section 15.4.26).  In addition, it also removes state
      ambiguity when case more than one transport specification was
   present in the client requires features that request, the server does
      not understand.

   Example (Not complete):
   C->S:   SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0
           CSeq: 302
           Require: funky-feature
           Funky-Parameter: funkystuff

   S->C:   RTSP/2.0 551 Option not supported
           CSeq: 302
           Unsupported: funky-feature

   In this example, "funky-feature" is MUST return the feature-tag single (transport-
   spec) which indicates was actually chosen if any.  The number of transport-spec
   entries is expected to be limited as the client will get guidance on
   what configurations that are possible from the fictional Funky-Parameter field is required. presentation
   description.

   The relationship between "funky-feature" and Funky-Parameter is not
   communicated via the RTSP exchange, since that relationship is Transport header MAY also be used in subsequent SETUP requests to
   change transport parameters.  A server MAY refuse to change
   parameters of an
   immutable property existing stream.

   A transport specification may only contain one of "funky-feature" and thus should not any given parameter
   within it.  Parameters MAY be
   transmitted with every exchange.

   Proxies and other intermediary devices SHALL ignore this header.  If given in any order.  Additionally, it
   may only contain either of the unicast or the multicast transport
   type parameter.  All parameters need to be understood in a particular extension requires that intermediate devices support it, transport
   specification, if not, the extension should transport specification MUST be tagged in ignored.
   RTSP proxies of any type that uses or modifies the Proxy-Require field instead
   (see Section 16.35).  See discussion in transport
   specification, e.g. access proxy or security proxy, MUST remove
   specifications with unknown parameters before forwarding the proxies section
   (Section 17.1) about when to consider RTSP
   message.  If that a feature requires result in no remaining transport specification the
   proxy
   support.

16.43.  RTP-Info shall send a 461 (Unsupported Transport) (Section 15.4.26)
   response without any Transport header.

      The RTP-Info response-header field Transport header is used restricted to set RTP-specific
   parameters in the PLAY response.  For describing a single media
      stream.  (RTSP can also control multiple streams using RTP as transport
   protocol the RTP-Info header SHOULD be a single
      entity.)  Making it part of RTSP rather than relying on a 200 response to
   PLAY.

      The exclusion
      multitude of session description formats greatly simplifies
      designs of firewalls.

   The general syntax for the RTP-Info in transport specifier is a PLAY response list of slash
   separated tokens:
   Value1/Value2/Value3...
   Which for RTP
      transported media will result in that a client needs to
      synchronize transports take the media streams using RTCP.  This may have negative
      impact as form:
   RTP/profile/lower-transport.

   The default value for the RTCP can be lost, and does not need "lower-transport" parameters is specific to be
      particulary timely in their arrival.  Also functionality as
      informing
   the client from which packet a seek has occurred profile.  For RTP/AVP, the default is
      affected.

   The RTP-Info MAY also be included in SETUP responses UDP.

   There are two different methods for how to provide
   synchronization information when changing transport parameters, see
   Section 13.3.

   The header can carry specify where the following parameters:

   url:  Indicates media
   should be delivered for unicast transport:

   dest_addr:  The presence of this parameter and its values indicates
         the stream URI which destination address or addresses (host address and port
         pairs for IP flows) necessary for which the following RTP
         parameters correspond, this URI MUST be media transport.

   No dest_addr:  The lack of the dest_addr parameter indicates that the
         server MUST send media to same used in address for which the
         SETUP request RTSP
         messages originates.  Does not work for this transports requiring
         explicitly given destination ports.

   The choice of method for indicating where the media stream.  Any relative URI SHALL is to be
   delivered depends on the use case.  In some case the Request-URI as base URI.  This parameter SHALL only allowed
   method will be
         present.

   ssrc: The Synchronization source (SSRC) that the RTP timestamp to use no explicit address indication and
         sequence number provide applies to.  This parameter SHALL be
         present.

   seq:  Indicates have the sequence number of
   server deliver media to the first packet source of the stream
         that RTSP messages.

   For Multicast there is direct result of several methods for specifying addresses but
   they are different in how they work compared with unicast:

   dest_addr with client picked address:  The address and relevant
         parameters like TTL (scope) for the request.  This allows clients actual multicast group to
         gracefully deal
         deliver the media to.  There are security implications
         (Section 21) with packets when seeking. this method that needs to be addressed if
         using this method because a RTSP server can be used as a DoS
         attacker on a existing multicast group.

   dest_addr using Session Description Information:  The client uses
         this value to differentiate packets that originated before information
         included in the
         seek transport header can all be coming from packets that originated after the seek.  Note that a
         client may not receive the packet with
         session description, e.g. the expressed sequence
         number, SDP c= and instead packets with a higher sequence number, due
         to packet loss or reordering. m= line.  This parameter is RECOMMENDED to
         be present.

   rtptime:  SHALL indicate
         mitigates some of the RTP timestamp value corresponding to security issues of the
         start time value in previous methods
         as it is the Range response header, or if not
         explicitly given session provider that picks the implied start point. multicast group
         and scope.  The client uses this
         value to calculate MUST include the mapping of RTP time to NPT or other
         media timescale.  This parameter SHOULD be present to ensure
         inter-media synchronization information if it is achieved.  There exist no
         requirement that any received RTP packet will have the same RTP
         timestamp value as the one
         available in the parameter used to establish
         synchronization.

      A mapping from RTP timestamps to NTP timestamps (wall clock) is
      available via RTCP.  However, this information session description.

   No dest_addr:  The behavior when no explicit multicast group is not sufficient
      to generate a mapping from RTP timestamps to media clock time
      (NPT, etc.).  Furthermore,
         present in order to ensure that this
      information is available at the necessary time (immediately at
      startup or after a seek), and that it is delivered reliably, this
      mapping request is placed in the RTSP control channel.

      In order to compensate for drift for long, uninterrupted
      presentations, not defined.

   An RTSP clients should additionally map NPT proxy will need to NTP,
      using initial RTCP sender reports take care.  If the media is not desired to do
   be routed through the mapping, and later
      reports proxy, the proxy will need to check drift against introduce the mapping.

   Example:
   Range:npt=3.25-15
   RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102;
            rtptime=12345678,url="rtsp://example.com/foo/video"
            ssrc=9A9DE123:seq=30211;rtptime=29567112

   Lets assume that Audio uses a 16kHz RTP timestamp clock and Video
   a 90kHz RTP timestamp clock. Then
   destination indication.

   Below are the media synchronization configuration parameters associated with transport:

   General parameters:

   unicast / multicast:  This parameter is
   depicted in a mutually exclusive
         indication of whether unicast or multicast delivery will be
         attempted.  One of the following way.

   NPT    3.0---3.1---3.2-X-3.3---3.4---3.5---3.6
   Audio               PA A
   Video                  V    PV

   X: NPT time value = 3.25, from Range header.
   A: RTP timestamp value for Audio from RTP-Info header (12345678).
   V: RTP timestamp value for Video from RTP-Info header (29567112).
   PA: RTP audio packet carrying an RTP timestamp two values MUST be specified.  Clients
         that are capable of 12344878. Which
       corresponds handling both unicast and multicast
         transmission needs to NPT = (12344878 - A) / 16000 + 3.25 = 3.2
   PV: RTP video packet carrying an RTP timestamp indicate such capability by including two
         full transport-specs with separate parameters for each.

   layers:  The number of 29573412. Which
       corresponds multicast layers to NPT = (29573412 - V) / 90000 + 3.25 = 3.32

16.44.  Scale

   A scale value of 1 indicates normal play at the normal forward
   viewing rate.  If not 1, the value corresponds be used for this media
         stream.  The layers are sent to consecutive addresses starting
         at the rate with
   respect dest_addr address.  If the parameter is not included, it
         defaults to normal viewing rate.  For example, a ratio single layer.

   dest_addr:  A general destination address parameter that can contain
         one or more address specifications.  Each combination of 2 indicates
   twice
         Protocol/Profile/Lower Transport needs to have the normal viewing rate ("fast forward") format and a ratio
         interpretation of 0.5
   indicates half its address specification defined.  For RTP/
         AVP/UDP and RTP/AVP/TCP, the normal viewing rate.  In other words, address specification is a ratio of 2
   has normal play time increase at twice the wallclock rate.  For every
   second of elapsed (wallclock) time, 2 seconds tuple
         containing a host address and port.  Note, only a single
         destination entity per transport spec is intended.  The usage
         of content will be
   delivered.  A negative value indicates reverse direction.  For
   certain multiple destination to distribute a single media transports this may require certain considerations to
   work consistent, see Appendix C.1 for description on how RTP handles
   this.

   Unless requested otherwise by
         multiple entities is unspecified.

         The client originating the Speed parameter, RTSP request MAY specify the data rate
   SHOULD NOT be changed.  Implementation
         destination address of scale changes depends on the server and media type.  For video, a server may, for example,
   deliver only key frames or selected key frames.  For audio, for
   example, it may time-scale stream recipient with the audio while preserving pitch or, less
   desirably, deliver fragments host
         address part of audio.

   The server should try to approximate the viewing rate, but tuple.  When the destination address is
         specified, the recipient may
   restrict be a different party than the range
         originator of scale values that it supports.  The response the request.  To avoid becoming the unwitting
         perpetrator of a remote-controlled denial-of-service attack, a
         server MUST contain perform security checks (see Section 21.1) and
         SHOULD log such attempts before allowing the actual scale value client to direct a
         media stream to a recipient address not chosen by the server.
         Implementations cannot rely on TCP as reliable means of client
         identification.  If the server does not implement allow the possibility host address
         part of the tuple to scale, be set, it will
   not MUST return a Scale header.  A server supporting Scale operations for
   PLAY SHALL indicate this with the use 463 (Destination
         Prohibited).

         The host address part of the "play.scale" feature-
   tags.

   When indicating a negative scale tuple MAY be empty, for a reverse playback, the Range
   header MUST indicate a decreasing range as described in
   Section 16.38.

   Example of playing example
         ":58044", in reverse at 3.5 times normal rate:
     Scale: -3.5
     Range: npt=15-10

16.45.  Seek-Style

   When a client sends a PLAY request with a Range header cases when only destination port is desired to perform a
   random access be
         specified.  Responses to request including the media, Transport header
         with a dest_addr parameter SHOULD include the client does not know if full destination
         address that is actually used by the server.  The server
   will pick the first media samples or the first random access point
   prior to MUST
         NOT remove address information present already in the request range.  Depending on use case,
         when responding unless the client may protocol requires it.

   src_addr:  A general source address parameter that can contain one or
         more address specifications.  Each combination of Protocol/
         Profile/Lower Transport needs to have a strong preference.  To express this preference the format and
         interpretation of its address specification defined.  For RTP/
         AVP/UDP and provide RTP/AVP/TCP, the
   client with information on how address specification is a tuple
         containing a host address and port.

         This parameter MUST be specified by the server actually acted on that
   preference if it transmits
         media packets from another address than the Seek-Style header is defined.

   Seek-Style is one RTSP messages
         are sent to.  This will allow the client to verify source
         address and give it a general header that MAY be included destination address for its RTCP feedback
         packets if RTP is used.  The address or addresses indicated in any PLAY
   request to indicate
         the client's preference src_addr parameter SHOULD be used both for any sending and
         receiving of the media stream that
   has random access properties. streams data packets.  The server SHALL always include main reasons
         are threefold: First, indicating the
   header in any PLAY response for media with random access properties
   to indicate what policy was applied.  A Server that receives a
   unknown Seek-Style policy SHALL ignore it port and select source address(s)
         lets the server
   default policy.

   This specification defines receiver know where from the following seek policies that may be
   requested:

   RAP:  Random Access Point (RAP) packets is the behavior expected to
         originate.  Secondly, traversal of requesting NATs are greatly simplified
         when traffic is flowing symmetrically over a NAT binding.
         Thirdly, certain NAT traversal mechanisms, needs to know to
         which address and port to send so called "binding packets" from
         the
      server receiver to locate the closest previous random access point that
      exist sender, thus creating a address binding in
         the media aggregate and deliver from that.  By requesting
      a RAP media quality will be NAT that the best possible as all media will sender to receiver packet flow can use.

               This information may also be
      delivered from available through SDP.
               However, since this is more a point where full feature of transport than
               media state can initialization, the authoritative source for this
               information should be established in the media decoder.

   First-Prior: SETUP response.

   mode: The first-prior policy will start delivery with mode parameter indicates the
      media unit that has a playout time first prior methods to the requested
      time.  For discrete media that would only include media units that
      would still be rendered at supported for
         this session.  Valid values are PLAY and RECORD.  If not
         provided, the request time.  For continous media
      that default is media that will be render during the requested start time
      of the range.

   Next: PLAY.  The next media units after the provided start time of the
      range.  For continous framed media that would mean the first next
      frame after RECORD value was defined in
         RFC 2326 and is in this specification unspecified but reserved.

   interleaved:  The interleaved parameter implies mixing the provided time.  For discrete media
         stream with the first unit
      that control stream in whatever protocol is to be rendered after being
         used by the provided time. control stream, using the mechanism defined in
         Section 14.  The main usage is
      for this case is when argument provides the client knows it has all media up channel number to a
      certain point be
         used in the $ statement and would like to continue delivery so that a
      complete non-interrupted media playback can MUST be achieved.  Example
      of such scenarios include switching from a broadcast/multicast
      delivery to a unicast based delivery.  This policy SHALL only present.  This parameter
         MAY be
      used on specified as a interval, e.g., interleaved=4-5 in cases
         where the client's explicit request.

   Please note that these expressed preferences exist transport choice for optimizing the
   startup time or the media quality. stream requires it,
         e.g. for RTP with RTCP.  The "Next" policy breaks the
   normal definition of channel number given in the Range header to enable
         request are only a guidance from the client to request
   media with minimal overlap, although some may still occur for
   aggregated sessions.  RAP and First-Prior the server on
         what channel number(s) to use.  The server MAY set any valid
         channel number in the response.  The declared channel(s) are
         bi-directional, so both fulfill end-parties MAY send data on the
   requirement given
         channel.  One example of providing media from the requested range and forward.
   However, unless RAP such usage is used, the media quality second channel used
         for many media codecs
   using predictive methods can RTCP, where both server and client sends RTCP packets on
         the same channel.

               This allows RTP/RTCP to be severly degraded unless additional
   data handled similarly to the way
               that it is available as, done with UDP, i.e., one channel for example, already buffered, or through RTP and
               the other
   side channels.

16.46.  Speed

   The Speed request-header field for RTCP.

   Multicast-specific:

   ttl:  multicast time-to-live for IPv4.  When included in requests the server to deliver data to
         value indicate the TTL value that the client at a particular speed, contingent on request the server's ability
   and desire server
         to serve the media stream at use.  In a response, the given speed.
   Implementation value actually being used by the
         server is OPTIONAL.  The default is returned.  A server will need to consider what values
         that are reasonable and also the bit
   rate authority of the stream.

   The parameter value is expressed as a decimal ratio, e.g., a value of
   2.0 indicates that data is user to be delivered twice as fast set
         this value.  Corresponding function are not needed for IPv6 as normal.
   A speed of zero
         the scoping is invalid.  All speeds may not part of the address.

   RTP-specific:

   These parameters are MAY only be possible to
   support.  Therefore used if the actual media transport protocol
   is RTP.

   ssrc: The ssrc parameter, if included in a SETUP response, indicates
         the RTP SSRC [RFC3550] value(s) that will be used speed by the media
         server for RTP packets within the stream.  It is expressed as
         an eight digit hexadecimal value.

         The ssrc parameter MUST NOT be included specified in the
   response. requests.  The lack
         functionality of specifying the ssrc parameter in a response header SETUP
         request is indication of lack of
   support from deprecated as it is incompatible with the server of this functionality.  Support
         specification of RTP in RFC 3550[RFC3550].  If the speed
   functionality are indicated by parameter is
         included in the "play.speed" feature-tag.

   Example:
     Speed: 2.5

   Use Transport header of this field changes a SETUP request, the bandwidth used for data delivery.  It
   is meant server
         MAY ignore it, and choose appropriate SSRCs for use in specific circumstances where preview of the
   presentation at a higher or lower rate is necessary.  Implementors
   should keep stream.
         The server MAY set the ssrc parameter in mind that bandwidth for the session may be negotiated
   beforehand (by means other than RTSP), and therefore re-negotiation
   may be necessary.  When data is delivered over UDP, it is highly
   recommended that means such as RTCP Transport header
         of the response.

   The parameters defined below MAY only be used to track packet loss
   rates.  If if the data media transport
   protocol of the lower-level transport is performed connection-oriented (such as
   TCP).  However, these parameters MUST NOT be used when interleaving
   data over non-dedicated best-
   effort networks the sender is required to perform congestion RTSP control
   of connection.

   setup:  Clients use the stream(s). setup parameter on the Transport line in a
         SETUP request, to indicate the roles it wishes to play in a TCP
         connection.  This can result parameter is adapted from [RFC4145].  We
         discuss the use of this parameter in that RTP/AVP/TCP non-
         interleaved transport in Appendix C.2.2; the communicated speed discussion below
         is
   impossible limited to maintain.

16.47.  Server

   See [H14.38], however syntactic issues.  Clients may specify the header syntax is corrected in
   Section 20.2.3.

16.48.  Session
         following values for the setup parameter: ["active":] The Session request-header and response-header field identifies
         client will initiate an
   RTSP session.  An RTSP session outgoing connection. ["passive":] The
         client will accept an incoming connection. ["actpass":] The
         client is created by the server as willing to accept an incoming connection or to
         initiate an outgoing connection.

         If a result
   of client does not specify a successful SETUP request and in setup value, the "active" value
         is assumed.

         In response to a client SETUP request where the session
   identifier setup parameter
         is given set to "active", a server's 2xx reply MUST assign the setup
         parameter to "passive" on the client.  The RTSP session exist until
   destroyed by Transport header line.

         In response to a TEARDOWN or timed out by client SETUP request where the server.

   The session identifier setup parameter
         is chosen by the server (see Section 4.3) and set to "passive", a server's 2xx reply MUST be returned in assign the SETUP response.  Once setup
         parameter to "active" on the Transport header line.

         In response to a client receives a
   session identifier, it SHALL be included in any SETUP request related where the setup parameter
         is set to
   that session.  This means that "actpass", a server's 2xx reply MUST assign the Session setup
         parameter to "active" or "passive" on the Transport header MUST be included in
   a request using
         line.

         Note that the following methods: PLAY, PAUSE, and TEARDOWN, and
   MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, and
   REDIRECT, "holdconn" value for setup is not defined for
         RTSP use, and SHALL MUST NOT be included in DESCRIBE.  In an RTSP response appear on a Transport line.

   connection:  Clients use the session header SHALL be included in methods, SETUP, PLAY, and
   PAUSE, and MAY be included in methods, TEARDOWN, and REDIRECT, and if
   included setup parameter on the Transport line in
         a SETUP request, to indicate the SETUP request prefers the
         reuse of an existing connection between client and server (in
         which case the following methods it SHALL also be
   included in client sets the response, OPTIONS, GET_PARAMETER, and SET_PARAMETER,
   and SHALL NOT be included in DESCRIBE.

   Note that a session identifier identifies an RTSP session across
   transport sessions "connection" parameter to
         "existing"), or connections.  RTSP requests for a given session
   can use different URIs (Presentation and media URIs).  Note, that
   there are restrictions depending on the session client requires the creation of a new
         connection between client and server (in which URIs that are
   acceptable cast the client
         sets the "connection" parameter to "new").  Typically, clients
         use the "new" value for the first SETUP request for a given method.  However, multiple "user" sessions URL, and
         "existing" for subsequent SETUP requests for a URL.

         If a client SETUP request assigns the same URI from "new" value to
         "connection", the same server response MUST also assign the "new"
         value to "connection" on the Transport line.

         If a client will require use SETUP request assigns the "existing" value to
         "connection", the server response MUST assign a value of different
   session identifiers.
         "existing" or "new" to "connection" on the Transport line, at
         its discretion.

         The session identifier default value of "connection" is needed to distinguish several delivery
      requests "existing", for all SETUP
         requests (initial and subsequent).

   RTCP-mux:  Use to negotiate the same URI coming from the same client. usage of RTP and RTCP multiplexing
         [I-D.ietf-avt-rtp-and-rtcp-mux] on a single underlying
         transport stream.  The response 454 (Session Not Found) SHALL be returned if presence of this parameter in a SETUP
         request indicates the session
   identifier is invalid.

16.49.  Supported clients support and desire to use RTP and
         RTCP multiplexing.  The Supported header field enumerates all client MAY still include two transport
         streams in the extensions Transport header specification to handle cases
         if RTP and RTCP multiplexing is not supported by the client or server using feature tags.  The header carries server.
         If the
   extensions supported by server supports the message sending entity.  The Supported
   header MAY be included in any request.  When present usage of RTP and RTCP multiplexing
         it SHALL include this parameter in the response and strip down
         the transport address negotiation to a request, single src_addr and
         dest_addr.  If the receiver MUST respond with its corresponding Supported header.
   Note, also in 4xx server does not support RTP and 5xx responses RTCP
         multiplexing is removes this parameter from the supported header transport
         specification in response and treat the specification as if the
         parameter was not included.

   The Supported header field contains a list combination of feature-tags, described
   in Section 4.7, that transport protocol, profile and lower transport
   needs to be defined.  A number of combinations are understood by defined in the
   Appendix C.

   Below is a usage example, showing a client advertising the capability
   to handle multicast or server.

   Example: unicast, preferring multicast.  Since this is
   a unicast-only stream, the server responds with the proper transport
   parameters for unicast.

     C->S:  OPTIONS rtsp://example.com/ SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
            Supported: foo, bar, blech
           CSeq: 302
           Transport: RTP/AVP;multicast;mode="PLAY",
               RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
               "192.0.2.5:3457";mode="PLAY"
           Accept-Ranges: NPT, SMPTE, UTC
           User-Agent: PhonyClient/1.2

     S->C: RTSP/2.0 200 OK
            Supported: bar, blech, baz

16.50.  Timestamp
           CSeq: 302
           Date: Thu, 23 Jan 1997 15:35:06 GMT
           Session: 47112344
           Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
              "192.0.2.5:3457";src_addr="192.0.2.224:6256"/
              "192.0.2.224:6257";mode="PLAY"
           Accept-Ranges: NPT
           Media-Properties: Random-Access=0.6, Dynamic,
                             Time-Limited=20081128T165900

16.53.  Unsupported

   The Timestamp general-header field describes when Unsupported response-header lists the agent sent features not supported by
   the
   request.  The value of server.  In the timestamp case where the feature was specified via the
   Proxy-Require field (Section 16.35), if there is of significance only to a proxy on the
   agent path
   between the client and may use any timescale. the server, the proxy MUST send a response
   message with a status code of 551 (Option Not Supported).  The responding agent
   request MUST echo the
   exact same value and MAY, if it has accurate NOT be forwarded.

   See Section 16.42 for a usage example.

16.54.  User-Agent

   The User-Agent request-header field contains information about this,
   add a floating point number indicating the number of seconds that has
   elapsed since it has received
   user agent originating the request.  The timestamp  This is used by for statistical
   purposes, the agent to compute tracing of protocol violations, and automated
   recognition of user agents for the round-trip time sake of tailoring responses to the responding
   avoid particular user agent so
   that it can adjust the timeout value for retransmissions.  It also
   resolves retransmission ambiguities for unreliable transport of RTSP.

16.51.  Transport limitations.  User agents SHOULD include
   this field with requests.  The Transport request and response header field indicates which
   transport protocol is to be used can contain multiple product
   tokens and configures its parameters such
   as destination address, compression, multicast time-to-live comments identifying the agent and
   destination port for a single stream.  It sets those values not
   already determined by a presentation description.

   A Transport request header field MAY contain any subproducts which
   form a list significant part of transport
   options acceptable to the client, in user agent.  By convention, the form of multiple transport
   specification entries.  Transport specifications
   product tokens are comma separated, listed in decreasing order of preference.  Parameters may be added their significance for
   identifying the application.

   Example:
   User-Agent: PhonyClient/1.2

16.55.  Vary

   Editor's note: this section needs to
   each transport specififcation, separated by a semicolon. reviewed, as RTSP does not cache
   responses.

   The server
   MUST return a Transport response-header Vary field in value indicates the response to
   indicate set of request-header fields that
   fully determines, while the values actually chosen if any.  If not transport
   specification response is supported no transport header fresh, whether a cache is returned and
   permitted to use the response to reply to a subsequent request SHALL be responded using the status code 461 (Unsupported
   Transport) (Section 15.4.13).  In case more than one transport
   specification was present in
   without revalidation.  For uncacheable or stale responses, the request, Vary
   field value advises the server MUST return user agent about the
   single (transport-spec) which was actually chosen if any.  The number
   of transport-spec entries is expected criteria that were used
   to be limited as select the client
   will get guidance on what configurations representation.  A Vary field value of "*" implies that are possible
   a cache cannot determine from the
   presentation description.

   The Transport request headers of a subsequent
   request whether this response is the appropriate representation.  See
   section 13.6 XXX for use of the Vary header field MAY also be used in subsequent SETUP
   requests to change transport parameters.  A by caches

   An RTSP server MAY refuse to
   change parameters of an existing stream.

   A transport specification may only contain one of any given parameter
   within it.  Parameters MAY be given in SHOULD include a Vary header field with any order.  Additionally, it
   may only contain either of the unicast or the multicast transport
   type parameter.  All parameters needs cacheable
   response that is subject to be understood in server-driven negotiation.  Doing so
   allows a transport
   specification, if not the transport specification SHALL be ignored.
   RTSP proxies of any type cache to properly interpret future requests on that uses or modifies resource
   and informs the transport
   specification, e.g. acces proxy or security proxy, SHALL remove
   specifications with unknown parameters before forwarding user agent about the RTSP
   message.  If presence of negotiation on that result in no remaing transport specification the
   proxy shall send
   resource.  A server MAY include a 461 (Unsupported Transport) (Section 15.4.13)
   response without any Transport header.

      The Transport Vary header field with a non-
   cacheable response that is restricted subject to describing a single
      media stream.  (RTSP can also control multiple streams as a single
      entity.)  Making it part server-driven negotiation,
   since this might provide the user agent with useful information about
   the dimensions over which the response varies at the time of RTSP rather than relying on a
      multitude the
   response.

   A Vary field value consisting of session description formats greatly simplifies
      designs a list of firewalls.

   The general syntax field-names signals that
   the representation selected for the transport specifier response is based on a list of slash
   separated tokens:

   Value1/Value2/Value3...
   Which selection
   algorithm which considers ONLY the listed request-header field values
   in selecting the most appropriate representation.  A cache MAY assume
   that the same selection will be made for RTP transports take future requests with the form:
   RTP/profile/lower-transport.

   The default value
   same values for the "lower-transport" parameters is specific to listed field names, for the profile.  For RTP/AVP, duration of time for
   which the default response is UDP.

   There fresh.

   The field-names given are two different methods for how not limited to specify where the media
   should be delivered for unicast transport:

   dest_addr:  The presence set of standard request-
   header fields defined by this parameter and its values indicates specification.  Field names are case-
   insensitive.

   A Vary field value of "*" signals that unspecified parameters not
   limited to the destination address or addresses (host request-headers (e.g., the network address and port
         pairs for IP flows) necessary for of the media transport.

   No dest_addr:  The lack
   client), play a role in the selection of the dest_addr parameter indicates that response representation.
   The "*" value MUST NOT be generated by a proxy server; it may only be
   generated by an origin server.

16.56.  Via

   The Via general-header field MUST be used by proxies to indicate the
   intermediate protocols and recipients between the user agent and the
   server SHALL send media on requests, and between the origin server and the client on
   responses.  The field is intended to same address be used for which tracking message
   forwards, avoiding request loops, and identifying the RTSP
         messages originates.  Does not work for transports requiring
         explicitly given destination ports.

   The choice protocol
   capabilities of method for indicating where all senders along the media request/response chain.

   Multiple Via field values represents each proxy that has forwarded
   the message.  Each recipient MUST append its information such that
   the end result is ordered according to be
   delivered depends on the use case.  In some case sequence of forwarding
   applications.

   Proxies (e.g., Access Proxy or Translator Proxy) SHOULD NOT, by
   default, forward the only allowed
   method will be to use no explicit address indication names and have ports of hosts within the
   server deliver media to private/
   protected region.  This information SHOULD only be propagated if
   explicitly enabled.  If not enabled, the source via-received of any host
   behind the RTSP messages. firewall/NAT SHOULD be replaced by an appropriate
   pseudonym for that host.

   For Multicast there is several methods organizations that have strong privacy requirements for specifying addresses but
   they are hiding
   internal structures, a proxy MAY combine an ordered subsequence of
   Via header field entries with identical sent-protocol values into a
   single such entry.  Applications MUST NOT combine entries which have
   different received-protocol values.

16.57.  WWW-Authenticate

   The WWW-Authenticate response-header field MUST be included in how they work compared with unicast:

   dest_addr with client picked address: 401
   (Unauthorized) response messages.  The address field value consists of at
   least one challenge that indicates the authentication scheme(s) and relevant
   parameters like TTL (scope) for the actual multicast group applicable to
         deliver the media to.  There Request-URI.

   The HTTP access authentication process is described in [RFC2617].
   User agents are security implications
         (Section 21) with this method that needs advised to be addressed take special care in parsing the WWW-
   Authenticate field value as it might contain more than one challenge,
   or if
         using this method because more than one WWW-Authenticate header field is provided, the
   contents of a RTSP server challenge itself can be used as a DoS
         attacker on contain a existing multicast group.

   dest_addr using Session Decription Information:  The information
         included comma-separated list of
   authentication parameters.

17.  Proxies

   RTSP Proxies are RTSP agents that sit in the transport header between a client and a
   server.  A proxy can all be comming from the
         session description, e.g. take on both the SDP c= role as a client and m= line.  This
         mitigates some of the security issues of the previous methods as server
   depending on what it tries to accomplish.  Proxies are also
   introduced for several different reasons and the below are often
   combined.

   Caching Proxy:  This type of proxy is used to reduce the session provider that picks workload on
         servers and connections.  By caching the multicast group description and scope.  The client SHALL include media
         streams, i.e., the information if it is
         available in presentation, the session description.

   No dest_addr:  The lack of an explicit multicast group request proxy can serve a client
         with content, but without requesting it from the server to decide the group address once it
         has been cached and its scope.  For this has not become stale.  See the caching
         Section 18.  This type of proxy is also expected to
         work understand
         RTSP end-point functionality, i.e., functionality identified in
         the server needs Require header in addition to have a context about what scope that
         works. Proxy-Require demands.

   Translator Proxy:  This method type of proxy is currently under specified.

   An used to ensure that an RTSP proxy will need
         client get access to take care.  If the media is servers and content on an external network
         or using content encodings not desired to
   be routed through the proxy, supported by the client.  The
         proxy will need to introduce the
   destination indication.

   Below are performs the configuration parameters associated with transport:

   General parameters:

   unicast / multicast:  This parameter is a mutually exclusive
         indication necessary translation of whether unicast addresses,
         protocols or multicast delivery will be
         attempted.  One encodings.  This type of proxy is expected to also
         understand RTSP end-point functionality, i.e. functionality
         identified in the two values MUST be specified.  Clients
         that are capable of handling both unicast and multicast
         transmission needs Require header in addition to indicate such capability by including two
         full transport-specs with separate parameters for each.

   layers:  The number what Proxy-
         Require demands.

   Access Proxy:  This type of multicast layers to be used for this media
         stream.  The layers are sent to consecutive addresses starting
         at the dest_addr address.  If the parameter proxy is not included, it
         defaults used to a single layer.

   dest_addr:  A general destination address parameter ensure that can contain
         one or more address specifications.  Each combination of
         Protocol/Profile/Lower Transport needs a RTSP
         client get access to have the format and
         interpretation of its address specification defined.  For RTP/
         AVP/UDP and RTP/AVP/TCP, the address specification servers on an external network.  Thus this
         proxy is placed on the border between two domains, e.g. a tuple
         containing a host
         private address space and port.  Note, only a single
         destination entity per transport spec is intended. the public Internet.  The usage proxy
         performs the necessary translation, usually addresses.  This
         type of multiple destination proxies are required to distribute redirect the media to
         themselves or a single controlled gateway that perform the translation
         before the media to
         multiple entities can reach the client.

   Security Proxy:  This type of proxy is unspecified.

         The client originating used to help facilitate
         security functions around RTSP.  For example when having a
         firewalled network, the RTSP security proxy request MAY specify that the
         destination address of
         necessary pinholes in the stream recipient with firewall is opened when a client in
         the host
         address part protected network want to access media streams on the
         external side.  This proxy can also limit the clients access to
         certain type of content.  This proxy can perform its function
         without redirecting the tuple.  When media between the destination server and client.
         However, in deployments with private address spaces this proxy
         is
         specified, the recipient may likely to be a different party than the
         originator of combined with the request.  To avoid becoming access proxy.  Anyway, the unwitting
         perpetrator
         functionality of a remote-controlled denial-of-service attack, a
         server MUST perform security checks (see Section 21.1) and
         SHOULD log such attempts before allowing this proxy is usually closely tied into
         understand all aspects of how the client to direct a media stream to transport.

   Auditing Proxy:  RTSP proxies can also provide network owners with a recipient address not chosen by
         logging and audit point for RTSP sessions, e.g. for
         corporations that tracks their employees usage of the server.
         Implementations cannot rely on TCP as reliable means network.
         This type of client
         identification.  If proxy can perform its function without inserting
         itself or any other node in the server does not allow media transport.  This proxy
         type can also accept unknown methods as it doesn't interfere
         with the host address
         part clients requests.

   All type of proxies can be used also when using secured communication
   with TLS as RTSP 2.0 allows the tuple client to approve certificate chains
   used for connection establishment from a proxy, see Section 19.3.2.
   However that trust model may not be set, it SHALL return 463 (Destination
         Prohibited).

         The host address part suitable for all type of
   deployment, and instead secured sessions do by-pass of the tuple MAY proxies.

   Access proxies SHOULD NOT be empty, for example
         ":58044", used in cases when only destination port is desired equipment like NATs and
   firewalls that aren't expected to be
         specified.  Responses regularly maintained, like home
   or small office equipment.  In these cases it is better to request including use the Transport header
         with
   NAT traversal procedures defined for RTSP 2.0
   [I-D.ietf-mmusic-rtsp-nat].  The reason for these recommendations is
   that any extensions of RTSP resulting in new media transport
   protocols or profiles, new parameters etc may fail in a dest_addr parameter SHOULD include the full destination
         address proxy that is actually used by the server.  The server MUST
         NOT remove address information present already
   isn't maintained.  Thus resulting in the request blocking further development of
   RTSP and its usage.

17.1.  Proxies and Protocol Extensions

   The existence of proxies must always be considered when responding unless developing
   new RTSP extensions.  Most type of proxies will need to implement any
   new method to operate correct in the protocol requires it.

   src_addr:  A general source address parameter that can contain one or
         more address specifications.  Each combination presence of Protocol/
         Profile/Lower Transport needs that extension.  New
   headers will be possible to introduce without being blocked by
   proxies not yet updated.  However, it is important to have the format consider if
   this header and
         interpretation of its address specification defined.  For RTP/
         AVP/UDP and RTP/AVP/TCP, the address specification function is a tuple
         containing a host address and port.

         This parameter MUST required to be specified understood by the server if it transmits
         media packets from another address than the one RTSP messages
         are sent to.  This will allow
   proxy or can be forwarded.  If the client header needs to verify source
         address and give it be understood a destination address for its RTCP feedback
         packets if RTP is used.  The address or addresses indicated in
   feature-tag representing the src_addr parameter SHOULD functionality needs to be used both included in
   the Proxy-Require header.  Below are guidelines for sending and
         receiving of analysis if the media streams data packets.
   header needs to be understood.  The main reasons transport header and its
   parameters also shows that headers that are threefold: First, indicating the port extensible and source address(s)
         lets the receiver know where from requires
   correct interpretation in the packets is expected to
         originate.  Secondly, traversal of NATs are greatly simplified
         when traffic is flowing symmetrically over proxy also requires handling rules.

   When defining a NAT binding.
         Thirdly, certain NAT traversal mechanisms, new RTSP header it needs to know to
         which address and port to send so called "binding packets" from
         the receiver be considered if RTSP
   proxies are required to the sender, thus creating a address binding in
         the NAT that the sender understand them to receiver packet flow can use.

               This information may also be available through SDP.
               However, since achieve correct
   functionality.  Determining this is more a feature of transport than
               media initialization, not easy as the authoritative source functionality for this
               information should
   proxies are widely varied as can be in the SETUP response.

   mode: The mode parameter indicates understood from the methods to be supported for above list of
   functionality.  When evaluating this session.  Valid values are PLAY and RECORD.  If not
         provided, one can dived the default is PLAY. functionality
   into three main categories:

   Media modifying:  The RECORD value was defined in
         RFC 2326 caching and is in this specification unspecified but reserved.

   interleaved:  The interleaved parameter implies mixing translator proxies are modifying
      the actual media
         stream with the control stream in whatever protocol is being
         used by the control stream, using the mechanism defined in
         Section 14.  The argument provides the channel number to be
         used in the $ statement and MUST be present.  This parameter
         MAY be specified as a range, e.g., interleaved=4-5 in cases
         where the transport choice for the media stream requires it,
         e.g. for RTP with RTCP.  The channel number given in the therefore needs to understand also request are only a guidance from the client
      directed to the server on
         what channel number(s) to use.  The server MAY set any valid
         channel number in the response.  The declared channel(s) are
         bi-directional, so both end-parties MAY send data on that affects how the given
         channel.  One example of such usage media is rendered.
      Thus this type of proxies needs to also understand the second channel used
         for RTCP, where both server side
      functionality.

   Transport modifying:  The access and client sends RTCP packets on the same channel.

               This allows RTP/RTCP to be handled similarly security proxy both need to
      understand the how the way
               that it transport is done with UDP, i.e., one channel performed, either for RTP and opening
      pinholes or to translate the other for RTCP.

   Multicast-specific:

   ttl:  multicast time-to-live for IPv4.  When included outer headers, e.g.  IP and UDP.

   Non-modifying:  The audit proxy is special in requests the
         value indicate the TTL value that it do not modify
      the client request messages in other ways than to insert the server Via header.  That
      makes it possible for this type to use.  In a response, forward RTSP message that
      contains different type of unknown methods, headers or header
      parameters.

   Based on the value actually being used by above classification one should evaluate if ones
   functionality requires the
         server is returned.  A server will need Transport modifying type of proxies to consider what values
   understand it or not.

18.  Caching

   In HTTP, response-request pairs are cached.  RTSP differs
   significantly in that respect.  Responses are reasonable and also not cacheable, with the authority
   exception of the user to set
         this value.  Corresponding function are presentation description returned by DESCRIBE.
   (Since the responses for anything but DESCRIBE and GET_PARAMETER do
   not needed return any data, caching is not really an issue for IPv6 as
         the scoping these
   requests.)  However, it is part of desirable for the address.

   RTP-specific:

   These parameters are MAY only continuous media data,
   typically delivered out-of-band with respect to RTSP, to be used if cached,
   as well as the session description.

   On receiving a SETUP or PLAY request, a proxy ascertains whether it
   has an up-to-date copy of the continuous media transport protocol content and its
   description.  It can determine whether the copy is RTP.

   ssrc: The ssrc parameter, if included in up-to-date by
   issuing a SETUP response, indicates or DESCRIBE request, respectively, and comparing the RTP SSRC [RFC3550] value(s)
   Last-Modified header with that will be used by of the media
         server for RTP packets within cached copy.  If the stream.  It copy is expressed as
         an eight digit hexadecimal value.

         The ssrc parameter SHALL NOT be specified in requests.  The
         functionality of specifying
   not up-to-date, it modifies the ssrc parameter in a SETUP transport parameters as
   appropriate and forwards the request is deprecated to the origin server.
   Subsequent control commands such as it is incompatible with PLAY or PAUSE then pass the
         specification of RTP in RFC 3550[RFC3550].  If proxy
   unmodified.  The proxy delivers the parameter is
         included in continuous media data to the Transport header of
   client, while possibly making a SETUP request, the server
         MAY ignore it, and choose appropriate SSRCs local copy for the stream. later reuse.  The server MAY set
   exact behavior allowed to the ssrc parameter cache is given by the cache-response
   directives described in Section 16.10.  A cache MUST answer any
   DESCRIBE requests if it is currently serving the Transport header stream to the
   requester, as it is possible that low-level details of the response.

   The parameters defined below MAY only be used if stream
   description may have changed on the media transport
   protocol if origin-server.

   Note that an RTSP cache, unlike the lower-level transport HTTP cache, is connection-oriented (such as
   TCP).  However, these parameters MUST NOT be used when interleaving of the "cut-
   through" variety.  Rather than retrieving the whole resource from the
   origin server, the cache simply copies the streaming data over as it
   passes by on its way to the client.  Thus, it does not introduce
   additional latency.

   To the client, an RTSP control connection.

   setup:  Clients use the setup parameter on proxy cache appears like a regular media
   server, to the Transport line in media origin server like a
         SETUP request, client.  Just as an HTTP
   cache has to indicate store the roles content type, content language, and so on for
   the objects it wishes caches, a media cache has to play in store the presentation
   description.  Typically, a TCP
         connection.  This parameter is adapted cache eliminates all transport-references
   (that is, e.g. multicast information) from [RFC4145].  We
         discuss the use presentation
   description, since these are independent of this parameter in RTP/AVP/TCP non-
         interleaved transport in Appendix C.2.2; the discussion below
         is limited data delivery from
   the cache to syntactic issues.  Clients may specify the
         following values for client.  Information on the setup parameter: ["active":] The
         client will initiate an outgoing connection. ["passive":] The
         client will accept an incoming connection. ["actpass":] The
         client encodings remains the
   same.  If the cache is willing to accept an incoming connection or able to
         initiate an outgoing connection.

         If a client does not specify translate the cached media data, it
   would create a setup value, new presentation description with all the "active" value
         is assumed.

         In encoding
   possibilities it can offer.

18.1.   Validation Model (HTTP)

   When a cache has a stale entry that it would like to use as a
   response to a client SETUP request where the setup parameter
         is set client's request, it first has to "active", check with the origin
   server (or possibly an intermediate cache with a server's 2xx reply MUST assign fresh response) to
   see if its cached entry is still usable.  We call this "validating"
   the setup
         parameter cache entry.  Since we do not want to "passive" on have to pay the Transport header line.

         In overhead of
   retransmitting the full response to a client SETUP request where if the setup parameter cached entry is set good, and we
   do not want to "passive", a server's 2xx reply MUST assign pay the setup
         parameter to "active" on overhead of an extra round trip if the Transport header line.

         In response cached
   entry is invalid, the RTSP protocol supports the use of conditional
   methods.

   The key protocol features for supporting conditional methods are
   those concerned with "cache validators."  When an origin server
   generates a full response, it attaches some sort of validator to it,
   which is kept with the cache entry.  When a client SETUP (user agent or
   proxy cache) makes a conditional request where the setup parameter
         is set to "actpass", for a server's 2xx reply MUST assign resource for which it
   has a cache entry, it includes the setup
         parameter to "active" or "passive" on associated validator in the Transport header
         line.

         Note
   request.

   The server then checks that validator against the "holdconn" value for setup is not defined current validator
   for
         RTSP use, the entity, and, if they match (see Section 18.1.3), it responds
   with a special status code (usually, 304 (Not Modified)) and MUST NOT appear on no
   message body.  Otherwise, it returns a Transport line.

   connection:  Clients use full response (including
   message body).  Thus, we avoid transmitting the setup parameter on full response if the Transport line in
   validator matches, and we avoid an extra round trip if it does not
   match.

   In RTSP, a SETUP request, to indicate the SETUP conditional request prefers the
         reuse of an existing connection between client and server (in
         which case looks exactly the client sets same as a normal
   request for the "connection" parameter to
         "existing"), or same resource, except that it carries a special
   header (which includes the client requires validator) that implicitly turns the creation of
   method (usually DESCRIBE) into a new
         connection between client conditional.

   The protocol includes both positive and server (in which cast the client
         sets the "connection" parameter negative senses of cache-
   validating conditions.  That is, it is possible to "new").  Typically, clients
         use the "new" value for the first SETUP request for either
   that a URL, method be performed if and
         "existing" for subsequent SETUP requests for only if a URL.

         If validator matches or if
   and only if no validators match.

      Note: a client SETUP request assigns the "new" value to
         "connection", the server response MUST also assign that lacks a validator may still be cached, and
      served from cache until it expires, unless this is explicitly
      prohibited by a cache-control directive (see Section 16.10).
      However, a cache cannot do a conditional retrieval if it does not
      have a validator for the "new" entity, which means it will not be
      refreshable after it expires.

18.1.1.  Last-Modified Dates

   The Last-Modified header (Section 16.26) value is often used as a
   cache validator.  In simple terms, a cache entry is considered to "connection" on be
   valid if the Transport line.

         If a client SETUP