(12) United States Patent
`Gross et al.
`
`USOO6553515B1
`(10) Patent No.:
`US 6,553,515 B1
`(45) Date of Patent:
`Apr. 22, 2003
`
`(54) SYSTEM, METHOD AND COMPUTER
`PROGRAM PRODUCT FOR DIAGNOSTIC
`SUPERVISION OF INTERNET
`CONNECTIONS
`
`(75) Inventors: Charles J. Gross, Earlysville, VA (US);
`James R. Hartless, Faber, VA (US);
`Vijay K. Sharma, Charlottesville, VA
`(US); Michael A. Starr, Charlottesville,
`VA (US)
`(73) Assignee: Comdial Corporation, Sarasota, FL
`(US)
`
`(*) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(21) Appl. No.: 09/393,659
`(22) Filed:
`Sep. 10, 1999
`7
`(51) Int. Cl.' ................................................. G06F 11/00
`(52) U.S. Cl. ............................... 714/47; 714/4; 714/25;
`714/43; 709/224
`(58) Field of Search ................................ 714/47, 4, 25,
`714/43, 48, 44, 56, 46, 57; 709/224
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`5,655,068 A * 8/1997 Opoczynski ................... 714/4
`5,696,701 A * 12/1997 Burgess et al. ...
`... 702/186
`6,108,800 A
`8/2000 Asawa ........................ 71.4/26
`6,138,249 A * 10/2000 Nolet .......................... 71.4/25
`6,205,413 B1
`3/2001 Bisdikian et al. ............. 703/23
`6,237,114 B1 * 5/2001 Wookey et al. ............... 714/47
`6.286,058 B1 * 9/2001 Hrastar et al. .............. 709/218
`
`6.289,379 B1 * 9/2001 Urano et al................. 709/223
`6,367,037 B1 * 4/2002 Remer et al. ............... 710/105
`6,470,385 B1 * 10/2002 Nakashima et al. ........ 709/224
`* cited b y examiner
`Primary Examiner Robert BeauSoliel
`Assistant Examiner-Christopher R. McGrath
`(74) Attorney, Agent, or Firm-Sterne, Kessler, Goldstein
`& Fox
`ABSTRACT
`(57)
`A System, method and computer program product for man
`aging diagnostic and performance information for commu
`nications System terminal endpoints (TES) communicating
`OVC a Internet Protocol (IP) network. The TEs communi
`cate by connections that are voice, modem, facsimile, Video,
`data transmissions, or the like. A Diagnostic Supervisor (DS)
`transmits Diagnostic Configuration Messages (DCMs) to the
`TEs. The TE's generate Diagnostic Messages (DMs) based
`on diagnostic information, including error Statistics, Voice
`Statistics, facsimile Statistics, Video Statistics, data Statistics,
`or the like, concerning IP network connections in which the
`TEs participate. The DCMs instructs the TES how to format
`and when to transmit DMs. The DMs are transmitted by the
`TES to the DS. In a System with more that one DS, the TES
`can transmit DMs to the plural DSs, other TES or any
`network devices. The DS can be programmed locally or
`remotely to send various types of DCMs. The DS can also
`be programmed locally or remotely to provide diagnostic
`reports based on DMs to network users or to the network
`administrator. Diagnostic information is used for disconnect
`Supervision, answer detection, attendant Supervision, billing
`management, rerouting of IP connections to the PSTN, and
`the like.
`
`54 Claims, 13 Drawing Sheets
`
`204
`
`PPhone TEf DS
`
`208
`
`Server TEf DS
`
`CD TE
`
`
`
`
`
`212S
`
`Cienti TE
`
`PC TE DS
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 001
`
`

`

`U.S. Patent
`
`Apr. 22, 2003
`
`Sheet 1 of 13
`
`US 6,553,515 B1
`
`O
`v
`ver
`
`H
`
`2.
`u
`2
`
`V
`
`|| 0
`L
`
`CO
`
`25
`
`CO
`O
`v
`
`CO O
`v-
`
`Lif
`-
`
`O
`
`O
`
`O
`
`V
`\-
`9
`
`Lif
`H
`
`ON-1
`w
`
`Li
`H
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 002
`
`

