Release notes 1.20 ...............................................................................................................................................................................

1
Starting the tool................................................................................................................................................................................... 1
Initial screen ....................................................................................................................................................................................... 2
Scenario building screen ...................................................................................................................................................................... 3
SIP messages ...................................................................................................................................................................................... 4
Condition ........................................................................................................................................................................................... 5
Commands and playing RTP ................................................................................................................................................................ 6
Variables ............................................................................................................................................................................................ 7
Inserting values in scenario .................................................................................................................................................................. 9
Call generation.................................................................................................................................................................................. 10
Scenario progress screen .................................................................................................................................................................... 11
Menu options .................................................................................................................................................................................... 11
Keywords ......................................................................................................................................................................................... 12
Version checker ................................................................................................................................................................................ 13

This is an updated tutorial page to reflect changes made in version 1.20. New users read everything. Old users
just focus on highlighted parts.

Release notes 1.20

Candidates for the next release:
- All screens will be made with MIG layout
- Use XML for scenario files

Rel 1.20
New Features:
- Multipart SDP bodies (used for BLA/BLF - Broadsoft style, multiple SDP bodies,..)
- Added new Menu item "Tools"
- Under Tools there is utility that can be used to calculate SDP body
- Under Options there is a new Remote RTP dialog. It can be used to unconditionally send RTP to a given RTP
address:port. As part of the dialog there is a parameter called "Group RTP Packets". Its default value is
"1", but one slower/older machines where RTP sounds choppy try setting this value to 2, 3, 4.
- '«' sign is added on Scenario Entry Text screen to mark the end of the line. This is actually replaced wity
'\r\n' just about before sending it on the wire.
- Starting to use MIG layout. Hoepfully next version fixes possible screen display issues noticed on Linux
version. Linux users, please report weird looking screens.
- Added continuous RTP flag. It enabled it will play over and over the same RTP pcap file. Well, technically the
RTP is played as long as a pause command demands. If you play an out-of-band DTMF digit you want to turn
off this flag, cause most likely you do not want the digit to be played multiple times.

Starting the tool

• First make sure the latest JRE (Java Runtime Environment) is installed on a PC. Get JRE from here.
• Download 'SIP Inspector' and double click on 'SIPInspector.jar'. Program should start automatically.
• Alternatively, use platform independent way to start the tool:

C:\> java -jar SIPInspector.jar

NOTE: If user plans to work with RTP, one more package needs to be installed (JPcap).

1
Initial screen
Initial screen offers basic account settings, option to pick local network interface, transport is UDP (versions
1.00+ do not support TCP) and remote server.
1st step: Account - under number you are
supposed to enter a caller ID. Default
number is 1000, but this can be changed
as needed. A default client scenario will
register this number and will be used for
caller ID in an outgoing call. Provide
authentication parameters such username
and password. Change an RTP port if
needed. See below for more info about
authentication and RTP port.

2nd step: Local Info - Upon start, SIP

Inspector will detect all NIC cards on the
computer and will list them as available
local IP addresses. User must select at
least one IP address. Majority of users
have a single NIC card so do not be
surprised if you do not see what depicted
on the Figure 1 below. First discovered NIC
card will be selected by default. Most times
a SIP signaling port is 5060 and transport
is UDP. These can be changed as needed.

3rd step: Remote Server – Skip this step

if the tool is supposed to work in a server
mode. If it has to work as a client, the
Remote IP address and Remote Server
Ports have to be configured. This is where
SIP messages will be sent to. Failure to do
so will force SIP Inspector to work in a
'server mode'. If in a 'server mode' the
utility rejects to make an outgoing call.
Keep that in mind! Beginners can click at
this point 'Next' button. It takes you to
another screen.
Figure 1
4th step - It is time to advance to another
screen. Just click on 'Next' button.

• Authentication parameters are required if remote server challenges client's the requests. Default
client scenario takes into account configured authentication parameters and uses them for registration
purposes. If a server challenges requests, the following line is expected to be added in an outgoing
request:

Proxy-Authorization: [authentication username=dead; password=beef;]

• This automatically generates a 'Proxy-Authorization' header value using 'dead' for a username and
'beef' for a password to calculate an authentication response. Starting from version 0.9 users must
specify a header name. In this case it is 'Proxy-Authorization' but can be anything user needs.
NOTE: Keep in mind that sometimes authentication fails due to a wrong SIP header name is used. If Proxy-
Authorization is not working try using ‘Proxy-Authenticate’

