The location service can specify multiple SIP addresses for users if necessary. For example, you might need multiple SIP addresses if a recipient logs on at different locations (e.g., a telephone and a computer terminal). When the location service returns multiple SIP addresses, the proxy server relays the INVITE request to each identified UAS. Proxy servers try each SIP address either sequentially or in parallel until the call is successfully established, the callee declines to accept the call, or the callee can't be reached.
When a proxy server forwards a SIP request, it adds its name to the beginning of the list of forwarders in the SIP message header's Via field. This field lets SIP responses take the same return path as requests. During the return path, each proxy server removes its name from the Via field after it processes the SIP response.
The Redirect Server
One of SIP's fundamental functions is redirection. Redirection lets users temporarily change locations and still be contactable through the same SIP identity. For example, if user jerry@acme.com is out of the office and has registered his SIP identity at the hotel at which he's staying, a SIP message routed to jerry@acme.com might ultimately get routed to room1206@la.hyatt.com.
In such cases, having the proxy server relay the original SIP message to the new SIP address is inappropriate because the network traversal would likely be suboptimal. Instead, you should have a redirect server in Acme inform the caller that a different SIP address should be used to contact the intended recipient. The redirect server needs to have access to the location service for Acme users, as Figure 4 shows.
After the proxy server receives the initial INVITE request, the proxy server sends the request to the redirect server. After the redirect server finds out about the new temporary address from the location server, the redirect server returns a SIP/2.0 300 Moved Temporarily response. The Contact field contains the temporary address. The original caller then reissues its INVITE request, but this time to the temporary address. To complete the transaction, the caller issues an ACK request to the redirect server. (Figure 4 doesn't show this last step.)
Although redirect servers and proxy servers are separate components, the RTC Server implements the components on one server. A server that includes a combination of functions is called a SIP server. Configuration settings on the SIP server determine how SIP messages for various SIP recipients are processed (e.g., whether the messages go to a proxy server or to a redirect server).
The Registrar Server
Users can inform a proxy or redirect server about the addresses at which they can be contacted. When a user wants to change an address, the SIP client issues a REGISTER request. A registrar server accepts REGISTER requests from the SIP client and records the user's new information. Typically, the SIP server uses this information to populate the location service so that the location service can redirect subsequent requests to the correct address.
The SIP clients can contact a registrar server two ways. They can directly contact the registrar server by using address information that's configured into the client. Or they can indirectly contact the registrar server by using the multicast address sip.mcast.net (224.0.1.75) to broadcast a registration request to the all SIP servers group. SIP servers listen on this address and process SIP REGISTER requests accordingly.
Figure 5 contains a sample REGISTER request. The Request URI specifies the destination of the REGISTER request (i.e., the registrar server) and must contain only a host name or domain name—it can't contain a username. The To field identifies the user's SIP address to be registered. When the user is performing the registration, the addresses in the To and From fields usually match. In the case of a third-party registration (i.e., a third party is making a registration on another user's behalf), the From field contains the third party's SIP address.
Although not always required, the REGISTER request might include a Contact field. In the sample REGISTER request in Figure 5, notice that the Contact field's address differs from that in the To field. In such cases, a proxy or redirect server directs future requests for the user specified in the To field to the address specified in the Contact field.
The Expires field specifies the registration's lifetime in seconds. The sample REGISTER request expires in 12 hours. However, if the client doesn't specify a value for the registration lifetime, SIP servers typically register the client for 1 hour. Users can cancel a registration by reissuing a REGISTER request with an expiration time of 0 seconds.
In the same way that you can combine the proxy and redirect functions on one SIP server, you can add the registrar function to the same SIP server. The RTC Server implements the proxy, redirect, and registrar functions on one SIP server.
Core Concepts Covered
I've introduced you to the core concepts of SIP as specified in RFC 2543. You need to fully understand these concepts before you look at how real products implement SIP. In an upcoming article, I'll show you how Microsoft's SIP client (Windows Messenger) and Microsoft's SIP server (RTC Server) interact and work.
End of Article
Prev. page
1
2
[3]
next page -->
