We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
Network Identity Management API Specification - FIWARE Forge Wiki

Network Identity Management API Specification

From FIWARE Forge Wiki

Jump to: navigation, search

Please consider that this description is not final yet.

Contents

Introduction to the S3C.IdentityManagementModule API (S3C.IdM)

Please check the Legal Notice to understand the rights to use FI-WARE Open Specifications.

S3C.IdM API Core

In the first version of the he S3C.IdM API the main focus lies on SIP oriented applications. The services, which will use the Module, are needed to understand custom made private header P-Header in the SIP Signalling Messages (see RFC 3325 and RFC 3455). This approach will affect also the S3C inner & outer interfaces, because the Network IdM will be more or less handled like an additional SIP Proxy but will be located in the application/service layer, which means it is also a kind of application server. The two interfaces towards OpenIMS Core and OpenEPC will be changed to one connection towards the HSS interface. The Home Subscriber Server (HSS) is used to store the subscription profiles of all subscribers in an IMS-domain.

Intended Audience

The specification is more intended for the service developers, which can benefit from the Virtual Identity Attributes as well as On-Demand Service Provider which are able to provide the data with the help of SIP signalling, which the IdM Module will provide to the service. You should be familiar with:

  • IMS (IP Multimedia Subsystem)
  • SIP (Session Initiation Protocol)

API Change History

Revision Date Changes Summary
May 7th, 2012
  • Updated The Picture
  • Changed the underlying text regarding to the picture
May 16th, 2012
  • Added Sequence Diagram + Text
  • Added some new P-Header fields
October 17th, 2012
  • Tidy up the documentation
  • Changed the structure regarding the features of the Network Identity Management
  • Added Third Party Call Control Feature
  • Added the Security Thoughts Section
November 17th, 2012
  • Tidy up the documentation
November 17th, 2012
  • Updated Page and removed unreleased feature set

S3C.IdM API Information

Intelligent Device Identification / Third Party Call Control

The intelligent device identification can be used to distinguish different User Agents (UA) of one specific subscriber in an IMS Core environment.

With the help of the RFC 5627 (Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol) you are able to address only one specific User Agent Instance of a subscriber. Therefore it is needed that the User Agent has implemented the RFC 5627 (Obtaining and Using GRUU). Beside the possibility of different end users as well as different User Agents on a device, we define one user agent (sip client) per device, which leads to the device identification with the help of the user agent. We are not focusing on multiple instances per device but on multiple devices (each with one user agent) per subscriber.

To understand how this is possible, you have to consider, that per subscriber a public identity (called IMPU) as well as at least one private identity (called IMPI) is necessary in the IMS Core. If a service or another subscriber wants to reach a user he tries to contact this subscriber via the public identity. The IMS Core forwards the SIP INVITE to all connected user agents of that registered profile - this means every connected device gets the INVITE which is not always the intended functionality.

General Architecture

Picture 1: General Architecture for Device Identification

Each device has a specific identifier called GRUU, this is represented in the sip.instance. This identifier is transmitted via the header value "sip.instance" in the registration process at the contact header field. The Network IdM is involved in the registration process and knows therefore the connected devices per user over the instance ID (GRUU). The picture contains only example data. Usually the identification of a user agent is longer than 3 digits. Regarding RFC 5626, the sip instance is a Uniform Resource Name (URN) that uniquely identifies this specific UA instance. This identity appears in two variants. A temporary GRUU and a public GRUU. The Network IdM deals only with the public GRUU.

Use Case: Video on Demand

For the service providers the Identity Management is able to provide a list of contact points (User Agent Instances) per subscriber. Therefore the service is able to reach only one specific end users device. This is helpful for on demand consuming services. The service gets via the HTTP/REST interface the list of all connected devices per subscriber (e.g. bob@ims.domain). The documentation of that API is still under consolidation and will be published when this is finished. Regarding to the figure 7.4.IdM.1, the service receives the list with four entries upon a request. The user decides to demands a specific video and chooses on which user agent instance he wants to obtain this video.

This new created demand needs to be sent to the Network IdM over the HTTP/REST API with the following general information:

  • From
  • To
  • User Device Id.

The Network IdM Feature Third Party Call Control (3PCC) will establish at first a connection towards the end user's target device (user agent instance). After that, it establishes the connection towards the "From" Address. The third step is to interconnect the two established connections. After this, the 3PCC Function is only a signalling proxy relay service to be always informed of the status of this flow.

This mechanism is described in RFC 3725 (Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol in section 10.1 Click-to-Dial).

Next to the direct chosen UA instance, RFC 3840 describes a way to contact only feasible UA instances with a set of required capabilities. This additional feature needs more logic in the core network and is not implemented by now in the used OpenIMS Core and also not planned to get implemented.

API Description

This part is currently under construction and will be published as soon as possible. Nevertheless, it is considered to use the mechanisms and syntax of GSMA's oneAPI (see oneAPI and oneAPI's RESTful API for Voice Call Control) for the RESTful API towards the service providers.

Personal tools
Create a book