2
Scenario building screen

Scenario building screen has 3 sections:

1. Scenario tree - this part of GUI provides
an overview of messages and instructions that
make a scenario. They are referred as scenario
entries. One or more entries can be selected.
If selected, entries' content is displayed in
'Scenario entry text' box. Entries are added
and removed using '<<Add' and 'Del>>'
buttons, respectively. All entries can be
selected with CTRL-A. Selecting an entry and
using up and down arrow buttons can always
reorder entries in a tree.

2. Scenario creation tools - as name

indicates, is used to build a custom scenario. A
SIP tab is responsible for SIP signaling
messages. A condition tab is used to create
conditional and unconditional branching. A
command tab allows addition of a pause or a
command to play a pcap file. A variable tab is
used create custom variables. The content of
variables is usually extracted from a received
message using star matching algorithm. All of
these tabs are explained into more details
below. Direction can be IN or OUT. IN means
to be received by the tool, OUT means the
message will be sent out.

3. SIP message text area - displays a

textual representation of a selected scenario
entry. In this area users can manually delete,
add or modify scenario entries as needed. One
thing to keep in mind is to keep a mouse
within the Scenario entry text area. Exiting the
section forces the utility to update entries in
Figure 2 the memory. SIP Inspector uses number of
key words like [local_ip], [local_port],...
These keywords are replaced with real values just before the message is sent out. Using keywords in a
scenario means scenarios are highly portable. It is always better to go with generic scenarios for portability
reasons.

Since version 1.00 introduces simultaneous calls, few new entry fields are added when the tool works in a
client mode. 'Calls/sec' controls the speed of calls generated, 'Max Concurrent' fields limits a maximum
concurrent calls (0 means infinite) and 'Total calls' controls when call generation stops (0 means infinite).

It is worth mentioning key-word [len]. It is used in Content-Length header and tells the tool to calculate SDP
message body and replace [len] with calculated number of bytes. This way user can easy change SDP bodies
without going through a hassle of manually calculating the length.

INVITE sip:155@[remote_ip]:[remote_port] SIP/2.0

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

3
 From: <sip:1000@[local_ip]:[local_port]>;tag=24417923471779367133
To: <sip:155@[remote_ip]:[remote_port]>
Call-ID: [call_number]@[local_ip]
CSeq: [cseq+1] INVITE
Max-Forwards: 70
Contact: <sip:1000@[local_ip]:[local_port];transport=[transport]>
User-Agent: SIPInspector_v_[ver]
Content-Type: application/sdp
Content-Length: [len] <--- See how [len] is used instead of exact number of bytes

v=0
o=111 843670094 843670094 IN IP4 [local_ip]
s=-
c=IN IP4 [local_ip]
t=0 0
a=sendrecv
m=audio [media_port] RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

At any point it is possible to go back to 'Initial screen' or click 'Run' to start executing the scenario.
Sometimes, custom scenarios become a mess. To get back default scenario, delete all messages go back to
'Initial screen' and then click on 'Next'.

SIP messages
Each SIP message has a direction and can be deemed as optional. If an incoming message is optional, scenario
control logic is allowed to skip to the next SIP message and evaluate if expected message is received. An
optional outgoing message is sent out ONLY if previously received message was optional. This is a new concept
and was introduced in version 1.00. The purpose is to handle unexpected and out-of-dialog messages
incoming messages. Typical examples are REGISTER or OPTIONS messages. The best way to handle such
messages is to put them at the beginning of the scenario. Take a look at the following cases:

<--- REGISTER* <--- NOTIFY*

---> 200* ---> 200*
<--- OPTIONS* ---> REGISTER
---> 200* <--- 407*
---> INVITE ---> REGISTER*
<--- 100* <--- 200
<--- 180*
<--- 200
---> ACK
---- Play pcap=test.pcap
<--- BYE
---> 200

Marked in green is what really is wanted. Extra messages that MAY come are marked in red. Most of times
they just need to be responded with 200 OK.

Scenario on the left instructs the tool to establish a call, send an RTP and wait for the other side to terminate a
call. At any point during this call an unexpected REGISTER and/or OPTIONS requests may come in. To stop
retransmissions, the tool will respond to both requests with 200 OK and the call scenario will not be
interrupted/affected.

