RTSP TCP and RTSP UDP
These message flows use RTSP over TCP or over UDP to simulate an RTSP session that controls an RTP connection, which carries the simulated media content. RTSP can be considered the control stream, and RTP the content stream. The flow is intended to generate streaming media between the MN and the Network Host node.
The diagram shows the RTSP TCP message flow. In the RTSP UDP message flow, the TCP connection would not exist, and the RTP UDP subflow is executed after step 2.
When control plane protocols are used, the message flow begins after Data Start Delay timer expires. The MN initiates the TCP connection, when TCP is used, and the Client Port and Server Port in the message flow define the ports used by both sides.
-
The client begins the message sequence by issuing a SETUP request that includes the URL, and the CSeq and Transport headers.
-
The CSeq header is a unique sequence number for every request sent by the client. The server uses the sequence number in request responses.
-
The Transport header includes the ports that are requested for the RTP stream.
-
The server responds with a confirmation that includes a Session header. This session number would be used to bind multiple RTP streams in one RTSP session, and is sent back to the server in subsequent requests.
-
The client issues a PLAY request to begin the media stream, and the server responds with a confirmation.
At this point in the message flow, either the RTP TCP or the RTP UDP Subflow is executed. It establishes an RTP connection using the ports identified in the subflow, and sends two packets to the client. The first packet is 128 bytes, and the second is 64 bytes. After the second packet is received, the subflow sends a TRANS_COMPLETE event back to the mainflow, allowing it to continue.
-
The client issues a TEARDOWN to terminate both the RTP and RTSP sessions, and the server responds with a confirmation.
If TCP is used, the TCP connections for both RTSP and RTP are closed when the mainflow transaction is completed.
In the default configuration, the message flow will repeat once per second while the MN session is active. This assumes that the entire flow can be completed in one second. The flow must complete before the next iteration can begin, even if this results in a slower transaction rate.
GPRS Testing
When you use secondary PDP contexts in a GGSN Nodal test case, you can more closely model real world activity by activating the secondary contexts when the RTP subflow is executed and deleting them when the subflow is complete. The RTSP TCP Dynamically Start Secondary Contexts and RTSP UDP Dynamically Start Secondary Contexts message flows, in combination with the test case settings, provide the triggering necessary to activate and delete contexts as the DMFs are executed.
Two event controls are added to the RTSP DMF between steps 1 and 2 to handle secondary context events. A USER_DEFINED_EVENT_1 is sent to the test case (<External>) after the server responds to the SETUP request to trigger secondary context activation. The mainflow then waits for a SOCKET_OPEN event from the subflow, indicating that the secondary context was successfully activated, before continuing with the PLAY request.
The mainflow continues with the remainder of the RTSP flow and when the subflow execution is complete, the test case attempts to delete the secondary context.
|
NOTE: The Auto-Start Secondary Contexts box on the General tab of the test case must be cleared in order to dynamically trigger secondary contexts from a DMF. |
Modifying the Message Flow
You can specify that random port numbers, in the IANA specified dynamic range of 49152 — 65535, be used by the client by entering a 0 for the Client Port.
Since RTSP is a text-based protocol you can easily modify the message headers. The URL and Session number should be used consistently in all messages, and the CSeq number should match in request/response pairs.
|
IMPORTANT: If you change the Transport header, the ports defined in the RTP subflow should be changed to match. The test will execute correctly regardless of the ports specified in the header, but if a content or Security Gateway is in the data network, it may inspect the packets and expect that the requested ports will be used for the actual data transfer. |