draft-ietf-mmusic-rfc2326bis-16.txt   draft-ietf-mmusic-rfc2326bis-17.txt 
MMUSIC Working Group H. Schulzrinne MMUSIC Working Group H. Schulzrinne
Internet-Draft Columbia University Internet-Draft Columbia University
Intended status: Standards Track A. Rao Intended status: Standards Track A. Rao
Expires: May 22, 2008 Cisco Expires: August 28, 2008 Cisco
R. Lanphier R. Lanphier
Real Networks Real Networks
M. Westerlund M. Westerlund
Ericsson AB Ericsson AB
M. Stiemerling (Ed.) M. Stiemerling (Ed.)
NEC NEC
November 19, 2007 February 25, 2008
Real Time Streaming Protocol 2.0 (RTSP) Real Time Streaming Protocol 2.0 (RTSP)
draft-ietf-mmusic-rfc2326bis-16.txt draft-ietf-mmusic-rfc2326bis-17.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 22, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This memorandum defines RTSP version 2.0 which is a revision of the This memorandum defines RTSP version 2.0 which is a revision of the
Proposed Standard RTSP version 1.0 which is defined in RFC 2326. Proposed Standard RTSP version 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 control over the delivery of data with real-time protocol for control over 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 2, line 25 skipping to change at page 2, line 25
clips. This protocol is intended to control multiple data delivery clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP, sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and provide a means for choosing delivery multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550). mechanisms based upon RTP (RFC 3550).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Scope and Background . . . . . . . . . . . . . . . . . . 8 1.1. Scope and Background . . . . . . . . . . . . . . . . . . 8
1.2. RTSP Specificication Update . . . . . . . . . . . . . . 9 1.2. RTSP Specificication Update . . . . . . . . . . . . . . 9
1.3. Notational Conventions . . . . . . . . . . . . . . . . . 10 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 9
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 10 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 10
2. RTSP Introduction . . . . . . . . . . . . . . . . . . . . . . 15 2. RTSP Introduction . . . . . . . . . . . . . . . . . . . . . . 14
2.1. Protocol Properties . . . . . . . . . . . . . . . . . . 15 2.1. Protocol Properties . . . . . . . . . . . . . . . . . . 14
2.2. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 16 2.2. RTSP's Relationship to HTTP . . . . . . . . . . . . . . 15
2.3. Overall Operation . . . . . . . . . . . . . . . . . . . 17 2.3. Extending RTSP . . . . . . . . . . . . . . . . . . . . . 16
2.4. RTSP States . . . . . . . . . . . . . . . . . . . . . . 18 2.4. Overall Operation . . . . . . . . . . . . . . . . . . . 17
2.5. Relationship with Other Protocols . . . . . . . . . . . 19 2.5. RTSP States . . . . . . . . . . . . . . . . . . . . . . 18
2.6. Relationship with Other Protocols . . . . . . . . . . . 19
3. RTSP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 20 3. RTSP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 20
3.1. On-demand Playback of Stored Content . . . . . . . . . . 20 3.1. On-demand Playback of Stored Content . . . . . . . . . . 20
3.2. Unicast distribution of Live Content . . . . . . . . . . 21 3.2. Unicast distribution of Live Content . . . . . . . . . . 21
3.3. On-demand Playback using Multicast . . . . . . . . . . . 22 3.3. On-demand Playback using Multicast . . . . . . . . . . . 22
3.4. Inviting an RTSP server into a conference . . . . . . . 22 3.4. Inviting an RTSP server into a conference . . . . . . . 22
3.5. Live Content using Multicast . . . . . . . . . . . . . . 23 3.5. Live Content using Multicast . . . . . . . . . . . . . . 23
4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 25 4. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 25
4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 25 4.1. RTSP Version . . . . . . . . . . . . . . . . . . . . . . 25
4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 25 4.2. RTSP IRI and URI . . . . . . . . . . . . . . . . . . . . 25
4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 27 4.3. Session Identifiers . . . . . . . . . . . . . . . . . . 27
skipping to change at page 3, line 21 skipping to change at page 3, line 22
8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 37 8.1.1. Status Code and Reason Phrase . . . . . . . . . . . 37
8.2. Response Header Fields . . . . . . . . . . . . . . . . . 40 8.2. Response Header Fields . . . . . . . . . . . . . . . . . 40
9. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 9. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 43 9.1. Entity Header Fields . . . . . . . . . . . . . . . . . . 43
9.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 44 9.2. Entity Body . . . . . . . . . . . . . . . . . . . . . . 44
10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 45 10. Connections . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Reliability and Acknowledgements . . . . . . . . . . . . 45 10.1. Reliability and Acknowledgements . . . . . . . . . . . . 45
10.2. Using Connections . . . . . . . . . . . . . . . . . . . 46 10.2. Using Connections . . . . . . . . . . . . . . . . . . . 46
10.3. Closing Connections . . . . . . . . . . . . . . . . . . 47 10.3. Closing Connections . . . . . . . . . . . . . . . . . . 47
10.4. Timing Out Connections and RTSP Messages . . . . . . . . 48 10.4. Timing Out Connections and RTSP Messages . . . . . . . . 48
10.5. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 48 10.5. Showing Liveness . . . . . . . . . . . . . . . . . . . . 48
11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 49 10.6. Use of IPv6 . . . . . . . . . . . . . . . . . . . . . . 49
12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 51 11. Capability Handling . . . . . . . . . . . . . . . . . . . . . 50
13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 52 12. Pipelining Support . . . . . . . . . . . . . . . . . . . . . 52
13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 53 13. Method Definitions . . . . . . . . . . . . . . . . . . . . . 53
13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 54 13.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 54
13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 56 13.2. DESCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 55
13.3.1. Changing Transport Parameters . . . . . . . . . . . 58 13.3. SETUP . . . . . . . . . . . . . . . . . . . . . . . . . 57
13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 59 13.3.1. Changing Transport Parameters . . . . . . . . . . . 59
13.5. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 64 13.4. PLAY . . . . . . . . . . . . . . . . . . . . . . . . . . 60
13.6. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 66 13.5. PAUSE . . . . . . . . . . . . . . . . . . . . . . . . . 65
13.7. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 67 13.6. TEARDOWN . . . . . . . . . . . . . . . . . . . . . . . . 68
13.8. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 68 13.7. GET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 69
13.9. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 69 13.8. SET_PARAMETER . . . . . . . . . . . . . . . . . . . . . 70
14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 73 13.9. REDIRECT . . . . . . . . . . . . . . . . . . . . . . . . 71
15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 75 14. Embedded (Interleaved) Binary Data . . . . . . . . . . . . . 74
15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 75 15. Status Code Definitions . . . . . . . . . . . . . . . . . . . 76
15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 75 15.1. Success 1xx . . . . . . . . . . . . . . . . . . . . . . 76
15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 75 15.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 76
15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 75 15.2. Success 2xx . . . . . . . . . . . . . . . . . . . . . . 76
15.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 76 15.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 76
15.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 76 15.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . 76
15.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 76 15.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 77
15.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 76 15.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . 77
15.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 76 15.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . 77
15.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 77 15.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . 77
15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 77 15.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . 77
15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 77 15.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . 78
15.4.2. 405 Method Not Allowed . . . . . . . . . . . . . . . 77 15.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 78
15.4.3. 451 Parameter Not Understood . . . . . . . . . . . . 77 15.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . 78
15.4.4. 452 reserved . . . . . . . . . . . . . . . . . . . . 77 15.4.2. 405 Method Not Allowed . . . . . . . . . . . . . . . 78
15.4.5. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 78 15.4.3. 451 Parameter Not Understood . . . . . . . . . . . . 78
15.4.6. 454 Session Not Found . . . . . . . . . . . . . . . 78 15.4.4. 452 reserved . . . . . . . . . . . . . . . . . . . . 78
15.4.7. 455 Method Not Valid in This State . . . . . . . . . 78 15.4.5. 453 Not Enough Bandwidth . . . . . . . . . . . . . . 79
15.4.8. 456 Header Field Not Valid for Resource . . . . . . 78 15.4.6. 454 Session Not Found . . . . . . . . . . . . . . . 79
15.4.9. 457 Invalid Range . . . . . . . . . . . . . . . . . 78 15.4.7. 455 Method Not Valid in This State . . . . . . . . . 79
15.4.10. 458 Parameter Is Read-Only . . . . . . . . . . . . . 78 15.4.8. 456 Header Field Not Valid for Resource . . . . . . 79
15.4.11. 459 Aggregate Operation Not Allowed . . . . . . . . 78 15.4.9. 457 Invalid Range . . . . . . . . . . . . . . . . . 79
15.4.12. 460 Only Aggregate Operation Allowed . . . . . . . . 78 15.4.10. 458 Parameter Is Read-Only . . . . . . . . . . . . . 79
15.4.13. 461 Unsupported Transport . . . . . . . . . . . . . 79 15.4.11. 459 Aggregate Operation Not Allowed . . . . . . . . 79
15.4.14. 462 Destination Unreachable . . . . . . . . . . . . 79 15.4.12. 460 Only Aggregate Operation Allowed . . . . . . . . 79
15.4.15. 463 Destination Prohibited . . . . . . . . . . . . . 79 15.4.13. 461 Unsupported Transport . . . . . . . . . . . . . 80
15.4.16. 464 Data Transport Not Ready Yet . . . . . . . . . . 79 15.4.14. 462 Destination Unreachable . . . . . . . . . . . . 80
15.4.17. 470 Connection Authorization Required . . . . . . . 79 15.4.15. 463 Destination Prohibited . . . . . . . . . . . . . 80
15.4.18. 471 Connection Credentials not accepted . . . . . . 79 15.4.16. 464 Data Transport Not Ready Yet . . . . . . . . . . 80
15.4.19. 472 Failure to establish secure connection . . . . . 80 15.4.17. 470 Connection Authorization Required . . . . . . . 80
15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 80 15.4.18. 471 Connection Credentials not accepted . . . . . . 80
15.5.1. 551 Option not supported . . . . . . . . . . . . . . 80 15.4.19. 472 Failure to establish secure connection . . . . . 81
16. Header Field Definitions . . . . . . . . . . . . . . . . . . 81 15.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 81
16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 90 15.5.1. 551 Option not supported . . . . . . . . . . . . . . 81
16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 90 16. Header Field Definitions . . . . . . . . . . . . . . . . . . 82
16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 91 16.1. Accept . . . . . . . . . . . . . . . . . . . . . . . . . 91
16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 91 16.2. Accept-Credentials . . . . . . . . . . . . . . . . . . . 91
16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 91 16.3. Accept-Encoding . . . . . . . . . . . . . . . . . . . . 92
16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 91 16.4. Accept-Language . . . . . . . . . . . . . . . . . . . . 92
16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 92 16.5. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . 92
16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 92 16.6. Allow . . . . . . . . . . . . . . . . . . . . . . . . . 92
16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 92 16.7. Authorization . . . . . . . . . . . . . . . . . . . . . 93
16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 92 16.8. Bandwidth . . . . . . . . . . . . . . . . . . . . . . . 93
16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 95 16.9. Blocksize . . . . . . . . . . . . . . . . . . . . . . . 93
16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 95 16.10. Cache-Control . . . . . . . . . . . . . . . . . . . . . 93
16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 96 16.11. Connection . . . . . . . . . . . . . . . . . . . . . . . 96
16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 96 16.12. Connection-Credentials . . . . . . . . . . . . . . . . . 96
16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 96 16.13. Content-Base . . . . . . . . . . . . . . . . . . . . . . 97
16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 96 16.14. Content-Encoding . . . . . . . . . . . . . . . . . . . . 97
16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 97 16.15. Content-Language . . . . . . . . . . . . . . . . . . . . 97
16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 97 16.16. Content-Length . . . . . . . . . . . . . . . . . . . . . 97
16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 97 16.17. Content-Location . . . . . . . . . . . . . . . . . . . . 98
16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 97 16.18. Content-Type . . . . . . . . . . . . . . . . . . . . . . 98
16.21. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 97 16.19. CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . 98
16.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 98 16.20. Date . . . . . . . . . . . . . . . . . . . . . . . . . . 98
16.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 99 16.21. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . 98
16.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 99 16.22. Expires . . . . . . . . . . . . . . . . . . . . . . . . 99
16.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 99 16.23. From . . . . . . . . . . . . . . . . . . . . . . . . . . 100
16.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 100 16.24. If-Match . . . . . . . . . . . . . . . . . . . . . . . . 100
16.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 100 16.25. If-Modified-Since . . . . . . . . . . . . . . . . . . . 100
16.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 100 16.26. If-None-Match . . . . . . . . . . . . . . . . . . . . . 101
16.29. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 100 16.27. Last-Modified . . . . . . . . . . . . . . . . . . . . . 101
16.30. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 101 16.28. Location . . . . . . . . . . . . . . . . . . . . . . . . 101
16.31. Proxy-Authorization . . . . . . . . . . . . . . . . . . 101 16.29. Pipelined-Requests . . . . . . . . . . . . . . . . . . . 101
16.32. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 101 16.30. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . 102
16.33. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 102 16.31. Proxy-Authorization . . . . . . . . . . . . . . . . . . 102
16.32. Proxy-Require . . . . . . . . . . . . . . . . . . . . . 102
16.33. Proxy-Supported . . . . . . . . . . . . . . . . . . . . 103
16.34. Public . . . . . . . . . . . . . . . . . . . . . . . . . 103 16.34. Public . . . . . . . . . . . . . . . . . . . . . . . . . 103
16.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 103 16.35. Range . . . . . . . . . . . . . . . . . . . . . . . . . 104
16.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 105 16.36. Referer . . . . . . . . . . . . . . . . . . . . . . . . 106
16.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 105 16.37. Retry-After . . . . . . . . . . . . . . . . . . . . . . 106
16.38. Require . . . . . . . . . . . . . . . . . . . . . . . . 105 16.38. Require . . . . . . . . . . . . . . . . . . . . . . . . 106
16.39. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 106 16.39. RTP-Info . . . . . . . . . . . . . . . . . . . . . . . . 107
16.40. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 108 16.40. Scale . . . . . . . . . . . . . . . . . . . . . . . . . 109
16.41. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 109 16.41. Speed . . . . . . . . . . . . . . . . . . . . . . . . . 109
16.42. Server . . . . . . . . . . . . . . . . . . . . . . . . . 110 16.42. Server . . . . . . . . . . . . . . . . . . . . . . . . . 110
16.43. Session . . . . . . . . . . . . . . . . . . . . . . . . 110 16.43. Session . . . . . . . . . . . . . . . . . . . . . . . . 110
16.44. Supported . . . . . . . . . . . . . . . . . . . . . . . 111 16.44. Supported . . . . . . . . . . . . . . . . . . . . . . . 111
16.45. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 112 16.45. Timestamp . . . . . . . . . . . . . . . . . . . . . . . 111
16.46. Transport . . . . . . . . . . . . . . . . . . . . . . . 112 16.46. Transport . . . . . . . . . . . . . . . . . . . . . . . 112
16.47. Unsupported . . . . . . . . . . . . . . . . . . . . . . 118 16.47. Unsupported . . . . . . . . . . . . . . . . . . . . . . 117
16.48. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 118 16.48. User-Agent . . . . . . . . . . . . . . . . . . . . . . . 118
16.49. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 118 16.49. Vary . . . . . . . . . . . . . . . . . . . . . . . . . . 118
16.50. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 118 16.50. Via . . . . . . . . . . . . . . . . . . . . . . . . . . 118
16.51. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 119 16.51. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . 118
17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 17. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 18. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
19. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 123 19. Security Framework . . . . . . . . . . . . . . . . . . . . . 122
19.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 123 19.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 122
19.2. Media on Demand using Pipelining . . . . . . . . . . . . 126 19.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 122
19.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 128 19.3. Security and Proxies . . . . . . . . . . . . . . . . . . 123
19.4. Single Stream Container Files . . . . . . . . . . . . . 131 19.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 124
19.5. Live Media Presentation Using Multicast . . . . . . . . 133 19.3.2. User approved TLS procedure . . . . . . . . . . . . 125
19.6. Capability Negotiation . . . . . . . . . . . . . . . . . 135 20. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
20. Security Framework . . . . . . . . . . . . . . . . . . . . . 137 20.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 127
20.1. RTSP and HTTP Authentication . . . . . . . . . . . . . . 137 20.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 129
20.2. RTSP over TLS . . . . . . . . . . . . . . . . . . . . . 137 20.2.1. Generic Protocol elements . . . . . . . . . . . . . 129
20.3. Security and Proxies . . . . . . . . . . . . . . . . . . 138 20.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 132
20.3.1. Accept-Credentials . . . . . . . . . . . . . . . . . 139 20.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 136
20.3.2. User approved TLS procedure . . . . . . . . . . . . 140 20.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 143
21. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 21. Security Considerations . . . . . . . . . . . . . . . . . . . 144
21.1. Base Syntax . . . . . . . . . . . . . . . . . . . . . . 143 21.1. Remote denial of Service Attack . . . . . . . . . . . . 146
21.2. RTSP Protocol Definition . . . . . . . . . . . . . . . . 145 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 148
21.2.1. Generic Protocol elements . . . . . . . . . . . . . 145 22.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 148
21.2.2. Message Syntax . . . . . . . . . . . . . . . . . . . 148 22.1.1. Description . . . . . . . . . . . . . . . . . . . . 148
21.2.3. Header Syntax . . . . . . . . . . . . . . . . . . . 152 22.1.2. Registering New Feature-tags with IANA . . . . . . . 149
21.3. SDP extension Syntax . . . . . . . . . . . . . . . . . . 159 22.1.3. Registered entries . . . . . . . . . . . . . . . . . 149
22. Security Considerations . . . . . . . . . . . . . . . . . . . 160 22.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 149
22.1. Remote denial of Service Attack . . . . . . . . . . . . 162 22.2.1. Description . . . . . . . . . . . . . . . . . . . . 149
23. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 164 22.2.2. Registering New Methods with IANA . . . . . . . . . 149
23.1. Feature-tags . . . . . . . . . . . . . . . . . . . . . . 164 22.2.3. Registered Entries . . . . . . . . . . . . . . . . . 150
23.1.1. Description . . . . . . . . . . . . . . . . . . . . 164 22.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 150
23.1.2. Registering New Feature-tags with IANA . . . . . . . 165 22.3.1. Description . . . . . . . . . . . . . . . . . . . . 150
23.1.3. Registered entries . . . . . . . . . . . . . . . . . 165 22.3.2. Registering New Status Codes with IANA . . . . . . . 150
23.2. RTSP Methods . . . . . . . . . . . . . . . . . . . . . . 165 22.3.3. Registered Entries . . . . . . . . . . . . . . . . . 150
23.2.1. Description . . . . . . . . . . . . . . . . . . . . 165 22.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 150
23.2.2. Registering New Methods with IANA . . . . . . . . . 165 22.4.1. Description . . . . . . . . . . . . . . . . . . . . 150
23.2.3. Registered Entries . . . . . . . . . . . . . . . . . 166 22.4.2. Registering New Headers with IANA . . . . . . . . . 151
23.3. RTSP Status Codes . . . . . . . . . . . . . . . . . . . 166 22.4.3. Registered entries . . . . . . . . . . . . . . . . . 151
23.3.1. Description . . . . . . . . . . . . . . . . . . . . 166 22.5. Transport Header Registries . . . . . . . . . . . . . . 152
23.3.2. Registering New Status Codes with IANA . . . . . . . 166 22.5.1. Transport Protocol Specification . . . . . . . . . . 152
23.3.3. Registered Entries . . . . . . . . . . . . . . . . . 166 22.5.2. Transport modes . . . . . . . . . . . . . . . . . . 153
23.4. RTSP Headers . . . . . . . . . . . . . . . . . . . . . . 166 22.5.3. Transport Parameters . . . . . . . . . . . . . . . . 154
23.4.1. Description . . . . . . . . . . . . . . . . . . . . 166 22.6. Cache Directive Extensions . . . . . . . . . . . . . . . 154
23.4.2. Registering New Headers with IANA . . . . . . . . . 167 22.7. Accept-Credentials . . . . . . . . . . . . . . . . . . . 155
23.4.3. Registered entries . . . . . . . . . . . . . . . . . 167 22.7.1. Accept-Credentials policies . . . . . . . . . . . . 155
23.5. Transport Header Registries . . . . . . . . . . . . . . 168 22.7.2. Accept-Credentials hash algorithms . . . . . . . . . 155
23.5.1. Transport Protocol Specification . . . . . . . . . . 168 22.8. Range header formats . . . . . . . . . . . . . . . . . . 156
23.5.2. Transport modes . . . . . . . . . . . . . . . . . . 169 22.9. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 156
23.5.3. Transport Parameters . . . . . . . . . . . . . . . . 170 22.9.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 156
23.6. Cache Directive Extensions . . . . . . . . . . . . . . . 170 22.9.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 157
23.7. Accept-Credentials . . . . . . . . . . . . . . . . . . . 171 22.9.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 158
23.7.1. Accept-Credentials policies . . . . . . . . . . . . 171 22.10. SDP attributes . . . . . . . . . . . . . . . . . . . . . 159
23.7.2. Accept-Credentials hash algorithms . . . . . . . . . 171 23. References . . . . . . . . . . . . . . . . . . . . . . . . . 160
23.8. Range header formats . . . . . . . . . . . . . . . . . . 172 23.1. Normative References . . . . . . . . . . . . . . . . . . 160
23.9. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 172 23.2. Informative References . . . . . . . . . . . . . . . . . 162
23.9.1. The rtsp URI Scheme . . . . . . . . . . . . . . . . 172 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 165
23.9.2. The rtsps URI Scheme . . . . . . . . . . . . . . . . 173 A.1. Media on Demand (Unicast) . . . . . . . . . . . . . . . 165
23.9.3. The rtspu URI Scheme . . . . . . . . . . . . . . . . 174 A.2. Media on Demand using Pipelining . . . . . . . . . . . . 169
23.10. SDP attributes . . . . . . . . . . . . . . . . . . . . . 175 A.3. Media on Demand (Unicast) . . . . . . . . . . . . . . . 171
24. References . . . . . . . . . . . . . . . . . . . . . . . . . 176 A.4. Single Stream Container Files . . . . . . . . . . . . . 175
24.1. Normative References . . . . . . . . . . . . . . . . . . 176 A.5. Live Media Presentation Using Multicast . . . . . . . . 177
24.2. Informative References . . . . . . . . . . . . . . . . . 178 A.6. Capability Negotiation . . . . . . . . . . . . . . . . . 178
Appendix A. RTSP Protocol State Machine . . . . . . . . . . . . 181 Appendix B. RTSP Protocol State Machine . . . . . . . . . . . . 180
A.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 181 B.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 180
A.2. State variables . . . . . . . . . . . . . . . . . . . . 181 B.2. State variables . . . . . . . . . . . . . . . . . . . . 180
A.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 181 B.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . 180
A.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 182 B.4. State Tables . . . . . . . . . . . . . . . . . . . . . . 181
Appendix B. Media Transport Alternatives . . . . . . . . . . . . 187 Appendix C. Media Transport Alternatives . . . . . . . . . . . . 186
B.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 187 C.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 186
B.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 187 C.1.1. AVP . . . . . . . . . . . . . . . . . . . . . . . . 186
B.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 187 C.1.2. AVP/UDP . . . . . . . . . . . . . . . . . . . . . . 186
B.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 188 C.1.3. AVPF/UDP . . . . . . . . . . . . . . . . . . . . . . 187
B.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 189 C.1.4. SAVP/UDP . . . . . . . . . . . . . . . . . . . . . . 188
B.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 189 C.1.5. SAVPF/UDP . . . . . . . . . . . . . . . . . . . . . 188
B.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 189 C.1.6. RTCP usage with RTSP . . . . . . . . . . . . . . . . 188
B.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 190 C.2. RTP over TCP . . . . . . . . . . . . . . . . . . . . . . 189
B.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 190 C.2.1. Interleaved RTP over TCP . . . . . . . . . . . . . . 189
B.2.2. RTP over independent TCP . . . . . . . . . . . . . . 190 C.2.2. RTP over independent TCP . . . . . . . . . . . . . . 189
B.2.3. Handling NPT Jumps in the RTP Media Layer . . . . . 194 C.2.3. Handling NPT Jumps in the RTP Media Layer . . . . . 193
B.2.4. Handling RTP Timestamps after PAUSE . . . . . . . . 197 C.2.4. Handling RTP Timestamps after PAUSE . . . . . . . . 196
B.2.5. RTSP / RTP Integration . . . . . . . . . . . . . . . 199 C.2.5. RTSP / RTP Integration . . . . . . . . . . . . . . . 198
B.2.6. Scaling with RTP . . . . . . . . . . . . . . . . . . 199 C.2.6. Scaling with RTP . . . . . . . . . . . . . . . . . . 198
B.2.7. Maintaining NPT synchronization with RTP C.2.7. Maintaining NPT synchronization with RTP
timestamps . . . . . . . . . . . . . . . . . . . . . 199 timestamps . . . . . . . . . . . . . . . . . . . . . 198
B.2.8. Continuous Audio . . . . . . . . . . . . . . . . . . 199 C.2.8. Continuous Audio . . . . . . . . . . . . . . . . . . 198
B.2.9. Multiple Sources in an RTP Session . . . . . . . . . 199 C.2.9. Multiple Sources in an RTP Session . . . . . . . . . 198
B.2.10. Usage of SSRCs and the RTCP BYE Message During an C.2.10. Usage of SSRCs and the RTCP BYE Message During an
RTSP Session . . . . . . . . . . . . . . . . . . . . 199 RTSP Session . . . . . . . . . . . . . . . . . . . . 198
B.3. Future Additions . . . . . . . . . . . . . . . . . . . . 200 C.3. Future Additions . . . . . . . . . . . . . . . . . . . . 199
Appendix C. Use of SDP for RTSP Session Descriptions . . . . . . 201 Appendix D. Use of SDP for RTSP Session Descriptions . . . . . . 200
C.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 201 D.1. Definitions . . . . . . . . . . . . . . . . . . . . . . 200
C.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 201 D.1.1. Control URI . . . . . . . . . . . . . . . . . . . . 200
C.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 202 D.1.2. Media Streams . . . . . . . . . . . . . . . . . . . 201
C.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 203 D.1.3. Payload Type(s) . . . . . . . . . . . . . . . . . . 202
C.1.4. Format-Specific Parameters . . . . . . . . . . . . . 203 D.1.4. Format-Specific Parameters . . . . . . . . . . . . . 202
C.1.5. Directionality of media stream . . . . . . . . . . . 203 D.1.5. Directionality of media stream . . . . . . . . . . . 202
C.1.6. Range of Presentation . . . . . . . . . . . . . . . 204 D.1.6. Range of Presentation . . . . . . . . . . . . . . . 203
C.1.7. Time of Availability . . . . . . . . . . . . . . . . 205 D.1.7. Time of Availability . . . . . . . . . . . . . . . . 204
C.1.8. Connection Information . . . . . . . . . . . . . . . 205 D.1.8. Connection Information . . . . . . . . . . . . . . . 204
C.1.9. Entity Tag . . . . . . . . . . . . . . . . . . . . . 205 D.1.9. Entity Tag . . . . . . . . . . . . . . . . . . . . . 204
C.2. Aggregate Control Not Available . . . . . . . . . . . . 206 D.2. Aggregate Control Not Available . . . . . . . . . . . . 205
C.3. Aggregate Control Available . . . . . . . . . . . . . . 206 D.3. Aggregate Control Available . . . . . . . . . . . . . . 205
C.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 207 D.4. RTSP external SDP delivery . . . . . . . . . . . . . . . 206
Appendix D. Minimal RTSP Implementation . . . . . . . . . . . . 209 Appendix E. Minimal RTSP Implementation . . . . . . . . . . . . 208
D.1. Minimal Core Implementation . . . . . . . . . . . . . . 209 E.1. Minimal Core Implementation . . . . . . . . . . . . . . 208
D.2. Recommended Core Implementation . . . . . . . . . . . . 209 E.2. Recommended Core Implementation . . . . . . . . . . . . 208
D.3. The Basic Playback Feature Support . . . . . . . . . . . 210 E.3. The Basic Playback Feature Support . . . . . . . . . . . 209
D.3.1. Client . . . . . . . . . . . . . . . . . . . . . . . 210 E.3.1. Client . . . . . . . . . . . . . . . . . . . . . . . 209
D.3.2. Server . . . . . . . . . . . . . . . . . . . . . . . 210 E.3.2. Server . . . . . . . . . . . . . . . . . . . . . . . 209
D.3.3. Proxy . . . . . . . . . . . . . . . . . . . . . . . 211 E.3.3. Proxy . . . . . . . . . . . . . . . . . . . . . . . 210
D.4. Secure Transport . . . . . . . . . . . . . . . . . . . . 211 E.4. Secure Transport . . . . . . . . . . . . . . . . . . . . 210
Appendix E. Requirements for Unreliable Transport of RTSP . . . 212 Appendix F. Requirements for Unreliable Transport of RTSP . . . 211
Appendix F. Backwards Compatibility Considerations . . . . . . . 214 Appendix G. Backwards Compatibility Considerations . . . . . . . 213
F.1. Play Request in Play mode . . . . . . . . . . . . . . . 214 G.1. Play Request in Play mode . . . . . . . . . . . . . . . 213
F.2. Using Persistent Connections . . . . . . . . . . . . . . 214 G.2. Using Persistent Connections . . . . . . . . . . . . . . 213
Appendix G. Open Issues . . . . . . . . . . . . . . . . . . . . 215 Appendix H. Open Issues . . . . . . . . . . . . . . . . . . . . 214
Appendix H. Changes . . . . . . . . . . . . . . . . . . . . . . 217 Appendix I. Changes . . . . . . . . . . . . . . . . . . . . . . 216
H.1. Changes needing to be updated . . . . . . . . . . . . . 222 I.1. Changes needing to be updated . . . . . . . . . . . . . 221
Appendix I. Acknowledgements . . . . . . . . . . . . . . . . . . 224 Appendix J. Acknowledgements . . . . . . . . . . . . . . . . . . 223
I.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 224 J.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 223
Appendix J. RFC Editor Consideration . . . . . . . . . . . . . . 226 Appendix K. RFC Editor Consideration . . . . . . . . . . . . . . 225
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 227 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 226
Intellectual Property and Copyright Statements . . . . . . . . . 228 Intellectual Property and Copyright Statements . . . . . . . . . 227
1. Introduction 1. Introduction
1.1. Scope and Background 1.1. Scope and Background
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) which is an application-level protocol for control over (RTSP 2.0) which is an application-level protocol for control over
the delivery of data with real-time properties, typically streaming the delivery of data with real-time properties, typically streaming
media. Streaming media is, for instance, video on demand or audio media. Streaming media is, for instance, video on demand or audio
life streaming. Put simply, RTSP acts as a "network remote control" life streaming. Put simply, RTSP acts as a "network remote control"
skipping to change at page 8, line 40 skipping to change at page 8, line 40
There is no notion of an RTSP connection in the protocol. Instead, There is no notion of an RTSP connection in the protocol. Instead,
an RTSP server maintains a session labeled by an identifier to an RTSP server maintains a session labeled by an identifier to
associate groups of media streams and their states. An RTSP session associate groups of media streams and their states. An RTSP session
is not tied to a transport-level connection such as a TCP connection. is not tied to a transport-level connection such as a TCP connection.
During a session, a client may open and close multiple reliable During a session, a client may open and close multiple reliable
transport connections to the server to issue RTSP requests for that transport connections to the server to issue RTSP requests for that
session. session.
The set of streams to be controlled in an RTSP session is defined by The set of streams to be controlled in an RTSP session is defined by
a presentation description. This memorandum does not define a format a presentation description. This memorandum does not define a format
for the presentation description. However Appendix C describes how for the presentation description. However Appendix D describes how
SDP [RFC4566] is used for this purpose. The streams controlled by SDP [RFC4566] is used for this purpose. The streams controlled by
RTSP may use RTP [RFC3550] for their data transport, but the RTSP may use RTP [RFC3550] for their data transport, but the
operation of RTSP does not depend on the transport mechanism used to operation of RTSP does not depend on the transport mechanism used to
carry continuous media. RTSP is intentionally similar in syntax and carry continuous media. RTSP is intentionally similar in syntax and
operation to HTTP/1.1 [RFC2616] so that extension mechanisms to HTTP operation to HTTP/1.1 [RFC2616] so that extension mechanisms to HTTP
can in most cases also be applied to RTSP. However, RTSP differs in can in most cases also be applied to RTSP.
a number of important aspects from HTTP:
* RTSP introduces a number of new methods and has a different
protocol identifier.
* RTSP has the notion of a session built into the protocol.
* An RTSP server needs to maintain state in almost all cases, as
opposed to the stateless nature of HTTP.
* Both an RTSP server and client can issue requests.
* Data is usually carried out-of-band by a different protocol.
Session descriptions returned in a DESCRIBE response (see
Section 13.2) and interleaving of RTP with RTSP over TCP are
exceptions to this rule (see Section 14).
* RTSP is defined to use ISO 10646 (UTF-8) rather than ISO
8859-1, consistent with HTML internationalization efforts
[RFC2070].
* The Request-URI always contains the absolute URI. Because of
backward compatibility with a historical blunder, HTTP/1.1
[RFC2616] carries only the absolute path in the request and
puts the host name in a separate header field.
This makes "virtual hosting" easier, where a single host with
one IP address hosts several document trees.
The protocol supports the following operations: The RTSP 2.0 protocol supports the following operations:
Retrieval of media from media server: The client can either request Retrieval of media from media server: The client can either request
a presentation description via RTSP DESCRIBE, HTTP or some a presentation description via RTSP DESCRIBE, HTTP or some
other method. If the presentation is being multicast, the other method. If the presentation is being multicast, the
presentation description contains the multicast addresses and presentation description contains the multicast addresses and
ports to be used for the continuous media. If the presentation ports to be used for the continuous media. If the presentation
is to be sent only to the client via unicast, the client is to be sent only to the client via unicast, the client
provides the destination. provides the destination.
Invitation of a media server to a conference: A media server can be Invitation of a media server to a conference: A media server can be
skipping to change at page 10, line 8 skipping to change at page 9, line 32
HTTP/1.1 [RFC2616]. HTTP/1.1 [RFC2616].
1.2. RTSP Specificication Update 1.2. RTSP Specificication Update
This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0, a This memorandum specifies RTSP 2.0 which is an update of RTSP 1.0, a
proposed standard defined in [RFC2326]. The goal of this version is proposed standard defined in [RFC2326]. The goal of this version is
to correct the many flaws that have been identified in RTSP 1.0 since to correct the many flaws that have been identified in RTSP 1.0 since
its publication. The corrections are such that backwards its publication. The corrections are such that backwards
compatibility was impossible. Thus a new version was deemed the most compatibility was impossible. Thus a new version was deemed the most
appropriate solution to get a more functional protocol. There are no appropriate solution to get a more functional protocol. There are no
plans to revise RTSP 1.0. Appendix H catalogs the changes of this plans to revise RTSP 1.0. Appendix I catalogs the changes of this
version in relation to RTSP 1.0. version in relation to RTSP 1.0.
RTSP 2.0 has reduced functionality compared to RTSP 1.0 and aims at RTSP 2.0 has reduced functionality compared to RTSP 1.0 and aims at
specifying the RTSP core, functionality and rules for extensions, and specifying the RTSP core, functionality and rules for extensions, and
basic interaction with the media delivery protocol RTP [RFC3550]. basic interaction with the media delivery protocol RTP [RFC3550].
Any other functionality would need to be published as extension Any other functionality would need to be published as extension
documents. This specification provides rules for such extensions and documents. This specification provides rules for such extensions and
defines registries to avoid naming collisions. defines registries to avoid naming collisions.
skipping to change at page 12, line 35 skipping to change at page 12, line 7
Media server indirection: Redirection of a media client to a Media server indirection: Redirection of a media client to a
different media server. different media server.
(Media) stream: A single media instance, e.g., an audio stream or a (Media) stream: A single media instance, e.g., an audio stream or a
video stream as well as a single whiteboard or shared application video stream as well as a single whiteboard or shared application
group. When using RTP, a stream consists of all RTP and RTCP group. When using RTP, a stream consists of all RTP and RTCP
packets created by a source within an RTP session. packets created by a source within an RTP session.
Message: The basic unit of RTSP communication, consisting of a Message: The basic unit of RTSP communication, consisting of a
structured sequence of octets matching the syntax defined in structured sequence of octets matching the syntax defined in
Section 21 and transmitted over a connection or a connectionless Section 20 and transmitted over a connection or a connectionless
transport. transport.
Non-Aggregated Control: Control of a single media stream. This is Non-Aggregated Control: Control of a single media stream. This is
only possible in RTSP sessions with a single media. only possible in RTSP sessions with a single media.
Participant: Member of a conference. A participant may be a Participant: Member of a conference. A participant may be a
machine, e.g., a playback server. machine, e.g., a playback server.
Presentation: A set of one or more streams presented to the client Presentation: A set of one or more streams presented to the client
as a complete media feed and described by a presentation as a complete media feed and described by a presentation
skipping to change at page 16, line 30 skipping to change at page 15, line 30
HTTP since controlling continuous media requires server state in HTTP since controlling continuous media requires server state in
most cases. most cases.
Appropriate server control: If a client can start a stream, it needs Appropriate server control: If a client can start a stream, it needs
to be able to stop a stream. Servers should not start streaming to be able to stop a stream. Servers should not start streaming
to clients in such a way that clients cannot stop the stream. to clients in such a way that clients cannot stop the stream.
Transport negotiation: The client can negotiate the transport method Transport negotiation: The client can negotiate the transport method
prior to actually needing to process a continuous media stream. prior to actually needing to process a continuous media stream.
2.2. Extending RTSP 2.2. RTSP's Relationship to HTTP
RTSP is intentionally similar in syntax and operation to HTTP/1.1
[RFC2616] so that extension mechanisms to HTTP can in most cases also
be applied to RTSP. However, RTSP differs in a number of important
aspects from HTTP:
* RTSP introduces a number of new methods and has a different
protocol identifier.
* RTSP has the notion of a session built into the protocol.
* An RTSP server needs to maintain state in almost all cases, as
opposed to the stateless nature of HTTP.
* Both an RTSP server and client can issue requests.
* Data is usually carried out-of-band by a different protocol.
Session descriptions returned in a DESCRIBE response (see
Section 13.2) and interleaving of RTP with RTSP over TCP are
exceptions to this rule (see Section 14).
* RTSP is defined to use ISO 10646 (UTF-8) rather than ISO
8859-1, consistent with HTML internationalization efforts
[RFC2070].
* The Request-URI always contains the absolute URI. Because of
backward compatibility with a historical blunder, HTTP/1.1
[RFC2616] carries only the absolute path in the request and
puts the host name in a separate header field.
This makes "virtual hosting" easier, where a single host with
one IP address hosts several document trees.
2.3. Extending RTSP
Since not all media servers have the same functionality, media Since not all media servers have the same functionality, media
servers by necessity will support different sets of requests. For servers by necessity will support different sets of requests. For
example: example:
o A server may not be capable of seeking (absolute positioning) if o A server may not be capable of seeking (absolute positioning) if
it is to support live events only. it is to support live events only.
o Some servers may not support setting stream parameters and thus o Some servers may not support setting stream parameters and thus
not support GET_PARAMETER and SET_PARAMETER. not support GET_PARAMETER and SET_PARAMETER.
skipping to change at page 17, line 29 skipping to change at page 17, line 15
o A new version of the protocol can be defined, allowing almost all o A new version of the protocol can be defined, allowing almost all
aspects (except the position of the protocol version number) to aspects (except the position of the protocol version number) to
change. A new version of the protocol MUST be registered through change. A new version of the protocol MUST be registered through
an IETF standard track document. an IETF standard track document.
The basic capability discovery mechanism can be used to both discover The basic capability discovery mechanism can be used to both discover
support for a certain feature and to ensure that a feature is support for a certain feature and to ensure that a feature is
available when performing a request. For detailed explanation of available when performing a request. For detailed explanation of
this see Section 11. this see Section 11.
2.3. Overall Operation 2.4. Overall Operation
Each presentation and media stream is identified by an RTSP URI. The Each presentation and media stream is identified by an RTSP URI. The
overall presentation and the properties of the media the presentation overall presentation and the properties of the media the presentation
is composed of are defined by a presentation description file, the is composed of are defined by a presentation description file, the
format of which is outside the scope of this specification. The format of which is outside the scope of this specification. The
presentation description file may be obtained by the client using presentation description file may be obtained by the client using
HTTP or other means such as email and may not necessarily be stored HTTP or other means such as email and may not necessarily be stored
on the media server. on the media server.
For the purposes of this specification, a presentation description is For the purposes of this specification, a presentation description is
skipping to change at page 18, line 28 skipping to change at page 18, line 15
Multicast, server chooses address: The media server picks the Multicast, server chooses address: The media server picks the
multicast address and port. This is the typical case for a live multicast address and port. This is the typical case for a live
or near-media-on-demand transmission. or near-media-on-demand transmission.
Multicast, client chooses address: If the server is to participate Multicast, client chooses address: If the server is to participate
in an existing multicast conference, the multicast address, port in an existing multicast conference, the multicast address, port
and encryption key are given by the conference description, and encryption key are given by the conference description,
established by means outside the scope of this specification, for established by means outside the scope of this specification, for
example by a SIP created conference. example by a SIP created conference.
2.4. RTSP States 2.5. RTSP States
RTSP controls a stream which may be sent via a separate protocol, RTSP controls a stream which may be sent via a separate protocol,
independent of the control channel. For example, RTSP control may be independent of the control channel. For example, RTSP control may be
transported on a TCP connection while the media data is conveyed via transported on a TCP connection while the media data is conveyed via
UDP. Thus, data delivery continues even if no RTSP requests are UDP. Thus, data delivery continues even if no RTSP requests are
received by the media server. Also, during its lifetime a single received by the media server. Also, during its lifetime a single
media stream may be controlled by RTSP requests issued sequentially media stream may be controlled by RTSP requests issued sequentially
on different TCP connections. Therefore, the server needs to on different TCP connections. Therefore, the server needs to
maintain "session state" to be able to correlate RTSP requests with a maintain "session state" to be able to correlate RTSP requests with a
stream. The state transitions are described in Appendix A. stream. The state transitions are described in Appendix A.
skipping to change at page 19, line 18 skipping to change at page 19, line 5
or location or location
TEARDOWN: Frees resources associated with the stream. The RTSP TEARDOWN: Frees resources associated with the stream. The RTSP
session ceases to exist on the server. session ceases to exist on the server.
RTSP methods that contribute to state use the Session header field RTSP methods that contribute to state use the Session header field
(Section 16.44) to identify the RTSP session whose state is being (Section 16.44) to identify the RTSP session whose state is being
manipulated. The server generates session identifiers in response to manipulated. The server generates session identifiers in response to
SETUP requests (Section 13.3). SETUP requests (Section 13.3).
2.5. Relationship with Other Protocols 2.6. Relationship with Other Protocols
RTSP has some overlap in functionality with HTTP. It also may RTSP has some overlap in functionality with HTTP. It also may
interact with HTTP in that the initial contact with streaming content interact with HTTP in that the initial contact with streaming content
will often be made through a web page. The current protocol will often be made through a web page. The current protocol
specification aims to allow different hand-off points between a web specification aims to allow different hand-off points between a web
server and the media server implementing RTSP. For example, the server and the media server implementing RTSP. For example, the
presentation description can be retrieved using HTTP or RTSP, which presentation description can be retrieved using HTTP or RTSP, which
reduces round trips in web-browser-based scenarios, yet also allows reduces round trips in web-browser-based scenarios, yet also allows
for stand alone RTSP servers and clients which do not rely on HTTP at for stand alone RTSP servers and clients which do not rely on HTTP at
all. However, RTSP differs fundamentally from HTTP in that most data all. However, RTSP differs fundamentally from HTTP in that most data
skipping to change at page 26, line 8 skipping to change at page 26, line 8
request relates to; i.e., the media type indicated in Content-Type request relates to; i.e., the media type indicated in Content-Type
header in the response to DESCRIBE. header in the response to DESCRIBE.
The syntax of any URI query string is unspecified and responder The syntax of any URI query string is unspecified and responder
(usually the server) specific. The query is, from the requestor's (usually the server) specific. The query is, from the requestor's
perspective, an opaque string and needs to be handled as such. perspective, an opaque string and needs to be handled as such.
The URI scheme "rtsp" requires that commands are issued via a The URI scheme "rtsp" requires that commands are issued via a
reliable protocol (within the Internet, TCP), while the scheme reliable protocol (within the Internet, TCP), while the scheme
"rtsps" identifies a reliable transport using secure transport (TLS "rtsps" identifies a reliable transport using secure transport (TLS
[RFC4346], see (Section 20). [RFC4346], see (Section 19).
For the scheme "rtsp", if no port number is provided in the authority For the scheme "rtsp", if no port number is provided in the authority
part of the URI port number 554 SHALL be used. For the scheme part of the URI port number 554 SHALL be used. For the scheme
"rtsps", the TCP port 322 is registered and SHALL be assumed. "rtsps", the TCP port 322 is registered and SHALL be assumed.
A presentation or a stream is identified by a textual media A presentation or a stream is identified by a textual media
identifier, using the character set and escape conventions of URIs identifier, using the character set and escape conventions of URIs
(RFC 3986 [RFC3986]). URIs may refer to a stream or an aggregate of [RFC3986]. URIs may refer to a stream or an aggregate of streams;
streams; i.e., a presentation. Accordingly, requests described in i.e., a presentation. Accordingly, requests described in
(Section 13) can apply to either the whole presentation or an (Section 13) can apply to either the whole presentation or an
individual stream within the presentation. Note that some request individual stream within the presentation. Note that some request
methods can only be applied to streams, not presentations, and vice methods can only be applied to streams, not presentations, and vice
versa. versa.
For example, the RTSP URI: For example, the RTSP URI:
rtsp://media.example.com:554/twister/audiotrack rtsp://media.example.com:554/twister/audiotrack
may identify the audio stream within the presentation "twister", may identify the audio stream within the presentation "twister",
skipping to change at page 27, line 7 skipping to change at page 27, line 7
The path components of the RTSP URI are opaque to the client and do The path components of the RTSP URI are opaque to the client and do
not imply any particular file system structure for the server. not imply any particular file system structure for the server.
This decoupling also allows presentation descriptions to be used This decoupling also allows presentation descriptions to be used
with non-RTSP media control protocols simply by replacing the with non-RTSP media control protocols simply by replacing the
scheme in the URI. scheme in the URI.
4.3. Session Identifiers 4.3. Session Identifiers
Session identifiers are strings of any arbitrary length. A session Session identifiers are strings of any arbitrary length but with a
identifier MUST be chosen cryptographically random (See [RFC4086] ) minimum length of 8 characters. A session identifier MUST be chosen
and MUST be at least eight characters (can contain a maximum of 48 cryptographically random (see [RFC4086]) and MUST be at least 8
bits of entropy) long to make guessing it more difficult. It is characters long (can contain a maximum of 48 bits of entropy) to make
RECOMMENDED that it contains 128 bits of entropy, i.e. approxamitely guessing it more difficult. It is RECOMMENDED that it contains 128
22 characters from a high quality generator. (See Section 22.) bits of entropy, i.e. approxamitely 22 characters from a high quality
However, it needs to be noted that the session identifier does not generator. (see Section 21.) However, it needs to be noted that the
provide any security against session hijacking unless it is kept session identifier does not provide any security against session
confidential between client, server and trusted proxies. hijacking unless it is kept confidential between client, server and
trusted proxies.
4.4. SMPTE Relative Timestamps 4.4. SMPTE Relative Timestamps
A SMPTE relative timestamp expresses time relative to the start of A SMPTE relative timestamp expresses time relative to the start of
the clip. Relative timestamps are expressed as SMPTE time codes for the clip. Relative timestamps are expressed as SMPTE time codes for
frame-level access accuracy. The time code has the format frame-level access accuracy. The time code has the format
hours:minutes:seconds:frames.subframes, hours:minutes:seconds:frames.subframes,
with the origin at the start of the clip. The default smpte format with the origin at the start of the clip. The default smpte format
skipping to change at page 28, line 42 skipping to change at page 28, line 44
using UTC (GMT). Fractions of a second may be indicated. using UTC (GMT). Fractions of a second may be indicated.
Example for November 8, 1996 at 14h37 and 20 and a quarter seconds Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
UTC: UTC:
19961108T143720.25Z 19961108T143720.25Z
4.7. Feature-tags 4.7. Feature-tags
Feature-tags are unique identifiers used to designate features in Feature-tags are unique identifiers used to designate features in
RTSP. These tags are used in Require ( (Section 16.38)), Proxy- RTSP. These tags are used in Require (Section 16.38), Proxy-Require
Require (Section 16.32), Proxy-Supported ( (Section 16.33)), (Section 16.32), Proxy-Supported (Section 16.33), Unsupported
Unsupported ( (Section 16.47)), and header fields. (Section 16.47), and header fields.
A feature-tag definition MUST indicate which combination of clients, A feature-tag definition MUST indicate which combination of clients,
servers or proxies they applies to. servers or proxies they applies to.
The creator of a new RTSP feature-tag should either prefix the The creator of a new RTSP feature-tag should either prefix the
feature-tag with a reverse domain name (e.g., feature-tag with a reverse domain name (e.g.,
"com.example.mynewfeature" is an apt name for a feature whose "com.example.mynewfeature" is an apt name for a feature whose
inventor can be reached at "example.com"), or register the new inventor can be reached at "example.com"), or register the new
feature-tag with the Internet Assigned Numbers Authority (IANA) (see feature-tag with the Internet Assigned Numbers Authority (IANA) (see
IANA Section 23). IANA Section 22).
The usage of feature-tags is further described in Section 11 that The usage of feature-tags is further described in Section 11 that
deals with capability handling. deals with capability handling.
4.8. Entity Tags 4.8. Entity Tags
Entity tags are opaque strings that are used to compare two entities Entity tags are opaque strings that are used to compare two entities
from the same resource, for example in caches or to optimize setup from the same resource, for example in caches or to optimize setup
after a redirect. Further explanation is present in [H3.11]. For an after a redirect. Further explanation is present in [H3.11]. For an
explanation of how to compare entity tags see [H13.3]. Entity tags explanation of how to compare entity tags see [H13.3]. Entity tags
can be carried in the ETag header (see Section 16.21) or in SDP (see can be carried in the ETag header (see Section 16.21) or in SDP (see
Appendix C.1.9). Appendix D.1.9).
Entity tags are used in RTSP to make some methods conditional. The Entity tags are used in RTSP to make some methods conditional. The
methods are made conditional through the inclusion of headers, see methods are made conditional through the inclusion of headers, see
Section 16.24 and Section 16.26. Note that RTSP entity tags apply to Section 16.24 and Section 16.26. Note that RTSP entity tags apply to
the complete presentation; i.e., both the session description and the the complete presentation; i.e., both the session description and the
individual media streams. Thus entity tags can be used to verify at individual media streams. Thus entity tags can be used to verify at
setup time after a redirect that the same session description applies setup time after a redirect that the same session description applies
to the media at the new location using the If-Match header. to the media at the new location using the If-Match header.
5. RTSP Message 5. RTSP Message
skipping to change at page 38, line 40 skipping to change at page 38, line 40
| Code | Reason | Method | | Code | Reason | Method |
+------+----------------------------------------+-----------------+ +------+----------------------------------------+-----------------+
| 100 | Continue | all | | 100 | Continue | all |
| | | | | | | |
| | | | | | | |
| 200 | OK | all | | 200 | OK | all |
| | | | | | | |
| | | | | | | |
| 300 | Multiple Choices | all | | 300 | Multiple Choices | all |
| | | | | | | |
| 301 | Multiple Choices | all |
| | | |
| 301 | Moved Permanently | all | | 301 | Moved Permanently | all |
| | | | | | | |
| 302 | Found | all | | 302 | Found | all |
| | | | | | | |
| 303 | See Other | all | | 303 | See Other | all |
| | | | | | | |
| 305 | Use Proxy | all | | 305 | Use Proxy | all |
| | | | | | | |
| | | | | | | |
| 400 | Bad Request | all | | 400 | Bad Request | all |
| 401 | Unauthorized | all |
| | | | | | | |
| 401 | Unauthorized | all |
| 402 | Payment Required | all | | 402 | Payment Required | all |
| | | | | | | |
| 403 | Forbidden | all | | 403 | Forbidden | all |
| | | | | | | |
| 404 | Not Found | all | | 404 | Not Found | all |
| | | | | | | |
| 405 | Method Not Allowed | all | | 405 | Method Not Allowed | all |
| | | | | | | |
| 406 | Not Acceptable | all | | 406 | Not Acceptable | all |
| | | | | | | |
skipping to change at page 45, line 27 skipping to change at page 45, line 27
RTSP messages in connectionless mode over a transport protocol such RTSP messages in connectionless mode over a transport protocol such
as UDP. However, it was not specified in sufficient detail to allow as UDP. However, it was not specified in sufficient detail to allow
for interoperable implementations. In an attempt to reduce for interoperable implementations. In an attempt to reduce
complexity and scope, and due to lack of interest, RTSP 2.0 does not complexity and scope, and due to lack of interest, RTSP 2.0 does not
attempt to define a mechanism for supporting RTSP over UDP or other attempt to define a mechanism for supporting RTSP over UDP or other
connectionless transport protocols. A side-effect of this is that connectionless transport protocols. A side-effect of this is that
RTSP requests SHALL NOT be sent to multicast groups since no RTSP requests SHALL NOT be sent to multicast groups since no
connection can be established with a specific receiver in multicast connection can be established with a specific receiver in multicast
environments. environments.
Certain RTSP headers, such as the CSeq header Section 16.19), which Certain RTSP headers, such as the CSeq header (Section 16.19), which
may appear to be relevant only to connectionless transport scenarios may appear to be relevant only to connectionless transport scenarios
are still retained and must be implemented according to the are still retained and must be implemented according to the
specification. In the case of CSeq, it is quite useful for matching specification. In the case of CSeq, it is quite useful for matching
responses to requests if the requests are pipelined (see Section 12). responses to requests if the requests are pipelined (see Section 12).
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
skipping to change at page 47, line 48 skipping to change at page 47, line 48
responding to a request with an error code. responding to a request with an error code.
Certain error responses such as "460 Only Aggregate Operation Certain error responses such as "460 Only Aggregate Operation
Allowed" (Section 15.4.12) are used for negotiating capabilities Allowed" (Section 15.4.12) are used for negotiating capabilities
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 22). response poses a Denial of Service security risk (Section 21).
If a server initiates a connection close while the client is If a server closes a connection while the client is attempting to
attempting to send a new request, the client will have to close its send a new request, the client will have to close its current
current connection, establish a new connection and send its request connection, establish a new connection and send its request over the
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.
10.4. Timing Out Connections and RTSP Messages 10.4. Timing Out Connections and RTSP Messages
Receivers of a request (responder) SHOULD respond to requests in a Receivers of a request (responder) SHOULD respond to requests in a
timely manner even when a reliable transport such as TCP is used. timely manner even when a reliable transport such as TCP is used.
skipping to change at page 48, line 41 skipping to change at page 48, line 41
for further responses. If more than 10 seconds elapses without for further responses. If more than 10 seconds elapses without
receiving any response, the requestor MAY assume that the responder receiving any response, the requestor MAY assume that the responder
is unresponsive and abort the connection. is unresponsive and abort the connection.
A requestor SHOULD wait longer than 10 seconds for a response if it A requestor SHOULD wait longer than 10 seconds for a response if it
is experiencing significant transport delays on its connection to the is experiencing significant transport delays on its connection to the
responder. The requestor is capable of determining the RTT of the responder. The requestor is capable of determining the RTT of the
request/response cycle using the Timestamp header (Section 16.45) in request/response cycle using the Timestamp header (Section 16.45) in
any RTSP request. any RTSP request.
10.5. Use of IPv6 10.5. Showing Liveness
The mechanisms for showing liveness of the client is, any RTSP
request with a Session header, if RTP & RTCP is used an RTCP message,
or through any other used media protocol capable of indicating
liveness of the RTSP client. It is RECOMMENDED that a client does
not wait to the last second of the timeout before trying to send a
liveness message. The RTSP message may be lost or when using
reliable protocols, such as TCP, the message may take some time to
arrive safely at the receiver. To show liveness between RTSP request
issued to accomplish other things, the following mechanisms can be
used, in descending order of preference:
RTCP: If RTP is used for media transport RTCP SHOULD be used. If
RTCP is used to report transport statistics, it SHALL also work
as keep alive. The server can determine the client by used
network address and port together with the fact that the client
is reporting on the servers SSRC(s). A downside of using RTCP
is that it only gives statistical guarantees to reach the
server. However that probability is so low that it can be
ignored in most cases. For example, a session with 60 seconds
timeout and enough bitrate assigned to RTCP messages to send a
message from client to server on average every 5 seconds. That
client have for a network with 5 \% packet loss, the
probability to fail showing liveness sign in that session
within the timeout interval of 2.4*E-16. In sessions with
shorter timeout times, or much higher packet loss, or small
RTCP bandwidths SHOULD also use any of the mechanisms below.
SETPARAMETER: When using SETPARAMETER for keep alive, no body SHOULD
be included. This method is the RECOMMENDED RTSP method to use
in request only intended to perform keep-alive.
OPTIONS: This method does also work. However it causes the server
to perform more unnecessary processing and result in bigger
responses than necessary for the task. The reason for this is
that the server needs to determine what capabilities that are
associated with the media resource to correctly populate the
Public and Allow headers.
The timeout parameter MAY be included in a SETUP response, and SHALL
NOT be included in requests. The server uses it to indicate to the
client how long the server is prepared to wait between RTSP commands
or other signs of life before closing the session due to lack of
activity (see below and Appendix B). The timeout is measured in
seconds, with a default of 60 seconds. The length of the session
timeout SHALL NOT be changed in a established session.
10.6. Use of IPv6
Explicit IPv6 support was not present in RTSP 1.0 (RFC 2326). RTSP 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.
11. Capability Handling 11. Capability Handling
This section describes the capability handling mechanism available in This section describes the available capability handling mechanism
RTSP which allows RTSP to be extended. Extensions to this version of which allows RTSP to be extended. Extensions to this version of the
the protocol are basically done in two ways. First, new headers can protocol are basically done in two ways. First, new headers can be
be added. Secondly, new methods can be added. The capability added. Secondly, new methods can be added. The capability handling
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 wether it is supported. This is done by issuing a method to discover wether it is supported. This is done by issuing a
OPTIONS request to the other party. Depending on the URI it will OPTIONS request to the other party. Depending on the URI it will
either apply in regards to a certain media resource, the whole server either apply in regards to a certain media resource, the whole server
in general, or simply the next hop. The OPTIONS response MUST in general, or simply the next hop. The OPTIONS response MUST
contain a Public header which declares all methods supported for the contain a Public header which declares all methods supported for the
indicated resource. indicated resource.
It is not necessary to use OPTIONS to discover support of a method, It is not necessary to use OPTIONS to discover support of a method,
skipping to change at page 51, line 23 skipping to change at page 52, line 23
requests in their sending order. The sending order can be determined requests in their sending order. The sending order can be determined
by the CSeq header and its sequence number. For TCP the delivery by the CSeq header and its sequence number. For TCP the delivery
order will be the same as the sending order. The processing of the order will be the same as the sending order. The processing of the
request SHALL also have been finished before processing the next request SHALL also have been finished before processing the next
request from the same entity. The responses MUST be sent in the request from the same entity. The responses MUST be sent in the
order the requests was processed. order the requests was processed.
RTSP 2.0 has extended support for pipelining compared to RTSP 1.0. RTSP 2.0 has extended support for pipelining compared to RTSP 1.0.
The major improvement is to allow all requests to setup and initiate The major improvement is to allow all requests to setup and initiate
media playback to be pipelined after each other. This is media playback to be pipelined after each other. This is
accomplished by the utilization of the Pipelined-Requests header (See accomplished by the utilization of the Pipelined-Requests header (see
Section 16.29). This header allows a client to request that two or Section 16.29). This header allows a client to request that two or
more requests is to be processed in the same RTSP session context more requests is to be processed in the same RTSP session context
which the first request creates. In other words a client can request which the first request creates. In other words a client can request
that two or more media streams are set-up and then played without that two or more media streams are set-up and then played without
needing to wait for a single response. This speeds up the initial needing to wait for a single response. This speeds up the initial
startup time for an RTSP session with at least one RTT. startup time for an RTSP session with at least one RTT.
When pipelining requests care must be taken. If a pipelined request If a pipelined request builds on the succesful completion of one or
builds on the succesful completion of one or more prior requests the more prior requests the requestor must verify that all requests were
requestor must verify that all requests was executed as expected. O executed as expected. A common example will be two SETUP requests
common example will be two SETUP requests and a PLAY request. In and a PLAY request. In case one of the SETUP fails unexpectedly, the
case one of the SETUP fails unexpectedly, the PLAY request can still PLAY request can still be succesfully executed. However, not as
be succesfully executed. However, not as expected by the requesting expected by the requesting client as only a single media instead of
client as only a single media instead of two will be played. In this two will be played. In this case the client can send a PAUSE
case the client can send a PAUSE request, correct the failing SETUP request, correct the failing SETUP request and then request it to be
request and then request it to be played. 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 SHALL NOT New methods may be defined in the future. Method names SHALL NOT
start with a $ character (decimal 24) and MUST be a token as defined start with a $ character (decimal 24) and MUST be a token as defined
by the ABNF [RFC4234] in the syntax chapter Section 21. The methods by the ABNF [RFC4234] 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 |
| | | | | | | | | | | |
| | S -> C | | | | | | S -> C | | | |
skipping to change at page 52, line 36 skipping to change at page 53, line 36
| | S -> C | | | | | | S -> C | | | |
| | | | | | | | | | | |
| PAUSE | C -> S | P,S | required | required | | PAUSE | C -> S | P,S | required | required |
| | | | | | | | | | | |
| PLAY | C -> S | P,S | required | required | | PLAY | C -> S | P,S | required | required |
| | | | | | | | | | | |
| REDIRECT | S -> C | P,S | optional | required | | REDIRECT | S -> C | P,S | optional | required |
| | | | | | | | | | | |
| SETUP | C -> S | S | required | required | | SETUP | C -> S | S | required | required |
| | | | | | | | | | | |
| SETPARAMETER | C -> S | P,S | required | optional | | SET_PARAMETER | C -> S | P,S | required | optional |
| | | | | | | | | | | |
| | S -> C | | | | | | S -> C | | | |
| | | | | | | | | | | |
| TEARDOWN | C -> S | P,S | required | required | | TEARDOWN | C -> S | P,S | required | required |
+---------------+-----------+--------+--------------+---------------+ +---------------+-----------+--------+--------------+---------------+
Table 7: Overview of RTSP methods, their direction, and what objects Table 7: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Legend: R=Respond, (P: presentation, S: stream) they operate on. Legend: R=Respond,
Sd=Send, Opt: Optional, Req: Required Sd=Send, Opt: Optional, Req: Required
Note on Table 7: GET_PARAMETER is recommended, but not required. Note on Table 7: GET_PARAMETER is recommended, but not required.
For example, a fully functional server can be built to deliver For example, a fully functional server can be built to deliver
media without any parameters. SETPARAMETER is required however media without any parameters. SET_PARAMETER is required however
due to its usage for keep-alive. PAUSE is now required due to due to its usage for keep-alive. PAUSE is now required due to
that it is the only way of getting out of the state machines play that it is the only way of getting out of the state machines play
state without terminating the whole session. state without terminating the whole session.
If an RTSP agent does not support a particular method, it MUST return If an RTSP agent does not support a particular method, it MUST return
501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD 501 (Not Implemented) and the requesting RTSP agent, in turn, SHOULD
NOT try this method again for the given agent / resource combination. NOT try this method again for the given agent / resource combination.
13.1. OPTIONS 13.1. OPTIONS
skipping to change at page 56, line 20 skipping to change at page 57, line 20
act as "helper applications" that accept a media initialization file act as "helper applications" that accept a media initialization file
from a user interface, and/or other means that are appropriate to the from a user interface, and/or other means that are appropriate to the
operating environment of the clients. operating environment of the clients.
13.3. SETUP 13.3. SETUP
The SETUP request for an URI specifies the transport mechanism to be The SETUP request for an URI specifies the transport mechanism to be
used for the streamed media. The SETUP method may be used in three used for the streamed media. The SETUP method may be used in three
different cases; Create an RTSP session, add a media to a session, different cases; Create an RTSP session, add a media to a session,
and change the transport parameters of already set up media stream. and change the transport parameters of already set up media stream.
When in PLAY state, using SETUP to create or add media to a session Using SETUP to add media to an existing session, when the session is
when in PLAY state is unspecified. Otherwise SETUP can be used in in PLAY state, is unspecified. Otherwise SETUP can be used in all
all three states; INIT, and READY, for both purposes and in PLAY to three states; INIT, and READY, for both purposes and in PLAY to
change the transport parameters. change the transport parameters.
The Transport header, see Section 16.46, specifies the transport The Transport header, see Section 16.46, specifies the transport
parameters acceptable to the client for data transmission; the parameters acceptable to the client for data transmission; the
response will contain the transport parameters selected by the response will contain the transport parameters selected by the
server. This allows the client to enumerate in descending order of server. This allows the client to enumerate in descending order of
preference the transport mechanisms and parameters acceptable to it, preference the transport mechanisms and parameters acceptable to it,
while the server can select the most appropriate. It is expected while the server can select the most appropriate. It is expected
that the session description format used will enable the client to that the session description format used will enable the client to
select a limited number possible configurations that are offered to select a limited number possible configurations that are offered to
the server to choose from. All transport related parameters shall be the server to choose from. All transport related parameters shall be
included in the Transport header, the use of other headers for this included in the Transport header, the use of other headers for this
purpose is discouraged due to middle boxes such as firewalls, or purpose is discouraged due to middleboxes, such as firewalls or NATs.
NATs.
For the benefit of any intervening firewalls, a client SHALL indicate For the benefit of any intervening firewalls, a client SHALL indicate
the known transport parameters, even if it has no influence over the known transport parameters, even if it has no influence over
these parameters, for example, where the server advertises a fixed these parameters, for example, where the server advertises a fixed
multicast address as destination. multicast address as destination.
Since SETUP includes all transport initialization information, Since SETUP includes all transport initialization information,
firewalls and other intermediate network devices (which need this firewalls and other intermediate network devices (which need this
information) are spared the more arduous task of parsing the information) are spared the more arduous task of parsing the
DESCRIBE response, which has been reserved for media DESCRIBE response, which has been reserved for media
skipping to change at page 59, line 41 skipping to change at page 60, line 40
13.4. PLAY 13.4. PLAY
The PLAY method tells the server to start sending data via the The PLAY method tells the server to start sending data via the
mechanism specified in SETUP. PLAY requests are valid when the mechanism specified in SETUP. PLAY requests are valid when the
session is in READY or PLAY states. A PLAY request MUST include a session is in READY or PLAY states. A PLAY request MUST include a
Session header to indicate which session the request applies to. Session header to indicate which session the request applies to.
For aggregated sessions where the initial SETUP request (creating a For aggregated sessions where the initial SETUP request (creating a
session) is followed by one or more additional SETUP request, a PLAY session) is followed by one or more additional SETUP request, a PLAY
request MAY be pipelined after those additional SETUP requests request MAY be pipelined after those additional SETUP requests
without awaiting their responses. This can procedure can reduce the without awaiting their responses. This procedure can reduce the
delay from start of session establishment until media play-out has delay from start of session establishment until media play-out has
started with one round trip time. However an client needs to be started with one round trip time. However an client needs to be
aware that using this procedure will result in the playout of the aware that using this procedure will result in the playout of the
server state established at the time of processing the PLAY, i.e. server state established at the time of processing the PLAY, i.e.,
after the processing of all the requests prior to the PLAY request in after the processing of all the requests prior to the PLAY request in
the pipeline. This may not be the intended one due to failure of any the pipeline. This may not be the intended one due to failure of any
of the prior requests. However a client easily determine this based of the prior requests. However a client easily determine this based
on the responses from those requests. In case of failure the client on the responses from those requests. In case of failure the client
can halt the media playout using PAUSE and try to establish the can halt the media playout using PAUSE and try to establish the
intended state again before issuing another PLAY request. intended state again before issuing another PLAY request.
In an aggregated session the PLAY request MUST contain an aggregated In an aggregated session the PLAY request MUST contain an aggregated
control URI. A server SHALL responde with error 460 (Only Aggregate control URI. A server SHALL responde with error 460 (Only Aggregate
Operation Allowed) if the client PLAY Request-URI is for one of the Operation Allowed) if the client PLAY Request-URI is for one of the
skipping to change at page 61, line 20 skipping to change at page 62, line 20
that will be played back, i.e. for which duration any media (having that will be played back, i.e. for which duration any media (having
content at this time) is delivered. This may differ from the content at this time) is delivered. This may differ from the
requested range if alignment of the requested range to valid frame requested range if alignment of the requested range to valid frame
boundaries is required for the media source. Note that some media boundaries is required for the media source. Note that some media
streams in an aggregate may need to be delivered from even earlier streams in an aggregate may need to be delivered from even earlier
points. Also, some media format have a very long duration per points. Also, some media format have a very long duration per
individual data unit, therefore it might be necessary for the client individual data unit, therefore it might be necessary for the client
to parse the data unit, and select where to start. to parse the data unit, and select where to start.
Example: Single audio stream (MIDI) Example: Single audio stream (MIDI)
C->S: PLAY rtsp://example.com/audio RTSP/2.0 C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836 CSeq: 836
Session: 12345678 Session: 12345678
Range: npt=7.05- Range: npt=7.05- 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: 836 CSeq: 836
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=3.52- Range: npt=3.52-
RTP-Info:url="rtsp://example.com/audio" RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545 ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.52 S->C: RTP Packet TS=2345962545 => NPT=3.52
skipping to change at page 65, line 48 skipping to change at page 67, line 22
CSeq: 834 CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=10-30 Range: npt=10-30
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=4FAD8726:seq=57654;rtptime=2792482193 ssrc=4FAD8726:seq=57654;rtptime=2792482193
Session: 12345678 Session: 12345678
after 11 seconds, i.e. at 21 seconds into the presentation: After 11 seconds, i.e. at 21 seconds into the presentation:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0 C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835 CSeq: 835
Session: 12345678 Session: 12345678
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: 835 CSeq: 835
Date: 23 Jan 1997 15:35:09 GMT Date: 23 Jan 1997 15:35:09 GMT
Server: PhonyServer 1.0 Server: PhonyServer 1.0
Range: npt=21-30 Range: npt=21-30
skipping to change at page 67, line 38 skipping to change at page 69, line 24
Server: PhonyServer 1.0 Server: PhonyServer 1.0
13.7. GET_PARAMETER 13.7. GET_PARAMETER
The GET_PARAMETER request retrieves the value of a parameter or The GET_PARAMETER request retrieves the value of a parameter or
parameters for a presentation or stream specified in the URI. If the parameters for a presentation or stream specified in the URI. If the
Session header is present in a request, the value of a parameter MUST Session header is present in a request, the value of a parameter MUST
be retrieved in the specified session context. The content of the be retrieved in the specified session context. The content of the
reply and response is left to the implementation. reply and response is left to the implementation.
The method MAY also be used without a body (entity). If the this The method MAY also be used without a body (entity). If the request
request is successful, i.e. a 200 OK response is received, then the is successful, i.e., a 200 OK response is received, then the keep-
keep-alive timer has been updated. Any non-required header present alive timer has been updated. Any non-required header present in
in such a request may or may not been processed. To allow a client such a request may or may not been processed. To allow a client to
to determine if any such header has been processed, it is necessary determine if any such header has been processed, it is necessary to
to use a feature-tag and the Require header. Due to this reason it use a feature-tag and the Require header. Due to this reason it is
is RECOMMENDED that any parameters to be retrieved are sent in the RECOMMENDED that any parameters to be retrieved are sent in the body,
body, rather than using any header. rather than using any header.
Example: Example:
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0 S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 431 CSeq: 431
Content-Type: text/parameters Content-Type: text/parameters
Session: 12345678 Session: 12345678
Content-Length: 26 Content-Length: 26
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
skipping to change at page 71, line 39 skipping to change at page 73, line 25
would be redirected by the request. This is a safeguard against would be redirected by the request. This is a safeguard against
misbehaving clients that refuses to respond to a REDIRECT request. misbehaving clients that refuses to respond to a REDIRECT request.
That should not provide any benefit. That should not provide any benefit.
After a REDIRECT request has been processed, a client that wants to After a REDIRECT request has been processed, a client that wants to
continue to send or receive media for the resource identified by the continue to send or receive media for the resource identified by the
Request-URI will have to establish a new session with the designated Request-URI will have to establish a new session with the designated
host. If the URI given in the Location header is a valid resource host. If the URI given in the Location header is a valid resource
URI, a client SHOULD issue a DESCRIBE request for the URI. URI, a client SHOULD issue a DESCRIBE request for the URI.
Note: The media resource indicated by the \header {Location header Note: The media resource indicated by the Location header can be
can be identical, slightly different or totally different. This identical, slightly different or totally different. This is the
is the reason why a new DESCRIBE request SHOULD be issued. reason why a new DESCRIBE request SHOULD be issued.
If the Location header contains only a host address, the client MAY If the Location header contains only a host address, the client MAY
assume that the media on the new server is identical to the media on assume that the media on the new server is identical to the media on
the old server, i.e. all media configuration information from the old the old server, i.e. all media configuration information from the old
session is still valid except for the host address. However the session is still valid except for the host address. However the
usage of conditional SETUP using ETag identifiers are RECOMMENDED to usage of conditional SETUP using ETag identifiers are RECOMMENDED to
verify the assumption. verify the assumption.
This example request redirects traffic for this session to the new This example request redirects traffic for this session to the new
server at the given absolute time: server at the given absolute time:
skipping to change at page 75, line 21 skipping to change at page 76, line 21
information about the error. information about the error.
15.1. Success 1xx 15.1. Success 1xx
15.1.1. 100 Continue 15.1.1. 100 Continue
See, [H10.1.1]. See, [H10.1.1].
15.2. Success 2xx 15.2. Success 2xx
15.2.1. 200 OK
See, [H10.2.1].
15.3. Redirection 3xx 15.3. Redirection 3xx
The notation "3rr" indicates response codes from 300 to 399 inclusive The notation "3rr" indicates response codes from 300 to 399 inclusive
which are meant for redirection. The response code 304 is excluded which are meant for redirection. The response code 304 is excluded
from this set, as it is not used for redirection. from this set, as it is not used for redirection.
See [H10.3] for definition of status code 300 to 305. However See [H10.3] for definition of status code 300 to 305. However
comments are given for some to how they apply to RTSP. comments are given for some to how they apply to RTSP.
Within RTSP, redirection may be used for load balancing or Within RTSP, redirection may be used for load balancing or
skipping to change at page 76, line 41 skipping to change at page 77, line 41
Transport: RTP/AVP/TCP;unicast;interleaved=0-1 Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2 User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 302 Try Other Server S->C: RTSP/2.0 302 Try Other Server
CSeq: 2 CSeq: 2
Location: rtsp://s2.example.com:8001/fizzle/foo Location: rtsp://s2.example.com:8001/fizzle/foo
15.3.4. 303 See Other 15.3.4. 303 See Other
This status code SHALL NOT be used in RTSP. However as it was This status code SHALL NOT be used in RTSP. However, it was allowed
allowed to use in RTSP 1.0 (RFC 2326). to use in RTSP 1.0 (RFC 2326).
15.3.5. 304 Not Modified 15.3.5. 304 Not Modified
If the client has performed a conditional DESCRIBE or SETUP (see If the client has performed a conditional DESCRIBE or SETUP (see
Section 16.25) and the requested resource has not been modified, the Section 16.25) and the requested resource has not been modified, the
server SHOULD send a 304 response. This response MUST NOT contain a server SHOULD send a 304 response. This response MUST NOT contain a
message-body. message-body.
The response MUST include the following header fields: The response MUST include the following header fields:
skipping to change at page 81, line 40 skipping to change at page 82, line 40
Table 8: Overview of RTSP methods, their direction, and what objects Table 8: Overview of RTSP methods, their direction, and what objects
(P: presentation, S: stream) they operate on. Body notes if a method (P: presentation, S: stream) they operate on. Body notes if a method
is allowed to carry body and in which direction, R = Request, is allowed to carry body and in which direction, R = Request,
r=response. Note: It is allowed for all error messages 4xx and 5xx to r=response. Note: It is allowed for all error messages 4xx and 5xx to
have a body have a body
The general syntax for header fields is covered in Section 5.2. This The general syntax for header fields is covered in Section 5.2. This
section lists the full set of header fields along with notes on section lists the full set of header fields along with notes on
meaning, and usage. The syntax definition for header fields are meaning, and usage. The syntax definition for header fields are
present in Section 21.2.3. Throughout this section, we use [HX.Y] to present in Section 20.2.3. Throughout this section, we use [HX.Y] to
refer to Section X.Y of the current HTTP/1.1 specification RFC 2616 refer to Section X.Y of the current HTTP/1.1 specification RFC 2616
[RFC2616]. Examples of each header field are given. [RFC2616]. Examples of each header field are given.
Information about header fields in relation to methods and proxy Information about header fields in relation to methods and proxy
processing is summarized in Table 9, Table 10, Table 11, and processing is summarized in Table 9, Table 10, Table 11, and
Table 12. Table 12.
The "where" column describes the request and response types in which The "where" column describes the request and response types in which
the header field can be used. Values in this column are: the header field can be used. Values in this column are:
skipping to change at page 82, line 32 skipping to change at page 83, line 32
a: A proxy can add or concatenate the header field if not present. a: A proxy can add or concatenate the header field if not present.
m: A proxy can modify an existing header field value. m: A proxy can modify an existing header field value.
d: A proxy can delete a header field value. d: A proxy can delete a header field value.
r: A proxy needs to be able to read the header field, and thus r: A proxy needs to be able to read the header field, and thus
this header field cannot be encrypted. this header field cannot be encrypted.
The rest of the columns relate to the presence of a header field in a The rest of the columns relate to the presence of a header field in a
method. The method names when abbreviated, are according to table method. The method names when abbreviated, are according to Table 8:
XXX {tab:methods2:
c: Conditional; requirements on the header field depend on the c: Conditional; requirements on the header field depend on the
context of the message. context of the message.
m: The header field is mandatory. m: The header field is mandatory.
m*: The header field SHOULD be sent, but clients/servers need to be m*: The header field SHOULD be sent, but clients/servers need to be
prepared to receive messages without that header field. prepared to receive messages without that header field.
o: The header field is optional. o: The header field is optional.
skipping to change at page 84, line 4 skipping to change at page 84, line 51
| | | | | | | | | | | | | | | | | | | |
| Accept-Ranges | R | r | - | - | m | - | - | - | | Accept-Ranges | R | r | - | - | m | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Accept-Ranges | r | r | - | - | o | - | - | - | | Accept-Ranges | r | r | - | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Accept-Ranges | 456 | r | - | - | - | o | - | - | | Accept-Ranges | 456 | r | - | - | - | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Allow | r | am | c | c | c | - | - | - | | Allow | r | am | c | c | c | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Allow | 405 | am | m | m | m | m | m | m | | Allow | 405 | am | m | m | m | m | m | m |
| | | | | | | | | |
| Authorization | R | | o | o | o | o | o | o | | Authorization | R | | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
| Bandwidth | R | | o | o | o | o | - | - | | Bandwidth | R | | o | o | o | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Blocksize | R | | o | - | o | o | - | - | | Blocksize | R | | o | - | o | o | - | - |
| | | | | | | | | | | | | | | | | | | |
| Cache-Control | | r | o | - | o | - | - | - | | Cache-Control | | r | o | - | o | - | - | - |
| | | | | | | | | | | | | | | | | | | |
| Connection | | | o | o | o | o | o | o | | Connection | | | o | o | o | o | o | o |
| | | | | | | | | | | | | | | | | | | |
skipping to change at page 90, line 19 skipping to change at page 91, line 19
16.1. Accept 16.1. Accept
The Accept request-header field can be used to specify certain The Accept request-header field can be used to specify certain
presentation description content types which are acceptable for the presentation description content types which are acceptable for the
response. response.
See [H14.1] for syntax. See [H14.1] for syntax.
Example of use: Example of use:
Accept: application/example q=1.0, application/sdp Accept: application/example q=1.0, application/sdp
16.2. Accept-Credentials 16.2. Accept-Credentials
The Accept-Credentials header is a request header used to indicate to The Accept-Credentials header is a request header used to indicate to
any trusted intermediary how to handle further secured connections to any trusted intermediary how to handle further secured connections to
proxies or servers. See Section 20 for the usage of this header. It proxies or servers. See Section 19 for the usage of this header. It
SHALL NOT be included in server to client requests. SHALL NOT be included in server to client requests.
In a request the header SHALL contain the method (User, Proxy, or In a request the header SHALL contain the method (User, Proxy, or
Any) for approving credentials selected by the requestor. The method Any) for approving credentials selected by the requestor. The method
SHALL NOT be changed by any proxy, unless it is "proxy" when a proxy SHALL NOT be changed by any proxy, unless it is "proxy" when a proxy
MAY change it to "user" to take the role of user approving each MAY change it to "user" to take the role of user approving each
further hop. If the method is "User" the header contains zero or further hop. If the method is "User" the header contains zero or
more of credentials that the client accept. The header may contain more of credentials that the client accepts. The header may contain
zero credentials in the first RTSP request to a RTSP server when zero credentials in the first RTSP request to a RTSP server when
using the "User" method. This as the client has not yet received any using the "User" method. This as the client has not yet received any
credentials to accept. Each credential SHALL consist of one URI credentials to accept. Each credential SHALL consist of one URI
identifying the proxy or server, the hash algorithm identifier, and identifying the proxy or server, the hash algorithm identifier, and
the hash over that entity's DER encoded certificate [RFC3280] in the hash over that entity's DER encoded certificate [RFC3280] in
Base64 [RFC4648]. All RTSP clients and proxies SHALL implement the Base64 [RFC4648]. All RTSP clients and proxies SHALL implement the
SHA-256[FIPS-pub-180-2] algorithm for computation of the hash of the SHA-256[FIPS-pub-180-2] algorithm for computation of the hash of the
DER encoded certificate. The SHA-256 algorithm is identified by the DER encoded certificate. The SHA-256 algorithm is identified by the
token "sha-256". token "sha-256".
skipping to change at page 91, line 30 skipping to change at page 92, line 28
16.5. Accept-Ranges 16.5. Accept-Ranges
The Accept-Ranges request and response-header field allows indication The Accept-Ranges request and response-header field allows indication
of the format supported in the Range header. The client SHALL of the format supported in the Range header. The client SHALL
include the header in SETUP requests to indicate which formats it include the header in SETUP requests to indicate which formats it
support to receive in PLAY and PAUSE responses, and REDIRECT support to receive in PLAY and PAUSE responses, and REDIRECT
requests. The server SHALL include the header in SETUP and 456 error requests. The server SHALL include the header in SETUP and 456 error
responses to indicate the formats supported for the resource responses to indicate the formats supported for the resource
indicated by the request URI. indicated by the request URI.
Accept-Ranges: NPT, SMPTE Accept-Ranges: NPT, SMPTE
This header has the same syntax as [H14.5] and the syntax is defined This header has the same syntax as [H14.5] and the syntax is defined
in Section 21.2.3. However, new range-units are defined. in Section 20.2.3. However, new range-units are defined.
16.6. Allow 16.6. Allow
The Allow entity-header field lists the methods supported by the The Allow entity-header field lists the methods supported by the
resource identified by the Request-URI. The purpose of this field is resource identified by the Request-URI. The purpose of this field is
to strictly inform the recipient of valid methods associated with the to strictly inform the recipient of valid methods associated with the
resource. An Allow header field MUST be present in a 405 (Method Not resource. An Allow header field MUST be present in a 405 (Method Not
Allowed) response. See [H14.7] for syntax definition. The Allow Allowed) response. See [H14.7] for syntax definition. The Allow
header MUST also be present in all OPTIONS responses where the header MUST also be present in all OPTIONS responses where the
content of the header will not include exactly the same methods as content of the header will not include exactly the same methods as
skipping to change at page 92, line 48 skipping to change at page 93, line 45
that MUST be obeyed by all caching mechanisms along the request/ that MUST be obeyed by all caching mechanisms along the request/
response chain. response chain.
Cache directives MUST be passed through by a proxy or gateway Cache directives MUST be passed through by a proxy or gateway
application, regardless of their significance to that application, application, regardless of their significance to that application,
since the directives may be applicable to all recipients along the since the directives may be applicable to all recipients along the
request/response chain. It is not possible to specify a cache- request/response chain. It is not possible to specify a cache-
directive for a specific cache. directive for a specific cache.
Cache-Control should only be specified in a SETUP request and its Cache-Control should only be specified in a SETUP request and its
response. Note: Cache-Control does em not govern the caching of response. Note: Cache-Control does not govern the caching of
responses as for HTTP, instead it applies to the media stream responses as for HTTP, instead it applies to the media stream
identified by the SETUP request. The RTSP requests are generally not identified by the SETUP request. The RTSP requests are generally not
cacheable, for further information see Section 18. Below is the cacheable, for further information see Section 18. Below is the
description of the cache directives that can be included in the description of the cache directives that can be included in the
Cache-Control header. Cache-Control header.
no-cache: Indicates that the media stream MUST NOT be cached no-cache: Indicates that the media stream MUST NOT be cached
anywhere. This allows an origin server to prevent caching even anywhere. This allows an origin server to prevent caching even
by caches that have been configured to return stale responses by caches that have been configured to return stale responses
to client requests. Note, there are no security function to client requests. Note, there is no security function
enforcing that the content can't be cached. enforcing that the content can't be cached.
public: Indicates that the media stream is cacheable by any cache. public: Indicates that the media stream is cacheable by any cache.
private: Indicates that the media stream is intended for a single private: Indicates that the media stream is intended for a single
user and MUST NOT be cached by a shared cache. A private (non- user and MUST NOT be cached by a shared cache. A private (non-
shared) cache may cache the media streams. shared) cache may cache the media streams.
no-transform: An intermediate cache (proxy) may find it useful to no-transform: An intermediate cache (proxy) may find it useful to
convert the media type of a certain stream. A proxy might, for convert the media type of a certain stream. A proxy might, for
skipping to change at page 97, line 22 skipping to change at page 98, line 22
likely to be restricted in practice to presentation descriptions and likely to be restricted in practice to presentation descriptions and
parameter-value types. 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
RTSP request-response pair. This field MUST be present in all RTSP request-response pair. This field MUST be present in all
requests and responses. For every RTSP request containing the given requests and responses. For every RTSP request containing the given
sequence number, the corresponding response will have the same sequence number, the corresponding response will have the same
number. Any retransmitted request MUST contain the same sequence number. Any retransmitted request MUST contain the same sequence
number as the original (i.e. the sequence number is em not number as the original (i.e. the sequence number is not incremented
incremented for retransmissions of the same request). For each new for retransmissions of the same request). For each new RTSP request
RTSP request the CSeq value SHALL be incremented by one. The initial the CSeq value SHALL be incremented by one. The initial sequence
sequence number MAY be any number, however it is RECOMMENDED to start number MAY be any number, however it is RECOMMENDED to start at 0.
at 0. Each sequence number series is unique between each requester Each sequence number series is unique between each requester and
and responder, i.e. the client has one series for its request to a responder, i.e. the client has one series for its request to a server
server and the server has another when sending request to the client. and the server has another when sending request to the client. Each
Each requester and responder is identified with its network address. requester and responder is identified with its network address.
Proxies that aggregate several sessions on the same transport will Proxies that aggregate several sessions on the same transport will
regularly need to renumber the CSeq header field in requests and regularly need to renumber the CSeq header field in requests and
responses to fulfill the rules for the header. responses to fulfill the rules for the header.
Example: Example:
CSeq: 239 CSeq: 239
16.20. Date 16.20. Date
See [H14.18]. An RTSP message containing a body MUST include a Date See [H14.18]. An RTSP message containing a body MUST include a Date
header if the sending host has a clock. Servers SHOULD include a header if the sending host has a clock. Servers SHOULD include a
Date header in all other RTSP messages. Date header in all other RTSP messages.
16.21. ETag 16.21. ETag
skipping to change at page 98, line 14 skipping to change at page 99, line 13
disadvantage that a change in any of the parts results in disadvantage that a change in any of the parts results in
invalidation of all the parts. invalidation of all the parts.
If the ETag is provided both inside the entity, e.g. within the If the ETag is provided both inside the entity, e.g. within the
"a=etag" attribute in SDP, and in the response message, then both "a=etag" attribute in SDP, and in the response message, then both
tags SHALL be identical. It is RECOMMENDED that the ETag is tags SHALL be identical. It is RECOMMENDED that the ETag is
primarily given in the RTSP response message, to ensure that caches primarily given in the RTSP response message, to ensure that caches
can use the ETag without requiring content inspection. However for can use the ETag without requiring content inspection. However for
session descriptions that are distributed outside of RTSP, for session descriptions that are distributed outside of RTSP, for
example using HTTP, etc. it will be necessary to include the entity example using HTTP, etc. it will be necessary to include the entity
tag in the session description as specified in Appendix C.1.9. tag in the session description as specified in Appendix D.1.9.
SETUP and DESCRIBE requests can be made conditional upon the ETag SETUP and DESCRIBE requests can be made conditional upon the ETag
using the headers If-Match (Section 16.24) and If-None-Match ( using the headers If-Match (Section 16.24) and If-None-Match (
Section 16.26). Section 16.26).
16.22. Expires 16.22. Expires
The Expires entity-header field gives a date and time after which the The Expires entity-header field gives a date and time after which the
description or media-stream should be considered stale. The description or media-stream should be considered stale. The
interpretation depends on the method: interpretation depends on the method:
skipping to change at page 101, line 6 skipping to change at page 102, line 6
binding upon the succesful completion of a session creating request, binding upon the succesful completion of a session creating request,
i.e. SETUP. If the request failed to create an RTSP session no i.e. SETUP. If the request failed to create an RTSP session no
binding SHALL be created. In case the request contains both a binding SHALL be created. In case the request contains both a
Session header and the Pipelined-Requests header the Pipelined- Session header and the Pipelined-Requests header the Pipelined-
Requests SHALL be ignored. Requests SHALL be ignored.
Note: Based on the above definition at least the first request Note: Based on the above definition at least the first request
containing a new unique Pipelined-Requests will be required to be a containing a new unique Pipelined-Requests will be required to be a
SETUP request (unless the protocol is extended with new methods of SETUP request (unless the protocol is extended with new methods of
creating a session). After that first one, additional SETUP requests creating a session). After that first one, additional SETUP requests
or request of any type using the RTSP session context may includ the or request of any type using the RTSP session context may include the
Pipelined-Requests header. Pipelined-Requests header.
For all responses to request that contained the Pipelined-Requests, For all responses to request that contained the Pipelined-Requests,
the Session header and the Pipelined-Requests SHALL both be included, the Session header and the Pipelined-Requests SHALL both be included,
assuming that it is allowed for that response and that the binding assuming that it is allowed for that response and that the binding
between the header values exist. Pipelined-Requests SHOULD NOT be between the header values exist. Pipelined-Requests SHOULD NOT be
used in requests after that the client has received the RTSP Session used in requests after that the client has received the RTSP Session
ID. This as using the real session ID allows the request to be used ID. This as using the real session ID allows the request to be used
also in cases the persistent connection has been terminated and a new also in cases the persistent connection has been terminated and a new
connection is needed. connection is needed.
skipping to change at page 103, line 36 skipping to change at page 104, line 29
In general proxies should allow all methods to transparently pass In general proxies should allow all methods to transparently pass
through from the sending RTSP agent to the receiving RTSP agent, through from the sending RTSP agent to the receiving RTSP agent,
but there may be cases where this is not desirable for a given but there may be cases where this is not desirable for a given
proxy. Modification of the Public response header field by the proxy. Modification of the Public response header field by the
intervening proxies ensures that the request sender gets an intervening proxies ensures that the request sender gets an
accurate response indicating the methods that can be used on the accurate response indicating the methods that can be used on the
target agent via the proxy chain. target agent via the proxy chain.
16.35. Range 16.35. Range
The Range header specifies a time range in PLAY ( Section 13.4), The Range header specifies a time range in PLAY (Section 13.4), PAUSE
PAUSE (Section 13.5), SETUP (Section 13.3), and REDIRECT ( (Section 13.5), SETUP (Section 13.3), and REDIRECT (Section 13.9)
Section 13.9) requests and responses. requests and responses.
The range can be specified in a number of units. This specification The range can be specified in a number of units. This specification
defines smpte (Section 4.4), npt (Section 4.5), and clock defines smpte (Section 4.4), npt (Section 4.5), and clock
(Section 4.6) range units. While byte ranges [H14.35.1] and other (Section 4.6) range units. While byte ranges [H14.35.1] and other
extended units MAY be used, their behavior is unspecified since they extended units MAY be used, their behavior is unspecified since they
are not normally meaningful in RTSP. Servers supporting the Range are not normally meaningful in RTSP. Servers supporting the Range
header MUST understand the NPT range format and SHOULD understand the header MUST understand the NPT range format and SHOULD understand the
SMPTE range format. If the Range header is sent in a time format SMPTE range format. If the Range header is sent in a time format
that is not understood, the recipient SHOULD return 456 (Header Field that is not understood, the recipient SHOULD return 456 (Header Field
Not Valid for Resource) and include an Accept-Ranges header Not Valid for Resource) and include an Accept-Ranges header
indicating the supported time formats for the given resource. indicating the supported time formats for the given resource.
The Range header MAY contain a time parameter in UTC, specifying the The Range header MAY contain a time parameter in UTC, specifying the
time at which the operation is to be made effective. This time at which the operation is to be made effective. This
functionality SHALL be used only with the REDIRECT method. functionality SHALL be used only with the REDIRECT method.
Example:
Range: clock=19960213T143205Z-;time=19970123T143720Z
The notation is similar to that used for the HTTP/1.1 [RFC2616]
byte-range header. It allows clients to select an excerpt from
the media object, and to play from a given point to the end as
well as from the current location to a given point.
Ranges are half-open intervals, including the first point, but Ranges are half-open intervals, including the first point, but
excluding the second point. In other words, a range of A-B starts excluding the second point. In other words, a range of A-B starts
exactly at time A, but stops just before B. Only the start time of a exactly at time A, but stops just before B. Only the start time of a
media unit such as a video or audio frame is relevant. For example, media unit such as a video or audio frame is relevant. For example,
assume that video frames are generated every 40 ms. A range of 10.0- assume that video frames are generated every 40 ms. A range of 10.0-
10.1 would include a video frame starting at 10.0 or later time and 10.1 would include a video frame starting at 10.0 or later time and
would include a video frame starting at 10.08, even though it lasted would include a video frame starting at 10.08, even though it lasted
beyond the interval. A range of 10.0-10.08, on the other hand, would beyond the interval. A range of 10.0-10.08, on the other hand, would
exclude the frame at 10.08. exclude the frame at 10.08.
Example:
Range: clock=19960213T143205Z-;time=19970123T143720Z
The notation is similar to that used for the HTTP/1.1 [RFC2616]
byte-range header. It allows clients to select an excerpt from
the media object, and to play from a given point to the end as
well as from the current location to a given point.
By default, range intervals increase, where the second point is By default, range intervals increase, where the second point is
larger than the first point. larger than the first point.
Example: Example:
Range: npt=10-15 Range: npt=10-15
However, range intervals can also decrease if the Scale header (see However, range intervals can also decrease if the Scale header (see
Section 16.40) indicates a negative scale value. For example, this Section 16.40) indicates a negative scale value. For example, this
would be the case when a playback in reverse is desired. would be the case when a playback in reverse is desired.
Example: Example:
Scale: -1 Scale: -1
Range: npt=15-10 Range: npt=15-10
Decreasing ranges are still half open intervals as described above. Decreasing ranges are still half open intervals as described above.
Thus, for range A-B, A is closed and B is open. In the above Thus, for range A-B, A is closed and B is open. In the above
example, 15 is closed and 10 is open. An exception to this rule is example, 15 is closed and 10 is open. An exception to this rule is
the case when B=0 in a decreasing range. In this case, the range is the case when B=0 in a decreasing range. In this case, the range is
closed on both ends, as otherwise there would be no way to reach 0 on closed on both ends, as otherwise there would be no way to reach 0 on
a reverse playback for formats that have such a notion, like NPT and a reverse playback for formats that have such a notion, like NPT and
SMPTE. SMPTE.
skipping to change at page 105, line 31 skipping to change at page 106, line 25
The Require request-header field is used by clients or servers to The Require request-header field is used by clients or servers to
ensure that the other end-point supports features that are required ensure that the other end-point supports features that are required
in respect to this request. It can also be used to query if the in respect to this request. It can also be used to query if the
other end-point supports certain features, however the use of the other end-point supports certain features, however the use of the
Supported (Section 16.44) is much more effective in this purpose. Supported (Section 16.44) is much more effective in this purpose.
The server MUST respond to this header by using the Unsupported The server MUST respond to this header by using the Unsupported
header to negatively acknowledge those feature-tags which are NOT header to negatively acknowledge those feature-tags which are NOT
supported. The response SHALL use the error code 551 (Option Not supported. The response SHALL use the error code 551 (Option Not
Supported). This header does not apply to proxies, for the same Supported). This header does not apply to proxies, for the same
functionality in respect to proxies see, header Proxy-Require ( functionality in respect to proxies see Proxy-Require header
Section 16.32). (Section 16.32).
This is to make sure that the client-server interaction will This is to make sure that the client-server interaction will
proceed without delay when all features are understood by both proceed without delay when all features are understood by both
sides, and only slow down if features are not understood (as in sides, and only slow down if features are not understood (as in
the example below). For a well-matched client-server pair, the the example below). For a well-matched client-server pair, the
interaction proceeds quickly, saving a round-trip often required interaction proceeds quickly, saving a round-trip often required
by negotiation mechanisms. In addition, it also removes state by negotiation mechanisms. In addition, it also removes state
ambiguity when the client requires features that the server does ambiguity when the client requires features that the server does
not understand. not understand.
skipping to change at page 108, line 4 skipping to change at page 108, line 29
information is available at the necessary time (immediately at information is available at the necessary time (immediately at
startup or after a seek), and that it is delivered reliably, this startup or after a seek), and that it is delivered reliably, this
mapping is placed in the RTSP control channel. mapping is placed in the RTSP control channel.
In order to compensate for drift for long, uninterrupted In order to compensate for drift for long, uninterrupted
presentations, RTSP clients should additionally map NPT to NTP, presentations, RTSP clients should additionally map NPT to NTP,
using initial RTCP sender reports to do the mapping, and later using initial RTCP sender reports to do the mapping, and later
reports to check drift against the mapping. reports to check drift against the mapping.
Example: Example:
Range:npt=3.25-15 Range:npt=3.25-15
RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102; RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102;
rtptime=12345678,url="rtsp://example.com/foo/video" rtptime=12345678,url="rtsp://example.com/foo/video"
ssrc=9A9DE123:seq=30211;rtptime=29567112 ssrc=9A9DE123:seq=30211;rtptime=29567112
Lets assume that audio uses a 16kHz RTP timestamp clock and Video Lets assume that Audio uses a 16kHz RTP timestamp clock and Video
a 90kHz RTP timestamp clock. Then the media synchronization is a 90kHz RTP timestamp clock. Then the media synchronization is
depicted in the following way. depicted in the following way.
NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6 NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6
Audio PA A Audio PA A
Video V PV Video V PV
X: NPT time value = 3.25, from Range header. X: NPT time value = 3.25, from Range header.
A: RTP timestamp value for Audio from RTP-Info header (12345678). A: RTP timestamp value for Audio from RTP-Info header (12345678).
V: RTP timestamp value for Video from RTP-Info header (29567112). V: RTP timestamp value for Video from RTP-Info header (29567112).
skipping to change at page 108, line 37 skipping to change at page 109, line 16
A scale value of 1 indicates normal play at the normal forward A scale value of 1 indicates normal play at the normal forward
viewing rate. If not 1, the value corresponds to the rate with viewing rate. If not 1, the value corresponds to the rate with
respect to normal viewing rate. For example, a ratio of 2 indicates respect to normal viewing rate. For example, a ratio of 2 indicates
twice the normal viewing rate ("fast forward") and a ratio of 0.5 twice the normal viewing rate ("fast forward") and a ratio of 0.5
indicates half the normal viewing rate. In other words, a ratio of 2 indicates half the normal viewing rate. In other words, a ratio of 2
has normal play time increase at twice the wallclock rate. For every has normal play time increase at twice the wallclock rate. For every
second of elapsed (wallclock) time, 2 seconds of content will be second of elapsed (wallclock) time, 2 seconds of content will be
delivered. A negative value indicates reverse direction. For delivered. A negative value indicates reverse direction. For
certain media transports this may require certain considerations to certain media transports this may require certain considerations to
work consistent, see Appendix B.1 for description on how RTP handles work consistent, see Appendix C.1 for description on how RTP handles
this. this.
Unless requested otherwise by the Speed parameter, the data rate Unless requested otherwise by the Speed parameter, the data rate
SHOULD not be changed. Implementation of scale changes depends on SHOULD not be changed. Implementation of scale changes depends on
the server and media type. For video, a server may, for example, the server and media type. For video, a server may, for example,
deliver only key frames or selected key frames. For audio, it may deliver only key frames or selected key frames. For audio, for
time-scale the audio while preserving pitch or, less desirably, example, it may time-scale the audio while preserving pitch or, less
deliver fragments of audio. desirably, deliver fragments of audio.
The server should try to approximate the viewing rate, but may The server should try to approximate the viewing rate, but may
restrict the range of scale values that it supports. The response restrict the range of scale values that it supports. The response
MUST contain the actual scale value chosen by the server. MUST contain the actual scale value chosen by the server.
If the server does not implement the possibility to scale, it will If the server does not implement the possibility to scale, it will
not return a Scale header. A server supporting Scale operations for not return a Scale header. A server supporting Scale operations for
PLAY SHALL indicate this with the use of the "play.scale" feature- PLAY SHALL indicate this with the use of the "play.scale" feature-
tags. tags.
skipping to change at page 109, line 27 skipping to change at page 110, line 4
16.41. Speed 16.41. Speed
The Speed request-header field requests the server to deliver data to The Speed request-header field requests the server to deliver data to
the client at a particular speed, contingent on the server's ability the client at a particular speed, contingent on the server's ability
and desire to serve the media stream at the given speed. and desire to serve the media stream at the given speed.
Implementation by the server is OPTIONAL. The default is the bit Implementation by the server is OPTIONAL. The default is the bit
rate of the stream. rate of the stream.
The parameter value is expressed as a decimal ratio, e.g., a value of The parameter value is expressed as a decimal ratio, e.g., a value of
2.0 indicates that data is to be delivered twice as fast as normal. 2.0 indicates that data is to be delivered twice as fast as normal.
A speed of zero is invalid. All speeds may not be possible to A speed of zero is invalid. All speeds may not be possible to
support. Therefore the actual used speed MUST be included in the support. Therefore the actual used speed MUST be included in the
response. The lack of a response header is indication of lack of response. The lack of a response header is indication of lack of
support from the server of this functionality. Support of the speed support from the server of this functionality. Support of the speed
functionality are indicated by the "play.speed" feature\-tag. functionality are indicated by the "play.speed" feature-tag.
Example: Example:
Speed: 2.5 Speed: 2.5
Use of this field changes the bandwidth used for data delivery. It Use of this field changes the bandwidth used for data delivery. It
is meant for use in specific circumstances where preview of the is meant for use in specific circumstances where preview of the
presentation at a higher or lower rate is necessary. Implementors presentation at a higher or lower rate is necessary. Implementors
should keep in mind that bandwidth for the session may be negotiated should keep in mind that bandwidth for the session may be negotiated
beforehand (by means other than RTSP), and therefore re-negotiation beforehand (by means other than RTSP), and therefore re-negotiation
may be necessary. When data is delivered over UDP, it is highly may be necessary. When data is delivered over UDP, it is highly
recommended that means such as RTCP be used to track packet loss recommended that means such as RTCP be used to track packet loss
rates. If the data transport is performed over non-dedicated best- rates. If the data transport is performed over non-dedicated best-
skipping to change at page 110, line 8 skipping to change at page 110, line 29
may be necessary. When data is delivered over UDP, it is highly may be necessary. When data is delivered over UDP, it is highly
recommended that means such as RTCP be used to track packet loss recommended that means such as RTCP be used to track packet loss
rates. If the data transport is performed over non-dedicated best- rates. If the data transport is performed over non-dedicated best-
effort networks the sender is required to perform congestion control effort networks the sender is required to perform congestion control
of the stream(s). This can result in that the communicated speed is of the stream(s). This can result in that the communicated speed is
impossible to maintain. impossible to maintain.
16.42. Server 16.42. Server
See [H14.38], however the header syntax is corrected in See [H14.38], however the header syntax is corrected in
Section 21.2.3. Section 20.2.3.
16.43. Session 16.43. Session
The Session request-header and response-header field identifies an The Session request-header and response-header field identifies an
RTSP session. An RTSP session is created by the server as a result RTSP session. An RTSP session is created by the server as a result
of a successful SETUP request and in the response the session of a successful SETUP request and in the response the session
identifier is given to the client. The RTSP session exist until identifier is given to the client. The RTSP session exist until
destroyed by a TEARDOWN or timed out by the server. destroyed by a TEARDOWN or timed out by the server.
The session identifier is chosen by the server (see Section 4.3) and The session identifier is chosen by the server (see Section 4.3) and
skipping to change at page 110, line 31 skipping to change at page 110, line 52
that session. This means that the Session header MUST be included in that session. This means that the Session header MUST be included in
a request using the following methods: PLAY, PAUSE, and TEARDOWN, and a request using the following methods: PLAY, PAUSE, and TEARDOWN, and
MAY be included in SETUP, OPTIONS, SETPARAMETER, GET_PARAMETER, and MAY be included in SETUP, OPTIONS, SETPARAMETER, GET_PARAMETER, and
REDIRECT, and SHALL NOT be included in DESCRIBE. In an RTSP response REDIRECT, and SHALL NOT be included in DESCRIBE. In an RTSP response
the session header SHALL be included in methods, SETUP, PLAY, and the session header SHALL be included in methods, SETUP, PLAY, and
PAUSE, and MAY be included in methods, TEARDOWN, and REDIRECT, and if PAUSE, and MAY be included in methods, TEARDOWN, and REDIRECT, and if
included in the request of the following methods it SHALL also be included in the request of the following methods it SHALL also be
included in the response, OPTIONS, GET_PARAMETER, and SETPARAMETER, included in the response, OPTIONS, GET_PARAMETER, and SETPARAMETER,
and SHALL NOT be included in DESCRIBE. and SHALL NOT be included in DESCRIBE.
The timeout parameter MAY be included in a SETUP response, and SHALL
NOT be included in requests. The server uses it to indicate to the
client how long the server is prepared to wait between RTSP commands
or other signs of life before closing the session due to lack of
activity (see below and Appendix A). The timeout is measured in
seconds, with a default of 60 seconds (1 minute). The length of the
session timeout SHALL NOT be changed in a established session.
The mechanisms for showing liveness of the client is, any RTSP
request with a Session header, if RTP & RTCP is used an RTCP message,
or through any other used media protocol capable of indicating
liveness of the RTSP client. It is RECOMMENDED that a client does
not wait to the last second of the timeout before trying to send a
liveness message. The RTSP message may be lost or when using
reliable protocols, such as TCP, the message may take some time to
arrive safely at the receiver. To show liveness between RTSP request
issued to accomplish other things, the following mechanisms can be
used, in descending order of preference:
RTCP: If RTP is used for media transport RTCP SHOULD be used. If
RTCP is used to report transport statistics, it SHALL also work
as keep alive. The server can determine the client by used
network address and port together with the fact that the client
is reporting on the servers SSRC(s). A downside of using RTCP
is that it only gives statistical guarantees to reach the
server. However that probability is so low that it can be
ignored in most cases. For example, a session with 60 seconds
timeout and enough bitrate assigned to RTCP messages to send a
message from client to server on average every 5 seconds. That
client have for a network with 5 \% packet loss, the
probability to fail showing liveness sign in that session
within the timeout interval of 2.4*E-16. In sessions with
shorter timeout times, or much higher packet loss, or small
RTCP bandwidths SHOULD also use any of the mechanisms below.
SETPARAMETER: When using SETPARAMETER for keep alive, no body SHOULD
be included. This method is the RECOMMENDED RTSP method to use
in request only intended to perform keep-alive.
OPTIONS: This method does also work. However it causes the server
to perform more unnecessary processing and result in bigger
responses than necessary for the task. The reason for this is
that the server needs to determine what capabilities that are
associated with the media resource to correctly populate the
Public and Allow headers.
Note that a session identifier identifies an RTSP session across Note that a session identifier identifies an RTSP session across
transport sessions or connections. RTSP requests for a given session transport sessions or connections. RTSP requests for a given session
can use different URIs (Presentation and media URIs). Note, that can use different URIs (Presentation and media URIs). Note, that
there are restrictions depending on the session which URIs that are there are restrictions depending on the session which URIs that are
acceptable for a given method. However, multiple "user" sessions for acceptable for a given method. However, multiple "user" sessions for
the same URI from the same client will require use of different the same URI from the same client will require use of different
session identifiers. session identifiers.
The session identifier is needed to distinguish several delivery The session identifier is needed to distinguish several delivery
requests for the same URI coming from the same client. requests for the same URI coming from the same client.
skipping to change at page 114, line 41 skipping to change at page 114, line 12
destination entity per transport spec is intended. The usage destination entity per transport spec is intended. The usage
of multiple destination to distribute a single media to of multiple destination to distribute a single media to
multiple entities is unspecified. multiple entities is unspecified.
The client originating the RTSP request MAY specify the The client originating the RTSP request MAY specify the
destination address of the stream recipient with the host destination address of the stream recipient with the host
address part of the tuple. When the destination address is address part of the tuple. When the destination address is
specified, the recipient may be a different party than the specified, the recipient may be a different party than the
originator of the request. To avoid becoming the unwitting originator of the request. To avoid becoming the unwitting
perpetrator of a remote-controlled denial-of-service attack, a perpetrator of a remote-controlled denial-of-service attack, a
server MUST perform security checks (see Section 22.1) and server MUST perform security checks (see Section 21.1) and
SHOULD log such attempts before allowing the client to direct a SHOULD log such attempts before allowing the client to direct a
media stream to a recipient address not chosen by the server. media stream to a recipient address not chosen by the server.
Implementations cannot rely on TCP as reliable means of client Implementations cannot rely on TCP as reliable means of client
identification. If the server does not allow the host address identification. If the server does not allow the host address
part of the tuple to be set, it SHALL return 463 (Destination part of the tuple to be set, it SHALL return 463 (Destination
Prohibited). Prohibited).
The host address part of the tuple MAY be empty, for example The host address part of the tuple MAY be empty, for example
":58044", in cases when only destination port is desired to be ":58044", in cases when only destination port is desired to be
specified. specified.
skipping to change at page 115, line 43 skipping to change at page 115, line 15
mode: The mode parameter indicates the methods to be supported for mode: The mode parameter indicates the methods to be supported for
this session. Valid values are PLAY and RECORD. If not this session. Valid values are PLAY and RECORD. If not
provided, the default is PLAY. The RECORD value was defined in provided, the default is PLAY. The RECORD value was defined in
RFC 2326 and is in this specification unspecified but reserved. RFC 2326 and is in this specification unspecified but reserved.
interleaved: The interleaved parameter implies mixing the media interleaved: The interleaved parameter implies mixing the media
stream with the control stream in whatever protocol is being stream with the control stream in whatever protocol is being
used by the control stream, using the mechanism defined in used by the control stream, using the mechanism defined in
Section 14. The argument provides the channel number to be Section 14. The argument provides the channel number to be
used in the $ statement and MUST be present. This parameter used in the $ statement and MUST be present. This parameter
MAY be specified as a range, e.g., tt interleaved=4-5 in cases MAY be specified as a range, e.g., interleaved=4-5 in cases
where the transport choice for the media stream requires it, where the transport choice for the media stream requires it,
e.g. for RTP with RTCP. The channel number given in the e.g. for RTP with RTCP. The channel number given in the
request are only a guidance from the client to the server on request are only a guidance from the client to the server on
what channel number(s) to use. The server MAY set any valid what channel number(s) to use. The server MAY set any valid
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.
skipping to change at page 116, line 46 skipping to change at page 116, line 18
The parameters defined below MAY only be used if the media transport The parameters defined below MAY only be used if the media transport
protocol if the lower-level transport is connection-oriented (such as protocol if the lower-level transport is connection-oriented (such as
TCP). However, these parameters MUST NOT be used when interleaving TCP). However, these parameters MUST NOT be used when interleaving
data over the RTSP control connection. data over the RTSP control connection.
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 B.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
client is willing to accept an incoming connection or to client is willing to accept an incoming connection or to
initiate an outgoing connection. initiate an outgoing connection.
If a client does not specify a setup value, the "active" value If a client does not specify a setup value, the "active" value
is assumed. is assumed.
skipping to change at page 117, line 50 skipping to change at page 117, line 21
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).
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 B. 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
CSeq: 302 CSeq: 302
Transport: RTP/AVP;multicast;mode="PLAY", Transport: RTP/AVP;multicast;mode="PLAY",
RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";mode="PLAY" "192.0.2.5:3457";mode="PLAY"
Accept-Ranges: NPT, SMPTE, UTC Accept-Ranges: NPT, SMPTE, UTC
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: 302 CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344 Session: 47112344
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/ Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";src_addr="192.0.2.224:6256" "192.0.2.5:3457";src_addr="192.0.2.224:6256"/
/"192.0.2.224:6257";mode="PLAY" "192.0.2.224:6257";mode="PLAY"
Accept-Ranges: NPT Accept-Ranges: NPT
16.47. Unsupported 16.47. Unsupported
The Unsupported response-header field lists the features not The Unsupported response-header field lists the features not
supported by the server. In the case where the feature was specified supported by the server. In the case where the feature was specified
via the Proxy-Require field (Section 16.32), if there is a proxy on via the Proxy-Require field (Section 16.32), if there is a proxy on
the path between the client and the server, the proxy MUST send a the path between the client and the server, the proxy MUST send a
response message with a status code of 551 (Option Not Supported). response message with a status code of 551 (Option Not Supported).
The request SHALL NOT be forwarded. The request SHALL NOT be forwarded.
See Section 16.38 for a usage example. See Section 16.38 for a usage example.
16.48. User-Agent 16.48. User-Agent
See [H14.43] for explanation, however the syntax is clarified due to See [H14.43] for explanation, however the syntax is clarified due to
an error in RFC 2616. A Client SHOULD include this header in all an error in RFC 2616. A Client SHOULD include this header in all
RTSP messages it sends. RTSP messages it sends.
skipping to change at page 120, line 37 skipping to change at page 119, line 37
firewalled network, the security proxy request that the firewalled network, the security proxy request that the
necessary pinholes in the firewall is opened when a client in necessary pinholes in the firewall is opened when a client in
the protected network want to access media streams on the the protected network want to access media streams on the
external side. It can also provide network owners with a external side. It can also provide network owners with a
logging and audit point for RTSP sessions, e.g. for logging and audit point for RTSP sessions, e.g. for
corporations that tracks or limits their employees access to corporations that tracks or limits their employees access to
certain type of content. certain type of content.
All type of proxies can be used also when using secured communication All type of proxies can be used also when using secured communication
with TLS as RTSP 2.0 allows the client to approve certificate chains with TLS as RTSP 2.0 allows the client to approve certificate chains
used for connection establishment from a proxy, see Section 20.3.2. used for connection establishment from a proxy, see Section 19.3.2.
However that trust model may not be suitable for all type of However that trust model may not be suitable for all type of
deployment, and instead secured sessions do by-pass of the proxies. deployment, and instead secured sessions do by-pass of the proxies.
Access proxies SHOULD NOT be used in equipment like NATs and Access proxies SHOULD NOT be used in equipment like NATs and
firewalls that aren't expected to be regularly maintained, like home firewalls that aren't expected to be regularly maintained, like home
or small office equipment. In these cases it is better to use the or small office equipment. In these cases it is better to use the
NAT traversal procedures defined for RTSP 2.0 NAT traversal procedures defined for RTSP 2.0
[I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is [I-D.ietf-mmusic-rtsp-nat]. The reason for these recommendations is
that any extensions of RTSP resulting in new media transport that any extensions of RTSP resulting in new media transport
protocols or profiles, new parameters etc may fail in a proxy that protocols or profiles, new parameters etc may fail in a proxy that
skipping to change at page 123, line 5 skipping to change at page 122, line 5
cache has to store the content type, content language, and so on for cache has to store the content type, content language, and so on for
the objects it caches, a media cache has to store the presentation the objects it caches, a media cache has to store the presentation
description. Typically, a cache eliminates all transport-references description. Typically, a cache eliminates all transport-references
(that is, e.g. multicast information) from the presentation (that is, e.g. multicast information) from the presentation
description, since these are independent of the data delivery from description, since these are independent of the data delivery from
the cache to the client. Information on the encodings remains the the cache to the client. Information on the encodings remains the
same. If the cache is able to translate the cached media data, it same. If the cache is able to translate the cached media data, it
would create a new presentation description with all the encoding would create a new presentation description with all the encoding
possibilities it can offer. possibilities it can offer.
19. Examples 19. Security Framework
This section contains several different examples trying to illustrate
possible ways of using RTSP. The examples can also help with the
understanding of how functions of RTSP work. However remember that
this is examples and the normative and syntax description in the
other sections takes precedence. Please also note that many of the
example contain syntax illegal line breaks to accommodate the
formatting restriction that the RFC series impose.
19.1. Media on Demand (Unicast)
The is an example of media on demand streaming of a media stored in a
container file. For purposes of this example, a container file is a
storage entity in which multiple continuous media types pertaining to
the same end-user presentation are present. In effect, the container
file represents an RTSP presentation, with each of its components
being RTSP controlled media streams. Container files are a widely
used means to store such presentations. While the components are
transported as independent streams, it is desirable to maintain a
common context for those streams at the server end.
This enables the server to keep a single storage handle open
easily. It also allows treating all the streams equally in case
of any prioritization of streams by the server.
It is also possible that the presentation author may wish to prevent
selective retrieval of the streams by the client in order to preserve
the artistic effect of the combined media presentation. Similarly,
in such a tightly bound presentation, it is desirable to be able to
control all the streams via a single control message using an
aggregate URI.
The following is an example of using a single RTSP session to control
multiple streams. It also illustrates the use of aggregate URIs. In
a container file it is also desirable to not write any URI parts
which is not kept, when the container is distributed, like the host
and most of the path element. Therefore this example also uses the
"*" and relative URI in the delivered SDP.
Client C requests a presentation from media server M. The movie is
stored in a container file. The client has obtained an RTSP URI to
the container file.
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 257
Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
a=control: *
a=range: npt=0-0:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
m=video 0 RTP/AVP 26
a=control: trackID=4
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: NPT, SMPTE, UTC
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001;
src_addr="192.0.2.5:9000"/"192.0.2.5:9001"
ssrc=93CB001E
Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Session: 12345678
Accept-Ranges: NPT, SMPTE, UTC
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003;
src_addr="192.0.2.5:9002"/"192.0.2.5:9003";
ssrc=A813FC13
Session: 12345678
Expires: 24 Jan 1997 15:35:13 GMT
Date: 23 Jan 1997 15:35:13 GMT
Accept-Range: NPT
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=0-10, npt=30-
Session: 12345678
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678
Range: npt=0-10, npt=30-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1";
ssrc=4F312DD8:seq=54321;rtptime=2876889
C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 5
User-Agent: PhonyClient/1.2
Session: 12345678
M->C: RTSP/2.0 200 OK
CSeq: 5
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:01 GMT
Session: 12345678
Range: npt=34.57-623.10
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 6
User-Agent: PhonyClient/1.2
Range: npt=34.57-623.10
Session: 12345678
M->C: RTSP/2.0 200 OK
CSeq: 6
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:01 GMT
Session: 12345678
Range: npt=34.57-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12555;rtptime=6330012,
url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=55021;rtptime=3132889
19.2. Media on Demand using Pipelining
This example is basically the example above ( Section 19.1) but now
utilizing pipelining to speed up the setup. Into requiring only two
round trip times until media starts flowing. First getting the
session description to determine what media resources need to be
setup. In the second one send the necessary SETUP requests and the
PLAY request to initiate media delivery.
Client C requests a presentation from media server M. The movie is
stored in a container file. The client has obtained an RTSP URI to
the container file.
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 257
Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
a=control: *
a=range: npt=0-0:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
m=video 0 RTP/AVP 26
a=control: trackID=4
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: NPT, SMPTE, UTC
Pipelined-Requests: 7654
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Accept-Ranges: NPT, SMPTE, UTC
Pipelined-Requests: 7654
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=0-10, npt=30-
Session: 12345678
Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001;
src_addr="192.0.2.5:9000"/"192.0.2.5:9001"
ssrc=93CB001E
Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT
Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003;
src_addr="192.0.2.5:9002"/"192.0.2.5:9003";
ssrc=A813FC13
Session: 12345678
Expires: 24 Jan 1997 15:35:13 GMT
Date: 23 Jan 1997 15:35:13 GMT
Accept-Range: NPT
Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678
Range: npt=0-10, npt=30-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1";
ssrc=4F312DD8:seq=54321;rtptime=2876889
Pipelined-Requests: 7654
19.3. Media on Demand (Unicast)
An alternative example of media on demand with a bit more tweaks is
the following. Client C requests a movie distributed from two
different media servers A (tt audio.example.com) and V (tt
video.example.com). The media description is stored on a web server
W. The media description contains descriptions of the presentation
and all its streams, including the codecs that are available, dynamic
RTP payload types, the protocol stack, and content information such
as language or copyright restrictions. It may also give an
indication about the timeline of the movie.
In this example, the client is only interested in the last part of
the movie.
C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
W->C: HTTP/1.0 200 OK
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 264
Expires: 23 Jan 1998 15:35:06 GMT
v=0
o=- 2890844526 2890842807 IN IP4 192.0.2.5
s=RTSP Session
e=adm@example.com
a=range:npt=0-1:49:34
t=0 0
m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC
A->C: RTSP/2.0 200 OK
CSeq: 1
Session: 12345678
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057";
src_addr="192.0.2.5:5000"/"192.0.2.5:5001"
Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0
Expires: 24 Jan 1997 15:35:12 GMT
Cache-Control: public
Accept-Ranges: NPT, SMPTE
C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC
V->C: RTSP/2.0 200 OK
CSeq: 1
Session: 23456789
Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059";
src_addr="192.0.2.5:5002"/"192.0.2.5:5003"
Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0
Cache-Control: public
Expires: 24 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT, SMPTE
C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: 23456789
Range: smpte=0:10:00-
V->C: RTSP/2.0 200 OK
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-1:49:23
RTP-Info: url="rtsp://video.example.com/twister/video"
ssrc=A17E189D:seq=12312232;rtptime=78712811
Server: PhonyServer/2.0
Date: 23 Jan 1997 15:35:13 GMT
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: 12345678
Range: smpte=0:10:00-
A->C: RTSP/2.0 200 OK
CSeq: 2
Session: 12345678
Range: smpte=0:10:00-1:49:23
RTP-Info: url="rtsp://audio.example.com/twister/audio.en"
ssrc=3D124F01:seq=876655;rtptime=1032181
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:13 GMT
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: 12345678
A->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:52 GMT
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: 23456789
V->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/2.0
Date: 23 Jan 1997 15:36:52 GMT
Even though the audio and video track are on two different servers,
may start at slightly different times, and may drift with respect to
each other, the client can perform initial synchronize of the two
media using RTP-Info and Range received in the PLAY responses. If
the two servers are time synchronized the RTCP packets can also be
used to maintain synchronization.
19.4. Single Stream Container Files
Some RTSP servers may treat all files as though they are "container
files", yet other servers may not support such a concept. Because of
this, clients needs to use the rules set forth in the session
description for Request-URIs, rather than assuming that a consistent
URI may always be used throughout. Below are an example of how a
multi-stream server might expect a single-stream file to be served:
C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/2.0
Accept: application/x-rtsp-mh, application/sdp
CSeq: 1
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 1
Content-base: rtsp://foo.com/test.wav/
Content-type: application/sdp
Content-length: 148
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT
Expires: 23 Jan 1997 17:00:00 GMT
v=0
o=- 872653257 872653257 IN IP4 192.0.2.5
s=mu-law wave file
i=audio test
t=0 0
a=control: *
m=audio 0 RTP/AVP 0
a=control:streamid=0
C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/2.0
Transport: RTP/AVP/UDP;unicast;
dest_addr=":6970"/":6971";mode="PLAY"
CSeq: 2
User-Agent: PhonyClient/1.2
Accept-Ranges: NPT, SMPTE, UTC
S->C: RTSP/2.0 200 OK
Transport: RTP/AVP/UDP;unicast;dest_addr=":6970"/":6971";
src_addr="192.0.2.5:6970"/"192.0.2.5:6971";
mode="PLAY";ssrc=EAB98712
CSeq: 2
Session: 2034820394
Expires: 23 Jan 1997 16:00:00 GMT
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:07 GMT
Accept-Ranges: NPT
C->S: PLAY rtsp://foo.com/test.wav/ RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: 2034820394
S->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:08 GMT
Session: 2034820394
Range: npt=0-600
RTP-Info: url="rtsp://foo.com/test.wav/streamid=0"
ssrc=0D12F123:seq=981888;rtptime=3781123
Note the different URI in the SETUP command, and then the switch back
to the aggregate URI in the PLAY command. This makes complete sense
when there are multiple streams with aggregate control, but is less
than intuitive in the special case where the number of streams is
one. However the server has declared that the aggregated control URI
in the SDP and therefore this is legal.
In this case, it is also required that servers accept implementations
that use the non-aggregated interpretation and use the individual
media URI, like this:
C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
19.5. Live Media Presentation Using Multicast
The media server M chooses the multicast address and port. Here, it
is assumed that the web server only contains a pointer to the full
description, while the media server M maintains the full description.
C->W: GET /sessions.html HTTP/2.0
Host: www.example.com
W->C: HTTP/2.0 200 OK
Content-Type: text/html
<html>
...
<href "Stremed Live Music performance"
src="rtsp://live.example.com/concert/audio">
...
</html>
C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 1
Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: 182
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT
Supported: play.basic
v=0
o=- 2890844526 2890842807 IN IP4 192.0.2.5
s=RTSP Session
m=audio 3456 RTP/AVP 0
c=IN IP4 224.2.0.1/16
a=control: rtsp://live.example.com/concert/audio
a=range:npt=0-
C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 2
Transport: RTP/AVP;multicast
Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT
Transport: RTP/AVP;multicast;dest_addr="224.2.0.1:3456"/"
224.2.0.1:3457";ttl=16
Session: 0456804596
Accept-Ranges: NPT, UTC
C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 3
Session: 0456804596
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:07 GMT
Session: 0456804596
Range:npt=1256-
RTP-Info: url="rtsp://live.example.com/concert/audio"
ssrc=0D12F123:seq=1473; rtptime=80000
19.6. Capability Negotiation
This examples illustrate how the client and server determines their
capability to support a special feature, in this case "play.scale".
The server, through the clients request and the included Supported
header, learns the client supports RTSP 2.0, and also supports the
playback time scaling feature of RTSP. The server's response
contains the following feature related information to the client; it
supports the basic playback (play.basic), the extended functionality
of time scaling of content (play.scale), and one "example.com"
proprietary feature (com.example.flight). The client also learns the
methods supported (Public header) by the server for the indicated
resource.
C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0
CSeq: 1
Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 1
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
Server: PhonyServer/2.0
Supported: play.basic, play.scale, com.example.flight
When the client sends its SETUP request it tells the server that it
is requires support of the play.scale feature for this session by
including the Require header.
C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
RTP/AVP/TCP;unicast;interleaved=0-1
Require: play.scale
Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 3
Session: 12345678
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057";
src_addr="192.0.2.5:5000"/"192.0.2.5:5001"
Server: PhonyServer/2.0
Accept-Ranges: NPT, SMPTE
20. Security Framework
The RTSP security framework consists of two high level components: The RTSP security framework consists of two high level components:
the pure authentication mechanisms based on HTTP authentication, and the pure authentication mechanisms based on HTTP authentication, and
the transport protection based on TLS, which is independent of RTSP. the transport protection based on TLS, which is independent of RTSP.
Because of the similarity in syntax and usage between RTSP servers Because of the similarity in syntax and usage between RTSP servers
and HTTP servers, the security for HTTP is re-used to a large extent. and HTTP servers, the security for HTTP is re-used to a large extent.
20.1. RTSP and HTTP Authentication 19.1. RTSP and HTTP Authentication
RTSP and HTTP share common authentication schemes, and thus follow RTSP and HTTP share common authentication schemes, and thus follow
the same usage guidelines as specified in[RFC2617] and also in [H15]. the same usage guidelines as specified in[RFC2617] and also in [H15].
Servers SHOULD implement both basic and digest [RFC2617] Servers SHOULD implement both basic and digest [RFC2617]
authentication. authentication.
It should be stressed that using the HTTP authentication alone does It should be stressed that using the HTTP authentication alone does
not provide full control message security. Therefore, in not provide full control message security. Therefore, in
environments requiring tighter security for the control messages, TLS environments requiring tighter security for the control messages, TLS
SHOULD be used, see Section 20.2. SHOULD be used, see Section 19.2.
20.2. RTSP over TLS 19.2. RTSP over TLS
RTSP SHALL follow the same guidelines with regards to TLS [RFC4346] RTSP SHALL follow the same guidelines with regards to TLS [RFC4346]
usage as specified for HTTP, see [RFC2818]. RTSP over TLS is usage as specified for HTTP, see [RFC2818]. RTSP over TLS is
separated from unsecured RTSP both on URI level and port level. separated from unsecured RTSP both on URI level and port level.
Instead of using the "rtsp" scheme identifier in the URI, the "rtsps" Instead of using the "rtsp" scheme identifier in the URI, the "rtsps"
scheme identifier MUST be used to signal RTSP over TLS. If no port scheme identifier MUST be used to signal RTSP over TLS. If no port
is given in a URI with the "rtsps" scheme, port 322 SHALL be used for is given in a URI with the "rtsps" scheme, port 322 SHALL be used for
TLS over TCP/IP. TLS over TCP/IP.
When a client tries to setup an insecure channel to the server (using When a client tries to setup an insecure channel to the server (using
skipping to change at page 138, line 12 skipping to change at page 123, line 12
RTSP includes the possibility to keep a TCP session up between the RTSP includes the possibility to keep a TCP session up between the
client and server, throughout the RTSP session lifetime. It may be client and server, throughout the RTSP session lifetime. It may be
convenient to keep the TCP session, not only to save the extra setup convenient to keep the TCP session, not only to save the extra setup
time for TCP, but also the extra setup time for TLS (even if TLS uses time for TCP, but also the extra setup time for TLS (even if TLS uses
the resume function, there will be almost two extra roundtrips). the resume function, there will be almost two extra roundtrips).
Still, when TLS is used, such behavior introduces extra active state Still, when TLS is used, such behavior introduces extra active state
in the server, not only for TCP and RTSP, but also for TLS. This may in the server, not only for TCP and RTSP, but also for TLS. This may
increase the vulnerability to DoS attacks. increase the vulnerability to DoS attacks.
In addition to these recommendations, Section 20.3 gives further In addition to these recommendations, Section 19.3 gives further
recommendations of TLS usage with proxies. recommendations of TLS usage with proxies.
20.3. Security and Proxies 19.3. Security and Proxies
The nature of a proxy is often to act as a "man-in-the-middle", while The nature of a proxy is often to act as a "man-in-the-middle", while
security is often about preventing the existence of a "man-in-the- security is often about preventing the existence of a "man-in-the-
middle". This section provides the clients with the possibility to middle". This section provides clients with the possibility to use
use proxies even when applying secure transports (TLS) between the proxies even when applying secure transports (TLS) between the RTSP
RTSP agents. The TLS proxy mechanism allows for server and proxy agents. The TLS proxy mechanism allows for server and proxy
identification using certificates. However, the client can not be identification using certificates. However, the client can not be
identified based on certificates. The client needs to select between identified based on certificates. The client needs to select between
using the procedure specified below or using a TLS connection using the procedure specified below or using a TLS connection
directly (by-passing any proxies) to the server. The choice may be directly (by-passing any proxies) to the server. The choice may be
dependent on policies. dependent on policies.
There are basically two categories of proxies, the transparent There are basically two categories of proxies, the transparent
proxies (of which the client is not aware) and the non-transparent proxies (of which the client is not aware) and the non-transparent
proxies (of which the client is aware). An infrastructure based on proxies (of which the client is aware). An infrastructure based on
proxies requires that the trust model is such that both client and proxies requires that the trust model is such that both client and
skipping to change at page 139, line 28 skipping to change at page 124, line 28
"rtsps" URI. TLS MAY be applied on intermediate links (e.g. between "rtsps" URI. TLS MAY be applied on intermediate links (e.g. between
client and proxy, or between proxy and proxy), even if the resource client and proxy, or between proxy and proxy), even if the resource
and the end server does not require to use it. The proxy SHALL when and the end server does not require to use it. The proxy SHALL when
initiating the next hop TLS connection use the incomming TLS initiating the next hop TLS connection use the incomming TLS
connections CipherSuite list, only modified by removing any cipher connections CipherSuite list, only modified by removing any cipher
suits that the proxy does not support. In case a proxy fails to suits that the proxy does not support. In case a proxy fails to
establish a TLS connection due to cipher suite mismatch between proxy establish a TLS connection due to cipher suite mismatch between proxy
and next hop proxy or server, this is indicated using error code 472 and next hop proxy or server, this is indicated using error code 472
(Failure to establish secure connection). (Failure to establish secure connection).
20.3.1. Accept-Credentials 19.3.1. Accept-Credentials
The Accept-Credentials header can be used by the client to distribute The Accept-Credentials header can be used by the client to distribute
simple authorization policies to intermediate proxies. The client simple authorization policies to intermediate proxies. The client
includes the Accept-Credentials header to dictate how the proxy includes the Accept-Credentials header to dictate how the proxy
treats the server/next proxy certificate. There are currently three treats the server/next proxy certificate. There are currently three
methods defined: methods defined:
Any, which means that the proxy (or proxies) SHALL accept whatever Any, which means that the proxy (or proxies) SHALL accept whatever
certificate presented. This is of course not a recommended certificate presented. This is of course not a recommended
option to use, but may be useful in certain circumstances (such option to use, but may be useful in certain circumstances (such
skipping to change at page 139, line 51 skipping to change at page 124, line 51
Proxy, which means that the proxy (or proxies) MUST use its own Proxy, which means that the proxy (or proxies) MUST use its own
policies to validate the certificate and decide whether to policies to validate the certificate and decide whether to
accept it or not. This is convenient in cases where the user accept it or not. This is convenient in cases where the user
has a strong trust relation with the proxy. Reason why a has a strong trust relation with the proxy. Reason why a
strong trust relation may exist are; personal/company proxy, strong trust relation may exist are; personal/company proxy,
proxy has a out-of-band policy configuration mechanism. proxy has a out-of-band policy configuration mechanism.
User, which means that the proxy (or proxies) MUST send credential User, which means that the proxy (or proxies) MUST send credential
information about the next hop to the client for authorization. information about the next hop to the client for authorization.
The client can then decide whether the proxy should accept the The client can then decide whether the proxy should accept the
certificate or not. See Section 20.3.2 for further details. certificate or not. See Section 19.3.2 for further details.
If the Accept-Credentials header is not included in the RTSP request If the Accept-Credentials header is not included in the RTSP request
from the client, then the "Proxy" method SHALL be used as default. from the client, then the "Proxy" method SHALL be used as default.
If an other method than the "Proxy" is to be used, then the Accept- If an other method than the "Proxy" is to be used, then the Accept-
Credentials header SHALL be included in all of the RTSP request from Credentials header SHALL be included in all of the RTSP request from
the client. This is because it cannot be assumed that the proxy the client. This is because it cannot be assumed that the proxy
always keeps the TLS state or the users previously preference between always keeps the TLS state or the users previously preference between
different RTSP messages (in particular if the time interval between different RTSP messages (in particular if the time interval between
the messages is long). the messages is long).
skipping to change at page 140, line 32 skipping to change at page 125, line 32
established connection. However if the server to client request is established connection. However if the server to client request is
in relation to a session established over a TLS secured channel, if in relation to a session established over a TLS secured channel, if
MUST be sent in a TLS secured connection. That secured connection MUST be sent in a TLS secured connection. That secured connection
MUST also be the one used by the last client to server request. If MUST also be the one used by the last client to server request. If
no such transport connection exist at the time when the server desire no such transport connection exist at the time when the server desire
to send the request, it silently fails. to send the request, it silently fails.
Further policies MAY be defined and registered, but should be done so Further policies MAY be defined and registered, but should be done so
with caution. with caution.
20.3.2. User approved TLS procedure 19.3.2. User approved TLS procedure
For the "User" method each proxy MUST perform the the following For the "User" method each proxy MUST perform the the following
procedure for each RTSP request: procedure for each RTSP request:
o Setup the TLS session to the next hop if not already present (i.e. o Setup the TLS session to the next hop if not already present (i.e.
run the TLS handshake, but do not send the RTSP request). run the TLS handshake, but do not send the RTSP request).
o Extract the peer certificate chain for the TLS session. o Extract the peer certificate chain for the TLS session.
o Check if a matching identity and hash of the peer certificate is o Check if a matching identity and hash of the peer certificate is
skipping to change at page 143, line 5 skipping to change at page 127, line 5
RTSP messages may take significantly more round-trip times for the RTSP messages may take significantly more round-trip times for the
first message. An complete extra message exchange between the proxy first message. An complete extra message exchange between the proxy
connecting to the next hop and the client results because of the connecting to the next hop and the client results because of the
process for approval for each hop. However after the first message process for approval for each hop. However after the first message
exchange the remaining message should not be delayed, if each message exchange the remaining message should not be delayed, if each message
contains the chain of proxies that the requestor accepts. The contains the chain of proxies that the requestor accepts. The
procedure of including the credentials in each request rather than procedure of including the credentials in each request rather than
building state in each proxy, avoids the need for revocation building state in each proxy, avoids the need for revocation
procedures. procedures.
21. Syntax 20. Syntax
The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF)
as defined in RFC 4234 [RFC4234]. It uses the basic definitions as defined in RFC 4234 [RFC4234]. It uses the basic definitions
present in RFC 4234. present in RFC 4234.
Please note that ABNF strings, e.g. "Accept", are case insensitive Please note that ABNF strings, e.g. "Accept", are case insensitive
as specified in section 2.3 of RFC 4234. as specified in section 2.3 of RFC 4234.
21.1. Base Syntax 20.1. Base Syntax
RTSP header field values can be folded onto multiple lines if the RTSP header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear continuation line begins with a space or horizontal tab. All linear
white space, including folding, has the same semantics as SP. A white space, including folding, has the same semantics as SP. A
recipient MAY replace any linear white space with a single SP before recipient MAY replace any linear white space with a single SP before
interpreting the field value or forwarding the message downstream. interpreting the field value or forwarding the message downstream.
This is intended to behave exactly as HTTP/1.1 as described in RFC This is intended to behave exactly as HTTP/1.1 as described in RFC
2616 [RFC2616]. The SWS construct is used when linear white space is 2616 [RFC2616]. The SWS construct is used when linear white space is
optional, generally between tokens and separators. optional, generally between tokens and separators.
skipping to change at page 145, line 24 skipping to change at page 129, line 24
LAQUOT = SWS "<" ; left angle quote LAQUOT = SWS "<" ; left angle quote
TEXT-UTF8char = %x21-7E / UTF8-NONASCII TEXT-UTF8char = %x21-7E / UTF8-NONASCII
UTF8-NONASCII = %xC0-DF 1UTF8-CONT UTF8-NONASCII = %xC0-DF 1UTF8-CONT
/ %xE0-EF 2UTF8-CONT / %xE0-EF 2UTF8-CONT
/ %xF0-F7 3UTF8-CONT / %xF0-F7 3UTF8-CONT
/ %xF8-FB 4UTF8-CONT / %xF8-FB 4UTF8-CONT
/ %xFC-FD 5UTF8-CONT / %xFC-FD 5UTF8-CONT
UTF8-CONT = %x80-BF UTF8-CONT = %x80-BF
21.2. RTSP Protocol Definition 20.2. RTSP Protocol Definition
21.2.1. Generic Protocol elements 20.2.1. Generic Protocol elements
RTSP-IRI = schemes ":" IRI-rest RTSP-IRI = schemes ":" IRI-rest
IRI-rest = ihier-part [ "?" iquery ] [ "#" ifragment ] IRI-rest = ihier-part [ "?" iquery ] [ "#" ifragment ]
ihier-part = "//" iauthority ipath-abempty ihier-part = "//" iauthority ipath-abempty
RTSP-IRI-ref = RTSP-IRI / irelative-ref RTSP-IRI-ref = RTSP-IRI / irelative-ref
irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ] irelative-ref = irelative-part [ "?" iquery ] [ "#" ifragment ]
irelative-part = "//" iauthority ipath-abempty irelative-part = "//" iauthority ipath-abempty
/ ipath-absolute / ipath-absolute
/ ipath-noscheme / ipath-noscheme
/ ipath-empty / ipath-empty
skipping to change at page 148, line 39 skipping to change at page 132, line 39
fraction = 1*DIGIT fraction = 1*DIGIT
feature-tag = token feature-tag = token
session-id = 1*256( ALPHA / DIGIT / safe ) session-id = 1*256( ALPHA / DIGIT / safe )
extension-header = header-name HCOLON header-value extension-header = header-name HCOLON header-value
header-name = token header-name = token
header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) header-value = *(TEXT-UTF8char / UTF8-CONT / LWS)
21.2.2. Message Syntax 20.2.2. Message Syntax
RTSP-message = Request / Response ;RTSP/2.0 messages RTSP-message = Request / Response ;RTSP/2.0 messages
Request = Request-Line Request = Request-Line
*(general-header *(general-header
/ request-header / request-header
/ entity-header ) / entity-header )
CRLF CRLF
[ message-body ] [ message-body ]
Response = Status-Line Response = Status-Line
skipping to change at page 152, line 35 skipping to change at page 136, line 17
/ Content-Base / Content-Base
/ Content-Encoding / Content-Encoding
/ Content-Language / Content-Language
/ Content-Length / Content-Length
/ Content-Location / Content-Location
/ Content-Type / Content-Type
/ Expires / Expires
/ Last-Modified / Last-Modified
/ extension-header / extension-header
21.2.3. Header Syntax 20.2.3. Header Syntax
All header syntaxes not defined in this section are defined in All header syntaxes not defined in this section are defined in
section 14 of the HTTP 1.1 specification [RFC2616]. section 14 of the HTTP 1.1 specification [RFC2616].
Accept = "Accept" HCOLON Accept = "Accept" HCOLON
[ accept-range *(COMMA accept-range) ] [ accept-range *(COMMA accept-range) ]
accept-range = media-range *(SEMI accept-param) accept-range = media-range *(SEMI accept-param)
media-range = ( "*/*" media-range = ( "*/*"
/ ( m-type SLASH "*" ) / ( m-type SLASH "*" )
/ ( m-type SLASH m-subtype ) / ( m-type SLASH m-subtype )
skipping to change at page 158, line 21 skipping to change at page 142, line 21
/ SEMI "ssrc" EQUAL ssrc *(SLASH ssrc) / SEMI "ssrc" EQUAL ssrc *(SLASH ssrc)
/ SEMI "client_ssrc" EQUAL ssrc / SEMI "client_ssrc" EQUAL 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 trn-param-ext / SEMI trn-param-ext
/ SEMI "setup" EQUAL contrans-setup / SEMI "setup" EQUAL contrans-setup
/ SEMI "connection" EQUAL contrans-con / SEMI "connection" EQUAL contrans-con
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 / DQ *TEXT DQ) trn-par-value = *(rtsp-unreserved / DQ *TEXT DQ)
ttl = 1*3DIGIT ; 0 to 255 ttl = 1*3DIGIT ; 0 to 255
ssrc = 8HEX ssrc = 8HEX
channel = 1*3DIGIT channel = 1*3DIGIT
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]
skipping to change at page 159, line 34 skipping to change at page 143, line 34
sent-protocol = protocol-name SLASH protocol-version sent-protocol = protocol-name SLASH protocol-version
SLASH transport-prot SLASH transport-prot
protocol-name = "RTSP" / token protocol-name = "RTSP" / token
protocol-version = token protocol-version = token
transport-prot = "UDP" / "TCP" / "TLS" / other-transport transport-prot = "UDP" / "TCP" / "TLS" / other-transport
other-transport = token other-transport = token
sent-by = host [ COLON port ] sent-by = host [ COLON port ]
WWW-Authenticate = "WWW-Authenticate" HCOLON challenge WWW-Authenticate = "WWW-Authenticate" HCOLON challenge
21.3. SDP extension Syntax 20.3. SDP extension Syntax
This section defines in ABNF the SDP extensions defined for RTSP. This section defines in ABNF the SDP extensions defined for RTSP.
See Appendix C for the definition of the extensions in text. See Appendix D for the definition of the extensions in text.
control-attribute = "a=control:" *SP RTSP-URI control-attribute = "a=control:" *SP RTSP-URI
a-range-def = "a=range:" ranges-spec CRLF a-range-def = "a=range:" ranges-spec CRLF
a-etag-def = "a=etag:" entity-tag CRLF a-etag-def = "a=etag:" entity-tag CRLF
22. Security Considerations 21. Security Considerations
Because of the similarity in syntax and usage between RTSP servers Because of the similarity in syntax and usage between RTSP servers
and HTTP servers, the security considerations outlined in [H15] and HTTP servers, the security considerations outlined in [H15]
apply. Specifically, please note the following: apply. Specifically, please note the following:
Abuse of Server Log Information: RTSP and HTTP servers will Abuse of Server Log Information: RTSP and HTTP servers will
presumably have similar logging mechanisms, and thus should be presumably have similar logging mechanisms, and thus should be
equally guarded in protecting the contents of those logs, thus equally guarded in protecting the contents of those logs, thus
protecting the privacy of the users of the servers. See protecting the privacy of the users of the servers. See
[H15.1.1] for HTTP server recommendations regarding server [H15.1.1] for HTTP server recommendations regarding server
skipping to change at page 161, line 22 skipping to change at page 145, line 22
In addition to the recommendations in the current HTTP specification In addition to the recommendations in the current HTTP specification
(RFC 2616 [RFC2616], as of this writing) and also of the previous (RFC 2616 [RFC2616], as of this writing) and also of the previous
RFC2068 [RFC2068], future HTTP specifications may provide additional RFC2068 [RFC2068], future HTTP specifications may provide additional
guidance on security issues. guidance on security issues.
The following are added considerations for RTSP implementations. The following are added considerations for RTSP implementations.
Concentrated denial-of-service attack: The protocol offers the Concentrated denial-of-service attack: The protocol offers the
opportunity for a remote-controlled denial-of-service attack. opportunity for a remote-controlled denial-of-service attack.
See Section 22.1. See Section 21.1.
Session hijacking: Since there is no or little relation between a Session hijacking: Since there is no or little relation between a
transport layer connection and an RTSP session, it is possible transport layer connection and an RTSP session, it is possible
for a malicious client to issue requests with random session for a malicious client to issue requests with random session
identifiers which would affect unsuspecting clients. The identifiers which would affect unsuspecting clients. The
server SHOULD use a large, random and non-sequential session server SHOULD use a large, random and non-sequential session
identifier to minimize the possibility of this kind of attack. identifier to minimize the possibility of this kind of attack.
However, unless the RTSP signalling always are confedentiality However, unless the RTSP signalling always are confedentiality
protected, e.g. using TLS, an on-path attacker will be able to protected, e.g. using TLS, an on-path attacker will be able to
hijack a session. For real session security, client hijack a session. For real session security, client
skipping to change at page 162, line 14 skipping to change at page 146, line 14
local security policy. local security policy.
Scope of Multicast: If RTSP is used to control the transmission of Scope of Multicast: If RTSP is used to control the transmission of
media onto a multicast network it is need to consider the scope media onto a multicast network it is need to consider the scope
that delivery has. RTSP supports the TTL Transport header that delivery has. RTSP supports the TTL Transport header
parameter to indicate this scope. However such scope control parameter to indicate this scope. However such scope control
is risk as it may be set to large and distribute media beyond is risk as it may be set to large and distribute media beyond
the intended scope. the intended scope.
TLS through proxies: If one uses the possibility to connect TLS in TLS through proxies: If one uses the possibility to connect TLS in
multiple legs (Section 20.3 one really needs to be aware of the multiple legs (Section 19.3 one really needs to be aware of the
trust model. That procedure requires full faith and trust in trust model. That procedure requires full faith and trust in
all proxies that one allows to connect through. They are man all proxies that one allows to connect through. They are man
in the middle and has access to all that goes on over the TLS in the middle and has access to all that goes on over the TLS
connection. Thus it is important to consider if that trust connection. Thus it is important to consider if that trust
model is acceptable in the actual application. model is acceptable in the actual application.
22.1. Remote denial of Service Attack 21.1. Remote denial of Service Attack
The attacker may initiate traffic flows to one or more IP addresses The attacker may initiate traffic flows to one or more IP addresses
by specifying them as the destination in SETUP requests. While the by specifying them as the destination in SETUP requests. While the
attacker's IP address may be known in this case, this is not always attacker's IP address may be known in this case, this is not always
useful in prevention of more attacks or ascertaining the attackers useful in prevention of more attacks or ascertaining the attackers
identity. Thus, an RTSP server MUST only allow client-specified identity. Thus, an RTSP server MUST only allow client-specified
destinations for RTSP-initiated traffic flows if the server has destinations for RTSP-initiated traffic flows if the server has
ensured that the specified destination address accepts receiving ensured that the specified destination address accepts receiving
media through different security mechanisms. Security mechanism that media through different security mechanisms. Security mechanism that
are acceptable in an increased generality are; verification of the are acceptable in an increased generality are; verification of the
skipping to change at page 164, line 5 skipping to change at page 148, line 5
indication as a valid media destination is very low. If the server indication as a valid media destination is very low. If the server
include in its STUN requests a cookie (consisting of random material) include in its STUN requests a cookie (consisting of random material)
that is the destination echo back the solution is also safe against that is the destination echo back the solution is also safe against
having a off-path attacker being able to spoof the STUN checks. having a off-path attacker being able to spoof the STUN checks.
Leaving this solution vulnerable only to on-path attackers that can Leaving this solution vulnerable only to on-path attackers that can
see the STUN requests go to the target of attack. see the STUN requests go to the target of attack.
For delivery to multicast addresses there is need for another For delivery to multicast addresses there is need for another
solution which is not specified here. solution which is not specified here.
23. IANA Considerations 22. IANA Considerations
This section sets up a number of registries for RTSP 2.0 that should This section sets up a number of registries for RTSP 2.0 that should
be maintained by IANA. For each registry there is a description on be maintained by IANA. For each registry there is a description on
what it is required to contain, what specification is needed when what it is required to contain, what specification is needed when
adding a entry with IANA, and finally the entries that this document adding a entry with IANA, and finally the entries that this document
needs to register. See also the Section 2.2 "Extending RTSP". There needs to register. See also the Section 2.3 "Extending RTSP". There
is also an IANA registration of two SDP attributes. is also an IANA registration of two SDP attributes.
The sections describing how to register an item uses some of the The sections describing how to register an item uses some of the
requirements level described in RFC 2434 [RFC2434], namely "First requirements level described in RFC 2434 [RFC2434], namely "First
Come, First Served", "Specification Required", and "Standards Come, First Served", "Specification Required", and "Standards
Action". Action".
A registration request to IANA MUST contain the following A registration request to IANA MUST contain the following
information: information:
skipping to change at page 164, line 38 skipping to change at page 148, line 38
or an individual); or an individual);
o A reference to a further description, if available, for example o A reference to a further description, if available, for example
(in order of preference) an RFC, a published standard, a published (in order of preference) an RFC, a published standard, a published
paper, a patent filing, a technical report, documented source code paper, a patent filing, a technical report, documented source code
or a computer manual; or a computer manual;
o For proprietary features, contact information (postal and email o For proprietary features, contact information (postal and email
address); address);
23.1. Feature-tags 22.1. Feature-tags
23.1.1. Description 22.1.1. Description
When a client and server try to determine what part and functionality When a client and server try to determine what part and functionality
of the RTSP specification and any future extensions that its counter of the RTSP specification and any future extensions that its counter
part implements there is need for a namespace. This registry part implements there is need for a namespace. This registry
contains named entries representing certain functionality. contains named entries representing certain functionality.
The usage of feature-tags is explained in Section 11 and The usage of feature-tags is explained in Section 11 and
Section 13.1. Section 13.1.
23.1.2. Registering New Feature-tags with IANA 22.1.2. Registering New Feature-tags with IANA
The registering of feature-tags is done on a first come, first served The registering of feature-tags is done on a first come, first served
basis. basis.
The name of the feature MUST follow these rules: The name may be of The name of the feature MUST follow these rules: The name may be of
any length, but SHOULD be no more than twenty characters long. The any length, but SHOULD be no more than twenty characters long. The
name MUST NOT contain any spaces, or control characters. The name MUST NOT contain any spaces, or control characters. The
registration SHALL indicate if the feature-tag applies to clients, registration SHALL indicate if the feature-tag applies to clients,
servers, or proxies only or any combinations of these. Any servers, or proxies only or any combinations of these. Any
proprietary feature SHALL have as the first part of the name a vendor proprietary feature SHALL have as the first part of the name a vendor
tag, which identifies the organization. tag, which identifies the organization.
23.1.3. Registered entries 22.1.3. Registered entries
The following feature-tags are in this specification defined and The following feature-tags are in this specification defined and
hereby registered. The change control belongs to the IETF. hereby registered. The change control belongs to the IETF.
play.basic: The minimal implementation for playback operations play.basic: The minimal implementation for playback operations
according to Appendix D. Applies for both clients, servers and according to Appendix E. Applies for both clients, servers and
proxies. proxies.
play.scale: Support of scale operations for media playback. Applies play.scale: Support of scale operations for media playback. Applies
only for servers. only for servers.
play.speed: Support of the speed functionality for playback. play.speed: Support of the speed functionality for playback.
Applies only for servers. Applies only for servers.
23.2. RTSP Methods 22.2. RTSP Methods
23.2.1. Description 22.2.1. Description
What a method is, is described in section Section 13. Extending the What a method is, is described in section Section 13. Extending the
protocol with new methods allow for totally new functionality. protocol with new methods allow for totally new functionality.
23.2.2. Registering New Methods with IANA 22.2.2. Registering New Methods with IANA
A new method MUST be registered through an IETF standard track A new method MUST be registered through an IETF standard track
document. The reason is that new methods may radically change the document. The reason is that new methods may radically change the
protocols behavior and purpose. protocols behavior and purpose.
A specification for a new RTSP method MUST consist of the following A specification for a new RTSP method MUST consist of the following
items: items:
o A method name which follows the ABNF rules for methods. o A method name which follows the ABNF rules for methods.
o A clear specification on what action and response a request with o A clear specification on what action and response a request with
the method will result in. Which directions the method is used, the method will result in. Which directions the method is used,
C->S or S->C or both. How the use of headers, if any, modifies C->S or S->C or both. How the use of headers, if any, modifies
the behavior and effect of the method. the behavior and effect of the method.
o A list or table specifying which of the registered headers that o A list or table specifying which of the registered headers that
are allowed to use with the method in request or/and response. are allowed to use with the method in request or/and response.
o Describe how the method relates to network proxies. o Describe how the method relates to network proxies.
23.2.3. Registered Entries 22.2.3. Registered Entries
This specification, RFCXXXX, registers 9 methods: DESCRIBE, This specification, RFCXXXX, registers 9 methods: DESCRIBE,
GET_PARAMETER, OPTIONS, PAUSE, PLAY, REDIRECT, SETUP, SETPARAMETER, GET_PARAMETER, OPTIONS, PAUSE, PLAY, REDIRECT, SETUP, SETPARAMETER,
and TEARDOWN. and TEARDOWN.
23.3. RTSP Status Codes 22.3. RTSP Status Codes
23.3.1. Description 22.3.1. Description
A status code is the three digit numbers used to convey information A status code is the three digit numbers used to convey information
in RTSP response messages, seeSection 8. The number space is limited in RTSP response messages, seeSection 8. The number space is limited
and care should be taken not to fill the space. and care should be taken not to fill the space.
23.3.2. Registering New Status Codes with IANA 22.3.2. Registering New Status Codes with IANA
A new status code can only be registered by an IETF standards track A new status code can only be registered by an IETF standards track
document. A specification for a new status code MUST specify the document. A specification for a new status code MUST specify the
following: following:
o The requested number. o The requested number.
o A description what the status code means and the expected behavior o A description what the status code means and the expected behavior
of the sender and receiver of the code. of the sender and receiver of the code.
23.3.3. Registered Entries 22.3.3. Registered Entries
RFCXXX, registers the numbered status code defined in the ABNF entry RFCXXX, registers the numbered status code defined in the ABNF entry
"Status-Code" except "extension-code" in Section 21.2.2. "Status-Code" except "extension-code" in Section 20.2.2.
23.4. RTSP Headers 22.4. RTSP Headers
23.4.1. Description 22.4.1. Description
By specifying new headers a method(s) can be enhanced in many By specifying new headers a method(s) can be enhanced in many
different ways. An unknown header will be ignored by the receiving different ways. An unknown header will be ignored by the receiving
entity. If the new header is vital for a certain functionality, a entity. If the new header is vital for a certain functionality, a
feature-tag for the functionality can be created and demanded to be feature-tag for the functionality can be created and demanded to be
used by the counter-part with the inclusion of a Require header used by the counter-part with the inclusion of a Require header
carrying the feature-tag. carrying the feature-tag.
23.4.2. Registering New Headers with IANA 22.4.2. Registering New Headers with IANA
A public available specification is required to register a header. A public available specification is required to register a header.
The specification SHOULD be a standards document, preferable an IETF The specification SHOULD be a standards document, preferable an IETF
RFC. RFC.
The specification MUST contain the following information: The specification MUST contain the following information:
o The name of the header. o The name of the header.
o An ABNF specification of the header syntax. o An ABNF specification of the header syntax.
o A list or table specifying when the header may be used, o A list or table specifying when the header may be used,
encompassing all methods, their request or response, the direction encompassing all methods, their request or response, the direction
(C->S or S->C). (C->S or S->C).
o How the header is to be handled by proxies. o How the header is to be handled by proxies.
o A description of the purpose of the header. o A description of the purpose of the header.
23.4.3. Registered entries 22.4.3. Registered entries
All headers specified in Section 16 in RFCXXXX are to be registered. All headers specified in Section 16 in RFCXXXX are to be registered.
Furthermore the following RTSP headers defined in other Furthermore the following RTSP headers defined in other
specifications are registered: specifications are registered:
o x-wap-profile defined in [3gpp-26234]. o x-wap-profile defined in [3gpp-26234].
o x-wap-profile-diff defined in [3gpp-26234]. o x-wap-profile-diff defined in [3gpp-26234].
skipping to change at page 168, line 10 skipping to change at page 152, line 10
o 3GPP-Adaptation defined in [3gpp-26234]. o 3GPP-Adaptation defined in [3gpp-26234].
o 3GPP-QoE-Metrics defined in [3gpp-26234]. o 3GPP-QoE-Metrics defined in [3gpp-26234].
o 3GPP-QoE-Feedback defined in [3gpp-26234]. o 3GPP-QoE-Feedback defined in [3gpp-26234].
The use of "X-" is NOT RECOMMENDED but the above headers in the The use of "X-" is NOT RECOMMENDED but the above headers in the
register list was defined prior to the clarification. register list was defined prior to the clarification.
23.5. Transport Header Registries 22.5. Transport Header Registries
The transport header contains a number of parameters which have The transport header contains a number of parameters which have
possibilities for future extensions. Therefore registries for these possibilities for future extensions. Therefore registries for these
needs to be defined. needs to be defined.
23.5.1. Transport Protocol Specification 22.5.1. Transport Protocol Specification
A registry for the parameter transport-protocol specification SHALL A registry for the parameter transport-protocol specification SHALL
be defined with the following rules: be defined with the following rules:
o Registering require an public available standards specification. o Registering require an public available standards specification.
o A contact person or organization with address and email. o A contact person or organization with address and email.
o A value definition that are following the ABNF syntax definition. o A value definition that are following the ABNF syntax definition.
o A describing text that explains how the registered value are used o A describing text that explains how the registered value are used
in RTSP. in RTSP.
This specification registers the following values: This specification registers the following values:
RTP/AVP: Use of the RTP[RFC3550] protocol for media transport in RTP/AVP: Use of the RTP[RFC3550] protocol for media transport in
combination with the "RTP profile for audio and video combination with the "RTP profile for audio and video
conferences with minimal control"[RFC3551] over UDP. The usage conferences with minimal control"[RFC3551] over UDP. The usage
is explained in RFC XXXX, appendix Appendix B.1. is explained in RFC XXXX, appendix Appendix C.1.
RTP/AVP/UDP: the same as RTP/AVP. RTP/AVP/UDP: the same as RTP/AVP.
RTP/AVPF: Use of the RTP[RFC3550] protocol for media transport in RTP/AVPF: Use of the RTP[RFC3550] protocol for media transport in
combination with the "Extended RTP Profile for RTCP-based combination with the "Extended RTP Profile for RTCP-based
Feedback (RTP/AVPF)"[RFC4585] over UDP. The usage is explained Feedback (RTP/AVPF)"[RFC4585] over UDP. The usage is explained
in RFC XXXX, appendix Appendix B.1. in RFC XXXX, appendix Appendix C.1.
RTP/AVPF/UDP: the same as RTP/AVPF. RTP/AVPF/UDP: the same as RTP/AVPF.
RTP/SAVP: Use of the RTP[RFC3550] protocol for media transport in RTP/SAVP: Use of the RTP[RFC3550] protocol for media transport in
combination with the "The Secure Real-time Transport Protocol combination with the "The Secure Real-time Transport Protocol
(SRTP)" [RFC3711] over UDP. The usage is explained in RFC (SRTP)" [RFC3711] over UDP. The usage is explained in RFC
XXXX, appendix Appendix B.1. XXXX, appendix Appendix C.1.
RTP/SAVP/UDP: the same as RTP/SAVP. RTP/SAVP/UDP: the same as RTP/SAVP.
RTP/SAVPF: Use of the RTP[RFC3550] protocol for media transport in RTP/SAVPF: Use of the RTP[RFC3550] protocol for media transport in
combination with the "[I-D.ietf-avt-profile-savpf] over UDP. combination with the "[I-D.ietf-avt-profile-savpf] over UDP.
The usage is explained in RFC XXXX, appendix Appendix B.1. The usage is explained in RFC XXXX, appendix Appendix C.1.
RTP/SAVPF/UDP: the same as RTP/SAVPF. RTP/SAVPF/UDP: the same as RTP/SAVPF.
RTP/AVP/TCP: Use of the RTP[RFC3550] protocol for media transport in RTP/AVP/TCP: Use of the RTP[RFC3550] protocol for media transport in
combination with the "RTP profile for audio and video combination with the "RTP profile for audio and video
conferences with minimal control"[RFC3551] over TCP. The usage conferences with minimal control"[RFC3551] over TCP. The usage
is explained in RFC XXXX, appendix Appendix B.2.2. is explained in RFC XXXX, appendix Appendix C.2.2.
RTP/AVPF/TCP: Use of the RTP[RFC3550] protocol for media transport RTP/AVPF/TCP: Use of the RTP[RFC3550] protocol for media transport
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 Appendix B.2.2. in RFC XXXX, appendix 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 Appendix B.2.2. RFC XXXX, appendix 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 "[I-D.ietf-avt-profile-savpf] over TCP. in combination with the "[I-D.ietf-avt-profile-savpf] over TCP.
The usage is explained in RFC XXXX, appendix Appendix B.2.2. The usage is explained in RFC XXXX, appendix Appendix C.2.2.
23.5.2. Transport modes 22.5.2. Transport modes
A registry for the transport parameter mode SHALL be defined with the A registry for the transport parameter mode SHALL be defined with the
following rules: following rules:
o Registering requires an IETF standard tracks document. o Registering requires an IETF standard tracks document.
o A contact person or organization with address and email. o A contact person or organization with address and email.
o A value definition that are following the ABNF token definition. o A value definition that are following the ABNF token definition.
o A describing text that explains how the registered value are used o A describing text that explains how the registered value are used
in RTSP. in RTSP.
This specification registers 1 value: This specification registers 1 value:
PLAY: See RFC XXXX. PLAY: See RFC XXXX.
23.5.3. Transport Parameters 22.5.3. Transport Parameters
A registry for parameters that may be included in the Transport A registry for parameters that may be included in the Transport
header SHALL be defined with the following rules: header SHALL be defined with the following rules:
o Registering required a Open Standards document. o Registering required a Open Standards document.
o A value definition that are following the ABNF token definition. o A value definition that are following the ABNF token definition.
o A describing text that explains how the registered value are used o A describing text that explains how the registered value are used
in RTSP. in RTSP.
This specification registers all the transport parameters defined in This specification registers all the transport parameters defined in
Section 16.46. Section 16.46.
23.6. Cache Directive Extensions 22.6. Cache Directive Extensions
There exist a number of cache directives which can be sent in the There exist a number of cache directives which can be sent in the
Cache-Control header. A registry for this cache directives SHALL be Cache-Control header. A registry for this cache directives SHALL be
defined with the following rules: defined with the following rules:
o Registering requires an IETF standard tracks document. o Registering requires an IETF standard tracks document.
o A registration is required to contain a contact person. o A registration is required to contain a contact person.
o Name of the directive and a definition of the value, if any. o Name of the directive and a definition of the value, if any.
skipping to change at page 171, line 13 skipping to change at page 155, line 13
max-stale: max-stale:
min-fresh: min-fresh:
must-revalidate: must-revalidate:
proxy-revalidate: proxy-revalidate:
max-age: max-age:
23.7. Accept-Credentials 22.7. Accept-Credentials
The security framework's TLS connection mechanism has two The security framework's TLS connection mechanism has two
registerable entities. registerable entities.
23.7.1. Accept-Credentials policies 22.7.1. Accept-Credentials policies
In Section 20.3.1 three policies for how to handle certificates. In Section 19.3.1 three policies for how to handle certificates.
Further policies may be defined and SHALL be registered with IANA Further policies may be defined and SHALL be registered with IANA
using the following rules: using the following rules:
o Registering requires an IETF standard tracks document. o Registering requires an IETF standard tracks document.
o A registration is required name a contact person. o A registration is required name a contact person.
o Name of the policy. o Name of the policy.
o A describing text that explains how the policy works for handling o A describing text that explains how the policy works for handling
the certificates. the certificates.
This specification registers the following values: This specification registers the following values:
Any Any
Proxy Proxy
User User
23.7.2. Accept-Credentials hash algorithms 22.7.2. Accept-Credentials hash algorithms
The Accept-Credentials header (See Section 16.2) allows for the usage The Accept-Credentials header (See Section 16.2) allows for the usage
of other algorithms for hashing the DER records of accepted entities. of other algorithms for hashing the DER records of accepted entities.
The registration of any future algorithm is expected to be extremely The registration of any future algorithm is expected to be extremely
rare and could also be an interoperability problem. Therefore the rare and could also be an interoperability problem. Therefore the
XXX bare for registering new algorithms is placed intentional high. XXX bare for registering new algorithms is placed intentional high.
Any registration of a new hash algorithm SHALL meet the following Any registration of a new hash algorithm SHALL meet the following
requirement: requirement:
o Registration requires an IETF standard track document. o Registration requires an IETF standard track document.
o A definition of the algorithm and its identifier meeting the o A definition of the algorithm and its identifier meeting the
"token" ABNF requirement. "token" ABNF requirement.
23.8. Range header formats 22.8. Range header formats
The Range header allows for different range formats. New ones may be The Range header allows for different range formats. New ones may be
registered, but moderation should be applied as it makes registered, but moderation should be applied as it makes
interoperability more difficult. A registration SHALL fulfill the interoperability more difficult. A registration SHALL fulfill the
following requirements: following requirements:
o A publicly available standards document. o A publicly available standards document.
o A ABNF definition of the range format that fulfils the "range-ext" o A ABNF definition of the range format that fulfils the "range-ext"
definition. definition.
o A Contact person for the registration. o A Contact person for the registration.
o Rules for how one handles the range when using a negative Scale. o Rules for how one handles the range when using a negative Scale.
23.9. URI Schemes 22.9. URI Schemes
This specification defines two URI schemes ("rtsp" and "rtsps") and This specification defines two URI schemes ("rtsp" and "rtsps") and
reserves a third one ("rtspu"). Registrations are following RFC reserves a third one ("rtspu"). Registrations are following RFC
4395[RFC4395]. 4395[RFC4395].
23.9.1. The rtsp URI Scheme 22.9.1. The rtsp URI Scheme
URI scheme name: rtsp URI scheme name: rtsp
Status: Permanent Status: Permanent
URI scheme syntax: See Section 21.2.1 of RFC XXXX. URI scheme syntax: See Section 20.2.1 of RFC XXXX.
URI scheme semantics: The rtsp scheme is used to indicate resources URI scheme semantics: The rtsp scheme is used to indicate resources
accessible through the usage of the Real-time Streaming accessible through the usage of the Real-time Streaming
Protocol (RTSP). RTSP allows different operations on the Protocol (RTSP). RTSP allows different operations on the
resource identified by the URI, but the primary purpose is the resource identified by the URI, but the primary purpose is the
streaming delivery of the resource to a client. However the streaming delivery of the resource to a client. However the
operations that are currently defined are: Describing the operations that are currently defined are: Describing the
resource for the purpose of configuring the receiving entity resource for the purpose of configuring the receiving entity
(DESCRIBE), configuring the delivery method and its addressing (DESCRIBE), configuring the delivery method and its addressing
(SETUP), controlling the delivery (PLAY and PAUSE), reading or (SETUP), controlling the delivery (PLAY and PAUSE), reading or
skipping to change at page 173, line 26 skipping to change at page 157, line 26
Section 7 of RFC 3986 applies also to this scheme. They needs Section 7 of RFC 3986 applies also to this scheme. They needs
to be reviewed and considered in any implementation utilizing to be reviewed and considered in any implementation utilizing
this scheme. this scheme.
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
Author/Change controller: IETF MMUSIC WG Author/Change controller: IETF MMUSIC WG
References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX
23.9.2. The rtsps URI Scheme 22.9.2. The rtsps URI Scheme
URI scheme name: rtsps URI scheme name: rtsps
Status: Permanent Status: Permanent
URI scheme syntax: See Section 21.2.1 of RFC XXXX. URI scheme syntax: See Section 20.2.1 of RFC XXXX.
URI scheme semantics: The rtsps scheme is used to indicate resources URI scheme semantics: The rtsps scheme is used to indicate resources
accessible through the usage of the Real-time Streaming accessible through the usage of the Real-time Streaming
Protocol (RTSP) over TLS. RTSP allows different operations on Protocol (RTSP) over TLS. RTSP allows different operations on
the resource identified by the URI, but the primary purpose is the resource identified by the URI, but the primary purpose is
the streaming delivery of the resource to a client. However the streaming delivery of the resource to a client. However
the operations that are currently defined are: Describing the the operations that are currently defined are: Describing the
resource for the purpose of configuring the receiving entity resource for the purpose of configuring the receiving entity
(DESCRIBE), configuring the delivery method and its addressing (DESCRIBE), configuring the delivery method and its addressing
(SETUP), controlling the delivery (PLAY and PAUSE), reading or (SETUP), controlling the delivery (PLAY and PAUSE), reading or
skipping to change at page 174, line 22 skipping to change at page 158, line 22
Section 7 of RFC 3986 applies also to this scheme. They needs Section 7 of RFC 3986 applies also to this scheme. They needs
to be reviewed and considered in any implementation utilizing to be reviewed and considered in any implementation utilizing
this scheme. this scheme.
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
Author/Change controller: IETF MMUSIC WG Author/Change controller: IETF MMUSIC WG
References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX References: RFC 2326, RFC 3986, RFC 3987, RFC XXXX
23.9.3. The rtspu URI Scheme 22.9.3. The rtspu URI Scheme
URI scheme name: rtspu URI scheme name: rtspu
Status: Permanent Status: Permanent
URI scheme syntax: See Section 3.2 of RFC 2326. URI scheme syntax: See Section 3.2 of RFC 2326.
URI scheme semantics: The rtspu scheme is used to indicate resources URI scheme semantics: The rtspu scheme is used to indicate resources
accessible through the usage of the Real-time Streaming accessible through the usage of the Real-time Streaming
Protocol (RTSP) over unrelaible datagram transport. RTSP Protocol (RTSP) over unrelaible datagram transport. RTSP
skipping to change at page 175, line 19 skipping to change at page 159, line 19
Section 7 of RFC 3986 applies also to this scheme. They needs Section 7 of RFC 3986 applies also to this scheme. They needs
to be reviewed and considered in any implementation utilizing to be reviewed and considered in any implementation utilizing
this scheme. this scheme.
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
Author/Change controller: IETF MMUSIC WG Author/Change controller: IETF MMUSIC WG
References: RFC 2326, RFC 3986, RFC 3987 References: RFC 2326, RFC 3986, RFC 3987
23.10. SDP attributes 22.10. SDP attributes
This specification defines two SDP [RFC4566] attributes that it is This specification defines two SDP [RFC4566] attributes that it is
requested that IANA register. requested that IANA register.
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: range Attribute name: range
Long form: Media Range Attribute Long form: Media Range Attribute
Type of name: att-field Type of name: att-field
Type of attribute: Media and session level Type of attribute: Media and session level
skipping to change at page 176, line 5 skipping to change at page 160, line 5
Attribute name: etag Attribute name: etag
Long form: Entity Tag Long form: Entity Tag
Type of name: att-field Type of name: att-field
Type of attribute: Media and session level Type of attribute: Media and session level
Subject to charset: No Subject to charset: No
Purpose: RFC XXXX Purpose: RFC XXXX
Reference: RFC XXXX Reference: RFC XXXX
Values: See ABNF definition Values: See ABNF definition
24. References 23. References
24.1. Normative References 23.1. Normative References
[3gpp-26234] [3gpp-26234]
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", Augusti 2002. (FIPS PUBS) 180-2: Secure Hash Standard", Augusti 2002.
[I-D.ietf-avt-profile-savpf] [I-D.ietf-avt-profile-savpf]
Ott, J. and E. Carrara, "Extended Secure RTP Profile for Ott, J. and E. Carrara, "Extended Secure RTP Profile for
RTCP-based Feedback (RTP/SAVPF)", RTCP-based Feedback (RTP/SAVPF)",
draft-ietf-avt-profile-savpf-11 (work in progress), draft-ietf-avt-profile-savpf-12 (work in progress),
July 2007. November 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.
[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.
skipping to change at page 178, line 23 skipping to change at page 162, line 23
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.
24.2. Informative References 23.2. Informative References
[I-D.ietf-mmusic-rtsp-nat] [I-D.ietf-mmusic-rtsp-nat]
Westerlund, M. and T. Zeng, "An Network Address Translator Westerlund, M. and T. Zeng, "An Network Address Translator
(NAT) Traversal mechanism for media controlled by Real- (NAT) Traversal mechanism for media controlled by Real-
Time Streaming Protocol (RTSP)", Time Streaming Protocol (RTSP)",
draft-ietf-mmusic-rtsp-nat-05 (work in progress), draft-ietf-mmusic-rtsp-nat-05 (work in progress),
July 2007. July 2007.
[ISO.13818-1.2000] [ISO.13818-1.2000]
International Organization for Standardization, International Organization for Standardization,
skipping to change at page 181, line 5 skipping to change at page 165, line 5
Miller, J., Krauskopf, T., Resnick, P., and W. Treese, Miller, J., Krauskopf, T., Resnick, P., and W. Treese,
"PICS label distribution label syntax and communication "PICS label distribution label syntax and communication
protocols", W3C REC-PICS-labels-961031. protocols", W3C REC-PICS-labels-961031.
[W3C.REC-PICS-services] [W3C.REC-PICS-services]
Miller, J., Resnick, P., and D. Singer, "Rating services Miller, J., Resnick, P., and D. Singer, "Rating services
and rating systems (and their machine readable and rating systems (and their machine readable
descriptions)", W3C REC-PICS-services-961031, descriptions)", W3C REC-PICS-services-961031,
October 1996. October 1996.
Appendix A. RTSP Protocol State Machine Appendix A. Examples
This section contains several different examples trying to illustrate
possible ways of using RTSP. The examples can also help with the
understanding of how functions of RTSP work. However remember that
this is examples and the normative and syntax description in the
other sections takes precedence. Please also note that many of the
example contain syntax illegal line breaks to accommodate the
formatting restriction that the RFC series impose.
A.1. Media on Demand (Unicast)
The is an example of media on demand streaming of a media stored in a
container file. For purposes of this example, a container file is a
storage entity in which multiple continuous media types pertaining to
the same end-user presentation are present. In effect, the container
file represents an RTSP presentation, with each of its components
being RTSP controlled media streams. Container files are a widely
used means to store such presentations. While the components are
transported as independent streams, it is desirable to maintain a
common context for those streams at the server end.
This enables the server to keep a single storage handle open
easily. It also allows treating all the streams equally in case
of any prioritization of streams by the server.
It is also possible that the presentation author may wish to prevent
selective retrieval of the streams by the client in order to preserve
the artistic effect of the combined media presentation. Similarly,
in such a tightly bound presentation, it is desirable to be able to
control all the streams via a single control message using an
aggregate URI.
The following is an example of using a single RTSP session to control
multiple streams. It also illustrates the use of aggregate URIs. In
a container file it is also desirable to not write any URI parts
which is not kept, when the container is distributed, like the host
and most of the path element. Therefore this example also uses the
"*" and relative URI in the delivered SDP.
Client C requests a presentation from media server M. The movie is
stored in a container file. The client has obtained an RTSP URI to
the container file.
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 257
Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
a=control: *
a=range: npt=0-0:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
m=video 0 RTP/AVP 26
a=control: trackID=4
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: NPT, SMPTE, UTC
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001;
src_addr="192.0.2.5:9000"/"192.0.2.5:9001"
ssrc=93CB001E
Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Session: 12345678
Accept-Ranges: NPT, SMPTE, UTC
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003;
src_addr="192.0.2.5:9002"/"192.0.2.5:9003";
ssrc=A813FC13
Session: 12345678
Expires: 24 Jan 1997 15:35:13 GMT
Date: 23 Jan 1997 15:35:13 GMT
Accept-Range: NPT
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=0-10, npt=30-
Session: 12345678
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678
Range: npt=0-10, npt=30-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1";
ssrc=4F312DD8:seq=54321;rtptime=2876889
C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 5
User-Agent: PhonyClient/1.2
Session: 12345678
M->C: RTSP/2.0 200 OK
CSeq: 5
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:01 GMT
Session: 12345678
Range: npt=34.57-623.10
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 6
User-Agent: PhonyClient/1.2
Range: npt=34.57-623.10
Session: 12345678
M->C: RTSP/2.0 200 OK
CSeq: 6
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:01 GMT
Session: 12345678
Range: npt=34.57-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12555;rtptime=6330012,
url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=55021;rtptime=3132889
A.2. Media on Demand using Pipelining
This example is basically the example above (Appendix A.1), but now
utilizing pipelining to speed up the setup. It requires only two
round trip times until the media starts flowing. First of all, the
session description is retrieved to determine what media resources
need to be setup. In the second step, one sends the necessary SETUP
requests and the PLAY request to initiate media delivery.
Client C requests a presentation from media server M. The movie is
stored in a container file. The client has obtained an RTSP URI to
the container file.
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 257
Content-Base: rtsp://example.com/twister.3gp/
Expires: 24 Jan 1997 15:35:06 GMT
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
a=control: *
a=range: npt=0-0:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
m=video 0 RTP/AVP 26
a=control: trackID=4
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: NPT, SMPTE, UTC
Pipelined-Requests: 7654
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Accept-Ranges: NPT, SMPTE, UTC
Pipelined-Requests: 7654
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=0-10, npt=30-
Session: 12345678
Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001;
src_addr="192.0.2.5:9000"/"192.0.2.5:9001"
ssrc=93CB001E
Session: 12345678
Expires: 24 Jan 1997 15:35:12 GMT
Date: 23 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT
Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003;
src_addr="192.0.2.5:9002"/"192.0.2.5:9003";
ssrc=A813FC13
Session: 12345678
Expires: 24 Jan 1997 15:35:13 GMT
Date: 23 Jan 1997 15:35:13 GMT
Accept-Range: NPT
Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678
Range: npt=0-10, npt=30-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1";
ssrc=4F312DD8:seq=54321;rtptime=2876889
Pipelined-Requests: 7654
A.3. Media on Demand (Unicast)
An alternative example of media on demand with a bit more tweaks is
the following. Client C requests a movie distributed from two
different media servers A (audio.example.com) and V (
video.example.com). The media description is stored on a web server
W. The media description contains descriptions of the presentation
and all its streams, including the codecs that are available, dynamic
RTP payload types, the protocol stack, and content information such
as language or copyright restrictions. It may also give an
indication about the timeline of the movie.
In this example, the client is only interested in the last part of
the movie.
C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
W->C: HTTP/1.0 200 OK
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 264
Expires: 23 Jan 1998 15:35:06 GMT
v=0
o=- 2890844526 2890842807 IN IP4 192.0.2.5
s=RTSP Session
e=adm@example.com
a=range:npt=0-1:49:34
t=0 0
m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC
A->C: RTSP/2.0 200 OK
CSeq: 1
Session: 12345678
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057";
src_addr="192.0.2.5:5000"/"192.0.2.5:5001"
Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0
Expires: 24 Jan 1997 15:35:12 GMT
Cache-Control: public
Accept-Ranges: NPT, SMPTE
C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: NPT, SMPTE, UTC
V->C: RTSP/2.0 200 OK
CSeq: 1
Session: 23456789
Transport: RTP/AVP/UDP;unicast;dest_addr=":3058"/":3059";
src_addr="192.0.2.5:5002"/"192.0.2.5:5003"
Date: 23 Jan 1997 15:35:12 GMT
Server: PhonyServer/1.0
Cache-Control: public
Expires: 24 Jan 1997 15:35:12 GMT
Accept-Ranges: NPT, SMPTE
C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: 23456789
Range: smpte=0:10:00-
V->C: RTSP/2.0 200 OK
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-1:49:23
RTP-Info: url="rtsp://video.example.com/twister/video"
ssrc=A17E189D:seq=12312232;rtptime=78712811
Server: PhonyServer/2.0
Date: 23 Jan 1997 15:35:13 GMT
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: 12345678
Range: smpte=0:10:00-
A->C: RTSP/2.0 200 OK
CSeq: 2
Session: 12345678
Range: smpte=0:10:00-1:49:23
RTP-Info: url="rtsp://audio.example.com/twister/audio.en"
ssrc=3D124F01:seq=876655;rtptime=1032181
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:13 GMT
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: 12345678
A->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:36:52 GMT
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: 23456789
V->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/2.0
Date: 23 Jan 1997 15:36:52 GMT
Even though the audio and video track are on two different servers,
may start at slightly different times, and may drift with respect to
each other, the client can perform initial synchronize of the two
media using RTP-Info and Range received in the PLAY responses. If
the two servers are time synchronized the RTCP packets can also be
used to maintain synchronization.
A.4. Single Stream Container Files
Some RTSP servers may treat all files as though they are "container
files", yet other servers may not support such a concept. Because of
this, clients needs to use the rules set forth in the session
description for Request-URIs, rather than assuming that a consistent
URI may always be used throughout. Below are an example of how a
multi-stream server might expect a single-stream file to be served:
C->S: DESCRIBE rtsp://foo.com/test.wav RTSP/2.0
Accept: application/x-rtsp-mh, application/sdp
CSeq: 1
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 1
Content-base: rtsp://foo.com/test.wav/
Content-type: application/sdp
Content-length: 148
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT
Expires: 23 Jan 1997 17:00:00 GMT
v=0
o=- 872653257 872653257 IN IP4 192.0.2.5
s=mu-law wave file
i=audio test
t=0 0
a=control: *
m=audio 0 RTP/AVP 0
a=control:streamid=0
C->S: SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/2.0
Transport: RTP/AVP/UDP;unicast;
dest_addr=":6970"/":6971";mode="PLAY"
CSeq: 2
User-Agent: PhonyClient/1.2
Accept-Ranges: NPT, SMPTE, UTC
S->C: RTSP/2.0 200 OK
Transport: RTP/AVP/UDP;unicast;dest_addr=":6970"/":6971";
src_addr="192.0.2.5:6970"/"192.0.2.5:6971";
mode="PLAY";ssrc=EAB98712
CSeq: 2
Session: 2034820394
Expires: 23 Jan 1997 16:00:00 GMT
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:07 GMT
Accept-Ranges: NPT
C->S: PLAY rtsp://foo.com/test.wav/ RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: 2034820394
S->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:08 GMT
Session: 2034820394
Range: npt=0-600
RTP-Info: url="rtsp://foo.com/test.wav/streamid=0"
ssrc=0D12F123:seq=981888;rtptime=3781123
Note the different URI in the SETUP command, and then the switch back
to the aggregate URI in the PLAY command. This makes complete sense
when there are multiple streams with aggregate control, but is less
than intuitive in the special case where the number of streams is
one. However the server has declared that the aggregated control URI
in the SDP and therefore this is legal.
In this case, it is also required that servers accept implementations
that use the non-aggregated interpretation and use the individual
media URI, like this:
C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
A.5. Live Media Presentation Using Multicast
The media server M chooses the multicast address and port. Here, it
is assumed that the web server only contains a pointer to the full
description, while the media server M maintains the full description.
C->W: GET /sessions.html HTTP/1.1
Host: www.example.com
W->C: HTTP/1.1 200 OK
Content-Type: text/html
<html>
...
<href "Streamed Live Music performance"
src="rtsp://live.example.com/concert/audio">
...
</html>
C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 1
Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: 182
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT
Supported: play.basic
v=0
o=- 2890844526 2890842807 IN IP4 192.0.2.5
s=RTSP Session
m=audio 3456 RTP/AVP 0
c=IN IP4 224.2.0.1/16
a=control: rtsp://live.example.com/concert/audio
a=range:npt=0-
C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 2
Transport: RTP/AVP;multicast
Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:06 GMT
Transport: RTP/AVP;multicast;dest_addr="224.2.0.1:3456"/"
224.2.0.1:3457";ttl=16
Session: 0456804596
Accept-Ranges: NPT, UTC
C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 3
Session: 0456804596
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:07 GMT
Session: 0456804596
Range:npt=1256-
RTP-Info: url="rtsp://live.example.com/concert/audio"
ssrc=0D12F123:seq=1473; rtptime=80000
A.6. Capability Negotiation
This examples illustrate how the client and server determines their
capability to support a special feature, in this case "play.scale".
The server, through the clients request and the included Supported
header, learns the client supports RTSP 2.0, and also supports the
playback time scaling feature of RTSP. The server's response
contains the following feature related information to the client; it
supports the basic playback (play.basic), the extended functionality
of time scaling of content (play.scale), and one "example.com"
proprietary feature (com.example.flight). The client also learns the
methods supported (Public header) by the server for the indicated
resource.
C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0
CSeq: 1
Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 1
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
Server: PhonyServer/2.0
Supported: play.basic, play.scale, com.example.flight
When the client sends its SETUP request it tells the server that it
is requires support of the play.scale feature for this session by
including the Require header.
C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
RTP/AVP/TCP;unicast;interleaved=0-1
Require: play.scale
Accept-Ranges: NPT, SMPTE, UTC
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 3
Session: 12345678
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057";
src_addr="192.0.2.5:5000"/"192.0.2.5:5001"
Server: PhonyServer/2.0
Accept-Ranges: NPT, SMPTE
Appendix B. RTSP Protocol State Machine
The RTSP session state machine describes the behavior of the protocol The RTSP session state machine describes the behavior of the protocol
from RTSP session initialization through RTSP session termination. from RTSP session initialization through RTSP session termination.
The State machine is defined on a per session basis which is uniquely The State machine is defined on a per session basis which is uniquely
identified by the RTSP session identifier. The session may contain identified by the RTSP session identifier. The session may contain
one or more media streams depending on state. If a single media one or more media streams depending on state. If a single media
stream is part of the session it is in non-aggregated control. If stream is part of the session it is in non-aggregated control. If
two or more is part of the session it is in aggregated control. two or more is part of the session it is in aggregated control.
The below state machine is a normative description of the protocols The below state machine is a normative description of the protocols
behavior. However, in case of ambiguity with the earlier parts of behavior. However, in case of ambiguity with the earlier parts of
this specification, the description in the earlier parts SHALL take this specification, the description in the earlier parts SHALL take
precedence. precedence.
A.1. States B.1. States
The state machine contains three states, described below. For each The state machine contains three states, described below. For each
state there exist a table which shows which requests and events that state there exist a table which shows which requests and events that
is allowed and if they will result in a state change. is allowed and if they will result in a state change.
Init: Initial state no session exist. Init: Initial state no session exist.
Ready: Session is ready to start playing. Ready: Session is ready to start playing.
Play: Session is playing, i.e. sending media stream data in the Play: Session is playing, i.e. sending media stream data in the
direction S->C. direction S->C.
A.2. State variables B.2. State variables
This representation of the state machine needs more than its state to This representation of the state machine needs more than its state to
work. A small number of variables are also needed and is explained work. A small number of variables are also needed and is explained
below. below.
NRM: The number of media streams part of this session. NRM: The number of media streams part of this session.
RP: Resume point, the point in the presentation time line at which RP: Resume point, the point in the presentation time line at which
a request to continue will resume from. A time format for the a request to continue will resume from. A time format for the
variable is not mandated. variable is not mandated.
A.3. Abbreviations B.3. Abbreviations
To make the state tables more compact a number of abbreviations are To make the state tables more compact a number of abbreviations are
used, which are explained below. used, which are explained below.
IFI: IF Implemented. IFI: IF Implemented.
md: Media md: Media
PP: Pause Point, the point in the presentation time line at which PP: Pause Point, the point in the presentation time line at which
the presentation was paused. the presentation was paused.
Prs: Presentation, the complete multimedia presentation. Prs: Presentation, the complete multimedia presentation.
RedP: Redirect Point, the point in the presentation time line at RedP: Redirect Point, the point in the presentation time line at
which a REDIRECT was specified to occur. which a REDIRECT was specified to occur.
SES: Session. SES: Session.
A.4. State Tables B.4. State Tables
This section contains a table for each state. The table contains all This section contains a table for each state. The table contains all
the requests and events that this state is allowed to act on. The the requests and events that this state is allowed to act on. The
events which is method names are, unless noted, requests with the events which is method names are, unless noted, requests with the
given method in the direction client to server (C->S). In some cases given method in the direction client to server (C->S). In some cases
there exist one or more requisite. The response column tells what there exist one or more requisite. The response column tells what
type of response actions should be performed. Possible actions that type of response actions should be performed. Possible actions that
is requested for an event includes: response codes, e.g. 200, headers is requested for an event includes: response codes, e.g. 200, headers
that MUST be included in the response, setting of state variables, or that MUST be included in the response, setting of state variables, or
setting of other session related parameters. The new state column setting of other session related parameters. The new state column
skipping to change at page 187, line 5 skipping to change at page 186, line 5
of media" event when all media has finished playing, the session of media" event when all media has finished playing, the session
still remain in Play state. An explicit PAUSE request MUST be sent still remain in Play state. An explicit PAUSE request MUST be sent
to change the state to Ready. It may appear that there exist an to change the state to Ready. It may appear that there exist an
automatic transitions in "RedP reached" and "PP reached", however automatic transitions in "RedP reached" and "PP reached", however
they are requested and acknowledge before they take place. The time they are requested and acknowledge before they take place. The time
at which the transition will happen is known by looking at the range at which the transition will happen is known by looking at the range
header. If the client sends request close in time to these header. If the client sends request close in time to these
transitions it needs to be prepared for getting error message as the transitions it needs to be prepared for getting error message as the
state may or may not have changed. state may or may not have changed.
Appendix B. Media Transport Alternatives Appendix C. Media Transport Alternatives
This section defines how certain combinations of protocols, profiles This section defines how certain combinations of protocols, profiles
and lower transports are used. This includes the usage of the and lower transports are used. This includes the usage of the
Transport header's source and destination address parameters Transport header's source and destination address parameters
"src_addr" and "dest_addr". "src_addr" and "dest_addr".
B.1. RTP C.1. RTP
This section defines the interaction of RTSP with respect to the RTP This section defines the interaction of RTSP with respect to the RTP
protocol [RFC3550]. It also defines any necessary media transport protocol [RFC3550]. It also defines any necessary media transport
signalling with regards to RTP. signalling with regards to RTP.
The available RTP profiles and lower layer transports are described The available RTP profiles and lower layer transports are described
below along with rules on signalling the available combinations. below along with rules on signalling the available combinations.
B.1.1. AVP C.1.1. AVP
The usage of the "RTP Profile for Audio and Video Conferences with The usage of the "RTP Profile for Audio and Video Conferences with
Minimal Control" [RFC3551] when using RTP for media transport over Minimal Control" [RFC3551] when using RTP for media transport over
different lower layer transport protocols is defined below in regards different lower layer transport protocols is defined below in regards
to RTSP. to RTSP.
One such case is defined within this document, the use of embedded One such case is defined within this document, the use of embedded
(interleaved) binary data as defined in Section 14. The usage of (interleaved) binary data as defined in Section 14. The usage of
this method is indicated by include the "interleaved" parameter. this method is indicated by include the "interleaved" parameter.
When using embedded binary data the "src_addr" and "dest_addr" SHALL When using embedded binary data the "src_addr" and "dest_addr" SHALL
NOT be used. This addressing and multiplexing is used as defined NOT be used. This addressing and multiplexing is used as defined
with use of channel numbers and the interleaved parameter. with use of channel numbers and the interleaved parameter.
B.1.2. AVP/UDP C.1.2. AVP/UDP
This part describes sending of RTP [RFC3550] over lower transport This part describes sending of RTP [RFC3550] over lower transport
layer UDP [RFC0768] according to the profile "RTP Profile for Audio layer UDP [RFC0768] according to the profile "RTP Profile for Audio
and Video Conferences with Minimal Control" defined in RFC 3551 and Video Conferences with Minimal Control" defined in RFC 3551
[RFC3551]. This profiles requires one or two uni- or bi-directional [RFC3551]. This profiles requires one or two uni- or bi-directional
UDP flows per media stream. The first UDP flow is for RTP and the UDP flows per media stream. The first UDP flow is for RTP and the
second is for RTCP. Embedding of RTP data with the RTSP messages, in second is for RTCP. Embedding of RTP data with the RTSP messages, in
accordance with Section 14, SHOULD NOT be performed when RTSP accordance with Section 14, SHOULD NOT be performed when RTSP
messages are transported over unreliable transport protocols, like messages are transported over unreliable transport protocols, like
UDP [RFC0768]. UDP [RFC0768].
skipping to change at page 188, line 45 skipping to change at page 187, line 45
SHALL NOT be sent. SHALL NOT be sent.
o The RTP/UDP packets from the client to the server SHALL be sent to o The RTP/UDP packets from the client to the server SHALL be sent to
the address and port given by the first address and port pair of the address and port given by the first address and port pair of
the "src_addr" parameter. the "src_addr" parameter.
o RTP and RTCP Packets SHOULD be sent from the corresponding o RTP and RTCP Packets SHOULD be sent from the corresponding
receiver port, i.e. RTCP packets from server should be sent from receiver port, i.e. RTCP packets from server should be sent from
the "src_addr" parameters second address port pair. the "src_addr" parameters second address port pair.
B.1.3. AVPF/UDP C.1.3. AVPF/UDP
The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/ The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/
AVPF)"[RFC4585] MAY be used as RTP profiles in session using RTP. AVPF)"[RFC4585] MAY be used as RTP profiles in session using RTP.
All that is defined for AVP SHALL also apply for AVPF. All that is defined for AVP SHALL also apply for AVPF.
The usage of AVPF is indicated by the media initialization protocol The usage of AVPF is indicated by the media initialization protocol
used. In the case of SDP it is indicated by media lines (m=) used. In the case of SDP it is indicated by media lines (m=)
containing the profile RTP/AVPF. That SDP MAY also contain further containing the profile RTP/AVPF. That SDP MAY also contain further
AVPF related SDP attributes configuring the AVPF session regarding AVPF related SDP attributes configuring the AVPF session regarding
reporting interval and feedback messages that shall be used that reporting interval and feedback messages that shall be used that
SHALL be followed. SHALL be followed.
B.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 SHALL also apply for SAVP. using RTP. All that is defined for AVP SHALL also apply for SAVP.
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 RECOMMENDED mechanism for establishing that
security association is to use MIKEY with RTSP as defined in RFC 4567 security association is to use MIKEY with RTSP as defined in RFC 4567
[RFC4567]. [RFC4567].
B.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)" [I-D.ietf-avt-profile-savpf] is an RTP profile (SAVPF) (RTP/SAVPF)" [I-D.ietf-avt-profile-savpf] is an RTP profile (SAVPF)
that MAY be used in RTSP sessions using RTP. All that is defined for that MAY be used in RTSP sessions using RTP. All that is defined for
AVP SHALL also apply for SAVPF. AVP SHALL also apply 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 RECOMMENDED mechanism for establishing that
security association is to use MIKEY[RFC3830] with RTSP as defined in security association is to use MIKEY[RFC3830] with RTSP as defined in
RFC 4567 [RFC4567]. RFC 4567 [RFC4567].
B.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 SHALL be supported if an RTSP explained below. Due to that RTCP SHALL be supported if an RTSP
agent handles RTP. agent handles RTP.
B.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.
The first is available from RTP-Info header to accomplish the initial The first is available from RTP-Info header to accomplish the initial
synchronization. But to be able to handle any clockdrift between the synchronization. But to be able to handle any clockdrift between the
media streams, RTCP is needed. media streams, RTCP is needed.
B.1.6.2. RTSP Session keep-alive C.1.6.2. RTSP Session keep-alive
RTCP traffic from the RTSP client to the RTSP server SHALL function RTCP traffic from the RTSP client to the RTSP server SHALL function
as keep-alive. Which requires an RTSP server supporting RTP to use as keep-alive. Which requires an RTSP server supporting RTP to use
the received RTCP packets as indications that the client desires the the received RTCP packets as indications that the client desires the
related RTSP session to be kept alive. related RTSP session to be kept alive.
B.1.6.3. Bit-rate adapation C.1.6.3. Bit-rate adapation
RTCP Receiver Rerports and any additional feedback from the client RTCP Receiver Rerports and any additional feedback from the client
SHALL be used adapt the bit-rate used over the transport for all SHALL be used adapt the bit-rate used over the transport for all
cases when RTP is sent over UDP. A RTP sender without reserved cases when RTP is sent over UDP. A RTP sender without reserved
resources SHALL NOT use more than its fair share of the available resources SHALL NOT use more than its fair share of the available
resources. This can be determined by comparing on short to medium resources. This can be determined by comparing on short to medium
term (some seconds) the used bit-rate and adapt it so that the RTP term (some 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 sender sends at a bit-rate comparable to what a TCP sender would
achieve on average over the same path. achieve on average over the same path.
B.2. RTP over TCP C.2. RTP over TCP
Transport of RTP over TCP can be done in two ways, over independent Transport of RTP over TCP can be done in two ways, over independent
TCP connections using RFC 4571 [RFC4571] or interleaved in the RTSP TCP connections using RFC 4571 [RFC4571] or interleaved in the RTSP
control connection. In both cases the protocol SHALL be "rtp" and control connection. In both cases the protocol SHALL be "rtp" and
the lower layer SHALL be TCP. The profile may be any of the above the lower layer SHALL be TCP. The profile may be any of the above
specified ones; AVP, AVPF, SAVP or SAVPF. specified ones; AVP, AVPF, SAVP or SAVPF.
B.2.1. Interleaved RTP over TCP C.2.1. Interleaved RTP over TCP
The use of embedded (interleaved) binary data transported on the RTSP The use of embedded (interleaved) binary data transported on the RTSP
connection is possible as specified in Section 14. When using this connection is possible as specified in Section 14. When using this
declared combination of interleaved binary data the RTSP messages declared combination of interleaved binary data the RTSP messages
MUST be transported over TCP. TLS may or may not be used. MUST be transported over TCP. TLS may or may not be used.
One should however consider that this will result that all media One should however consider that this will result that all media
streams go through any proxy. Using independent TCP connections can streams go through any proxy. Using independent TCP connections can
avoid that issue. avoid that issue.
B.2.2. RTP over independent TCP C.2.2. RTP over independent TCP
In this Appendix, we describe the sending of RTP [RFC3550] over lower In this Appendix, we describe the sending of RTP [RFC3550] over lower
transport layer TCP [RFC0793] according to "Framing Real-time transport layer TCP [RFC0793] according to "Framing Real-time
Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over
Connection-Oriented Transport" [RFC4571]. This Appendix adapts the Connection-Oriented Transport" [RFC4571]. This Appendix adapts the
guidelines for using RTP over TCP within SIP/SDP [RFC4145] to work guidelines for using RTP over TCP within SIP/SDP [RFC4145] to work
with RTSP. with RTSP.
A client codes the support of RTP over independent TCP by specifying A client codes the support of RTP over independent TCP by specifying
an RTP/AVP/TCP transport option without an interleaved parameter in an RTP/AVP/TCP transport option without an interleaved parameter in
skipping to change at page 192, line 42 skipping to change at page 191, line 42
SHOULD use the "connection" parameter (defined in Section 16.46) on SHOULD use the "connection" parameter (defined in Section 16.46) 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.
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 Section 19.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
Date: 23 Jan 1997 15:35:06 GMT Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp Content-Type: application/sdp
skipping to change at page 194, line 34 skipping to change at page 193, line 34
M->C: RTSP/2.0 200 OK M->C: RTSP/2.0 200 OK
CSeq: 4 CSeq: 4
Server: PhonyServer/1.0 Server: PhonyServer/1.0
Date: 23 Jan 1997 15:35:14 GMT Date: 23 Jan 1997 15:35:14 GMT
Session: 12345678 Session: 12345678
Range: npt=0-10, npt=30-623.10 Range: npt=0-10, npt=30-623.10
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1"; RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1";
ssrc=4F312DD8:seq=54321;rtptime=2876889 ssrc=4F312DD8:seq=54321;rtptime=2876889
B.2.3. Handling NPT Jumps in the RTP Media Layer C.2.3. Handling NPT Jumps in the RTP Media Layer
RTSP allows media clients to control selected, non-contiguous RTSP allows media clients to control selected, non-contiguous
sections of media presentations, rendering those streams with an RTP sections of media presentations, rendering those streams with an RTP
media layer[RFC3550]. Such control allows jumps to be created in NPT media layer[RFC3550]. Such control allows jumps to be created in NPT
timeline of the RTSP session. For example, jumps in NPT can be timeline of the RTSP session. For example, jumps in NPT can be
caused by multiple ranges in the range specifier of a PLAY request or caused by multiple ranges in the range specifier of a PLAY request or
through a "seek" opertaion on an RTSP session which involves a PLAY, through a "seek" opertaion on an RTSP session which involves a PLAY,
PAUSE, PLAY scenario where a new NPT is set for the session. The PAUSE, PLAY scenario where a new NPT is set for the session. The
media layer rendering the RTP stream should not be affected by jumps media layer rendering the RTP stream should not be affected by jumps
in NPT. Thus, both RTP sequence numbers and RTP timestamps MUST be in NPT. Thus, both RTP sequence numbers and RTP timestamps MUST be
skipping to change at page 197, line 5 skipping to change at page 196, line 5
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
. . . . . .
S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s
S -> C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s S -> C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s
S -> C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s S -> C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s
. . . . . .
S -> C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s S -> C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s
B.2.4. Handling RTP Timestamps after PAUSE C.2.4. Handling RTP Timestamps after PAUSE
During a PAUSE / PLAY interaction in an RTSP session, the duration of During a PAUSE / PLAY interaction in an RTSP session, the duration of
time for which the RTP transmission was halted MUST be reflected in time for which the RTP transmission was halted MUST be reflected in
the RTP timestamp of each RTP stream. The duration can be calculated the RTP timestamp of each RTP stream. The duration can be calculated
for each RTP stream as the time elapsed from when the last RTP packet for each RTP stream as the time elapsed from when the last RTP packet
was sent before the PAUSE request was received and when the first RTP was sent before the PAUSE request was received and when the first RTP
packet was sent after the subsequent PLAY request was received. The packet was sent after the subsequent PLAY request was received. The
duration includes all latency incurred and processing time required duration includes all latency incurred and processing time required
to complete the request. to complete the request.
skipping to change at page 199, line 5 skipping to change at page 198, line 5
after this PLAY request. after this PLAY request.
A client can use the RTSP range header and RTP-Info header to map NPT A client can use the RTSP range header and RTP-Info header to map NPT
time of a presentation with the RTP timestamp. time of a presentation with the RTP timestamp.
Note: In RFC 2326 [RFC2326], this matter was not clearly defined and Note: In RFC 2326 [RFC2326], this matter was not clearly defined and
was misunderstood commonly. However for RTSP 2.0 it is expected that was misunderstood commonly. However for RTSP 2.0 it is expected that
this will be handled correctly and no exception handling will be this will be handled correctly and no exception handling will be
required. required.
B.2.5. RTSP / RTP Integration C.2.5. RTSP / RTP Integration
For certain datatypes, tight integration between the RTSP layer and For certain datatypes, tight integration between the RTSP layer and
the RTP layer will be necessary. This by no means precludes the the RTP layer will be necessary. This by no means precludes the
above restrictions. Combined RTSP/RTP media clients should use the above restrictions. Combined RTSP/RTP media clients should use the
RTP-Info field to determine whether incoming RTP packets were sent RTP-Info field to determine whether incoming RTP packets were sent
before or after a seek or before or after a PAUSE. before or after a seek or before or after a PAUSE.
B.2.6. Scaling with RTP C.2.6. Scaling with RTP
For scaling (see Section 16.40), RTP timestamps should correspond to For scaling (see Section 16.40), RTP timestamps should correspond to
the playback timing. For example, when playing video recorded at 30 the playback timing. For example, when playing video recorded at 30
frames/second at a scale of two and speed (Section 16.41) of one, the frames/second at a scale of two and speed (Section 16.41) of one, the
server would drop every second frame to maintain and deliver video server would drop every second frame to maintain and deliver video
packets with the normal timestamp spacing of 3,000 per frame, but NPT packets with the normal timestamp spacing of 3,000 per frame, but NPT
would increase by 1/15 second for each video frame. would increase by 1/15 second for each video frame.
Note: The above scaling puts requirements on the media codec or a Note: The above scaling puts requirements on the media codec or a
media stream to support it. For example motion JPEG or other non- media stream to support it. For example motion JPEG or other non-
predictive video coding can easier handle the above example. predictive video coding can easier handle the above example.
B.2.7. Maintaining NPT synchronization with RTP timestamps C.2.7. Maintaining NPT synchronization with RTP timestamps
The client can maintain a correct display of NPT (Normal Play Time) The client can maintain a correct display of NPT (Normal Play Time)
by noting the RTP timestamp value of the first packet arriving after by noting the RTP timestamp value of the first packet arriving after
repositioning. The sequence parameter of the RTP-Info repositioning. The sequence parameter of the RTP-Info
(Section 16.39) header provides the first sequence number of the next (Section 16.39) header provides the first sequence number of the next
segment. segment.
B.2.8. Continuous Audio C.2.8. Continuous Audio
For continuous audio, the server SHOULD set the RTP marker bit at the For continuous audio, the server SHOULD set the RTP marker bit at the
beginning of serving a new PLAY request or at jumps in timeline. beginning of serving a new PLAY request or at jumps in timeline.
This allows the client to perform playout delay adaptation. This allows the client to perform playout delay adaptation.
B.2.9. Multiple Sources in an RTP Session C.2.9. Multiple Sources in an RTP Session
Note that more than one SSRC MAY be sent in the media stream. If it Note that more than one SSRC MAY be sent in the media stream. If it
happens all sources are expected to be rendered simultaneously. happens all sources are expected to be rendered simultaneously.
B.2.10. Usage of SSRCs and the RTCP BYE Message During an RTSP Session C.2.10. Usage of SSRCs and the RTCP BYE Message During an RTSP Session
The RTCP BYE message indicates the end of use of a given SSRC. If The RTCP BYE message indicates the end of use of a given SSRC. If
all sources leave an RTP session, it can, in most cases, be assumed all sources leave an RTP session, it can, in most cases, be assumed
to have ended. Therefore, a client or server SHALL NOT send a RTCP to have ended. Therefore, a client or server SHALL NOT send a RTCP
BYE message until it has finished using a SSRC. A server SHOULD keep BYE message until it has finished using a SSRC. A server SHOULD keep
using a SSRC until the RTP session is terminated. Prolonging the use using a SSRC until the RTP session is terminated. Prolonging the use
of a SSRC allows the established synchronization context associated of a SSRC allows the established synchronization context associated
with that SSRC to be used to synchronize subsequent PLAY requests with that SSRC to be used to synchronize subsequent PLAY requests
even if the PLAY response is late. even if the PLAY response is late.
skipping to change at page 200, line 18 skipping to change at page 199, line 18
consequences, as it will force the media sender to change its SSRC in consequences, as it will force the media sender to change its SSRC in
accordance with the RTP specification[RFC3550]. This will result in accordance with the RTP specification[RFC3550]. This will result in
a loss of synchronization context, and require any receiver to wait a loss of synchronization context, and require any receiver to wait
for RTCP sender reports for all media requiring synchronization for RTCP sender reports for all media requiring synchronization
before being able to play out synchronized. Due to these reasons a before being able to play out synchronized. Due to these reasons a
client joining a session should take care to not select the same SSRC client joining a session should take care to not select the same SSRC
as the server. Any SSRC signalled in the Transport header SHOULD be as the server. Any SSRC signalled in the Transport header SHOULD be
avoided. A client detecting a collision prior to sending any RTP or avoided. A client detecting a collision prior to sending any RTP or
RTCP messages can also select a new SSRC. RTCP messages can also select a new SSRC.
B.3. Future Additions C.3. Future Additions
It is the intention that any future protocol or profile regarding It is the intention that any future protocol or profile regarding
both for media delivery and lower transport should be easy to add to both for media delivery and lower transport should be easy to add to
RTSP. This section provides the necessary steps that needs to be RTSP. This section provides the necessary steps that needs to be
meet. meet.
The following things needs to be considered when adding a new The following things needs to be considered when adding a new
protocol of profile for use with RTSP: protocol of profile for use with RTSP:
o The protocol or profile needs to define a name tag representing o The protocol or profile needs to define a name tag representing
skipping to change at page 200, line 40 skipping to change at page 199, line 40
use in the Transport header specification. use in the Transport header specification.
o The useful combinations of protocol/profile/lower-layer needs to o The useful combinations of protocol/profile/lower-layer needs to
be defined and for each combination declare the necessary be defined and for each combination declare the necessary
parameters to use in the Transport header. parameters to use in the Transport header.
o For new media protocols the interaction with RTSP needs to be o For new media protocols the interaction with RTSP needs to be
addressed. One important factor will be the media addressed. One important factor will be the media
synchronization. synchronization.
See the IANA section (Section 23) for information how to register new See the IANA section (Section 22) for information how to register new
attributes. attributes.
Appendix C. Use of SDP for RTSP Session Descriptions Appendix D. Use of SDP for RTSP Session Descriptions
The Session Description Protocol (SDP, [RFC4566]) may be used to The Session Description Protocol (SDP, [RFC4566]) may be used to
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). However the (e.g., two audio streams spoken in different languages). However the
SDP extension "Grouping of Media Lines in the Session Description SDP extension "Grouping of Media Lines in the Session Description
Protocol (SDP)" [RFC3388] may provide such functionality depending on Protocol (SDP)" [RFC3388] may provide such functionality depending on
need. Also future grouping semantics may in the future be developed. need. Also future grouping semantics may in the future be developed.
C.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 (RFC 4566 [RFC4566]): SDP (RFC 4566 [RFC4566]):
C.1.1. Control URI D.1.1. Control URI
The "a=control:" attribute is used to convey the control URI. This The "a=control:" attribute is used to convey the control URI. This
attribute is used both for the session and media descriptions. If attribute is used both for the session and media descriptions. If
used for individual media, it indicates the URI to be used for used for individual media, it indicates the URI to be used for
controlling that particular media stream. If found at the session controlling that particular media stream. If found at the session
level, the attribute indicates the URI for aggregate control level, the attribute indicates the URI for aggregate control
(presentation URI). The session level URI SHALL be different from (presentation URI). The session level URI SHALL be different from
any media level URI. The presence of a session level control any media level URI. The presence of a session level control
attribute SHALL be interpreted as support for aggregated control. attribute SHALL be interpreted as support for aggregated control.
The control attribute SHALL be present on media level unless the The control attribute SHALL be present on media level unless the
presentation only contains a single media stream, in which case the presentation only contains a single media stream, in which case the
attribute MAY only be present on the session level. attribute MAY only be present on the session level.
ABNF for the attribute is defined in Section 21.3. ABNF for the attribute is defined in Section 20.3.
Example: Example:
a=control:rtsp://example.com/foo a=control:rtsp://example.com/foo
This attribute MAY contain either relative or absolute URIs, This attribute MAY contain either relative or absolute URIs,
following the rules and conventions set out in RFC 3986 [RFC3986]. following the rules and conventions set out in RFC 3986 [RFC3986].
Implementations SHALL look for a base URI in the following order: Implementations SHALL look for a base URI in the following order:
1. the RTSP Content-Base field; 1. the RTSP Content-Base field;
2. the RTSP Content-Location field; 2. the RTSP Content-Location field;
3. the RTSP Request-URI. 3. the RTSP Request-URI.
skipping to change at page 202, line 34 skipping to change at page 201, line 34
However this will also mean that using "*" in the SDP will result in However this will also mean that using "*" in the SDP will result in
control URI including the trailing slash, i.e. control URI including the trailing slash, i.e.
"rtsp://example.com/container.mp4/". "rtsp://example.com/container.mp4/".
Note: The usage of TrackID in the above is not an standardized Note: The usage of TrackID in the above is not an standardized
form, but one example out of several similar strings such as form, but one example out of several similar strings such as
TrackID, Track_ID, StreamID that is used by different server TrackID, Track_ID, StreamID that is used by different server
vendors to indicate a particular piece of media inside a container vendors to indicate a particular piece of media inside a container
file. file.
C.1.2. Media Streams D.1.2. Media Streams
The "m=" field is used to enumerate the streams. It is expected that The "m=" field is used to enumerate the streams. It is expected that
all the specified streams will be rendered with appropriate all the specified streams will be rendered with appropriate
synchronization. If the session is over multicast, the port number synchronization. If the session is over multicast, the port number
indicated SHOULD be used for reception. The client MAY try to indicated SHOULD be used for reception. The client MAY try to
override the destination port, through the Transport header. The override the destination port, through the Transport header. The
servers MAY allow this, the response will indicate if allowed or not. servers MAY allow this, the response will indicate if allowed or not.
If the session is unicast, the port number is the ones RECOMMENDED by If the session is unicast, the port number is the ones RECOMMENDED by
the server to the client, about which receiver ports to use; the the server to the client, about which receiver ports to use; the
client MUST still include its receiver ports in its SETUP request. client MUST still include its receiver ports in its SETUP request.
The client MAY ignore this recommendation. If the server has no The client MAY ignore this recommendation. If the server has no
preference, it SHOULD set the port number value to zero. preference, it SHOULD set the port number value to zero.
The "m=" lines contain information about what transport protocol, The "m=" lines contain information about what transport protocol,
profile, and possibly lower-layer is to be used for the media stream. profile, and possibly lower-layer is to be used for the media stream.
The combination of transport, profile and lower layer, like RTP/AVP/ The combination of transport, profile and lower layer, like RTP/AVP/
UDP needs to be defined for how to be used with RTSP. The currently UDP needs to be defined for how to be used with RTSP. The currently
defined combinations are defined in Appendix B, further combinations defined combinations are defined in Appendix C, further combinations
MAY be specified. MAY be specified.
Usage of grouping of media lines [RFC3388] to determine which media Usage of grouping of media lines [RFC3388] to determine which media
lines should or should not be included in a RTSP session is lines should or should not be included in a RTSP session is
unspecified. unspecified.
Example: Example:
m=audio 0 RTP/AVP 31 m=audio 0 RTP/AVP 31
C.1.3. Payload Type(s) D.1.3. Payload Type(s)
The payload type(s) are specified in the "m=" line. In case the The payload type(s) are specified in the "m=" line. In case the
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.
C.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.
C.1.5. Directionality of media stream D.1.5. Directionality of media stream
The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly" The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly"
provides instructions on which direction the media streams flow provides instructions on which direction the media streams flow
within a session. When using RTSP the SDP can be delivered to a within a session. When using RTSP the SDP can be delivered to a
client using either RTSP DESCRIBE or a number of RTSP external client using either RTSP DESCRIBE or a number of RTSP external
methods, like HTTP, FTP, and email. Based on this the SDP applies to methods, like HTTP, FTP, and email. Based on this the SDP applies to
how the RTSP client will see the complete session. Thus for media how the RTSP client will see the complete session. Thus for media