4
 Scenario on the right is typical
and useful when registering with
a server. The server may respond
with 100 and/or 407 before it
sends a 200 OK. Client must be
ready to calculate authorization
response and may be getting
some 'unexpected' messages, like
NOTIFY for MWI (Message
Waiting Indication).

If an incoming message is
mandatory, scenario will not
Figure 3
advance until an expected
message is received. Requests
and Responses offer set of standard SIP messages. They can be selected from a drop down list. But, users and
not limited to an offered selection. A new message can always be typed in and then added to a scenario.

Make sure not to forget to check 'Optional' box if applicable.

Buttons "<<Add" or "Del>>" are used to add new entry or to remove existing entries.

Condition
Together with Variables it is the most difficult part to understand so I will spend extra words to make sure the
concept is described the best I can. Sometimes it is not known how exactly scenario will evolve. For example,
let's assume the tool works as a client and registers with the server. At times REGISTER requests may be
accepted, but at times they may be challenged. Conditions help us to create a scenario that will work in both
cases. Similarly, If the tool works as a server it is not guaranteed the client will not try to occasionally register
before it makes a call. To better handle cases like these, conditional and unconditional branching are
implemented.

There are 3 different subcategories: label, goto and if statements.

Client scenario (taken from a scenario tree) may look like below. It registers with a server and provide
authentication response if asked. Then, it makes a call.

---> REGISTER // send REGISTER request out

<--- 100* // server may respond with 100, but it is optional
<--- 407* // server may respond with 407, but it is optional
---- set resp=("startline","SIP/2.0 * ") // inspect startline of response,store return code
// in variable 'resp'
---- if (resp == 200) goto call // if response was 200, jump to label 'call'
---> REGISTER // otherwise, send REGISTER with an
// authentication response
<--- 200 // expects 200 OK
call: // label named 'call'
---> INVITE // send an INVITE out and proceed with a call
<--- 100*
<--- 180
<--- 200
---> ACK

5
---- Play pcap=test.pcap
---- Pause[ms]=15000 // Pause is required and tells the tool how long
---> BYE // to keep playing an RTP
<--- 200 OK

Label - if a label button is selected, it is possible to enter any text for a label name. It represents a place of
interest in a scenario. Usually used in conjunction with 'goto' and 'if' condition entries.

Goto - When a goto button is selected, the tool automatically provides a list of available labels. Pick one and
and create an entry. Make sure label where to jump is already created.

if condition - if a button is selected, tool automatically enables fields for its creation. First field is a drop down
list of variables available. More
about variables is given later in
this manual. Second field is a
drop down list of relational
operators. Third field is a value
to be compared with the
variable. The fourth field is a
label where to jump to if
condition is satisfied.

This should give you an idea

how things work. If you would
like to explore more about
conditions, please look at few
scenario examples provided with
Figure 4 a tool. After experimenting with
them for a while, I am sure you
will figure out all the missing parts ;-)

Commands and playing RTP

Currently, only 2 commands are available: pause and
play_pcap. They are accessible through 'Command' tab.

• Pause must have a numeric value that represents

duration in ms.

• Play_pcap command plays RTP packets from a saved

cap file. Usually, pcap files are saved with Wireshark.
The tool itself will derive info where to send RTP by
inspecting an SDP body of a SIP message. The tool
can act as a media/application server and handle calls
with RTP streams from many clients at the same time.
Once all RTP packets are played from a pcap file it will Figure 5
start from the beginning, unless otherwise told. To
play RTP packets, users must have JPcap installed on their machines.

Do not be surprised if following scenario does not This is a proper way to create a scenario for the

6
produce any audio on the other side. Such scenario client. In this scenario pcap file is played for 15
will end very quickly cause as soon as the seconds. After that call is terminated and RTP is
audio is started BYE is sent out which terminates the stopped.
call and stops RTP.

---> INVITE ---> INVITE

<--- 100* <--- 100*
<--- 180 <--- 180
<--- 200 <--- 200
---> ACK ---> ACK
---- Play pcap=test.pcap ---- Play pcap=test.pcap
---> BYE ---- Pause[ms]=15000 // duration required
<--- 200 ---> BYE
<--- 200

To fix the things a pause command is needed

immediately after command to play pcap file.
Duration of the pause determines how long and RTP
will play.

