draft-ietf-mmusic-rfc2326bis-24.txt   draft-ietf-mmusic-rfc2326bis-25.txt 
MMUSIC Working Group H. Schulzrinne MMUSIC Working Group H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Obsoletes: 2326 (if approved) A. Rao Obsoletes: 2326 (if approved) A. Rao
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: January 3, 2011 R. Lanphier Expires: April 28, 2011 R. Lanphier
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
July 2, 2010 October 25, 2010
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-24 draft-ietf-mmusic-rfc2326bis-25
Abstract Abstract
This memorandum defines RTSP version 2.0 which obsoletes RTSP version This memorandum defines RTSP version 2.0 which obsoletes RTSP version
1.0 which is defined in RFC 2326. 1.0 which is defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-level The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for setup and control of the delivery of data with real-time protocol for setup and control of the delivery of data with real-time
properties. RTSP provides an extensible framework to enable properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and controlled, on-demand delivery of real-time data, such as audio and
skipping to change at page 1, line 48 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 9 skipping to change at page 4, line 9
9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 48 9. Message Body . . . . . . . . . . . . . . . . . . . . . . . . 48
9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 48 9.1. Message-Body Header Fields . . . . . . . . . . . . . . . 48
9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 49 9.2. Message Body . . . . . . . . . . . . . . . . . . . . . . 49
10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 50 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 50
10.1. Reliability and Acknowledgements . . . . . . . . . . . . 50 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 50
10.2. Using Connections . . . . . . . . . . . . . . . . . . . 51 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 51
10.3. Closing Connections . . . . . . . . . . . . . . . . . . 53 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 53
10.4. Timing Out Connections and RTSP Messages . . . . . . . . 54 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 54
10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 55 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 55
10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 56 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 56
11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 57 10.7. Overload Control . . . . . . . . . . . . . . . . . . . . 56
12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 59 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 58
13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 60 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 60
13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 61 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 61
13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 62 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 62
13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 64 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 63
13.3.1. Changing Transport Parameters . . . . . . . . . . . 67 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 65
13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 68 13.3.1. Changing Transport Parameters . . . . . . . . . . . 68
13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 68 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 69
13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 72 13.4.1. General Usage . . . . . . . . . . . . . . . . . . . 69
13.4.3. Updating current PLAY Requests . . . . . . . . . . . 73 13.4.2. Aggregated Sessions . . . . . . . . . . . . . . . . 73
13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 76 13.4.3. Updating current PLAY Requests . . . . . . . . . . . 74
13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 76 13.4.4. Playing On-Demand Media . . . . . . . . . . . . . . 77
13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 76 13.4.5. Playing Dynamic On-Demand Media . . . . . . . . . . 77
13.4.7. Playing Live with Recording . . . . . . . . . . . . 77 13.4.6. Playing Live Media . . . . . . . . . . . . . . . . . 77
13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 78 13.4.7. Playing Live with Recording . . . . . . . . . . . . 78
13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 78 13.4.8. Playing Live with Time-Shift . . . . . . . . . . . . 79
13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 79 13.5. PLAY_NOTIFY . . . . . . . . . . . . . . . . . . . . . . 79
13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 80 13.5.1. End-of-Stream . . . . . . . . . . . . . . . . . . . 80
13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 81 13.5.2. Media-Properties-Update . . . . . . . . . . . . . . 81
13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 83 13.5.3. Scale-Change . . . . . . . . . . . . . . . . . . . . 82
13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 85 13.6. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 84
13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 85 13.7. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 86
13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 86 13.7.1. Client to Server . . . . . . . . . . . . . . . . . . 86
13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 87 13.7.2. Server to Client . . . . . . . . . . . . . . . . . . 87
13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 88 13.8. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 88
13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 90 13.9. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 89
14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 93 13.10. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 91
15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 95 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 94
15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 95 15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 96
15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 95 15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 96
15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 95 15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 96
15.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 95 15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 96
15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 95 15.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 96
15.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 96 15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 96
15.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 96 15.3.1. 301 Moved Permanently . . . . . . . . . . . . . . . 97
15.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 96 15.3.2. 302 Found . . . . . . . . . . . . . . . . . . . . . 97
15.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 96 15.3.3. 303 See Other . . . . . . . . . . . . . . . . . . . 97
15.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 97 15.3.4. 304 Not Modified . . . . . . . . . . . . . . . . . . 97
15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 97 15.3.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 98
15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 97 15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 98
15.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 97 15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 98
15.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 98 15.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . 98
15.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 98 15.4.3. 402 Payment Required . . . . . . . . . . . . . . . . 99
15.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 98 15.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . 99
15.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 98 15.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . 99
15.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 98 15.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . 99
15.4.8. 407 Proxy Authentication Required . . . . . . . . . 99 15.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . 99
15.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 99 15.4.8. 407 Proxy Authentication Required . . . . . . . . . 100
15.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 99 15.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . 100
15.4.11. 411 Length Required . . . . . . . . . . . . . . . . 99 15.4.10. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 100
15.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 100 15.4.11. 411 Length Required . . . . . . . . . . . . . . . . 100
15.4.13. 413 Request Message Body Too Large . . . . . . . . . 100 15.4.12. 412 Precondition Failed . . . . . . . . . . . . . . 101
15.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 100 15.4.13. 413 Request Message Body Too Large . . . . . . . . . 101
15.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 100 15.4.14. 414 Request-URI Too Long . . . . . . . . . . . . . . 101
15.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 100 15.4.15. 415 Unsupported Media Type . . . . . . . . . . . . . 101
15.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 100 15.4.16. 451 Parameter Not Understood . . . . . . . . . . . . 101
15.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 101 15.4.17. 452 reserved . . . . . . . . . . . . . . . . . . . . 101
15.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 101 15.4.18. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 102
15.4.20. 455 Method Not Valid in This State . . . . . . . . . 101 15.4.19. 454 Session Not Found . . . . . . . . . . . . . . . 102
15.4.21. 456 Header Field Not Valid for Resource . . . . . . 101 15.4.20. 455 Method Not Valid in This State . . . . . . . . . 102
15.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 101 15.4.21. 456 Header Field Not Valid for Resource . . . . . . 102
15.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 101 15.4.22. 457 Invalid Range . . . . . . . . . . . . . . . . . 102
15.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 101 15.4.23. 458 Parameter Is Read-Only . . . . . . . . . . . . . 102
15.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 101 15.4.24. 459 Aggregate Operation Not Allowed . . . . . . . . 102
15.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 102 15.4.25. 460 Only Aggregate Operation Allowed . . . . . . . . 102
15.4.27. 462 Destination Unreachable . . . . . . . . . . . . 102 15.4.26. 461 Unsupported Transport . . . . . . . . . . . . . 103
15.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 102 15.4.27. 462 Destination Unreachable . . . . . . . . . . . . 103
15.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 102 15.4.28. 463 Destination Prohibited . . . . . . . . . . . . . 103
15.4.30. 465 Notification Reason Unknown . . . . . . . . . . 102 15.4.29. 464 Data Transport Not Ready Yet . . . . . . . . . . 103
15.4.31. 470 Connection Authorization Required . . . . . . . 102 15.4.30. 465 Notification Reason Unknown . . . . . . . . . . 103
15.4.32. 471 Connection Credentials not accepted . . . . . . 103 15.4.31. 466 Key Management Error . . . . . . . . . . . . . . 103
15.4.33. 472 Failure to establish secure connection . . . . . 103 15.4.32. 470 Connection Authorization Required . . . . . . . 104
15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 103 15.4.33. 471 Connection Credentials not accepted . . . . . . 104
15.5.1. 500 Internal Server Error . . . . . . . . . . . . . 103 15.4.34. 472 Failure to establish secure connection . . . . . 104
15.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 103 15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 104
15.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 103 15.5.1. 500 Internal Server Error . . . . . . . . . . . . . 104
15.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 103 15.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . 104
15.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 104 15.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . 104
15.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 104 15.5.4. 503 Service Unavailable . . . . . . . . . . . . . . 105
15.5.7. 551 Option not supported . . . . . . . . . . . . . . 104 15.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . 105
16. Header Field Definitions . . . . . . . . . . . . . . . . . . 105 15.5.6. 505 RTSP Version Not Supported . . . . . . . . . . . 105
16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 115 15.5.7. 551 Option not supported . . . . . . . . . . . . . . 105
16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 115 16. Header Field Definitions . . . . . . . . . . . . . . . . . . 106
16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 116 16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 116
16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 117 16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 116
16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 118 16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 117
16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 118 16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 118
16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 118 16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 119
16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 119 16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 119
16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 119 16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 119
16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 120 16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 120
16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 122 16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 121
16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 123 16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 121
16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 124 16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 123
16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 124 16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 124
16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 125 16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 125
16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 125 16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 125
16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 126 16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 126
16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 126 16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 127
16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 126 16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 127
16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 127 16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 128
16.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 128 16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 128
16.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 129 16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 129
16.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 129 16.21. Expires . . . . . . . . . . . . . . . . . . . . . . . . 130
16.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 130 16.22. From . . . . . . . . . . . . . . . . . . . . . . . . . . 130
16.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 130 16.23. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 131
16.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 131 16.24. If-Modified-Since . . . . . . . . . . . . . . . . . . . 131
16.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 131 16.25. If-None-Match . . . . . . . . . . . . . . . . . . . . . 132
16.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 132 16.26. Last-Modified . . . . . . . . . . . . . . . . . . . . . 132
16.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 134 16.27. Location . . . . . . . . . . . . . . . . . . . . . . . . 133
16.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 134 16.28. Media-Properties . . . . . . . . . . . . . . . . . . . . 133
16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 135 16.29. Media-Range . . . . . . . . . . . . . . . . . . . . . . 135
16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 135 16.30. MTag . . . . . . . . . . . . . . . . . . . . . . . . . . 136
16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 136 16.31. Notify-Reason . . . . . . . . . . . . . . . . . . . . . 136
16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 136 16.32. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 136
16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 136 16.33. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 137
16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 137 16.34. Proxy-Authorization . . . . . . . . . . . . . . . . . . 138
16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 138 16.35. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 138
16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 139 16.36. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 139
16.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 140 16.37. Public . . . . . . . . . . . . . . . . . . . . . . . . . 139
16.40. Request-Status . . . . . . . . . . . . . . . . . . . . . 141 16.38. Range . . . . . . . . . . . . . . . . . . . . . . . . . 140
16.41. Require . . . . . . . . . . . . . . . . . . . . . . . . 141 16.39. Referrer . . . . . . . . . . . . . . . . . . . . . . . . 142
16.42. Retry-After . . . . . . . . . . . . . . . . . . . . . . 142 16.40. Request-Status . . . . . . . . . . . . . . . . . . . . . 142
16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 143 16.41. Require . . . . . . . . . . . . . . . . . . . . . . . . 143
16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 145 16.42. Retry-After . . . . . . . . . . . . . . . . . . . . . . 144
16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 146 16.43. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 144
16.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 148 16.44. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 146
16.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 148 16.45. Seek-Style . . . . . . . . . . . . . . . . . . . . . . . 147
16.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 149 16.46. Server . . . . . . . . . . . . . . . . . . . . . . . . . 149
16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 150 16.47. Session . . . . . . . . . . . . . . . . . . . . . . . . 149
16.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 150 16.48. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 150
16.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 151 16.49. Supported . . . . . . . . . . . . . . . . . . . . . . . 151
16.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 151 16.50. Terminate-Reason . . . . . . . . . . . . . . . . . . . . 152
16.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 158 16.51. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 152
16.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 158 16.52. Transport . . . . . . . . . . . . . . . . . . . . . . . 153
16.55. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 159 16.53. Unsupported . . . . . . . . . . . . . . . . . . . . . . 160
16.56. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 160 16.54. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 160
16.57. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 160 16.55. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 160
16.56. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 161
17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 16.57. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 162
17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 162 17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
17.2. Multiplexing and Demultiplexing of Messages . . . . . . 163 17.1. Proxies and Protocol Extensions . . . . . . . . . . . . 164
18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 17.2. Multiplexing and Demultiplexing of Messages . . . . . . 165
18.1. Validation Model . . . . . . . . . . . . . . . . . . . . 164 18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
18.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 166 18.1. Validation Model . . . . . . . . . . . . . . . . . . . . 166
18.1.2. Message Body Tag Cache Validators . . . . . . . . . 166 18.1.1. Last-Modified Dates . . . . . . . . . . . . . . . . 168
18.1.3. Weak and Strong Validators . . . . . . . . . . . . . 166 18.1.2. Message Body Tag Cache Validators . . . . . . . . . 168
18.1.3. Weak and Strong Validators . . . . . . . . . . . . . 168
18.1.4. Rules for When to Use Message Body Tags and 18.1.4. Rules for When to Use Message Body Tags and
Last-Modified Dates . . . . . . . . . . . . . . . . 168 Last-Modified Dates . . . . . . . . . . . . . . . . 170
18.1.5. Non-validating Conditionals . . . . . . . . . . . . 170 18.1.5. Non-validating Conditionals . . . . . . . . . . . . 172
18.2. Invalidation After Updates or Deletions . . . . . . . . 170 18.2. Invalidation After Updates or Deletions . . . . . . . . 172
19. Security Framework . . . . . . . . . . . . . . . . . . . . . 172 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 174
19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 172 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 174
19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 172 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 174
19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 173 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 175
19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 174 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 176
19.3.2. User approved TLS procedure . . . . . . . . . . . . 175 19.3.2. User approved TLS procedure . . . . . . . . . . . . 177
20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 178 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 180
20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 180 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 182
20.2.1. Generic Protocol elements . . . . . . . . . . . . . 180 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 182
20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 183 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 185
20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 187 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 189
20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 196 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 198
21. Security Considerations . . . . . . . . . . . . . . . . . . . 197 21. Security Considerations . . . . . . . . . . . . . . . . . . . 199
21.1. Remote denial of Service Attack . . . . . . . . . . . . 199 21.1. Remote denial of Service Attack . . . . . . . . . . . . 201
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 201 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 203
22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 201 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 203
22.1.1. Description . . . . . . . . . . . . . . . . . . . . 201 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 203
22.1.2. Registering New Feature-tags with IANA . . . . . . . 202 22.1.2. Registering New Feature-tags with IANA . . . . . . . 204
22.1.3. Registered entries . . . . . . . . . . . . . . . . . 202 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 204
22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 202 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 204
22.2.1. Description . . . . . . . . . . . . . . . . . . . . 202 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 204
22.2.2. Registering New Methods with IANA . . . . . . . . . 203 22.2.2. Registering New Methods with IANA . . . . . . . . . 205
22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 203 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 205
22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 203 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 205
22.3.1. Description . . . . . . . . . . . . . . . . . . . . 203 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 205
22.3.2. Registering New Status Codes with IANA . . . . . . . 204 22.3.2. Registering New Status Codes with IANA . . . . . . . 206
22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 204 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 206
22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 204 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 206
22.4.1. Description . . . . . . . . . . . . . . . . . . . . 204 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 206
22.4.2. Registering New Headers with IANA . . . . . . . . . 204 22.4.2. Registering New Headers with IANA . . . . . . . . . 206
22.4.3. Registered entries . . . . . . . . . . . . . . . . . 205 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 207
22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 205 22.5. Accept-Credentials . . . . . . . . . . . . . . . . . . . 207
22.5.1. Accept-Credentials policies . . . . . . . . . . . . 205 22.5.1. Accept-Credentials policies . . . . . . . . . . . . 207
22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 206 22.5.2. Accept-Credentials hash algorithms . . . . . . . . . 208
22.6. Cache-Control Cache Directive Extensions . . . . . . . . 206 22.6. Cache-Control Cache Directive Extensions . . . . . . . . 208
22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 207 22.7. Media Properties . . . . . . . . . . . . . . . . . . . . 209
22.7.1. Description . . . . . . . . . . . . . . . . . . . . 207 22.7.1. Description . . . . . . . . . . . . . . . . . . . . 209
22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 207 22.7.2. Registration Rules . . . . . . . . . . . . . . . . . 209
22.7.3. Registered Values . . . . . . . . . . . . . . . . . 208 22.7.3. Registered Values . . . . . . . . . . . . . . . . . 210
22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 208 22.8. Notify-Reason header . . . . . . . . . . . . . . . . . . 210
22.8.1. Description . . . . . . . . . . . . . . . . . . . . 208 22.8.1. Description . . . . . . . . . . . . . . . . . . . . 210
22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 208 22.8.2. Registration Rules . . . . . . . . . . . . . . . . . 210
22.8.3. Registered Values . . . . . . . . . . . . . . . . . 209 22.8.3. Registered Values . . . . . . . . . . . . . . . . . 211
22.9. Range header formats . . . . . . . . . . . . . . . . . . 209 22.9. Range header formats . . . . . . . . . . . . . . . . . . 211
22.9.1. Description . . . . . . . . . . . . . . . . . . . . 209 22.9.1. Description . . . . . . . . . . . . . . . . . . . . 211
22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 209 22.9.2. Registration Rules . . . . . . . . . . . . . . . . . 211
22.9.3. Registered Values . . . . . . . . . . . . . . . . . 209 22.9.3. Registered Values . . . . . . . . . . . . . . . . . 211
22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 210 22.10. Terminate-Reason Header . . . . . . . . . . . . . . . . 212
22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 210 22.10.1. Redirect Reasons . . . . . . . . . . . . . . . . . . 212
22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 210 22.10.2. Terminate-Reason Header Parameters . . . . . . . . . 212
22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 210 22.11. RTP-Info header parameters . . . . . . . . . . . . . . . 212
22.11.1. Description . . . . . . . . . . . . . . . . . . . . 210 22.11.1. Description . . . . . . . . . . . . . . . . . . . . 212
22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 211 22.11.2. Registration Rules . . . . . . . . . . . . . . . . . 213
22.11.3. Registered Values . . . . . . . . . . . . . . . . . 211 22.11.3. Registered Values . . . . . . . . . . . . . . . . . 213
22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 211 22.12. Seek-Style Policies . . . . . . . . . . . . . . . . . . 213
22.12.1. Description . . . . . . . . . . . . . . . . . . . . 211 22.12.1. Description . . . . . . . . . . . . . . . . . . . . 213
22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 211 22.12.2. Registration Rules . . . . . . . . . . . . . . . . . 213
22.12.3. Registered Values . . . . . . . . . . . . . . . . . 212 22.12.3. Registered Values . . . . . . . . . . . . . . . . . 214
22.13. Transport Header Registries . . . . . . . . . . . . . . 212 22.13. Transport Header Registries . . . . . . . . . . . . . . 214
22.13.1. Transport Protocol Specification . . . . . . . . . . 212 22.13.1. Transport Protocol Specification . . . . . . . . . . 214
22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 213 22.13.2. Transport modes . . . . . . . . . . . . . . . . . . 215
22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 214 22.13.3. Transport Parameters . . . . . . . . . . . . . . . . 216
22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 214 22.14. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 216
22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 214 22.14.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 216
22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 215 22.14.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 217
22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 216 22.14.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 218
22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 217 22.15. SDP attributes . . . . . . . . . . . . . . . . . . . . . 219
22.16. Media Type Registration for text/parameters . . . . . . 218 22.16. Media Type Registration for text/parameters . . . . . . 220
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 220 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 222
23.1. Normative References . . . . . . . . . . . . . . . . . . 220 23.1. Normative References . . . . . . . . . . . . . . . . . . 222
23.2. Informative References . . . . . . . . . . . . . . . . . 222 23.2. Informative References . . . . . . . . . . . . . . . . . 224
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 225 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 227
A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 225 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 227
A.2. Media on Demand using Pipelining . . . . . . . . . . . . 229 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 231
A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 231 A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 233
A.4. Single Stream Container Files . . . . . . . . . . . . . 235 A.4. Single Stream Container Files . . . . . . . . . . . . . 237
A.5. Live Media Presentation Using Multicast . . . . . . . . 237 A.5. Live Media Presentation Using Multicast . . . . . . . . 239
A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 238 A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 240
Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 240 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 242
B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 240 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 242
B.2. State variables . . . . . . . . . . . . . . . . . . . . 240 B.2. State variables . . . . . . . . . . . . . . . . . . . . 242
B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 240 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 242
B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 241 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 243
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 249
Appendix C. Media Transport Alternatives . . . . . . . . . . . . 247 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 249
C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 247 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 249
C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 247 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 249
C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 247 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 250
C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 248 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 251
C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 249 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 253
C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 249 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 253
C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 249 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 255
C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 250 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 255
C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 251 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 255
C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 251 C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 259
C.3. Handling Media Clock Time Jumps in the RTP Media Layer . 255 C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 263
C.4. Handling RTP Timestamps after PAUSE . . . . . . . . . . 259 C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 265
C.5. RTSP / RTP Integration . . . . . . . . . . . . . . . . . 261 C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 265
C.6. Scaling with RTP . . . . . . . . . . . . . . . . . . . . 261 C.7. Maintaining NPT synchronization with RTP timestamps . . 265
C.7. Maintaining NPT synchronization with RTP timestamps . . 261 C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 265
C.8. Continuous Audio . . . . . . . . . . . . . . . . . . . . 261 C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 265
C.9. Multiple Sources in an RTP Session . . . . . . . . . . . 261
C.10. Usage of SSRCs and the RTCP BYE Message During an C.10. Usage of SSRCs and the RTCP BYE Message During an
RTSP Session . . . . . . . . . . . . . . . . . . . . . . 261 RTSP Session . . . . . . . . . . . . . . . . . . . . . . 265
C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 262 C.11. Future Additions . . . . . . . . . . . . . . . . . . . . 266
Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 263 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 267
D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 263 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 267
D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 263 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 267
D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 264 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 268
D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 265 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 269
D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 265 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 269
D.1.5. Directionality of media stream . . . . . . . . . . . 265 D.1.5. Directionality of media stream . . . . . . . . . . . 269
D.1.6. Range of Presentation . . . . . . . . . . . . . . . 266 D.1.6. Range of Presentation . . . . . . . . . . . . . . . 270
D.1.7. Time of Availability . . . . . . . . . . . . . . . . 267 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 271
D.1.8. Connection Information . . . . . . . . . . . . . . . 267 D.1.8. Connection Information . . . . . . . . . . . . . . . 271
D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 267 D.1.9. Message Body Tag . . . . . . . . . . . . . . . . . . 271
D.2. Aggregate Control Not Available . . . . . . . . . . . . 268 D.2. Aggregate Control Not Available . . . . . . . . . . . . 272
D.3. Aggregate Control Available . . . . . . . . . . . . . . 268 D.3. Aggregate Control Available . . . . . . . . . . . . . . 272
D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 269 D.4. Grouping of Media Lines in SDP . . . . . . . . . . . . . 273
D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 270 D.5. RTSP external SDP delivery . . . . . . . . . . . . . . . 274
Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 271 Appendix E. RTSP Use Cases . . . . . . . . . . . . . . . . . . . 275
E.1. On-demand Playback of Stored Content . . . . . . . . . . 271 E.1. On-demand Playback of Stored Content . . . . . . . . . . 275
E.2. Unicast Distribution of Live Content . . . . . . . . . . 272 E.2. Unicast Distribution of Live Content . . . . . . . . . . 276
E.3. On-demand Playback using Multicast . . . . . . . . . . . 273 E.3. On-demand Playback using Multicast . . . . . . . . . . . 277
E.4. Inviting an RTSP server into a conference . . . . . . . 273 E.4. Inviting an RTSP server into a conference . . . . . . . 277
E.5. Live Content using Multicast . . . . . . . . . . . . . . 274 E.5. Live Content using Multicast . . . . . . . . . . . . . . 278
Appendix F. Text format for Parameters . . . . . . . . . . . . . 276 Appendix F. Text format for Parameters . . . . . . . . . . . . . 280
Appendix G. Requirements for Unreliable Transport of RTSP . . . 277 Appendix G. Requirements for Unreliable Transport of RTSP . . . 281
Appendix H. Backwards Compatibility Considerations . . . . . . . 279 Appendix H. Backwards Compatibility Considerations . . . . . . . 283
H.1. Play Request in Play State . . . . . . . . . . . . . . . 279 H.1. Play Request in Play State . . . . . . . . . . . . . . . 283
H.2. Using Persistent Connections . . . . . . . . . . . . . . 279 H.2. Using Persistent Connections . . . . . . . . . . . . . . 283
Appendix I. Open Issues . . . . . . . . . . . . . . . . . . . . 280 Appendix I. Open Issues . . . . . . . . . . . . . . . . . . . . 284
Appendix J. Changes . . . . . . . . . . . . . . . . . . . . . . 281 Appendix J. Changes . . . . . . . . . . . . . . . . . . . . . . 285
J.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 281 J.1. Brief Overview . . . . . . . . . . . . . . . . . . . . . 285
J.2. Detailed List of Changes . . . . . . . . . . . . . . . . 282 J.2. Detailed List of Changes . . . . . . . . . . . . . . . . 286
Appendix K. Acknowledgements . . . . . . . . . . . . . . . . . . 289 Appendix K. Acknowledgements . . . . . . . . . . . . . . . . . . 293
K.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 289 K.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 293
Appendix L. RFC Editor Consideration . . . . . . . . . . . . . . 291 Appendix L. RFC Editor Consideration . . . . . . . . . . . . . . 295
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 292 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 296
1. Introduction 1. Introduction
This memo defines version 2.0 of the Real Time Streaming Protocol This memo defines version 2.0 of the Real Time Streaming Protocol
(RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and (RTSP 2.0). RTSP 2.0 is an application-level protocol for setup and
control over the delivery of data with real-time properties, control over the delivery of data with real-time properties,
typically streaming media. Streaming media is, for instance, video typically streaming media. Streaming media is, for instance, video
on demand or audio live streaming. Put simply, RTSP acts as a on demand or audio live streaming. Put simply, RTSP acts as a
"network remote control" for multimedia servers, similar to the "network remote control" for multimedia servers, similar to the
remote control for a DVD player. remote control for a DVD player.
skipping to change at page 18, line 19 skipping to change at page 18, line 19
provides a mapping between RTP timestamps and the content time scale. provides a mapping between RTP timestamps and the content time scale.
When the server want to notify the client about the completion of the When the server want to notify the client about the completion of the
media delivery, it sends a PLAY_NOTIFY request to the client. The media delivery, it sends a PLAY_NOTIFY request to the client. The
PLAY_NOTIFY request includes information about the stream end, PLAY_NOTIFY request includes information about the stream end,
including the last RTP sequence number for each stream, thus enabling including the last RTP sequence number for each stream, thus enabling
the client to empty the buffer smoothly. the client to empty the buffer smoothly.
2.5.1. Media Delivery Manipulations 2.5.1. Media Delivery Manipulations
The basic playback functionality of RTSP enables delivery of a range The basic playback functionality of RTSP enables delivery of a range
of requested content to the client at the pace intended by the the of requested content to the client at the pace intended by the
content's creator. However, RTSP can also manipulate the delivery to content's creator. However, RTSP can also manipulate the delivery to
the client in two ways. the client in two ways.
Scale: The ratio of media content time delivered per unit playback Scale: The ratio of media content time delivered per unit playback
time. time.
Speed: The ratio of playback time delivered per unit of wallclock Speed: The ratio of playback time delivered per unit of wallclock
time. time.
Both affect the media delivery per time unit. However, they Both affect the media delivery per time unit. However, they
skipping to change at page 22, line 12 skipping to change at page 22, line 12
method (Section 13.1) and the Supported header (Section 16.49). It method (Section 13.1) and the Supported header (Section 16.49). It
can also try and possibly fail using new methods, or require that can also try and possibly fail using new methods, or require that
particular features are supported using the Require or Proxy-Require particular features are supported using the Require or Proxy-Require
header. header.
The RTSP protocol in itself can be extended in three ways, listed The RTSP protocol in itself can be extended in three ways, listed
here in order of the magnitude of changes supported: here in order of the magnitude of changes supported:
o Existing methods can be extended with new parameters, for example, o Existing methods can be extended with new parameters, for example,
headers, as long as these parameters can be safely ignored by the headers, as long as these parameters can be safely ignored by the
recipient. If the client needs negative acknowledgement when a recipient. If the client needs negative acknowledgment when a
method extension is not supported, a tag corresponding to the method extension is not supported, a tag corresponding to the
extension may be added in the field of the Require or Proxy- extension may be added in the field of the Require or Proxy-
Require headers (see Section 16.35). Require headers (see Section 16.35).
o New methods can be added. If the recipient of the message does o New methods can be added. If the recipient of the message does
not understand the request, it must respond with error code 501 not understand the request, it must respond with error code 501
(Not Implemented) so that the sender can avoid using this method (Not Implemented) so that the sender can avoid using this method
again. A client may also use the OPTIONS method to inquire about again. A client may also use the OPTIONS method to inquire about
methods supported by the server. The server must list the methods methods supported by the server. The server must list the methods
it supports using the Public response header. it supports using the Public response header.
skipping to change at page 27, line 38 skipping to change at page 27, line 38
lower version than RTSP/2.13, which in turn is lower than RTSP/12.3. lower version than RTSP/2.13, which in turn is lower than RTSP/12.3.
Leading zeros MUST be ignored by recipients and MUST NOT be sent. Leading zeros MUST be ignored by recipients and MUST NOT be sent.
4.2. RTSP IRI and URI 4.2. RTSP IRI and URI
RTSP 2.0 defines and registers three URI schemes "rtsp", "rtsps" and 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, "rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0,
and is defined here to register and reserve the URI scheme that is and is defined here to register and reserve the URI scheme that is
defined in RTSP 1.0. The "rtspu" scheme indicates unspecified defined in RTSP 1.0. The "rtspu" scheme indicates unspecified
transport of the RTSP messages over unreliable transport (UDP in RTSP transport of the RTSP messages over unreliable transport (UDP in RTSP
1.0). A RTSP server MUST response with with an error code indicating 1.0). A RTSP server MUST response with an error code indicating the
the "rtspu" scheme is not implemented (501) to a request that carries "rtspu" scheme is not implemented (501) to a request that carries a
a "rtspu" URI scheme. The details of the syntax of "rtsp" and "rtspu" URI scheme. The details of the syntax of "rtsp" and "rtsps"
"rtsps" URIs has been changed from RTSP 1.0. URIs has been changed from RTSP 1.0.
This specification also defines the format of the RTSP IRI [RFC3987] This specification also defines the format of the RTSP IRI [RFC3987]
that can be used as RTSP resource identifiers and locators, in web that can be used as RTSP resource identifiers and locators, in web
pages, user interfaces, on paper, etc. However, the RTSP request pages, user interfaces, on paper, etc. However, the RTSP request
message format only allows usage of the absolute URI format. The message format only allows usage of the absolute URI format. The
RTSP IRI format MUST use the rules and transformation for IRIs RTSP IRI format MUST use the rules and transformation for IRIs
defined in [RFC3987]. This way RTSP 2.0 URIs for request can be defined in [RFC3987]. This way RTSP 2.0 URIs for request can be
produced from an RTSP IRI. produced from an RTSP IRI.
The RTSP IRI and URI are both syntax restricted compared to the The RTSP IRI and URI are both syntax restricted compared to the
skipping to change at page 30, line 23 skipping to change at page 30, line 23
smpte=10:12:33:20- smpte=10:12:33:20-
smpte=10:07:33- smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01 smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01 smpte-25=10:07:00-10:07:33:05.01
4.5. Normal Play Time 4.5. Normal Play Time
Normal play time (NPT) indicates the stream absolute position Normal play time (NPT) indicates the stream absolute position
relative to the beginning of the presentation, not to be confused relative to the beginning of the presentation, not to be confused
with the Network Time Protocol (NTP) [RFC1305]. The timestamp with the Network Time Protocol (NTP) [RFC5905]. The timestamp
consists of two parts: the mandatory first part may be expressed in consists of two parts: the mandatory first part may be expressed in
either seconds or hours, minutes, and seconds. The optional second either seconds or hours, minutes, and seconds. The optional second
part consists of a decimal point and decimal figures and indicates part consists of a decimal point and decimal figures and indicates
fractions of a second. fractions of a second.
The beginning of a presentation corresponds to 0.0 seconds. Negative The beginning of a presentation corresponds to 0.0 seconds. Negative
values are not defined. values are not defined.
The special constant "now" is defined as the current instant of a The special constant "now" is defined as the current instant of a
live event. It MAY only be used for live events, and MUST NOT be live event. It MAY only be used for live events, and MUST NOT be
skipping to change at page 34, line 26 skipping to change at page 34, line 26
Time Progressing: As times progresses new content will become Time Progressing: As times progresses new content will become
available. If the content also is retained it will become longer available. If the content also is retained it will become longer
as everything between the start point and the point currently as everything between the start point and the point currently
being made available can be accessed. If the media server uses a being made available can be accessed. If the media server uses a
sliding window policy for retention, the start point will also sliding window policy for retention, the start point will also
change as time progresses. change as time progresses.
4.9.4. Supported Scale Factors 4.9.4. Supported Scale Factors
Content often suppports only a limited set or range of scales when Content often supports only a limited set or range of scales when
delivering the media.. To enable the client to know what values or delivering the media.. To enable the client to know what values or
ranges of scale operations that the whole content or the current ranges of scale operations that the whole content or the current
position supports, a media properties attribute for this is defined position supports, a media properties attribute for this is defined
which contains a list with the values and/or ranges that are which contains a list with the values and/or ranges that are
supported. The attribute is named "Scales". It may be updated at supported. The attribute is named "Scales". It may be updated at
any point in the content due to content consisting of spliced pieces any point in the content due to content consisting of spliced pieces
or content being dynamically updated by out-of-band mechanisms. or content being dynamically updated by out-of-band mechanisms.
4.9.5. Mapping to the Attributes 4.9.5. Mapping to the Attributes
This section shows exemaples of how one would map the above usages to This section shows examples of how one would map the above usages to
the properties and their values. the properties and their values.
On-demand: Random Access: Random Access=5s, Content Modifications: On-demand: Random Access: Random Access=5s, Content Modifications:
Immutable, Retention: unlimited or time limited. Immutable, Retention: unlimited or time limited.
Dynamic On-demand: Random Access: Random Access=3s, Content Dynamic On-demand: Random Access: Random Access=3s, Content
Modifications: Dynamic, Retention: unlimited or time limited. Modifications: Dynamic, Retention: unlimited or time limited.
Live: Random Access: No seeking, Content Modifications: Time Live: Random Access: No seeking, Content Modifications: Time
Progressing, Retention: Duration limited=0.0s Progressing, Retention: Duration limited=0.0s
skipping to change at page 50, line 42 skipping to change at page 50, line 42
It is also useful in proxies for keeping track of the different It is also useful in proxies for keeping track of the different
requests when aggregating several client requests on a single TCP requests when aggregating several client requests on a single TCP
connection. connection.
10.1. Reliability and Acknowledgements 10.1. Reliability and Acknowledgements
Since RTSP messages are transmitted using reliable transport Since RTSP messages are transmitted using reliable transport
protocols, they MUST NOT be retransmitted at the RTSP protocol level. protocols, they MUST NOT be retransmitted at the RTSP protocol level.
Instead, the implementation must rely on the underlying transport to Instead, the implementation must rely on the underlying transport to
provide reliability. The RTSP implementation may use any indication provide reliability. The RTSP implementation may use any indication
of reception acknowledgement of the message from the underlying of reception acknowledgment of the message from the underlying
transport protocols to optimize the RTSP behavior. transport protocols to optimize the RTSP behavior.
If both the underlying reliable transport such as TCP and the RTSP If both the underlying reliable transport such as TCP and the RTSP
application retransmit requests, each packet loss or message loss application retransmit requests, each packet loss or message loss
may result in two retransmissions. The receiver typically cannot may result in two retransmissions. The receiver typically cannot
take advantage of the application-layer retransmission since the take advantage of the application-layer retransmission since the
transport stack will not deliver the application-layer transport stack will not deliver the application-layer
retransmission before the first attempt has reached the receiver. retransmission before the first attempt has reached the receiver.
If the packet loss is caused by congestion, multiple If the packet loss is caused by congestion, multiple
retransmissions at different layers will exacerbate the retransmissions at different layers will exacerbate the
congestion. congestion.
Lack of acknowledgement of an RTSP request should be handled within Lack of acknowledgment of an RTSP request should be handled within
the constraints of the connection timeout considerations described the constraints of the connection timeout considerations described
below (Section 10.4). below (Section 10.4).
10.2. Using Connections 10.2. Using Connections
A TCP transport can be used for both persistent connections (for A TCP transport can be used for both persistent connections (for
several message exchanges) and transient connections (for a single several message exchanges) and transient connections (for a single
message exchange). Implementations of this specification MUST message exchange). Implementations of this specification MUST
support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) support RTSP over TCP. The scheme of the RTSP URI (Section 4.2)
indicates the default port that the server will listen on if the port indicates the default port that the server will listen on if the port
skipping to change at page 53, line 45 skipping to change at page 53, line 45
of a server with respect to content or other factors. In such of a server with respect to content or other factors. In such
cases, it is inefficient for the server to close a connection on cases, it is inefficient for the server to close a connection on
an error response. Also, such behavior would prevent an error response. Also, such behavior would prevent
implementation of advanced/special types of requests or result in implementation of advanced/special types of requests or result in
extra overhead for the client when testing for new features. On extra overhead for the client when testing for new features. On
the flip side, keeping connections open after sending an error the flip side, keeping connections open after sending an error
response poses a Denial of Service security risk (Section 21). response poses a Denial of Service security risk (Section 21).
The server MAY close a connection if he receives an incomplete The server MAY close a connection if he receives an incomplete
message and if the message is not completed within a reasonable message and if the message is not completed within a reasonable
amount of time. It is RECOMMENDED that the server waits at least 1 amount of time. It is RECOMMENDED that the server waits at least 10
second for the completion of a message or for the next part of the second for the completion of a message or for the next part of the
message to arrive (which is an indication that the transport and the message to arrive (which is an indication that the transport and the
client are still alive). client are still alive). Servers believing they are under attack or
otherwise starved for resources during that event consider using a
shorter timeout.
If a server closes a connection while the client is attempting to If a server closes a connection while the client is attempting to
send a new request, the client will have to close its current send a new request, the client will have to close its current
connection, establish a new connection and send its request over the connection, establish a new connection and send its request over the
new connection. new connection.
An RTSP message should not be terminated by closing the connection. An RTSP message should not be terminated by closing the connection.
Such a message MAY be considered to be incomplete by the receiver and Such a message MAY be considered to be incomplete by the receiver and
discarded. An RTSP message is properly terminated as defined in discarded. An RTSP message is properly terminated as defined in
Section 5. Section 5.
skipping to change at page 57, line 5 skipping to change at page 56, line 14
activity (see Appendix B). The timeout is measured in seconds, with activity (see Appendix B). The timeout is measured in seconds, with
a default of 60 seconds. The length of the session timeout MUST NOT a default of 60 seconds. The length of the session timeout MUST NOT
be changed in an established session. be changed in an established session.
10.6. Use of IPv6 10.6. Use of IPv6
Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP
2.0 has been updated for explicit IPv6 support. Implementations of 2.0 has been updated for explicit IPv6 support. Implementations of
RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers. RTSP 2.0 MUST understand literal IPv6 addresses in URIs and headers.
10.7. Overload Control
Overload in RTSP can occur when server and proxies have insufficient
resources to complete the processing of a request. An improper
handling of such an overload situation at proxies and servers can
impact the operation of the RTSP deployment, probably worsen the
situation. RTSP defines the 503 (Service Unavailable) response
(Section Section 15.5.4) to let servers and proxies notify requesting
proxies and RTSP clients about an overload situation. In conjunction
with the Retry-After header (Section Section 16.42) the server or
proxy can indicate the time after the requesting entity can send
another request to the proxy or server.
Simply implementing and using the 503 (Service Unavailable) is not
sufficient enough for properly handling overload situations. For
instance, a simplistic approach would be to send the 503 response
with a Retry-After header set to a fixed value. However, this can
cause the situation where multiple RTSP clients again send requests
to a proxy or server at roughly the same time which may again cause
an overload situation, or if the "old" overload situation is not yet
solved, i.e., the length indicated in the Retry-After header was too
short.
An RTSP server or proxy in an overload situation must select the
value of the Retry-After header carefully and in dependency of its
current load situation. It is RECOMMENDED to increase the length
proportional with the current load of the server, i.e., an increasing
workload should result in an increased length of the indicated
unavailability. It is RECOMMENDED to not send the same value in the
Retry-After header to all requesting proxies and clients, but to add
a variation the mean value of the Retry-After header.
Another issue are load balancing RTSP proxies, i.e., where an RTSP
proxy is used to select amongst a set of RTSP servers to handled the
requests, or when multiple server addresses are available for a given
server name. The proxy or client may receive a 503 (Service
Unavailable) from one of its RTSP servers or a TCP timeout (if the
server is even unable to handled the request message). The proxy or
client simply retries the other addresses, but may also receive a 503
(Service Unavailable) response or TCP timeouts from those addresses.
In such a situation, where none of the RTSP servers/addresses can
handled the request, the RTSP agent has to wait before it can send
any new requests to the RTSP server. Any additional request to a
specific address MUST be delayed according to the Retry-After headers
received. For addresses where no response was received or TCP
timeout occurred, an initial wait timer SHOULD be set to 5 seconds.
That timer MUST be doubled for each additional failure to connect or
receive response.
11. Capability Handling 11. Capability Handling
This section describes the available capability handling mechanism This section describes the available capability handling mechanism
which allows RTSP to be extended. Extensions to this version of the which allows RTSP to be extended. Extensions to this version of the
protocol are basically done in two ways. First, new headers can be protocol are basically done in two ways. First, new headers can be
added. Secondly, new methods can be added. The capability handling added. Secondly, new methods can be added. The capability handling
mechanism is designed to handle both cases. mechanism is designed to handle both cases.
When a method is added, the involved parties can use the OPTIONS When a method is added, the involved parties can use the OPTIONS
method to discover whether it is supported. This is done by issuing method to discover whether it is supported. This is done by issuing
skipping to change at page 60, line 10 skipping to change at page 61, line 10
resulting presentation will not be as expected by the requesting resulting presentation will not be as expected by the requesting
client, as only a single media instead of two will be played. In client, as only a single media instead of two will be played. In
this case the client can send a PAUSE request, correct the failing this case the client can send a PAUSE request, correct the failing
SETUP request and then request it to be played. SETUP request and then request it to be played.
13. Method Definitions 13. Method Definitions
The method indicates what is to be performed on the resource The method indicates what is to be performed on the resource
identified by the Request-URI. The method name is case-sensitive. identified by the Request-URI. The method name is case-sensitive.
New methods may be defined in the future. Method names MUST NOT New methods may be defined in the future. Method names MUST NOT
start with a $ character (decimal 24) and MUST be a token as defined start with a $ character (decimal 36) and MUST be a token as defined
by the ABNF [RFC5234] in the syntax chapter Section 20. The methods by the ABNF [RFC5234] in the syntax chapter Section 20. The methods
are summarized in Table 7. are summarized in Table 7.
+---------------+-----------+--------+-------------+-------------+ +---------------+-----------+--------+-------------+-------------+
| method | direction | object | Server req. | Client req. | | method | direction | object | Server req. | Client req. |
+---------------+-----------+--------+-------------+-------------+ +---------------+-----------+--------+-------------+-------------+
| DESCRIBE | C -> S | P,S | recommended | recommended | | DESCRIBE | C -> S | P,S | recommended | recommended |
| | | | | | | | | | | |
| GET_PARAMETER | C -> S | P,S | optional | optional | | GET_PARAMETER | C -> S | P,S | optional | optional |
| | | | | | | | | | | |
skipping to change at page 74, line 49 skipping to change at page 75, line 49
Range: npt=14-25 Range: npt=14-25
Seek-Style: Next Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921, ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193 ssrc=789DAF12:seq=57654;rtptime=2792842193
A common use of a PLAY request while in Play state is changing the A common use of a PLAY request while in Play state is changing the
scale of the media, i.e., entering or leaving from fast forward or scale of the media, i.e., entering or leaving from fast forward or
fast rewind. The client can issue an updating PLAY request that is fast rewind. The client can issue an updating PLAY request that is
either a continunation or a complete replacement, as discussed above either a continuation or a complete replacement, as discussed above
this section. We give an example of a client that is requesting a this section. We give an example of a client that is requesting a
fast forward without giving a stop point and the change from fast fast forward without giving a stop point and the change from fast
forward to regular playout (scale = 1). forward to regular playout (scale = 1).
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2034 CSeq: 2034
Session: 12345678 Session: 12345678
Range: npt=now- Range: npt=now-
Scale: 2.0 Scale: 2.0
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
skipping to change at page 75, line 27 skipping to change at page 76, line 27
Session: 12345678 Session: 12345678
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Range: npt=2:17:21.394- Range: npt=2:17:21.394-
Seek-Style: Next Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack" RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921, ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack" url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193 ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: 12345678 Session: 12345678
[playing in fast forward and now returing to scale = 1] [playing in fast forward and now returning to scale = 1]
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2035 CSeq: 2035
Session: 12345678 Session: 12345678
Range: npt=now- Range: npt=now-
Scale: 1.0 Scale: 1.0
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK S->C: RTSP/2.0 200 OK
CSeq: 2035 CSeq: 2035
skipping to change at page 89, line 4 skipping to change at page 90, line 4
Content-Type: text/parameters Content-Type: text/parameters
packets_received: 10 packets_received: 10
jitter: 0.3838 jitter: 0.3838
13.9. SET_PARAMETER 13.9. SET_PARAMETER
This method requests to set the value of a parameter or a set of This method requests to set the value of a parameter or a set of
parameters for a presentation or stream specified by the URI. The parameters for a presentation or stream specified by the URI. The
method MAY also be used without a message body. It is the method MAY also be used without a message body. It is the
RECOMMENDED method to be used in arequest sent for the sole purpose RECOMMENDED method to be used in a request sent for the sole purpose
of updating the keep-alive timer. If this request is successful, of updating the keep-alive timer. If this request is successful,
i.e. a 200 OK response is received, then the keep-alive timer has i.e. a 200 OK response is received, then the keep-alive timer has
been updated. Any non-required header present in such a request may 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 or may not been processed. To allow a client to determine if any
such header has been processed, it is necessary to use a feature tag such header has been processed, it is necessary to use a feature tag
and the Require header. Due to this reason it is RECOMMENDED that and the Require header. Due to this reason it is RECOMMENDED that
any parameters are sent in the body, rather than using any header. any parameters are sent in the body, rather than using any header.
A request is RECOMMENDED to only contain a single parameter to allow A request is RECOMMENDED to only contain a single parameter to allow
the client to determine why a particular request failed. If the the client to determine why a particular request failed. If the
skipping to change at page 93, line 18 skipping to change at page 94, line 18
conjunction with network address translators that block RTP traffic conjunction with network address translators that block RTP traffic
over UDP, it may be necessary to interleave RTSP messages and media over UDP, it may be necessary to interleave RTSP messages and media
stream data. This interleaving should generally be avoided unless stream data. This interleaving should generally be avoided unless
necessary since it complicates client and server operation and necessary since it complicates client and server operation and
imposes additional overhead. Also, head of line blocking may cause imposes additional overhead. Also, head of line blocking may cause
problems. Interleaved binary data SHOULD only be used if RTSP is problems. Interleaved binary data SHOULD only be used if RTSP is
carried over TCP. Interleaved data is not allowed inside RTSP carried over TCP. Interleaved data is not allowed inside RTSP
messages. messages.
Stream data such as RTP packets is encapsulated by an ASCII dollar Stream data such as RTP packets is encapsulated by an ASCII dollar
sign (24 decimal), followed by a one-byte channel identifier, sign (36 decimal), followed by a one-byte channel identifier,
followed by the length of the encapsulated binary data as a binary, followed by the length of the encapsulated binary data as a binary,
two-byte integer in network byte order. The stream data follows two-byte integer in network byte order. The stream data follows
immediately afterwards, without a CRLF, but including the upper-layer immediately afterwards, without a CRLF, but including the upper-layer
protocol headers. Each $ block MUST contain exactly one upper-layer protocol headers. Each $ block MUST contain exactly one upper-layer
protocol data unit, e.g., one RTP packet. protocol data unit, e.g., one RTP packet.
0 1 2 3 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 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 | | "$" = 36 | Channel ID | Length in bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Length number of bytes of binary data : : Length number of bytes of binary data :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The channel identifier is defined in the Transport header with the The channel identifier is defined in the Transport header with the
interleaved parameter (Section 16.52). interleaved parameter (Section 16.52).
When the transport choice is RTP, RTCP messages are also interleaved When the transport choice is RTP, RTCP messages are also interleaved
by the server over the TCP connection. The usage of RTCP messages is by the server over the TCP connection. The usage of RTCP messages is
indicated by including a interval containing a second channel in the indicated by including a interval containing a second channel in the
skipping to change at page 102, line 45 skipping to change at page 103, line 45
violation of this specification). The server would use this error violation of this specification). The server would use this error
code to indicate that the requested action could not be performed due code to indicate that the requested action could not be performed due
to the failure of completing the connection establishment. to the failure of completing the connection establishment.
15.4.30. 465 Notification Reason Unknown 15.4.30. 465 Notification Reason Unknown
This indicates that the client has received a PLAY_NOTIFY This indicates that the client has received a PLAY_NOTIFY
(Section 13.5) with a Notify-Reason header (Section 16.31) unknown to (Section 13.5) with a Notify-Reason header (Section 16.31) unknown to
the client. the client.
15.4.31. 470 Connection Authorization Required 15.4.31. 466 Key Management Error
This indicates that there has been an error in a Key Management
function used in conjunction with a request. For example usage of
MIKEY according to Appendix C.1.4.1 may result in this error.
15.4.32. 470 Connection Authorization Required
The secured connection attempt needs user or client authorization The secured connection attempt needs user or client authorization
before proceeding. The next hops certificate is included in this before proceeding. The next hops certificate is included in this
response in the Accept-Credentials header. response in the Accept-Credentials header.
15.4.32. 471 Connection Credentials not accepted 15.4.33. 471 Connection Credentials not accepted
When performing a secure connection over multiple connections, a When performing a secure connection over multiple connections, a
intermediary has refused to connect to the next hop and carry out the intermediary has refused to connect to the next hop and carry out the
request due to unacceptable credentials for the used policy. request due to unacceptable credentials for the used policy.
15.4.33. 472 Failure to establish secure connection 15.4.34. 472 Failure to establish secure connection
A proxy fails to establish a secure connection to the next hop RTSP 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 agent. This is primarily caused by a fatal failure at the TLS
handshake, for example due to server not accepting any cipher suits. handshake, for example due to server not accepting any cipher suits.
15.5. Server Error 5xx 15.5. Server Error 5xx
Response status codes beginning with the digit "5" indicate cases in Response status codes beginning with the digit "5" indicate cases in
which the server is aware that it has erred or is incapable of which the server is aware that it has erred or is incapable of
performing the request The server SHOULD include an message body performing the request The server SHOULD include an message body
skipping to change at page 103, line 52 skipping to change at page 105, line 12
response from the upstream server it accessed in attempting to response from the upstream server it accessed in attempting to
fulfill the request. fulfill the request.
15.5.4. 503 Service Unavailable 15.5.4. 503 Service Unavailable
The server is currently unable to handle the request due to a The server is currently unable to handle the request due to a
temporary overloading or maintenance of the server. The implication temporary overloading or maintenance of the server. The implication
is that this is a temporary condition which will be alleviated after 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 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 Retry-After header. If no Retry-After is given, the client SHOULD
handle the response as it would for a 500 response. handle the response as it would for a 500 response. The client MUST
honor the length, if given in the Retry-After header.
Note: The existence of the 503 status code does not imply that Note: The existence of the 503 status code does not imply that
a server must use it when becoming overloaded. Some servers a server must use it when becoming overloaded. Some servers
may wish to simply refuse the connection. may wish to simply refuse the connection.
15.5.5. 504 Gateway Timeout 15.5.5. 504 Gateway Timeout
The server, while acting as a proxy, did not receive a timely The server, while acting as a proxy, did not receive a timely
response from the upstream server specified by the URI or some other response from the upstream server specified by the URI or some other
auxiliary server (e.g. DNS) it needed to access in attempting to auxiliary server (e.g. DNS) it needed to access in attempting to
skipping to change at page 119, line 12 skipping to change at page 120, line 12
credentials SHOULD be valid for all other requests within this realm credentials SHOULD be valid for all other requests within this realm
(assuming that the authentication scheme itself does not require (assuming that the authentication scheme itself does not require
otherwise, such as credentials that vary according to a challenge otherwise, such as credentials that vary according to a challenge
value or using synchronized clocks). value or using synchronized clocks).
When a shared cache (see Section 18) receives a request containing an When a shared cache (see Section 18) receives a request containing an
Authorization field, it MUST NOT return the corresponding response as Authorization field, it MUST NOT return the corresponding response as
a reply to any other request, unless one of the following specific a reply to any other request, unless one of the following specific
exceptions holds: exceptions holds:
1. If the response includes the "maxage" cache-control directive, 1. If the response includes the "max-age" cache-control directive,
the cache MAY use that response in replying to a subsequent the cache MAY use that response in replying to a subsequent
request. But (if the specified maximum age has passed) a proxy request. But (if the specified maximum age has passed) a proxy
cache MUST first revalidate it with the origin server, using the cache MUST first revalidate it with the origin server, using the
request-headers from the new request to allow the origin server request-headers from the new request to allow the origin server
to authenticate the new request. (This is the defined behavior to authenticate the new request. (This is the defined behavior
for maxage.) If the response includes "maxage=0", the proxy MUST for max-age.) If the response includes "max-age=0", the proxy
always revalidate it before re-using it. MUST always revalidate it before re-using it.
2. If the response includes the "must-revalidate" cache-control 2. If the response includes the "must-revalidate" cache-control
directive, the cache MAY use that response in replying to a directive, the cache MAY use that response in replying to a
subsequent request. But if the response is stale, all caches subsequent request. But if the response is stale, all caches
MUST first revalidate it with the origin server, using the MUST first revalidate it with the origin server, using the
request-headers from the new request to allow the origin server request-headers from the new request to allow the origin server
to authenticate the new request. to authenticate the new request.
3. If the response includes the "public" cache-control directive, it 3. If the response includes the "public" cache-control directive, it
MAY be returned in reply to any subsequent request. MAY be returned in reply to any subsequent request.
16.8. Bandwidth 16.8. Bandwidth
The Bandwidth request-header field describes the estimated bandwidth The Bandwidth request-header field describes the estimated bandwidth
available to the client, expressed as a positive integer and measured available to the client, expressed as a positive integer and measured
in kilobits per second. The bandwidth available to the client may in kilobits per second. The bandwidth available to the client may
change during an RTSP session, e.g., due to mobility, congestion, change during an RTSP session, e.g., due to mobility, congestion,
etc. etc.
Clients may not be able to accurately determine the available
bandwidth, for example due to that first hop is not a bottleneck.
For example most local area networks (LAN) will not be a bottleneck
if the server is not in the same LAN. Thus link speeds of WLAN or
Ethernet networks are normally not a basis for estimating the
available bandwidth. Cellular devices or other devices directly
connected to an modem or connection enabling device may more
accurately estimate the bottleneck bandwidth and what is reasonable
share of it for RTSP controlled media. The client will also need to
take into account other traffic sharing the bottleneck. For example
by only assigning a certain fraction to RTSP and its media streams.
It is RECOMMENDED that only clients that has accurate and explicit
information about bandwidth bottlenecks uses this header.
This header is not a substitute for proper congestion control. Only
a method providing an initial estimate and coarsely determine if the
selected content can be delivered at all.
Example: Example:
Bandwidth: 62360 Bandwidth: 62360
16.9. Blocksize 16.9. Blocksize
The Blocksize request-header field is sent from the client to the The Blocksize request-header field is sent from the client to the
media server asking the server for a particular media packet size. media server asking the server for a particular media packet size.
This packet size does not include lower-layer headers such as IP, 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 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 than the one requested. The server MAY truncate this packet size to
skipping to change at page 126, line 22 skipping to change at page 127, line 42
where a resource has multiple variants associated with it, and those where a resource has multiple variants associated with it, and those
entities actually have separate locations by which they might be entities actually have separate locations by which they might be
individually accessed, the server SHOULD provide a Content-Location individually accessed, the server SHOULD provide a Content-Location
for the particular variant which is returned. for the particular variant which is returned.
The Content-Location value is not a replacement for the original The Content-Location value is not a replacement for the original
requested URI; it is only a statement of the location of the resource requested URI; it is only a statement of the location of the resource
corresponding to this particular variant at the time of the request. corresponding to this particular variant at the time of the request.
Future requests MAY specify the Content-Location URI as the request Future requests MAY specify the Content-Location URI as the request
URI if the desire is to identify the source of that particular URI if the desire is to identify the source of that particular
variant. variant. This is useful if the RTSP agent desires verify if the
resource variant is current through a conditional request.
A cache cannot assume that an message body with a Content-Location A cache cannot assume that an message body with a Content-Location
different from the URI used to retrieve it can be used to respond to different from the URI used to retrieve it can be used to respond to
later requests on that Content-Location URI. However, the Content- later requests on that Content-Location URI. However, the Content-
Location can be used to differentiate between multiple variants Location can be used to differentiate between multiple variants
retrieved from a single requested resource. retrieved from a single requested resource.
If the Content-Location is a relative URI, the relative URI is If the Content-Location is a relative URI, the relative URI is
interpreted relative to the Request-URI. interpreted relative to the Request-URI.
Note, that Content-Location can be used in some cases to derive the
base-URI for relative URI present in session description formats.
This needs to be taken into account when Content-Location is used.
The easiest way to avoid needing to consider that issue is to include
the Content-Base whenever the Content-Location is included.
Note also, when using Media Tags in conjunction with Content-Location
it is important that the different versions have different MTags,
even if provided under different Content-Location URIs. This as they
have still been provided under the same request URI.
Note also, as in most cases as the URI used in the DESCRIBE and the
SETUP requests are different the URI provided in a DESCRIBE Content-
Location response can't directly be used in a SETUP request. Instead
the extra step of resolving URIs combined with the media descriptions
indication, like with SDP's a=control attribute.
16.18. Content-Type 16.18. Content-Type
The Content-Type header indicates the media type of the message body The Content-Type header indicates the media type of the message body
sent to the recipient. Note that the content types suitable for RTSP sent to the recipient. Note that the content types suitable for RTSP
are likely to be restricted in practice to presentation descriptions are likely to be restricted in practice to presentation descriptions
and parameter-value types. and parameter-value types.
16.19. CSeq 16.19. CSeq
The CSeq general-header field specifies the sequence number for an The CSeq general-header field specifies the sequence number for an
skipping to change at page 129, line 38 skipping to change at page 131, line 27
their site's security policy. It is strongly recommended that the their site's security policy. It is strongly recommended that the
user be able to disable, enable, and modify the value of this field user be able to disable, enable, and modify the value of this field
at any time prior to a request. at any time prior to a request.
16.23. If-Match 16.23. If-Match
The If-Match request-header field is especially useful for ensuring The If-Match request-header field is especially useful for ensuring
the integrity of the presentation description, independent of how the the integrity of the presentation description, independent of how the
presentation description was received. The presentation description presentation description was received. The presentation description
can be fetched via means external to RTSP (such as HTTP) or via the can be fetched via means external to RTSP (such as HTTP) or via the
DESCRIBE message and the SETUP message. In the case of retrieving DESCRIBE message. In the case of retrieving the presentation
the presentation description via RTSP, the server implementation is description via RTSP, the server implementation is guaranteeing the
guaranteeing the integrity of the description between the time of the integrity of the description between the time of the DESCRIBE message
DESCRIBE message and the SETUP message. By including the MTag given and the SETUP message. By including the MTag given in or with the
in or with the session description in a If-Match header part of the session description in a If-Match header part of the SETUP request,
SETUP request, the client ensures that resources set up are matching the client ensures that resources set up are matching the
the description. A SETUP request with the If-Match header for which description. A SETUP request with the If-Match header for which the
the MTag validation check fails, MUST response using 412 MTag validation check fails, MUST response using 412 (Precondition
(Precondition Failed). Failed).
This validation check is also very useful if a session has been This validation check is also very useful if a session has been
redirected from one server to another. redirected from one server to another.
16.24. If-Modified-Since 16.24. If-Modified-Since
The If-Modified-Since request-header field is used with the DESCRIBE The If-Modified-Since request-header field is used with the DESCRIBE
and SETUP methods to make them conditional. If the requested variant and SETUP methods to make them conditional. If the requested variant
has not been modified since the time specified in this field, a has not been modified since the time specified in this field, a
description will not be returned from the server (DESCRIBE) or a description will not be returned from the server (DESCRIBE) or a
skipping to change at page 155, line 48 skipping to change at page 157, line 12
channel number in the response. The declared channel(s) are channel number in the response. The declared channel(s) are
bi-directional, so both end-parties MAY send data on the given bi-directional, so both end-parties MAY send data on the given
channel. One example of such usage is the second channel used channel. One example of such usage is the second channel used
for RTCP, where both server and client sends RTCP packets on for RTCP, where both server and client sends RTCP packets on
the same channel. the same channel.
This allows RTP/RTCP to be handled similarly to the way This allows RTP/RTCP to be handled similarly to the way
that it is done with UDP, i.e., one channel for RTP and that it is done with UDP, i.e., one channel for RTP and
the other for RTCP. the other for RTCP.
MIKEY: This parameter is used in conjunction with transport
specifications that can utilize MIKEY for security context
establishment. So far only the SRTP based RTP profiles SAVP
and SAVPF can utilize MIKEY and this is defined in
Appendix C.1.4.1. This parameter can be included both in
request and response messages. The binary MIKEY message SHALL
be BASE64 [RFC4648] encoded before being included in the value
part of the parameter.
Multicast-specific: Multicast-specific:
ttl: multicast time-to-live for IPv4. When included in requests the ttl: multicast time-to-live for IPv4. When included in requests the
value indicate the TTL value that the client request the server value indicate the TTL value that the client request the server
to use. In a response, the value actually being used by the to use. In a response, the value actually being used by the
server is returned. A server will need to consider what values server is returned. A server will need to consider what values
that are reasonable and also the authority of the user to set that are reasonable and also the authority of the user to set
this value. Corresponding functions are not needed for IPv6 as this value. Corresponding functions are not needed for IPv6 as
the scoping is part of the address. the scoping is part of the address.
skipping to change at page 156, line 32 skipping to change at page 158, line 5
The ssrc parameter MUST NOT be specified in requests. The The ssrc parameter MUST NOT be specified in requests. The
functionality of specifying the ssrc parameter in a SETUP functionality of specifying the ssrc parameter in a SETUP
request is deprecated as it is incompatible with the request is deprecated as it is incompatible with the
specification of RTP in RFC 3550[RFC3550]. If the parameter is specification of RTP in RFC 3550[RFC3550]. If the parameter is
included in the Transport header of a SETUP request, the server included in the Transport header of a SETUP request, the server
MAY ignore it, and choose appropriate SSRCs for the stream. MAY ignore it, and choose appropriate SSRCs for the stream.
The server MAY set the ssrc parameter in the Transport header The server MAY set the ssrc parameter in the Transport header
of the response. of the response.
RTCP-mux: Use to negotiate the usage of RTP and RTCP multiplexing
[RFC5761] on a single underlying transport stream / flow. The
presence of this parameter in a SETUP request indicates the
clients support and requires the server to use RTP and RTCP
multiplexing. The client SHALL only include one transport
stream in the Transport header specification. To provide the
server with a choice between using RTP/RTCP multiplexing or
not, two different transport header specifications must be
included.
The parameters setup and connection defined below MAY only be used if The parameters setup and connection defined below MAY only be used if
the media transport protocol of the lower-level transport is the media transport protocol of the lower-level transport is
connection-oriented (such as TCP). However, these parameters MUST connection-oriented (such as TCP). However, these parameters MUST
NOT be used when interleaving data over the RTSP control connection. NOT be used when interleaving data over the RTSP control connection.
The third parameter, RTCP-mux, can be used also in the interleaved
mode.
setup: Clients use the setup parameter on the Transport line in a setup: Clients use the setup parameter on the Transport line in a
SETUP request, to indicate the roles it wishes to play in a TCP SETUP request, to indicate the roles it wishes to play in a TCP
connection. This parameter is adapted from [RFC4145]. We connection. This parameter is adapted from [RFC4145]. We
discuss the use of this parameter in RTP/AVP/TCP non- discuss the use of this parameter in RTP/AVP/TCP non-
interleaved transport in Appendix C.2.2; the discussion below interleaved transport in Appendix C.2.2; the discussion below
is limited to syntactic issues. Clients may specify the is limited to syntactic issues. Clients may specify the
following values for the setup parameter: ["active":] The following values for the setup parameter: ["active":] The
client will initiate an outgoing connection. ["passive":] The client will initiate an outgoing connection. ["passive":] The
client will accept an incoming connection. ["actpass":] The client will accept an incoming connection. ["actpass":] The
skipping to change at page 157, line 43 skipping to change at page 159, line 27
value to "connection" on the Transport line. value to "connection" on the Transport line.
If a client SETUP request assigns the "existing" value to If a client SETUP request assigns the "existing" value to
"connection", the server response MUST assign a value of "connection", the server response MUST assign a value of
"existing" or "new" to "connection" on the Transport line, at "existing" or "new" to "connection" on the Transport line, at
its discretion. its discretion.
The default value of "connection" is "existing", for all SETUP The default value of "connection" is "existing", for all SETUP
requests (initial and subsequent). requests (initial and subsequent).
RTCP-mux: Use to negotiate the usage of RTP and RTCP multiplexing
[I-D.ietf-avt-rtp-and-rtcp-mux] on a single underlying
transport stream. The presence of this parameter in a SETUP
request indicates the clients support and requires the server
to use RTP and RTCP multiplexing. The client SHALL only
include one transport stream in the Transport header
specification. To provide the server with a choice between
using RTP/RTCP multiplexing or not, two different transport
header specifications must be included.
The combination of transport protocol, profile and lower transport The combination of transport protocol, profile and lower transport
needs to be defined. A number of combinations are defined in the needs to be defined. A number of combinations are defined in the
Appendix C. Appendix C.
Below is a usage example, showing a client advertising the capability Below is a usage example, showing a client advertising the capability
to handle multicast or unicast, preferring multicast. Since this is to handle multicast or unicast, preferring multicast. Since this is
a unicast-only stream, the server responds with the proper transport a unicast-only stream, the server responds with the proper transport
parameters for unicast. parameters for unicast.
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0 C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
skipping to change at page 185, line 30 skipping to change at page 187, line 30
/ "455" ; Method Not Valid in This State / "455" ; Method Not Valid in This State
/ "456" ; Header Field Not Valid for Resource / "456" ; Header Field Not Valid for Resource
/ "457" ; Invalid Range / "457" ; Invalid Range
/ "458" ; Parameter Is Read-Only / "458" ; Parameter Is Read-Only
/ "459" ; Aggregate operation not allowed / "459" ; Aggregate operation not allowed
/ "460" ; Only aggregate operation allowed / "460" ; Only aggregate operation allowed
/ "461" ; Unsupported Transport / "461" ; Unsupported Transport
/ "462" ; Destination Unreachable / "462" ; Destination Unreachable
/ "463" ; Destination Prohibited / "463" ; Destination Prohibited
/ "464" ; Data Transport Not Ready Yet / "464" ; Data Transport Not Ready Yet
/ "465" ; Notification Reason Unknown
/ "466" ; Key Management Error
/ "470" ; Connection Authorization Required / "470" ; Connection Authorization Required
/ "471" ; Connection Credentials not accepted / "471" ; Connection Credentials not accepted
/ "472" ; Failure to establish secure connection / "472" ; Failure to establish secure connection
/ "500" ; Internal Server Error / "500" ; Internal Server Error
/ "501" ; Not Implemented / "501" ; Not Implemented
/ "502" ; Bad Gateway / "502" ; Bad Gateway
/ "503" ; Service Unavailable / "503" ; Service Unavailable
/ "504" ; Gateway Time-out / "504" ; Gateway Time-out
/ "505" ; RTSP Version not supported / "505" ; RTSP Version not supported
/ "551" ; Option not supported / "551" ; Option not supported
skipping to change at page 195, line 18 skipping to change at page 197, line 18
/ (SEMI "interleaved" EQUAL channel [ "-" channel ]) / (SEMI "interleaved" EQUAL channel [ "-" channel ])
/ (SEMI "ttl" EQUAL ttl) / (SEMI "ttl" EQUAL ttl)
/ (SEMI "layers" EQUAL 1*DIGIT) / (SEMI "layers" EQUAL 1*DIGIT)
/ (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc)) / (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc))
/ (SEMI "mode" EQUAL mode-spec) / (SEMI "mode" EQUAL mode-spec)
/ (SEMI "dest_addr" EQUAL addr-list) / (SEMI "dest_addr" EQUAL addr-list)
/ (SEMI "src_addr" EQUAL addr-list) / (SEMI "src_addr" EQUAL addr-list)
/ (SEMI "setup" EQUAL contrans-setup) / (SEMI "setup" EQUAL contrans-setup)
/ (SEMI "connection" EQUAL contrans-con) / (SEMI "connection" EQUAL contrans-con)
/ (SEMI "RTCP-mux") / (SEMI "RTCP-mux")
/ (SEMI "MIKEY" EQUAL MIKEY-Value)
/ (SEMI trn-param-ext) / (SEMI trn-param-ext)
contrans-setup = "active" / "passive" / "actpass" contrans-setup = "active" / "passive" / "actpass"
contrans-con = "new" / "existing" contrans-con = "new" / "existing"
trn-param-ext = par-name [EQUAL trn-par-value] trn-param-ext = par-name [EQUAL trn-par-value]
par-name = token par-name = token
trn-par-value = *(rtsp-unreserved / quoted-string) trn-par-value = *(rtsp-unreserved / quoted-string)
ttl = 1*3DIGIT ; 0 to 255 ttl = 1*3DIGIT ; 0 to 255
ssrc = 8HEX ssrc = 8HEX
channel = 1*3DIGIT ; 0 to 255 channel = 1*3DIGIT ; 0 to 255
MIKEY-Value = base64
mode-spec = ( DQ mode *(COMMA mode) DQ ) mode-spec = ( DQ mode *(COMMA mode) DQ )
mode = "PLAY" / token mode = "PLAY" / token
addr-list = quoted-addr *(SLASH quoted-addr) addr-list = quoted-addr *(SLASH quoted-addr)
quoted-addr = DQ (host-port / extension-addr) DQ quoted-addr = DQ (host-port / extension-addr) DQ
host-port = ( host [":" port] ) host-port = ( host [":" port] )
/ ( ":" port ) / ( ":" port )
extension-addr = 1*qdtext extension-addr = 1*qdtext
host = < As defined in RFC 3986> host = < As defined in RFC 3986>
port = < As defined in RFC 3986> port = < As defined in RFC 3986>
Unsupported = "Unsupported" HCOLON feature-tag-list Unsupported = "Unsupported" HCOLON feature-tag-list
skipping to change at page 213, line 43 skipping to change at page 215, line 43
in combination with the "Extended RTP Profile for RTCP-based in combination with the "Extended RTP Profile for RTCP-based
Feedback (RTP/AVPF)"[RFC4585] over TCP. The usage is explained Feedback (RTP/AVPF)"[RFC4585] over TCP. The usage is explained
in RFC XXXX, Appendix C.2.2. in RFC XXXX, Appendix C.2.2.
RTP/SAVP/TCP: Use of the RTP[RFC3550] protocol for media transport RTP/SAVP/TCP: Use of the RTP[RFC3550] protocol for media transport
in combination with the "The Secure Real-time Transport in combination with the "The Secure Real-time Transport
Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in
RFC XXXX, Appendix C.2.2. RFC XXXX, Appendix C.2.2.
RTP/SAVPF/TCP: Use of the RTP[RFC3550] protocol for media transport RTP/SAVPF/TCP: Use of the RTP[RFC3550] protocol for media transport
in combination with the "[RFC5124] over TCP. The usage is in combination with the "Extended Secure RTP Profile for Real-
explained in RFC XXXX, Appendix C.2.2. time Transport Control Protocol (RTCP)-Based Feedback (RTP/
SAVPF)" [RFC5124] over TCP. The usage is explained in RFC
XXXX, Appendix C.2.2.
22.13.2. Transport modes 22.13.2. Transport modes
A registry for the transport parameter mode MUST be defined with the A registry for the transport parameter mode MUST be defined with the
following rules: following rules:
o Registering requires an IETF Standards Action. o Registering requires an IETF Standards Action.
o A contact person or organization with address and email. o A contact person or organization with address and email.
skipping to change at page 218, line 26 skipping to change at page 221, line 7
Security considerations: This format may carry any type of Security considerations: This format may carry any type of
parameters. Some can clear have security requirements, like parameters. Some can clear have security requirements, like
privacy, confidentiality or integrity requirements. The format privacy, confidentiality or integrity requirements. The format
has no built in security protection. For the usage it was defined has no built in security protection. For the usage it was defined
the transport can be protected between server and client using the transport can be protected between server and client using
TLS. However, care must be take to consider if also the proxies TLS. However, care must be take to consider if also the proxies
are trusted with the parameters in case hop-by-hop security is are trusted with the parameters in case hop-by-hop security is
used. If stored as file in file system the necessary precautions used. If stored as file in file system the necessary precautions
needs to be taken in relation to the parameters requirements needs to be taken in relation to the parameters requirements
including object security such as S/MIME [RFC3851]. including object security such as S/MIME [RFC5751].
Interoperability considerations: This media type was mentioned as a Interoperability considerations: This media type was mentioned as a
fictional example in RFC 2326 but was not formally specified. fictional example in RFC 2326 but was not formally specified.
This have resulted in usage of this media type which may not match This have resulted in usage of this media type which may not match
its formal definition. its formal definition.
Published specification: RFC XXXX, Appendix F. Published specification: RFC XXXX, Appendix F.
Applications that use this media type: Applications that use RTSP Applications that use this media type: Applications that use RTSP
and have additional parameters they like to read and set using the and have additional parameters they like to read and set using the
skipping to change at page 220, line 20 skipping to change at page 222, line 20
Third Generation Partnership Project (3GPP), "Transparent Third Generation Partnership Project (3GPP), "Transparent
end-to-end Packet-switched Streaming Service (PSS); end-to-end Packet-switched Streaming Service (PSS);
Protocols and codecs; Technical Specification 26.234", Protocols and codecs; Technical Specification 26.234",
December 2002. December 2002.
[FIPS-pub-180-2] [FIPS-pub-180-2]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Federal Information Processing Standards Publications "Federal Information Processing Standards Publications
(FIPS PUBS) 180-2: Secure Hash Standard", August 2002. (FIPS PUBS) 180-2: Secure Hash Standard", August 2002.
[I-D.ietf-avt-rtp-and-rtcp-mux]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
skipping to change at page 221, line 16 skipping to change at page 223, line 10
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004. August 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
skipping to change at page 222, line 11 skipping to change at page 223, line 50
Oriented Transport", RFC 4571, July 2006. Oriented Transport", RFC 4571, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-
RSA-R: An Additional Mode of Key Distribution in
Multimedia Internet KEYing (MIKEY)", RFC 4738,
November 2006.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008. (RTP/SAVPF)", RFC 5124, February 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
skipping to change at page 222, line 33 skipping to change at page 224, line 29
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, September 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010.
23.2. Informative References 23.2. Informative References
[I-D.ietf-mmusic-rtsp-nat] [I-D.ietf-mmusic-rtsp-nat]
Goldberg, J., Westerlund, M., and T. Zeng, "A Network Goldberg, J., Westerlund, M., and T. Zeng, "A Network
Address Translator (NAT) Traversal mechanism for media Address Translator (NAT) Traversal mechanism for media
controlled by Real-Time Streaming Protocol (RTSP)", controlled by Real-Time Streaming Protocol (RTSP)",
draft-ietf-mmusic-rtsp-nat-09 (work in progress), draft-ietf-mmusic-rtsp-nat-09 (work in progress),
January 2010. January 2010.
[ISO.13818-6.1995] [ISO.13818-6.1995]
skipping to change at page 223, line 13 skipping to change at page 225, line 17
elements and interchange formats - Information interchange elements and interchange formats - Information interchange
- Representation of dates and times", ISO/IEC Standard - Representation of dates and times", ISO/IEC Standard
8601, December 2000. 8601, December 2000.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet [RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982. text messages", STD 11, RFC 822, August 1982.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions
Functional Specification", RFC 1644, July 1994. Functional Specification", RFC 1644, July 1994.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997. RFC 2068, January 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
skipping to change at page 223, line 38 skipping to change at page 225, line 39
RFC 2663, August 1999. RFC 2663, August 1999.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding [RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding
Dependency in the Session Description Protocol (SDP)", Dependency in the Session Description Protocol (SDP)",
RFC 5583, July 2009. RFC 5583, July 2009.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
[Stevens98] [Stevens98]
Stevens, W., "Unix Networking Programming - Volume 1, Stevens, W., "Unix Networking Programming - Volume 1,
second edition", 1998. second edition", 1998.
Appendix A. Examples Appendix A. Examples
This section contains several different examples trying to illustrate This section contains several different examples trying to illustrate
possible ways of using RTSP. The examples can also help with the possible ways of using RTSP. The examples can also help with the
understanding of how functions of RTSP work. However, remember that understanding of how functions of RTSP work. However, remember that
these are examples and the normative and syntax description in the these are examples and the normative and syntax description in the
skipping to change at page 249, line 16 skipping to change at page 251, line 16
AVPF related SDP attributes configuring the AVPF session regarding AVPF related SDP attributes configuring the AVPF session regarding
reporting interval and feedback messages to be used. This reporting interval and feedback messages to be used. This
configuration MUST be followed. configuration MUST be followed.
C.1.4. SAVP/UDP C.1.4. SAVP/UDP
The RTP profile "The Secure Real-time Transport Protocol (SRTP)" The RTP profile "The Secure Real-time Transport Protocol (SRTP)"
[RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions [RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions
using RTP. All that is defined for AVP MUST also apply for SAVP. using RTP. All that is defined for AVP MUST also apply for SAVP.
The usage of SRTP requires that a security association is The usage of SRTP requires that a security context is established.
established. The RECOMMENDED mechanism for establishing that The default key-management unless otherwise signalled shall be MIKEY
security association is to use MIKEY with RTSP as defined in RFC 4567 in RSA-R mode as defined in Appendix C.1.4.1, and not according to
[RFC4567]. the procedure defined in "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)"
[RFC4567]. The reason is that RFC 4567 sends the initial MIKEY
message in SDP, thus both requiring the usage of the DESCRIBE method
and forcing the server to keep state for client performing DESCRIBE
in anticipation that they might require key management.
MIKEY is selected as default method for establishing security
association within an RTSP session as it can be embedded in the RTSP
messages, while still ensuring confidentiality of content of the
keying material, even when using hop-by-hop TLS security for the RTSP
messages. This method does also support pipelining of the RTSP
messages.
C.1.4.1. MIKEY Key Establishment
This method for using MIKEY to establish the security context for
SRTP is initiated in the client's SETUP request, and the servers
response to the SETUP carries the MIKEY response. Thus ensuring that
the Security context establishment happens simultaneously with the
establishment of the media stream being protected. By using MIKEY's
RSA-R mode [RFC4738] the client can be initiator and still allow the
server to set the parameters in accordance with the actual media
stream.
The Security Context Establishment is done according to the following
process:
1. The client determines that SAVP or SAVPF shall be used from
media description format, e.g. SDP. If no other key management
method is explicitly signalled, then MIKEY SHALL be used as
defined here in. This specification does not specify an
explicit method for indicating this security context
establishment method, but future specifications may.
2. The client SHALL establish a TLS connection for RTSP messages,
directly or hop by hop with the server. If hop-by-hop TLS
security is used, the User method SHALL be indicated in the
Accept-Credentials header. We do note that using hop-by-hop
does allow the proxy to insert itself as a man in the middle
also in the MIKEY exchange by providing one of its certificates,
rather than the server's in the Connection-Credentials header.
The client shall therefore validate the server certificate.
3. The client retrieves the servers certificate from a direct TLS
connection, or if hop by hop from Connection-Credentials header.
The client then checks that the server certificate is valid and
belongs to server.
4. The client forms the MIKEY Initiator message using RSA-R mode in
unicast mode as specified in [RFC4738]. The client SHOULD use
the same certificate for TLS and in MIKEY to enable server to
bind the two together. The client's certificate SHALL be
included in the MIKEY message. The client SHALL indicate its
SRTP capabilities in the message.
5. The MIKEY message from the previous step is base64 [RFC4648]
encoded and becomes the value of the MIKEY parameter that are
included in the transport specification(s) that specifies a SRTP
based profile (SAVP, SAVPF) in the SETUP request.
6. Any proxy encountering the MIKEY parameter SHALL forward it
without modification. A proxy requiring to understand transport
specificaation which doesn't support SAVP/SAVPF with MIKEY will
discard the whole transport specification. Most types of proxy
can easily support SAVP and SAVPF with MIKEY. If possible
bypassing the proxy should be tried.
7. The server upon receiving the SETUP request, while need to
decide upon the transport specification to use, if multiple are
included by the client. In the determination of which transport
specifications that are supported and preferred, the server
should decode the MIKEY message to take the embedded SRTP
parameters into account. If all transport specs require SRTP
but no MIKEY parameter or other supported keying method is
included, the server shall respond with 403.
8. Upon generating a response the following outcomes can occur:
* A transport spec not using SRTP and MIKEY is selected. Thus
the answer will not contain any MIKEY parameter.
* A transport spec using SRTP and MIKEY is selected but an
error is encountered in the MIKEY processing. In that case
an RTSP error response code of 466 "Key Management Error"
SHALL be used. A MIKEY message describing the error MAY be
included.
* A transport spec using SRTP and MIKEY is selected and a MIKEY
response message can be created. The server SHOULD use the
same certificate for TLS and in MIKEY to enable client to
bind the two together. If a different certificate is used it
SHALL be included in the MIKEY message. It is RECOMMENDED
that the envelope key cache type is set to 'Cache' and that a
single envelope key is reused for all MIKEY messages to the
client. That message is included in the MIKEY parameter part
of the single selected transport specification in the SETUP
response. The server will set the SRTP parameters as
preferred for this media stream within the supported range by
the client.
9. The server transmits the SETUP response back to the client.
10. The client receives the SETUP response and if the response code
indicates a successful request it decodes the MIKEY message and
establish the security context from the parameters in the MIKEY
response.
In the above method the client's certificate may be self-signed in
cases where the client's identify is not necessary to establish and
the security goal is only to ensure that the RTSP signalling client
is the same as the one receiving the SRTP security context.
C.1.5. SAVPF/UDP C.1.5. SAVPF/UDP
The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback The RTP profile "Extended Secure RTP Profile for RTCP-based Feedback
(RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in (RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in
RTSP sessions using RTP. All that is defined for AVP MUST also apply RTSP sessions using RTP. All that is defined for AVP MUST also apply
for SAVPF. for SAVPF.
The usage of SRTP requires that a security association is The usage of SRTP requires that a security association is
established. The RECOMMENDED mechanism for establishing that established. The default mechanism for establishing that security
security association is to use MIKEY[RFC3830] with RTSP as defined in association is to use MIKEY[RFC3830] with RTSP as defined
RFC 4567 [RFC4567]. Appendix C.1.4.1.
C.1.6. RTCP usage with RTSP C.1.6. RTCP usage with RTSP
RTCP has several usages when RTP is used for media transport as RTCP has several usages when RTP is used for media transport as
explained below. Due to that RTCP MUST be supported if an RTSP agent explained below. Due to that RTCP MUST be supported if an RTSP agent
handles RTP. handles RTP.
C.1.6.1. Media synchronization C.1.6.1. Media synchronization
RTCP provides media synchronization and clock drift compensation. RTCP provides media synchronization and clock drift compensation.
skipping to change at page 250, line 19 skipping to change at page 254, line 33
when RTP is sent over UDP. An RTP sender without reserved resources when RTP is sent over UDP. An RTP sender without reserved resources
MUST NOT use more than its fair share of the available resources. MUST NOT use more than its fair share of the available resources.
This can be determined by comparing on short to medium term (some This can be determined by comparing on short to medium term (some
seconds) the used bit-rate and adapt it so that the RTP sender sends seconds) the used bit-rate and adapt it so that the RTP sender sends
at a bit-rate comparable to what a TCP sender would achieve on at a bit-rate comparable to what a TCP sender would achieve on
average over the same path. average over the same path.
C.1.6.4. RTP and RTCP Multiplexing C.1.6.4. RTP and RTCP Multiplexing
RTSP can be used to negotiate the usage of RTP and RTCP multiplexing RTSP can be used to negotiate the usage of RTP and RTCP multiplexing
as described in [I-D.ietf-avt-rtp-and-rtcp-mux]. This allows servers as described in [RFC5761]. This allows servers and client to reduce
and client to reduce the amount of resources required for the session the amount of resources required for the session by only requiring
by only requiring one underlying transport stream per media stream one underlying transport stream per media stream instead of two when
instead of two when using RTP and RTCP. This lessens the server port using RTP and RTCP. This lessens the server port consumption and
consumption and also the necessary state and keep-alive work when also the necessary state and keep-alive work when operating across
operating across Network and Address Translators [RFC2663]. Network and Address Translators [RFC2663].
Content must be prepared with some consideration for RTP and RTCP Content must be prepared with some consideration for RTP and RTCP
multiplexing, mainly ensuring that the RTP payload types used does multiplexing, mainly ensuring that the RTP payload types used does
not collide with the ones used for RTCP packet types this option not collide with the ones used for RTCP packet types this option
likely needs explicit support from the content unless the RTP payload likely needs explicit support from the content unless the RTP payload
types can be remapped by the server and that is correctly reflected types can be remapped by the server and that is correctly reflected
in the session description. Beyond that support of this feature in the session description. Beyond that support of this feature
should come at little cost and much gain. should come at little cost and much gain.
It is recommended that if the content and server supports RTP and It is recommended that if the content and server supports RTP and
skipping to change at page 253, line 27 skipping to change at page 257, line 41
continue using the existing TCP RTP and RTCP connections? The client continue using the existing TCP RTP and RTCP connections? The client
SHOULD use the "connection" parameter (defined in Section 16.52) on SHOULD use the "connection" parameter (defined in Section 16.52) on
the Transport line to make its intention clear in the regard (by the Transport line to make its intention clear in the regard (by
setting "connection" to "new" if new connections are needed, and by setting "connection" to "new" if new connections are needed, and by
setting "connection" to "existing" if the existing connections are to setting "connection" to "existing" if the existing connections are to
be used). After a 2xx reply for a SETUP request for a new be used). After a 2xx reply for a SETUP request for a new
connection, parties should close the pre-existing connections, after connection, parties should close the pre-existing connections, after
waiting a suitable period for any stray RTP or RTCP packets to waiting a suitable period for any stray RTP or RTCP packets to
arrive. arrive.
The usage of SRTP, i.e. either SAVP or SAVPF profiles requires that a
security association is established. The default mechanism for
establishing that security association is to use MIKEY[RFC3830] with
RTSP as defined Appendix C.1.4.1.
Below, we rewrite part of the example media on demand example shown Below, we rewrite part of the example media on demand example shown
in Appendix A.1 to use RTP/AVP/TCP non-interleaved: in Appendix A.1 to use RTP/AVP/TCP non-interleaved:
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0 C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1 CSeq: 1
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 1 CSeq: 1
Server: PhonyServer/1.0 Server: PhonyServer/1.0
skipping to change at page 263, line 18 skipping to change at page 267, line 18
describe streams or presentations in RTSP. This description is describe streams or presentations in RTSP. This description is
typically returned in reply to a DESCRIBE request on an URI from a typically returned in reply to a DESCRIBE request on an URI from a
server to a client, or received via HTTP from a server to a client. server to a client, or received via HTTP from a server to a client.
This appendix describes how an SDP file determines the operation of This appendix describes how an SDP file determines the operation of
an RTSP session. SDP as is provides no mechanism by which a client an RTSP session. SDP as is provides no mechanism by which a client
can distinguish, without human guidance, between several media can distinguish, without human guidance, between several media
streams to be rendered simultaneously and a set of alternatives streams to be rendered simultaneously and a set of alternatives
(e.g., two audio streams spoken in different languages). The SDP (e.g., two audio streams spoken in different languages). The SDP
extension "Grouping of Media Lines in the Session Description extension "Grouping of Media Lines in the Session Description
Protocol (SDP)" [RFC3388] provides such functionality to some degree. Protocol (SDP)" [RFC5888] provides such functionality to some degree.
Appendix D.4 describes the usage of SDP media line grouping for RTSP. Appendix D.4 describes the usage of SDP media line grouping for RTSP.
D.1. Definitions D.1. Definitions
The terms "session-level", "media-level" and other key/attribute The terms "session-level", "media-level" and other key/attribute
names and values used in this appendix are to be used as defined in names and values used in this appendix are to be used as defined in
SDP[RFC4566]: SDP[RFC4566]:
D.1.1. Control URI D.1.1. Control URI
skipping to change at page 265, line 31 skipping to change at page 269, line 31
payload type is a static payload type from RFC 3551 [RFC3551], no payload type is a static payload type from RFC 3551 [RFC3551], no
other information may be required. In case it is a dynamic payload other information may be required. In case it is a dynamic payload
type, the media attribute "rtpmap" is used to specify what the media type, the media attribute "rtpmap" is used to specify what the media
is. The "encoding name" within the "rtpmap" attribute may be one of is. The "encoding name" within the "rtpmap" attribute may be one of
those specified in RFC 3551 (Sections 5 and 6), or an MIME type those specified in RFC 3551 (Sections 5 and 6), or an MIME type
registered with IANA, or an experimental encoding as specified in SDP registered with IANA, or an experimental encoding as specified in SDP
(RFC 4566 [RFC4566]). Codec-specific parameters are not specified in (RFC 4566 [RFC4566]). Codec-specific parameters are not specified in
this field, but rather in the "fmtp" attribute described below. this field, but rather in the "fmtp" attribute described below.
The selection of the RTP payload type numbers used may be required to The selection of the RTP payload type numbers used may be required to
consider RTP and RTCP Multiplexing [I-D.ietf-avt-rtp-and-rtcp-mux] if consider RTP and RTCP Multiplexing [RFC5761] if that is to be
that is to be supported by the server. supported by the server.
D.1.4. Format-Specific Parameters D.1.4. Format-Specific Parameters
Format-specific parameters are conveyed using the "fmtp" media Format-specific parameters are conveyed using the "fmtp" media
attribute. The syntax of the "fmtp" attribute is specific to the attribute. The syntax of the "fmtp" attribute is specific to the
encoding(s) that the attribute refers to. Note that some of the encoding(s) that the attribute refers to. Note that some of the
format specific parameters may be specified outside of the fmtp format specific parameters may be specified outside of the fmtp
parameters, like for example the "ptime" attribute for most audio parameters, like for example the "ptime" attribute for most audio
encodings. encodings.
skipping to change at page 270, line 4 skipping to change at page 274, line 4
A client is not required to issues SETUP requests for all streams A client is not required to issues SETUP requests for all streams
within an aggregate object. Servers should allow the client to ask within an aggregate object. Servers should allow the client to ask
for only a subset of the streams. for only a subset of the streams.
D.4. Grouping of Media Lines in SDP D.4. Grouping of Media Lines in SDP
For some types media it is desirable to express a relationship For some types media it is desirable to express a relationship
between various media components, for instance, for lip between various media components, for instance, for lip
synchronization or Scalable Video Codec (SVC) [RFC5583]. This synchronization or Scalable Video Codec (SVC) [RFC5583]. This
relationship is expressed on the SDP level by grouping of media relationship is expressed on the SDP level by grouping of media
lines, as described in [RFC3388] and can be exposed to RTSP. lines, as described in [RFC5888] and can be exposed to RTSP.
For RTSP it is mainly important to know how to handle grouped medias For RTSP it is mainly important to know how to handle grouped medias
received by means of SDP, i.e., if the media are under aggregate received by means of SDP, i.e., if the media are under aggregate
control (see Appendix D.3) or if aggregate control is not available control (see Appendix D.3) or if aggregate control is not available
(see Appendix D.2). (see Appendix D.2).
It is RECOMMENDED that grouped medias are handled by aggregate It is RECOMMENDED that grouped medias are handled by aggregate
control, to give the client the ability to control either the whole control, to give the client the ability to control either the whole
presentation or single medias. presentation or single medias.
skipping to change at page 282, line 33 skipping to change at page 286, line 33
Compared to RTSP 1.0 (RFC 2326), the below changes has been made when Compared to RTSP 1.0 (RFC 2326), the below changes has been made when
defining RTSP 2.0. Note that this list does not reflect minor defining RTSP 2.0. Note that this list does not reflect minor
changes in wording or correction of typographical errors. changes in wording or correction of typographical errors.
o The section on minimal implementation was deleted without o The section on minimal implementation was deleted without
substitution. substitution.
o The Transport header has been changed in the following way: o The Transport header has been changed in the following way:
* The ABNF has been changed to define that extensions are * The ABNF has been changed to define that extensions are
possible, and that unknown extension parameters are to be possible, and that unknown parameters results in that servers
ignored. ignore the transport specification.
* To prevent backwards compatibility issues, any extension or new * To prevent backwards compatibility issues, any extension or new
parameter requires the usage of a feature-tag combined with the parameter requires the usage of a feature-tag combined with the
Require header. Require header.
* Syntax unclarities with the Mode parameter has been resolved. * Syntax unclarities with the Mode parameter has been resolved.
* Syntax error with ";" for multicast and unicast has been * Syntax error with ";" for multicast and unicast has been
resolved. resolved.
skipping to change at page 289, line 33 skipping to change at page 293, line 33
Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt,
John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Ingemar Johansson, John K. Ho, Go Hori, Philipp Hoschka, Anne Jones, Ingemar Johansson,
Anders Klemets, Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo Anders Klemets, Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo
F. Llach, Thomas Marshall, Rob McCool, David Oran, Joerg Ott, Maria F. Llach, Thomas Marshall, Rob McCool, David Oran, Joerg Ott, Maria
Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins,
Igor Plotnikov, Jonathan Sergent, Pinaki Shah, David Singer, Lior Igor Plotnikov, Jonathan Sergent, Pinaki Shah, David Singer, Lior
Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John Francis Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John Francis
Stracke, Maureen Chesire, David Walker, Geetha Srikantan, Stephan Stracke, Maureen Chesire, David Walker, Geetha Srikantan, Stephan
Wenger, Pekka Pessi, Jae-Hwan Kim, Holger Schmidt, Stephen Farrell, Wenger, Pekka Pessi, Jae-Hwan Kim, Holger Schmidt, Stephen Farrell,
Xavier Marjou, Joe Pallas, Martti Mela, Byungjo Yoon and Patrick Xavier Marjou, Joe Pallas, Martti Mela, Byungjo Yoon and Patrick
Hoffman. Hoffman, Jinhang Choi.
K.1. Contributors K.1. Contributors
The following people have made written contributions that were The following people have made written contributions that were
included in the specification: included in the specification:
o Tom Marshall contributed text on the usage of 3rr status codes. o Tom Marshall contributed text on the usage of 3rr status codes.
o Thomas Zheng contributed text on the usage of the Range in PLAY o Thomas Zheng contributed text on the usage of the Range in PLAY
responses and proposed an earlier version of the PLAY_NOTIFY responses and proposed an earlier version of the PLAY_NOTIFY
skipping to change at page 292, line 42 skipping to change at page 296, line 42
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
Martin Stiemerling Martin Stiemerling
NEC Laboratories Europe, NEC Europe Ltd. NEC Laboratories Europe, NEC Europe Ltd.
Kurfuersten-Anlage 36 Kurfuersten-Anlage 36
Heidelberg 69115 Heidelberg 69115
Germany Germany
Phone: +49 (0) 6221 4342 113 Phone: +49 (0) 6221 4342 113
Email: stiemerling@nw.neclab.eu Email: martin.stiemerling@neclab.eu
URI: http://ietf.stiemerling.org
 End of changes. 60 change blocks. 
383 lines changed or deleted 607 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/