t.120
`
`A Primer
`on the
`T.120
`Series
`Standard
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1016 – 001
`
`

`

`A DataBeam Corporation White Paper
`
`A PRIMER ON THE T.120 SERIES STANDARDS
`
`The T.120 standard contains a series of communication
`and application protocols and services that provide sup-
`port for real-time, multipoint data communications.
`These multipoint facilities are important building blocks
`for a whole new range of collaborative applications,
`including desktop data conferencing, multi-user applica-
`tions, and multi-player gaming.
`
`Broad in scope, T.120 is a comprehensive specification
`that solves several problems that have historically slowed
`market growth for applications of this nature. Perhaps
`most importantly, T.120 resolves complex technological
`issues in a manner that is acceptable to both the comput-
`ing and telecommunications industries.
`
`Established by the International Telecommunications
`Union (ITU), T.120 is a family of open standards that
`was defined by leading data communication practitioners
`in the industry. Over 100 key international vendors,
`including Apple, AT&T, British Telecom, Cisco Systems,
`Intel, MCI, Microsoft, and PictureTel, have committed
`to implementing T.120-based products and services.
`
`While T.120 has emerged as a critical element in the data
`communications landscape, the only information that
`currently exists on the topic is a weighty and complicated
`set of standards documents. This primer bridges this
`information gap by summarizing T.120’s major benefits,
`fundamental architectural elements, and core capabilities.
`
`Broad vendor support
`means that end users
`will be able to choose
`from a variety of inter-
`operable products.
`
`A PRIMER ON THE T.120 STANDARD
`
`1
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1016 – 002
`
`

