#62 Scalable RTP playback system for SIPp

[Deon Van der Westhuysen]

Below is information about an improved RTP playback system for SIPp. Attached patch is based on http://sourceforge.net/projects/sipp/files/sipp/3.3/sipp-3.3.tar.gz/download .

RTPStream description:

RTPStream is a highly scable framework for playing back RTP streams from SIPp as part of a load test. It has been tested up to 3000 concurrent calls playing from a single SIPp application instance (on Windows Server 2008 with a modified Cygwin1.dll and HP NC382i NICs) Beyond this point the NIC started to drop frames.

Multiple RTP playback streams are handled per thread (configurable, default is 20) and each playback stream is fully independent. Playback files are preloaded into memory and shared across calls playing back the same file.

Playback does not require PCAP or other external libraries. Only requirement is to supply raw audio files encoded in the desired playback codec. Minimum and maximum RTP port numbers are configurable.

The current code supports G.711 and G.729 codecs for playback but it is trivial to add other codecs with fixed packet sizes. (Playback parameters in code are: time between each packet [p-time], number of bytes from audio file to copy into each packet and the number of ticks to advance the RTP clock)

The RTP playback can be paused and resumed from the xml scenarios. The playback of an active RTP stream is automatically paused when a 0.0.0.0 (hold) media address is received in a SDP and will automatically resume as soon as a valid media address is received again.

The RTPStream framework can co-exist with PCAPPLAY playback.

Current limitations:

• No support for RTP echo [should be relatively easy to add]
• No support for playback of video [some stub code provided]

RTPStream usage:

The RTP streaming functionality introduces five new SIPp options and a new scenario action.

The command line options are:

• min_rtp_port: The lowest port number SIPp will use for RTP traffic. Default is 8192.
• max_rtp_port: The highest port number SIPp will use for RTP traffic. Default is 65535.
• rtp_payload: Default payload type for RTP traffic. Default is 8 (PCMA).
• rtp_threadtasks: The number of RTP stream playback tasks per thread. Default is 20.
• rtp_buffsize: The send/receive buffer size for each RTP socket. Default is 65535.

rtp_playload may be set to 0 (PCMU), 8 (PCMA) or 18 (G729) and can be overrided from the scenario.

The new action “rtp_stream” control the playpack of RTP traffic from within a scenario and has the following parameters:

• pause: pause the playback of the current RTP stream. When paused, no RTP packets are transmitted. Requests to pause an already paused playback are simply discarded.
• resume: resume the playback of a paused RTP stream. Playback resumes from the last position played. Resuming an already playing stream is simply ignored, as are requests to pause or resume a call with no actively playing RTP stream.
• anything else is interpreted as a playback request. The format is as described below.

The format for the playback string is: <filename>[,<loopcount>[,<payloadtype>]]

<filename> should point to a raw audio file (i.e. no headers etc.) encoded in the specified codec (either in the playback parameter string or command line). If no codec is specified, PCMA is assumed. No processing is done on the contents of this file – every 20ms a fixed number of bytes (based on selected codec) of the file is wrapped in a RTP header and transmitted to the remote party. Note: the filename cannot contain a “,” as part of the filename.

<loopcount> specifies how many times the audio file is played before playback automatically stops. If no <loopcount> is specified it defaults to 1 (play the file once). <loopcount> is decremented after each playback of the file. When <loopcount> reaches 0 playback is stopped – no more RTP packets are transmitted. This does not however end the call and a new playback file can be specified. Specify a <loopcount> of -1 to have the playback repeat forever.

<payloadtype> tells SIPp what codec was used to encode the audio file. Currently payload types 0, 8 and 18 are currently supported.

[Deon Van der Westhuysen]

Here is the patch.