Browse Prior Art Database

Inter-Operation with Wide Area Desktop Conferencing Standard T.120

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

Publishing Venue

IBM

Related People

Aldred, BK: AUTHOR [+3]

Abstract

T.120 is the proposed ITU standard for desk top conferencing. It is highly desirable that any architecture for Real-time Multi-media Communications (RTMMC), which includes desk top conferencing, is interoperable with the proposed standard. Since the RTMMC application programming interface will typically offer a superset of the equivalent component in T.120 (MCS), the approach is to provide compatibility for a subset of the RTMMC API.

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

Inter-Operation with Wide Area Desktop Conferencing Standard T.120

      T.120 is the proposed ITU standard for desk top conferencing.
It is highly desirable that any architecture for Real-time
Multi-media Communications (RTMMC), which includes desk top
conferencing, is interoperable with the proposed standard.  Since the
RTMMC application programming interface will typically offer a
superset of the equivalent component in T.120 (MCS), the approach is
to provide compatibility for a subset of the RTMMC API.

      Given the essential incompatibilities in the protocol streams
produced by the two architectures, the solution is based upon the
following elements:
  o  application proxies in both environments that simulate the real
      applications that each environment expects
  o  a RTMMC call manager that establishes the application proxies
and
      controls their operation

      The application proxies are the key to inter-operability.  Each
proxy appears in both environments; such a proxy collects the events
that a real application should have received in one environment and
then uses its appearance in the other environment to issue a request
that will have the desired effect in that environment.  This mapping
process is controlled by the RTMMC call manager at the node supplying
the interconnection.

      A fictitious example, illustrated in the Figure, explains the
approach.  Consider an application L in the RTMMC environment
collaborating with an application M in the MCS environment as shown
in (a).

      The proposed solution is to create an application proxy P which
appears: (a) as application l in the MCS environment representing
application L and, (b) as application m in the RTMMC environment
representing MCS application M.  Assume M issues a request that
generates an MCS event at l; proxy P now uses its m appearance to
issue a request that produces an equivalent RTMMC event at L; this is
shown in (b).  In essence, the intent of M in the M...