Advanced Data Protocols

This topic briefly describes the pre-defined protocols available with the Advanced Data feature. The commands and packet formats that are defined in this topic are those used in the default DMFs. Since you have full control over both the client and server messages, you can define a message flow with any of the messages that are supported by the data protocol. Messages can be defined manually or you can use the Protocol Wizard to construct message flows for the protocols supported by the wizard. The protocols covered in this topic and the default DMFs for each are listed below.

Fireball - (fb_udp , fb_tcp, fb_http, fb_https, fb_quic)

CUST

Select cust protocol, to define the application-layer headers as part of the DMF request and response messages and optionally define a raw transport protocol as the Underlying Layer.

FTP (ftp), ftps, ftps_implicit

HTTP , HTTP2, HTTPS,

ICMP

IMAP

IMAP Fetch

MMS

MMS HTTP Send

POP3

POP3 LIST and RETR

HTTP/HTTPS

RTSP

SIP

SMTP

SMTP MAIL

TFTP

WAP/WSP

Wireless Village HTTP Get

Fireball

In Fireball mode there is an allocation bias toward maximum data plane performance for certain basic DMF data types and transport protocols (fb_udp , fb_tcp, fb_http, fb_https, fb_quic). This performance increase comes at the expense of DMF functionality and flexibility and restricted support for transport protocols/technologies.

Fireball Mode is used in conjunction with the Fireball checkbox which is supported in several test cases including AMF Nodal, MME Nodal and SGW Nodal. Fireball is a DMF threading model that provides optimized data performance.

Additional details in About Data Message Flows.

File Transfer Protocol (FTP)

FTP provides reliable and efficient file transfer between a client and a server.

FTP is a text-based protocol that runs over TCP. Two separate connections are used with FTP: a control connection and a data transfer connection. The server listens for connections on TCP port 21. When a client establishes the control connection with TCP, the server indicates that it is ready to receive requests. The client then sends requests to which the server responds.

Two modes can be used to establish the data transfer connection: active or passive.

In passive mode (PASV or EPSV command), the server notifies the client of the port that it will use for the transfer and the client initiates the TCP connection to the specified port.
In active mode (PORT or EPORT command), the client notifies the server of the port that it will use for the transfer and the server initiates the TCP connection to the specified port.

ftps data protocol is the same as "ftp" except that the TLS Tab is automatically added and Force 3-way Handshake should always be checked. Client Port is defaulted to 2000.

ftps_implicit data protocol is the same as "ftp" except that the TLS Tab is automatically added and Force 3-way Handshake should always be checked. Client Port is defaulted to 2000 and Server Port is defaulted to 990.

An FTP session transitions through the states shown in the table below.

State	Description
Control Connection	The client establishes a TCP connection, and the server responds with a status message.
Login	The client identifies itself to the server.
Transfer	The client and server negotiate the mode and connection to be used for the data transfer, the client and server exchange files, and the data connection is closed.
Logout	The client has issued a QUIT in one of the previous states. The FTP/TCP connection is being terminated.

The following tables describe the formats of the client requests and server responses used in the default DMFs.

Request	Description
USER name	The client supplies a user name (name) in response to the server status.
PASS password	The client supplies a password to the server.
PASV	An IPv4 client requests that passive mode be used for the data transfer.
EPSV protocol	An IPv4 or IPv6 client requests that passive mode and the requested protocol be used for the data transfer. A 1 requests IPv4 and a 2 requests IPv6. Protocol is automatically provisioned based on the MN's IP address.
PORT address and port	An IPv4 client requests that active mode be used for the transfer. The client IP address and port to be used for the data transfer are included with the command. Address and port are automatically provisioned with the MN's IP address and the Client Port defined in the data transfer subflow.
EPRT \|protocol\|address\|port\|	An IPv4 or IPv6 client requests that active mode be used for the transfer. The protocol, client IP address and port to be used for the data transfer are included with the command. A 1 requests IPv4 and a 2 requests IPv6. Protocol, address and port are automatically provisioned based on the MN's IP address and the Client Port defined in the data transfer subflow.
RETR x	The client requests a file (x) from the server.
QUIT	The client ends the session.

