1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
|
Integrated scenarios
====================
Integrated scenarios? Yes, there are scenarios that are embedded in
SIPp executable. While you can create your own custom SIP scenarios
(see how to create your own XML scenarios), a few basic (yet useful)
scenarios are available in SIPp executable.
UAC
```
Scenario file: :download:`uac.xml <uac.xml>`
::
SIPp UAC Remote
|(1) INVITE |
|------------------>|
|(2) 100 (optional) |
|<------------------|
|(3) 180 (optional) |
|<------------------|
|(4) 200 |
|<------------------|
|(5) ACK |
|------------------>|
| |
|(6) PAUSE |
| |
|(7) BYE |
|------------------>|
|(8) 200 |
|<------------------|
UAC with media
``````````````
Scenario file: :download:`uac_pcap.xml <uac_pcap.xml>`
::
SIPp UAC Remote
|(1) INVITE |
|------------------>|
|(2) 100 (optional) |
|<------------------|
|(3) 180 (optional) |
|<------------------|
|(4) 200 |
|<------------------|
|(5) ACK |
|------------------>|
| |
|(6) RTP send (8s) |
|==================>|
| |
|(7) RFC2833 DIGIT 1|
|==================>|
| |
|(8) BYE |
|------------------>|
|(9) 200 |
|<------------------|
UAS
```
Scenario file: :download:`uas.xml <uas.xml>`
::
Remote SIPp UAS
|(1) INVITE |
|------------------>|
|(2) 180 |
|<------------------|
|(3) 200 |
|<------------------|
|(4) ACK |
|------------------>|
| |
|(5) PAUSE |
| |
|(6) BYE |
|------------------>|
|(7) 200 |
|<------------------|
regexp
``````
Scenario file: :download:`regexp.xml <regexp.xml>`
This scenario, which behaves as an UAC is explained in greater details
in this section.
::
SIPp regexp Remote
|(1) INVITE |
|------------------>|
|(2) 100 (optional) |
|<------------------|
|(3) 180 (optional) |
|<------------------|
|(4) 200 |
|<------------------|
|(5) ACK |
|------------------>|
| |
|(6) PAUSE |
| |
|(7) BYE |
|------------------>|
|(8) 200 |
|<------------------|
branch
``````
Scenario files: :download:`branchc.xml <branchc.xml>` and
:download:`branchs.xml <branchs.xml>`
Those scenarios, which work against each other (branchc for client
side and branchs for server side) are explained in greater details in
this section.
::
REGISTER ---------->
200 <----------
200 <----------
INVITE ---------->
100 <----------
180 <----------
403 <----------
200 <----------
ACK ---------->
[ 5000 ms]
BYE ---------->
200 <----------
UAC Out-of-call Messages
````````````````````````
Scenario file: :download:`ooc_default.xml <ooc_default.xml>`
When a SIPp UAC receives an out-of-call request, it instantiates an
out-of-call scenario. By default this scenario simply replies with a
200 OK response. This scenario can be overridden by passing the -oocsf
or -oocsn command line options.
::
SIPp UAC Remote
|(1) .* |
|<------------------|
|(2) 200 |
|------------------>|
3PCC
````
3PCC stands for 3rd Party Call Control. 3PCC is described in
:RFC:`3725`. While this feature was first developed to allow 3PCC like
scenarios, it can also be used for every case where you would need one
SIPp to talk to several remotes.
In order to keep SIPp simple (remember, it's a test tool!), one SIPp
instance can only talk to one remote. Which is an issue in 3PCC call
flows, like call flow I (SIPp being a controller)::
A Controller B
|(1) INVITE no SDP | |
|<------------------| |
|(2) 200 offer1 | |
|------------------>| |
| |(3) INVITE offer1 |
| |------------------>|
| |(4) 200 OK answer1 |
| |<------------------|
| |(5) ACK |
| |------------------>|
|(6) ACK answer1 | |
|<------------------| |
|(7) RTP | |
|.......................................|
Scenario file: :download:`3pcc-A.xml <3pcc-A.xml>`
Scenario file: :download:`3pcc-B.xml <3pcc-B.xml>`
Scenario file: :download:`3pcc-C-A.xml <3pcc-C-A.xml>`
Scenario file: :download:`3pcc-C-B.xml <3pcc-C-B.xml>`
The 3PCC feature in SIPp allows to have two SIPp instances launched
and synchronised together. If we take the example of call flow I, one
SIPp instance will take care of the dialog with remote A (this
instance is called 3PCC-C-A for 3PCC-Controller-A-Side) and another
SIPp instance will take care of the dialog with remote B (this
instance is called 3PCC-C-B for 3PCC-Controller-B-Side).
The 3PCC call flow I will, in reality, look like this (Controller has
been divided in two SIPp instances)::
A Controller A Controller B B
|(1) INVITE no SDP | | |
|<------------------| | |
|(2) 200 offer1 | | |
|------------------>| | |
| sendCmd (offer1) | |
| |----------------->| |
| | recvCmd |
| | |(3) INVITE offer1 |
| | |------------------>|
| | |(4) 200 OK answer1 |
| | |<------------------|
| | sendCmd |
| | (answer1) | |
| |<-----------------| |
| recvCmd |(5) ACK |
| | |------------------>|
|(6) ACK answer1 | | |
|<------------------| | |
|(7) RTP | | |
|..........................................................|
As you can see, we need to pass information between both sides of the
controller. SDP "offer1" is provided by A in message (2) and needs to
be sent to B side in message (3). This mechanism is implemented in the
scenarios through the <sendCmd> command. This::
<sendCmd>
<![CDATA[
Call-ID: [call_id]
[$1]
]]>
</sendCmd>
Will send a "command" to the twin SIPp instance. Note that including
the Call-ID is mandatory in order to correlate the commands to actual
calls. In the same manner, this::
<recvCmd>
<action>
<ereg regexp="Content-Type:.*"
search_in="msg"
assign_to="2"/>
</action>
</recvCmd>
Will receive a "command" from the twin SIPp instance. Using the
regular expression mechanism, the content is retrieved and stored in a
call variable ($2 in this case), ready to be reinjected::
<send>
<![CDATA[
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port]
From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]
Call-ID: [call_id]
CSeq: 1 ACK
Contact: sip:sipp@[local_ip]:[local_port]
Max-Forwards: 70
Subject: Performance Test
[$2]
]]>
</send>
In other words, sendCmd and recvCmd can be seen as synchronization
points between two SIPp instances, with the ability to pass parameters
between each other.
Another scenario that has been reported to be do-able with the 3PCC
feature is the following:
+ A calls B. B answers. B and A converse
+ B calls C. C answers. C and B converse
+ B "REFER"s A to C and asks to replace A-B call with B-C call.
+ A accepts. A and C talk. B drops out of the calls.
|
