IUT, it is sufficient to reproduce the steps described above, acting on the endpoint. In addition, it is necessary that a called endpoint is configured to act as specified by the test. This can be easily done by simulating the called endpoint using one of the tools described in Section 8.3.2. How to configure the tool is not described here, because it depends heavily on the tool that has been selected. As an example, if the IUT is a SIP phone, one should hook the phone off, compose a phone number that is configured in the network and wait for the dialing timeout (this will cause the INVITE to be sent). If it is running the test number 1, the called endpoint will not answer, causing timer A to expire. Then the IUT should send another INVITE message. At this point, the called endpoint will respond with two subsequent 1xx messages. Then, the called endpoint will send a message with a response code between 300 and 699, and the IUT should send an ACK. In the case described, in order to check the compliance of the IUT, one should check if it correctly sends the INVITE and ACK messages, and if it correctly closes the SIP transaction when timer D expires. The same procedure can be applied for all the other tests derived from the state machine. 8.4.4 Testing Using Standard Test Specifications Validating the SIP UA client that begins an invitation process means: (1) in the first instance, to verify the INVITE message features according to RFC 3261 specifications; (2) subsequently, to check that the IUT follows the state machine transition according to the response received and the current state, and generates an ACK response in conformity with the RFC 3261; (3) finally, in case of no answer, to confirm that the timer and message retransmission processes act as defined in the standard. ETSI test specifications deal in a complete treatment of these tests. The following subsections give some examples that clarify the way to validate the INVITE client transaction. 8.4.4.1 INVITE Features ETSI TS 102 027 lists the "valid behavi