`

`KEY BENEFITS OF T.120
`So why all the excitement about T.120?
`The bottom line is that it provides excep-
`tional benefits to end users, vendors, and
`developers tasked with implementing real-
`time applications. The following list is a
`high-level overview of the major benefits
`associated with the T.120 standard:
`
`Multipoint Data Delivery
`
`T.120 provides an elegant abstraction for
`developers to create and manage a
`multipoint domain with ease. From an
`application perspective, data is seamlessly
`delivered to multiple parties in “realtime.”
`
`A DataBeam Corporation White Paper
`
`viding a flexible solution for mixed unicast
`and multicast networks. The Multicast
`Adaptation Protocol (MAP) is expected to
`be ratified in early 1998.
`Network Transparency
`
`Applications are completely shielded from
`the underlying data transport mechanism
`being used. Whether the transport is a
`high-speed LAN or a simple dial-up
`modem, the application developer is only
`concerned with a single, consistent set of
`application services.
`
`Platform Independence
`
`Because the T.120 standard is completely
`free from any platform dependencies, it
`will readily
`take advantage of
`the
`inevitable advances
`in
`T.120 BENEFITS
`computing technology. In
`4 Multipoint Data Delivery
`fact, DataBeam’s
`cus-
`tomers have already ported
`the T.120 source code eas-
`ily from Windows to a
`variety of environments,
`including
`OS/2,
`MAC/OS, several versions
`of UNIX, and other pro-
`prietary real-time operat-
`ing systems.
`
`4 Interoperability
`
`4 Reliable Data Delivery
`
`4 Multicast Enabled Delivery
`
`4 Network Transparency
`
`4 Platform Independence
`
`4 Network Independence
`
`4 Support for Varied Topologies
`
`4 Application Independence
`
`Interoperability
`T.120 allows endpoint
`applications from multiple
`vendors to interoperate.
`T.120 also specifies how
`applications may interop-
`erate with (or through) a
`variety of network bridg-
`ing products and services
`that also support the T.120
`standard.
`
`Reliable Data
`Delivery
`
`Error-corrected data deliv-
`ery ensures that all end-
`points will receive each
`data transmission.
`
`4 Scalability
`
`4 Co-existence with Other
`Standards
`
`4 Extendability
`
`Network
`Independence
`The T.120 standard sup-
`ports a broad range of
`transport options, includ-
`ing the Public Switched Telephone
`Networks (PSTN or POTS), Integrated
`Switched Digital Networks (ISDN),
`Packet Switched Digital Networks
`(PSDN), Circuit Switched Digital
`Networks (CSDN), and popular local area
`network protocols (such as TCP/IP and
`IPX via reference protocol). Furthermore,
`these vastly different network transports,
`operating at different speeds, can easily co-
`exist in the same multipoint conference.
`
`Multicast Enabled Delivery
`In muliticast enabled networks, T.120 can
`employ reliable (ordered, guaranteed) and
`unreliable delivery services. Unreliable
`data delivery is also available without mul-
`ticast. By using multicast, the T.120 infra-
`structure reduces network congestion and
`improves performance for the end user.
`The T.120 infrastructure can use both
`unicast and multicast simultaneously, pro-
`
`2
`
`A PRIMER ON THE T.120 STANDARD
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1016 – 003
`
`

`

`A DataBeam Corporation White Paper
`
`Support for Varied Topologies
`
`Multipoint conferences can be set up with
`virtually no limitation on network topolo-
`gy. Star
`topologies, with a
`single
`Multipoint Control Unit (MCU) will be
`common early on. The standard also sup-
`ports a wide variety of other topologies
`ranging from those with multiple, cascad-
`ed MCUs to topologies as simple as a
`daisy-chain. In complex multipoint con-
`ferences, topology may have a significant
`impact on efficiency and performance.
`
`Application Independence
`Although the driving market force behind
`T.120 was teleconferencing, its designers
`purposely sought to satisfy a much broad-
`er range of application needs. Today,
`T.120 provides a generic, real-time com-
`munications facility that can be used by
`many different applications. These appli-
`cations include interactive gaming, virtual
`
`reality and simulations, real-time subscrip-
`tion news feeds, and process control appli-
`cations.
`
`Scalability
`
`T.120 is defined to be easily scalable from
`simple PC-based architectures to complex
`multi-processor environments character-
`ized by their high performance. Resources
`for T.120 applications are plentiful, with
`practical limits imposed only by the con-
`fines of the specific platform running the
`software.
`
`Co-existence with Other
`Standards
`T.120 was designed to work alone or with-
`in the larger context of other ITU stan-
`dards, such as the H.32x family of video
`conferencing standards. T.120 also sup-
`ports and cross-references other important
`ITU standards, such as V.series modems.
`
`FIGURE 1: MODEL OF ITU T.120 SERIES ARCHITECTURE
`
`Application(s)
`(Using both Standard and Non-standard Application Protocols)
`
`Application(s)
`(Using Std. App. Protocols)
`
`Node
`Controller
`
`Application(s)
`(Using Std. App. Protocols)
`
`Multipoint File Transfer T.127
`
`Still Image Exchange T.126
`
`....
`
`...
`
`ITU-T Standard
`Application Protocols
`
`Non-standard Application
`Protocols
`
`Generic Application
`Template (GAT) T.121
`
`Generic Application
`Template (GAT) T.121
`
`Generic Conference Control (GCC)
`T.124
`
`Multipoint Communication Service (MCS)
`T.122/125
`
`Network-specific Transport Protocols
`T.123
`
`A PRIMER ON THE T.120 STANDARD
`
`3
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1016 – 004
`
`

`

`Extendability
`
`The T.120 standard can be freely extended
`to include a variety of new capabilities,
`such as support for new transport stacks
`(like ATM or Frame Relay), improved
`security measures, and new application-
`level protocols.
`
`ARCHITECTURAL OVERVIEW
`The T.120 architecture relies on a multi-
`layered approach with defined protocols
`and service definitions between layers.
`Each layer presumes that all layers exist
`below. Figure 1 provides a graphical repre-
`sentation of the T.120 architecture.
`
`The lower level layers (T.122, T.123,
`T.124, and T.125) specify an application-
`independent mechanism for providing
`multipoint data communication services
`to any application that can use these facil-
`ities. The upper level layers (T.126 and
`T.127) define protocols for specific con-
`ferencing applications, such as shared
`whiteboarding and multipoint file trans-
`fer. Applications using these standardized
`protocols can co-exist in the same confer-
`ence with applications using proprietary
`protocols. In fact, a single application may
`even use a mix of standardized and non-
`standardized protocols.
`
`A DataBeam Corporation White Paper
`
`COMPONENT OVERVIEW
`
`The following overview describes the key
`characteristics and concepts behind each
`individual component of the T.120 stan-
`dard. This overview starts at the bottom of
`the T.120 stack and progresses upward.
`
`Transport Stacks - T.123
`T.120 applications expect the underlying
`transport to provide reliable delivery of its
`Protocol Data Units (PDUs) and to seg-
`ment and sequence that data. T.123 speci-
`fies transport profiles for each of the fol-
`lowing:
`
`• Public Switched Telephone
`• Networks (PSTN)
`• Integrated Switched Digital
`• Networks (ISDN)
`• Circuit Switched Digital
`• Networks (CSDN)
`• Packet Switched Digital
`• Networks (PSDN)
`• TCP/IP
`• Novell Netware IPX
`• (via reference profile)
`
`As highlighted below in Figure 2, the
`T.123 layer presents a uniform OSI trans-
`port interface and services (X.214/X.224)
`
`FIGURE 2: CROSS-SECTION OF T.123 TRANSPORTS (BASIC MODE PROFILES)
`
`Multipoint Communication Service (T.122/T.125)
`
`Transport Layer
`(Layer 4)
`
`X.224 \ 0
`
`X.224 \ 0
`
`X.224 \ 0
`
`X.224 \ 0
`RFC1006
`
`null + SCF
`
`null + SCF
`
`null + SCF
`
`T.123
`
`Q.922
`
`Q.922
`
`Q.922
`
`*
`
`COM.DRV
`
`H.221 MLP
`
`X.21 or X.21 bis
`
`NWIPXSPX.DLL
`
`WINSOCK.DLL
`
`Platform-specific
`Interface (Windows)
`
`PSTN
`
`ISDN
`
`IPX
`
`TCP/IP
`
`4
`
`* Subset of Q.922
`
`A PRIMER ON THE T.120 STANDARD
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1016 – 005
`
`

`

`A DataBeam Corporation White Paper
`
`to the MCS layer above. The T.123 layer
`includes built-in error correction facilities
`so application developers do not have to
`rely on special hardware facilities to per-
`form this function.
`
`available, such as IP networks. While mul-
`ticast provides unreliable delivery, many
`applications using T.120 require reliable
`services. Developers can incorporate a
`variety of multicast error correction
`schemes into MAP, thereby selecting the
`scheme most closely aligned with their
`application.
`
`In a given computing environment, a
`transport stack typically plugs into a local
`facility that provides an interface to the
`specific transport connection. For exam-
`In 1996, the ITU is expected to adopt
`ple,
`in the Windows environment,
`extensions to support important new
`DataBeam’s transport stacks
`transport
`facilities, such as
`The MCU is a logical
`plug into COMM.DRV for
`Asynchronous Transfer Mode
`construct whose role
`modem
`communications,
`(ATM) and H.324 POTS
`may be served by a
`WINSOCK.DLL for TCP/IP
`videophone. It is necessary to
`node on a desktop
`and UDP/IP communications,
`note that developers can easily
`or by special-
`and NWIPXSPX. DLL for
`produce a proprietary transport
`purpose equipment
`within the network.
`Novell IPX communications
`stack (supporting, for example,
`support.
`AppleTalk) that transparently
`uses the services above T.123. An impor-
`tant function of MCUs or T.120-enabled
`bridges, routers, or gateways is to provide
`transparent interworking across different
`network boundaries.
`
`The Multicast Adaptation Protocol
`(MAP) service layer is a new extension to
`MCS. MAP manages unicast- and multi-
`cast-based transports. MAP can be used
`with any transport where multicast is
`
`FIGURE 3: EXAMPLES OF VALID MCS TOPOLOGIES
`
`TOP PROVIDER
`
`MCU
`
`MCU
`
`NODE
`
`NODE
`
`NODE
`
`NODE
`
`NODE
`
`CASCADED MCU TOPOLOGY
`
`TOP PROVIDER
`
`MCU
`
`NODE
`
`NODE
`
`NODE
`
`TOP PROVIDER
`
`MCU
`
`NODE
`
`NODE
`
`NODE
`
`DAISY-CHAIN TOPOLOGY
`
`TRADITIONAL STAR TOPOLOGY
`
`A PRIMER ON THE T.120 STANDARD
`
`5
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1016 – 006
`
`

`

`Multipoint Communication
`Service (MCS) - T.122, T.125
`
`T.122 defines the multipoint services
`available to the developer, while T.125
`specifies the data transmission protocol.
`Together they form MCS, the multipoint
`“engine” of the T.120 conference. MCS
`relies on T.123 to deliver the data. (Use of
`MCS is entirely independent of the actual
`T.123 transport stack(s) that is loaded.)
`
`FIGURE 4: CHANNEL DIAGRAM
`
`DOMAIN
`
`Private
`Channel
`
`Broadcast
`Channel
`
`Broadcast
`Channel
`
`Private
`Channel
`
`MCS is a powerful tool that can be used to
`solve virtually any multipoint application
`design requirement. MCS is an elegant
`abstraction of a complex organism.
`Learning to use MCS effectively is the key
`to successfully developing real-time appli-
`cations.
`
`How MCS Works
`
`TABLE 1: CHANNEL SETUP EXAMPLE
`
`A DataBeam Corporation White Paper
`
`In a T.120 conference, nodes connect up-
`ward to a Multipoint Control Unit
`(MCU). The MCU model in T.120 pro-
`vides a reliable approach that works in
`both public and private networks.
`Multiple MCUs may be easily chained
`together in a single domain. Figure 3 illus-
`trates three potential topology structures.
`Each domain has a single Top Provider or
`MCU that houses the information base
`critical to the conference. If the Top
`Provider either fails or leaves a conference,
`the conference is terminated. If a lower
`level MCU (i.e., not the Top Provider)
`fails, only the nodes on the tree below that
`MCU are dropped from the conference.
`Because all nodes contain MCS, they are
`all potentially “MCUs.”
`
`One of the critical features of the T.120
`approach is the ability to direct data. This
`feature allows applications to communi-
`cate efficiently. MCS applications direct
`data within a domain via the use of chan-
`nels. An application can choose to use
`multiple channels simultaneously for
`whatever purposes it needs (for example,
`separating annotation and file transfer
`operations). Application instances choose
`to obtain information by subscribing to
`whichever channel(s) contains the desired
`data. These channel assignments can be
`dynamically changed during the life of the
`conference. Figure 4 presents an overview
`of multiple channels in use within a
`domain.
`
`It is the application developer’s responsi-
`bility to determine how to use channels
`
`Type
`Error Control Channels
`
`Annotations
`
`Bitmap Images
`
`File Transfer
`
`Priority
`Top
`
`Routing
`Standard
`
`High
`
`Uniform
`
`Medium
`
`Uniform
`
`Low
`
`Standard
`
`In a conference, multiple endpoints (or
`MCS nodes) are
`logically connected
`together to form what T.120 refers to as a
`domain. Domains generally equate to the
`concept of a conference. An application
`may actually be attached to
`multiple domains simulta-
`neously. For example, the
`chairperson of a
`large
`online
`conference may
`simultaneously monitor
`information being dis-
`cussed among several activ-
`ity groups.
`
`Channel
`
`1 2 3 4
`
`6
`
`A PRIMER ON THE T.120 STANDARD
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1016 – 007
`
`

`

