A.2 RTSP
26.2343GPPProtocols and codecsRelease 17Transparent end-to-end Packet-switched Streaming Service (PSS)TS
A.2.1 General
Clause 5.3.2 of the present document defines the required RTSP support in PSS clients and servers by making references to Appendix D of [5]. It also defines the RTSP header fields that are specific to PSS. The current clause gives an informative overview of these methods (see Table A.2) and headers (see Table A.3). Note that this overview does not replace the information in Appendix D of [5] and Clause 5.3.2 of the present document, which must be consulted for a full implementation of RTSP in PSS. Two examples of RTSP sessions are also given.
Table A.2: Overview of the RTSP method support in PSS
|
Method |
Requirement for a minimal on-demand playback client according to [5]. |
Requirement for a PSS client according to the present document. |
Requirement for a minimal on-demand playback server according to [5]. |
Requirement for a PSS server according to the present document. |
|
OPTIONS |
O |
O |
Respond |
Respond |
|
REDIRECT |
Respond |
Respond |
O |
O |
|
DESCRIBE |
O |
Generate |
O |
Respond |
|
SETUP |
Generate |
Generate |
Respond |
Respond |
|
PLAY |
Generate |
Generate |
Respond |
Respond |
|
PAUSE |
Generate |
Generate |
Respond |
Respond |
|
TEARDOWN |
Generate |
Generate |
Respond |
Respond |
|
SET_PARAMETER |
O |
O |
O |
O |
|
NOTE 1: O = Support is optional NOTE 2: ‘Generate’ means that the client/server is required to generate the request where applicable. NOTE 3: ‘Respond’ means that the client/server is required to properly respond to the request. |
||||
Table A.3: Overview of the RTSP header support in PSS
|
Header |
Requirement for a minimal on-demand playback client according to [5]. |
Requirement for a PSS client according to the present document. |
Requirement for a minimal on-demand playback server according to [5]. |
Requirement for a PSS server according to the present document. |
|
Bandwidth |
O |
O |
O |
O |
|
Connection |
include/understand |
include/understand |
include/understand |
include/understand |
|
Content-Encoding |
understand |
understand |
include |
include |
|
Content-Language |
understand |
understand |
include |
include |
|
Content-Length |
understand |
understand |
include |
include |
|
Content-Type |
understand |
understand |
include |
include |
|
CSeq |
include/understand |
include/understand |
include/understand |
include/understand |
|
Date |
include |
include |
include |
include |
|
Location |
understand |
understand |
O |
O |
|
Public |
O |
O |
include |
include |
|
Range |
O |
include/understand |
understand |
include/understand |
|
Require |
O |
O |
understand |
understand |
|
RTP-Info |
understand |
understand |
include |
include |
|
Server4 |
O |
O |
O |
O |
|
Session |
include |
include |
understand |
understand |
|
Timestamp |
O |
O |
include/understand |
include/understand |
|
Transport |
include/understand |
include/understand |
include/understand |
include/understand |
|
Unsupported |
include |
include |
include |
include |
|
User-Agent4 |
O |
O |
O |
O |
|
3GPP-Adaptation |
N/A |
O |
N/A |
O |
|
3GPP-Link-Char |
N/A |
O |
N/A |
O |
|
3GPP-QoE-Metrics |
N/A |
O |
N/A |
O |
|
NOTE 1: O = Support is optional NOTE 2: ‘include’ means that the client/server is required to include the header in a request or response where applicable. NOTE 3: ‘understand’ means that the client/server is required to be able to respond properly if the header is received in a request or response. NOTE 4: According to [5] the "Server" and "User-Agent" headers are not strictly required for a minimal RTSP implementation, although it is highly recommended that they are included with responses and requests. The same applies to PSS servers and clients according to the present document. |
||||
The example below is intended to give some more understanding of how RTSP and SDP are used within the 3GPP PSS. The example assumes that the streaming client has the RTSP URL to a presentation consisting of an H.264 video sequence and AMR speech. RTSP messages sent from the client to the server are in bold and messages from the server to the client in italic. In the example the server provides aggregate control of the two streams.
EXAMPLE 1:
DESCRIBE rtsp://mediaserver.com/movie.test RTSP/1.0
CSeq: 1
User-Agent: TheStreamClient/1.1b2
RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: 435
v=0
o=- 950814089 950814089 IN IP4 144.132.134.67
s=Example of aggregate control of AMR speech and H.264 video
e=foo@bar.com
c=IN IP4 0.0.0.0
b=AS:410
b=TIAS: 394680
t=0 0
a=range:npt=0-59.3478
a=control:*
a=maxprate:20
m=audio 0 RTP/AVP 97
b=AS:13
b=TIAS:10680
b=RR:350
b=RS:300
a=maxprate:5
a=rtpmap:97 AMR/8000
a=fmtp:97
a=maxptime:200
a=control:streamID=0
m=video 0 RTP/AVP 98
b=AS:387
b=TIAS:384000
b=RR:14400
b=RS:4800
a=maxprate:40
a=rtpmap:98 H264/90000
a=fmtp:98 profile=-level-id=42c00c;sprop-parameter-sets=Z0LADJWgUH6Af1A=,aM46gA==
a=control:streamID=1
SETUP rtsp://mediaserver.com/movie.test/streamID=0 RTSP/1.0
CSeq: 2
Transport: RTP/AVP/UDP;unicast;client_port=3456-3457
User-Agent: TheStreamClient/1.1b2
RTSP/1.0 200 OK
CSeq: 2
Transport: RTP/AVP/UDP;unicast;client_port=3456-3457; server_port=5678-5679
Session: dfhyrio90llk
SETUP rtsp://mediaserver.com/movie.test/streamID=1 RTSP/1.0
CSeq: 3
Transport: RTP/AVP/UDP;unicast;client_port=3458-3459
Session: dfhyrio90llk
User-Agent: TheStreamClient/1.1b2
RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP/UDP;unicast;client_port=3458-3459; server_port=5680-5681
Session: dfhyrio90llk
PLAY rtsp://mediaserver.com/movie.test RTSP/1.0
CSeq: 4
Session: dfhyrio90llk
User-Agent: TheStreamClient/1.1b2
RTSP/1.0 200 OK
CSeq: 4
Session: dfhyrio90llk
Range: npt=0-
RTP-Info: url= rtsp://mediaserver.com/movie.test/streamID=0; seq=9900;rtptime=4470048,
url= rtsp://mediaserver.com/movie.test/streamID=1; seq=1004;rtptime=1070549
NOTE: Headers can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. For more information, see RFC2616 [17].
The user watches the movie for 20 seconds and then decides to jump to 10 seconds before the end…
PAUSE rtsp://mediaserver.com/movie.test RTSP/1.0
CSeq: 5
Session: dfhyrio90llk
User-Agent: TheStreamClient/1.1b2
PLAY rtsp://mediaserver.com/movie.test RTSP/1.0
CSeq: 6
Range: npt=50-59.3478
Session: dfhyrio90llk
User-Agent: TheStreamClient/1.1b2
RTSP/1.0 200 OK
CSeq: 5
Session: dfhyrio90llk
RTSP/1.0 200 OK
CSeq: 6
Session: dfhyrio90llk
Range: npt=50-59.3478
RTP-Info: url= rtsp://mediaserver.com/movie.test/streamID=0;
seq=39900;rtptime=44470648,
url= rtsp://mediaserver.com/movie.test/streamID=1;
seq=31004;rtptime=41090349
After the movie is over the client issues a TEARDOWN to end the session…
TEARDOWN rtsp://mediaserver.com/movie.test RTSP/1.0
CSeq: 7
Session: dfhyrio90llk
User-Agent: TheStreamClient/1.1b2
RTSP/1.0 200 OK
Cseq: 7
Session: dfhyrio90llk
Connection: close
The example below contains a complete RTSP signalling for session set-up with rate adaptation support, where the client buffer feedback functionality is initialised and used. To allow the server to know that a client supports the buffer feedback formats and signalling, the client includes a link to its UAProf description in its RTSP DESCRIBE request.
EXAMPLE 2:
DESCRIBE rtsp://mediaserver.com/movie.test RTSP/1.0
CSeq: 1
User-Agent: TheStreamClient/1.1b2
x-wap-profile: "http://uaprof.example.com/products/TheStreamClient1.1b2"
RTSP/1.0 200 OK
CSeq: 1Date: 20 Aug 2003 15:35:06 GMT
Content-Base: rtsp://mediaserver.com/movie.test/
Content-Type: application/sdp
Content-Length: 500
v=0
o=- 950814089 950814089 IN IP4 144.132.134.67
s=Example of aggregate control of AMR speech and H.264 video
e=foo@bar.com
c=IN IP4 0.0.0.0
b=AS:77
b=TIAS:69880
t=0 0
a=maxprate:20
a=range:npt=0-59.3478
a=control:*
m=audio 0 RTP/AVP 97
b=AS:15
b=TIAS:12800
b=RR:560
b=RS:190
a=maxprate:5
a=rtpmap:97 AMR-WB/16000
a=fmtp:97 octet-align=1
a=control: streamID=0
a=3GPP-Adaptation-Support:2
m=video 0 RTP/AVP 98
b=AS:397
b=TIAS:384000
b=RR:14400
b=RS:4800
a=maxprate:40
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id =42c00c ; sprop-parameter-sets=Z0LADJWgUH6Af1A=,aM46gA==
a=control: streamID=1
a=3GPP-Adaptation-Support:1
SETUP rtsp://mediaserver.com/movie.test/streamID=0 RTSP/1.0
CSeq: 2
Transport: RTP/AVP/UDP;unicast;client_port=3456-3457
User-Agent: TheStreamClient/1.1b2
3GPP-Adaptation: url="rtsp://mediaserver.com/movie.test/streamID=0";size=14500;target-time=5000
RTSP/1.0 200 OK
CSeq: 2
Transport: RTP/AVP/UDP;unicast;client_port=3456-3457;server_port=5678-5679;ssrc=A432F9B1
Session: dfhyrio90llk
3GPP-Adaptation: url="rtsp://mediaserver.com/movie.test/streamID=0";size=14500;target-time=5000
SETUP rtsp://mediaserver.com/movie.test/streamID=1 RTSP/1.0
CSeq: 3
Transport: RTP/AVP/UDP;unicast;client_port=3458-3459
Session: dfhyrio90llk
User-Agent: TheStreamClient/1.1b2
3GPP-Adaptation: url="rtsp://mediaserver.com/movie.test/streamID=1";size=35000;target-time=5000
RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP/UDP;unicast;client_port=3458-3459; server_port=5680-5681; ssrc=4D23AE29
Session: dfhyrio90llk
3GPP-Adaptation: url=" rtsp://mediaserver.com/movie.test/streamID=1";size=35000;target-time=5000
PLAY rtsp://mediaserver.com/movie.test/ RTSP/1.0
CSeq: 4
Session: dfhyrio90llk
User-Agent: TheStreamClient/1.1b2
RTSP/1.0 200 OK
CSeq: 4
Session: dfhyrio90llk
Range: npt=0-
RTP-Info: url= rtsp://mediaserver.com/movie.test/streamID=0; seq=9900;rtptime=4470048, url= rtsp://mediaserver.com/movie.test/streamID=1; seq=1004;rtptime=1070549
If the client desires to change the target buffer protection time during the session, it can signal a new value to the server by means of an RTSP SET_PARAMETER request.
SET_PARAMETER rtsp://mediaserver.com/movie.test/ RTSP/1.0
CSeq: 8
Session: dfhyrio90llk
User-Agent: TheStreamClient/1.1b2
3GPP-Adaptation: url="rtsp://mediaserver.com/movie.test/streamID=0";target-time=7000,url="rtsp://mediaserver.com/movie.test/streamID=1";target-time=7000
RTSP/1.0 200 OK
CSeq: 8
Session: dfhyrio90llk
3GPP-Adaptation: url="rtsp://mediaserver.com/movie.test/streamID=0";target-time=7000,url="rtsp://mediaserver.com/movie.test/streamID=1";target-time=7000
A.2.2 Implementation guidelines
A.2.2.1 Usage of persistent TCP
Considering the potentially long round-trip-delays in a packet switched streaming service over UMTS it is important to keep the number of messages exchanged between a server and a client low. The number of requests and responses exchanged is one of the factors that will determine how long it takes from the time that a user initiates PSS until the streams starts playing in a client.
RTSP methods are sent over either TCP or UDP for IP. Both client and server shall support RTSP over TCP whereas RTSP over UDP is optional. For TCP the connection can be persistent or non-persistent. A persistent connection is used for several RTSP request/response pairs whereas one connection is used per RTSP request/response pair for the non-persistent connection. In the non-persistent case each connection will start with the three-way handshake (SYN, ACK, SYN) before the RTSP request can be sent. This will increase the time for the message to be sent by one round trip delay.
For these reasons it is recommended that 3GPP PSS clients should use a persistent TCP connection, at least for the initial RTSP methods until media starts streaming.
A.2.2.2 Detecting link aliveness
In the wireless environment, connection may be lost due to fading, shadowing, loss of battery power, or turning off the terminal even though the PSS session is active. In order for the server to be able to detect the client’s aliveness, the PSS client should send "wellness" information to the PSS server for a defined interval as described in the RFC2326. There are several ways for detecting link aliveness described in the RFC2326, however, the client should be careful about issuing "PLAY method without Range header field" too close to the end of the streams, because it may conflict with pipelined PLAY requests. Below is the list of recommended "wellness" information for the PSS clients and servers in a prioritised order.
1. RTCP
2. OPTIONS method with Session header field
NOTE: Both servers and clients can initiate this OPTIONS method.
The client should send the same wellness information in ‘Ready’ state as in ‘Playing’ and ‘Recording’ states, and the server should detect the same client’s wellness information in ‘Ready’ state as in ‘Playing’ and ‘Recording’ states. In particular, the same link aliveness mechanism should be managed following a ‘PAUSE’ request and response.