|
|
The following sections describe how WebLogic SIP Server 2.2 functions in a service provider network:
WebLogic SIP Server can be deployed in 3GPP R6 compliant IMS networks as well as in non-IMS networks. WebLogic SIP Server 2.2 can interoperate with a number of network functions regardless of which applications or functions it hosts.
3GPP R6 Specification Conformance outlines WebLogic SIP Server's 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 WebLogic SIP 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."
The WebLogic SIP Server 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.
WebLogic SIP Server uses certain p-headers directly. For example, p-asserted-identity is used as an assertion of identity within the WebLogic SIP 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.
WebLogic SIP Server does not programmatically force applications to be compliant with the 3GPP SIP Profile, although applications deployed on WebLogic SIP 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.
WebLogic SIP Server 2.2 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.:
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.
For a more detailed description of the Service Trigger Points supported by WebLogic SIP Server 2.2 see SIP Servlet API Service Invocation.
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. WebLogic SIP Server 2.2 does not support IPv6.
When using TCP, WebLogic SIP Server 2.2 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, WebLogic SIP 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, BEA 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 WebLogic SIP Server 2.2 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.
WebLogic SIP Server 2.2 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 WebLogic SIP Server is "Ut". This interface is primarily used for three purposes:
WebLogic SIP 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.
WebLogic SIP Server 2.2 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 WebLogic SIP Server 2.2.
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 WebLogic SIP Server.
WebLogic SIP Server 2.2 supports four primary management interfaces:
WebLogic SIP Server 2.2 also builds upon WebLogic Server 8.1's basic SNMP support, which includes features such as SNMP proxying. See the WebLogic SNMP Management Guide in the WebLogic Server 8.1 documentation for more information.
The WebLogic SIP Server 2.2 Web Administration Console is used for the following tasks:
The WebLogic SIP Server 2.2 Administration console provides a convenient interface for observing current usage metrics as shown in Figure 3-4, Cluster-Wide SIP Session Metrics, on page 3-9, Figure 3-5, Application Metrics, on page 3-9, and Figure 3-6, Data Tier Statistics, on page 3-10.
The 3GPP R6 specifications define the "Mr" reference point as the SIP protocol. In actual deployments, however, a more refined view of the general-purpose media control interface is required.
Media Server vendors appear to disagree on the possibility of a general-purpose interface between IMS SIP Application Servers and Media Resource Functions, and even on the general architecture of the MRF as a sub-system in the network.
In all cases known to BEA, however, the transport protocols are TCP, UDP, or SCTP combined with application-layer protocols such as SIP or HTTP. The media control messages are generally formatted as eXtensible Markup Language (XML) documents.
WebLogic SIP Server does not provide a specific API for media server control, because there is not yet an applicable standard nor clear opportunity for one to be defined. In cases where the media control interface relies on the exchange of XML documents using standard transports, the implementation of media control is neither complex nor labor intensive for application developers. WebLogic SIP Server provides support for all of the required protocols, and offers a powerful XML-handling facility that is sufficient in nearly all cases.
Interoperability between WebLogic SIP Server 2.2 and many popular MRF implementations from multiple vendors has been demonstrated. Most use cases have been easy to implement using WebLogic SIP Server 2.2.
WebLogic SIP Server 2.2 does not offer any specific capabilities related to charging and billing. It is within the scope of the application developer to generate Call Detail Records or implement interfaces for real-time billing and mediation gateways/functions in the service provider network. WebLogic SIP Server 2.2 supports a number of transport mechanisms and data formats, specifically XML and any text based formats, using Java 2 Standard Edition and Java EE.
WebLogic SIP Server users must be authenticated when they request access to a protected resource, such as a protected method in a deployed SIP Servlet. WebLogic SIP Server 2.2 enables you to perform SIP Servlet authentication using any of the following techniques:
Different SIP Servlets deployed on WebLogic SIP 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.
WebLogic SIP 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.
WebLogic SIP Server 2.2 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.
WebLogic SIP Server 2.2 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.
WebLogic SIP Server 2.2 enables administrators to designate network hosts that are considered to be "trusted". Trusted hosts are hosts for which WebLogic SIP 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.
WebLogic SIP Server 2.2 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.
It is also possible to use WebLogic SIP Server 2.2 in scenarios that do not involve trusted hosts. See Standards Alignment for a more detailed description of WebLogic SIP Server 2.2 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. WebLogic SIP Server adds additional deployment descriptor elements to help developers easily map SIP Servlet roles to actual principals and/or roles configured by the WebLogic SIP Server 2.2 administrator.
|
