Administrator Guides EN Owner's manual

Abstract (from RFC3261):
41-001391-00 Rev 03 – 04.2012 13-2
SIP supports five facets of establishing and terminating multimedia communications:
• User location: determination of the end system to be used for communication;
• User availability: determination of the willingness of the called party to engage in communications;
• User capabilities: determination of the media and media parameters to be used;
• Session setup: "ringing", establishment of session parameters at both called and calling party;
• Session management: including transfer and termination of sessions, modifying session parameters, and invoking serv-
ices.
SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF proto-
cols to build a complete multimedia architecture. Typically, these architectures will include protocols such as the real-time
transport protocol (RTP) (RFC 1889 [28]) for transporting real-time data and providing QoS feedback, the real-time stream-
ing protocol (RTSP) (RFC 2326 [29]) for controlling delivery of streaming media, the Media Gateway Control Protocol (MEG-
ACO) (RFC 3015 [30]) for controlling gateways to the Public Switched Telephone Network (PSTN), and the session descrip-
tion protocol (SDP) (RFC 2327 [1]) for describing multimedia sessions. Therefore, SIP should be used in conjunction with
other protocols in order to provide complete services to the users. However, the basic functionality and operation of SIP
does not depend on any of these protocols.
SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services. For exam-
ple, SIP can locate a user and deliver an opaque object to his current location. If this primitive is used to deliver a session
description written in SDP, for instance, the endpoints can agree on the parameters of a session. If the same primitive is
used to deliver a photo of the caller as well as the session description, a "caller ID" service can be easily implemented. As
this example shows, a single primitive is typically used to provide several different services.
SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to
be managed. SIP can be used to initiate a session that uses some other conference control protocol. Since SIP messages
and the sessions they establish can pass through entirely different networks, SIP cannot, and does not, provide any kind of
network resource reservation capabilities.
SIP Concepts and Services
The following are selected definitions from the draft:
Address-Of-Record:
An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to
another URI where the user might be available. Typically, the location service is populated through registrations. An
AOR is frequently thought of as the "public address" of the user.
Back-to-Back User Agent
A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server
(UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates
requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has
established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior.
HOME DOMAIN
The domain providing service to a SIP user. Typically, this is the domain present in the URI in the address-of-record of
a registration.
Location Service:
A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s).
It contains a list of bindings of address-of-record keys to zero or more contact addresses. The bindings can be created
and removed in many ways; this specification defines a REGISTER method that updates the bindings.