Request	Response	Description
USER	331 Please specify the password	The server requests the password for the supplied user name.
PASS	230 User logged in	The client login was successful.
PWD	257 /home/sseuser	The server responds to a PWD request with the current directory.
PASV	227 Entering Passive Mode (address and port)	The server confirms the use of passive mode and provides the IP address and port that will be used by the server for the data transfer. IP address and port are automatically provisioned with the Network Host address and the Server Port defined in the data transfer subflow.
EPSV	229 Entering Extended Passive Mode(\|\|\|port\|)	The server confirms the use of passive mode and provides the port that will be used for the data transfer. Port is automatically provisioned with the Server Port defined in the data transfer subflow.
PORT	200 PORT command successful. Consider using PASV.	The server confirms the use of active mode.
EPRT	200 PORT command successful. Consider using PASV.	The server confirms the use of active mode.
RETR	150 File status okay; about to open data connection — or — 226 Closing data connection; file transfer successful	The server notifies the client that the transfer is about to begin. When the transfer is complete, the server notifies the client that the data connection will be closed.
QUIT	221 Goodbye	The client ends the session, the server releases its resources, and the TCP session is closed.

The following DMFs are provided with FTP:

^ Back to Top

Hypertext Transfer Protocol (HTTP , HTTPS and HTTP2)

HTTP provides client access to web site content on a server.

HTTP is a text-based protocol that runs over TCP. The server listens for connections on TCP port 80. A client initiates the TCP connection and then sends requests to which the server responds. There are no authentication or authorization states within HTTP itself. Those tasks are left to the destination web site.

HTTPS consists of communication over Hypertext Transfer Protocol (HTTP) within a connection encrypted by Transport Layer Security (TCP) or SSL (Secure Sockets Layer).

The following tables describe the formats of the client requests and server responses used in the default DMFs.

Request	Description
GET file HTTP/v Host: host User-Agent: c	The client requests the content of a file from a host using the specified version (v) of HTTP. The client software (c) that initiates the request is identified in the User-Agent header.

Request	Response	Description
GET	HTTP/v 200 OK Date: d Content-Type: text/html Server: s content	The server responds with the web page. The headers identify the HTTP version (v), the date and time the page was accessed (d), and the server software (s) that handled the request. A blank line follows the headers, and the page content immediately follows.

Either HTTP 1.0 or HTTP 1.1 can be used in a message flow by simply modifying the version in the request and response headers. There is one major difference between the versions from a testing perspective: HTTP 1.1 uses persistent connection by default, and HTTP 1.0 does not. In a default configuration, HTTP 1.1 maintains the TCP connection through successive requests from the client, while HTTP 1.0 closes the TCP connection after the server response and the client initiates a new TCP connection with the next request.

Major differences between HTTP/2 and HTTP1/1.1

binary, instead of text
fully multiplexed, instead of ordered and blocking
can use on connection for parallelism
uses header compression to reduce overhead
allows servers to "push" responses pro-actively into client caches.

A sample HTTP 2 DMF is located in the "Basic" Library. It has a message flow of a typical http GET method, showing binary format, compressed headers, and multiple streams thus displaying most of the characteristics of HTTP2 with the exception of server pushes.

NOTES: HTTP2 DMF message editing rules:

Header lines is in this format: <header name>:<header value><CRLF>.
The header lines must be ended with “CRLF”.
Header name and header value must be split by “:”, note that no space is allowed beside “:”.
The pseudo-header names must start with “:”.
All header names must be lowercase, and comply to HTTP spec.
If there is body part, there must be an empty line (only “CRLF”) between the headers part and the body part.

HTTP redirect will not be supported in the HTTP2 protocol.

The following DMFs are provided with HTTP:

^ Back to Top

Internet Control Message Protocol (ICMP)

ICMP can be used in either Basic Data or Advanced Data DMFs. The ping option in the Data Protocol drop-down list configures a Basic Data DMF that sends Echo messages and responds with Echo Reply messages. You can construct an Advanced Data DMF with other types of ICMP messages by selecting custom for the protocol and manually defining messages with ICMP headers and payloads, or by using the Protocol Wizard.

Refer to RFC 792 for definitions of the ICMP messages supported by the Protocol Wizard.

^ Back to Top

Internet Message Access Protocol (IMAP)

