SIPP User Guide)

Document directory

• 1.2.1 UAC. BAT:
• 1.2.2 data.csv:
• 1.2.3 UAC. xml:

 

1 installation and Overview:

SIPP is a tool software used to test the performance of the SIP protocol. This is a GPL open source software.

It contains some basic sipstone user proxy workflows (UAC and UAS) and can be used to create and release multiple calls using invite and B ye. It can also read the XML scenario file, that is, the configuration file that describes any performance tests. It dynamically displays test running statistics (call rate, back-to-back signal latency, and message statistics ). Periodically dump the CSV statistics. TCP and UDP on multiple sockets can be reused by means of re-transmission management. You can use regular expressions in the scenario definition file to dynamically adjust the call rate.

SIPP can be used to test many real sip devices, such as sip proxy, b2buas, SIP Media Server, SIP/X gateway, and sip pbx, it can also simulate thousands of SIP proxy calls to your SIP System.

Sipp url: http://sipp.sourceforge.net/, you can download the latest version of sippsoftware, and provide information in English.

1.1 SIPP Installation

SIPP provides Linux, windows, and HPUX versions. The installation on Windows is very simple. Next we will talk about the installation in Linux.

First, you can download the latest version of SIPP from the http://sourceforge.net/projects/sipp/files/sipp/3.2/, unzip it to get an RPM file, you can use the RPM command to complete the installation. If you get the green version of SIPP, You need to recompile it to use it. SIPP is written in C ++, so the system must support g ++ to compile successfully.

SIPP supports four different installation modes:

1) No TLS support or password verification support:

A) # tar-xvf sipp-1.1rc6.tar.gzb)

# Cd sipp-1.1.rc6c)

# Makemake

The SIPP file is an executable file. You only need to use the scenario XML file and CSV file to perform the SIP test. This is the most common installation.

 

2) supports TLS and password verification, but does not support pcap voice playback:

A) # tar-xvf sipp-1.1rc6.tar.gzb)

# Cd sipp-1.1.rc6c)

# Make ossl

In this way, the compiled file is added to the TLS support for password verification.

 

3) pcap play is supported, but password verification is not supported: (pcap play means RTP speech can be performed, but no 407 auth verification is performed)

A) # tar-xvf sipp-1.1rc6.tar.gzb)

# Cd sipp-1.1.rc6c)

# Make pcapplay

 

4) Support for pcap audio file playback and password verification: (407 auth verification supported)

A. # tar-xvf sipp-1.1rc6.tar

B) # cd sipp-1.1.rc6

C) # Make pcapplay_ossl

1.2 SIPP usage

When using SIPP for testing, prepare five files: UAC. bat, UAS. bat, UAC. XML, UAS. XML, and data.csv.

UAC. BAT: Call the SIPP command, pass in the batch processing file of the corresponding parameters, and simulate UAC (for example, the main name ).

UAS. BAT: Call the SIPP command, pass in the batch processing file of the corresponding parameters, simulate UAS (such as called), of course, do not prepare this file to directly input the SIPP command to execute the program, however, it is more convenient and reliable to write and execute files.

UAC. xml: The UAC-side sip signal process.

UAS. xml: the UAs-side sip signal process.

Data.csv: Used for the data to be introduced in UAC. xml and UAS. xml.

The following is an example of how to compile and use these five files.

 

1.2.1 UAC. BAT:

Example:

SIPP-Sn UAC 172.31.89.4: 5060-R 1-RP 3000-INF data.csv-P 7098-I 172.31.89.242-s 8001-SF uac_onecall.xml-M 1000-l 900

Parameters:

172.31.89.4: 5060: Remote address and port (introduced in the script using [remote_ip] and [remote_port)

-R 1-RP 3000: Send a call every three seconds

-INF data.csv: import the Data configuration file

-P 7098: local port (introduced in the script using [local_port)

-I 172.31.89.242: local address (introduced in the script using [local_ip)

-S 8001: called Number (introduced using [SERVICE] in the script)

-SF uac_onecall.xml: Introduce the script file and write it according to the call process to be simulated.

-Sn UAC: executes the default UAC process. If you need to execute a self-compiled process file, this parameter should not be included in the command.

-M 1000: stops and exits after sending the 1000 call.

-L 900: the maximum number of calls to be retained at the same time. The default value is 3 * caps * Call duration. When the total number of existing calls reaches this value for various reasons, the SIPP stops generating new calls until the total number of existing calls falls below this value.

1.2.2 data.csv:

Example:

Sequential

8000;

The first behavior is the number method, usually sequential or random.

In this example, there is only one data entry. [field0] is used for import. If there are multiple data entries, separate them with semicolons. The numbers are incremented during reference, for example, [field1] and [field2].

 

1.2.3 UAC. xml:

Example:

<Scenario name = "branch_client">

 

<Send retrans = "500">

<! [CDATA [

 

Invite SIP: [SERVICE] @ [remote_ip] Sip/2.0

Via: SIP/2.0/[transport] [local_ip]: [local_port]; branch = [branch]; rport

Allow: Invite, cancel, ack, bye, options, refer, policy, message, subscribe, Info

From: "[field0]" <SIP: [field0] @ [local_ip]>; tag = [call_number]

To: "[SERVICE]" <SIP: [SERVICE] @ [remote_ip]>

Call-ID: [call_id]

CSeq: 1 invite

Contact: <SIP: [field0] @ [local_ip]: [local_port]>

Max-forwards: 70

Content-Type: Application/SDP

Content-Length: [Len]

 

V = 0

O = [field0] 00 inip4 [local_ip]

S = SIP call

T = 0 0

C = in ip4 [local_ip]

M = audio [media_port] RTP/AVP 0

A = rtpmap: 0 PCMU/8000

 

]>

</Send>

Note:

1. For parameters that require SIPP command value assignment, refer to UAC. Bat instructions.

[Local_ip], [local_port], [remote_ip], [remote_port], and [Service]

2. SIPP automatically detects the generated parameters:

[Call_number], [call_id], [CSeq], [Len], and [branch]

3.for details about how to import data from the data configuration file, see data.csv. The first value is field0.

4. CSeq: 1 invite: Here it should have been written as CSeq: [CSeq] invite, and CSeq: [CSeq] ack in the corresponding ACK, however, when the invite and ACK are mixed with prack, if Ack is written in the above form, it cannot correspond to invite, so it can be written to death.

5. When testing the service, you should add <route: called Side address> in the header domain to ensure that the call will be routed to the called from the AS, otherwise the as will send a message to the default address.

 

<Recv response = "100" Optional = "true">

</Recv>

Note: As expected, 100 trying may be affected after invite is sent, or trying may not be received. Therefore, an optional flag is added.

 

& Lt; Recv response = "180" & gt;

</Recv>

Note: If a response other than 180 is received, the system exits unexpectedly.

 

& Lt; Recv response = "200" & gt;

</Recv>

 

<Send>

<! [CDATA [

 

Ack SIP: [SERVICE] @ [remote_ip] Sip/2.0

Via: SIP/2.0/[transport] [local_ip]: [local_port]; branch = [branch]; rport

[Last_from:]

[Last_to:]

Call-ID: [call_id]

Contact: <SIP: [field0] @ [local_ip]: [local_port]>

CSeq: 1 ack

Max-forwards: 70

Content-Length: 0

 

]>

</Send>

Note: When sending a request, it is neither necessary nor possible to fill in all fields again (for example, the from field is not required because the from field in a dialog is the same; the to field cannot be filled in by itself, and must be introduced from the previous response, because the to-tag is added at the remote end and is unknown locally ), therefore, you can use the [last _ field name] method to retrieve it from the previous message.

Generally, the from and to fields are obtained from the previous message. For ack 200, via can be copied from the initial invite. At this time, the branch parameter will automatically generate a value different from the initial invite; when the Ack is not 200, it is introduced from the previous message.

 

<Pause milliseconds = "30000"/>

Note: The call status is maintained for 30 seconds to simulate the duration of the actual call.

 

<NOP>

<Action>

<Exec play_pcap_audio = "C: \ 711. pcap"/>

<Exec play_pcap_video = "C: \ h263.pcap"/>

</Action>

</NOP>

Note: you can send a media stream in the call status if needed. The premise is that there is a media stream file under the corresponding directory.

 

<Send retrans = "500">

<! [CDATA [

 

Bye SIP: [SERVICE] @ [remote_ip] Sip/2.0

Via: SIP/2.0/[transport] [local_ip]: [local_port]; branch = [branch]; rport

[Last_from:]

[Last_to:]

Call-ID: [call_id]

CSeq: 2 bye

Max-forwards: 70

Content-Length: 0

 

]>

</Send>

Note: After the retrans parameter is added, you can re-transmit the data after the set time without receiving the response. In this example, the value is 500 milliseconds.

 

& Lt; Recv response = "200" & gt;

</Recv>

 

<Pause milliseconds = "3000"/>

 

<! -- Definition of the response time repartition table (unit is MS) -->

<Responsetimerepartition value = "10, 20,30, 40, 50,100,150,200"/>

 

<! -- Definition of the call length repartition table (unit is MS) -->

<Calllengthrepartition value = "10, 50,100,500,100 0, 5000,100 00"/>

 

</Scenario>

 

2. FAQs:

1. Unable to bind main socket, errno = 125.

The local port you want to bind is already in use. You can change it to another one.

 

2. While expecting '000000' response, received' Sip/180 2.0 OK

In the script, 100 or 180 is received after invite is sent, and 200 is received directly. You can add optional = "true" after 180.

 

3. No response after a message is sent

Make sure that the remote server-side system is normal and the remote address and port in UAC. Bat are correct. In addition, you may need to add the local address to the trusted node of the server.

 

4. Can't open pcap file '711. pcap '.

Make sure that the media stream file exists, the path is correct, and the media stream file is available.

 

2.1 UAS. bat

Example:

SIPP-Sn UAC 172.31.89.4: 5060-INF data.csv-I 172.31.89.242-P 8890-s 8001-SF uas_onecall.xml

For more information about the parameters, see UAC. bat.

 

2.2 UAS. xml

Example:

<Scenario name = "branch_server">

<Recv request = "invite">

<Action>

<Ereg Regexp = ". *" search_in = "HDR" header = "CSeq:" assign_to = "6"/>

<Ereg Regexp = ". *" search_in = "HDR" header = "via:" assign_to = "5"/>

</Action>

</Recv>

Regular Expression usage instructions: In this example, it is not required, but in many cases, you need to use it. When the sequence contains prack, when UAS sends the 200 OK message of invite, some fields (such as via and CSeq) cannot be introduced from the received message using the [last _ field name] method, because the previous message is prack rather than invite, you need to save the two fields of invite for future use. The above usage is to save the value of the CSeq field of invite as number 6 and use it when sending the 200 OK message of invite in the following way: CSeq: [$6]

 

<Send>

<! [CDATA [

 

Sip/2.0 100 trying

[Last_via:]

[Last_from:]

[Last_to:]

[Last_Call-ID:]

[Last_cseq:]

Content-Length: 0

 

]>

</Send>

Note: basically all fields can be introduced from the previous message.

 

<Send>

<! [CDATA [

 

Sip/2.0 180 ringing

[Last_via:]

[Last_from:]

[Last_to:]; tag = [call_number]

[Last_Call-ID:]

[Last_cseq:]

[Last_Record-Route:]

Contact: <SIP: [local_ip]: [local_port]>

P-asserted-Identity: "[SERVICE]" <SIP: [SERVICE] @ [local_ip]>

Content-Length: [Len]

 

]>

</Send>

Note: When the to field is introduced from the previous message, you need to add the to-tag. The call_number is automatically generated by SIPP and 1 is added during continuous calls. When a related field is introduced from the previous message, if this field is not found in the previous message, it will not exist in this message.

 

<Pause milliseconds = "5000"/>

 

<Send>

<! [CDATA [

 

Sip/2.0 200 OK

[Last_via:]

Allow: Invite, cancel, ack, bye

[Last_from:]

[Last_to:]; tag = [call_number]

[Last_Call-ID:]

[Last_cseq:]

[Last_Record-Route:]

Contact: <SIP: [local_ip]: [local_port]>

P-asserted-Identity: "[SERVICE]" <SIP: [SERVICE] @ [local_ip]>

Content-Type: Application/SDP

Content-Length: [Len]

 

V = 0

O = [SERVICE] 00 inip4 [local_ip]

S = SIP call

T = 0 0

C = in ip4 [local_ip]

M = audio10000 RTP/AVP 0

A = rtpmap: 0 PCMU/8000

]>

</Send>

Note: The previous message of 100,180,200 is an INVITE message. Therefore, the to-tag must be added to the to field, and the call_number in a dialog is the same, so it can be consistent with the to-tag of 180.

 

<Recv request = "Ack">

</Recv>

 

<Recv request = "bye">

</Recv>

 

<Send>

<! [CDATA [

 

Sip/2.0 200 OK

[Last_via:]

[Last_from:]

[Last_to:]

[Last_Call-ID:]

[Last_cseq:]

Contact: <SIP: [local_ip]: [local_port]; Transport = [transport]>

Content-Length: 0

]>

</Send>

Note: The cantact field cannot be introduced from the previous message.

 

<! -- Keep the call open for a while in case the 200 is lost to be -->

<! -- Able to retransmit it if we receive the bye again. -->

<Pause milliseconds = "3000"/>

 

<! -- Definition of the response time repartition table (unit is MS) -->

<Responsetimerepartition value = "10, 20,30, 40, 50,100,150,200"/>

 

<! -- Definition of the call length repartition table (unit is MS) -->

<Calllengthrepartition value = "10, 50,100,500,100 0, 5000,100 00"/>

 

</Scenario>