`

`U.S. Patent
`
`Apr. 22, 2003
`
`Sheet 2 of 13
`
`US 6,553,515 B1
`
`SC] / El_| / Od
`
`
`
`
`
`
`
`
`
`
`
`ZOZ
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 003
`
`

`

`U.S. Patent
`
`Apr. 22, 2003
`
`Sheet 3 of 13
`
`US 6,553,515 B1
`
`
`
`
`
`| LNE ITIO
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 004
`
`

`

`U.S. Patent
`
`Apr. 22, 2003
`
`Sheet 4 of 13
`
`US 6,553,515 B1
`
`907
`
`
`
`
`
`
`
`
`
`
`
`}}
`}}
`
`----************************| ~ || |O/|
`
`807
`
`
`
`suon?ölunu?uoo ;º)
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 005
`
`

`

`U.S. Patent
`
`Apr. 22, 2003
`
`Sheet 5 of 13
`
`US 6,553,515 B1
`
`
`
`SXAOV WOO. —>
`
`
`
`WOC] <!—
`
`WOCJ
`
`9. "SDH
`
`
`
`
`
`
`
`
`
`
`
`Z07
`
`909
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 006
`
`

`

`U.S. Patent
`
`Apr. 22, 2003
`
`Sheet 6 of 13
`
`US 6,553,515 B1
`
`|----
`
`
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 007
`
`

`

`U.S. Patent
`
`Apr. 22, 2003
`
`Sheet 7 of 13
`
`US 6,553,515 B1
`
`
`
`907
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`~~
`
`80/
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 008
`
`

`

`U.S. Patent
`
`Apr. 22, 2003
`
`Sheet 8 of 13
`
`US 6,553,515 B1
`
`0 || ||
`
`
`
`
`
`
`
`
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 009
`
`

`

`U.S. Patent
`
`Apr. 22, 2003
`
`Sheet 9 of 13
`
`US 6,553,515 B1
`
`
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 010
`
`