IMAP provides client access to email messages on a server, and offers more extensive capabilities than POP3, including access to multiple mailboxes. IMAP is used for message retrieval — SMTP is used to send mail.

IMAP is a text-based protocol that runs over TCP. The server listens for connections on TCP port 143. When a client establishes a TCP connection, the server sends a greeting. The client then sends requests to which the server responds. An IMAP session transitions through the states shown in the table below.

State	Description
Connection	The client establishes a TCP connection, and the server responds with a greeting.
Not Authenticated	The client identifies itself to the server.
Authenticated	The client is authenticated using plain text, but must select a mailbox before issuing any commands that interact with a mailbox.
Selected	The client has selected a mailbox and can access its contents.
Logout	The client has issued a LOGOUT in one of the previous states. The IMAP/TCP connection is being terminated.

The following tables describe the formats of the client commands and the server responses used in the default DMF. Commands are not case sensitive, and client requests are prefixed with a unique identifier (tag). A different tag is used for each request sent, and the server's final response to the request should be prefixed with the same tag.

Command	Description
tag LOGIN name password	The client supplies a user name (name) and password in response to the server greeting, and the server responds with a login confirmation.
tag SELECT mailbox	The client identifies the mailbox to use, and the server responds with an inventory of the contents and status responses.
tag UID FETCH x	The client requests a single message by message number (x), and the server responds with the requested message and a completion confirmation.
tag LOGOUT	The client sends a request to end the session, the server responds with a confirmation and then releases its resources and closes the TCP connection.

There are three types of server responses: status responses, server data, and continuation requests. Status responses can be tagged or untagged. Un-tagged responses begin with *. Status responses are OK (success), NO (failure), BAD (protocol error), PREAUTH, and BYE. PREAUTH and BYE are always untagged. Responses are terminated with a CR-LF pair.

Request	Response	Description
	* OK IMAP4rev1 Server	The server responds to the TCP connection with a greeting.
LOGIN	tag OK Login completed	The server responds with the authentication status.
SELECT	* 2 EXISTS * 1 RECENT * OK [unseen 1] * FLAGS (/Answered/Deleted/Seen) tag OK [Read-Write] Complete	When the client selects a mailbox, the server responds with multiple messages that report: The number of messages in the mailbox (EXISTS). The message number of any unread messages (RECENT). This message is repeated for every unread message in the mailbox. The total number of unread messages and an OK keyword to terminate the unread message list. The mailbox flags. The client's mailbox permissions and a Complete keyword to terminate the SELECT responses.
UID FETCH	* 10 FETCH (UID n BODY [] {size} message ) tag OK Complete	The server responds to a FETCH by first transmitting the requested message and then sending a Complete message. The message packet includes the message number (n), the size of the message in bytes, the message, and a terminating parenthesis on the last line. Email message headers such as To and From are included in message.
LOGOUT	* BYE Logout Received tag OK Complete	The server first acknowledges the LOGOUT request, and then responds with a Complete when the session is terminated.

The following default DMF is provided with POP3:

IMAP Fetch

^ Back to Top

Multimedia Messaging Service (MMS)

MMS is more than a protocol, it is a network application that allows users to send and receive messages that include various types of media content. MMS is based on WAP architecture, and uses a number of technologies, network elements, and protocols to provide the service. A description of the many configurations and the binary encoding used with MMS is beyond the scope of this documentation.

The DMF provided with MMS — MMS HTTP Send — provides an example of MMS embedded in HTTP and transported over TCP.

With the Protocol Wizard, you can build an MMS/WSP message flow.

Refer to the Open Mobile Alliance specifications for definitions of the WSP and MMS messages supported by the wizard.

^ Back to Top

Post Office Protocol Version 3 (POP3)

POP3 provides basic, single mailbox, client access to email messages on a server. It does not support the ability to send email — SMTP performs that service.

POP3 is a text-based protocol that runs over TCP. The server listens for connections on TCP port 110. When a client establishes a TCP connection, the server sends a greeting. The client then sends requests to which the server responds. A POP3 session transitions through the states shown in the table below.

State	Description
Connection	The client establishes a TCP connection, and the server responds with a greeting.
Authorization	The client identifies itself to the server.
Transaction	The client sends requests, and the server responds. In this state, a number of different requests can be sent during one session. Requests can be pipelined, allowing up to 10 requests to be outstanding at any one time. Responses are not pipelined.
Update	The client ends the session by issuing a QUIT during the transaction state, the server releases its resources, and the TCP connection is closed.

