n 100 Trying A (caller) B (callee) Typically does not contain a To tag 183 Session A (caller) B (callee) Information about the progress of Progress the session (call state) PRACK A (caller) B (callee) Acknowledges receipt of reliably transported provisional response (1xx) UPDATE A (caller) B (callee) Used to change media session parameters in early dialogs (before the final response to the initial INVITE) 180 Ringing A (caller) B (callee) QoS or security information or ring tone or animations from user agent server (UAS) to the user agent client (UAC) 200 OK A (caller) B (callee) Request has completed successfully A (caller) B (callee) Acknowledgment of final response to INVITE a BYE message, then the bidirectional connection will be released, and the call/session will be closed. The VOVIDA project provides a good example of Q-SIP/SDP implementation, and VoIP applications [13]. 15.3.2 Connection Establishment in the IP/MPLS Transit Network RSVP-TE is required as the UNI signaling to request QoS-guaranteed connec- tion establishment [11]. In our implementation of RSVP-TE, we expanded the objects for PATH message and RESV message to contain the traffic parame- ters (such as peak data rate, peak burst size, committed data rate, committed burst size, and excess burst size) and service class-type that implicitly specifies the QoS parameters (such as end-to-end delay, jitter boundary, packet error ratio, packet loss ratio, service availability, protection mode, and service relia- bility). Table 15.2 describes the RSVP-TE messages with their major contents. To establish a bidirectional QoS-guaranteed connection, a coordinator mod- ule of the caller provides the related traffic/QoS parameters to the RSVP client. These parameters are based on session parameters that have been nego- tiated during the previous Q-SIP/SDP INVITE procedure between the caller and the callee via SIP proxy servers. In the current implementation of the mul- timedia terminal, as shown in Figure 15.4, the MM (multimedia) service coor- dinator is man