NOTE: On Figure5 there is a checkbox called ‘Cont’. The checkbox tells the tool to keep playing the same pcap
file over and over, until pause expires. Lets say you have a pcap file worth 30 seconds of RTP but you would
like to play the same file twice in a row. In that case you would need check this box and make sure it the
pause value is set to 60000[ms] = 60 seconds.

Variables
The purpose of a variable is to store a value retrieved from a received message. For example, in SIP, a fully
established dialog requires client to remember To tag parameter (toTag). While, initial roll-out of SIP Inspector
for that purpose used keyword [peer_tag_param], this is not enough. For example, users require remembering
custom parameters and parts of received message. Having hard-coded keywords embedded into SIP Inspector
was not an option. A more generic and flexible way to extract information was required. Variables have to be
used when working with PRACKs, SUBSCRIBEs,... See PRACK client/server scenarios that come with SIP
Inspector.

Variables are not global, but tied to a call-dialog instance. Each concurrent call will have its own value for
"toTag"

Variables tab offers 3 entries.

Variable name - user picks a variable name. In my case I

chose 'toTag'. But can be any string. Later in a scenario if the
value stored into variable has to be used user puts keyword
[$toTag]. Please pay attention to '$' part. It tells SIP Inspector
it has to deal with a variable.

NOTE: '$' is not required when creating a variable scenario

entry. Do not use '$’ before variable name under Variable
name, but only later when referencing a variable through a
keyword.

Header - If user knows searched text is to be found under

Figure 6 specific header, and then it needs to be provided here. This

7
field can be left empty. If empty, it tells the tool to start searching from the beginning of the message until the
first match occurs. In my example I put "To". Starting from version 0.9, it is possible to use 'startline' instead
of a header name. It is required to remember response code or a request method.

Expression - Instead of using regular expression, I opted for wild-card expressions. In essence, users provide
pattern, and whatever is matched with '*' is stored into a variable. It is much simpler than regexp.

The purpose of a variable is to store a value retrieved from a received message. For example, in SIP, a fully
established dialog requires client to remember To tag paramter (toTag). While, initial roll-out of SIP Inspector
for that purpose used keyword [peer_tag_param], this is not enough. For example, users require to remember
custom parameters and parts of received message. Having hard-coded keywords embedded into SIP Inspector
was not an option. A more generic and flexible way to extract information was required. Variables have to be
used when working with PRACKs, SUBSCRIBEs,... See PRACK client/server scenarios that come with SIP
Inspector.

Variables are not global, but tied to a call-dialog instance. Each concurrent call will have its own value for
"toTag".

Logic for wild-cared expression pattern matching is as follows:

• Find pattern on the left from '*', find pattern on the right from '*', return whatever is in between found
patterns
• If no pattern on the left, find pattern on the right from '*', return whatever is before found pattern
• If no pattern on the right from '*', return whatever is after found pattern.

My example (shown on the picture above) stores a To tag parameter value into variable 'toTag'. The most
important thing while working with variables is to master a wild-card search. Let me expand a bit on it and
illustrate the principle with few examples. Let’s say user needs to extract pieces of the following Contact
header value and store it in different variables.

Contact: Zarko Coklin user <sip:112@192.168.1.201:5060;transport=udp;rinstance=124_test_32>

Variable Header Expression Semantics Commentary

Header name
does not have to
var0="Zarko Coklin user be followed by
var0 Contact "*" <sip:112@192.168.1.201:5060;transpor ":" Wild-card
t=udp;rinstance=124_test_32>" expression
returns the whole
header value.
Putting a '*' at
the end of
var1="<sip:112@192.168.1.201:5060;tr
var1 Contact: "Zarko Coklin user *" expression picks
ansport=udp;rinstance=124_test_32>"
up the rest of the
string.

Putting a '*' at
the beginning
picks up the first
part of the
var2 "Contact" "* Coklin" var2="Zarko"
matched pattern.
Note the Header
field is enclosed
with quotes.

var3 "Contact:" " * " var3="Coklin" Note that header

8
 value starts with
"Zarko" and not
with " Zarko",
therefore wild-
card expression
returns "Coklin".
Convenient way
var4 Contact: "<sip:*@" var4="112" to get a
username.
In this case not
header is
provided.
var5 - "=500" var5="500"
Variable var5 is
assigned value
"500".