The following table describes the formats of the client commands used in the default DMF.

Refer to RFC 1939 for definitions of the POP3 messages supported by the Protocol Wizard.

Command	Description
USER name	The client supplies a user name (name) in response to the server greeting. If an OK is received, the client can continue with PASS; otherwise, the client can re-issue USER or QUIT.
PASS password	The client supplies a password to the server. If an OK is received, the client can continue with LIST, RETR, or TOP; otherwise, the client can re-issue USER or QUIT.
LIST	The client requests a list of messages in the folder. If an OK is received, it is followed by a multi-line response including the number of messages and the message number and size of each.
RETR x	The client requests a single message by message number (x). If an OK is received, it is followed by a multi-line response including the message headers followed by a blank line and the message body.
TOP x y	The client requests the first y lines of message number x. If an OK is received, it is followed by a multi-line response including the message headers followed by a blank line and the first y lines of the message.
QUIT	The client ends the session, the server releases its resources, and the TCP connection is closed.

Server responses begin with a status indicator and keyword followed by optional text, and are terminated with a CR-LF pair. A positive server response uses the format +OK any text; an error response would use the -ERR any text format. The maximum response size is 512 characters including the terminating CR-LF. When the response includes multiple lines, the final line is .CRLF (period followed by CR-LF).

Request	Response	Description
	+OK	The server responds to the TCP connection with a greeting.
USER	+OK	The server acknowledges the user name.
PASS	+OK Ready	The server confirms the login and is ready to accept commands.
LIST	+OK t message n size .	The server responds to a LIST with an inventory of the mailbox's contents: The OK response acknowledges the command and reports the total (t) number of messages in the mailbox. The message number (n) and size in bytes of each message is transmitted in a separate packet. A period message terminates the inventory.
RETR	+OK size octets message .	The server first acknowledges the RETR command with the size of the email message, and then transmits the message terminated with a period on the last line. The email message headers are included in message.
QUIT	+OK bye	The server acknowledges the QUIT command and terminates the session.

The following default DMF is provided with POP3:

POP3 LIST and RETR

^ Back to Top

Real-Time Transport Protocol (RTP)

RTP is a transport protocol for real-time data such as streaming media. RTP is typically used with a companion protocol that establishes a session between the client and a server — SIP or RTSP, for example. RTP carries the data stream, and the companion protocol manages the session.

RTP is a bit-position, field-oriented protocol that can run over TCP or UDP. The server listens for connections on port 4900. An RTP session does not transition through states as such, the client establishes a connection with the underlying protocol, the content is sent by the server, and the client drops the connection. Normally, RTP is used during the retrieval state of its companion protocol, and the companion protocol controls the connection.

The complexity of the RTP packet format is beyond the scope of this documentation. The default DMF provided for RTP simulates an audio/video conference type. To define a different type of packet, refer to RFC 3550, "RTP: A Transport Protocol for Real-Time Applications."

The following default DMF is provided with RTP:

^ Back to Top

Real-Time Streaming Protocol (RTSP)

RTSP is a control protocol for streaming media to the client from a media server. Another protocol, typically RTP, is used to actually carry the media stream.

RTSP is a text-based protocol that can run over TCP or UDP. The server listens for connections on port 554. A client establishes the control session with a connection using the underlying protocol, and then sends a request to set up a stream. Multiple streams can be controlled by one RTSP session. An RTSP session transitions through the states shown in the table below.

State	Description
Connection	The client establishes a TCP connection.
Set Up	The client requests a connection for each of the media streams, and the server responds with a confirmation.
Play	The client requests the media content, the server responds with a confirmation, and the carrying protocol connections are established. The Play state is not required in an RTSP session — it can transition to Tear Down immediately following Set Up.
Tear Down	The client ends the session by issuing a TEARDOWN, and the media connections (if any) are closed as is the RTSP connection.

The following table describes the formats of the client commands used in the default DMF.

