64	SIP: Understanding the Session Initiation Protocol

same time. For contacts with different priorities, a proxy can do sequential forking, sending the request in the order specified by the q-values.

For full registration security, TLS must be used as HTTP digest does not provide the needed integrity protection. Otherwise, an attacker can modify the Contact URI in an authenticated REGISTER to point to another UA.

3.6 Uniform Resource Indicators

SIP uses a number of Uniform Resource Identifiers. Common URIs are shown in Table 3.2.

SIP URIs will be discussed in Section 4.2. SIPS will be covered in Chapter 14. Telephony URI is covered in Section 4.2.2. Presence and IM URIs are covered in Chapter 8, along with the XMPP URI. H.323 URIs are covered in Section 11.4. Web URIs are defined in [10].

SIP uses Uniform Resource Indicators or URIs for most addresses. URIs and URLs were introduced in Section 1.4. For SIP, the URI scheme is either sip for a normal SIP URI or sips for a Secure SIP URI. Secure SIP means that a SIP message sent using this URI will be protected using TLS across each hop. SIP URIs must contain either a host name or an IP address. They usually contain a user part, although they do not have to. For example, a URI for a proxy server typically will not have a user part. URIs also may contain parameters. SIP URI parameters are listed in Table 3.3. In this table, URI means any valid URI while URN means any valid URN.

The following is a list of some examples of SIP URIs.

sip:fred@flintstone.org sip:vilma@flintstone.org;transport=tcp sip:[e-mail] sip:[e-mail] sip:192.0.3.4:44352 sip:proxy34.sipstation.com

Table 3.2

Common URIs Used with SIP

URI Scheme	Use	Specification
sip	SIP	RFC 3261
sips	Secure SIP	RFC 3261
tel	Telephony	RFC 3966
pres	Presence	RFC 3861
im	Instant messaging	RFC 3861
xmpp	XMPP (Jabber)	RFC 4622
h323	H.323	RFC 3508
http	Web	RFC 2616

		SIP Clients and Servers		65
			Table 3.3
			SIP URI Parameters
	Parameter	Specification	Example	Common Usage
	cause	RFC 4458	cause=486	Voicemail
	comp	RFC 3486	comp=sigcomp	Sigcomp compression used
	content-type	RFC 4240	content-type=audio	Media server control
	delay	RFC 4240	delay=10	Media server control
	duration	RFC 4240	duration=60	Media server control
	gr	[14]	gr	Globally routable UA URI
	local	RFC 4240	local=en	Media server control
	lr	RFC 3261	lr	Loose route parameter used in
				Route and Record-Route
	maddr	RFC 3261	maddr=1.2.3.4	Multicast address
	method	RFC 3261	method=INVITE	Used to escape a method into
				a URI
	ob	[15]	ob	SIP outbound
	param[n]	RFC 4240	param1=”today”	Media server control [11]
	play	RFC 4240	play=URI	Media server control [11]
	repeat	RFC 4240	repeat=forever	Media server control [11]
	sigcomp-id	RFC 5049	sigcomp-id=URN	Sigcomp ID [12]
	target	RFC 4240	target=IRO	Media server control [11]
	target	RFC 4458	target=URI	Voicemail [13]
	ttl	RFC 3261	ttl=224	Time to live for a multicast
				address
	transport	RFC 3261	transport=tcp	Transport protocol
	user	RFC 3261	user=phone	Telephone digits in user part
	voicexml	RFC 4240	voicexml=URI	Media server control [11]

sip:r3.example.com;lr

sip:[phone];user=[e-mail]

SIP URIs can also be used to encoded telephone numbers. Sometimes, this includes the user=phone parameter.

3.7 Acknowledgment of Messages

Most SIP requests are end-to-end messages between user agents. Proxies between the two user agents simply forward the messages they receive and rely on the user agents to generate acknowledgments or responses.

There are some exceptions to this general rule. The CANCEL method (used to terminate pending calls or searches and discussed in detail in Section 4.1.5) is a hop-by-hop request. A proxy receiving a CANCEL immediately sends a 200 OK response back to the sender and generates a new CANCEL, which is then forwarded in the next hop to the same set of destinations as the original request. (The order

66 SIP: Understanding the Session Initiation Protocol

of sending the 200 OK and forwarding the CANCEL is not important.) This is shown in Figure 3.4.

Other exceptions to this rule include 3xx, 4xx, 5xx, and 6xx responses to an INVITE request. While an ACK to a 2xx response is generated by the end point, a 3xx, 4xx, 5xx, or 6xx response is acknowledged on a hop-by-hop basis. A proxy server receiving one of these responses immediately generates an ACK back to the sender and forwards the response to the next hop. This type of hop-by- hop acknowledgment is shown in Figure 4.2.

ACK messages are only sent to acknowledge responses to INVITE requests. For responses to all other request types, there is no acknowledgment. A lost response is detected by the UAS when the request is retransmitted.

3.8 Reliability

SIP has reliability mechanisms defined, which allow the use of unreliable transport layer protocols such as UDP. When SIP uses TCP, these mechanisms are not used, since it is assumed that TCP will retransmit the message if it is lost and inform the client if the server is unreachable.

For SIP transport using UDP, there is always the possibility of messages being lost or even received out of sequence, because UDP guarantees only that the datagram is error free. A UAS validates and parses a SIP request to make sure that the UAC has not errored by creating a request missing required header fields or other syntax violations. Reliability mechanisms in SIP include:

•Retransmission timers;

•Increasing command sequence CSeq numbers;

•Positive acknowledgments.

How SIP handles retransmissions depends on the method. One retransmission scheme is defined for INVITEs, known as INVITE transactions, and another is defined for all other methods, known as a non-INVITE transaction.

For non-INVITE transactions, a SIP timer, T1, is started by a UAC or a stateful proxy server when a new request is generated or sent. If no response to the request (as identified by a response containing the identical local tag, remote tag, Call-ID, and CSeq) is received when T1 expires, the request is resent. After a request is retransmitted, the next timer period is doubled until T2 is reached. If a provisional (informational class 1xx) response is received, the UAC or stateful proxy server immediately switches to timer T2. After that, the remaining retransmissions occur at T2 intervals. This capped exponential backoff process is continued until a 64*T1, after which the request is declared dead. A stateful proxy

SIP Clients and Servers

67

server that receives a retransmission of a request discards the retransmission and continues its retransmission schedule based on its own timers. Typically, it will resend the last provisional response. This retransmission scheme for non-INVITE is shown in Figure 3.6 for a REFER request.

For an INVITE transaction, the retransmission scheme is slightly different. INVITEs are retransmitted starting at T1, and then the timer is doubled after each retransmission. The INVITE is retransmitted until 64*T1 after which the request is declared dead. After a provisional (1xx) response is received, the INVITE is never retransmitted. This retransmission scheme is shown in Figure 3.7. A proxy may discard the transaction state after 3 minutes. A stateful proxy must store a forwarded request or generated response message for 32 seconds. Suggested default values for T1 and T2 are 500 ms and 4 seconds, respectively. Timer T1 is supposed to be an estimate of the roundtrip time (RTT) in the network. Longer values are allowed, but not shorter ones, because this will generate more message retransmissions. See Table 4 in RFC 3261 [1] for a summary of SIP timers.

Note that gaps in CSeq number do not always indicate a lost message. In the authentication examples, not every request (and hence CSeq) generated by

Figure 3.6 A SIP reliability example of a non-INVITE transaction.