Building upon the information provided already in this chapter, a number of examples are provided to demonstrate how SIP messages might appear
in various situations. We do not explain every possible option in these exam-ples, just some of the most common occurrences. For details of all options available, the reader is referred to RFC 3261.
Registration
The very first request issued by a client is likely to be REGISTER, because this is the request that provides the server with an address at which the user can be reached for SIP sessions. The REGISTER request is somewhat similar to the Registration Request between a terminal and a gatekeeper in H.323.
Figure 5-8 shows an example registration scenario. In this scenario, Collins has logged in to host station1.work.com. This causes a REGISTER request to be sent to the local registrar. The Via: header field contains the path taken by the request so far, which requires that the originating client insert its own address in this field. Note the format of the Via: header and in particular the fact that it specifies the transport being used. The default is the User Datagram Protocol (UDP). Note also that the Via: header
a
b
Registrar [email protected]
REGISTER sip:registrar.work.com SIP/2.0
Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123 Max-Forwards: 70
From: sip:[email protected]; tag=123456 To: sip:[email protected]
Call-ID: [email protected] CSeq: 1 REGISTER
Contact: sip:[email protected] Expires: 7200
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123 From: sip:[email protected],tag=123456
To: sip:[email protected] Call-ID: [email protected] CSeq: 1 REGISTER
Contact: sip:[email protected] Expires: 3600
Content-Length: 0
Figure 5-8 SIP registration
contains a branch parameter. The purpose of the branch parameter is dis-cussed later when we describe the operation of proxy servers.
The From: header field indicates the address of the individual who has initiated the registration. The To: header field indicates the “address of record” of the user being registered and is the address that the registrar will store for that user. In other words, this is the address at which the user wants to be contactable. The From: and To: fields will be identical if a user is registering himself. The two fields need not be identical, however, which means that one individual can perform a registration on behalf of another.
Note that the To: header field is not used to contain the address of the reg-istrar. That address is indicated in the first line of the request. Note that the From: field in our example contains a tag parameter, which is a pseudoran-dom value generated at the sender of the request and is used for identifica-tion purposes.
The Call-ID: header field is set by the originating client. All REGISTER requests for an individual client should use the same value of Call-ID. In order to avoid the possibility that different clients might choose the same Call-ID, the recommended syntax for the Call-ID is local-id@host, thereby making the Call-ID host specific.
In Figure 5-8, Collins has inserted a Contact: header field that indicates that future SIP messages should be routed to sip:collins@station1 .work.com. In other words, messages that are addressed to sip:Collins
@work.com should be forwarded to sip:[email protected].
The REGISTER request does not contain a message body, since the mes-sage is not used to describe a session of any kind. Therefore, the Content-Length: field is set to 0.
The response to the REGISTER request is positive, as indicted by the 200 (OK) in the response line. Note that the content of the Via: header field is copied from request to response. The content of the CSeq: (or command sequence) header field is also copied from request to response. The CSeq:
header field indicates the method used in the request and an integer num-ber. Consecutive requests for the same Call-ID must use contiguous increasing integer numbers. Although not as critical for REGISTER requests, the use of the CSeq is very important in other requests where dif-ferent requests can be issued for the same Call-ID, in which case the CSeq is used to avoid ambiguity. A response to any request must use the same value of CSeq as used in the request itself.
Through the use of the Expires: header, Collins has requested that the registration be effective for 2 hours. The registrar has chosen to override this aspect of the request and has limited the duration of the request to 1 hour. A registrar can change the length of time for which a given
registra-tion is effective, but if a registrar chooses to do so, it will normally set a lower registration interval than that requested. It will not set a higher interval. The Expires: header may be specified as a duration in seconds or as a specific data and time. If it is specified as a number of seconds, the maximum value is such that a registration may be active for up to approx-imately 136 years, which should be long enough for anyone. If a REGISTER request contains an Expires: header with a value that is too short (the reg-istration is to be active for too short a time), then the REGISTER request will be rejected with the status code 423 (Interval too brief). The response will include the Min-Expires: header field, which specifies the minimum registration interval that the registrar will accept.
Having registered as shown in Figure 5-8, Collins could subsequently register at another terminal. In such a case, both registrations would become active and subsequent invitations destined for Collins would be routed to both terminals. Of course, before registering at the second loca-tion, Collins could cancel the existing registration. This would be done by sending another REGISTER request for the same address of record and Contact and specifying a registration interval of 0. In this case, the REG-ISTER request would be identical to the first REGREG-ISTER request, with the exceptions that the CSeq integer is incremented and the Expires header field contains the value 0. If Collins wanted to cancel all existing registra-tions, then he would send a REGISTER message with the Expires header field set to 0 and the Contact header field populated with the wildcard char-acter *. The Expires header value of 0 indicates the cancellation of a Regis-tration and the Contact: header value of * indicates that the request is applicable to all contact information for Collins.
Invitation
The INVITE request is the most fundamental and important SIP request, as it is the request used to initiate a session (i.e., establish a call). Figure 5-9 shows a two-party call, where Collins initiates the session. The INVITE request is issued to [email protected], as can be seen from the Request-URI. The reason why the address is very specific to the host where the callee is located is because this example’s signaling flow does not tra-verse any proxies. Under normal circumstances, one might expect that the message would be addressed to sip:[email protected] and would be for-warded by a proxy to sip:[email protected]. Since our example does not include a proxy to forward the INVITE to the specific host, the INVITE itself is addressed to the specific host. In our example, the To:
header field has the same value as the Request-URI, because we are not traversing any proxies. (As described later in this chapter, the Request-URI can be changed when a message passes through a proxy.)
The From: header field indicates that the call is from [email protected].
As can be seen from Figure 5-9, SIP enables a display name to be used with
a
the SIP URI. Thus, the called user’s terminal could display the name Daniel when alerting the called user rather than displaying the SIP URI. The optional header field Subject: is used to indicate the nature of the call, and the type of media that Daniel wishes to use is described within the message body. The Content-Type: entity header field indicates that this particular message body is described according to SDP. The Content-Disposition header field indicates that the message body is to be treated as session information (as opposed to being displayed to the user, for example). In the example, the length of xxx is used just to indicate some nonzero value. The actual length will depend upon the content of the message body.
In Figure 5-9, the first response received is an indication that the user is being alerted. This is conveyed through the use of the 180 status code. Note that most of the header fields are copied from the request to the response, with the exception of the Content-Length and Content-Type, since this response does not contain a message body.
Note that the To: header field from the called party contains a tag meter, whereas the To: field in the original invite did not contain a tag para-meter. In fact, the tag parameter should be inserted only by the party that
“owns” the address in question. In combination, the content of the tag in the From: field, the tag in the To: field, and the Call-ID constitute a dialog ID, which identifies a peer-to-peer relationship between two user agents. Once both parties have inserted their tag values into the To: and From: fields according to which of the fields they “own,” then a dialog has been estab-lished. From that point onwards, each party should include the appropriate tag value in the To: and From: fields of every subsequent request and response until the dialog is terminated.
An important aspect of the dialog is the dialog state. If the response to an INVITE is a 1XX (provisional) response and it contains a tag parameter in the To: header field, then a session has not yet been established, but a dia-log has. Such a diadia-log is said to be in early state. If a 2XX response is received with a tag in the To: header field, then the dialog is confirmed.
Subsequently in our example, the called user answers and a 200 (OK) re-sponse is returned. This rere-sponse to an INVITE includes a number of header fields that have been copied from the original request. In addition, it contains a message body describing the media that the called party wants to use.
Finally, the caller sends an ACK to confirm receipt of the response. Note that the content of the CSeq: header field has changed to reflect the new request. Note also that, although most requests are answered with a 200 (OK) response if the request has been received and handled correctly, this is not the case for an ACK request. Once the ACK has been sent, the parties can exchange media.
Note that the requests shown in Figure 5-9 all include the Max-Forwards header field. This header should be included in all requests to ensure that a given request does not traverse too many proxies. The value of Max-Forwards is decremented at each proxy in the chain between requester and responder. Seventy is the recommended initial value for Max-Forwards. We discuss proxy servers later in this chapter.