Command	Description
SETUP url RTSP/1.0 CSeq: n Transport: RTP/AVP;unicast;client_port=p — or — SETUP url RTSP/1.0 CSeq: n Session: s Transport: RTP/AVP;unicast;client_port=p	The client requests a url, provides a sequence number (n) for the command, and identifies the RTP/RTCP port pair (p) on which it wishes to receive the media content. The requested url takes the format rtsp://domain/directory/file name. The port pair should be separated with a dash: 4900-4901, for example. The server responds with a confirmation that includes a matching sequence number, a session number, and a transport header that confirms the client ports and identifies the server ports that will send the media content. If the server is responding to an initial SETUP request, it returns a unique session number (s). The session number is used in subsequent SETUP requests and responses if multiple media streams are requested.
PLAY url RTSP/1.0 CSeq: n Session: s	The client requests the media content, using the same url, sequence number, and session number used in the SETUP command. The server responds with a confirmation.
TEARDOWN url RTSP/1.0 CSeq: n Session: s	The client drops the media content connection established with the PLAY command, and the server responds with a confirmation. If no media connections remain, the RTSP session is terminated.

Command

Description

SETUP url RTSP/1.0
CSeq: n
Transport: RTP/AVP;unicast;client_port=p

— or —

SETUP url RTSP/1.0
CSeq: n
Session: s
Transport: RTP/AVP;unicast;client_port=p

The client requests a url, provides a sequence number (n) for the command, and identifies the RTP/RTCP port pair (p) on which it wishes to receive the media content.

The requested url takes the format rtsp://domain/directory/file name. The port pair should be separated with a dash: 4900-4901, for example.

The server responds with a confirmation that includes a matching sequence number, a session number, and a transport header that confirms the client ports and identifies the server ports that will send the media content. If the server is responding to an initial SETUP request, it returns a unique session number (s). The session number is used in subsequent SETUP requests and responses if multiple media streams are requested.

PLAY url RTSP/1.0
CSeq: n
Session: s

The client requests the media content, using the same url, sequence number, and session number used in the SETUP command. The server responds with a confirmation.

TEARDOWN url RTSP/1.0
CSeq: n
Session: s

The client drops the media content connection established with the PLAY command, and the server responds with a confirmation. If no media connections remain, the RTSP session is terminated.

All server responses begin with RTSP/1.0 200 OK. A response to a SETUP command includes the CSeq, Session, and Transport headers; responses to the PLAY or TEARDOWN commands include only the CSeq header.

Request	Response	Description
SETUP	RTSP/1.0 200 OK CSeq: n Session: s Transport: RTP/AVP;unicast;client_port=c;server_port=p	The server responds to a SETUP request with the sequence number supplied by the client (n), the session number (s), and the client (c) and server (p) ports that will be used for the stream.
PLAY	RTSP/1.0 200 OK Cseq: n	The server acknowledges the PLAY request with the client's sequence number (n).
TEARDOWN	RTSP/1.0 200 OK CSeq: n	The server acknowledges the TEARDOWN request with the client's sequence number (n), and releases the session connections.

Request

Response

Description

SETUP

RTSP/1.0 200 OK
CSeq: n
Session: s
Transport: RTP/AVP;unicast;client_port=c;server_port=p

The server responds to a SETUP request with the sequence number supplied by the client (n), the session number (s), and the client (c) and server (p) ports that will be used for the stream.

PLAY

RTSP/1.0 200 OK
Cseq: n

The server acknowledges the PLAY request with the client's sequence number (n).

TEARDOWN

RTSP/1.0 200 OK

CSeq: n

The server acknowledges the TEARDOWN request with the client's sequence number (n), and releases the session connections.

The following DMF is provided with RTSP:

^ Back to Top

Session Initiation Protocol (SIP)

SIP is an application-layer protocol that is used to control dialogs between one or more participants. A dialog can include, but is not limited to, an Internet telephone call, multimedia distribution, or multimedia conference. SIP does not include a data transfer mechanism — it must be used with another protocol, such as RTP, to provide data services.

SIP is a text-based protocol that can run over TCP or UDP. The User Agent Client (MN) establishes a TCP connection with a User Agent Server (Network Host), and then sends requests to which the server responds. A SIP session transitions through the states shown in the table below.

