Introduction

Purpose and scope

The purpose of the document is to re-implement basic BLF and Presentity functionality from PortaPresence solution in PortaSIP (Media Server) Cluster.

Collaborators

Business Department

• Vlad Chetyrko, Andriy Zhylenko

Development Department

• Unknown User (psv), Maxim Kondratenko, Unknown User (tez)

Testing and Support Departments

• TBD

Definitions, acronyms and abbreviation

BLF: Busy Lamp Field (BLF) is a light on an IP phone which tells you whether another extension connected to the same PBX is busy or not.

Presence: also known as presence information, conveys the ability and willingness of a user to communicate across a set of devices.

Presentity:  an entity (usually a human) which provides information about its presence (whether it is available and willing to communicate through communication services).

References

1. TT#363625, TT#345154, TT#417587, TT#416479 - existing issues and challenges.
2. RFC3265, RFC6665 - SIP-Specific Event Notifications
3. RFC4235 - An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
4. RFC3856 - A Presence Event Package for the Session Initiation Protocol (SIP)
5. RFC3857 - A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)
6. RFC3903 - Session Initiation Protocol (SIP) Extension for Event State Publication
7. RFC3680 - A Session Initiation Protocol (SIP) Event Package for Registrations

Overview

Currently for providing call and user agent tracking functionality we are utilizing non-clustered solution called PortaPresence. This solution has several important limitation which sometime complicates  further usage of it and for some users make even unacceptable to use such solution. The list of major issues are following:

• Current solution can't be efficient scaled. I.e. it is possible to utilize several PortaPresence servers but they are unable to correctly share data thus we need somehow intentionality separate users pools designated to work with each the PortaPresence which is unacceptable in some cases.
• The PortaPresence doesn't provide any redundancy means. E.g. hardware server failure where a single PortaPresence is installed leads to a failure of functionality provided by it.
• The PortaPresence by design utilizes "third party tracking" logic where call states reconstructed using data from intermediate SIP Proxy. It creates an additional load on such Proxy and doesn't allow reliably restore a call state - any temporary Proxy failure leads to lost signaling and distorted calls state.
• The PortaPresence utilizes only stand SIP header fields to detected tracked entity. This makes impossible providing BLF functionality to PortaBiling entities as account aliases. Also any attempt to manipulate with caller/callee identity leads to broken BLF tracking.

Specifications

Create "Business requirements" Create "Software requirements" Create "Design requirements"

Testing plan

Feature integration guide