oint (user A) "invites" another SIP endpoint (user B) to join in a call. During this process, user A formulates an INVITE message requesting that user B joins a particular conference or establishes a two-party conversation. This INVITE request may be forwarded by proxies, and it eventually arrives to the called endpoint (user B), whichcan potentially accept the invitation. If user B wants to join the call, it sends a confirmatory response (SIP 2xx). Otherwise, it sends a failure response (SIP 4xx), or a 3xx, 5xx, or 6xx SIP response, depending on the reason of the rejection. Before sending a final response, the called endpoint can also send provisional responses that have a status code of type 1xx to advise the calling party of progress in contacting the called user. The INVITE client transaction for an originating endpoint starts with the INVITE request sent by the endpoint and terminates with an ACK sent by the endpoint at the reception of a 2xx-6xx response. 8.4.2 Set Up of the Test Environment In order to test a SIP-originating endpoint, the first step is to replicate a VoIP production network environment in a test laboratory. Technological advances have made it possible to use network emulators, traffic generators, and ana- lyzers to recreate realistic conditions for testing a VoIP device. However, to perform a SIP signaling compliance test, when there are no specific network emulators' requirements, it is necessary to generate SIP signaling. It could be enough to build a SIP network installing different SIP proxy servers, such as the open source Asterisk and the SIP express router (SER). Each SIP server had to support a number of phones and be able to send calls to the other SIP servers. Basic call flow scenarios like registration, registration with authentication and SIP to SIP calls with and without authentication, and C 2009 by Taylor & Francis Group, LLC Compliance and Interoperability Testing of SIP Devices more complex situations like the use of supplementary services (call waiting, call forward, etc.