Referencing particular header instance is possible starting from version 0.92. You may find it useful while with Record-Route
headers.

To store a value of the 2nd "Record-Route" header found in

the incoming SIP message, under the Header field provide
"Record-Route-2". Note, "-2" part! This logic and behavior is
applicable to any header and not only to "Record-Route". To
learn more about this, see scenarios directory. In particular
"Record_route_server.txt" and "Record_route_client.txt" files.
At the moment, SIP Inspector does not change destination IP
address according to what is found in a top-most route. This
will stay as is until I hear enough bitter comments from you,
or it affects me :-)

If you need more info how to use variables, please refer to

Figure 7
scenario "SUBSCRIBE_dialog_server.txt" available in scenario
directory. It has lots of variables. They are needed to properly implement subscriptions server.

Inserting values in scenario

To create different calls it is a necessity to use different values in each call. That is achieved by loading values
from a file and using variables [fieldN], where N is non-negative integer number greater or equal to 0. Let say
a simple registration scenario has to register 3 VoIP numbers. SIP messages are created using [fieldN]
macros.

Values field has to be created. It will have 3 lines for each VoIP number. And each line can be dissected into
values separated with ';'.

Let’s take an example where Values files has the content as follows:

Error! Reference source not found.

Even though 3 different users are registered the scenario has only 2 messages: an outgoing REGISTER request
and an incoming 200 OK response. The trick is to repeat scenario execution 3 times, use [fieldN] key-words
which will be replaced with values inserted from the file.

9
 // Lines can be commented using # or //
// Also, make sure values are separated with ;
1000;Zarko;Coklin
2000;John;Doe
3000;Fedor;Emelianenko

Scenario tree SIP Messages

---> REGISTER ---------->
<--- 200 REGISTER sip:[field0]@[remote_ip]:[remote_port];transport=udp SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: "[field1] [field2]"<sip:[field0]@[remote_ip]:[remote_port]>;tag=244179
To: "[field1] [field2]"<sip:[field0]@[remote_ip]:[remote_port]>
Call-ID: [call_number]@[local_ip]
CSeq: [cseq+1] REGISTER
Max-Forwards: 70
Contact: <sip:[field0]@[local_ip]:[local_port];transport=[transport]>
User-Agent: SIPInspector_v_1.00
Content-Length: 0

<----------
200 OK

The end result will be 3 REGISTER messages. All 3 will be different. All occurrences of [fieldN] will be
substituted and here is how:

• 1st REGISTER: [field0] = 1000, [field1] = Zarko, [Field2] = Coklin

• 2nd REGISTER: [field0] = 2000, [field1] = John, [Field2] = Doe
• 3rd REGISTER: [field0] = 3000, [field1] = Fedor, [Field2] = Emelianenko

Pretty useful, huh? Just do not forget to put [fieldN] where required in a SIP message, and do not forget to load Values File
prior running the script.

Call generation
If the tool works as a client it is possible to
specify speed at which calls are generated
[calls per second], maximum number of
concurrent calls and total number of calls
generated.

If Max Concurrent calls field is set to 0, it

means unlimited concurrent calls.

Figure 8 If Total calls field is set to 0, it means

unlimited.

Call generation logic is summarized as follows:

a) New calls are generate at calls/sec speed, until
b) Maximum number concurrent calls allowed is reached. At that point wait for a number of concurrent calls to drop
c) Continue call generation until total number of calls is reached

10
Scenario progress screen

Scenario progress screen provides information

how well scenario progresses. Outgoing
messages are prefixed with '--->' and incoming
messages are prefixed with '<---' patterns.

If an unexpected message is received it will not

interrupt scenario execution. Rather, its arrival
will be logged under 'Unexp' column.

At any point it is possible to stop scenario

execution, start it from the beginning or close
scenario progress screen. Closing the screen
will interrupt scenario execution.

Figure 9

Menu options
There are few menu options available to a user.

• At the very beginning on the 'Initial screen' it is possible to load a

