[6] Sugano, H., et al., "Common Presence and Instant Messaging (CPIM) Presence Informa- tion Data Format," IETF Internet-Draft, Work in Progress, 2002. Mahy, R., "Requirements for Connection Reuse in the Session Initiation Protocol (SIP)," IETF Internet-Draft, Work in Progress, 2003 [8] Dierks, T., et al., "The TLS Protocol Version 1.0," RFC 2246, 1999. Stewart, R., et al., "Stream Control Transmission Protocol," RFC 2960, 1999. Rosenberg, J., H. Schulzrinne, and G. Camarillo, "The Stream Control Transmission Pro- tocol as a Transport for the Session Initiation Protocol," IETF Internet-Draft, Work in Progress, 2002. SIP Clients and Servers The client-server nature of SIP has been introduced in the example message flows of Chapter 2. In this chapter, the types of clients and servers in a SIP net- work will be introduced and defined. 3.1 SIP User Agents A SIP-enabled end-device is called a SIP user agent [1]. One purpose of SIP is to enable sessions to be established between user agents. As the name implies, a user agent takes direction or input from a user and acts as an agent on their behalf to set up and tear down media sessions with other user agents. In most cases, the user will be a human, but the user could be another protocol, as in the case of a gateway (described in the next section). A user agent must be capable of establishing a media session with another user agent. A UA must maintain state on calls that it initiates or participates in. A minimum call state set includes the local and remote tags, Call-ID, local and remote CSeq header fields, along with the route set and any state informa- tion necessary for the media. This information is used to store the dialog information and for reliability. The remote CSeq storage is necessary to distin- guish between a re-INVITE and a retransmission. A re-INVITE is used to change the session parameters of an existing or pending call. It uses the same Call-ID, but the CSeq is incremented because it is a new request. A retransmitted INVITE will contain the same Call