State	Description
Connection	The client establishes a TCP connection.
Dialog Establishment	The client requests a dialog with a participant, and the server responds with status messages and a final confirmation. The client must acknowledge the final confirmation.
Dialog Termination	The client ends the dialog by issuing a BYE, the server terminates the SIP session and releases the TCP connection.

All client messages follow the same format:

keyword SIP-URI SIP-version
headers

The first line of the message includes a keyword that identifies the type of message, the recipient (SIP-URI), and the SIP version. A SIP URI uses the format sip:user@host;port;transport=x to identify the protocol and the recipient's address, and can optionally include the port and transport (x). The message headers begin on the second line, and each header is terminated with a CR-LF pair.

The following tables describe the formats of the client requests and server responses used in the default DMF.

Refer to RFC 3261 and RFC 3265 for definitions of the SIP messages supported by the Protocol Wizard.

Request	Description
INVITE request-URI SIP/2.0 Contact: <initiator-URI> Via:SIP/2.0/transport response-URI;branch=bID Max-Forwards:f To:<request-URI> From:<initiator-URI>;tag=t Call-ID:cID CSeq:s INVITE	The client requests a SIP 2.0 dialog with a client recipient using the INVITE request. The request-URI identifies the recipient with a SIP URI (see above). The following headers are required with an INVITE request: Contact — provides a SIP URI that can be used to contact the initiating client for subsequent requests. Via — identifies the transport used and where the response is to be sent. The branch value (bID) identifies the transaction created by the request, and must be unique to all requests sent by a client. A branch value that begins with the character string "z9hG4bK" indicates that the client is RFC compliant. Max-Forwards — the maximum number of hops (f) that a request can transit on its way to the destination. To — identifies the recipient with a SIP URI. From — identifies the initiator with a SIP URI and a tag (t) generated for the dialog. The tag value must be globally unique and cryptographically random. Call-ID — a unique identifier with the format string@host for messages used in a SIP session. Messages sent by either end of the dialog must contain the same cID. A new request outside of the dialog is assigned a different, globally unique Call-ID. CSeq — an identifier that groups messages involved in a transaction, consisting of a sequence number (s) followed by the request keyword.
ACK request-URI SIP/2.0 headers CSeq:s ACK	The client responds to the server's confirmation that the dialog has been established. All of the headers used in the INVITE request are required in the ACK except for the Contact header. All header values should match the INVITE message headers except for the ACK keyword used in the CSeq header. Data transfer can commence after the ACK is received.
BYE request-URI SIP/2.0 headers CSeq:s BYE	The client ends the session. All of the headers used in the INVITE request are required in the BYE request except for the Contact header. All header values should match the INVITE message headers except for the BYE keyword used in the CSeq header.

Request

Description

INVITE request-URI SIP/2.0
Contact: <initiator-URI>
Via:SIP/2.0/transport response-URI;branch=bID
Max-Forwards:f
To:<request-URI>
From:<initiator-URI>;tag=t
Call-ID:cID
CSeq:s INVITE

The client requests a SIP 2.0 dialog with a client recipient using the INVITE request. The request-URI identifies the recipient with a SIP URI (see above).

The following headers are required with an INVITE request:

Contact — provides a SIP URI that can be used to contact the initiating client for subsequent requests.
Via — identifies the transport used and where the response is to be sent. The branch value (bID) identifies the transaction created by the request, and must be unique to all requests sent by a client. A branch value that begins with the character string "z9hG4bK" indicates that the client is RFC compliant.
Max-Forwards — the maximum number of hops (f) that a request can transit on its way to the destination.
To — identifies the recipient with a SIP URI.
From — identifies the initiator with a SIP URI and a tag (t) generated for the dialog. The tag value must be globally unique and cryptographically random.
Call-ID — a unique identifier with the format string@host for messages used in a SIP session. Messages sent by either end of the dialog must contain the same cID. A new request outside of the dialog is assigned a different, globally unique Call-ID.
CSeq — an identifier that groups messages involved in a transaction, consisting of a sequence number (s) followed by the request keyword.

ACK request-URI SIP/2.0
headers
CSeq:s ACK

The client responds to the server's confirmation that the dialog has been established. All of the headers used in the INVITE request are required in the ACK except for the Contact header. All header values should match the INVITE message headers except for the ACK keyword used in the CSeq header.

Data transfer can commence after the ACK is received.