`

`U.S. Patent
`
`Apr. 22, 2003
`
`Sheet 10 of 13
`
`US 6,553,515 B1
`
`Establish IP
`Connection
`
`-N- 1002
`
`Initialize Silence & Non-Silence
`Counters & Start Timer
`
`1004
`
`Silent
`Packet
`
`1006
`
`Non-Silent
`Packet
`
`Increment
`Silent
`Counter
`
`- 1008
`
`1010
`
`
`
`Increment
`Non-Silent
`Counter
`
`
`
`
`
`
`
`(N- 1012
`
`
`
`
`
`
`
`Time
`Expired
`2
`
`Yes
`
`Calculate silent/Non-silent
`Packet Percentage
`
`1016
`
`N 1 O20
`---
`NO
`
`(N- 1018
`
`Yes
`
`-N
`
`1024
`
`Send D.M.
`
`1022
`
`FIG. 10
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 011
`
`

`

`U.S. Patent
`
`Apr. 22, 2003
`
`Sheet 11 of 13
`
`US 6,553,515 B1
`
`EStablish IP
`Connection
`
`1102
`
`Initialize Timer & Counter h- 1104
`
`-b
`
`Read Pameter h-1106
`store value
`n. 1108
`
`v
`
`
`
`Increment Counter
`
`1110
`
`Time N- 1112
`Expired
`
`NO
`
`1116
`
`Yes
`
`or r '------
`Calculate
`Average
`
`--------------
`Calculate
`Total Events
`
`N- 112O
`
`Limit
`Exceeded
`
`1122
`
`
`
`
`
`
`
`
`
`
`
`
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 012
`
`

`

`U.S. Patent
`U.S. Patent
`
`Apr.22, 2003
`
`Sheet 12 of 13
`
`US 6,553,515 B1
`US 6,553,515 B1
`
`1204
`
`3
`A
`~
`
`N
`
`=
`O
`LL.
`
`
`
`
`Attendantn
`
`
`co
`
`=e
`©
`Zo
`c
`#
`xt
`
`&
`“I
`re
`
`<=
`ec
`©
`Zo
`c
`
`2x
`
`009
`800
`
`E
`
`OoSACL»
`008
`
`CO
`
`LX110
`
`b
`Lu
`
`Z
`WW:
`<
`
`LW
`oN E
`
`009
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 — 013
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 013
`
`

`

`U.S. Patent
`
`Apr. 22, 2003
`
`Sheet 13 of 13
`
`US 6,553,515 B1
`
`
`
`Z09 ||
`
`Z09 ||
`
`008
`
`009
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 014
`
`

`

`US 6,553,515 B1
`
`1
`SYSTEM, METHOD AND COMPUTER
`PROGRAM PRODUCT FOR DIAGNOSTIC
`SUPERVISION OF INTERNET
`CONNECTIONS
`
`BACKGROUND OF THE INVENTION
`
`2
`locally or remotely to provide diagnostic reports based on
`DMs that were delivered to network users or to the network
`administrator, for example.
`In one embodiment of the present invention, the System
`can reroute an IP network connection between two or more
`TEs to the public switched telephone network (PSTN) based
`on the diagnostic information. Rerouting can be initiated by
`the DS, a TE, or by a TE with DS capabilities. Alternatively,
`rerouting can be initiated by a TE user, the network admin
`istrator or a communications System attendant.
`In another embodiment of the present invention, DCMs
`can be configured to instruct TEs to transmit DMs including
`Silent packet diagnostic information. The Silent packet diag
`nostic information can be used to provide the System with
`disconnect Supervision of IP connections by determining the
`average number of Silent packets detected over a period of
`time, or by a total count of Silent packets.
`In still another embodiment of the present invention,
`DCMs can be configured to instruct TEs to transmit DMs
`including non-Silent packet diagnostic information. The
`non-Silent packet diagnostic information can be used to
`provide the system with answer detection Supervision of IP
`connections by determining the average number of non
`Silent packets detected over a period of time, or by a total
`count of non-Silent packets.
`In yet another embodiment of the present invention, the
`diagnostic information comprises a plurality of parameters
`defined by the DCMs and the DMs. A DS or TE can be
`programmed to determine an average number of occurrences
`of one of the plurality of parameters or a total number of
`occurrences of one of the plurality of parameters.
`One embodiment of the present invention provides for
`attendant Supervision of the communications System. In this
`embodiment a human attendant provides real-time response
`to the diagnostic information. Alternatively, billing manage
`ment can be performed for the communications System
`using diagnostic information. For example, billing of an IP
`network connection, or a connection rerouted to the PSTN,
`is performed based on the diagnostic information provided
`by DMs.
`In a preferred embodiment of the present invention, the
`DS comprises a Configuration Manager, a Report Manager,
`a Real-Time Response Manager, and an Input/Output (I/O)
`Manager coupled to the IP network and the PSTN. The DS
`can also include a communications System So that it can
`function as a TE.
`Further features and advantages of the present invention,
`as well as the Structure and operation of various embodi
`ments of the present invention, are described in detail below
`with reference to the accompanying drawings.
`BRIEF DESCRIPTION OF THE DRAWINGS
`The present invention is described with reference to the
`accompanying drawings. In the drawings, like reference
`numbers indicate identical or functionally Similar elements.
`Additionally, the left-most digit(s) of a reference number
`identifies the drawing in which the reference number first
`appearS.
`FIG. 1 illustrates a System for communicating diagnostics
`or other feedback concerning IP connections from one or
`more terminal endpoints (TES) to a Diagnostic Supervisor
`(DS) according to an embodiment of the present invention.
`FIG. 2 illustrates various types of TES in a system similar
`to that depicted in FIG. 1 for communicating diagnostics or
`other feedback concerning IP connections according to
`another embodiment of the, present invention.
`
`15
`
`1. Field of the Invention
`This invention generally relates to communications, and
`more specifically to a System, method and computer pro
`gram product for diagnostics Supervision of Internet
`connections, Such as VoIP calls.
`2. Related Art
`The uses of the public Internet are very diverse. A use that
`has recently gained much attention is Voice-over-Internet
`Protocol (VoIP) technology, which involves using the public
`Internet or a private IP network to carry voice calls, either
`partially or completely bypassing the public Switched tele
`phone network (PSTN).
`VoIP, as well as video conferencing, has been used by
`computer hobbyists to place no-charge (and typically low
`quality) calls over the Internet, using microphones, video
`cameras, and Speakers connected to a personal computer
`(PC) audio card supported by audio/video software. Com
`25
`mercial applications of VoIP technology are now emerging.
`Various types of services can be provided using VoIP,
`including enterprise toll bypass, IP-based Interexchange
`Carrier (IXC; long distance) service, and IP-based local
`telephony.
`A drawback of existing implementations is the use of the
`User Datagram Protocol (UDP) to provided bandwidth not
`available using TCP, UDP is the connectionless transport
`protocol in the TCP/IP protocol layers. UDP does not
`provided for error detection/correction or any other quality
`of service (QoS) within the existing protocol. Thus, the
`quality and connection of calls is uncertain.
`What is needed is a technique to better control Internet
`connections, Such as VoIP calls, by providing real-time
`information about the quality of inbound and outbound
`Voice, modem, facsimile, Video Streams, and the like.
`SUMMARY OF THE INVENTION
`The present invention is directed to a System, method and
`computer program product for managing diagnostic and
`performance information for communications System termi
`nal endpoints (TES) communicating over an Internet Proto
`col (IP) network. The TEs communicate by connections that
`are voice, modem, facsimile, Video or data transmissions.
`A Diagnostic Supervisor (DS), which is capable of being
`coupled to the communications System, transmits Diagnostic
`Configuration Messages (DCMs) to the TEs. The TE's
`generate Diagnostic Messages (DMs) based on diagnostic
`information, including error Statistics, Voice Statistics, fac
`Simile Statistics, Video Statistics, data Statistics, or the like,
`concerning IP network connections in which the TES par
`ticipate. The DCMs instructs the TEs how to format and
`when to transmit DMs. The flexibility afforded by the DCMs
`allows large amounts of customized diagnostic information
`60
`to be delivered in a non-intrusive manner by limiting the
`transmission of diagnostic information only when required.
`The DMs are transmitted by the TEs to the DS. In a system
`with more that one DS, the TES can transmit DMs to the
`plural DSS, other TES or any network device.
`The DS can be programmed locally or remotely to send
`various types of DCMs. The DS can also be programmed
`
`35
`
`40
`
`45
`
`50
`
`55
`
`65
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 015
`
`