saved scenario. After working on a set of different scenarios, users will
find it is useful to save and load scenarios. The path to this command
is File/Load Scenario
• Scenario can be saved to a file at any time from the 'Scenario Building
Screen'. The path to this command is File/Save Scenario.
• Edit/File&Replace (Figure 8) brings a dialog where strings can be
replaced. It is a convenient way of changing several messages at once.
This is useful for example if user wants to change numbers in a default
scenario. All that has to be done is:
o a) select all the messages, Figure 10
o b) bring 'Find&Replace' dialog and
o c) replace the strings.
• Enabling Options/SIP Logging starts logging SIP messages to a log file. Log files are located in the
same directory where executable jar is. Late, logs can be loaded as scenarios.
• Options/Remote RTP – offers an ability to specify remote client’s IP address and port. It can be used
to unconditionally send unicast or multicast RTP to designated destination. There is one parameter on
this dialog called ‘Group RTP packets’. This value is used to tell the tool how to schedule inter packet
intervals. Usually, RTP packets are sent every 20ms. On older machines running Windows OS it is fairly
optimistic to have thread-seep accurancy of 20 ms. Setting this parameter to 2 will mean send 2 RTP
packets immediately and another two in 40 ms. Setting this parameter to 3 means send 3 RTP packets
at once and next thre in 60 ms, and so.on.
• Tools/SDP Calculator – this is a handly calculator to help you calculate SDP body. Do not pay too
much attention to ‘«’ symbol. It is just for your benefit to see where is the end of the line. Internally it
is replaced with “\r\n” and calculated as 2 characters.

11
Keywords
Replaced with "z9hG4bK" + callNumber + position the current entry has in scenario.
[branch]
Example value it may have: "z9hG4bK15"
Usually used to compose responses and will be replaced with header(s) matching given
name found and extracted from previous received message. Any SIP header name can be
[last_*:]
used instead of '*'. For example, key word "[last_Via:]" will be replaced with "Via" headers
and values found in previous received message.
Replaced with given header value as found in last received SIP message. For example,
[val_last_*:]
[val_last_RSeq:] is used in PRACK requests to get a RSeq value.
[call_number] Replaced with global call counter. Keeps incrementing with every new generated call.
Replaced with From tag if previous received message was request or with To tag if previous
[peer_tag_param]
received message was response.
[username] Replaced with username configured under Authentication tab.
[password] Replaced with password configured under Authentication tab

This is a complex key word and takes into consideration username and password. The
whole key word goes like this:
[authentication username=value1; password=value2;]
[authentication]
Replaced with Proxy-Authorization header with MD5 digest calculated taking value1 for a
username and value2 for a password. If previous message is different than 401 or 407
nothing happens.

[len] Replaced with number of bytes found in SDP

[service] Replaced with number value configured under Account tab
[local_ip] Replaced with local IP address
[local_port] Replaced with local signaling port
Replaced with remote server IP address or (if in server mode) with an IP address where the
[remote_ip]
last message came from
Replaced with remote server port or (if in server mode) with a port where the last message
[remote_port]
came from
[transport] Replaced with "UDP" or "TCP" depending what was selected for an IP connection type
Replaced with value configured under RTP tab. This is the port where RTP is received and
[media_port]
from which RTP is transmitted to the far end.
[cseq] Replaced with current cseq value for this call.
Replaced with current cseq incremented by N. cseq value is then set to incremented value
[cseq+N]
and therefore next call to [cseq] will have value increased by N.
[$var] Replaced with the value stored under variable 'var'. See 'Variables' for more info.
Replaced with the value stored under variable 'var'. The value is then increased by N. Next
[$var+N]
reference to '$var' returns a new (increased) value. See 'Variables' for more info.
[ver] Replaced with the SIP Inspector version.
Replaced with a value found in a values file. Values file can be loaded prior to running a
scenario (File/Load Values)A values file has rows and every row has list of values separated
with ';'. N denotes value index (index is 0-based). For example if the file has following
lines:
//[field0];[field1];[field2];
[fieldN]
zarko;coklin;1000
john;doe;2000
For the first generated call scenario keyword [field0] is replaced with 'zarko', [field1] with
'coklin' and [field2] with '1000'. For the second generate call scenario keyword [field0] is
replaced with 'john', [field1] with 'doe' and [field2] with '2000'.

12
Version checker

Occasionally, a new version of SIP Inspector will

become available. Do not be surprised if at start,
the similar pop-up screen appears. The tool has
intelligence to figure out there is a new version and
where to get it from. No browser is required to
download a new version. Just make sure to extract
a downloaded zip archive and to start a correct
version

Figure 10

13