SIP Call with Proxy Server

SIP Call with 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 when you travel. 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 on to 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. 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 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 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.

Figure 2.2: SIP call example with proxy server.

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 and can result 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 which device they are 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, 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:[e-mail] SIP/2.0
     Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKmp17a
     Max-Forwards: 70
     To: Heisenberg <sip:[e-mail]>
     From: E. Schroedinger <sip:[e-mail]>;tag=42
     Call-ID: 10@100.101.102.103
     CSeq: 1 INVITE
     Subject: Where are you exactly?
     Contact: <sip:[e-mail]>
     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:[e-mail]) in its database and locates Heisenberg. This completes the two-step process:

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 SIP/2.0
     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:[e-mail]>
     From: E. Schroedinger <sip:[e-mail]>;tag=42
     Call-ID: 10@100.101.102.103
     CSeq: 1 INVITE
     Contact: <sip:[e-mail]>
     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:[e-mail]>;tag=314159
     From: E. Schroedinger <sip:[e-mail]>;tag=42
     Call-ID: 10@100.101.102.103
     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, then 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:[e-mail]>;tag=314159
     From: E. Schroedinger <sip:[e-mail]>;tag=42
     Call-ID: 10@100.101.102.103
     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. Also, 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:[e-mail]>;tag=314159
     From: E. Schroedinger <sip:[e-mail]>;tag=42
     Call-ID: 10@100.101.102.103
     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:[e-mail]>;tag=314159
     From: E. Schroedinger <sip:[e-mail]>;tag=42
     Call-ID: 10@100.101.102.103
     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
     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 to 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 SIP/2.0
     Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bKka42
     Max-Forwards: 70
     To: Heisenberg <sip:[e-mail]>;tag=314159
     From: E. Schroedinger <sip:[e-mail]>;tag=42
     Call-ID: 10@100.101.102.103
     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. A proxy server can force further messaging to route through it by inserting a Record-Route header field, which is described in Section 6.2.12. 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 is discussed in Section 3.3.1. Note that the media is always end-to-end and not through the proxy.

In SIP the path of the signaling messages is totally independent of the path of the media. In telephony, this is described as the separation of control channel and bearer channel.

The media session is ended when Heisenberg sends a BYE message:

     BYE sip:[e-mail] SIP/2.0
     Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bK4332
     Max-Forwards: 70
     To: E. Schroedinger <sip:[e-mail]>;tag=42
     From: Heisenberg <sip:[e-mail]>;tag=314159
     Call-ID: 10@100.101.102.103
     CSeq: 2000 BYE
     Content-Length: 0

Note that Heisenberg's CSeq was initialized to 2000. Each SIP device maintains its own independent CSeq number space. This is explained in some detail in Section 6.1.5. The Request-URI is set to Schroedinger's Contact URI. Schroedinger confirms with a 200 OK response:

     SIP/2.0 200 OK
     Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bK4332
     To: E. Schroedinger <sip:[e-mail]>;tag=42
     From: Heisenberg <sip:[e-mail]>;tag=314159
     Call-ID: 10@100.101.102.103
     CSeq: 2000 BYE
     Content-Length: 0

Not discussed in the previous example is the question of how the database accessed by the proxy contained Heisenberg's current IP address. There are many ways this could be done using SIP or other protocols. The mechanism for accomplishing this using SIP is called registration and is discussed in the next section.