Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Controlling Usage of Distributed Real-Time Multi-Media Communications System

IP.com Disclosure Number: IPCOM000116356D
Original Publication Date: 1995-Sep-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 117K

Publishing Venue

IBM

Related People

Aldred, BK: AUTHOR [+4]

Abstract

Frequently in the operation of a multi-media communications implementation there is a need for control capabilities, either to restrict access to expensive resources and implement access policies, or to allow for costing and billing.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 49% of the total text.

Controlling Usage of Distributed Real-Time Multi-Media Communications
System

      Frequently in the operation of a multi-media communications
implementation there is a need for control capabilities, either to
restrict access to expensive resources and implement access policies,
or to allow for costing and billing.

      In the described system, these requirements are met by audit
managers; at any node an application can become an audit manager
through issuing the SetAuditManager API call.  Two kinds of audit
managers are supported: local and remote.  Both of these receive
information on application activity and may be required to approve
certain actions but additionally, local audit managers give
permission for their node to be remotely audited.  Only one audit
manager, with one audit event handler, per node is permitted; however
a single node may be audited by multiple remote audit managers.

      The SetAuditManager request identifies the target node and
application to be audited; if no application is specified then all
applications at that node are assumed.  A remote node can only be
audited if an active link already exists to that node.  The request
specifies the address of the audit event handler and the scope of
audit, defined through the identification of one or more audit
classes.

      The audit classes available are:
  Applications:           raise audit events for the specified
                           node/application(s).
  Channels:               raise audit events for channels to/from
                           the specified  node/application(s).
  Quality of service:     raise audit events for quality of service
                           requests for the specified
                           node/application(s).
  Tokens:                 raise audit events for local and global
                           tokens requests for the specified
                           node/application(s).

      If local auditing has been requested then the AUDIT_ SET_
AUDIT_ MANAGER_ REQUEST event is raised in the audit event handler of
the current local audit manager and provides a mechanism for allowing
or disallowing transfer of control.  If no audit manager exists the
event is processed by the default event handler, which allows the new
audit manager to be established.

      If remote auditing has been requested, the AUDIT_ REMOTE_
AUDIT_ MANAGER_ REQUEST event is raised in the audit event handler of
the remote audit manager which responds to allow or disallow the
remote
audit.  If no local audit manager exists then the request is
rejected.

      Depending upon the scope of the audit, almost all activity by
an audited application raises an audit event, first at the local
audit manager(s), then at the...