SIP TCP

This message flow uses SIP over TCP to simulate a SIP dialog that transmits simulated media content using RTP/UDP. The flow is intended to generate simple SIP traffic between the MN and the Network Host node.

This flow is also a good example of using a subflow to include a second protocol in the message flow.

When control plane protocols are used, the message flow begins after Data Start Delay timer expires. The MN initiates the TCP connection and the Client Port and Server Port in the message flow define the ports used by both sides.

1. The client begins the message sequence by issuing an INVITE request with mandatory headers. The server begins the response with an indication that it is locating the recipient.

2. The server continues the response with an indication that it is attempting to establish a dialog with the recipient.

3. The server completes the response with a confirmation that the dialog has been established.

4. The client acknowledges receipt of the server confirmation.

At this point in the message flow, 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.

5. The client issues a BYE to terminate the SIP dialog, the server responds with a confirmation, and the TCP connection is closed.

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 SIP TCP Dynamically Start Secondary Contexts message flow, 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 SIP DMF between steps 3 and 4 to handle secondary context events.  A USER_DEFINED_EVENT_1 is sent to the test case (<External>) after the server responds with a 200 OK 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 ACK.

The mainflow continues with the remainder of the SIP flow and when the subflow execution is complete, the test case attempts to delete the secondary context.