SIP Profile Overview

• Purpose

• Architectural Relationships

• Description of the interface class structure

• Memory overhead

The Session Initiation Protocol (SIP) Profile API provides a SIP registration service for applications through the use of a profile. A profile holds the information necessary for providing the required registration behaviour.

The behaviour of the registration service depends on the profile type used. There are different profile types for different standards, e.g., 3GPP R5 IMS, IETF and proprietary. At any given time, zero or more profiles of any profile type may exist. Each profile has a one-to-one correspondence with each SIP registration. The API allows more than one application to share the same profile, and thus the same SIP registration. The implementation of the API stores SIP profiles in persistent store.

A profile stores the following main parameters:

• The user-friendly name of the service provider.

• The type of the profile, e.g., 3GPP R5 IMS, IETF or proprietary.

• The user's registered public name (SIP AOR).

• The access provider identifier of the used IAP.

• The address of the SIP registrar server, with optional connection and security parameters.

• The address of the SIP proxy server, with optional connection and security parameters.

• Compression and security preferences.

• An indication as to whether the profile is always to be registered automatically, or registered only when it is used by an application.

• Any number of extension parameters stored in the form of key-value pairs.

The interface allows multiple clients to share common resources, profiles and SIP registrations through the client-server mechanism. It also gives access to permanently stored profiles and allows the reading of profiles' configuration values.

All time-consuming operations are asynchronous.

You need the following capabilities to use the SIP Profile API.

Capability

NetworkControl

NetworkServices

ReadUserData

The API cannot be extended.

A client of the SIP Profile API must create a CSIPProfileRegistry object.

As a precondition the client must already have created a CSIP object, and must also have implemented the callback functions defined by the MSIPProfileRegistryObserver class.

A CSIPProfile object is created using one of the retrieval functions that can be accessed through the CSIPProfileRegistry class. Profile data is copied from the permanent store into the new object. The copied values can be accessed using the accessor functions of CSIPProfile.

A client must enable a profile before using it. This is done by:

• providing an implementation of the MSIPConnectionObserver class

• calling CSIPProfileRegistry::EnableL()

The profile must be enabled whether or not it is already registered. Enabling the profile causes the profile to register itself, if it is not yet registered. In this event, the client is notified about the registration status through the callback function MSIPProfileRegistryObserver::ProfileRegistryEventOccurred().

By enabling the profile, the client indicates that the profile is being used by someone, and thus cannot be removed. Even in this case, the profile may be updated, although this is not recommended.

The client can stop using a profile by disabling it. The client can then delete the CSIPProfile object.

The following diagram shows the SDP Profile API class structure.

The amount of overhead memory used by a profile depends on its content. A typical usage is approximately 0.2 kB per profile. Also, the SIP Profile server monitors all instantiated profiles in order to send asynchronous events to clients when needed. It is therefore recommended that clients only create the minimum necessary number of profiles, and delete instances immediately when they are no longer needed.