[go: up one dir, main page]

WO1998009213A1 - Systeme virtuel de connexion multimedia - Google Patents

Systeme virtuel de connexion multimedia Download PDF

Info

Publication number
WO1998009213A1
WO1998009213A1 PCT/US1997/015018 US9715018W WO9809213A1 WO 1998009213 A1 WO1998009213 A1 WO 1998009213A1 US 9715018 W US9715018 W US 9715018W WO 9809213 A1 WO9809213 A1 WO 9809213A1
Authority
WO
WIPO (PCT)
Prior art keywords
vco
multimedia
control
event
virtual
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US1997/015018
Other languages
English (en)
Inventor
Gregory D. Girard
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
VISUAL TELESYSTEMS Inc
Original Assignee
VISUAL TELESYSTEMS Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by VISUAL TELESYSTEMS Inc filed Critical VISUAL TELESYSTEMS Inc
Publication of WO1998009213A1 publication Critical patent/WO1998009213A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1046—Call controllers; Call servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]

Definitions

  • the invention relates generally to multimedia connection systems.
  • ISDN/BRI Integrated Services Digital Network Basic Rate Interface
  • the software architectures used in the implementation of the motion-video connectivity sub-systems have been extremely tenuous, and essentially unusable as discreet modular components in that they lacked a comprehensive, extensible software model to support the diversity of underlying hardware technologies.
  • Perhaps the best attempt at creating a simple, reusable motion-video connectivity sub-system for integration into second-party products is available from Zydacron, Inc. (Zydacron Z240, Z250) .
  • Even the simple, clean implementation of this system's software control mechanism requires many months of specialized software development, including significant design and implementation of complicated protocol components, before the sub-system is usable in a commercial product.
  • ITU-T RECOMMENDATION H.320 Motion-video connectivity, between systems from different vendors, is possible only through the general acceptance of standardized protocols for interconnection between local and remote stations.
  • the International Telecommunication Union (ITU-T) adopted Recommendation H.221 (LINE TRANSMISSION OF NON-TELEPHONE SIGNALS) as the standard for the interconnection of devices supporting the exchange of audio, video, and binary data types (see ITU-T Recommendation H.221, FRAME STRUCTURE FOR A 64 TO 1920 kbits/s CHANNEL IN AUDIOVISUAL TELESERVICES, 1994.
  • Recommendation H.320 is a virtualized definition of an extensible, finite set of capabilities, device modes, data transfer frame structures, and call control procedures.
  • multimedia connectivity software architectures are mostly hardware driven. Since multimedia connectivity tasks, such as videoconferencing, require synchronous encoding/decoding of audio and video data at high data rates emanating to/from synchronous data transfer connectivity devices, most of the motion-video connectivity devices integrate all the necessary components onto one large, ulti- purpose device. Typically these devices take the form of an ISA or EISA personal computer adapter that includes additional hardware support for specialized video overlay functions. Without a major software development effort, it is impossible to utilize the manufacturer's sub-system for a new connectivity application.
  • a data transfer rate of 384 kbit/s is required to produce motion-video connection services with frame rates and image clarity sufficient for large-scale acceptance of these technologies; a 128 kbit/s data transfer rate produces video image quality that can best be described as "disappointing" to uninitiated technology customers who typically expect a broadcast quality television image (see D. Minoli and R. Keinath, Distributed Multimedia Through Broadband Communications Services, Norwood, Massachusetts, Artech House, pp. 187-207, 1994).
  • the principle that underlies the GDI is that there exists a finite set of graphical operations that will enable a software developer to draw just about anything on a bitmapped display device. It is taken into consideration that some graphics hardware is more or less suitable for the direct implementation of these operations; some operations may not be supported at all by the hardware. To derive a set of abstract, logical operations, without giving consideration to the underlying mechanism needed to support them, is referred to as the process of virtualization. In a GDI implementation, any graphics operation that may be supported directly by a hardware function, is accessed directly using a vendor-specific device driver. If a close mapping of a physical to a logical graphical operation exists, some software modification of the physical operation, to better implement the desired logical operation, is invoked as needed.
  • Videoconferencing is but one interesting multimedia connectivity service.
  • a generalized model for multimedia connectivity application development must take into consideration that the essence of these technologies is the structured sharing of sound and light spectral data (as opposed to binary data) .
  • the vendor- specific facets of media transducers and network interfaces employed to implement related services must be rendered entirely irrelevant to the operation of software programs desirous of device-independent audiovisual teleservices.
  • VCO Virtual Connection Object
  • Each VCO contains a reusable Virtual Device Interface (VDI) software component that contains the VCO's Software Control Interface (SCI) and device-independent media/connection device control methods.
  • VDI derives implementation of its services from a Virtualization Layer (VL) .
  • the Physical Device Interface (PDI) provides control of the physical media transducers and one or more network interface units, in a fashion consistent with both the techniques specified by their manufacturers, and in a way that enables their efficient utilization by methods in the VL.
  • Device-generated events, occurring in real-time, asynchronous with the system scheduler are inserted—into an infinite event queue, to be periodically dispatched to the VDI, synchronous with the system scheduler.
  • VCO Physical limitations on the level of service provided by encapsulated media transducers/network interface, are expressed as the Local Capabilities. When connected, the capabilities of the remote station are expressed as the Remote Capabilities, and are available to the constructor of the VCO. The quality of the connection is described as the logical intersection of both the Local Capabilities and the Remote Capabilities, and is referred to as the Connection Capabilities.
  • VCO implementations abstract multimedia connectivity services to the level of the Open Systems Interconnection Reference Model Presentation Layer; device-dependent control methodologies for vendor-specific media transducers and connectivity protocol stacks have no representation in the Presentation Layer.
  • Software programs that construct VCOs and utilize the presented multimedia connectivity services are referred to as VCO Clients. These device-independent connectivity programs realize the benefits of interoperability across any multimedia connectivity sub-system that encapsulates its services into a Virtual Connection Object, according to the disclosed methodology.
  • the invention is a multimedia connectivity program residing in computer readable memory.
  • the connectivity program when executed on a computer providing to an application program multimedia connectivity services through a real-time multimedia device control subsystem including components selected from among a plurality of multimedia devices and a plurality of real-time multimedia protocol stacks.
  • the program includes a single binary object encapsulating a virtual device interface and a device control interface.
  • the virtual device interface includes a plurality of virtual methods that represent logical operations available to the application program for controlling the multimedia device control subsystem.
  • the plurality of virtual functions are completely independent of the components within the device control subsystem.
  • the device control interface mapps the plurality of virtual functions to physical control methods which control the components of the multimedia control subsystem.
  • the device control interface includes a plurality of media control objects which represent audiovisual and binary data streams associated with the components of the plurality of devices and/or real-time multimedia protocol stacks.
  • the virtual device interface is configured to present a logical representation of the multimedia connectivity services provided by the connectivity program.
  • the device control interface includes a virtualization layer and a physical device interface layer, the virtualization layer being located between the virtual device interface and the physical device interface.
  • the physical device interface directly interfaces to the device control subsystem to provide a physical implementation of services requested by the application through the virtual device interface.
  • the virtualization layer resides between the virtual device interface and the physical device interface layer and is configured to translate and map device control mechanisms employed by the underlying multimedia control sub-system to representations required by the virtual methods of the virtual device interface.
  • the plurality of media control objects provides the multimedia connectivity control program with a pool of media device signal resources.
  • Each of the plurality of media control objects is classified as at least one of type of the group consisting of an audio type, a video type, an image binary data type.
  • each of the plurality of media control objects represents a signal from the group consisting of a signal from a remote station, a signal to a remote station, a signal from a local output device, and a signal to a local output device.
  • the operations performed on the plurality of media control objects by the physical device layer under control of the virtual device interface implements a logical software switching mechanism.
  • the virtual device interface implements a plurality of public member functions, the virtual functions being a subset of those public member functions and the plurality of public member functions representing all of the public member functions in the single binary object that are accessible by the application program.
  • the invention is a computer programmed to provide to an application program multimedia connectivity services through a real-time multimedia device control subsystem.
  • the multimedia device control subsystem includescomponents selected from among a plurality of multimedia devices and a plurality of real-time multimedia protocol stacks.
  • the programmed computer includes a virtual device interface and a device control interface, both of which are encapsulated in a single binary object.
  • the virtual device interface includes a plurality of virtual methods that represent logical operations available to the application program for controlling the multimedia device control subsystem.
  • the plurality of virtual functions are completely independent of the components within the device control subsystem.
  • the device control interface maps the plurality of virtual functions to physical control methods which control the components of the multimedia control subsystem.
  • the invention is a computer implemented method of providing multimedia connectivity services through a real-time multimedia device control subsystem.
  • the multimedia device control subsystem includes components selected from among a plurality of multimedia devices and a plurality of real- time multimedia protocol stacks.
  • the method includes the steps of defining and supporting by computer implemented steps a virtual device interface; and defining and supporting by computer implemented steps a device control interface. Both the virtual device interface and the device control interface are encapsulated in a single binary object.
  • the virtual device interface includes a plurality of virtual methods that represent logical operations available to the application program for controlling the multimedia device control subsystem.
  • the plurality of virtual functions are completely independent of the components within the device control subsystem.
  • the device control interface maps the plurality of virtual functions to physical control methods which control the components of the multimedia control subsystem.
  • Multimedia connectivity sub-systems when developed for use in a VMCS, present an externally consistent, fully abstracted set of logical operations to software programs, therewith exposing the faculty to create adjunct, device-independent, interoperable multimedia connectivity software application programs.
  • the disclosed invention is a methodology to enable the structured sharing of spectral information between interconnected microcomputer stations. Though principally intended to facilitate control of live audio and (motion) video information, this comprehensive connectivity paradigm incorporates mechanisms for store- forward operations; binary data object transfers are also supported.
  • the VMCS pursues a classic client-server model of application/sub-system interaction.
  • the sub-system presents a coherent software control mechanism to device- independent connectivity applications created explicitly to utilize its structured, highly-typed, set of services.
  • VMCS Virtualized Multimedia Connection System
  • FIG. 1 shows the symbol conventions used in the following figures
  • Fig. 2 is a block diagram showing a VCMS component overview
  • Fig. 3 is a block diagram showing a VCO architecture overview
  • Fig. 4 is a block diagram showing the VCO software architecture
  • Fig. 5 is a block diagram showing the VCO client application software architecture
  • Fig. 6 is a block diagram showing the VCO class derivation
  • Fig. 6A is a table of the VCO exception handling modalities
  • Fig. 6B is a table of the VCO trace output modalities
  • Fig. 6C is a table of VCO events which trigger notification
  • Fig. 7 is a block diagram showing the device control mechanism
  • Fig. 8 is a block diagram showing the VCO control methodologies
  • Fig. 9 is a block diagram showing the terminal output control flow
  • Fig. 10 is a block diagram showing the signal triggering mechanism control flow
  • Fig. 11 is a block diagram showing the event queuing and dispatching control flow
  • Fig. 12 is a block diagram showing the connection capability control flow
  • Fig. 13 is a block diagram showing the capability and mode mapping control flow
  • Fig. 14 is a block diagram showing the call controller control flow
  • Fig. 15 is a block diagram showing the line disconnection control flow
  • Fig. 16 is a block diagram showing the line dialed, ringback, busy, and connected control flows
  • Fig. 17 is a block diagram showing the line ring control flow
  • Fig. 18 is a block diagram showing the call reset, mode setting, and mode restoring control flows
  • Fig. 19 is a block diagram showing the exception handling control flow
  • Fig. 20 is a block diagram showing the media control object command control flow
  • Fig. 21 is a block diagram showing the media device capability query control flow
  • Fig. 22 is a block diagram showing the media access control request control flow
  • Fig. 23 is a block diagram showing the device event processing control flow
  • Fig. 24 is a block diagram showing the object construction and destruction control flows
  • Fig. 25 is a block diagram showing the "Open" command control flow
  • Fig. 26 is a block diagram showing the "Close" command control flow
  • Fig. 27 is a block diagram showing the "Call" command control flow
  • Fig. 28 is a block diagram showing the "Multicall" command control flow
  • Fig. 29 is a block diagram showing the "Hang-Up" command control flow; and Fig. 30 is a table of the multipoint control operations.
  • This term refers to a device that converts one form of energy into another.
  • specific reference is given to those that convert light and sound energy to electrical pulses, or inversely, electrical pulses back to light and sound energy. Examples include cameras, microphones, speakers, and video monitors.
  • This term refers to a digital data stream used to transfer raw or encoded binary information, except in the case of direct references to "bit-rate allocation signal indications.”
  • This term refers to a message connoting a change in state or modality of a system or station component; basic unit of notification used for the sole purpose of communicating the occurrence of some specific event.
  • Notification refers to an indication transmitted from one software component in the system to another software component in the same system. Typically used to notify software system components that some specific event has occurred and some response is required.
  • This term refers to sound and light data that are represented as modulations of electromagnetic or audible spectra; audible and visible waveform information.
  • This term refers to electrical pulse data encoded as binary numerical values that are typically referenced in octets.
  • Terminal This term refers to as a physical or virtual teletype console device that displays text data output to it, and returns text input, such as if read from a keyboard device; essentially a dedicated text-processing I/O device or software representation thereof, with no significant processing ability.
  • This term refers to an intelligent node on a network to which other network nodes can connect and exchange messages.
  • This term refers to the station whose resources are directly addressable without using an intervening network connection; conceptually perceived as the near-end of any connection.
  • This term refers to the station whose resources are not directly addressable without an intervening network connection; conceptually perceived as the far-end of any connection.
  • This term refers to bi-directional data transfer between interconnected stations on a network.
  • Vendor-specific refers to any hardware or software system component that requires a non-standardized software control layer to accommodate the particular requisite interface format and control procedures described by its manufacturer.
  • This term refers to a class of digital computer technologies that store, retrieve, manipulate, and play back audible and visual information. These technologicss are embodied in combined software and digital hardware sub-systems that encode spectral information presented to input transducers, into digital data streams that are then stored in a compressed format. This compressed digital information is later reconstituted back to spectral information by decompressing, decoding, and subsequent retransmission through output transducers.
  • This term refers to the generalized concept of establishing a communications link between two or more stations on a network, exchanging messages according to some preconceived notion of structured interaction; this notion of interaction referred to as a protocol.
  • Multimedia connectivity refers to the generalized concept of establishing a communications link between two or more stations on a network, exchanging messages according to some preconceived notion of structured interaction; this notion of interaction referred to as a protocol.
  • This term refers to the generalized concept of establishing an audible, and/or visual communications link between two or more stations on a network;
  • These technologies are embodied in combined software and digital hardware sub-systems that encode spectral information presented to input transducers, into digital data streams that are then transmitted across a network connection to a remote station in a compressed format. There it is reconstituted back to spectral information by decompressing, decoding, and subsequent retransmission through output transducers.
  • the connection between the stations is described as " live” , as if the input transducers of one station were connected directly to the output transducers of the other, and the network becomes conceptually irrelevant to the process.
  • a variety of other media forms, such as still pictures and plain binary data, may also be exchanged between stations on an occasional basis, and played back as needed.
  • MCI Media Control Interface
  • This term refers to a device driver interface specification that allows its users to control underlying physical media devices using a somewhat well-defined, standardized string-token command language.
  • This term refers to that set of MCI drivers that provide a standardized physical device control interface layer between the more device-independent software layers that issue MCI string commands, and the vendor-specific device drivers that contain proprietary interfaces and control procedures to initialize, shutdown, and utilize the peripheral hardware components.
  • This term refers to a methodology to enhance the quality of computer systems by describing their constituent components as discreet sets of related, well-defined operations whose implementations are isolated from their functionally described operational profiles; interactions between system software components are defined with equal precision, according to a specialized software development methodology.
  • Highly-structured programming languagesl and design tools promote creation of modular, reusable software components that can be recombined to build new components; existing components are better understood in terms of functionality and reliability. In this way, implementations of new components borrow the functionality (and demonstrated reliability) of preexisting software technologies to create new products, thereby significantly reducing development time and dramatically improving overall system reliability.
  • VMCS Virtualized Multimedia Connectivity Operating System
  • the VMCS server component runs parallel to the client applications that utilize it, the server responding to client requests with a stream of notifications directed to class objects located in the client programs.
  • a client application invoking a VMCS server spawns a concurrent operating system that effectively manages all hardware and software components necessary to establishing a device-independent multimedia connectivity service, in much the same way as any operating system does to support its general application programs.
  • the VMCS server runs by itself, independent of the client, and capable of offering services to more than one client at the same time.
  • the VCO Client selects an "operating system” that best suits the system hardware configuration, invokes it when needed, discards it when it is no longer needed, and changes it when it prefers an "operating system” with a different service profile. Consistent with the intention of its design, multiple VMCSs can be concurrently invoked.
  • the VMCS in accordance with the "operating system” model heretofore described, was intended from its inception, for implementation in multiprocessor or distributed systems where a separate coprocessor, parallel processor, or entire system could house the server component separately. Further, embedded implementations (for use with coprocessor systems) do not pose the usual implementation difficulties associated with sub-system designs whose client and server component were assumed to reside in shared memory.
  • VMCS virtualized system
  • This methodology is primarily a software development technique.
  • Object-oriented software components are created to abstract the low-level services of media control and network interface components to a fully-virtualized multimedia connection service that integrates the ITU-T multimedia interconnection protocols (H.320), the Open System Interconnection (OSI) Reference Model, and object-oriented software design principles.
  • the VMCS architecture combines these paradigms into a dynamically instantiable client-server multimedia connectivity service technology.
  • ITU-T Recommendation H.320 defines a discreet set of operations and procedures necessary to the sharing of spectral and binary data between compliant interconnected stations. It enables reliable, structured data transfer and device mode synchronization to. stations connected to the Integrated Services Digital Network (ISDN) .
  • ISDN Integrated Services Digital Network
  • a VMCS implementation employs the ubiquitous H.320 recommendation as a rigorous definition of its most basic set of multimedia connectivity operations. For stations that access the ISDN, this application of H.320 is natural and obvious, but the VMCS goes on to take further advantage of the apposite H.320 structure.
  • the VMCS architecture stipulates upon the promotion of the H.320 protocol set to that of a universal framework to which even non-compliant protocols can be promoted.
  • Connectivity system developers can abstract the presentation of non-compliant services to a representation more efficiently managed by applications (that are typically unconcerned with the specific requirements of the control mechanisms) .
  • the Open System Interconnection (OSI) Reference Model defines a layering model offered internationally as a generalized system architecture to affect the designs of connectivity software systems, particularly with respect to host stations desirous of reliable interconnection.
  • OS Open System Interconnection
  • VMCS Virtualized Multimedia Connection System
  • VMCS Virtualized Multimedia Connection System
  • Media control and network interface manufacturers are usually best qualified to supply low- level device/protocol support drivers that comprise the OSI Transport, Network, and Data Link Layers.
  • the VMCS is most efficiently implemented when it leaves this task to them, and instead builds on their work. For specific media control and connectivity tasks, it is often indeterminate as to whether a device, or software component, will comprise the best utensil. Since the OSI Reference Model is functionally specified, a system developer has the flexibility to derive a VMCS subcomponent, or entire OSI Layer, in a way that best supports its design specification, regardless of whether it is build with existing or newly created subcomponents.
  • VCO Client and server software components are developed with an object-oriented programming language, according to a precisely-defined class inheritance and derivation hierarchy.
  • a binary software object is created to encapsulate disparate software components into one functional entity, whose services are available only through structured access of its control elements (member functions and member data) .
  • the strategy of all VMCS designs derived by the application of this methodology, is to encapsulate media control services, connectivity services, and protocol support components, together, in a way that best integrates their properties into an instance of a standardized multimedia connection service to be used by device-independent client applications.
  • Specific protocol support procedures, and media control components are shared by all VMCS implementations; usually they are worth preserving, fine-tuning, and carrying forward to new implementations.
  • VMCS implementations created to support new hardware configurations are most accommodating to this circumstance, to the extent that they are typically minor modifications of a reference VMCS implementation.
  • New VMCS implementations may be designed in one of three modalities.
  • a VMCS can be developed to exploit the services of an existing multimedia connectivity product (hardware and software sub-system layers) manufactured by a third party. Such a project would restructure proprietary controls of the native interface, coercing (virtualizing) them to the structured consistency defined by the VMCS paradigm.
  • a second modality is to create a presentation of the defined VMCS services for a new device set, creating all device control components, VMCS components, and perhaps the devices themselves.
  • designs can, at run-time, invoke a particular presentation of services, derived from the ad hoc association of media control devices with selected connection services, in a way most suitable to producing a desired multimedia connectivity service profile.
  • any component there is no requirement for any component to be implemented entirely in hardware, or entirely in software, per se, so the distinction will not be brought to bear on this discussion.
  • Any VCO Client application can invoke the services of any server, without hesitation, with a guarantee of compatible access. More nebulous is the parity between the quality of services requested by the client, and those provisioned by physical devices encapsulated in the server.
  • the server is the binary software object that encapsulates the media control and connectivity sub-system.
  • VCO Virtual Connection Object
  • VCO Client Virtual Connection Object Client Application
  • Virtual Connection Objects are binary software objects that encapsulate the media control and connectivity components requisite to the implementation of a discreet subset of multimedia connectivity services. They are invoked and adjusted by manipulation of their members. When constructed, a VCO dynamically builds the particular operational context of hardware and software components needed to best implement virtualized multimedia connection services. Destruction of the object deletes this operational context by shutting down all components, turning off devices, and releasing any allocated resources. For the host OS, every implementation of such an object presents members that are identical in syntax, structure, and usage.
  • every VCO is functionally analogous in its control mechanism, but unique in both its name, and the degree to which it is able to realize the full set of VMCS services defined to be represented in every instance thereof; that is each VCO has a unique set of capabilities.
  • Inherent to every VCO is the ability to provide metrics describing the potential quality of services locally available, and the actual quality of services available while connected to a particular remote station.
  • the service profile of the unconnected local station is available prior to device initialization (but after VCO construction) , for casual examination by interested VCO Clients; this profile is referred to as the Local Capabilities.
  • the service profile of a remote station is available while it is connected to the local station, and this profile is referred to as the Remote Capabilities.
  • Connection Capabilities Also available when connected, is the service profile of the connection itself, referred to as the Connection Capabilities. This is the preeminently useful metric, and quantifies the potential quality of interactions between the local and remote stations; precisely, it is the logical intersection of the local and remote capabilities.
  • a real-time reporting mechanism alerts system software objects of changes in the specific states, modalities, and conditions critical to the operation of the encapsulated multimedia connectivity sub-system.
  • the basic unit of information, or indication is referred to as an Event, and each VCO contains a specialized delivery system that can notify software components in the host system when one such event has occurred; a Notifier Object is the mechanism for this delivery.
  • Notifier Objects are triggered by the occurrence of any event type to which they are programmed to respond, and they are used both internally by the VCO, and externally by its clients.
  • VCO is implemented to present the services of one particular configuration of media control/network interface setup that comprises the multimedia connectivity sub-system, and it is likely each significantly different hardware and/or software configuration will require a somewhat different VCO implementation; a VCO is a device-dependent entity.
  • Virtual Connection Object Clients are device-independent, software application programs that invoke VCOs, and manipulate their members to control live information-sharing sessions with remote stations; to that end, they create use-specific logical combinations of currently available audiovisual/data resources to support a defined set of multimedia connectivity tasks that is the embodiment of that particular connectivity application. They are developed in an apriori fashion, according to a concise, multimedia connectivity software control interface specification, the integral implementation of which each VCO must contain. Clients dynamically invoke at least one appropriate VCO, selected (from a library) according to some notion of suitability, and then construct it only when a connectivity session is actually to be initiated.
  • VCO Clients create instances of Notifier Objects, and utilize them as a mechanism to respond (more-or-less instantaneously) to occurrence of divers events to which they have been rendered sensitive.
  • a client software object that contains member functions to receive, and respond appropriately to, these signaled events is referred to as a Notification Receiver Object.
  • Clients may monitor and/or intercept connectivity and device control related occurrences in the encapsulated sub-system, by creating instances of VCO Notifier Objects with specific response profiles. These Notifier Object response profiles may be reconfigured ad hoc; they define the set of specific events that will trigger notifications (when a specified event occurs) to one identified NRO. There can be only one NRO associated with a particular instance of a Notifier Object.
  • any VCO Client can function using any VCO; a VCO Client is a device-independent entity.
  • VMCS Virtualized Multimedia Connection System
  • VISUAL TELEPHONE SYSTEM MODEL The creation of a visual telephone system is the most likely application for a VMCS implementation. Such a system illustrates all of the basic components that comprise the set of media control, network interface, and software control features common to most such solutions now available.
  • the ITU-T describes a generalized model for this type of system in a document referred to as Recommendation H.320.
  • This discussion as related to a VMCS implementation, is best served by a similar treatment of the subject, as it relates to the task of deriving a virtualized model of multimedia connectivity; the VMCS software abstraction represents the functional aspects of the generalized visual telephone, with some notable extensions to its base level utility. It must also be pointed out that a VMCS implementation in no way relies upon the ITU-T recommendations below the level of the signal and indication protocols specified by H.320 — any network or connectivity sub-system could conceivably be adapted as the underlying network transport layer.
  • VMCS virtual reality system
  • Devices and control systems described below should be considered in terms of being functional entities; the potential to support device characteristics with a software emulation module is an implementation alternative that does not alter the basic strategy of VMCS design.
  • input from, or output to a transducer device can be simulated by a data stream read from, or written to backing store.
  • transducers These devices are referred to as transducers in that it is their primary task to convert energy forms from spectral to pulsed electrical, or vise-versa. In practical terms, these devices are the only parts of the system with which the user interacts directly.
  • Audio devices include stationary microphones and related sound detection equipment to input the voice of the user.
  • loudspeakers and headphones are output transducers in a VMCS.
  • Video devices include a camera to input motion-video images of the user. For output, video monitors display motion-video, as do dedicated analog (NTSC/PAL) video displays • Image devices include a camera to input images, as well as scanners to capture high- resolution images. For output, video monitors display images, and in addition, printers that can render images are considered output transducers.
  • Data devices do not convert energy forms, but are essentially "locations" in the system through which data flows, or in which it is stored.
  • Data devices include any backing store (disk) entities, or data ports, such as a communications port.
  • Dedicated data streams, or "socket" interfaces would also qualify as valid VMCS inputs/outputs for binary data.
  • These devices compress data from input transducer devices prior to transmission or storage, or inversely decompress data following transmission from a remote station or retrieval from storage.
  • the process of compression is referred to as encoding, as spectral data is encoded according to an algorithm; decompression is correspondingly referred to decoding.
  • Visual telephones transmit and receive audio and video data in a compressed format so as to enhance the efficiency of the system in its endeavors to exchange large volumes of audio and video data across connections that only support a very limited bandwidth. Storage of images to disk proceeds in the same way to reduce the amount of storage space required.
  • Audio de/compression devices are typically incorporated together with H.221 encoding/decoding hardware used for video processing; audio compression and decompression are often accomplished in software.
  • Video de/compression for live motion-video conferencing is best accomplished with hardware specifically designed for H.221 encoding/decoding; video compression in software (for high quality video) is typically unsatisfactory.
  • Image de/compression for images is typically done in software according to a specialized algorithm (such as JPEG) or transmitted as a simple bitmap.
  • Data de/compression is typically not required, save only when the data object itself has been compressed prior to transmission, as part of a separate operation.
  • Signal multiplexing and demultiplexing operations are typically combined into a single hardware device that combines the audio, video, and related data streams to the single H.221 frame structure (multimedia signal) used in line transmission, and restores them to their constituent data streams upon receipt from a remote station or storage entity.
  • H.221 frame structure multimedia signal
  • This component is typically a hardware device that provides the physical connection between the host station and the network, though software simulations may provide an emulated version of the same.
  • Examples of recommended network types include the following:
  • Multipoint Control Unit This is a specialized device whose functionality is described by ITU-T Recommendations H.243 and H.231. The functionality of this device must be available for an implementation of a VMCS that is fully capable of the entire set of VMCS-defined multipoint control operations.
  • the VMCS is an implementation of this (system control) visual telephone system component, but conceived as a more generalized model suitable for utilization in a broad range of concurrent audiovisual/data sharing applications.
  • the VCO component of the VMCS allows a device-independent connectivity client application to utilize any audiovisual device control system services related to those of the defined visual telephone system.
  • a VMCS session takes the form of a visual telephone call.
  • This interconnection procedure is precisely defined, and permits interoperability between dissimilar stations sporting diverse equipment complements, while retaining compliance to ITU-T Recommendation H.320. It would not be possible to utilize the plethora of potential operating modalities of VMCS systems without a thorough categorization of the set of all those modalities known to be supported by the local station' s equipment configuration. Further, each station participating in a connectivity session (call) must come to an understanding of the modalities supported by its counterpart at the other end of the connection.
  • a request is made to the network for a connection to a remote station. Indication is received at both ends to indicate when this has occurred, and a bi-directional data channel from end to end is opened for use. This data channel carries multiplexed multimedia data between the stations.
  • a device-independent call control mechanism is integral to all VMCS server components (Virtual connection Objects) and operates directly to manage the call states and related operations required to create the connection and data channel.
  • An exchange of device capabilities takes place once the connection is created and frame alignment for the data channel is achieved. It is at this time that the VCO call controller initiates sending its own capabilities to the remote station. It also receives and stores capabilities sent from the remote station. A common base-level audio mode is selected.by the stations according to availability indicated by the exchanged capability sets. In the VMCS, any connection established must engage in the exchange (or emulate the exchange) of a capability set. A minimal bi-directional data channel must also be established in this phase. A capability exchange between stations can be initiated from either end, and may reoccur at any time (while connected) to assert a new ability recently assumed by a station; a device may be turned on or off during the session, thus changes the stations capability profile.
  • VCO Voice over IP
  • additional channels (if used)
  • the VCO supports connections of two separate lines. While network configurations may use six or more separate lines for a call, they are typically bonded together as one call and thus appear as a single line call to system call control. Call setup for additional lines proceeds in an identical fashion to that for the initial channel.
  • Both stations have available a list of the other's capabilities.
  • Each VMCS has associated with it, a specific conference profile parameter that is used to specify the operators preferred operating properties. Examples include a bias towards better video quality, or better audio quality. Coupled with this profile is a set of operating modalities that can be supported by both ends of the connection, and the preference of the remote operator.
  • a device mode negotiation mechanism seeks to algorithmically deduce the most suitable set of device modes for the call by interacting with the remote station to realize them.
  • H.211 This phase refers to the fully established session itself, whereby audio, video, and binary data exchange can take place over existing data channels.
  • the H.320 Recommendation states that visual and audio communications must be active in this phase, though the VMCS allows for idle connections during which time no data exchange takes place; that is audio and video may be disabled, while the connection is still technically active.
  • an indication is sent to the other end to signal termination of the call, in the form of disconnection signals for all lines.
  • Such action by one end initiates the call termination process; the initiating station shuts down all of its data transmission to the remote station.
  • Out-band signaling is typically used for the purpose of disconnection.
  • FIG. 2 depicts an overview of the major components of a Virtualized Multimedia Connection System. There are four significant entities shown: The Virtual Connection Object (VCO) , the Virtual Connection Object Client
  • VCO Client I/O devices
  • I/O devices I/O devices
  • the VCO and the VCO Client are the subject of this disclosure.
  • the I/O devices are connected with a direct physical link to adapter boards in the host system that permit the physical control of the I/O devices via device driver.
  • the only link the VCO has to these devices is through a vendor-specific Media Access Control software layer (or some other device driver)
  • the VCO link to the network interface unit is through a standardized, or vendor-specific network protocol stack.
  • the network protocol stack shown in the drawing is likely some OSI Transport Layer abstraction of a connection service.
  • the VCO combines the services of the data transfer (network) service with associated media transducer devices, so as to reliably offer system command and control of a derived multimedia connectivity service to an application program.
  • data transfer network
  • media transducer devices There are two primary components of any VMCS; they are as follows:
  • VCO Virtual Connection object
  • VCO Client constructs and utilizes the virtualized multimedia connection services hidden away inside the VCO by manipulating its member functions and member data.
  • VCO Client constructs and utilizes the virtualized multimedia connection services hidden away inside the VCO by manipulating its member functions and member data.
  • the objective of the VMCS design is to provide design-level support for a full virtualization of any multimedia connection system, so that device-independent representations of a logical control mechanism could be ported to a wide variety of supporting media control devices and network interface.
  • Client applications designed to utilize VMCS technology are interoperable with every VCO implementation (running under the same operating system) and thus more efficiently distributed, maintained, supported, and redeployed with new device complements.
  • Most important is the ability to bind any network interfaces to any media control interface by the addition of specialized hardware and software layers that combine the functions of these components without affecting its mechanism of control.
  • New and different underlying technologies are well utilized, however the extensible VMCS virtualization paradigm leaves their often peculiar operating procedures fully obscured from the view of application programs.
  • the VCO component of the VMCS incorporates a number of design methodologies whose purpose is to dissociate the control of services, from their physical implementations.
  • the Open System Interconnection (OSI) Reference Model (see B. Hebrawi, OSI Upper Layer Standards and Practices, New York, NY, McGraw-Hill, pp.11-15, 1993) and object-oriented programming languages are primary building blocks in any VMCS.
  • OSI Layering underpins the structure of the VMCS in that the VCO is a logical encapsulation of all of the OSI layers below the presentation layer.
  • the VCO members themselves comprise the OSI Presentation Layer implementation, whereas device- independent routines in the upper VCO layers form a discreet and reusable OSI session layer.
  • Class Structure of the VCO is rigidly defined so as to preserve the largest number of functional source components from modification, and to maintain the design integrity of the VMCS. Class components allow for a definitive specification of distinct, isolated functional units that will not affect their interactions with related components when their internal implementations have been modified to accommodate the operational characteristics of vendor-specific components.
  • Discreet Member Profile preserves the modality of the interface that makes each and every VCO implementation appear the same to clients, and consequently it is most essential to maintain its form to enable interoperability for all clients.
  • VCO Clients assume that the specific member profile of every VCO is identical, thus each can be invoked and utilized without concern for incompatibilities between them.
  • Token-based Job Description Language is a text-token representation of the VCO member functions and their highly structured enumerated arguments. If the structure of the VCO interface is consistent (over time) and reducible to simple string commands, then it is possible to reduce the control of any VCO to a series of text messages in a character stream. From this approach is derived the capacity to remotely control a VCO. User applications are almost entirely isolated from the server component in that each server
  • VCO functions as a command interpreter
  • the VCO client in FIG. 2 is a device-independent layer that is dynamically portable at run-time to other VCO-encapsulated multimedia connectivity sub-systems. All VCO Clients are fully interoperable with all server (VCO) layer components that offer a consistent presentation (OSI Presentation Layer) constructed according to an interface specified in this document. Notification calls from the VCO to the client can occur spontaneously, asynchronous with other system events, and concurrent with notifications emanating from other VCOs invoked by the same client, thus most client modules should be designed to support re-entrancy and mutual-exclusive access to resources.
  • a multithreaded implementation strategy is most efficient to manage the various, often concurrent tasks related to simultaneously maintaining the visual information presented to the user, and supporting the command, control, and real-time monitoring of the multimedia connectivity sub-system.
  • the flow of notifications from the VCO to the client is conducted according to a dynamically configurable interval that a client can optimize according to its particular needs.
  • the client runs at operating system speeds determined by the system scheduler, while low-level device control components in the VCO run at device speeds determined by the network and the devices themselves.
  • VMCS systems share the following characteristics:
  • VCO never miss events, and are never unable to respond to them due to their occurring in time slices not allocated to the application.
  • the VCO notifies its client application that a particular event has occurred, by scheduling the application to run, in response to that event, on a special thread created by the VCO event dispatcher.
  • the application shell is preferably an event- driven graphical user interface (GUI) program written in an object-oriented programming language.
  • GUI graphical user interface
  • a daemon that constructs a VCO, and fields string commands from a hardware or software data port, can serve as a non-interactive VCO client.
  • NRO Notification Receiver Objects
  • Any application class object can contain a specific member function and adjunct function mapping component to direct the VCO to send a notification message to that object upon the occurrence of any set of specified events.
  • the VCO utilizes a three-layer software design that converts the native modalities and properties of some set of physical devices to those that can be accurately described using the parameters specified by the VCO.
  • Underlying the software components are device control components used to physically operate the media control and connectivity sub-systems. These low-level components, and the devices that they control, are typically provided by a third party specializing in their respective technologies.
  • VDI Virtual Device Interface
  • VDI is a reusable shell that is common to all VCO implementations (in a given OS) .
  • VL Virtualization Layer
  • VL Translates logical operations defined in the VDI, to physical implementations (of those most similar) provided by the PDI.
  • the VL is set of mostly reusable routines that are, as needed, partially reimplemented to work with a particular device set in the PDI.
  • VL components may include direct accesses to vendor-specific connectivity protocol stacks and media control components.
  • PDI Physical Device Interface
  • VL Physical Device Interface
  • PDI implementations include direct accesses to vendor-specific connectivity protocol stacks and media control components.
  • the encapsulated devices in a VMCS typically include a network interface unit and a host of related media control devices.
  • the connectivity protocol stack refers to the software layers necessary to provide services defined for the OSI Transport Layer; that is, it must ensure the reliable transfer of messages between end users.
  • Media Access Control must contain drivers enabling physical operation of all devices relegated to VCO control, as previously specified in the section entitled DEFINITIONS.
  • the types of devices likely to be incorporated into the VCO design will be some variation upon those described to manage audio, video, images, and binary data, as specified in the section entitled I/O Equipment.
  • the VDI makes direct use of PDI members to invoke the services of physical devices in its mission to fulfill VCO Client requests for services.
  • the PDI calls functions in the connectivity protocol stack and in the Media Access Control layer.
  • the PDI calls member functions in the VL to provide the mapping, translation, and formatting necessary to coerce the low-level services to resemble those logically specified by the VDI.
  • events generated by the connectivity protocol stack and Media Access Control components are added to a general VCO event queue.
  • a dispatcher in the VCO removes events periodically, synchronous with the operating system scheduler.
  • An event processor in the VL responds to events as they are dispatched to it, invoking other VCO components as needed. Some of these events require that the client application be notified of their occurrence, if the client has so arranged.
  • FIG. 3 depicts a functional block diagram of a VCO, with components partitioned according to the VCO layer where they reside.
  • This section provides a high- level view of the VCO sub-components' functional organization. Subsequent sections pursue a more rigorous examination of the constructs themselves, here only topically considered. It is more important to note that the VDI, VL, and PDI sections labeled "Device/Protocol Controllers" are to be considered as layer-specific overlays of the same groups of components.
  • the groups in the VDI section "Device/Protocol Controllers" illustrate the logical definitions for each of ten distinct functional categories; corresponding groups in the VL and PDI describe the identically functional categories, but at a different level of software abstraction.
  • All components in the VDI section are fully reusable, device- independent software components. Those components in the PDI are vendor-specific and implementation-specific while those in the VL are mostly device-independent, but may require some implementation-specific coding to support wide variations in the underlying device control software.
  • VCO Software components in the VCO are physically divided into very specific object entities, each of which much interact with those adjunct and adjacent.
  • Such entities are the basic functional units of the VCO in that they form discreet functional "parts" that control and/or manage a well-defined set of tasks.
  • the VCO is a single binary software object that encapsulates all of the hardware and software components necessary to implement a fully Virtualized Multimedia Connection System. Virtualization of the services provided by disparate connectivity and media control systems is rendered according to three-layer progressive abstraction strategy that relies upon object-oriented software technology for both its design and implementation.
  • VDI Virtual Device Interface
  • a device-independent, reusable software layer call the Virtual Device Interface (VDI) is created to provide a detailed logical description of a virtualized multimedia connection service. It has as set of public member functions that define its interface to applications and other invoking software modules. Included in this layer are a series of software controllers that are specifically here located (in this logical layer) to embody the larger part of the system' s software implementations in a layer that would be directly propagated to new system implementations, wherefore to facilitate the creation of a highly reliable, reusable, portable modules.
  • VDI Virtual Device Interface
  • VL ⁇ Virtualization Layer
  • a device-dependent layer called the Physical Device Interface (PDI) interfaces directly to the device control sub-system to provide a physical implementation to the service requested by the VDI.
  • the PDI makes use of virtualization functions in the VL to coerce the particular message and data output formats of vendor-specific device control components, to a structured format integral to the VCO design.
  • Audiovisual and binary data streams in the PDI sub-system are represented as Media Control Objects (MCO) .
  • MCO Media Control Objects
  • a list of these objects is maintained by the PDI so as to present the VCO with a pool of available media device and signal resources. According to the media type, and its direction of flow in the system, these MCOs are classified accordingly as either an audio, video, image, or binary data type. They are further characterized as a signal from the remote station, to the remote station, to a local output device, or from a local output device.
  • Operations performed on these objects modify their properties and modalities of interaction, so as to provide the VCO with a logical software switching mechanism for its encapsulated media control device inputs and outputs.
  • the device-independent portion of the VCO is a fully reusable entity that is created once, and then propagated to all VCO implementations. It contains the definition of all the VCO public member functions accessed by clients. These members are collectively referred to as the Software Control Interface (SCI) , which itself includes a number of other VCO control mechanisms whose functionality extends well beyond simple calls to members.
  • SCI Software Control Interface
  • the VCO event notification mechanism and terminal stream I/O manager are integral to the VDI, as are ten controllers related to implementation of the services requested through calls to SCI members.
  • control members contain the member functions used by clients to invoke VCO services. Each relates to a set of public VCO member functions used to access a specific class of well-defined operations.
  • Event Notification Control Members enable the creation, deletion, and configuration of "Notifier Objects" (NO) that may be programmed to trigger on the occurrence of any one of a defined set of VCO events.
  • NO Notifier Objects
  • Terminal Services Control Members enable writes of text messages to VCO terminal output port, and command input through the VCO terminal input port. They also allow the VCO terminal output port to be attached to various output devices.
  • Network Session Control Members enable establishment of a network session with a remote station. They include members to invoke initialization and shutdown of the physical device control sub-system, as well as to place point-to-point and multipoint calls.
  • Audiovisual/Data Signal Switching Members enable signals to/from the remote station, and to/from transducers to be manipulated, combined, and interconnected in various combinations.
  • Binary Data object Exchange Control Members enable buffers, files, and other binary data entities to be transferred between the local and remote stations.
  • System Information Store/Retrieve Control Members enable access to VCO parameter blocks containing information about their encapsulated devices, current call states, protocol states, configuration, and control/monitoring context.
  • Protocol Management Control Members enable direct manipulation of the H.320 protocol whose implementation is integral to the VCO.
  • This notification mechanism is used both internally by the VCO, and by client applications that wish to monitor, or respond to specific system events.
  • a Notifier Object is created, and programmed to respond to any subset of the cataloged VCO events. If the event occurs, a special notification member in a target object is called and passed information regarding the occurrence of the event.
  • the Notification Controller refers to all of the member functions and member data necessary to implement the notification mechanism in each VCO. It contains three distinct parts that operate both independently and together, depending on the notification task at hand.
  • • Notification Triggering Mechanism is responsible for determining exactly when a Notifier Object should trigger, by examining its list of triggering events when one such event occurs. If the Notifier Object is set to trigger on the event, it is activated to initiate its trigger sequence, thereupon informing a specified software object that the event has occurred; it passes parameters during a call to a notification member function.
  • Notifier Object List Manager is responsible for creating, deleting, modifying, and querying a database containing all Notifier Objects for the VCO.
  • Linked Notifier Object List is a doubly linked list of all Notifier Objects for a VCO, and it is maintained by the Notifier Object List Manager.
  • Terminal Stream Controller This terminal stream mechanism is used both internally by the VCO, and by client applications that wish to direct streams of text messages to a configurable set of terminal output port destinations that may include files and system character devices. Alternately, streams of text messages directed to the VCO terminal input port are interpreted as VCO commands and invoke standard VCO operations.
  • This Terminal Stream Controller refers to all of the member functions and member data necessary to implement the terminal stream I/O mechanism in the VCO. It contains three distinct parts that operate both independently and together, depending on the terminal operation.
  • Terminal stream I/O Device controller is responsible for processing text messages sent to the VCO terminal input and output ports, in addition to managing the list of I/O devices.
  • Text command Encoder/Decoder is comprised of two separate components: the encoder portion converts calls to the SCI into text-token string command representation used for remote VCO control, and the decoder parses an input stream of such text-token string commands and makes calls to the SCI as indicated by their format.
  • Linked Terminal Stream I/O Device List is a doubly linked list of all terminal I/O device objects that describe the identity and status for all character stream files, and devices to which text messages sent to the VCO terminal output port are written.
  • This group of controllers serves to support the implementation of the logical operations invoked by calls to SCI member functions, as well as providing implementation of operations necessary to the establishment and maintenance of a connectivity session.
  • the implementations of services in this VDI component must be only that portion of the given operations that can be supported in a fully device-independent manner.
  • Object Construction refers to all procedures and data structures involved in the construction of the VCO, including initialization of all object software components that do not control devices. Provides direct support for operations invoked by construction of the VCO by a client application.
  • Object Destruction refers to all procedures and data structures involved in the destruction of the VCO, by its client application, including shutdown of all object software components.
  • Configuration/System Setup refers to all procedures and data structures involved in configuring the VCO according to its profile, previously saved on a backing store device. Also includes support for specialized audio, video, image, and binary data equipment setup utilities. Provides direct support for operations defined for the SCI Configuration/System Setup Members.
  • Binary Data Object Exchange refers to all procedures and data structures involved in the transfer of named binary objects, such as system files, to and from the remote station. Provides direct support for operations defined for the SCI Binary Data Object
  • Network Call State refers to all procedures and data structures to support a call controller compliant with that described in the section entitled Visual Call Progression, and consequently function to establish and maintain the connectivity session with the remote station. Provides direct support operations for internal VCO connectivity sessions.
  • System Information refers to all procedures and data structures involved with storage, retrieval, and maintenance of the various VCO parameter blocks, and their associated tables and lists. Provides direct support for operations defined for the SCI System Information Store/Retrieve Control Members.
  • Capability Exchange refers to all procedures and data structures needed to support a structured exchange and comparison of device capabilities, as described in the section entitled Visual Call Progression. Provides direct support operations for internal VCO connectivity sessions.
  • System Exception refers to all procedures and data structures involved in handling fatal errors that may occur in the VCO. Provides direct support for operations defined by SCI VCO Settings Members not shown in the drawing.
  • Media Control Object Access refers to all procedures and data structures involved in accessing the object-based device control system implemented in the PDI. Provides direct support for operations defined for the
  • Protocol Mode Negotiation refers to all procedures and data structures involved with establishing a common set of parameters between the local and remote stations as described in the section entitled Visual Call Progression.
  • This also lies support for operations that will affect a specific conference profile as specified by the VCO' s configuration parameters (or as set by the client application) ; includes support for operations essential to internal VCO network session implementation.
  • This layer Contains all procedures and data structures used to convert vendor-specific formats to those defined by the VCO. This layer also contains a number of controllers that are not always able to be implemented in a device- independent fashion, as some cognizance of vendor- specific peculiarities is frequently necessary to create a functional virtualization service layer.
  • the queue acts a storage repository to record both the progress of operations carried forth by the VCO, as well as reports of new states and modes assumed by its underlying real-time device control sub- system.
  • devices and VCO controllers perform a mutually exclusive addition of events to an infinite sized event queue, in real time.
  • a dispatcher removes them at a regular periodic rate, and disseminates them to an event processor, and to client applications desirous of knowing that one (of a particular set of events) has occurred .
  • Event Processor provides a structured mechanism for the VCO to respond appropriately to events generated by its device control sub-system. It maintains a number of feedback loops and procedures that are critical to enabling the VCO to adequately monitor and control its connectivity session without assistance or monitoring by the client application.
  • Periodic Event Dispatcher checks the VCO event queue at regular intervals to determine if it contains any events. If there is at least one event in the queue, the dispatcher removes it (a single event) and invokes the Notification Controller to trigger any Notifier Objects that may be configured to respond to that event.
  • Infinite FIFO Event Queue provides a sequentially-ordered cache for all events emanating from the device control sub-system or for events generated by software components within the VCO. It operates according to the first-in-first-out algorithm so that the original sequence at which the events occurred, is preserved through the event processing stage. Since the queue is constructed as a linked list of event records, it is capable of growing to a size limited only by the availability of system memory; thus events are never lost in any VMCS.
  • Critical Section Handler provides a mechanism to add events to the event queue in a mutually exclusive fashion. Also, various VCO operations that could result in resource contentions and deadlocks can utilize this component.
  • VCO controllers Assigns textual labels to VCO events, states, operations, and a host of other functional entities, in a way that describes them using plain language.
  • the role of this controller is to enable VCO components to report the status of their operations in a readily-understandable format, rather than by the encoded strategies typically employed in computer systems.
  • VCO controllers derive descriptive text messages from the labeling facilities offered here, and then send them to the VCO terminal output port.
  • Event Labeler Mechanism provides functions to return string labels for various VCO events of all types. In addition to returning text labels for the standard VCO notification events, this controller supports labeling for the generalized class of VCO events that includes all of the enumerated states, constants, modes, and string tokens representations of the arguments used by the Media Control Object Device Control Mechanism.
  • the command encoder/decoder mechanisms also rely on the services offered by this component.
  • Object Component Labeling Mechanism provides labels for VCO objects and constructs that are used to report the current location of execution, or processing, in terms of the names of actual VCO components invoked.
  • VCO Voice over IP
  • controllers Contains the names of the VCO classes, controllers, an mechanisms that are used to formulate precise reports for debugging, diagnostics, and general troubleshooting of VCO components.
  • Event and Object String Label Database contains tables of text tokens and string messages accessed by the event/object component labeler mechanisms.
  • the Device/Protocol Controllers for the VL and PDI layers represent the contribution of each layer in producing the virtualized multimedia connection services logically defined in the corresponding VDI controller (that occupies the same physical location on the drawing relative to the group of Device/Protocol Controllers) .
  • This group of VL controllers serves to support the implementation of the device-independent procedures and operations supported, at their highest level, by the corresponding controllers in the VDI .
  • the VL controllers are specifically Virtualization Layer components, they serve to support the implementation of VDI controllers by providing any necessary coercion of data format, command syntax, or interface method, from a vendor-specific modality, to that defined for the VDI.
  • the VL supplies a standardized function supporting a like standardized VDI function, but the embodiment of that in the VL is fully intended to be implementation-dependent.
  • Configuration Information Access provides any necessary mapping of configuration information from/to the format used by the backing store method. Typically reads from/writes to a string-based initialization file and translates the string token format to that used by the VCO configuration parameters .
  • Data Exchange Syntax Mapping provides mapping of file and record formats to that utilized by the connectivity protocol stack to that used by the host operating system. Examples include conversion of buffers and files to/from packet formats.
  • Call Event Mapping provides translation of vendor-specific connectivity protocol stack representation of call and line states to those used by the VCO call controller.
  • System Information Mapping provides translation of various vendor-specific representations of system information to/from those used by the VCO, and enables translation of Media Control Object Device
  • Control operations to H.221 device modes include call destinations, and media device states.
  • Capability Mapping provides translation of local and remote station H.221 capabilities emanating from the network protocol stack to those used by the VCO. Includes mapping of H.221 capabilities to Media Control Object capabilities. • system Exception Mapping provides translation of various fatal errors from vendor-specific components to standardized VCO exceptions.
  • Protocol Mode Mapping provides mapping of H.221 bit-rate allocation signal (BAS Code) indications used by the connectivity protocol stack (or emulated) to the device-independent representation used by the VCO.
  • BAS Code bit-rate allocation signal
  • Physical Device Interface Contains all procedures and data structures used to interface device drivers and operating system resources directly. All implementations of functions are assumed to be device-dependent, and it is the principle objective of this layer to locate some form of physical, or emulated support to realize those operations logically defined in the VDI. If the PDI cannot provide, or even emulate, a service specified by the VDI, then it must return a result code indicating that it is not capable of doing so.
  • the Device/Protocol Controllers for the PDI layer represent the contribution of this layer in providing the physical interface component of the virtualized multimedia connection services logically defined in the corresponding VDI controller.
  • This group of PDI controllers serves as the physical implementation of the corresponding operations managed by controllers in the VL.
  • the PDI controllers are specifically physical layer components, they support the implementation of VDI controllers by directly accessing device drivers and vendor-specific library software components provided by third party OEMs; in the most efficient designs, the PDI may be implemented as an actual device driver, directly controlling hardware.
  • OEM Support Libraries and Drivers provide specialized functions, such as image processing, digital signal processing, data port interface, and system diagnostics, that are vendor-specific and usually hardware-specific.
  • Configuration Information Backing Store is the physical device that stores the VCO configuration information. Usually a file on disk and/or some form of non-volatile memory device.
  • Connectivity Protocol Stack is the actual interface to the network, and includes all associated hardware and software components.
  • the network service is presented to the VCO session components and transducers at the level of the OSI Transport Layer, whose responsibility it is to ensure reliable transfer of messages between end users.
  • Network and Data Link layers must be available, in some form, below the Transport Layer, and a physical or emulated network interface unit must be present and detectable.
  • Media Access Control provides physical device control mechanisms for input and output transducer devices in the system. This driver complement is used directly to implement the PDI's defined set of device control interface functions used directly by the VDI, as well as by the Media Control Object Device Control Mechanism.
  • Device Capability List resides in the PDI as the master list of the all of the VCO capabilities. It is stored as an array of device-independent capability constants that reflect the range of H.320 (H.221) capability BAS codes.
  • Device Mode List resides in the PDI as the master list of the all of all possible device modes for any H.320 compliant station. It is stored as an array of device-independent device mode constants that reflect the range of H.320 (H.221) mode command BAS codes.
  • MCO Media Control Objects
  • VCO SOFTWARE ARCHITECTURE System Dynamics It is useful to consider the VCO as a mechanical device, much like a spring-driven mechanical clock movement.
  • Each VCO is a self-contained machine of interlocking parts, with a system timer interrupt advancing its works by the increment and released in balanced measures that bring stability and smoothness of operation to the system's "top” end.
  • the VCO's analogous "unwinding" takes place with the literal precision of a clock's escapement mechanism, in that the system timer serves as the regulatory entity releasing a steady pulse of queue-stored activities from the device control subsystems, to a client application.
  • a Virtualized Multimedia Connection System presents not only an idealized control mechanism to applications, but also idealizes the rate and content of the system's responses to these controls, without ever losing a system event, state change, mode change, exception or interrupt request.
  • the overall VCO design is consistent with that of multi-threaded, queue-based device driver designs that account for a significant portion of the dramatic gains in reliability and performance seen in the use of 32-bit, multi-tasking operating systems such as IBM's Operating System/2 (see H.M. Deitel, M.S. Kogan, The Design of OS/2, Reading, Massachuetts, Addison-Wesley, 1992).
  • FIG. 4 depicts an a detailed diagram of the major components and control flows of the Virtual Connection Object software architecture.
  • the Device/Protocol Controllers shown are the same as those shown in FIG. 3, but the purpose in this drawing is to illustrate the direction of control flow through them, rather than to describe what they are.
  • This discussion will examine the VCO in terms of its specific software mechanisms. To clearly show the functionality of individual VCO components in the two-dimensional drawing, it is necessary to alter their exact locations in the layering model from a perfect vertical orientation, to one more suited to revealing component interactive pathways. Summary of VCO Software Architecture
  • the software architecture of the VCO is can be described best in terms of two major functions: (a) controlling the multimedia connectivity sub-system it encapsulates, and (b) responding to events emanating from it. What ensues is a brief overview of outstanding features that characterize the dynamics of the VCO software model.
  • the Software Control Interface contains public member functions that enable a client application to access a consistent and logically-defined multimedia connectivity service to create a live audiovisual connections to a remote station. Calls to these members invoke the various
  • Device/Protocol Controller services in the various VCO layers until some physical operation is eventually performed, the result of which is translated to logical, standardized result prior to being returned to the caller.
  • Each VCO contains a general repository for all system information that is continuously updated to reflect the current states of all controllers and devices.
  • Every VCO has standard input and output terminal ports that function much like the standard input and output devices in operating system shell console devices. All text message sent to the VCO terminal output port are written to a list of terminal I/O devices maintained by a Terminal Stream Controller. This controller also accepts text commands written to the terminal input port and decodes them, translating them to SCI calls.
  • An infinite FIFO event queue accepts the addition of events asynchronously, in real-time, by device control software, and by software components in the VCO that generate their own particular events.
  • An Event Dispatcher runs synchronous with the operating system scheduler (does not preempt the regularly scheduled time slices) to remove events from the queue at a constant, periodic interval and disperse them to a
  • the Notification Controller examines the dispatched event, dispensing notification information about the event via Notifier Objects that send the indication, and all associated information, to an event processor in the VCO (if the event is from a device) , or to a client application object, depending on the Notifier Object's configured destination object.
  • the VCO Device Event Processor invokes procedures to respond appropriately to events emanating from the device control sub-system, so as to maintain a connectivity session with the connected remote station. Call control, capability exchange, and various protocol operations are driven by the event processor, as is the issuance of text messages, describing all system activities, to the terminal output port. Most network events that require attention from the application in similar multimedia connection systems do not require such attention by VCO Clients; specific intelligences in the Device Event Processor component better direct them to invocation of specialized internal procedures more suitable to such tasks, by their very designs — feedback loops often found in the application layer, reside in the VCO proper, alleviating the application developer from implementing sensitive protocol-specific modules.
  • VCOs can link together across a connection to control or monitor the activities of the other station.
  • This concept referred to as attachment, utilizes a bi-directional text message stream to enable interconnected VCOs to share commands and events.
  • VCOs can link together across a connection to control or monitor the activities of the other station.
  • This concept referred to as attachment, utilizes a bi-directional text message stream to enable interconnected VCOs to share commands and events.
  • VCOs calls to member functions in the SCI of one, are encoded into text commands by the Command Message Encoder, and transmitted to the other station.
  • the Command Message Decoder translates the text commands back to SCI calls.
  • events queued at one station, as well as results of operations are encoded by the Event Message Encoder, and transmitted to the other station.
  • the Event Message Decoder translates the text event messages back to events and adds them to the event queue, where they are dispatched along with a station identifier.
  • the Software Control Interface consists of the VCO's public member functions and protected data that allow client applications to control the VCO. Any request for service using the SCI must pass a number rigorous examinations designed to reject any possibility of damaging the encapsulated sub-system.
  • a client attempt to access a VCO member function results in an immediate set of verifications to determine if VCO is available for use, and if so, whether the context of the request is valid. For example, most operations require that the device control sub-system first be fully initialized. Arguments are checked for validity, and a text message describing the request is sent to the VCO terminal output port for tracing and monitoring purposes. If all conditions have been met, execution continues to the next level; progressing typically to a further request to the PDI. Rejected requests are turned away abruptly, but the client is compensated for his diligence, with a fair accounting of the dismissal; every operation returns a concise result code.
  • Event Noti ication Control Members make calls to the Notifier Object List Manager to create, delete, and configure, and trigger Notifier Objects in the Linked Notifier Object List. Calls to trigger notification invoke the Notification Triggering Mechanism directly.
  • Terminal Service Control Members make calls to the Terminal Stream I/O Device Controller to add and remote devices from the Linked Terminal Stream I/O Device List. Calls to send text messages to the terminal output port are made through this object, as are calls to send text command message to the terminal input port for decoding and execution.
  • Protocol Management Control Members make calls to the PDI to directly set H.230 device modes, send capabilities to the remote station, and perform other protocol related tasks .
  • the VCO terminal service has two main pathways: into the VCO through the terminal input port, and out of the VCO through the terminal output port. Alternately, when the terminal ports are considered as standard input and standard output devices for the VCO, it is sensible to view the two modalities as a stream "to the terminal" and "from the terminal".
  • Output Streams to VCO Terminal originate from the VCO itself, or from client applications. Messages "to the terminal” are directed to the terminal output port and dispersed, via write operations, to output devices (attached to the terminal output port). Summary, "To terminal” is synonymous with “ to text output devices.”
  • Input Streams from VCO Terminal originate from outside the VCO, typically from a dumb terminal or client application wishing to control it with text commands. SCI calls sending text messages as if "from the terminal” are directed to the terminal input port and interpreted as input text command messages, as if input from a keyboard. Summarily, "From terminal” is synonymous with
  • Terminal Stream I/O Device Controller maintains a linked object list of output device objects to which the text message sent to the terminal output port are written. All text messages sent to the terminal output port are written to every device cataloged by the linked object list.
  • Output devices include system files, character devices, and Notifier Objects created for the transmission of text message to objects.
  • System information is fully protected from direct external access the VCO, though all internal components can access it directly. Clients must us specific member functions to get a copy of the data, and use other members to affect changes to it through structured operations. Internally, all system parameters are fully accessible to all components derived from the VDI. • Configuration Parameters store the current copy of VCO configuration and system setup information that is read from backing store at VCO construction time. Contains information about the network service available, and all system defaults. The parameters can be modified and written back to backing store at any time.
  • Device Parameters store all settings and parameters related to the audio/video/image/data devices installed in the sub-system, and retain handles to the current source, destination, input, and output signals affected by the Media Control Object Device Mechanism.
  • Control Prameters stores all information related to maintaining the remote station control mechanism for any attached station.
  • Monitor Parameters store all information related to maintaining the monitoring access for any attached station.
  • Notification Mechanism conveys an indication that a particular event has occurred by activating, or "triggering", a notification entity referred to as a Notifier.
  • Notifier Objects Maintained in a list internal to the VCO, Notifier Objects are created specifically to call a member function of some appropriately enhanced class object, somewhere in the system (within or without the address space of the VCO) when triggered.
  • Notifier Objects in the list are systematically examined, and potentially triggered, according to a specialized modality of governance that considers the relationship of the outstanding event type (among other parameters) to the triggering profile of the Notifier Object itself.
  • Notifier Objects NO
  • Each NO is an instance of a class object that may be created by a VCO client, or the VCO itself, and configured to "trigger" in response to the occurrence of any one of a set of VCO events.
  • Each NO is associated with a specified Notification Receiver Object (NRO) to which the trigger response is directed.
  • NRO Notification Receiver Object
  • Passed to the NRO is an event identifier, and a number of qualifying arguments that describe the context of the event's occurrence.
  • There are two mutually exclusive modalities for any NO they can be configured to respond to any event, or configured to respond only to events emanating from VCO-encapsulated devices.
  • the Notifier Object list handler This component adds to, removes from, and maintains the integrity of the Notifier list. It also provides members for configuring Notifier Objects with new trigger response profiles, as well as to allow them to be enabled, disabled, and examined for statistical information.
  • the notification mechanism i ⁇ supported by a component that manages the list of all active Notifier Objects, and a triggering mechanism that determines as to whether or not an individual Notifier should trigger, based upon the occurrence of an event to which it is configured to respond.
  • Notifier Objects can be configured to respond to events that emanate from the device only, so as to direct their trigger response to the VCO Device Event Processor.
  • the VCO uses Notifier Objects internally to create a direct pathway for device events (added to the VCO queue by the device) , to be processed in the VCO Device Event Processor exclusively.
  • This distinction serves to prevent an infinite loop that would result if the VCO processes an event from a device, and then reissues (requeues it) it so that client applications can be subsequently notified of the same event — the same event would be dispatched back to the event processor again and again if reinterpreted as another occurrence of the same device event.
  • Notifier Objects configured to trigger on events directly from devices will only trigger on events directly from devices. When the event processor reissues the event from the device, it marks it to indicate it is not directly from a device, and it can no longer trigger the Notifier that would send it to the Device Event Processor.
  • VCO Client applications may request notification of a combination of VCO events by creating a Notifier Object and configuring it to trigger when any single event in the combination actually occurs.
  • the Notifier Object conveys event notification to an application object set to that purpose.
  • the object that receives notification is referred to as a Notification Receiver Object (NRO) .
  • Notification Receiver Objects (NRO) receive function calls from an entity in the VCO that is created specifically to direct notification of the occurrence of an event to them.
  • a class object can serve as an NRO if it contains a special Notification Receiver Member and an attendant thunk.
  • the thunk is a globally accessible function that is created to receive notification from the VCO and redirect that notification to the NRO's
  • a VCO can deliver a notification message to a class object which can then directly access other class members and member data that would not be available if the notification was to a non-member function i.e. had to access class members with a special class pointer.
  • Notifier Triggering Profiles refer to the set of events to which the Notifier Object is configured to respond. Notifier Objects are "triggered" to notify their associated NRO when one of these configured events occurs.
  • Event Handling Mechanism The event handling mechanism consists of three concurrent, but distinctly separate processes. From the perspective of any single event, these processes occur in a serial fashion. First, events are added to the trail of the VCO event queue by various VCO components. Next, a concurrently executing event dispatching process periodically removes an event from the queue. Finally, the event dispatcher sends the removed event to the Notification Controller where it triggers Notifier Objects configured to respond to events of this particular type. If the event is a device event, and the Notifier is configured to respond to device events, then its Notification Receiver Object receives notification that the event has occurred. If the event removed by the dispatcher is some derived event, it may trigger notifications to client application, or any other Notification Receiver Objects targeted by a Notifier responding to that event.
  • Device Events These events are generated directly by a device in the encapsulated sub-system; a situation that potentially requires some kind of immediate responsive action. They are the primary responses from VCO devices and emanate from network and media control driver software components.
  • the task of event processing includes the handling of both Device Events and Derived Events.
  • Device events can only trigger Notifier Objects configured to respond to device events, thereby enabling a particular Notifier Object to function as a dedicated device event notifier.
  • Events entering the Device Event Processor are typically line state changes, device mode changes, and indications from the remote station. These events drive protocol and session management routines during processing, which in turn generates derived events such as the call state changes and Media Control Object Device Control parameter changes.
  • derived events are queued for subsequent dispatching to client applications; these secondary occurrences are treated differently from primary events in that they will not be handled by the Device Event Processor.
  • Dispatching of events occurs periodically at a programmed rate that may be adjusted dynamically at run- time. Typically, dispatching five events per second is sufficient to present the client application with a manageable stream of events.
  • the event dispatcher is driven by a system timer interrupt. If the queue is available for mutually exclusive access, it is checked to determine if there are events in it. If there is at least one event in the queue, one event is removed in a critical section, and the queue is released to the system. If mutually exclusive access is not immediat €sly available, or there are no events in the queue, the dispatcher yields. Otherwise, the removed event is next presented to the Notification Controller where any Notifier Objects in its list, sensitive to the event, are triggered so as to disperse the event throughout the systen -
  • VCO exception handling mechanism is not shown in FIG. 4. Exceptions in the VCO are conditions that are deemed fatal errors from which the system cannot recover vithout risking a system crash.
  • the underlying design principle to VCO exception handling is that system crashes result most often from continued use of a destabilized system component, from attempts to recover from destabilized conditions, and from the failure of a destabilized system to acknowledge its "time-bomb" status.
  • VCO exceptions generate reports, and a subsequent disabling of the VCO. Neither the VCO, nor its concomitant support software, is accessed until the VCO is destructed.
  • VCO exception handling modes can be invoked incrementally by specifying any combination of the following modality flags. These modalities are additive, and affect the way in which reporting of the exception is handled.
  • Debug modality flag if set, specifies that detailed debugging information (in a message box) will be displayed at the time of exception. This mode is intended for use during system development where proprietary information will be displayed.
  • User modality flag if set, specifies that general "user" information (in a message box) will be displayed at the time of exception.
  • This mode is intended for use in the field after the product is released.
  • Notify modality flag if set, specifies that the exception will generate an exception event and trigger Notifier Objects prior to disabling of VCO.
  • Abort modality flag if set, specifies that the exception will abort all VCO operations, after reporting the exception, and disable the VCO.
  • This mechanism provides function calls that convert indexes to strings. It relies on a collection of string tables, whose string element positions reflect the value of the indexes.
  • the string tables can be loaded from resource files that contain text in the appropriate language.
  • Retrieving a text label to describe a VCO event is accomplished by presenting a VCO event identifier, result code, or standard enumerated constant to the appropriate member function.
  • a pointer to a static copy of a null terminated label is returned, and is typically used to formulate messages for terminal output, and by applications to display states, modes, and operations taking place in the VCO.
  • Retrieving a text label for a VCO software object is accomplished by presenting a pointer to the object to a member function.
  • a pointer to a static copy of a null terminated label is returned, and is typically used to formulate messages for debugger and trace window output. Used specifically for debugging, diagnostics, and troubleshooting.
  • Event and Object String Label Database A memory resident database in the VCO contains tables of string records for all of the VCO enumerated constants, and the VCO command set. Reference databases containing object pointers and labels are created at VCO construction time.
  • this device control method is intended for full implementation as a graphical desktop media control system, supporting a drag and drop signal switching model.
  • Each object representing a specific signal type, has a standardized set of properties, and well-defined modes of interaction.
  • the physical structure of the Media Control Object Device Control Mechanism represents each signal as a software class object, and all signals currently available in the system as a linked list of such objects in the VCO DEVICEPARAM structure.
  • Media Control Objects are created and deleted as signals become available, or unavailable, depending on connection state and device availability.
  • VCO signals are identified according to their type and direction. The possible types of signals include audio, video, image, and binary data.
  • the possible directions include input from the remote station, output to the remote station, input from a local transducer, and output to a local transducer.
  • Member data in each Media Control Object describe the current states and modes related to the signal.
  • Member data in each Media Control Object describe the current states and modes related to the signal, and member functions invoke physical operations in their host devices.
  • the divers Device/Protocol Controllers each have emulation components, shown in FIG. 4, that reside in either/both the VL and the PDI.
  • the objective in any VCO emulation mode is to enable to the VDI to operate fully, without the ability of it, or any client applications, to differentiate between operation with actual device support, or emulation of it.
  • Attachment of a remote station to the local station enables the local station to monitor its event stream and control its operations.
  • the basic mechanism of attachment has been discussed in general, however the specifics of this interaction deserve more attention.
  • an attachment mechanism sufficient to monitor a remote station requires a cross-linking of the output of one station's event encoder to the other station's event decoder.
  • To establish control of a remote station there must, in addition, be a cross-linking of the output of one station's command encoder to the other station's command decoder.
  • Monitoring context refers to the station that is the source of the current event stream emanating from the local VCO's dispatcher. Any combination of the monitoring modes can be in effect once attached.
  • a VCO that is not attached to a remote station can only monitor local events. The remote station must grant permission to be monitored by the local station by indicating so in its monitor parameters. VCO monitoring modes are described as follows:
  • • Local monitoring mode affects the target VCO to dispatch and process events local to it.
  • Remote monitoring mode affects the target VCO to dispatch and process events emanating from the remote station to which it is currently attached.
  • • Array monitoring mode affects the target VCO to dispatch and process events from a specified array of remote stations.
  • Control context refer to the station that is controlled by calls to local VCO SCI member functions.
  • VCO control modes from the perspective of the local station, and when set in the physical local station VCO, are described as follows:
  • Master control mode enables the local station to control a remote station to which it is currently attached.
  • Slave control mode enables the local station to be controlled by a remote station to which it is currently attached.
  • Peer control mode enables both the local and remote stations (attached to each other) to control themselves, but not each other. This is the standard operating mode for most interconnections between stations.
  • FIG. 5 depicts a VCO client application; arrows highlight the flow of function calls through its various components.
  • the diagram shows a full implementation of a VCO client application that best describes the VCO Client application concept. All of the components shown are not necessary to establish a minimally-functional multimedia connectivity session with a remote station, but are needed to make full use of the entire VCO feature complement.
  • the client application specification unlike that for the VCO itself, is represented in a generalized fashion, and strict compliance is not necessary to achieve the benefits advocated by the VMCS; a broad range of effective application designs may be derived from this prototypical VCO Client application model illustrated.
  • a client application selects a class library supporting an implementation of class VCO. Constructing class VCO, it makes calls to the Software Control Interface for the newly invoked VCO to establish a connectivity session with a remote host.
  • the client has a number of components that it uses to manage this session:
  • the Device-independent Connectivity Application Shell provides the user-interface and basic task management for the client application. This component displays session status information, and initiates the milestones of its inception and termination. This component is the logical control mechanism for all VCO operations. If it is to construct a VCO directly, it must be created with the same object-oriented language as the
  • VCO itself. While it is preferred that the client is a GUI application to best present the VCO control system to the user, it can be as simple as a daemon running in background, that processes string commands from a data stream directed to it.
  • Notification Receiver Objects receive notifications from the VCO that various VCO events have occurred.
  • Client applications typically create a Notifier Object to receive text streams from the VCO terminal output port.
  • At least one other Notifier Object should be created to receive indication of the three major classes of new local station modes (new H.221 transmit modes), new remote station modes (new H.221 receive modes) , and new call state changes (new call and line states) — one Notifier Object can be configured to respond to all three of these event types.
  • Event and Text Processing Components are specifically designed to analyze and/or respond to text and event information emanating from the VCO.
  • Text processing of the terminal output stream can take the form of graphical display in a trace window that has the facility to enable its viewer to move forward and backward through the output messages, in order to view the progress of the session. Trace information could also be saved to a log file to permit later analysis of session activity.
  • trace output can be analyzed by a debugger, or H.320 protocol analyzer. New remote station modes are usually routed to the Station Profile Controller for processing and interpretation.
  • the Station Profile Controller examines new modes set by the remote station, and using a Station Profiler, compares them to a database, to determine the remote station's manufacturer or type. Once identified, the remote station's profile is elicited from that same database, and its non-standard feature set made available to the application. Non-standard features include advanced camera control operations, proprietary VCO features, data exchange protocols, and application sharing features. Non-standard capabilities are also examined to determine the level of functionality, of which the remote station is capable.
  • the Non- standard H.221 Mode Mapper provides a virtualized representation of the remote- station's available special features, and presents them to the application shell in a manner conducive to their mapping to local station physical controls.
  • a stream of events flows from the VCO to the client.
  • notifications are discreet entities that are independent of any operating system or GUI event processing/queuing schemes, and resultantly more time-responsive; so much more responsive than adding events added to the application event queue, that notifications can preempt drawing operations by the GUI, but without inordinately starving the GUI of its time slices.
  • the notification is usually implemented to run on a separate thread, concurrent with those drawing on the display, and thus connectivity events can be processed concurrent with drawing, rather than subsequent to a GUI operation in progress.
  • the VCO Client notification system permits the design of high- performance, multithreaded applications that can process and respond to connectivity events with responsiveness that (in the context of a user interface) approximates real-time. Notification to VCO client applications, proceeds with rapidity such as is required for controlling both local peripheral devices, and the peripheral control features of remote stations, while concurrently maintaining a responsive graphical desktop display.
  • any class object can be configured to receive calls from a Notifier Object when any one of a subset of events occurs.
  • a member function in the object is declared for this purpose by the creation of a thunk.
  • thunks are created to redirect calls from the Notifier Object in the VCO, from a public global non-member function in the application (called by the Notifier Object) , to the particular class object instance and member function intended exclusively for the purpose of notification.
  • the receipt of notifications by the application often results in the application's issuance of calls back to the VCC to correct, compensate, or respond to the condition.
  • Many event handlers in the application function as feedback loops; upon notification, they immediately invoke VCO functions in response. Logical assistance by the client application is unnecessary once appropriate response routines have been setup - the VCO manages the multimedia connectivity system automatically.
  • the primary objective of the client station profiling mechanism is to first identify the remote station as one represented in a local database of potential remote station types. Once a descriptor for the remote station is found in the database, the client can now determine any non-standard device modes (that invoke special features) supported by that remote station. Further, a list of corresponding non-standard capabilities is also stored in the descriptor, such that the local station can make a positive predetermination as to whether the special feature associated with the remote station type, is actually available for use. Nonstandard modes supported by the remote station can then be mapped to leeai-controls so that the VCO client becomes capable of a degree of station control typically only possible by interconnection between two stations from the same manufacturer - VCO stations can fully understand the particular proprietary non-standard features they support. The VCO client is capable of an extraordinary degree of compatibility with an unlimited range of remote stations. Station Profile Controller
  • This software controller contains three components that provide the functions necessary to implement a transparent mapping between local station controls, and remote station non-standard features.
  • Local station features beyond those represented in the VCO control mechanism have specific sequences of device modes that must be set to activate them.
  • Non-standard modes on the remote station work the same way, except the mode sequences are different.
  • Station Profile Controller enable the client to associate any local or remote station non-standard feature (mode sequence) with a control on the local station.
  • mode sequence any local or remote station non-standard feature
  • the Station Profile Controller offers a symbolic, device- independent representation of local and remote station non-standard features, and beyond that, the ability to associate one local with one remote.
  • An example of this association is in order: consider a surveillance system that maintains two specialized features: 1) It allows an operator to remotely select the current camera from a variety of available input cameras. 2) It displays an "X" cursor on the operator station video image, pinpointing the exact center of focus for its currently selected camera, and the remote station will move its selected camera to correspond to any mouse- invoked change in the cursor location on the operation display, therein allowing the remote operator to survey the area with simple mouse movements.
  • the remote station will continuously reflect the camera's actual physical position by rendering a cursor on the operator station visual display. There is no H.320 representation of these operations, beyond support for sharing a cursor position; the selection of a remote camera is a simple operation, but the second feature is one complex, proprietary, and in need of specialized library support features
  • the cursor movement mechanism requires a complex feedback mechanism to move and display the "X" cursor as intended by the remote station's programming.
  • the operator station determines that the remote station is of this particular monitoring station type, and locates a descriptor in its database that describes it.
  • the modes to select the camera are represented symbolically to the VCO client, and mapped to local station controls.
  • the sequence of mode-setting operations necessary to the selection of the remote station camera is invoked by offering the symbolic representation of the operation to the Station Profile Controller.
  • incoming cursor position modes are mapped to a virtualized definition of cursor movement,, and passed to functions in a library of supporting routines, developed specifically to display it as required.
  • Local station mouse movements over the video display region, on the operator station's bitmapped display, are mapped to cursor movements sent to the remote station via a similar mechanism used for camera selection. It is the VCO's notification mechanism that enables the concurrent processing of device modes, sending and receiving them to/from the remote station, at the system level of the GUI application, without interference from other application activities.
  • This component is responsible for identifying the remote station. Upon connection, it sets sequences of modes, and conducts whatever query is necessary to determine its manufacturer. To this end, it compares modes sent back from the remote station to stored sequences in the database.
  • This component maps non-standard local modes, to specific features, by assigning mode sequences (and function calls) to an intermediate symbolic representation, which is then used in a feature mapping table.
  • mode sequences and function calls
  • This mapping is performed for non-standard remote station modes, however the mode sequences are preprogrammed, stored in a database descriptor, and selected according to the identity of the remote station.
  • This component manages the capabilities associated with the non-standard modes handled by the non-standard mode mapper. It provides a mechanism to determine if non-standard modes are available on the remote station, as well as mechanism to inform the remote station that the local station is capable of handling its non-standard modes.
  • VCO ACCESS METHODS Derived from this design are several methods for VCO Clients to access the services of the VCO, so as to make use of the VCO as an independent multimedia connectivity operating system that supports client sessions.
  • FIG. 8 depicts the various methods used by VCO Clients to access service of a particular VCO.
  • the controlling system is a "STATION” (connected across the network) , then it must establish a text data stream (in-band or out-band) to transceive VCO commands between the two systems. Note that the VCO depicted in the
  • REMOTE SYSTEM is controlling the local system as its master, by employing some command dispatching mechanism to connect to the local station, but not necessarily over the network.
  • VCOs The services of VCOs are utilized by client applications that construct them, and subsequently make calls to their member functions. Once constructed, the VCO lies resident in the host system as an adjunct multimedia connectivity operating system that can respond to requests for service, when accessed in one or more of the following ways:
  • VCO/TTY Access Daemon can construct a VCO in a host system, and then open a command text stream through a system communications port. Any remote system connecting to that port can send commands, and examine the effects of their issuance.
  • a VCO terminal session is established upon connection to a remote system communications port that is being monitored by a VCO directly, or monitored by an Access Daemon. From the perspective of the remote system, the method of creating a terminal session to control a VCO, is referred to as Remote
  • a seamlessly integrated remote VCO control solution referred to as Remote Member Access
  • Remote Member Access is an access method that creates, in a VCO implementation, a Media Control Object that is expressly designed to establish a bi- directional text data stream through a particular system port.
  • the VCO command/event streams are directed through it, to provide a level of control that allows a VCO client, invoking VCO members on its own local system, to drive a remote VCO transparently.
  • This method utilizes the identical components and mechanisms as for remote VCO control across a connection, except that the command/event stream is directed to an out-band communications port, and not the principle network connection.
  • VCO portion of the system must be created to support the specific configuration of devices installed.
  • Compliant client applications will run over any VCO that they construct.
  • Any number of VCOs can be created to encapsulate divers combinations of devices installed in the system.
  • An instance of a VCO (that encapsulates a device set) is one of many possible presentations of that same device set to an application; a different VCO implementation may invoke the same devices in a different way, or using different drivers (for example) to present an entirely different performance profile.
  • multiple VCOs can be instantiated concurrently to provide multiple multimedia connectivity sessions at the same time.
  • There is no limit to the application of the VMCS paradigm as long as the specified VCO service is provided, through some means, to the client application or marked as absent in the VCO's capabilities listing.
  • VMCS virtualized virtual system
  • a VMCS can be constructed to run over almost any combination of the components discussed in the section entitled Host System Equipment Requirements below, depending on the level of implementation desired; support for concurrent audio, video, image, and data services is hereupon described for the disclosure of full VMCS implementation, but any partial implementation is possible without affecting the basic VMCS design.
  • the VMCS is ideal for limited usage i.e. only for audio connectivity.
  • the bewildering array of devices for audio, video, data, imaging, and videoconferencing that are now available, often combine the functionality of two or more devices, in which case the perceived differentiation between them exists only in the software abstraction layers that comprise a VCO.
  • an audio and video device may be combined on one board, but will appear as (map to) a number of discreet functional Media Control Object entities, whose hardware support mechanism is indeterminate, when considered at the level of the VCO Client application.
  • a Personal Computer is the preferred host system. It should have a Pentium processor running at 120Mhz or faster, contain at least sixteen (16) megabytes of random access memory, and a minimum of 500 megabytes of backing store capacity. • 32-Bit Multitasking Operating System
  • the VMCS host operating system should provide protected memory address space for each process, support multiple threads, and have a preemptive scheduler.
  • a VMCS host operating system user interface should be event-driven, and provide a windowed graphical "object-desktop" environment where each visual component can be manipulated by drop/drag/cut/paste/properties operations .
  • Audiovisual encoding and decoding hardware may be integrated with other devices onto one or more adapter boards that plug into expansion slots in the computer.
  • the CODEC devices for this implementation must encode audio and video inputs from a microphone and camera, respectively, to a multiplexed digital signal compliant with the H.221 frame structures.
  • Decoding must proceed from this H.221 compatible signal to an analog audio output, and a VGA video signal for output to (for example) a video display terminal.
  • a high-resolution video graphics adapter must be installed so as to work in conjunction with a video overlay device.
  • This hardware configuration will support the station's principle visual graphics information output pathway by enabling the simultaneous display of bitmapped graphical and motion-video.
  • This sub-system must permit motion-video display in a windowed portion of the main screen, a region programmatically selected for that purpose.
  • the overlay controller allows the display of motion-video over a region of the bitmapped display device by enabling the real-time overlay of NTSC video frames onto the identified region of the main display bitmap.
  • Audio and Visual Peripheral Transducers include input devices such as an NTSC camera to input motion-video, a microphone to input audio, and a 600 DPI color scanner to input high-resolution still images.
  • Output devices include a 17" CRT display (1280 x 1024 resolution that can display 65,535 colors) for bitmapped and motion-video output, a loudspeaker for audio output, and a color laser printer for hardcopy photograph and document output. Audiovisual devices may plug into analog signal ports on adapter boards designed specifically for the purpose of PC bus interface, or into standard digital computer ports (according to their own unique interfacing requirements) .
  • NIU Network Interface Unit
  • a network interface unit must provide the physical link to the network. It needs to support a minimum transfer rate of 128 kbit/s through a plesiochronous network (see U.Black, ATM, Foundation for Broadband
  • ISDN Integrated Services Digital Network
  • the network interface must provide programmable software control of the physical network service, and in the case of the recommended ISDN configuration, ISDN network protocol software must provide accessibility to one or more b-channels (for encoded audio/video data) and to a d-channel for the out-band signaling required for H.320 protocol implementation. Data packets from the system must be directly accessible for synchronous transfer to and from the decoder/encoder devices (audio and video CODECS) .
  • BTI ISDN Basic Rate Interface
  • the ability to establish a connection supporting 128 kbit/sec is generally accepted as the absolute minimum bandwidth needed to support a primitive motion-video image (with a concurrent audio signal) across the ISDN.
  • a typical BRI installation is utilized as a 2b+ld channel configuration.
  • a triple-BRI, or composite line configuration (384 kbit/sec) is preferable, as it is capable of producing an image closer in quality to that is generally considered acceptable in other video applications.
  • Developing a VMCS from preexisting hardware components is a combined system and application software development effort.
  • Initial development of a VCO to control a set of devices is a significant undertaking that involves careful interface to device control software, and implementation of many of the specific protocols residing under the H.320 rubric.
  • implementation of the prototypical VCO kernel is non- trivial, diligence is repaid many times over in that nearly all of the kernel source code is propagated, in rote fashion, to create a new VCO that can readily support a new set of devices.
  • the client application binaries are directly re-releasable — client programs are fully device-independent and run over any VCO built to specification.
  • VMCS Disclosure provides the necessary description of a Virtualized Multimedia Connection System to derive a design for an actual implementation.
  • a complete set of the ITU-T recommendations referenced in ITU-T Recommendation H.320, are a necessary adjunct to the implementation and testing of fully compliant protocol implementations (see REFERENCES) .
  • C++ Software Development System or a functionally equivalent object-oriented development system must be used to create both the VCO (server) and client portions of the VMCS. Full implementation of the referenced AT&T C++ language must be supported.
  • VMCS server components it is the primary directive of every VCO to bind, dynamically at run-time, a connectivity source to a set of transducers; and do so in such a way that the service provided to client applications serves as a mechanism to share spectral information between interconnected stations ⁇
  • no consideration is given to any intermediate data transmission methods employed.
  • the VCO implementer it is the responsibility of the VCO implementer, to ensure that sound and light directed to and from the remote station, are somehow seamlessly, automatically, and transparently transited over the void that may exist between data streams associated with the source of connectivity, and those associated with the local transducers.
  • Most systems utilize an integrated audio/video hardware design to provide a direct analog signal link between these parts — consider those manufacturers mentioned in the Background section — but this model is crippling to the station in its other purposes for reasons aforesaid.
  • the operating system type specified for this system is characterized by the ability to spawn threads that run concurrently at specified priorities. They can be utilized to support transparent (to applications running in the foreground) real-time data streaming facilities. Data streams to/from connectivity sources can be attached to/from transducers, so as to bridge any gap between discreet devices installed separately in the system; sharing data between separately installed devices requires read/write operations executed by the microprocessor (there is no direct analog signal connection between devices on different adapters) . With the specified operating system type, a station can take advantage of the multiprocessor personal computers that would support the transfer of data at very high speeds (between devices in the system) , even at rates sufficient for normal system operation, while processing audio and video in real-time.
  • the VCO implementation must create the operational context in the system, dynamically when invoked, to move data between system components. It must do so in a way that is fully protected, secure, and unaffected by other system activities.
  • the creation of the sub-system's operational context must be transparent to the client application, as must its destruction at session's end.
  • a VCO is mostly comprised of software objects whose member function implementations are overridden by more derived versions of themselves that provide structured access to the services of installed adapter devices.
  • VCO architecture is a direct application of software object technology, to elucidate the details of its embodiment entails discussion of its components in terms of a class derivation hierarchy. Next follows examination of the VCO's class structure.
  • VCO implementation encapsulates one specific sub-system configuration that exhibits a particular set of properties (capabilities) that defines its unique service profile — unique in the set of standardized VCO operations it can support, but no different from any other VCO in the way it presents them to client applications.
  • each VCO is no different from any other in the way it is implemented.
  • More derived classes in the VCO are more device-dependent, ranging from the device- independent VDI classes, to the device- dependent class PDI.
  • More derived classes are more time critical, ranging from the VDI that responds to occurrences of events in OS-scheduled time slices, to the PDI that can queue events during interrupt service routines, invoked in real-time by device requests for interrupt.
  • VCO virtual members substituted with a more suitable implementation overriding them with one more device-specific (residing in a more derived class) ; that is, a default function is provided by the VDI, which the programmer can override in his particular implementation of the same feature.
  • This isolation of logical operations from physical device operations is realized by exploiting object-oriented software language constructs integral to the language itself; structural integrity and layering of operations in the VCO is enforced at the most fundamental level of source code expression.
  • the device control members used by the VDI (to lend physical device control to the implementation of its algorithms) are accessible directly in the same class, but the underlying device control mechanism is (for all intents and purposes) , in one more derived and not directly addressable. Resultantly, any changes to the way these more derived device control members are implemented, are beyond its discerning.
  • the class derivation diagram depicted in FIG. 5 shows the classes that directly comprise the VCO, as well as adjunct classes (Notifier and MCO) that are used to implement its feature set. Every component shown is used in every VCO implementation exactly as shown.
  • Class VDI being the Virtual Device Interface used by clients to access the VCO's encapsulated sub-system, is the only class, besides the public constructor and destructor in class VCO, that contains public member functions.
  • the symbols used to describe the various relationships between classes are mostly proprietary to this disclosure, as no widely-used convention to graphically express object-technology concepts has been adopted by a major standards organization. Symbolic conventions used here are shown in FIG. 1.
  • VCO is a composite derivation of the six classes: Terminal, Exception, Event, VDI, VL, PDI, and VCO.
  • Terminal enables the VCO to send text messages to a set of character output devices, or receive text messages, that are subsequently interpreted as commands. Since the VCO terminal can be programmed to use the VCO notification mechanism as a virtual output device, the class contains a pure virtual member used to direct text output to a Notifier Object configured for such purposes. This member is overridden by a supporting member function in the more derived class Event, and this override must be present for class terminal to compile.
  • Class Exception is derived from class
  • Class Exception also has a virtual function used to shutdown the VCO when an exception occurs.
  • An override in the VDI provides an implementation that shuts down the VCO, as expected during fatal errors.
  • Class Event is derived from class Exception, and is defined to contain the VCO event manager, which in turn manages the notification mechanism. It maintains a linked object list of Notifier Objects which are themselves each individually derived from the NOTIFIER data structure. Every Notifier Object is a protected class that is created by class Event, and is a friend to it. Class Event, but no other, can create, delete, or access class Notifier members directly except members of class Event, thus the Notifier Objects are essentially creatures of it. The event handler is the VCO's "proxy" to the linked list of Notifier Objects.
  • Class VDI is a protected derivation of class Event. It is defined to contain a large set of members that comprise the VCO Software Control
  • Class VL is derived from class VDI, and provides a location for an implementation- dependent set of routines to map physical device control operations and responses to/from the logical representation manipulated by members in the VDI. Most of its members are private to it, and narrowly focused in scope. Entry points to translation and mapping services are made public to more derived classes that wish to utilize them.
  • Class PDI is derived from VL, and contains 5 within it, private definitions and implementations of member functions that override the pure virtual device control members used in the VDI to invoke the services of physical devices in the ⁇ o encapsulated multimedia connectivity subsystem. The implementation of the pure virtual overrides utilize members in the VL to translate and map the structure of arguments and input/output data syntax to
  • PDI contains mechanisms to access the VCO Media Control Object Device Control Mechanism (Media Control Objects) . This mechanism relies upon the maintenance of a linked
  • Class MCO is derived from an MCOPARAM data structure that serves as a general purpose repository for
  • the design of the VMCS is to promote its utilization in a variety of operating environments that include distributed systems, remote access across a network
  • Class VCO is derived from class PDI, and functions as the capstone for the VCO class structure. The only members it inherits from its parent classes are the public members that comprise the SCI in the VDI. Its constructor and destructor call those of its parent classes, thus it invokes those of the VDI to create and destroy the VCO session..
  • Class VCO contains all additional implementation-specific entry points (object members) that are presented to client applications, including extensions to the VMCS that are not directly related to controlling the connectivity session. All client applications proceed with the expectation that the invocation of VCO services will always be accomplished using a pointer or reference to class "VCO" .
  • VCO terminal services Provides full implementation of the VCO terminal services by maintaining a list of output devices for the output terminal, and writing all text message sent to the terminal output port to every device on this list.
  • Text messages sent to the terminal input port are assumed to be VCO text commands. They are parsed into tokens, decoded, and executed as SCI commands. The sub-components residing in this class are listed below, with an accounting of the specific operations for which they must provide support.
  • Terminal Stream I/O Device Controller Operations supported by this sub-component must include the following:
  • VCO exception handling operations that include reporting the occurrence of the exception, and subsequently shutting the VCO down. Additional features of this component include the maintenance of an enable/disable flag that is tested by every public member function upon entry into the VCO; a disabled VCO must reject any call into it, and return the "Disabled" result code to the caller. There are a number of flags that can be used to configure the exact modality used by the exception handler to respond to exceptions, and each modality must be supported by the exception handler implementation, in accordance with the definitions shown in FIG. 6A. The sub-components residing in this class are listed below, with an accounting of the specific operations for which they must provide support. • Exception Handler
  • VCO event management operations Provides full implementation of the VCO event management operations.
  • a list of Notifier Objects is maintained, and a mechanism to trigger them is contained in this sub-component.
  • the VCO event queuing and dispatching mechanisms are located in this component, though critical section handling may be located in the VL to make use of special operating system support for semaphores and thread blocking features.
  • FIG. 6C shows the symbolic identifiers for these events, and provides concise definitions for each.
  • the physical source of the event is labeled as either hardware (HW) or software (SW) , and accompanied by a code that goes on to further clarify the specific system component from which the event is likely to (though not necessarily) emanate.
  • VCO developers creating a VCO to work with a new device set must identify the most reliable source for VCO events originating in hardware, and then map vendor- specific representations of the event to those virtual, standardized, and described in FIG. 6B.
  • Third-party device drivers in the MAC layer may not provide access to events identical in meaning or context to those cataloged by the VCO; some interpolated or emulated derivation (from events closely related) may be necessary for a compliant indication of the standardized occurrence, and any member functions created to approximate the representation of one such only marginally identifiable, should reside in the VL layer for invocation by members in the PDI.
  • the event manager is also responsible for managing the flow of trace information to its terminal output port.
  • the sources from which trace information emanates can be programmed in an additive fashion, by specifying a trace output profile. There are a number of flags, applied to express this profile as a logical combination of trace output source locations within the VCO's works, and each modality must be supported by the event manager implementation, in accordance with the definitions shown in FIG. 6B.
  • the sub-components residing in this class are listed below, with an accounting of the specific operations for which they must provide support.
  • Notifier Object List Manager Operations supported by this sub-component must include the following:
  • Notifier Object List The list itself is implemented as a linked object list, where each object contains the member functions and member data necessary to configure the Notifier Object's triggering profile, as well as to actually trigger it to deliver notification to its associated
  • Notification Triggering Mechanism Operations supported by this sub-component must include the following: - Ill -
  • Each NO is a self-contained reporting mechanism called a thunk.
  • This thunk must be created by any class that wishes to be informed of the occurrence of a VCO event.
  • the thunk provides a globally defined entry point to the address space of the instantiated class object that is to receive notifications, and the thunk retains knowledge of the exact class name and specific class member designated to receive notifications (from the NO residing in the VCO itself) .
  • the NO stores a pointer to this global entry point (the thunk) , a pointer to the Notification Receiver Object (NRO) , and a pointer to the NRO's Notification Receiver Member (NRM) that is the ultimate destination for delivery of notification.
  • NRO Notification Receiver Object
  • the NOTIFIER data structure from which the Notifier Object is derived contains all of this information, the achieved objective in its tracking to enable an immediate conveyance of a unit of system event information (a standard VCO event) directly from a driver-level component to the application, as soon as there exists an opportunity for the operating system to run the interested application.
  • system designers should first reflect upon the following:
  • Notifications are designed specifically to operate like system interrupts, independent of user interface event queues. Like interrupts, they require service only in response to very specific occurrences to which they are programmed to respond — service routines do not have to test for a wide range of possible triggering events, but can act directly with simple, well-defined operations .
  • Notifications from the VCO are virtually unaffected by user-interface operations, and events are never lost to "queue-full" conditions. They are fast, configurable, flexible, and offer a measurably more reliable feedback mechanism than the typical GUI event delivery mechanisms, but expectantly can interrupt drawing operations in progress.
  • Drawing operations, to display information delivered by a Notifier Object are best executed from a specific painting routine, whose invocation is governed by the receipt of paint messages from the GUI — painting messages and graphics to the display with each notification can prevent the GUI from processing messages in its own event queue.
  • NRMs should be constructed as high-level interrupt service routines that insert an event into the application's event queue (GUI event stream) , or spawn a new thread to exact some effect on the system, and return immediately.
  • GUI event stream application's event queue
  • To delay processing on a notification thread could delay notification to other VMCS objects (if a single thread is used by the triggering mechanism to trigger all NOs) .
  • none of the usual problems associated with delayed interrupt processing occur since the VCO queue retains all events till processing is resumed; no information is ever lost. Further, VCO events are but shadows of real-time events that will have long since been serviced in real-time, according to the methods implemented by driver-level vendor-specific components.
  • Notifier Objects add them to a linked object list upon construction, and remove them from the list upon destruction; their structured integration into a linked storage format is managed automatically.
  • Notifier Object Operations supported by this sub-component must include the following:
  • Class VDI Provides full implementation of the VCO Software Control Interface (SCI) , along with a number of private support functions. Any device-independent routine necessary to VCO implementation resides in this class.
  • the header file VDI.H (see Appendix) contains all of the constants, enumerations, and data structures used by both server and client portions of the VMCS. Following those definitions, is that of the SCI.
  • These member functions are the virtualized definition of the VMCS control mechanism from the client application's perspective, and are the only public members of the VCO; notably excepted is the VCO constructor and destructor in class VCO.
  • Not shown in VDI.H are the device-independent call and protocol management routines that provide support for the VCO connectivity sessions. They are implementations of various Recommendation H.320 protocols.
  • the session- related sub-components residing in this class are listed below, with an accounting of the specific operations for which they must provide support.
  • Network Session Operations supported in this group of member functions have public entry points that are represented in the SCI (see Section entitled VDI Header File in Appendix) . They are noted here to reference figures that detail their flow control pathways.
  • the Network Session operations must include the following:
  • Operations supported in this group of member functions are accessed by the public audiovisual/data signal switching control members in the SCI (see section entitled VDI Header File in Appendix) .
  • a query flag passed during a call to this member function determines whether or not a request for service or capability query is invoked. Operations supporting the service and query requests must include the following:
  • Call control related members must include the following:
  • Capability Exchanger Operations supported in this group of member functions contribute to implementing an algorithm that employs an H.221 mode- capability cross-reference table to determine if the connection between logical and remote stations can support a given H.221 device mode; that is, it compares the capability associated with the mode to the logical intersection of the capabilities of the local and remote stations.
  • Capability exchange operations are internal to the VCO, and must include the following:
  • a member function in the VDI is a Notification Receiver Member that receives notifications of device events from a Notifier Object created by the VCO at the time of its construction. Any events in FIG. 6C, whose source is identified as hardware, is considered a device event, and the Device
  • Event Processor responds to them to maintain the current connectivity session.
  • Device events are processed according to a specific algorithm that routes them through appropriate control flows depending on their particular category (see FIG. 23).
  • VCO device control interface Provides full implementation of the VCO device control interface, including a number of operations to interface operating system services.
  • a pure virtual override member must be implemented to support the operations defined for the pure virtual device control members defined in the VDI (see section entitled VDI Header File in Appendix) .
  • the header file PDI.H contains the definition of class PDI (see Appendix) and shows its role in the derivation of the VCO. Implementations in class PDI have no restrictions on the way they interface devices. Media Control Objects (instances of class MCO) , are the preferred mechanism.
  • the PDI creates an array of Media Control Objects that describes the available, and expected-to-be-available, audiovisual/data signal types.
  • These Media Control Objects contain the member functions and data structures needed to control the device that is the source of, or destination for, the signal they represent to the VCO.
  • the next section entitled MCO Device Control Mechanism goes on with a further discussion of the Media Control Object Device Control Mechanism. The sub-components residing in this class are listed below, with an accounting of the operations for which they must provide support.
  • VCO device capabilities are represented as device-independent constants, so there may be a necessary mapping operation from the BAS code (or proprietary) representations used by the connectivity protocol stack to/from those defined for the VMCS.
  • H.221 Device Mode BAS Codes A list of all H.221 device modes is kept in the PDI as a reference. This list is used to determine if a mode is standard, non- standard, of a given type, or invalid.
  • the callbacks come from the OSI transport layer (or its equivalent) . They call the VCO to report any changes in line states, the arrival of BAS codes from the remote station, and for a wide variety of status-related events, as defined in FIG. 6C. • Media Access Control Callback Members are called by routines in the device drivers that comprise the MAC layer. They call the VCO to report changes in device states, results of device operations, and a wide variety of status-related events, as defined in FIG. 6C. Upon receiving an event from any callback function, the vendor-specific event is mapped or translated to one of the standard VCO events, and added to the VCO event queue. Routines in class VL may be called for this purpose.
  • VCO.H contains the definition of class VCO (see section entitled General VMCS Header File in Appendix) and shows its role in the derivation of the VCO. All client applications must include this file in order to access the services of the VCO itself.
  • Class VCO is the class that is constructed by the client, and it presents to this client a number of public member functions described as follows: • Public VCO Members Available to Client • VCO is the constructor of the VCO, and invokes the constructors of all less derived classes when invoked.
  • • -VCO is the destructor of the VCO, and invokes the destructors of all less derived classes when invoked.
  • the device control diagram depicted in FIG. 7 shows how the VCO is able to reference the devices in its encapsulated sub-system as configurable representations of the data streams that they generate, process, or redirect.
  • Client calls to the SCI are shown to invoke SCI members that, according to their specified function, rely on calls to pure virtual device control members for their implementation, thus not all SCI members are included in the diagram.
  • the sixteen default Media Control Objects are arranged in the drawing to clearly demark the low- level, vendor-specific component to which they correspond, and manipulate when affected by PDI calls to their members.
  • Vendor-specific MAC components should be considered bi-directional — they support control pathways and data streams to and from a media control sub-system — and the different types of transducers required for each direction are clearly evident.
  • the "audio" objects reference a MAC component supporting audio input and output, and to that single MAC component is connected both microphone and speaker.
  • PDI calls made directly to the connectivity protocol stack and MAC components are not shown explicitly in the drawing, as the exact structure of their interactions are left to the implementer's discretion. Summary of Device Control Mechanism
  • Client calls to the SCI invoke members that often require the support of the encapsulated multimedia connectivity sub-system in their implementations.
  • SCI members such as "Open” and “Call" make requests for physical device control services by utilizing at least one of the pure virtual device control member functions declared in class VDI; these members are private and entirely separate from the public SCI members offered to clients.
  • the PDI contains overrides for these pure virtual device control members. These overrides invoke the appropriate device operations by making calls directly to the connectivity protocol stack or MAC layer components, as is appropriate to the desired device control operation. Implementations of the pure virtual device control overrides must perform any and all interface to vendor-specific hardware and software components necessary to fulfill the specified expectation of the pure virtual device control member in the SCI.
  • the particular SCI member, called by a client is MediaControl
  • the method of interface to the physical device is different from that used for call and protocol operations; its purpose is to switch or configure the audio, video, image, or data signals represented as virtualized system objects, or Media Control Objects.
  • the pure virtual override for MediaControl implemented in the PDI, then manipulates the members of Media Control Objects that have been created to represent the various available signal types.
  • audio, video, image, and data signals are combined, redirected, displayed, or routed to local devices or the remote station.
  • the Media Control Objects can also be used to set various modes (associated with the signals) by directly controlling the device associated with it.
  • the operation of the Media Control Object device control system is detailed as follows:
  • Each Media Control Object representing a specific signal type and direction, can be attached, or "plugged into” another Media Control Object that is compatible in both signal type and direction;
  • an audio source from a local device microphone
  • a video input from a remote station can be attached to an output to a local device (video display)
  • Each Media Control Object regardless of signal type, contains a data structure that reflects the various states and modalities of the signal. Member functions for each Media Control Object, allow them to be manipulated as independent, uni-directional channels.
  • Certain Media Control Objects can be combined into composite media control objects that describe a complex signal type, such as multiplexed audio/video information.
  • the objects can also be combined with objects that subject them to a specific transform, or split/join configuration.
  • Setting the parameters of a source/input object invokes a sub-system (driver-level) attempt to change the settings of the source device or station, whereas setting the parameters of a destination/output object attempts to change the settings of the destination device or station.
  • Device control operations are made directly available to VCO Client applications through the implementation of the MediaControl SCI member function, along with some related members that assist in the manipulations of these objects.
  • the SCI members map to essentially identical pure virtual device control members implemented in the PDI.
  • the switching of signals and device modalities generally takes place by selecting constants from various enumerated categories (see section entitled VDI Header File in Appendix) , and presenting them to the VCO with the MediaControl member.
  • the format of the arguments is constructed so that the specified operation applies to the currently assigned default Media Control Object for the specified Media Control Object type (see FIG. 7A) . For example, a command to mute the input microphone would likely reference AudioSrc as the Media Control Object type.
  • Handles are used to assign various non-default Media Control Objects as the default (one of the sixteen) for a given type.
  • the continuous linear enumeration of all possible constant arguments used for MediaControl function calls give each setting a unique numerical identifier, and thus each can be associated with a unique string token.
  • the argument formats for all of the MediaControl calls are detailed in the source code section (see section entitled VDI Head €»r File in Appendix) .
  • Each Media Control Object is a class object privately derived from an MCOPARAM (see section entitled VDI Header File in Appendix) structure. Regardless of the signal type (audio/video/image/data) represented by the Media Control Object, the MCOPARAM structure contains sub-records for all signal types. The programmer need only attend to the relevant section for the signal type for that object. There are a number of requirements as to the structure of the Media Control Objects physical structure, with regards to the specific details of its implementation.
  • Class PDI is a friend to all instances of class MCO. • Class VDI cannot access any MCOs directly, except through specific members that are implemented by class PDI.
  • All MCO members presented to the PDI should be simple, device-independent operations to manipulate the settings and operations precisely outlined by the audio, video, image, and data records contained in the MCOPARAM data structure. • Each MCO should be fully cognizant of its signal type and signal direction, and prohibit operations that are inconsistent with its fundamentally characteristic properties, i.e. cannot attach audio output to a video display.
  • Each MCO controls the device underlying the signal it represents by making requests to the Media Access Control layer components that drive them.
  • the PDI pure virtual override DevMediaControl presents settings to the Media Control Objects, and the Media Control Objects then go on to map the setting to a physical device control operation.
  • FIG. 22 shows the control flow for device control operations that are presented to MCI drivers that comprise the MAC layer. This diagram has greatly simplified the pathway from the VDI to the MCI driver, eliminating most of the interactions with the Media Control Object.
  • the PDI prepares a Media Control Request Record, and presents it to the appropriate Media Control Object so that the object can fill in its fields, and present it to a corresponding MCI driver (see FIG. 22) .
  • a device control operation initiated by the local station can result in the station assuming a new H.221 device mode, which is then transmitted to the remote station (if currently connected) for station synchronization, referred to as the "establishment of common modes" by Recommendation H.320. Finally, an event is added to the VCO event queue describing the new Media Control Object setting that has taken place.
  • a pathway must be established between the two stations such that they can share text string commands streams. Once this pathway is available, the two stations must come to a mutual understanding how they will interact; that is, which station is the master, and which is the slave.
  • a third station can control any one of a number of stations that are themselves interconnected in a conference.
  • a "third party” controller, or “remote operator” can intervene in conference already in progress to assist, diagnose, or monitor one of the conferees.
  • the details of designs that would accomplish this task are supportable by the VMCS, but beyond the scope of this disclosure. Below follows a description of the details for the VCO components used to implement the remote station attachment mechanism.
  • the command stream is bi-directional — to and from the remote station.
  • a Media Control Object supporting text data output to the remote station, and another Media Control Object supporting text data input from the remote station, are created to encapsulate the data pathways. Since mostly text message data will be exchanged, the pathway need only support low bandwidth (less than 16 kbit/s) on an occasional (asynchronous) basis. Data can be transported out-band on a separate channel (such as an ISDN D-Channel) or in-band, perhaps multiplexed with video data. The data transport mechanism for message data can also be accomplished through a tertiary source using an entirely separate connection from that used for primary communication. All messages to the remote station are written to the Media Control Object encapsulating the pathway to the remote station, while messages arriving from the remote station generate events as they are received by the Media Control Object encapsulating the pathway from the remote station.
  • Event Encoder This component converts binary event records added to the VCO event queue to a text event message representation, and then sends it to the remote station.
  • a definition of the binary event record is provided (see section entitled VDI Header File in Appendix) , however the exact text event message format is left to the system designer. Suffice it to say that the text message format used should be entirely universal to allow all VMCS implementation platforms to engage in "attachment”.
  • String tables in the Linguistic Controller areas of the VCO are used to convert the enumerated arguments to string tokens, whenever possible, while purely numerical arguments (such as parameters) are converted to ASCII hexadecimal strings.
  • Each event message must minimally include the following information:
  • the event encoder is usually only accessed when the VCO is attached to a remote station. While the VCO is attached, the encoder is invoked by the VCO queuing- mechanism each time an event is queued. The encoding takes place using a separate thread of execution to avoid interference with device timing.
  • This component converts text event messages received from the remote station and converts them to binary event records that are then added to the local VCO's event queue. This process is the inverse of the encoding process, and its success depends upon the consistency of the text event message format selected.
  • the source station identifier tells the receiving VCO where the event came from, and the string tables in the Linguistic Controller are used here to derive a numeric representation by comparison of the string token keywords to their relative position in the tables, and derive a string index when the token is identified.
  • the event decoding takes place using a separate thread of execution dedicated to fielding incoming command and event messages.
  • Linguistic Controller areas of the VCO are used to create text command messages whose format is variable depending on the SCI command encoded.
  • the command encoding takes place using a separate thread of execution dedicated to fielding incoming command and event messages.
  • This component redirects the text command portion of the shared messages to the local VCO terminal input port, where they are interpreted, and then used to generate calls to the local VCO's SCI, just as if they had been input from a local user at a terminal keyboard.
  • This process is the inverse of the encoding process, and its success depends upon the consistency of the text command message format selected.
  • the event decoding takes place using a separate thread of execution dedicated to fielding incoming command and event messages.
  • Each VCO has associated with it independent parameter blocks for remote control parameters and remote monitoring parameters.
  • the control and monitoring capabilities are stored as nonstandard capabilities in the local capabilities lists, and each station will know those of the other at the time of connection.
  • flags in the associated parameter blocks mark the state, and prohibit any further context changes till the stations are detached, disconnected, or the change is initiated by the "controlling" or "monitoring" station.
  • monitoring of a remote station requires only that the "monitor" station receives a stream of the events queued by the "monitored" VCO.
  • both stations are monitoring their own locally queued events; they are operating under a local monitoring context. If one station permits (indicates it is capable of) being monitored, the other can change its monitoring context, by setting its monitor mode flags to include the remote stations events, and therefore add the events from the other station to its own event queue, in addition to continuing to monitor its own event stream concurrently.
  • it can monitor only those events of the other station, or monitor any one of a group of stations in a conference, as they come into focus (though a virtual attachment must be established with each individual station prior) . Monitoring can occur bi- directionally at the same time; two stations may monitor each other concurrently.
  • the VCO With the ability to transparently send commands to a slave station, and transparently receive events from the station in response to those operations, the VCO that assumes the master control context becomes a fully operational virtualized representation of the slave station. And client applications that run on the master VCO are (practically speaking) virtual clients of the slave VCO.
  • ITU-T Recommendation H.231 (see ITU-I Recommendation H.231, MULTIPOINT CONTROL UNITS FOR AUDIOVISUAL SYSTEMS USING DIGITAL CHANNELS UP TO 2 Mbits/s, 1994) describes such units and their various configurations.
  • Attendant Recommendation H.243 (see ITU-I Recommendation H.243, PROCEDURE FOR ESTABLISHING COMMUNICATION BETWEEN THREE OR MORE AUDIOVISUAL TERMINALS USING DIGITAL CHANNELS UP TO 2 Mbits/s, 1994) describes the specific operations performed in a multipoint call environment, such as adding, dropping, and viewing specific conferees from the conference. These recommendations serve as the impetus for the logically defined multipoint control operations incorporated into the VMCS server (VCO) architecture. At time of writing, there exist fewer than a half-dozen widely available devices supporting a significant subset of the procedures outlined by the recommendations.
  • VCO VMCS server
  • MCU multipoint control unit
  • NIUs referred to as ports
  • a specialized algorithm determines which conferee, at any given time, is to be seen by the others.
  • the strength of the audio signal determines the individual that addresses the conference.
  • a chairman is specified to direct the conference, and he possesses special privileges to administer its outplay; his responsibilities as chairman include the appropriate allocation of resources, the creation of conferences, and the configuration equipment as needed.
  • the multipoint control operations supported by the VCO MultiCall SCI Member are shown below (see FIG. 30) .
  • Calls to this MultiCall member map to the PDI DevMultiConnect member, one that provides an actual physical implementation for them.
  • this PDI member will typically be constructed to issue vendor-specific commands to a MCU resident in the station, or cabled to it with some communications link. All of the major operations needed to directly control the mechanics of a conference, as its chairman, are included. Further discussions of these operations are provided in the source code (see section entitled VDI Header File in Appendix) .
  • the CALLPARAM structure in the VCO has a number of flags and variables used to track and configure multipoint control operations.
  • a series of flag values referred to as MULTICALLSTATES provide detailed indications as to very specific states in both the local VCO, and the conference in which it is participating.
  • VCO The procedure to implement a VCO differs depending on whether the project is to create an initial server component, or to create a new component (from an existing one) that will work on a new multimedia connectivity sub-system. While primary (initial) VCO development requires considerable effort, secondary (subsequent) VCOs are comparatively minor projects in both time and resource requirements. The development of VCO clients can proceed concurrently with, and independently of, that of the server(s) ; the production of VCO Clients requires markedly less design and development expertise than is required to produce the VCOs themselves.
  • VCO implementation Sequence The following procedure is applied to primary VCO development. Secondary VCO development efforts (based on the same design) reuse almost all components, without modification, thus steps l, 3, 4, and 5 are not necessary to create them.
  • VDI Virtual Device Interface Source code development for the VDI includes creating all of the classes from which it is derived.
  • the device-independent portion of the VCO is implemented as a distinct unit that can be built without any dependencies on any device-dependent, or vendor-specific components.
  • VCO Running in emulation mode, the VCO is debugged to verify the functionality of its device-independent portions.
  • a small sample client application must be created to invoke SCI members for testing purposes.
  • VCO Once the VCO is fully operational and debugged under emulation, physical device control is added to the PDI by providing a software linkage of the pure virtual device control overrides with the connectivity subsystem and associated devices previous emulated in software. Media Control Objects are implemented, tested, and integrated into the device control system.
  • VCO Live Device Control Component Running in the default device control mode, the VCO is debugged to verify the functionality of all of its components and features in a "live" connectivity environment. A sample client application must used, as in step 5, to invoke SCI members for testing purposes.
  • This section describes usage of the disclosed VMCS technology in an operational configuration. Consideration is given to the underlying theories of VMCS operating principles, including discussions relating to the sequences of operations needed to manage various multimedia connectivity tasks encountered during VCO connectivity sessions. In essence, the following section serves as an operations manual for the VMCS, focusing mostly on the services provided by the VCO.
  • VCO construction is a process defined by C++ as a means to create a binary software object from a class definition.
  • the client initiates a construction process that is in no way different from that of any other class, and the VCOPARAM data structure is initialized, along with other initialization tasks.
  • the Virtual Connection Object Upon successful construction of the Virtual Connection Object, its principle data structures and capabilities are available for perusal.
  • VCO terminal input and output ports are active, and can be used by the client to send text messages to output devices, or to decode command input.
  • the VCO may have successfully constructed, no drivers have been loaded, no devices have been accessed/initialized, and there is no way for the client to know if the hardware necessary to run this VCO is actually installed.
  • VCO destruction is a process defined by C++ as a means to destroy a previously constructed binary software object. With the VCO, the client invokes a destruction process that is in no way different from that of any other class. During the process of VCO destruction...
  • NOTIFICATION Once a client constructs a VCO, it can create a number of Notification Objects, the maximum of which is determined by the system designer. Notification indications are sent to the client immediately following construction, should any triggering events should occur. •
  • the NewNotifier command enables the creation of a Notifier Object, returning the handle to one just created as specified. When the Notifier Object is created, it is intimately associated with one particular Notification Receiver Member contained within one particular Notifier Receiver Object, neither of which can be changed; a new Notifier Object must be created to direct notification to a new object-member combination.
  • the DeleteNotifier command can be used to delete Notifier Objects, the handle of the Notifier Object being used to identify the instance to delete.
  • the EnableNotifier command can be used to enable or disable the specified Notifier Object.
  • Each Notifier Object can be disabled to stop the VCO notification process to that particular Notifier.
  • a call to the client's Notification Receiver Object occurs to prosecute indication of the occurrence of an event, during which time, it cannot be reentered by another such call until it returns from processing that event currently in play.
  • the SetNotifierTriggers command allows the client to change the set of events that cause the Notifier Object to trigger; that is, invoke the Notifier Object to deliver information to a specific member function of a specific class object, indicating that a particular VCO event has taken place.
  • the TriggerNotifiers command can be used to trigger one particular Notifier Object, unconditionally, or to present an event to the triggering mechanism, allowing it to trigger all Notifier Objects for the VCO that contain that specific event in their triggering profile.
  • Notifier Objects cannot be created or deleted while processing the notification of an event, because the internal list of Notifier
  • the triggering profile for the Notifier Object can always be modified.
  • CONFIGURATION/SYSTEM SETUP There are two distinct services available to VMCS system users for configuration/setup. The first is the ability to maintain a VCO initialization file that stores a text record describing all of the startup defaults for major categories of VCO settings, including a description of its network service, standard terminal output device, local station identity, dispatcher rate, device and connection time-outs, conference profile, and other default settings. The second is the ability to invoke dialog boxes containing detailed configuration/system setup utilities that are provided for each of the four possible media types (audio/video/image/data) that are potentially handled by the VCO.
  • the initialization file is read at VCO construction time, and its user-readable text arguments are converted to an internal binary format stored in the VCO, accessible as a data structure to VCO clients.
  • the SetConfig command allows clients to write a new configuration structure to the internal VCO configuration structure, and at the same time activate the new settings.
  • the RefreshConfig command allows clients to upload the VCO's internal configuration from its default initialization file, and at the same time activate the new settings. Alternately, the command can be used to upload the internal configuration stored in the initialization file into a client configuration record, leaving that of the VCO configuration record unmolested.
  • the StoreConfig command enables clients to store a configuration record directly in the default VCO initialization file, overwriting the existing configuration, or alternately, it enables clients to similarly store a configuration record held privately by the client. In either case, the data elements in the configuration record are converted to user-readable text arguments prior to being stored in the initialization file.
  • Integral configuration utility screens enable end users to adjust relatively minor vendor-specific device driver and operating specific system parameters that do not map well to the generalized, device-independent controls offered by the VDI and associated media control device control settings.
  • the VMCS concept intends these adjustments to be limited to those settings that are usually set once during initial system installation, and subsequently left mostly alone; they are settings that tune and enhance the operation of the standard VCO device control operations, and are not intended to duplicate or replace them.
  • the SetupVideoDevices command invokes the video setup utility, which provides camera adjustments such as white balance, access to test modes, NTSC/PAL mode selection, and focusing mode selection. Additional adjustments for video display include those that affect color, tint, hue, brightness, horizontal alignment and vertical alignment.
  • the SetupImageDevices command invokes the image setup utility, which includes output settings for any hardcopy display/printer device, or video display adjustments for factors similar to those in the video setup. Input settings for imaging devices typically relate to form size and ambient lighting.
  • the SetupDataDevices command invokes the data setup utility, which is more nebulous in its specific format, and whose settings may range from communications port settings to disk drive specifications for backing store.
  • the VMCS make no presumptions as to the ultimate use of data streams, thus the derived VMCS design must specify the data setup utility.
  • a VCO that directs a data stream to/from a communications port will maintain settings for baud rate, parity, stop bits, and other asynchronous data transmission settings.
  • the VCO terminal service provides an input and output port.
  • the terminal output port functions as a standard output device that displays character stream data written to it, while the terminal input port accepts character stream data written to it, and interprets it as VCO text commands.
  • Character stream data takes the form of null-terminated ASCII strings, referred to as text messages. The null character is used to denote the end of the message. Format dictates VCO text command strings terminate with a carriage return, and intervening nulls that terminate command (sub-strings) are ignored by the decoder .
  • Text messages sent to the terminal output port may be written, concurrently by the VCO, to more than one physical output device, following each client text output operation.
  • Physical output devices configured to be written when text messages are sent to the VCO terminal output port are referred to as attached (to the output port) .
  • clients sending text messages to the default VCO terminal output port will find that the same text message has been duly written to all output devices attached to the terminal output port.
  • Text messages sent to the terminal input port are parsed into string command and argument tokens, and interpreted by the VCO as representations of SCI commands. Once a text command has been fully decoded, it is used to affect SCI member functions, thereby providing a scripted control mechanism to any VCO client; scripts can be generated by the local client, read from script file, transmitted from a remote client across a connection, or entered directly from a terminal .
  • the terminal service is available immediately following construction. A default output device is identified in the configuration stored in the VCO initialization file, and attached to the terminal output port.
  • •- A range of standard output device types can be added or removed from the list of output devices attached to the output port. All output devices are written with every text message that is sent to the terminal output port.
  • the ToTer inal command is used to send an optionally formatted text message to the VCO terminal output port.
  • the command functions similarly to "print" statements used by various programming languages that send text to a standard output device.
  • the FromTerminal command is used to send an optionally formatted text command (VCO script command) to the VCO terminal input port.
  • THAT the terminal input port cannot be read for input by the client refers to the provision of input data to the VCO from the client.
  • the client is the source of the character stream. Since the VCO has no reason to request commands from the client (only the client can initiate the issuance of commands) the onus is on the client to send those commands to a mutually agreed-upon place where the VCO can receive them, and in so doing, invoke the VCO to decode them. Reiterated more plainly, the client "stuffs" script commands in a buffer, and calls the VCO to interpret them. • A Notifier Object may be created and utilized as a terminal output device.
  • the Notifier Object When the Notifier Object is attached to the terminal output port, it may be triggered by any VCO (or client) text output sent to the terminal output port, thereupon the Notifier Object is explicitly triggered so as to make the client's Notification Receiver Object the recipient of every text message sent to the terminal.
  • This mechanism allows any client to direct all text message output to a client's text processing routine.
  • Establishing a network session is accomplished by invoking a sequence of SCI members. Construction and destruction of the VCO frame the connectivity session in that a VCO is usually selected and constructed just prior to connecting to a remote station, and is subsequently destructed immediately following the termination of the connection to it, therein freeing all system resources humiliatwhile allocated to the maintenance of that association.
  • the process of associating two stations across the network, for the purpose of exchanging audio, video, image, and binary information between them, is advanced by a sequence of VCO operations next described:
  • the Open command initializes the encapsulated multimedia connectivity sub-system, loading and starting all supporting vendor-specific software components. Until the "open" is performed, only non-device related VCO services are active. All devices are started and tested to determine that they are fully operational. All available signals are represented in newly created Media Control Objects, and then are opened for use. The entire sub-system, including all hardware and software components, is set to default startup settings, and the network connection is verified. If the open is successful, a connection can be established at any time, and all local devices are accessible to the client, to be controlled by the user. Incoming calls from a remote station may be handled following a successful open. • The Call command initiates a call to a remote station.
  • the network is the ISDN (telephone system) and the "call" operation results in a direct dialing of the number of the remote stations line(s) .
  • the visual telephone service provided by the VMCS requires no further action by the client, and a simple result is returned.
  • a successful connection process results in the execution of an internal VCO process to establish a series of baseline operating modalities for the type of session established. For the visual telephone, a video window is displayed showing the far end, remote station audio is audible, and both local video and local audio are sent to the remote station.
  • Image and binary data facilities are initialized as idle, and pathways await client operations to exchange information.
  • the "call" operation of the VCO's visual telephone system works in an identically analogous fashion to makincj a "call” with a standard analog telephone: dial, connect, then concurrently exchange information bi-directionally, without delay.
  • the MultiCall command enables the initiation of a number of complex multipoint control operations (see FIG. 30) . If the local station is the conference chairman, the VCO client can add and remove conferees from the conference, among other administrative functions, all of which require the ability to control a multipoint control unit (in some direct or indirect fashion according to the actual physical implementation of the VCO service) . Other multipoint operations include various query and broadcast operations that may or may not require an advanced level of MCU control.
  • the client can query any of these operations to determine if they are currently supported by the session in progress.
  • the client can determine if the VCO implementation supports the operations at all by examining the VCO capabilities list, which includes multipoint control capabilities that are proprietary to VMCS technology.
  • the Hangup command enables the client to drop one, or more (all) lines used for the current call. Similar to the "call" operation, the "Hangup" operation of the VCO's visual telephone system works (by default) in an identically analogous fashion to the "Hangup" of a standard analog telephone: end the call without delay.
  • the Close command shuts down all devices in the multimedia connectivity sub-system, and unloads all vendor-specific software components. All client access to device control services is no longer available, and Media Control Objects are all destructed.
  • MEDIA DEVICE CONTROL Device control is available to the client by the manipulation of Media Control Objects via calls to the MediaControl SCI member.
  • the VCOPARAM structure contains a list of the names of all available Media Control Objects active in the system. This list will be empty if the VCO has not been opened first, as the list of Media Control Objects reflects the signals available for manipulation by the client. A list of the handles to these Media Control Objects is also available, and information about them may be obtained using the appropriate SCI member function. Principles governing the control of the devices in the encapsulated sub-system,, and their associated operations, are shown below:
  • any available signals in the VCO are represented as Media Control Objects, automatically opened for use, and enabled.
  • the MediaControl command enables clients to change the settings for any active (existing and enabled) Media Control Objects assigned to be one of the sixteen default types. Additionally, switching of signals (in the form of plugging together source and destination Media Control Objects) , creating composite signals from multiple input signals, and a host of related functions can also be accomplished with this command (see section entitled VDI Header File in Appendix) .
  • the SetDefaultMco command can be used to assign a non-default Media Control Object as a default Media Control Object, if it is the same type as the one it is replacing.
  • the GetMcoHandle command can be used to retrieve the handle to an Media Control Object from its name label or object type.
  • GetMcoLabel is a command that allows the name label for the Media Control Object to be determined from its handle.
  • the GetMcoParam command can be used to retrieve the internal parameters and settings for a specified Media Control Object, and thus it can be used to determine the operational states and settings of the signal represented by the Media Control Object, as well as the device (if any) that is the source or destination of that signal.
  • Data objects may be exchanged with single operations, between stations that are both running a VMCS; each of which fully understands the data formats and "transport layer” protocols of the other end. For now, such issues are left to resolution by the system developer who must determine the exact protocol used to transfer the VCO' s data objects as described herein.
  • manipulation of binary data objects is operationally well defined and described to client applications by the VMCS (The Software Control Interface and the logical manipulation of which is clearly implemented in the "session layer" residing in the VDI).
  • the ITU is currently working on Recommendation T.120 (Data Conferencing) to enable standards-based exchange of binary data objects.
  • T.120 remains incompletely specified, only partially implemented by any real products, and even less well understood by system developers. It is expected that T.120 will eventually provide the "language” necessary for the VCO to conduct its "binary data object exchanges" below the " session layer” , in an entirely standards-based fashion.
  • any data object can be transferred. Otherwise, if the data object to be transferred is a file, the remote station will be unable to respond to the VMCS proprietary file transfer protocol used on the data channel. Support for the exchange of cursor positions, facsimiles, still pictures (images) and raw data buffers is supported by most H.320 compliant stations, and thus possible between a VMCS and any remote station to which it may be connected. The mechanics of exchanging data objects between stations are discussed below:
  • the TransferBuffer command enables a client to send a buffer of binary data through the data channel (or multiplexed data channel using an allocated portion of its total bandwidth) , to the remote host. This command can also be used to determine if the data, channel to the remote station is available.
  • the TransferObject command enables a client to send or retrieve a specified data object through the data channel, or multiplexed data channel .
  • the transfer operations specify a Media Control Object whose data signal is used to transport the data. If the remote station is running a VMCS, the direction of Media Control Objects signal determines whether the transfer operation sends local data to remote station (data to remote) or is a request to retrieve data from the remote station (data from remote) .
  • the Media Control Object used for the transfer contains data structures and variables that describe the actual status of the transfer.
  • references to copies of data structures, stored internally in the VCO, are returned for those specific categories of information relating to devices, configuration, call, protocol, control, and monitoring parameters. One member returns a reference to a copy of the entire VCO system information data structure.
  • the internal data structure of a Media Control Object can be accessed in a way similar to other data structure, with the client specifying the default Media Control Object type, or a handle to one. Also, the handle for a Media Control Object can be obtained from a Media Control Object label or the Media Control Object' s type.
  • the H.320 protocol defines the basic operational structure of the VCO's multimedia connectivity services, and from the standpoint of the client, is mostly transparent to its functionality.
  • An exception lies in the VCO support for the manipulation of device modes and capabilities; it is useful for the client to affect the system's capability list, as well as the set device modes directly. Moreover, such access allows more knowledgeable clients to perform advanced, or less well supported operations at a low-level.
  • a data structure in the VCO referred to as PROTOCOLPARAM, provides the client with information about the H.221 multimedia connectivity protocol.
  • PROTOCOLPARAM provides the client with information about the H.221 multimedia connectivity protocol.
  • the SetConfProfile command enables the client to specify a conference profile that describes a preferred set of audio, video, and data modalities (relative to the available bandwidth of the connection) that define the overall quality of the connectivity session.
  • the SetModes command enables the client to specify one, or more, H.221 device modes by presenting them to the connectivity subsystem. This command is used in conjunction with the VerifyBandwidth command to determine if there is sufficient bandwidth available in the connection to support a specified set of audio and data modes, while retaining the current video mode.
  • the SendCaps command enables the client to transmit its entire H.221 capability list to the remote station.
  • the SetDeviceTimeout enables the client to specify the number of milliseconds the Network Interface Unit should wait for a response from a network request before timing out
  • the SetConnectionTimeout enables the client to specify the number of milliseconds the system should wait for a connection to a remote station to complete prior to timing out.
  • a large group of operations enables the client application to adjust, control, and invoke special features of the VCO. Some of these operations enable the manipulation of internal VCO settings that are typically left to their default settings for most sessions.
  • a number of commands are used by a client to attach to a remote VCO for the purposes of remote control and/or remote monitoring of it.
  • the EnableVco command is used by the client to alter the state of the VCO's "enable” flag, a task usually reserved for recovery from an exception that previously disabled it.
  • the SetVcoExceptMode is used to set the exact modality used by the VCO to handle exceptions .
  • the SetVcoTraceMode command is used to instruct the VCO as to exactly which operations and components should be configured to direct trace information to the VCO terminal output port.
  • the EnableMultiCallOps command is a simple switch that is used to select the client' s accessibility to the multipoint control operations. To disable these operations causes them to return "disabled" to the caller.
  • the EnableDispatcher command is used by clients to pause the dispatching of events from the VCO event queue. This operation is used when the client wishes to "idle" the VCO, while allowing underlying devices to function as best as they may.
  • the related command SetDispatcherRate enables the client to change that rate at which events are dispatched from the VCO event queue, a task usually performed when a faster or slower event stream is required by the client application; faster dispatching rates allow the client to operate at speeds closer to those of the encapsulated multimedia connectivity sub-system.
  • the UpdateCapsList command is used by the client to add or remove a device capability to the VCO device capability list, a version of which is transmitted to the remote station during the connection process.
  • a related command, UpdateModeCapsXRef allows the client to add or remove a mode-capability cross-reference record that is used when the VCO attempts to establish common operating modes with its remote station peer.
  • the EmuControl command enables the client to access an internal VCO emulation facility.
  • Features include enabling/disabling the VCO device emulation mode, and invoking predefined emulation sequences.
  • the AttachToRemote command is used by the client to provoke the VCO to attach to its remote station peer, if that peer is a VCO (running a VMCS) .
  • the DetachFromRemote command eliminates any attachment between interconnected VCO peer stations.
  • the SetVcoControlMode command is used to select the master, slave, or peer modality of operation for the local station, with respect to the remote station.
  • the SetVCOMonitorMode command enables the client to select the event stream for the VCO to process. Events from the local station, an attached station, a group of stations, or some combination of station are directed into its event queue for subsequent dispatching. • The SetStationLabel command is used to assign a text label to the local station so that it may be referenced (locally or by a remote station) by that name.
  • Source code in this disclosure illustrates the use of VCO services by a multithreaded, event-driven VCO Client application.
  • This simple program does not utilize a graphical user interface, but directs its output to the standard output console.
  • the program examines a VCO's capabilities to determine if it supports required audio, video, and data modes, and opens a connectivity session if it does.
  • Source code is also provided for the many header files used by both the VCO Clients and the VCO itself.
  • This source module contains definitions for the principle software enumerations, constants, data structures, and member functions that comprise the Virtual Device interface (VDI) software component of a Virtual Connection Object (VCO). Tbese items must be incorporated into both the client and server en ⁇ nes of any VMCS impieme tauon. in some form of computer language represen ⁇ non.
  • the device interface components are internal (non-public) to the VCO. and are of the pure virtual type. All other member functions, structure*, and constants shown below are used by every VCO to enable structured access to their encapsulated
  • This module contains only C+ + source code and strucured comments using ihc " // * notation to denote comments (in addition to the standard C comment notation using * /* •/ * ).
  • unknown refers to a value, condition, or requested operanon out can not be idennfied: that is the usage of lias word connotes a patently errant condition.
  • untzpeaed refers to a value, condition, or requested operanon that is idenofiable. but is mappropnate given the current 3515 set of preconditions: that is the usage of this word connotes inappropnateness of context.
  • blocking describes calls dial wait for the requested operauon to fully complete, the return value of which indicates its results. This modality of operaoon is the default for all calls. If there is a ' sBloc ing' argument to the call, and it is set to 0 (false), then the call returns immediately without wainng for the operation to complete, typically returning 'pending' if the request is valid, indication as to the result of this operanon comes from the insemon of a descriptive event into the VCO event queue upon its completion.
  • label refers to a string as defined in (6.) above, except that it may nor contain spaces and its length is less than 32 characters, including the null.
  • NRO Nonftcanon Receiver Object
  • NewLocalCap* Previous number capab ⁇ ioes New number capab ⁇ ines 3550
  • EVENT NuUEvent - 0x00000000 // NO-OP to event processor 3595
  • EVENT N ' ewEmuState - 0x00000001 // New VCO emula ⁇ on sate
  • EVENT NewRefCount - 0x00000004 // New VCO reference count
  • EVENT NewDcviceStatc - 0x00000008 // New media control device state
  • EVENT NewMeoF ⁇ cus - 0x00000010 // New 'current" media ctrl Object has been set 3600
  • EVENT NtwRemoteCaps 0x00000040: // New rc ⁇ ie capability list available
  • EVENT NewTe ⁇ ninput 0x10000000: // New text message to VCO (to VCO terminal input port)
  • VcoClosed // VCO is not operational: no calls possible
  • CONTROLMODE // VCO MONITOR MODALITY FLAGS
  • Mo ⁇ ModeAr ⁇ y - 0x04 True seis moruto ⁇ ng array of sra ⁇ ons conference
  • TermODevNoDfier - 0x01. Notifier as terminal output device TerroODevFile - 0x02. // File, or file system std device, as terminal output device
  • RandomLinelDisc // Emulate disc on line 1 at random nme (w/in I mm)
  • ITU-T H 243 typedef enum
  • BroadcastData // Enable Disable broadcast of local d. to conferees
  • MULTICALLOP / VCO UNIVERSAL RESULT CODES typedef enum ( 3750 Failure. // Operanon failed for some unspecified reason
  • QueueFuIl // Queue u full (no more objects can be inserted) Memory Alloc Error. // Memory could not be allocated to support operanon ResourceAlloc Error, // Dependent resource could not be allocated due to error Lnte ⁇ lError. // Some unexpected serious internal error was detected 3770 TimerFadure. // could not configure omer to modulate processing
  • InvalidObject // Specified object is unknown InvaiidSctang, // Specified setnng is unknown for this object InvalidPanm. // Specified parameter is unknown for dus setnng CmdSyn ⁇ xError. // Syntax error in 'command' pornon of message 3785 ArgSyn ⁇ xError. // Syntax error in 'arg * portion of message
  • IsRcvingConf udio - 0x0008. // Receiving conference audio
  • IsRcvmgConfVideo ⁇ 0x0010. // Receiving conference video
  • Audioln - 0 // Audio signal from remote sauon 3910 AudioOut // Audio signal to remote sa ⁇ on
  • AudioSrc Audio signal from local device
  • I ageS re // Image from local device 3920 ImageDst // Image to local device
  • Mul ⁇ plexed // Mul ⁇ ple inputs encoded into single output Detml ⁇ plexed. // tingle input decoded into mul ⁇ ple outputs Transformed. // single input subjected to specific transform Composite TypeEnd 3945 ) MCO COMPTYPE.
  • UnassignWindow // Unassign mooon-video display from wuidow
  • SetPixelDepdi // Set unagmg image pixel depth 4000 SetPhysicalWidm. // Set unagmg image physical width
  • SeiunageCombuieType // Set image combine type
  • SeiAudioQuality // Set audio signal quality pSyncbOn. // Turn on lip-tyncrtronizaoon of audio signal to video signal
  • SeiDTM Dureuon // Set dial tone moduia ⁇ on frequency pulse duration
  • RemoteDTMFPiilse // Pulse DTMF at remote sanon
  • Grayscalelmage // Grayscale unage type
  • ColorKey // Overlay des ⁇ na ⁇ on defined by colorkey with source
  • BirwiseXOR II Combine des ⁇ na ⁇ on and source wun bitwise XOR 4055 BicwiseAND. // Combine desnna ⁇ on and source wirh birwise AND

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Cette invention se rapporte à un programme de connectivité multimédia résidant en mémoire accessible en lecture, ledit programme de connectivité assurant, lorsqu'il est exécuté sur un ordinateur, des services de connectivité multimédia par l'intermédiaire d'un sous-système de commande de dispositifs multimédia en temps réel incorporant des composants sélectionnés parmi une pluralité de dispositifs multimédia et une pluralité de piles de protocoles multimédia en temps réel. Ledit programme comporte un unique objet binaire encapsulant une interface de dispositifs virtuels et une interface de commande de dispositifs, ladite interface de dispositifs virtuels incorporant une pluralité de procédés virtuels qui représentent des opérations logiques accessibles par le programme d'application pour commander le sous-système de commande des dispositifs multimédia, la pluralité des fonctions virtuelles étant complètement indépendantes des composants présents à l'intérieur du sous-système de commande des dispositifs, ladite interface de commande des dispositifs mettant en correspondance la pluralité de fonctions virtuelles et des procédés de commande physique qui commandent les composants du sous-système de commande multimédia.
PCT/US1997/015018 1996-08-27 1997-08-27 Systeme virtuel de connexion multimedia Ceased WO1998009213A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US70346396A 1996-08-27 1996-08-27
US08/703,463 1996-08-27

Publications (1)

Publication Number Publication Date
WO1998009213A1 true WO1998009213A1 (fr) 1998-03-05

Family

ID=24825492

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1997/015018 Ceased WO1998009213A1 (fr) 1996-08-27 1997-08-27 Systeme virtuel de connexion multimedia

Country Status (1)

Country Link
WO (1) WO1998009213A1 (fr)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1067455A1 (fr) * 1999-07-09 2001-01-10 CANAL+ Société Anonyme Exécuter et tester applications
WO2001041371A1 (fr) * 1999-12-06 2001-06-07 Telefonaktiebolaget Lm Ericsson (Publ) Formation intelligente de piconet
WO2002067117A1 (fr) * 2001-02-16 2002-08-29 Telefonaktiebolaget L M Ericsson (Publ) Procede et appareil de traitement de donnees dans un environnement multi-processeur
WO2002035789A3 (fr) * 2000-10-25 2002-11-21 Nortel Networks Ltd Technique d'autorisation de service
DE10262035B4 (de) * 2002-10-29 2006-03-23 Oasis Silicon Systems Ag Intelligenter Netzwerk Interface Controller
EP1118934A3 (fr) * 1999-12-30 2006-08-23 Siemens Aktiengesellschaft Technique de contrôle avec communication en temps réel entre objets
EP1372070A4 (fr) * 2001-03-19 2007-04-04 Mitsubishi Electric Corp Dispositif multimedia monte sur vehicule
CN114625347A (zh) * 2022-03-29 2022-06-14 中国工商银行股份有限公司 存储系统sdk的对接方法、装置、设备和存储介质
CN115357387A (zh) * 2022-08-19 2022-11-18 深圳森工科技有限公司 一种多线程可精确定点的多媒体记录及保存方法
CN119940266A (zh) * 2024-12-03 2025-05-06 杭州电子科技大学 一种基于硅基cmos异构集成pcb器件库的pdk开发方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4677588A (en) * 1983-11-14 1987-06-30 International Business Machines Corp. Network interconnection without integration
US5138614A (en) * 1990-04-12 1992-08-11 At&T Bell Laboratories Transformation method for network conference connections
US5226160A (en) * 1989-07-18 1993-07-06 Visage Method of and system for interactive video-audio-computer open architecture operation
US5483647A (en) * 1992-12-17 1996-01-09 Bull Hn Information Systems Inc. System for switching between two different operating systems by invoking the server to determine physical conditions to initiate a physical connection transparent to the user

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4677588A (en) * 1983-11-14 1987-06-30 International Business Machines Corp. Network interconnection without integration
US5226160A (en) * 1989-07-18 1993-07-06 Visage Method of and system for interactive video-audio-computer open architecture operation
US5138614A (en) * 1990-04-12 1992-08-11 At&T Bell Laboratories Transformation method for network conference connections
US5483647A (en) * 1992-12-17 1996-01-09 Bull Hn Information Systems Inc. System for switching between two different operating systems by invoking the server to determine physical conditions to initiate a physical connection transparent to the user

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1067455A1 (fr) * 1999-07-09 2001-01-10 CANAL+ Société Anonyme Exécuter et tester applications
WO2001041371A1 (fr) * 1999-12-06 2001-06-07 Telefonaktiebolaget Lm Ericsson (Publ) Formation intelligente de piconet
US6901057B2 (en) 1999-12-06 2005-05-31 Telefonaktiebolaget Lm Ericsson (Publ) Intelligent piconet forming
EP1118934A3 (fr) * 1999-12-30 2006-08-23 Siemens Aktiengesellschaft Technique de contrôle avec communication en temps réel entre objets
WO2002035789A3 (fr) * 2000-10-25 2002-11-21 Nortel Networks Ltd Technique d'autorisation de service
US7761541B1 (en) 2000-10-25 2010-07-20 Nortel Networks Limited Service enabling technology
WO2002067117A1 (fr) * 2001-02-16 2002-08-29 Telefonaktiebolaget L M Ericsson (Publ) Procede et appareil de traitement de donnees dans un environnement multi-processeur
US6848103B2 (en) 2001-02-16 2005-01-25 Telefonaktiebolaget Lm Ericsson Method and apparatus for processing data in a multi-processor environment
US7231642B2 (en) 2001-03-19 2007-06-12 Mitsubishi Denki Kasbushiki Kaisha Vehicle-mounted multimedia device
EP1372070A4 (fr) * 2001-03-19 2007-04-04 Mitsubishi Electric Corp Dispositif multimedia monte sur vehicule
DE10262035B4 (de) * 2002-10-29 2006-03-23 Oasis Silicon Systems Ag Intelligenter Netzwerk Interface Controller
US8972609B2 (en) 2002-10-29 2015-03-03 Smsc Europe Gmbh Intelligent network interface controller
CN114625347A (zh) * 2022-03-29 2022-06-14 中国工商银行股份有限公司 存储系统sdk的对接方法、装置、设备和存储介质
CN115357387A (zh) * 2022-08-19 2022-11-18 深圳森工科技有限公司 一种多线程可精确定点的多媒体记录及保存方法
CN119940266A (zh) * 2024-12-03 2025-05-06 杭州电子科技大学 一种基于硅基cmos异构集成pcb器件库的pdk开发方法

Similar Documents

Publication Publication Date Title
US5859979A (en) System for negotiating conferencing capabilities by selecting a subset of a non-unique set of conferencing capabilities to specify a unique set of conferencing capabilities
Mungee et al. The design and performance of a CORBA audio/video streaming service
US5506954A (en) PC-based conferencing system
US5490247A (en) Video subsystem for computer-based conferencing system
US5488570A (en) Encoding and decoding video signals using adaptive filter switching criteria
US5434913A (en) Audio subsystem for computer-based conferencing system
US6125398A (en) Communications subsystem for computer-based conferencing system using both ISDN B channels for transmission
Schmidt et al. C++ Network Programming, Volume 2: Systematic Reuse with ACE and Frameworks
US5764915A (en) Object-oriented communication interface for network protocol access using the selected newly created protocol interface object and newly created protocol layer objects in the protocol stack
US8606950B2 (en) System and method for transparently processing multimedia data
US5809235A (en) Object oriented network event management framework
Coulson et al. Extensions to ANSA for multimedia computing
US6405255B1 (en) Mixing and splitting multiple independent audio data streams in kernel space
GB2289186A (en) Collaborative working method and system
EP0620936A1 (fr) Travail en collaboration dans un reseau
CN115913937A (zh) 一种容器多网卡网络配置方法、装置、设备及存储介质
WO1998009213A1 (fr) Systeme virtuel de connexion multimedia
Mines et al. DAVE: A plug and play model for distributed multimedia application development
Tennenhouse et al. A software-oriented approach to the design of media processing environments
US20020029302A1 (en) Method, computer program product, and system for managing connection-oriented media
US20020026536A1 (en) Method, computer program product, and system for separating connection management functionality from a connection-oriented device driver
Lazar et al. Packetized video on MAGNET
Bahl et al. The J300 Family of Video and Audio Adapters: Software Architecture
Leydekkers et al. A computational and engineering view on open distributed real-time multimedia exchange
Nakajima A toolkit for building continuous media applications

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CA IL JP

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: JP

Ref document number: 1998511852

Format of ref document f/p: F

NENP Non-entry into the national phase

Ref country code: CA

122 Ep: pct application non-entry in european phase