The UAC
The UAC is an application that initiates a SIP request to a UAS. (A SIP message is either a request from a UAC to a UAS or a response from a UAS to a UAC.) The original SIP specification defines six possible types of requests (i.e., methods) that a UAC can issue: INVITE, ACK, OPTIONS, BYE, CANCEL, and REGISTER. (Extensions of SIP-related RFCs define additional methods, such as MESSAGE, INFO, and NOTIFY.) For example, the SIP request that Figure 1 shows uses the INVITE method and a Request Uniform Resource Identifier (URI) of sip:jerry@acme.com. The request ends with SIP's version number.
When the UAC initiates a SIP session, the UAC determines the protocol, port, and IP address of the UAS to which to send the request. In the absence of any locally configured proxy-server information (more about this topic later), the UAC uses information in the Request URI to determine how to route the SIP request to its endpoint. The Request URI always specifies a host but doesn't always specify the port and protocol. If the specified host is an explicit IP address, the UAC attempts to contact the UAS at the specified address. If the Request URI specifies a Fully Qualified Domain Name (FQDN), the UAC queries DNS services for resolution by using an ADDRESS, CNAME, or other resource record. (The OS implementation on which the UAC resides might provide alternative mechanisms for host-name resolution, such as local HOSTS files, WINS, or broadcasts, but RFC 2543 doesn't specify their use. Regardless, if the local OS resolves and returns a host name to the UAC, the UAC uses the resolved name in the subsequent SIP communication.)
If the Request URI specifies a port, the UAC attempts to contact the UAS at that port. If the Request URI doesn't specify a port, the UAC contacts UDP port 5060 by default. If the Request URI specifies a transport protocol (either TCP or UDP), the UAC uses that protocol. If the Request URI doesn't specify a transport protocol, the UAC attempts to use UDP; if that connection attempt fails, the UAC tries TCP.
If an INVITE request includes the port and protocol, it might look like
INVITE sip:jerry@3.141.59.26:5050;transport=TCP SIP/2.0
However, most applications use the shortened format (i.e., host name only), which looks like the first line in Figure 1.
The UAS
The UAS is an application that receives SIP requests from a UAC and returns responses to those requests. The UAS can be an application with which a user interacts, so upon receipt of a SIP request, some form of notification from the UAS to the user might take place.
Like HTTP status codes, SIP responses consist of a three-digit integer result code coupled with a textual phrase. The SIP result codes fall broadly into six categories: 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client error), 5xx (server error), and 6xx (global failure). Section 7 in RFC 2543 defines the result codes in their entirety.
Whatever the nature of the UAC's request and the UAS's resulting action, the UAS sends a response to the UAC. Sometimes the UAS issues more than one response to a request. For example, when the UAC issues an INVITE request to participate in a session, the UAS might issue three responses to the UAC's initial request. The SIP transaction is complete only when the UAS fully responds to the initial request. The UAC issues a final request, which uses the ACK method, to confirm that it has received the final response to its INVITE request. The only time the UAC uses the ACK request is in conjunction with the INVITE request.
Because SIP is a peer-to-peer protocol and a client/server protocol, a SIP endpoint must be able to initiate and respond to SIP session requests. Accordingly, such an endpoint must possess both UAS and UAC functionality. The user agent (UA) does just that—it has both UAC and UAS functionality. Another term commonly used for the UA is the SIP client.
The Proxy Server
Up to this point, the communication between the UAC and UAS has been effectively peer-to-peer, although strictly speaking it's client/server. However, proxy servers are commonly used in SIP implementations. The proxy server acts as an intermediary that can service requests or forward them to other UASs or UACs for servicing. In this approach, a user's UA (read client) routes all its SIP transactions through an explicit proxy server (read server). Figure 2 shows a typical intraorganizational configuration in which a user, when initiating a SIP session to another user within the same organization, has messages routed through a proxy server before those messages are relayed to the destination SIP client.
This intraorganizational architecture can extend to an interorganizational one. Figure 3 shows the interorganizational, or federated, architecture. Users in each organization have their UA configured to point to their respective proxy servers, and the proxy servers communicate with each other to relay messages.
Another common reason for using a proxy server is name mapping. For email services, users often have an address by which they're known externally and a private internal email address for internal mail routing. A similar concept is available with SIP. A proxy server can query a location service, such as a Lightweight Directory Access Protocol (LDAP) directory service, and map an external SIP identity to an internal SIP identity.
In addition to showing the federated architecture, Figure 3 shows the interactions between SIP components when name-mapping services are in effect. When the Acme proxy server receives the INVITE request, the server consults the location service to perform name mapping if necessary. In this case, the Acme proxy server submits jerry@acme.com and the location service returns the SIP address's internal form js@nyc.acme.com.
The implementation of a location service isn't in any way tied to the SIP specification. Nor does SIP mandate any means of interaction between a proxy server and a location service. How you choose to set up the SIP system is entirely up to you. You can choose whether or not to use a location service. If you decide to use one, you can choose the type of location service to use. The RTC Server uses a proprietary location service, not Active Directory (AD).
Prev. page
1
[2]
3
next page 