`A DataBeam Corporation White Paper
`
`within an application. For example, an
`application may send control information
`along a single channel and application
`data along a series of channels that may
`vary depending upon the type of data
`being sent. The application developer may
`also take advantage of the MCS concept of
`private channels to direct data to a discrete
`subset of a given conference.
`
`Data may be sent with one of four priori-
`ty levels. MCS applications may also spec-
`ify that data is routed along the quickest
`path of delivery using the standard send
`command. If the application uses the uni-
`form send command, it ensures that data
`from multiple senders will arrive at all des-
`tinations in the same order. Uniform data
`always travels all the way up the tree to the
`Top Provider. Table 1 provides an example
`of how a document conferencing applica-
`tion could set up its channels. Reliable or
`unreliable data delivery is determined by
`the application.
`
`There are no constraints on the size of the
`data sent from an application to MCS.
`Segmentation of data is automatically per-
`formed on behalf of the application.
`However, after receiving the data it is the
`application’s responsibility to reassemble
`the data by monitoring flags provided
`when the data is delivered.
`
`Tokens are the last major facility provided
`by MCS. Services are provided
`to grab, pass, inhibit, release,
`and query
`tokens. Token
`resources may be used as either
`exclusive (i.e., locking) or non-
`exclusive entities.
`
`Tokens can be used by an appli-
`cation in a number of ways. For example,
`an application may specify that only the
`holder of a specific token, such as the con-
`ductor, may send information in the con-
`ference.
`
`Another popular use of tokens is to coor-
`dinate tasks within a domain. For exam-
`ple, suppose a teacher wants to be sure
`that every student in a distance learning
`session answered a particular question
`before displaying the answer. Each node in
`the underlying application inhibits a spe-
`cific token after receiving the request to
`answer the question. The token is released
`by each node when an answer is provided.
`In the background, the teacher’s applica-
`tion continuously polls the state of the
`token. When all nodes have released the
`token, the application presents the teacher
`with a visual cue that the class is ready for
`the answer.
`
`Generic Conference Control
`(GCC) - T.124
`
`Generic Conference Control provides a
`comprehensive set of facilities for estab-
`lishing and managing the multipoint con-
`ference. It is with GCC that we first see
`features that are specific to the electronic
`conference.
`
`At the heart of GCC is an important
`information base about the state of the
`various conferences it may be servicing.
`One node, which may be the MCU itself,
`serves as the Top Provider for GCC infor-
`mation. Any actions or requests from
`lower GCC nodes ultimately filter up to
`this Top Provider.
`
`Using mechanisms in GCC,
`applications create conferences,
`join conferences, and invite
`others to conferences. As end-
`points join and leave confer-
`ences, the information base in
`GCC is updated and can be
`used to automatically notify all endpoints
`when these actions occur. GCC also
`knows who is the Top Provider for the
`conference. However, GCC does not con-
`tain detailed topology information about
`the means by which nodes from lower
`branches are connected to the conference.
`
`One of GCC’s most
`important roles is to
`maintain information
`about the nodes and
`applications that are
`in a conference.
`
`A PRIMER ON THE T.120 STANDARD
`
`7
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1016 – 008
`
`

`

