r in this chapter. The branch parameter is a transaction identifier. Responses relating to this request can be correlated because they will contain this same transaction identifier. The next header field shown is the Max-Forwards header field, which is initialized to some large integer and decremented by each SIP server, which receives and forwards the request, providing simple loop detection. The next header fields are the To and From header fields, which show the originator and destination of the SIP request. When a name label is used, as in this example, the SIP URI is enclosed in brackets and used for routing the request. The name label could be displayed during alerting, for example, but is not used by the protocol. The Call ID header field is an identifier used to keep track of a particu- lar SIP session. The originator of the request creates a locally unique string, then usually adds an "@" and its host name to make it globally unique. In addition to the Call-ID, each party in the session also contributes a random identifier, unique for each call. These identifiers, called tags, are included in the To and From header fields as the session is established. The initial INVITE shown contains a From tag but no To tag. The user agent that generates the initial INVITE to establish the session generates the unique Call and From tag. In the response to the INVITE, the user agent answering the request will generate the To tag. The combination of the local tag (contained in the From header field), remote tag (contained in the To header field), and the Call - ID uniquely identifies the established session, known as a "dialog." This dialog identifier is used by both SIP: Understanding the Session Initiation Protocol parties to identify this call because they could have multiple calls set up between them. Subsequent requests within the established session will use this dialog identifier, as will be shown in the following examples. The next header field shown is the CSeq, or command sequence. It con- tains a number, foll