CSeq: 1392 BYE

Content-Length: 0

The response echoes the CSeq of the original request: 1392 BYE. No ACK is sent since ACK is only sent in response to INVITE requests.

2.2 SIP Call with a Proxy Server

In the SIP message exchange of Figure 2.1, Tesla knew the IP address of Marconi and was able to send the INVITE directly to that address. This will not be the case in general—an IP address cannot be used like a telephone number. One reason is that IP addresses are often dynamically assigned due to the shortage of IPv4 addresses. For example, when a PC dials in to an Internet service provider (ISP) modem bank, an IP address is assigned using DHCP to the PC from a pool of available addresses allocated to the ISP. For the duration of the session, the IP address does not change, but it is different for each dial-in session. Even for an “always on” Internet connection such as a DSL line, a different IP address can be assigned after each reboot of the PC. Also, an IP address does not uniquely identify a user, but identifies a node on a particular physical IP network. You have one IP address at your office, another at home, and still another when you log on remotely while traveling. Ideally, there would be one address that would identify you wherever you are. In fact, there is an Internet protocol that does exactly that with e-mail. SMTP uses a host or system independent name (an e-mail address) that does not correspond to a particular IP address. It allows e-mail messages to reach you regardless of what your IP address is and where you are logged onto the Internet.

In addition, a request routed using only IP addresses will reach only one end point—only one device. Since communication is typically user-to-user instead of device-to-device, a more useful addressing scheme would allow a particular user to call another particular user, which would result in the request reaching the target user regardless of which device they are currently using, or if they have multiple devices.

SIP uses e-mail-like names for addresses. The addressing scheme is part of a family of Internet addresses known as URIs, as described in Section 1.4. SIP URIs can also handle telephone numbers, transport parameters, and a number of other items. A full description, including examples, can be found in Section 4.2. For now, the key point is that a SIP URI is a name that is resolved to an IP address by using a SIP proxy server and DNS lookups at the time of the call, as will be seen in the next example. Figure 2.2 shows an example of a more typical SIP call with a type of SIP server called a proxy server. In this example, the caller Schroedinger calls Heisenberg through a SIP proxy server. A SIP proxy operates in a similar way to a proxy in HTTP and other Internet protocols. A SIP proxy

Figure 2.2 SIP call example with a proxy server.

does not set up or terminate sessions, but sits in the middle of a SIP message exchange, receiving messages and forwarding them. This example shows one proxy, but there can be multiple proxies in a signaling path.

SIP has two broad categories of URIs: ones that correspond to a user, and ones that correspond to a single device or end point. The user URI is known as an address of record (AOR), and a request sent to an address of record will require database lookups and service and feature operations, which can result in the request being sent to one or more end devices. A device URI is known as a contact, and typically does not require database lookups. An address of record URI is usually used in To and From header fields, as this is the general way to reach a person and is suitable for storing in address books and in returning missed calls. A device URI is usually used in a Contact header field and is associated with a particular user for a shorter period of time. The method of relating (or binding) a contact URI with an address of record URI will be discussed in Section 2.3.

Because Schroedinger does not know exactly where Heisenberg is currently logged on and what device he is currently using, a SIP proxy server is used to route the INVITE. First, a DNS lookup of Heisenberg’s SIP URI domain name (munich.de) is performed (see Section 2.6 for the details), which returns the IP address of the proxy server proxy.munich.de, which handles that domain. The INVITE is then sent to that IP address:

INVITE sip:werner.heisenberg@munich.de SIP/2.0

Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a Max-Forwards: 70

To: Heisenberg <sip:werner.heisenberg@munich.de>

From: E. Schroedinger <sip:schroed5244@wave.org>;tag=42

Call-ID: 4827311-391-32934

CSeq: 1 INVITE

Subject: Where are you exactly?

Contact: <sip:schroed5244@pc33.wave.org>

Content-Type: application/sdp

Content-Length: 159

v=0

o=schroed5244 2890844526 2890844526 IN IP4 100.101.102.103 s=Phone Call

t=0 0

c=IN IP4 100.101.102.103 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000

The proxy looks up the SIP URI in the Request-URI (sip:werner. heisenberg@munich.de) in its database and locates Heisenberg. This completes the two-step process of:

1.DNS lookup by user agent to locate the IP address of the proxy. Database lookup is performed by the proxy to locate the IP address.

2.The INVITE is then forwarded to Heisenberg’s IP address with the addition of a second Via header field stamped with the address of the proxy.

INVITE sip:werner.heisenberg@200.201.202.203

Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK83842.1 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a Max-Forwards: 69

To: Heisenberg <sip:werner.heisenberg@munich.de>

From: E. Schroedinger <sip:schroed5244@wave.org>;tag=42 Call-ID: 4827311-391-32934