`A DataBeam Corporation White Paper
`
`FIGURE 5: T.121 GENERIC APPLICATION TEMPLATE
`
`User Application(s)
`
`Node Controller
`
`Generic Application Template (T.121)
`
`Application Resource
`Manager (ARM)
`
`Application Service
`Element(s) (ASE)
`
`Generic Conference Control (GCC)
`T.124
`
`Multipoint Communication Service (MCS)
`T.122/125
`
`Every application in a conference must
`register its unique application key with
`GCC. This enables any subsequent join-
`ing nodes to find compatible applications.
`Furthermore, GCC provides robust facili-
`ties for applications to exchange capabili-
`ties and arbitrate feature sets. In this way,
`applications from different vendors can
`readily establish whether or not they can
`interoperate and at what feature level. This
`arbitration facility is the mechanism used
`to ensure backward compatibility between
`different versions of the same application.
`
`GCC also provides conference security.
`This allows applications to incorporate
`password protection or “lock” facilities to
`prevent uninvited users from joining a
`conference.
`
`Another key function of GCC is its abili-
`ty to dynamically track MCS resources.
`Since multiple applications can use MCS
`at the same time, applications rely on
`GCC to prevent conflicts for MCS
`resources, such as channels and tokens.
`This ensures that applications do not step
`on each other by attaching to the same
`channel or requesting a token already in
`use by another application.
`
`Finally, GCC provides capabilities for sup-
`porting the concept of conductorship in a
`conference. GCC allows the application to
`identify the conductor and a means in
`which to transfer the conductor’s “baton.”
`The developer is free to decide how to use
`these conductorship facilities within the
`application.
`
`T.124 Revised
`
`As part of the ongoing enhancement
`process for the T.120 standards, the ITU
`has completed a draft revision of T.124.
`The new version, called T.124 Revised,
`introduces a number of changes to
`improve scalability. The most significant
`changes address the need to distribute ros-
`ter information to all nodes participating
`in a conference, as well as improvements
`in the efficiency of sending roster refresh
`information (from the Top Provider) any
`time a node joins or leaves a conference.
`
`To improve the distribution of roster
`information,
`the concept of Node
`Categories was introduced. These cate-
`gories provide a way for a T.124 node to
`join or leave a conference without affect-
`ing the roster information that was dis-
`tributed throughout a conference. In addi-
`
`8
`
`A PRIMER ON THE T.120 STANDARD
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1016 – 009
`
`

`