`

`US 6,553,515 B1
`
`3
`FIG. 3 illustrates a distributed diagnostics management
`System of Servers and clients that communicate via the
`Internet according to another embodiment of the present
`invention.
`FIG. 4 illustrates an exemplary architecture of a DS
`according to an embodiment of the present invention.
`FIG. 5 illustrates an exemplary architecture of a Configu
`ration Manager according to an embodiment of the present
`invention.
`FIG. 6 illustrates an exemplary architecture of a Report
`Manager according to an embodiment of the present inven
`tion.
`FIG. 7 illustrates an exemplary architecture of a Real
`Time Response Manager (RTRM) according to an embodi
`ment of thee present invention.
`FIG. 8 illustrates an exemplary architecture of a TE
`according to an embodiment of the present invention.
`FIGS. 9A-C illustrate exemplary flow diagrams for IP
`connection rerouting to the PSTN according to the present
`invention.
`FIG. 10 illustrates an exemplary flow diagram for dis
`connect Supervision or answer detection of IP connections
`according two embodiments of the present invention.
`FIG. 11 illustrates an exemplary flow diagram for moni
`toring connection parameters of IP connections according
`further embodiments of the present invention.
`FIG. 12 illustrates various types of TEs in a system for
`attendant Supervision of IP connections according to an
`embodiment of the present invention.
`FIG. 13 illustrates various types of TEs in a system for
`billing management of IP connections according to an
`embodiment of the present invention.
`DETAILED DESCRIPTION OF THE
`EMBODIMENTS
`
`I. OVERVIEW
`The following section is an overview of basic Internet
`related concepts, as discussed in PricewaterhouseCoopers
`Technology Forecast: 1999 (PricewaterhouseCoopers Tech
`nology Center, Menlo Park, Calif., 94025; order #TC-01
`09).
`Voice calls or facsimile transmissions, which are not
`distinguished from Voice calls by the phone network, must
`first be converted from analog signals into digital form. This
`conversion is performed by a codec (compression/
`decompression), which can be implemented either in Soft
`ware or Special-purpose hardware. Digitally encoding of
`voice calls is also done in the PSTN for interoffice trans
`mission by Systems. Such as private branch exchanges
`(PBXs). However, the codecs used for VoIP use bandwidth
`more efficiently than the those used in the PSTN, carrying
`voice in as little as 5 Kbps compared with the 64 Kbps
`needed by the phone network.
`Once digitized, the encoded Voice data is then wrapped
`within IP packets, using a Real-Time Transport Protocol
`(RTP), which runs over UDP (UDP is the connectionless
`transport protocol in the TCP/IP protocol suite; it serves as
`the counterpart to TCP, which is the connection-oriented
`protocol.) IP packets then are carried over a TCP/IP network.
`Call Setup and control-type features for voice, modem,
`facsimile, video and data systems are, based on the H.323
`Internet telephony standard (described below).
`It is desirable to incorporate Some form of quality of
`Service (QoS) features that can give a higher priority to
`
`4
`delay-Sensitive traffic Such as voice than to leSS-delay
`Sensitive data. These features can be provided by resource
`reservation protocol (RSVP) or by other mechanisms that
`enable network administrators to deliver traffic defined as
`high priority (Such as Video conferences) before less time
`sensitive traffic.
`
`A. VoIP-to-PSTN Gateway
`A VoIP-to-PSTN gateway is typically used to permit
`access to all telephone devices, not merely those connected
`to an IP network. The gateway functions to convert the calls
`between analog voice and packet data and translates
`between the VoIP call control system and the protocols used
`in the PSTN (such as, Signaling System 7 (SS7)).
`Most VoIP-based IXCs provide a bank of incoming phone
`lines at each of their points of presence (POPs). To initiate
`a network call, a user calls the VoIP gateway from a Standard
`analog telephone or fax machine. The gateway provides
`either a simulated dial tone or Some other tone. The user
`enters the destination telephone number as well as a personal
`identification number (PIN) for billing. The IXC establishes
`an IP connection between the user's local POP and another
`POP close to the calls destination. The destination gateway
`then places a Standard local call to the final destination, and
`the Voice or fax link is created. In practice, an Internet
`Exchange Carrier (IXC) system typically would be more
`integrated into the local phone network than Suggested here,
`So that the Subscriber would dial the long-distance phone
`number, and the calling number as well as the call itself
`would be transmitted transparently over the local phone
`network to the POP
`B. The H.323 Internet Telephony Standard
`H.323 is an Internet telephony standard from the ITU-T
`that defines multimedia communication over packet
`Switched networks that do not provide guaranteed QoS.
`H.323 is an extension of the original H.320 standard, which
`specified criteria for video conferencing over ISDN and
`other circuit-switched networks. H.323 extends H.320 for
`use on networkS Such as the Internet and private IP networkS.
`H.323 is adapted to Support many aspects of multimedia, but
`requires only voice and, as Such, generally is regarded as the
`standard for VoIP. H.323 defines the basic capabilities Inter
`net telephony Software must Support, and it specifies
`requirements for call control, audio, and Video compression
`technologies.
`The H.323 standard is directed to the types of data streams
`required for Internet telephony. All telephone Software must
`Support specified audio (Such as speech) and call-control
`Signals that permit telephones to find each other, determine
`each other's characteristics, and then monitor call Status.
`This Standard also specifies lowest-common denominator
`compression protocols, Such as G.711 (audio compression
`over 64-Kbps data path), G.723 and G.729 (audio compres
`Sion over an analog modem). H.323 also specifies the
`functions to be performed by a network control Server,
`known as the "gatekeeper.”
`Currently, H.323 requires that Internet telephones also
`adhere to H.245, the ITU-T standard for telephony control
`functions. H.245, along with the associated H.225.0 and
`Q.931 standards, defines how a phone should connect to
`another phone over the Internet, Start a conversation, deter
`mine the capabilities of the receiving phone, and hang up a
`call. During call initiation, the devices use H.245 to deter
`mine proper compression protocols and also whether the
`phones Support full-duplex or half-duplex transmission.
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 016
`
`

`

`US 6,553,515 B1
`
`S
`They also agree on what resolution is recommended for
`Video, which encryption capabilities are Supported or
`desired, and the maximum “jitter” (variation in delivery time
`for data packets) that will be allowed before the session is
`terminated.
`Other Internet Standards are under development, includ
`ing the Session Initiation Protocol (SIP) and the Simple
`Gateway Control Protocol (SGCP). SIP, a signaling protocol
`for Internet conferencing and telephony, handles basic call
`Setup functions as well as enhanced Services Such as call
`forwarding. SIP addresses users by an e-mail-like address
`and reuses Some of the infrastructure used for Internet e-mail
`delivery such as DNS MX (Domain Name System mail
`forwarding) records. In addition to its own address format,
`SIP can handle H.323 addresses or telephone numbers (as
`defined by the E.164 standard). SGCP is part of a VoIP
`architecture that distributes the voice-to-IP gateway func
`tions between the actual gateways, which perform transla
`tion between Voice Signals and IP packets, and a server
`known as the “call agent,” which handles complex Signaling
`protocols such as SS7. SGCP handles the communication
`between the call agent and the gateways. SGCP primarily is
`designed to Serve as a simple “remote control’ protocol that
`the call agent uses to program gateways according to
`instructions received through Signaling protocols Such as
`H.323 or SIP
`
`15
`
`25
`
`6
`(TE-TE) are programmable to provide diagnostic infor
`mation over the Internet 110 to each other or to the DS 108.
`The diagnostics are dependent on the type of connection,
`which can be either an Internet telephone voice call, transfer
`of Video, facsimile, data, or control information. Known
`methods and protocols to communicate Voice, modem,
`facsimile, Video, data and control information over the
`Internet 110 would be apparent to a person skilled in the
`relevant arts of Internet telephony and VoIP.
`Diagnostic information provided in this matter can give a
`network administrator advance warning of client problems,
`and/or historical data performance profiles. This can allow
`the network administrator to initiate Solutions perhaps even
`in advance of the client's recognition of the problem. A
`plethora of uses for diagnostic information can be provided
`according to the present invention as envisioned by the
`inventors. Many of the uses of diagnostic information
`according to the present invention are described below by
`way of example and not limitation.
`The terminal endpoints 102, 104–106 of FIG. 1 can be
`implemented in a variety of ways. FIG. 2 illustrates various
`types of terminal endpoints in a System Similar to that
`depicted in FIG. 1 for communicating diagnostics or other
`feedback concerning Internet connections according to the
`present invention. In the Simplest form a terminal endpoint
`is a communication device, Such as a Standard telephone
`with an IP gateway, which is illustrated at 202. Alternatively,
`a terminal end point can comprise an Internet phone, as
`illustrated at 204. Moreover, the Internet phone 204 can
`include the functionality of a diagnostic Supervisor. Another
`example of a terminal endpoint is a personal computer 206,
`which can also function as a diagnostic Supervisor. Other
`examples of terminal endpoints include Servers and clients.
`A server terminal endpoint is illustrated in 208, which can
`also serve as a diagnostic Supervisor. FIG. 2 also illustrates
`a client terminal endpoint 210. The client/TE 210 is effec
`tively a node capable of Switching between a plurality of
`communication devices Such as phones 212, 214 through
`216. Alternatively, a personal computer communication
`device or a personal computer communication device also
`functioning as a diagnostic Supervisor can be connected to
`the node and be part of the client/TE210. Such a PC/DS is
`illustrated at 218. A server 208 keeps all the general info
`about a network's configuration. It is also considered a
`master of the network, unless it's functions are distributed.
`FIG. 3 illustrates a distributed diagnostics management
`system of servers (302, 304-306) and clients (308,
`310-312), which communicate via the Internet 110. IP
`connections between Servers and clients, between plural
`Servers, or between plural clients can also be routed via the
`PSTN 314. In this embodiment, the diagnostic Supervisory
`functions can be distributed or can be redundant between
`multiple Servers, Such as Server 1, or Server 2 through Server
`n. The exemplary functions to be performed by a diagnostic
`Supervisor will now be described in connection with FIG. 4.
`FIG. 4 illustrates an exemplary architecture for a Diag
`nostic Supervisor 108, according to the present invention.
`The Diagnostic Supervisor 108 includes a Configuration
`Manager 402, a Report Manager 404, a real-time response
`manager 406, and an Input/Output (I/O) Manager 408.
`These four managers are interconnected by a bus System
`410, which permits the four managers to communicate
`directly with each other in a flexible manner. Alternatively,
`direct wiring or busing between each of the four managers
`can be provided, as would be apparent to a perSon Skilled in
`the relevant art. The Diagnostic Supervisor 108 can also
`include an internal or external communication controller
`
`35
`
`40
`
`45
`
`C. Real-Time Transport Protocol and Real-Time
`Control Protocol
`The Real-Time Transport Protocol (RTP) handles end-to
`end, real-time delivery of data such as video and voice. RTP
`transports data over the UDP and does not guarantee in-time
`delivery, order of delivery, or even delivery at all. RTP
`provides functionality that is required for real-time multi
`media traffic, including content identification, timing
`reconstruction, loss detection, and security. With RTP, data
`can be delivered to one or more destinations, and limits any
`delay, variation. Although RTP can take advantage of
`resource reservation protocols Such as RSVP, communicat
`ing dynamically to allocate appropriate bandwidth, but RTP
`itself does not provide for guaranteed bandwidth or other
`QoS features.
`Time stamps and header information are provided by RTP,
`which distinguish whether an IP packet is data or voice,
`allowing prioritization of voice packets. RSVP allows net
`working devices to reserve bandwidth for carrying unbroken
`multimedia data Streams.
`A companion protocol to RTP is Real-Time Control
`Protocol (RTCP), which analyzes network conditions. RTCP
`50
`provides feedback to RTP data sources and recipients in a
`periodic transmission fashion. RTCP permits adjustment to
`changing network loads by reporting to Senders and receiv
`erS various types of variations in network performance.
`II. SYSTEM DESCRIPTION OF THE PRESENT
`INVENTION
`A System 100 for communicating diagnostics or other
`feedback concerning Internet connections from one or more
`terminal endpoints TE-TE (102, 104 through 106,
`respectively) to a Diagnostic Supervisor (DS) 108 as illus
`trated in FIG. 1. The connections between the TES and the
`DS are performed using Internet protocol, as shown gener
`ally at Internet cloud 110. According to the present
`invention, the Internet cloud 110 may be the public Internet
`or private internet. As will be described in detail below,
`according to the present invention the terminal endpoints
`
`55
`
`60
`
`65
`
`Zoho Corp. and Zoho Corp. Pvt., Ltd.
`Exhibit 1025 – 017
`
`

`

`7
`412. The communication controller 412 handles call func
`tions Such as call control and VoIP management. The com
`munication controller 412 can be directly coupled to the bus
`System 410, and thus can be considered an integral part of
`the Diagnostic Supervisor 108. Alternatively, the communi
`cation controller 412 can be external to the Diagnostic
`Supervisor 108 and be coupled to the Diagnostic Supervisor
`108 through the I/O manager 408. Managers 402,404, 406
`and communication controller 412 can communicate via the
`I/O manger 408 with the Internet 110, and the PSTN 314.
`Alternate implementations can combine one or more of the
`managers 402,404, 406, 408 into one entity.
`The Configuration Manager 402 of the Diagnostic Super
`visor 108 permits a user or network administrator to con
`figure the diagnostic information to be provided by terminal
`endpoints before, during or after an Internet connection
`(e.g., the VoIP call). As will be described in detail below, the
`Configuration Manager 402 is programmable to provide
`diagnostic control messages (DCMs) to TEs in order to
`configure the terminal endpoints (TES) to provide the
`desired diagnostic information.
`The network administrator can program the Configuration
`Manager 402 to generate DCMs in a variety of manners. For
`example, the network administrator can program the Con
`25
`figuration Manager 402 by a personal computer 414 via the
`Diagnostic Supervisor 108 via the I/O manager 408.
`Alternatively, the network administrator can program DCMS
`using the Configuration Manager 402 remotely over an
`Internet connection, via a telephone link and the PSTN 314,
`or by a direct connection, Such as a Serial, parallel, or optical
`port directly to the Diagnostic Supervisor 108. Such direct
`(hardwired or wireless) connections are not illustrated in
`FIG. 4.
`The Report Manager 404 receives Diagnostic Messages
`35
`(DMs) from terminal endpoints configured by DCMs to
`relay diagnostic information or “events” to the DS 108. DMs
`are received by the Report Manager 404 via the I/O manager
`408 and bus network 410. The DMs can be transmitted from
`TES via the Internet 110 or the PSTN 314. In an alternative
`embodiment of the present invention in which the diagnostic
`Supervisor includes a communication controller 412, the
`Report Manager 404 can also receive DMs from the com
`munication controller 412. In this alternative embodiment,
`the communication controller 412 is the equivalent of a
`terminal endpoint and thus is also configured by DCMs from
`the Configuration Manager 402 to relay DMs to the Report
`Manager 404. Thus, the Diagnostic Supervisor 108 receives
`DMs reflecting its own events.
`The Report Manager 404 is programmable to provide
`reports for the network administrator in a human readable
`
`40
`
`45
`
`US 6,553,515 B1
`
`15
`
`8
`format. For example, reports can be provided by the Report
`Manager 404 in text form, graphic user interface form via
`the PC 414, as voice messages, or simply as printouts via a
`printer 416. Based on the below discussion of diagnostic
`configuration messages and diagnostic messages, the pro
`gramming of Report Manager 404 to produce reports for the
`network administrator would be apparent to a perSon Skilled
`in the relevant art. Moreover, the Report Manager 404 can
`be programmed to provide reports to the network
`administrator, other user or any network device over the
`Internet 110 or PSTN 314 via the I/O manager 408 and bus
`network 410.
`The Real-Time Response Manager (RTRM) 406 also
`receives DMS and acts in real-time to perform any necessary
`response to events. In addition to the various responses
`provided by the RTRM 406 as described below, it can
`generate external warnings using devices Such as an external
`alarm 418, pager device 420, or the like, as would be
`apparent to a perSon Skilled in the relevant art.
`FIG. 5 illustrates an exemplary architecture for the Con
`figuration Manager 402 according to an embodiment of the
`present invention. The Configuration Manager 402 includes
`a Diagnostic Configuration Message (DCM) Generator 502,
`a DCM Transceiver Unit 504 and a configuration database
`506. The DCM Generator 502 permits a network adminis
`trator to create DCMs in order to configure TEs.
`An example of a DCM is an information element (IE)
`having a format illustrated below in Table 1. Column (a) of
`Table 1 is the Field Number that lists the sequential number
`of information fields in the IE. Column (b) is the Field
`Length (octet) that gives the length in eight bit octets of each
`information field. Column (c) is the Information Field Name
`that lists the name of each information field used in the IE.
`Column (d) is the Information Field Description that
`describes the function, format and purpose of each infor
`mation field in the IE. The last column (e) is the Format and
`Value that defines the value or data format used in each
`information field. Unless noted otherwise in the field
`description, the data format used in each information field is
`an unsigned hexadecimal value. If the information field is
`composed of more than one octet, the first octet is the most
`Significant byte and the last octet is the le