CSeq: 1 INVITE

Contact: <sip:schroed5244@pc33.wave.org> Content-Type: application/sdp Content-Length: 159

v=0

o=schroed5244 2890844526 2890844526 IN IP4 100.101.102.103 s=Phone Call

c=IN IP4 100.101.102.103 t=0 0

m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

From the presence of two Via header fields, Heisenberg knows that the INVITE has been routed through a proxy server. Having received the INVITE, a 180 Ringing response is sent by Heisenberg to the proxy:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK83842.1 ;received=100.101.102.105

Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a

To: Heisenberg <sip:werner.heisenberg@munich.de>;tag=314159

From: E. Schroedinger <sip:schroed5244@wave.org>;tag=42 Call-ID: 4827311-391-32934

CSeq: 1 INVITE

Contact: <sip:werner.heisenberg@200.201.202.203> Content-Length: 0

Again, this response contains the Via header fields, and the To, From, Call-ID, and CSeq header fields from the INVITE request. The response is then sent to the address in the first Via header field, proxy.munich.de to the port number listed in the Via header field: 5060, in this case. Notice that the To header field now has a tag added to it to identify this particular dialog. Only the first Via header field contains a received parameter, since the second Via header already contains the literal IP address in the URI. The Contact header field contains the device URI of Heisenberg.

The proxy receives the response, checks that the first Via header field has its own address (proxy.munich.de), uses the transaction identifier in the Via header to locate the transaction, removes that Via header field, then forwards the response to the address in the next Via header field: IP address 100.101.102.103, port 5060. The resulting response sent by the proxy to Schroedinger is:

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a

To: Heisenberg <sip:werner.heisenberg@munich.de>;tag=314159 From: E. Schroedinger <sip:schroed5244@wave.org>;tag=42 Call-ID: 4827311-391-32934

CSeq: 1 INVITE

Contact: <sip:werner.heisenberg@200.201.202.203> Content-Length: 0

The use of Via header fields in routing and forwarding SIP messages reduces complexity in message forwarding. The request required a database lookup by the proxy to be routed. The response requires no lookup because the routing is imbedded in the message in the Via header fields. This ensures that responses route back through the same set of proxies as the request. The call is accepted by Heisenberg, who sends a 200 OK response:

SIP/2.0 200 OK

Via: SIP/2.0/UDP proxy.munich.de:5060;branch=z9hG4bK83842.1 ;received=100.101.102.105

Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a

To: Heisenberg <sip:werner.heisenberg@munich.de>;tag=314159 From: E. Schroedinger <sip:schroed5244@wave.org>;tag=42 Call-ID: 4827311-391-32934

CSeq: 1 INVITE

Contact: <sip:werner.heisenberg@200.201.202.203> Content-Type: application/sdp

Content-Length: 159

v=0

o=heisenberg 2890844526 2890844526 IN IP4 200.201.202.203 s=Phone Call

c=IN IP4 200.201.202.203 t=0 0

m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

The proxy forwards the 200 OK message to Schroedinger after removing the first Via header field:

SIP/2.0 200 OK

Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a

To: Heisenberg <sip:werner.heisenberg@munich.de>;tag=314159 From: E. Schroedinger <sip:schroed5244@wave.org>;tag=42 Call-ID: 4827311-391-32934

CSeq: 1 INVITE

Contact: <sip:werner.heisenberg@200.201.202.203> Content-Type: application/sdp

Content-Length: 159

v=0

o=heisenberg 2890844526 2890844526 IN IP4 200.201.202.203 s=phone call

c=IN IP4 200.201.202.203 t=0 0

m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000

The presence of the Contact header field with the SIP URI address of Heisenberg in the 200 OK allows Schroedinger to send the ACK directly to Heisenberg, bypassing the proxy. (Note that the Request-URI is set to Heisenberg’s Contact URI and not the URI in the To header field.) This request, and all future requests, continue to use the tag in the To header field:

ACK sip:werner.heisenberg@200.201.202.203

Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKka42 Max-Forwards: 70

To: Heisenberg <sip:werner.heisenberg@munich.de>;tag=314159 From: E. Schroedinger <sip:schroed5244@wave.org>;tag=42 Call-ID: 4827311-391-32934

CSeq: 1 ACK Content-Length: 0

This shows that the proxy server is not really “in the call.” It facilitates the two end points locating and contacting each other, but it can drop out of the signaling path as soon as it no longer adds any value to the exchange. This role of helping the two user agents locate each other is sometimes called rendezvous and is a key function of the SIP protocol. A proxy server can force further messaging to route through it by inserting a Record-Route header field, which is described in Section 6.119. In addition, it is possible to have a proxy server that does not retain any knowledge of the fact that there is a session established between Schroedinger and Heisenberg (referred to as call state information). This