`A DataBeam Corporation White Paper
`
`FIGURE 6: T.126 WORKSPACE DIAGRAM
`
`Bitmap
`
`Annotations
`
`tion, the Full Roster Refresh, which was
`previously sent any time a new node
`joined a conference, was eliminated by
`sending out roster details from the Top
`Provder. These changes will not affect
`backward compatibility to earlier revisions
`of T.124. This revision will go to the ITU
`for Decision in March of 1998.
`
`Generic Application Template
`(GAT) - T.121
`
`T.121 provides a template for T.120
`resource management that developers
`should use as a guide for building applica-
`tion protocols. T.121 is mandatory for
`standardized application protocols and is
`highly recommended for non-standard
`application protocols. The
`template
`ensures consistency and reduces the
`potential
`for unforeseen
`interaction
`between different protocol implementa-
`tions.
`
`A PRIMER ON THE T.120 STANDARD
`
`Within the T.121 model, GAT defines a
`generic Application Resource Manager
`(ARM). This entity manages GCC and
`MCS resources on behalf of the applica-
`tion
`protocol-specific
`functionality
`defined as an Application Service Element
`(ASE). Figure 5 demonstrates the GAT
`model within the T.120 architecture.
`Simply put, GAT provides a consistent
`model for managing T.120 resources
`required by the application to which the
`developer adds application-specific func-
`tionality.
`
`GAT’s functionality is considered to be
`generic and common to all application
`protocols. GAT’s
`services
`include
`enrolling the application in GCC and
`attaching to MCS domains. GAT also
`manages channels, tokens, and capabilities
`on behalf of the application. On a broad-
`er scale, GAT responds to GCC indica-
`
`9
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1016 – 010
`
`

`