BYE request-URI SIP/2.0
headers
CSeq:s BYE

The client ends the session. All of the headers used in the INVITE request are required in the BYE request except for the Contact header. All header values should match the INVITE message headers except for the BYE keyword used in the CSeq header.

Request	Response	Description
INVITE	SIP/2.0 100 Trying SIP/2.0 180 Ringing SIP/2.0 200 OK	The server responds to an INVITE with status messages indicating that it is locating the recipient (Trying), that it is attempting to establish a dialog with the recipient (Ringing), and that it has established the dialog (OK). The client must respond to the final OK with an ACK before data transfer can begin.
BYE	SIP/2.0 200 OK	The server acknowledges the end of session request, releases its resources, and the TCP connection is closed.

Request

Response

Description

INVITE

SIP/2.0 100 Trying

SIP/2.0 180 Ringing

SIP/2.0 200 OK

The server responds to an INVITE with status messages indicating that it is locating the recipient (Trying), that it is attempting to establish a dialog with the recipient (Ringing), and that it has established the dialog (OK).

The client must respond to the final OK with an ACK before data transfer can begin.

BYE

SIP/2.0 200 OK

The server acknowledges the end of session request, releases its resources, and the TCP connection is closed.

The following DMF is provided with SIP:

^ Back to Top

Simple Mail Transfer Protocol (SMTP)

SMTP is used to send email messages from a client to a mail server and from the sender's mail server to the recipient's mail server. Messages are received by a client using IMAP or POP3.

SMTP is a text-based protocol that can run over various reliable transport protocols. TCP is used to transport SMTP in the test system. The server listens for connections on port 25. When a client establishes a connection, the server sends a greeting. The client then sends requests to which the server responds. An SMTP session transitions through the states shown in the table below.

State	Description
Connection	The client establishes a connection, and the server responds with a greeting.
Session Establishment	The client identifies itself to the server.
Mail Transaction	The client sends requests, and the server responds. In this state, a number of different requests can be sent during one session. Requests can be pipelined, allowing up to 10 requests to be outstanding at any one time. Responses are not pipelined.
Session Termination	The client ends the session by issuing a QUIT during the transaction state, the server releases its resources, and the connection is closed.

The following tables describe the formats of the client requests and server responses used in the default DMF. Each command is terminated with a CR-LF pair.

Refer to RFC 2821 for definitions of the SMTP messages supported by the Protocol Wizard.

Request	Description
EHLO domain	The client requests a session, identifies itself by domain, and indicates that it supports SMTP service extensions by using the EHLO command rather than HELO.
MAIL FROM: <sender>	The client initiates a mail transaction with the MAIL command, and transmits the first email header. The FROM header includes the sender's email address enclosed in angle brackets.
RCPT TO: <recipient>	The client identifies the recipient of the message, including the recipient's email address enclosed in angle brackets. If the message is being sent to multiple recipients, this command is repeated for each recipient.
DATA	The client notifies the server that it is ready to transmit the email message content. When the server acknowledgement is received, the transmittal begins.
BDAT n [LAST]	The BDAT command can be used as an alternative to the DATA command. With BDAT, the command is issued preceding each message content packet and n identifies the number of octets in the following packet. The LAST keyword is included before the final packet is transmitted.
message content	The client transmits the email message content in one or more packets. When using the DATA command, the termination of the message is indicated with a line that contains, and only contains, a period followed by a CR-LF pair. The termination code may be sent in a separate packet.
QUIT	The client ends the session.

Request	Response	Description
	220 domain	The server notifies the client that it is ready to accept requests and identifies its domain.
EHLO	250-domain Welcome	The server acknowledges the session request, and informs the client of its capabilities in the following messages.
	250-CHUNKING	The server indicates that it supports the BDAT command, and that email message content can be transmitted in octet "chunks."
	250 PIPELINING	The server indicates that it supports pipelining.
MAIL	250 OK	The server acknowledges the start of the transaction.
RCPT	250 OK	The server acknowledges receipt of the recipient command.
DATA	354 Send Data 250 OK	The server notifies the client that it is ready to accept the email message content. Upon receipt of the termination code, the server acknowledges that message transmission is complete. The server does not acknowledge each message packet.
BDAT	250 OK	The server acknowledges receipt of each message packet, including the last.
QUIT	221 Bye	The server acknowledges the end of session request, releases its resources, and the TCP connection is closed.

