| Oracle® Communications Converged Application Server Concepts Release 5.1 Part Number E27705-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Converged Application Server Concepts Release 5.1 Part Number E27705-01 |
|
|
PDF · Mobi · ePub |
This chapter describes how Oracle Communications Converged Application Server functions in a service provider network.
Converged Application Server can be deployed in 3GPP R6 compliant IMS networks as well as in non-IMS networks. Converged Application Server can interoperate with a number of network functions regardless of which applications or functions it hosts, as depicted in Figure 3-1.
Figure 3-1 Converged Application Server Deployed in a Typical Service Provider Network
The following sections provide more information on the role of the Converged Application in the network, as depicted in Figure 3-1.
Note:
"3GPP R6 Specification Conformance" describes Converged Application Server conformance to the requirements introduced in the 3GPP Release 6 specifications.The SIP interface between the Serving CSCF and the IMS SIP Application Server (AS) is defined as the IMS Service Control (ISC) reference point. Although ISC is generally compliant with the SIP protocol as defined by the IETF, it introduces several specific procedures and transport layer requirements. SIP usage is often described as the "3GPP SIP Profile."
The ISC reference point does not require that the AS or Serving CSCF add any particular attribute or value to a request or response beyond the standard behavior of a SIP protocol entity. There are, however, a number of SIP methods and headers that are relevant to many of the services that are deployed on the IMS (SIP) AS. In order for the IMS SIP AS to "fully" comply with all of the 3GPP R5 and R6 specifications, many IETF RFCs and drafts would have to be supported. However, it is not reasonable to characterize this as "ISC compliance" because ISC specifically addresses the relationship between the IMS (SIP) AS and the Serving CSCF. From this perspective, ISC compliance is relatively straightforward and is minimally reflected in "Procedures at the AS" defined in 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 6)."
From the perspective of the Converged Application Server, the Serving CSCF is a SIP Proxy and/or User Agent (in the case of the Registration Event Package and third-party registration messages) and is the SIP Application Server's default gateway for SIP requests when the AS instantiates a User Agent Client.
The 3GPP requires SIP to be used in a more restricted manner than the IETF specs allow, and also requires a number of additional SIP headers. This use of SIP is often referred to as the "3GPP SIP Profile."
Converged Application Server's SIP Servlet Container provides automated management of session objects, Servlet lifecycle, security, OAM and other functions that are not clearly within the scope of an application's business logic. The SIP Servlet Container allows applications to handle (send/receive) SIP messages with non-standard methods or headers—the container is concerned only with the validation of message syntax, and with the protocol transaction layer.
Converged Application Server uses certain p-headers directly. For example, p-asserted-identity is used as an assertion of identity within the Converged Application Server security framework. Other headers, like the 3GPP p-charging-vector or p-charging-function-address, are relevant only within the scope of the application and have no container-level implications.
Converged Application Server does not programmatically force applications to be compliant with the 3GPP SIP Profile, although applications deployed on Converged Application Server may comply with the SIP Profile as necessary.
When requests are sent to an IMS SIP Application Server by the S-CSCF, the SIP AS is generally required to determine the session case (originating, terminating, or terminating unregistered) of the request, either implicitly or explicitly.
Converged Application Server provides several ways of determining the session case for the request. There are three mechanisms described in the 3GPP standardization that an IMS (SIP) AS may use to make this determination:
Session Case Specific Addresses (e.g. sip:sessioncase_as01.operator.net or sip:as01.operator.net:49494)
Tokens in the “User Part” of the Request URI (e.g. sip:token@as01.operator.net)
Request URI Parameters (e.g. sip:as01.operator.net;parameter)
See "3GPP TS 24.229: IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 6)" for more information.
The choice of which mechanism to use is at the discretion of both the Communications Service Provider and the SIP Servlet application deployer. The SIP Servlet API relies on a deployment descriptor file that is packaged with the SIP Servlet Application archive file when it is created. The descriptor explicitly indicates the Service Trigger Points that will be used by the SIP Servlet Container to determine which SIP Servlets to invoke. These Service Trigger Points are sufficient to support any of the methods described above for determining the session case of the request.
See Appendix A, "SIP Servlet API Service Invocation" for a more detailed description of the Service Trigger Points supported by Converged Application Server.
The 3GPP Release 6 specifications mandate the use of IPv6 (see IETF RFC 2460: Internet Protocol, Version 6 (IPv6) Specification) for all interfaces, including ISC. Converged Application Server also supports IPv6.
When using TCP, Converged Application Server does not arbitrarily create new connections for each SIP Transaction or Dialog. By default, responses to SIP requests are returned using the connection on which the request was received. If a TCP connection fails, Converged Application Server establishes a new TCP connection to the target host. This may mean that responses to SIP requests are returned using TCP connections that are different from the connection over which the request was sent. Although this conforms to the current best practice and to "IETF RFC 3261: SIP: Session Initiation Protocol," Oracle has discovered that many SIP products on the market demonstrate non-compliant behaviors with regard to handling OSI layer 3 protocols.
Although it is not normally the case that Converged Application Server is deployed directly facing end-user SIP devices, it is important to understand the impact this behavior might have in such cases. When interacting with SIP endpoints on the public Internet, TCP connections are often kept alive indefinitely as a means of overcoming Network Address Translation (NAT) limitations in many typical broadband routers and residential gateways.
Converged Application Server does not provide an Application Layer Gateway (ALG) capability, and it is presumed that such capabilities are provided by a standard Session Border Control function.
The 3GPP reference point associated with the HTTP interface provided by Converged Application Server is “Ut”. This interface is primarily used for three purposes:
As a Web-based User Interface for customer self-care and service configuration, potentially using HTML, XHTML or other presentation technologies.
To support content indirection.
To support XML Configuration Access Protocol (XCAP), required by Presence and Conference Control Protocol.
Converged Application Server provides HTTP support through its HTTP Servlet Container. Application developers may implement applications or components that support any or all of the above use cases for the “Ut” reference point.
Converged Application Server supports the Sh reference point used to interact with the Home Subscriber Server (HSS) as the principal provider of IMS Profile data associated with the Public Identity of the network user or subscriber. In many cases, standard LDAP directory servers or relational databases are also used as supplementary resources for service or subscriber data. These may also be accessed via standard interfaces supported by Converged Application Server.
In many deployments, and for certain types of services such as Presence or media repositories, subscriber and service data can be accessed using other means. These include LDAP, HTTP, or access to relational databases.
In non-IMS deployments, the security provider may also be a standard directory accessed via Lightweight Directory access Protocol (LDAP) or access to a relational database using a database-specific interface. Most major commercial relational databases provide Java Database Connectivity (JDBC). A number of high-performance and fault-tolerant JDBC drivers are available commercially for use with Converged Application Server.
The Converged Application Server Proxy Registrar implements the proxy and registrar functions described in RFC 3261. The Proxy Registrar combines the functionality of a SIP proxy server and registrar. Its main tasks include registering subscribers, looking up subscriber locations, and proxying requests onward. The Proxy Registrar is an optional component.
The Proxy Registrar's registrar function processes the REGISTER requests from user agent clients (UACs) and uses a location service to store a binding (that is, an association) between a user's address of record (AOR) and one or more contact addresses, typically the IP addresses of the UACs. The To header field of the REGISTER SIP message sent by a UA contains the address of record whose registration is to be created, queried, or modified and the CONTACT header field contains the corresponding contact addresses. The bindings between the AOR and the contact addresses are persistently stored in a database. The supported databases are Oracle 11g and MySQL 5.4.
Figure 3-2 illustrates the registration flow.
Upon receiving requests to the AOR, the proxy function locates the mapped URIs through a Location Service lookup and then proxies the request using the location information retrieved by this lookup.
Figure 3-3 illustrates a simplified view of the interaction between UAs when a subscriber, Alice, calls another subscriber, Bob, who is located in the same domain.
Bob may be registered from multiple user agents, such as personal phone, work phone, and computer. In this case, the query for Bob's location will return multiple bindings to the Proxy. The Proxy will then fork the call, either in parallel or sequentially, to the user agents that Bob is logged in to.
The Proxy is capable of proxying not only INVITE request, but other non-REGISTER requests such as MESSAGE, PUBLISH, SUBSCRIBE and so on.
When a caller and callee are in the same domain, the callee's location can be obtained by the outgoing proxy through the location service. A simplified example of the call flow for this scenario is shown in Figure 3-4. Note that this example does not include 100 Trying and 180 Ringing responses.
Figure 3-4 Call Establishment Flow Between Subscribers in a Single Domain
After the call is established, Alice and Bob's UAs can communicate directly, without using the Proxy. However, you can configure to route all subsequent traffic through the Proxy as well. This is the default and is useful if you want the ability to add additional services during the session.
If the caller and callee are in different domains, the outgoing proxy forwards the INVITE request to the callee's domain. The incoming proxy in the callee's domain performs the lookup and returns the callee's location, as illustrated in Figure 3-5.
The Proxy can use ENUM lookup to resolve TEL URLs. The backend for the ENUM service is a DNS, which stores a mapping between TEL URLs and SIP URIs.
You configure the Proxy Registrar primarily through the Administration Console. You configure authentication for the Proxy Registrar by editing the sip.xml deployment descriptor packaged in the Proxy Registrar application. You can also edit advanced parameters by using WebLogic Scripting Tool For more information, see "Configuring the Proxy Registrar" in the chapter "Configuring Engine Tier Container Properties" in Converged Application Server Administration Guide.
Converged Application Server enables control of media servers using the Media Server Control API based on JSR309, a standard Java interface. JSR309 (also referred to as JSR 309 and the JSR 309 API) defines an abstract Java interface for the manipulation of audio and video streams and conferences. Vendors of IP media servers provide JSR 309 based driver implementations that work with their IP media servers.
The JSR309 architecture assumes a distributed or IMS-like model where the Converged Application Server and media server reside on separate physical servers. User Agents (such as soft phones) interact with the applications deployed on Converged Application Server using the SIP protocol.
Converged Application Server supports media server control by providing built-in JSR309 support. The support includes the Media Server Control API, which provides a standard API for developing and deploying media rich, JSR-based applications for the Java platform without having prior knowledge of the underlying Media Server Control protocols.
A Java application that uses the Media Server Control API can use any JSR309-based implementation with any compatible media server. However, Converged Application Server provides a built-in JSR309 media driver, JVoiceBridge.
Whether using JVoiceBridge or the driver for another media server, the CAFE and Media Server Control APIs offer interfaces that ease the task of developing media-rich applications, such as Conferencing, Ring-back tone, or IVR applications easily using the JSR309 API.
For developers, the Media Server Control API provides a standard API for developing and deploying media rich, JSR-based applications for the Java platform without having prior knowledge of the underlying Media Server Control protocols. Moreover, a Java application that uses the Media Server Control API can use any JSR309-based implementation with any compatible media server.
For more information, see the discussion of media control in Converged Application Server Administration Guide.
Converged Application Server provides both a Diameter Rf interface application and a Diameter Ro interface application to facilitate offline and online charging in IMS networks. See "Using the Diameter Rf Interface Application for Offline Charging" and "Using the Diameter Ro Interface Application for Online Charging" in Converged Application Server Diameter Application Development Guide for information about how to access and use these Diameter applications in your own SIP Servlets.
Converged Application Server users must be authenticated when they request access to a protected resource, such as a protected method in a deployed SIP Servlet. Converged Application Server enables you to perform SIP Servlet authentication using any of the following techniques:
DIGEST authentication uses a simple challenge-response mechanism to verify the identity of a user over SIP or HTTP. See "Configuring Digest Authentication" in Converged Application Server Administration Guide.
CLIENT-CERT authentication uses an X509 certificate chain passed to the SIP application to authenticate a user. The X509 certificate chain can be provided in a number of different ways. In the most common case, two-way SSL handshake is performed before transmitting the chain to ensure secure communication between the client and server.
BASIC authentication uses the Authorization SIP header to transmit the username and password to SIP Servlets. BASIC authentication is not recommended for production systems unless you can ensure that all connections between clients and the Converged Application Server instance are secure.
Different SIP Servlets deployed on Converged Application Server can use different authentication mechanisms as necessary. The required authentication mechanism is specified in the auth-method element of the SIP Servlet Application's deployment descriptor. The deployment descriptor may also define resources that are to be protected, listing the specific role names that are required for access.
The Converged Application Server authentication services are implemented using one or more authentication providers. An authentication provider performs the work of proving the identity of a user or system process, and then transmitting the identity information to other components of the system.
Converged Application Server may be configured to use multiple authentication providers via different authentication methods. For example, when using Digest authentication an administrator may configure both a Digest Identity Asserter provider to assert the validity of a digest, and a second LDAP or RDBMS authentication provider that determines the group membership of a validated user.
Converged Application Server is designed for deployment scenarios where it is adjacent to trusted hosts and it is not required to fulfill the role of an application layer security boundary between the trusted and untrusted domains.
Converged Application Server enables administrators to designate network hosts that are considered to be “trusted.” Trusted hosts are hosts for which Converged Application Server performs no authentication. If the server receives a SIP message having a destination address that matches a configured trusted hostname, the message is delivered without Authentication.
Converged Application Server supports the P-Asserted-Identity SIP header as described in IETF RFC 3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks. This functionality automatically logs in using credentials specified in the P-Asserted-Identity header when they are received from a trusted host. When combined with the privacy header, P-Asserted-Identity also determines whether the message can be forwarded to trusted and non-trusted hosts.
Figure 3-6 Asserted Identity Handling in Converged Application Server
It is also possible to use Converged Application Server in scenarios that do not involve trusted hosts. See Chapter 6, "Standards Alignment," for a more detailed description of Converged Application Server standards compliance.
The SIP Servlet API specification defines a set of deployment descriptor elements that can be used for providing declarative and programmatic security for SIP Servlets. The primary method for declaring security constraints is to define one or more security-constraint elements and role definitions in the sip.xml deployment descriptor. Converged Application Server adds additional deployment descriptor elements to help developers easily map SIP Servlet roles to actual principals and/or roles configured by the Converged Application Server administrator.
A Session Border Controller (SBC) is a device used in VoIP networks to exert control over the signaling (and usually also the media streams) involved in setting up, conducting, and tearing down interactive media communications. SBCs are typically used to secure and protect the network and other devices in the operator's network from denial of service (DOS) attacks. Besides security, SBCs also perform functions such as QoS guarantees, regulatory compliances (lawful intercept), statistics collection, and so on. Services developed and deployed on Converged Application Server are most commonly hosted inside trusted networks. It is recommended to protect the network which hosts such services deployed on Converged Application Server with a Session Border Controller.
|
 Copyright © 2005, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