`A DataBeam Corporation White Paper
`
`FIGURE 7: T.127 FILE TRANSFER MODEL
`
`Current transmitter
`sourcing files A and B
`
`MBFT
`
`A
`
`B
`
`Node that requires
` file A
`
`Node that requires
` files A and B
`
`MBFT
`
`A
`
`MBFT
`
`A
`
`B
`
`MCS
`Provider
`
`Top MCS
`Provider
`
`MCS
`Provider
`
`MCS
`Provider
`
`Data Channels
`
`Control Channel
`
`tions and can invoke peer applications on
`other nodes in the conference.
`
`Still Image Exchange and
`Annotation (SI) - T.126
`
`T.126 defines a protocol for viewing and
`annotating
`still
`images
`transmitted
`between two or more applications. This
`capability is often referred to as document
`conferencing or shared whiteboarding.
`
`An important benefit of T.126 is that it
`readily shares visual information between
`applications that are running on dramati-
`cally different platforms. For example, a
`Windows-based desktop application could
`easily interoperate with a collaboration
`program running on a PowerMac.
`Similarly, a group-oriented conferencing
`system, without a PC-style interface,
`could share data with multiple users run-
`ning common PC desktop software.
`
`As Figure 6 illustrates, T.126 presents the
`concept of shared virtual workspaces that
`are manipulated by the endpoint applica-
`tions. Each workspace may contain a col-
`lection of objects that include bitmap
`images and annotation primitives, such as
`rectangles and freehand lines. Bitmaps
`typically originate from application infor-
`mation, such as a word processing docu-
`
`ment or a presentation slide. Because of
`their size, bitmaps are often compressed to
`improve performance over lower-speed
`communication links.
`
`T.126 is designed to provide a minimum
`set of capabilities required to share infor-
`mation between disparate applications.
`Because T.126 is simply a protocol, it does
`not provide any of the API-level structures
`that allow application developers to easily
`incorporate shared whiteboarding into an
`application. These types of facilities can
`only be found in toolkit-level implemen-
`tations of
`the
`standard
`(such as
`DataBeam’s
`Shared Whiteboard
`Application Toolkit, known as SWAT).
`
`Multipoint Binary File Transfer
`- T.127
`
`T.127 specifies a means for applications to
`transmit files between multiple endpoints
`in a conference. Files can be transferred to
`all participants in the conference or to a
`specified
`subset of
`the conference.
`Multiple file transfer operations may
`occur simultaneously in any given confer-
`ence and developers can specify priority
`levels for the file delivery. Finally, T.127
`provides options for compressing files
`before delivering the data. Figure 7 dis-
`
`10
`
`A PRIMER ON THE T.120 STANDARD
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1016 – 011
`
`

`

`A DataBeam Corporation White Paper
`
`FIGURE 8: NETWORK-LEVEL INTEROPERABILITY DIAGRAM
`
`PROPRIETARY
`DATA CONFERENCING
`APPLICATION
`
`Generic
`Conference
`Control
`
`GCC
`
`MULTIPOINT
`CONTROL UNIT
`
`GCC
`
`PROPRIETARY
`DATA CONFERENCING
`APPLICATION
`
`GCC
`
`MCS
`
`T.122/T.125
`
`T.122/T.125
`
`T.122/T.125
`
`Network
`aspects
`
`T.123
`
`T.123
`
`T.123
`
`T.123
`
`T.123
`
`plays a view of conference-wide and indi-
`vidual file transfers.
`
`Node Controller
`
`The Node Controller manages defined
`GCC Service Access Points (SAPs). This
`provides the node flexibility in responding
`to GCC events. Most of these GCC events
`relate to establishing conferences, adding
`or removing nodes from a conference, and
`breaking down and distributing informa-
`tion. The Node Controller’s primary
`responsibility is to translate these events
`and respond appropriately.
`
`Some GCC events can be handled auto-
`matically; for example, when a remote
`party joins a conference, each local Node
`Controller can post a simple message
`informing the local user that “Bill Smith
`has joined the conference.” Other events
`may require user intervention; for exam-
`ple, when a remote party issues an invita-
`tion to join a conference, the local Node
`Controller posts a dialog box stating that
`“Mary Jones has invited you to the Design
`Review conference. <Accept> <Decline>.”
`
`Node controllers can be MCU-based, ter-
`minal-based, or dual-purpose. DataBeam’s
`application, FarSite, for example, contains
`a dual-purpose Node Controller. The
`
`Another Terminal or MCU
`
`range of functionality found within a
`Node Controller can vary dramatically by
`implementation.
`
`Only one Node Controller can exist on an
`active T.120 endpoint. Therefore, if multi-
`ple applications need to simultaneously
`use T.120 services, the Node Controller
`needs to be accessible to each application.
`The local interface to the Node Controller
`is application- and vendor-specific and is
`not detailed in the T.120 documentation.
`
`INTEROPERABILITY
`
`Buyers overwhelmingly rate interoperabil-
`ity as the number one purchase criteria in
`their evaluation of teleconferencing prod-
`ucts. For most end users, interoperability
`translates to “my application can talk to
`your application”—regardless of which
`vendor supplied the product or on what
`platform it runs. When examining the
`T.120 standard closely, buyers can see that
`it provides for two levels of interoperabili-
`ty: application-level interoperability and
`network-level interoperability.
`
`Network-level Interoperability
`Network-level interoperability means that
`a given product can interwork with like
`products through the infrastructure of
`
`A PRIMER ON THE T.120 STANDARD
`
`11
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1016 – 012
`
`

`

`A DataBeam Corporation White Paper
`
`FIGURE 9: APPLICATION-LEVEL INTEROPERABILITY DIAGRAM
`
`DATABEAM'S
` STANDARDS-BASED
`APPLICATION
`
`T.126
`
`Generic
`Conference
`Control
`
` GCC
`
` MULTIPOINT
`CONTROL
`UNIT
`
`GCC
`
`OTHER STANDARDS-BASED
`DATA CONFERENCING
`APPLICATION
`
`T.126
`
` GCC
`
`MCS
`
`T.122/T.125
`
`T.122/T.125
`
`T.122/T.125
`
`Network
`aspects
`
`T.123
`
`T.123
`
`T.123
`
`T.123
`
`T.123
`
`network products and services that sup-
`port T.120. For example, T.120-based
`conferencing bridges (MCUs) that can
`support hundreds of simultaneous users
`are now being developed. If an application
`supports only the lower layers of T.120,
`customers can use these MCUs to host a
`multipoint conference only if everyone in
`the conference is using the exact same
`product. Figure 8 displays network inter-
`operability through a conference of like
`products.
`
`Application-level
`Interoperability
`
`The upper levels of T.120 specify proto-
`cols for common conferencing applica-
`tions, such as shared whiteboarding and
`binary file transfer. Applications support-
`ing these protocols can interoperate with
`any other application that provides similar
`support, regardless of the vendor or plat-
`form used. For example, through T.126,
`users of DataBeam’s FarSite application
`will be able to share and mark up docu-
`ments with users of group conferencing
`systems. This interoperability will exist in
`simple point-to-point conferences as well
`as large multipoint conferences using a
`conference bridge. Figure 9 represents
`
`12
`
`Anothe
`terminal or
`r
`MCU
`
`application-level interoperability between
`two standards-based applications connect-
`ed in a conference.
`
`In the short-term, network-level interop-
`erability will be the most common form of
`T.120 support found in conferencing
`applications. This is largely due to the fact
`that the lower-level T.120 layers were rati-
`fied by the ITU more than a year in
`advance of the application-level layers.
`However, end users will not be satisfied
`with network interoperability alone. For
`the market to grow, vendors will have to
`deliver the same application-level interop-
`erability (or endpoint interoperability)
`that customers enjoy today with fax
`machines and telephones.
`
`RATIFICATION OF THE T.120
`AND FUTURE T.130
`STANDARDS
`The Recommendations for the core
`multipoint communications infrastruc-
`ture components (T.122, T.123, T.124
`and T.125) were ratified by the ITU
`between March of 1993 and March of
`1995. The first of the application stan-
`dards (T.126 and T.127) was approved in
`
`A PRIMER ON THE T.120 STANDARD
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1016 – 013
`
`

`