The following DMF is provided with SMTP:

SMTP MAIL

^ Back to Top

Trivial File Transfer Protocol (TFTP)

TFTP is a simple protocol that is used to transfer files between a client and a server.

TFTP is a bit-position, field-oriented protocol that runs over UDP. Two separate connections are used: one for the client requests, and one for the data transfer. The server listens for requests on UDP port 69 and responds to requests received. TFTP is a stateless protocol that does not support pipelining. Each message must be acknowledged before the next message is sent.

The general format of a TFTP request message includes an operation code, the file name, and the transfer mode as shown below. The two variable length fields are terminated with a 0 byte. An Opcode of 01 identifies a read request (RRQ), and 02 identifies a write request (WWQ).

The format of a data transfer message includes an operation code, a sequential block number, and the data octets as shown below. An Opcode of 03 identifies the message as a data transfer block. The block number occupies two bytes, begins at 01, and increments by 1 for each subsequent block in the transfer. Each data message has a fixed size of 512 bytes except for the last, which includes only the number of bytes required to complete the file. A message size of less than 512 bytes notifies the destination that it has received the final block in the transfer.

Data transfer messages are acknowledged with an operation code and the number of the block received as shown below. An Opcode of 04 identifies an acknowledgement, and the block number occupies two bytes.

The following DMF is provided with TFTP:

TFTP RRQ

^ Back to Top

Wireless Application Protocol (WAP)

WAP is not a single protocol. It defines a set of standard components that enable communication between MNs and network servers. The DMFs provided with WAP use Wireless Session Protocol (WSP) and Wireless Transport Protocol (WTP) in a WAP 1.x protocol stack.

WTP is a transaction protocol designed to operate efficiently over a wireless datagram network and can provide reliable and non-reliable service. Reliable service allows for re-transmissions (waiting for an acknowledgement). Counters are defined to determine the maximum number of re-transmissions while awaiting an acknowledgement. Re-transmissions, acknowledgements, Transaction ID (TID) verification, and timing is performed in the WTP layer and not by the upper layer (WSP). WTP is connection-less in that explicit connection setup or teardown phases are not performed.

WSP provides HTTP/1.1 functionality, and can operate in a connection mode or a connection-less mode. Connection-less mode WSP bypasses the WTP layer and interfaces directly with the transport layer (UDP). Connection mode WSP establishes reliable sessions between the client and server and uses the services of the WTP to transmit and receive packets. WSP messages can be encoded to optimize the amount of data transmitted over the air.

The complexity of WSP requires that you must be familiar with the protocol to properly encode messages. WTP messages are automatically generated during the test using the protocol and message parameters in the message flow definition and cannot be manually modified.

The following DMFs are provided with WAP:

^ Back to Top

Wireless Village (WV)

Wireless Village is more than a protocol: it is a network application that allows users to send and receive instant messages and provides other services such as chat and group list maintenance. A description of the many configurations and commands available with WV is beyond the scope of this documentation.

The DMF provided with WV — Wireless Village HTTP Get — provides an example of WV Client Server Protocol (CSP) embedded in HTTP and transported over TCP.

RTP Voice / RTP Video

The RTP Voice or RTP Video File tab is available when you select rtpvoice / rtpvideo protocol (if your system is licensed).

Configure the following parameters:

RTP Voice Tab - The rtpvoice protocol supports native RTP with Audio codecs. The DMF configuration includes all the parameters required to accomplish RTP Audio.

RTP Video Tab - The rtpvideo protocol supports H.265, H.264, H.263 and VP8 Codecs. The DMF configuration includes a subset of the parameters required to accomplish RTP Video.

ABR

The purpose is to test the EPC for how well ABR DASH is downloading and playing. When ABR data type is selected, transaction related configuration fields will be greyed out. It will be continuous data traffic between client and server. Underlying Layer should be selectable: http/https, default value is http. When Underlying Layer https is selected, TLS tab should available to configure the cipher parameters. ABR DASH is a kind of general available data traffic type like http, tcp and etc. It can be used by any test case and used in any tunnel type.

See Data Message Flow - ABR for configuration information.

^ Back to Top