`A DataBeam Corporation White Paper
`
`March of 1995. An overview of the T.120
`series was approved in February of 1996 as
`Recommendation T.120. T.121 (GAT)
`was also approved at that time. Stable
`drafts of these recommendations existed
`for some time prior to the ratification,
`thereby providing a means for DataBeam
`to actively develop products in parallel to
`the standardization effort.
`
`The existing ratified standards are being
`actively discussed for possible amend-
`ments and extensions. This commonly
`occurs when implementation and interop-
`erability issues arise.
`
`T.130 Audio-visual Control For
`Multimedia Conferencing
`
`The T.130 series of recommendations
`define an architecture, a management and
`control protocol, and a set of services
`which together make up an Audio-Visual
`
`Control system (AVC). This system sup-
`ports the use of real-time streams and ser-
`vices in a multimedia conferencing envi-
`ronment. The protocol and services sec-
`tion, outlined in T.132, consists of two
`parts: management and control. Together,
`they allow Network Elements, such as the
`traditional MCU, Gateway, or Conference
`Server, to provide T.132 audio and video
`services to their endpoints. Some of the
`services include Stream Identification,
`On-Air Identification, Video Switching,
`Audio Mixing, Remote Device Control,
`and Continuous Presence.
`
`The T.130 series is built upon existing
`ITU-T conferencing recommendations
`such as the H.320 audio-visual conferenc-
`ing series and the T.120 series for
`multipoint data conferencing. The T.130
`series is compatible with systems, such as
`H.323, in which audio and video are
`
`FIGURE 10: AUDIO-VISUAL CONTROL ARCHITECTURE
`
`Real-
`time
`Audio
`Device
`
`Real-
`time
`Video
`Device
`
`Network-specific
`Mappings
`T.131 (NSM)
`
`User Applications
`
`Node Controller
`
`ITU-T Standard Application
`Protocol Entities
`
`Non-standard Application
`Protocol Entities
`
`Audio
`Stream(s)
`
`Video
`Stream(s)
`
`Control
`
`Audio-visual
`Control
`T.132 (AVC)
`
`Generic Conference
`Control
`T.124 (GCC)
`
`Multipoint Communication Service
`T.122/T.125 (MCS)
`
`Network-specific Transport
`Protocols (T.123)
`
`Data
`
`Network-specific
`Control Entity
`
`Control
`
`Network Multiplex
`
`A PRIMER ON THE T.120 STANDARD
`
`13
`