CA2343754A1

CA2343754A1 - Scaleable communications system

Info

Publication number: CA2343754A1
Application number: CA002343754A
Authority: CA
Inventors: Wongyu Cho; Hyeonkuk Jeong; Woohyung Kim; Hyunduk Ahn; Doyon Kim
Original assignee: Individual
Current assignee: Dialpad Communications Inc
Priority date: 1999-09-24
Filing date: 2000-09-06
Publication date: 2001-04-05
Also published as: KR20010050717A; WO2001024478A3; WO2001024478A2; JP2003530732A; CN1415159A; BR0006923A; EP1190550A2; AU7983000A

Abstract

A system that supports audio, video, data, and fax communications between a source personal computer and an audio communications device, such as a telephone or a destination personal computer. The system provides for communications first with an entry node, which selects an intermediate server.
The selected intermediate server selects an ITSP gateway, for example, which provides access to the audio communications device. The selected intermediate server initiates voice or video communications using for example, the H.323 standard, with the ITSP gateway. The selected intermediate server then informs the source personal computer to communicate directly with the ITSP gateway.
Thereby, the system scaleably supports voice or video communications in a "thin-client" environment.

Description

SCALEABLE COMMUNICATIONS SYSTEM
BACKGROUND
1. Field of the Invention The present invention relates to a method and apparatus for providing video and voice communications.

2. Discussion of Related Art VoIP (voice over Internet protocol (IP)) describes a set of facilities for managing the delivery of voice information using the public Internet or private intranets or networks, rather than using the traditional circuit-committed protocols of the public switched telephone network (PSTN). A major advantage of VoIP and Internet telephony is that it avoids the tolls charged by commercial telephone service providers such as MCITM or AT&T'~'.
VoIP derives from ITU-T H.323, a standard promoted by the VoIP Forum. The H.323 standard defines the format for sending audio, video, data, or fax using IP
on the public Internet and within intranets. In addition to IP, VoIP uses the well known real-time protocol (RTP) to ensure that communications are provided in a timely manner to avoid noticeable pauses in voice or video communications. Using public networks, it is currently difficult to control the latency. Better service is possible with private networks managed by an enterprise or by an Internet telephony service provider (ITSP).
Conventional techniques that support VoIP
communication require voluminous software to be downloaded to a user's personal computer. With the low speed communications links, users require much time to download the software. For personal computers with low memory storage capability, such as personal digital assistants (PDAs), VoIP communications may not be feasible given the volume of software needed.
SUMMARY
In accordance with an embodiment of the present invention, a system is provided which allows at least for audio communications between a personal computer and an audio communications device, such as a telephone. Video, data, and fax communications can also be supported.
In one embodiment of the present invention, communications between a personal computer and audio communications device is supported by at least one intermediate device. For communications between a personal computer and audio communications device, the personal computer communicates with a entry node, which selects an intermediate server. The personal computer next communicates with the selected intermediate server, which selects a ITSP gateway. The personal computer then communicates with the ITSP gateway. The ITSP gateway provides access to a PSTN which provides access to the destination audio communications device.
Thereby the personal computer communicates with the destination audio communications device.
One advantage of this embodiment is the software downloaded to the personal computer is less than if the personal computer had to both select an ITSP and establish communication with the ITSP.
Another advantage of this embodiment is the architecture that supports VOIP communications is scaleable so that numerous VoIP communications can be facilitated.

Another advantages of this embodiment is that it can use many varieties of the H.323 standard for VoIP
communications .
In one embodiment, for client to remote client communications, communications between client and remote client are direct. In this embodiment, client and remote client communicate without need for the client to support H.323. Thus considerable software storage is avoided.
Various embodiments of the present invention will be more fully understood in light of the following detailed description taken together with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 schematically depicts an embodiment of the present invention in which a system is used to provide communications between any client and any destination audio communication device.
FIG. 2 depicts an exemplary relationship between ITSP gateways of an ITSP network and the system, in accordance with an embodiment of the present invention.
FIG. 3 provides a more detailed diagram of a system which is in accordance with an embodiment of the present invention.
FIG. 4 provides a flow diagram of a process which is in accordance with an embodiment of the invention.
FIG. 5 schematically depicts messages communicated between a client, entry node, a selected intermediate server, and selected ITSP gateway during the process of FIG. 4, in accordance with an embodiment of the invention.
FIG. 6 provides a suitable flow diagram of an action of the process of FIG. 9, in accordance with an embodiment of the invention.

wo omaa~s pcTnrsoon4ass FIG. 7 depicts a sample web site used in one embodiment, in accordance with an embodiment of the invention.
FIG. 8 provides a suitable flow diagram of an action of the process of FIG. 4, in accordance with an embodiment of the invention.
FIG. 9 provides a suitable flow diagram of an action of the process of FIG. 4, in accordance with an embodiment of the invention.
FIG. 10 schematically depicts the relationship between multiple clients and a data base, in accordance with an embodiment of the invention.
Note that use of the same reference numbers in different figures indicates the same or like elements.
DETAILED DESCRIPTION
Incorporated materials The following table provides a list of topics and materials related to such topics. The materials are incorporated herein by reference in their entirety.
Topic Material UDP/IP Internet Engineering Task Force (IETF) Request for Comments 768.

TCP/IP "TCP/IP And Related Protocols, McGraw-Hill Series On Computer Communications", Third Edition, Ulysses D. Black, McGraw-Hill Companies, 1997, ISBN: 0079132820, and "TCP/IP Illustrated Volume l: The Protocols", W. Richard Stevens, Addison-Wesley, 1994.

H.323 and "Digital Subscriber Signaling System No. 1 related sub Network Layer - ISDN User-Network Interface protocols Layer 3 Specification for Basic Call such as RTP Control" (ITU-T Recommendation Q.931) and "Line Transmission of Non-Telephone Signals Control Protocol for Multimedia I Communication (ITU-T Recommendation H.245) . I
Client to destination communications device Overview FIG. 1 schematically depicts an embodiment of the present invention in which system 100 is used to provide audio communications between any client 105-1 to 105-N and any destination audio communication device 150-1 to 150-Z, such as a conventional telephone. In this embodiment, any client 105-1 to 105-N accesses system 100 through a public or private network such as the Internet. Hereafter client 105 refers to any client 105-1 to 105-N unless otherwise specified.
Hereafter destination audio communication device 150 refers to any destination audio communication device 150-1 to 150-Z unless otherwise specified.
System 100 communicates with ITSP networks 140-1 to 140-Y using a public or private network such as the Internet. Hereafter ITSP networks 140 refers to any ITSP networks 140-1 to 140-Y unless otherwise specified. At least one ITSP network communicates with a public switched telephone network (PSTN), which allows for communication with the destination audio communication device 150-1 to 150-Z.
FIG. 2 depicts an exemplary relationship between ITSP gateways 145-1 to 145-N of an ITSP network 140 and system 100. An ITSP network 140 is a private network that typically includes multiple ITSP gateways 145-1 to 195-N. Typically each ITSP gateway has a unique address, such as an IP address. For example, ITSP
networks are provided by IDT of New Jersey and QwestTM.
Each ITSP gateway is coupled to at least one public switched telephone network (PSTN) 148. PSTNs provide either wireline or wireless access to telephone units such as any of destination audio communication devices 150-1 to 150-Z. Hereafter ITSP gateway 145 refers to any ITSP gateways 145-I to 145-N unless otherwise specified.
Typically, each ITSP gateway uses a distinct implementation of the H.323 protocol to support communications.
Interface between client 105 and system 100 An exemplary embodiment of client 105 is a conventional personal computer (PC). A suitable PC
includes an input/output adapter, central processing unit (e. g., a microprocessor), and a memory. Suitable PCs are, for example, a IBM PS/2 personal computer, Apple Macintosh computer, UNIX-based workstation, or a PDA such as a Palm VII available from 3comTM. The PC
further includes a display such as a computer monitor such as a super VGA type or other visual display device.
The client 105 typically has resident thereon an operating system such as the Microsoft Windows NT'n' or the Microsoft Windows 95'n' Operating System (OS), the IBM OS/2, the Apple MAC OS, or the UNIX OS such as the HP-UX OS.
The client 105 also includes a speaker and microphone as well as a sound card to support broadcasting of audible information and transmission of audible information, such as speech of the user of the PC.
The PC user with access to the Internet or a private network can use a web browser such as Microsoft Internet ExplorerTM or Netscape Navigator''M to access a web page with graphical content. To specify a web site, the user enters a universal resource locator (URL) specifying both the server and the specific data ("web page") requested. The URL may specify a hyper text transfer protocol (HTTP) or another transfer protocol for communicating between the server and the browser. Using the Internet, the URL is transmitted to the host server which stores information corresponding to the URL.
In one embodiment, client 105 accesses system 100 using a website stored in the network 110. A
conventional website server, which is part of the network 110, hosts the website accessed by the client 105. A suitable website server is for example a SPARC
Server, available from SUN MicrosystemsT'', and uses either Microsoft NT 4.0, IIS, or UNIX operating system.
An exemplary website is described in more detail later with respect to FIG. 7. The website server supports requests from the user for features provided by the website.
System 100 FIG. 3 provides a more detailed diagram of system 100. System 100 includes a entry node 120 that communicates with at least one intermediate server 130-1 to 130-X using a public or private network such as the Internet. Each intermediate server 130-1 to 130-X
is capable of communicating with every ITSP gateway 145-1 to 145-N using a public or private network such as the Internet. Of course, additional entry nodes 120 can be used to support more communication sessions.
Entry node 120 of FIG. 3 monitors the activity of intermediate servers and selects an intermediate server to support audio communications from a distinct client 105, such as client 105-1. An exemplary embodiment of the entry node 120 is similar to the web server. The intermediate server selected by the entry node 120 to manage an audio communication from client 105 in turn selects an ITSP gateway that provides access to a PSTN
that provides communications with a destination audio communication device 150. Each intermediate server 130-1 to 130-X is similar to the web server. Hereafter intermediate server 130 refers to any intermediate server 130-1 to 130-X unless otherwise specified.
Database server In one embodiment, a distinct database server (not depicted) uses a "Log Database" to store information on each user and processes requests for information related to a client 105 or a specific user. A suitable database server is a conventional server. Exemplary communications to and from the database server are provided in Appendix B.
Software implementation overview Appendix A, an integral part of this disclosure, describes code segments that are executed by client 105, entry node server 120, and intermediate servers 130-1 to 130-X, in this embodiment. The code segments are used to perform process 400 of FIG. 4 that communications between client 105 and a destination audio communications device.
In action 405 of process 400, client 105 contacts entry node 120 to initiate use of system 100. Detailed description of action 405 is provided with respect to FIG. 6.
In action 410, the entry node 120 selects a suitable intermediate server 130. The entry node then identifies the selected intermediate server 130 to the client 105. Detailed description of action 410 is provided with respect to FIG. 8.
In action 415, the selected intermediate server 130 selects and establishes a communications channel with an ITSP gateway 145 and identifies the selected ITSP gateway to the client 105. Subsequently, the client 105 and ITSP gateway 145 communicate directly.
As stated earlier, the ITSP gateway 145 communicates with a PSTN, which provides communications with the destination audio communications device 150. Using the ITSP gateway 145, the client 105 communicates with the destination audio communications device 150. Detailed description of action 415 is provided with respect to FIG. 9.
In action 420, the client 105 ends the audio communications session. Detailed description of action 420 is provided below.
One advantage of this embodiment is that communication between the client 105 and destination audio communications device 150 is segmented so that selection and establishment of communications channels between the client 105 and ITSP gateway 145 is performed using entry node 120 and intermediate server 130. Thereby the software downloaded to the client 105 is less than if the client had to select and establish connection with an ITSP gateway (so called "thin client" environment}.
Exemplary Messages FIG. 5 schematically depicts messages communicated between the client 105, entry node 120, a selected intermediate server 130, and selected ITSP gateway 145 during process 400 during an exemplary operation of actions 405 to 420. Appendix D provides a description of a suitable protocol used to transmit the messages as well as a description of other messages.
Action 405 FIG. 6 provides a suitable flow diagram of action 405 (FIG. 4}. In action 610, the user, using a graphical web browser such as Netscape Navigator or Microsoft Explorer, supplies a universal resource locator (URL) or uses a hyperlink to access a web site that includes functionality in accordance with an embodiment of the present invention. The website is written, for example, in HTML, and includes potentially several web pages, each linked using the HTML code.
For example, FIG. 7 depicts a sample web site 700.
Website 700 includes a graphical touch pad 702, through which alphanumeric characters can be entered; a field 704, into which characters can be entered; caption "address book" 706, that accesses a phone book, for example: and a conventional graphical banner in position 708.
In another embodiment, web site 700 provides users access to electronic mail, voice mail messages, and faxes. Websites that provide access to electronic mail, voice mail messages, and faxes are well known;
see for example, Hotmail . com'~'~', Excite . comT''', and jfax.comT'''. Thus in this embodiment, web site 700 and system 100 allow users to respond vocally to voice mail messages, electronic mails, or faxes.
In action 610, after connection with the specified web site, the web site server uploads executable files that form "strtp.dll", "stnet.dll", "vscp.dll", and "tsd2.d11" to the PC of client 105. Such files and such *.dll files are listed in Appendix A.
Referring to FIG. 6, in action 620, the user enters a destination phone number, for example, into field 704 of the web site 700.
In one embodiment, when caption "address book" 706 of website 700 is selected, a phone book is provided to the user. Selecting a phone number in such phone book initiates a phone call to a destination audio communications device 150.
In one embodiment, the phone book is stored in a data base with data base server, described earlier.
Commands to the data base are described in more detail in Appendix B.

In position 708, a conventional graphical banner ad is displayed. Advertisements can be scheduled by use of a service available from Doubleclick of New York, New York, for example. Advertisements can be tailored to the user's interests. By providing advertisements that are targeted to specific users, advertising revenue can be maximized. In this embodiment, advertising revenue can be used to pay for costs of communication with the destination audio communications device 150.
Of course, by engaging the graphical banner advertisement, a user can purchase the product or service advertised.
In action 630, the client connects to a entry node 120 using, for example, the TCP/IP protocol. Action 630 corresponds to the message entitled TCP Connect 502 (FIG. 5). The IP Address and port number of the entry node 120 are preconfigured in the files downloaded in action 610. In action 630, the client communicates at least the destination phone number, User ID, Password, and Session ID to the entry node 120. The User ID
identifies a user and identifies information, such as described in Appendix B, associated with the user that is stored by the data base server. The Password is used by the web server to determine whether to permit access to the user's information from the data base.
The Session ID is used to track the status of the voice communication .
In action 640, the entry node 120 provides the contact information of a selected intermediate server 130 to the client 105 using, for example, the TCP/IP
protocol. Referring to FIG. 5, action 640 corresponds to the message entitled VEGA Server 504. In this embodiment, the contact information includes the IP
address and port number of the selected intermediate server. In this embodiment, the IP Address is a 4 byte IPv4 address (IP version 9) of the selected intermediate server 130 and the port number is a 2 byte port number that selected intermediate server monitors for future communications from the client 105.
In this embodiment, the entry node 120 maintains a table of potential intermediate servers 130 as well as the percent of active communications the intermediate server 130 maintains. Appendix C, an integral part of this disclosure, provides a description of a suitable technique whereby the entry node 120 monitors the activity level of intermediate servers 130. In this embodiment, the entry node 120 selects an intermediate server 130 that has the lowest activity percentage (e. g., Number of Active Sessions divided by Max Number of Sessions). If all potential intermediate servers 130 are idle to the same extent, the entry node selects an intermediate server 130 having the lowest associated identification number. Other selection methods can be used, such as random selection.
Action 410 FIG. 8 provides a suitable flow diagram of action 410 (FIG. 4). Appendix A provides a description of programs used in action 410.
In action 810, the client 105 connects to the selected intermediate server 130 using the IP address and port number, both specified earlier in action 610, using for example, TCP/IP. In the example of FIG. 5, action 810 corresponds to (second occurring) "TCP
Connect 506".
In action 820, the client 105 initializes connection with the selected intermediate server 130 by, for example, issuing a message entitled VSCP SETUP
(item 508, FIG. 5) to the selected intermediate server 130 by using for example TCP/IP. Message VSCP SETUP
initializes any communications between client 105 and WO 01!24478 PCTIUS00124485 the selected intermediate server 130. The following table provides a description of fields used in message VSCP SETUP.
Field Name Octet Brief description (byte) no.

User ID 1 to 8 User ID

Password 9 to 16 password string Client-side 17 to 18 Type of the media Media Transport transport address.

Address Type IPv4 is supported although other protocols can be.

Client-side 19 to 22 Client-side IP Address Media Transport for media transport.

Address Client-side 23 to 24 Client-side Port Media Transport number for media Port Number transport.

Calling Party 25 to 26 Length of the Calling Number Length Party Number.

Calling Party 27 to N, Called Party Number Number where N is Length. (E.164 -the length Maximum 128) of the called party number.

Called Party N to N+1 Length of called party Number Length number. (word) Called Party N+2 to M, Called Party Number Number where M is (E.164 - Maximum 128) the length of the called party number.

Client-side M to M+1 Type of protocol used Protocol Type for media streaming.

RTP is supported although other protocols can be used.

Client-side M+2 to M+3 See below.

Media Type Client-side M+4 to M+5 See below.

Payload Type Client-side M+6 to M+7 Maximum size of the Payload Max payload.

Frame Client-side M+8 Silence suppression Silence enabled.

Suppression Enable Client-side Echo M+9 Echo cancellation Cancellation enabled.

Enable Field Client-side Media Type represents the transmitted media type.
Media Type Value Voice 0x0001 Video 0x0002 Data 0x0003 Fax Ox0004~
Field Client-side Payload Type represents the type of compression algorithm used to encode the selected media type, such as voice, video, or data. Currently, encoded voice payloads are supported.
Payload Type Value Non-Standard 0x0001 6.711 A-Law 64K 0x0002 6.711 A-Law 56K 0x0003 6.711 u-Law 64K 0x0004 6.711 u-Law 56K 0x0005 6.722 64K 0x0006 6.722 56K 0x0007 6.723.1 0x0008 6.728 0x0009 6.729 Ox000a 6.729 Annex A Ox000b IS11172 Ox000c IS13818 Ox000d 6.729 Annex B Ox000e 6.729 Annex A Annex B Ox000f 6.723.1 Annex C 0x0010 GSM Full Rate 0x0011 GSM Half Rate 0x0012 GSM Enhanced Full Rate 0x0013 In action 830, the selected intermediate server 130 determines whether to allow the client 105 to begin a voice or video based communication. The selected intermediate server 130 performs authentication, which includes determining if the client 105 having the specified Userid and password is permitted to use the selected intermediate server 130.

If the client 105 is not permitted, the selected intermediate server 130 issues a RELEASE message to the client 105 (not depicted in FIG. 5). Message RELEASE
is described in more detail later. Examples of reasons for not permitting a client 105 include unknown User ID, incorrect password, and unsupported phone number.
See below for a description of the message RELEASE.
If the client 105 is permitted, then in action 840, the selected intermediate server 130 selects an ITSP gateway (hereafter "selected ITSP gateway"). An exemplary manner to select an ITSP gateway is to determine a least-cost available route for the destination phone number. Another exemplary manner to select an ITSP gateway 145 is to use a load balancing method whereby the ITSP gateway 145 with the least number of active sessions is selected. Load balancing advantageously lessens the impact of failure of a single ITSP gateway 145. Another exemplary manner to select an ITSP gateway 145 is to select an ITSP
gateways based on a general hierarchy. The selected ITSP gateway 145 is used to make a connection with the PSTN 148, through which the destination phone number is connected. The selected ITSP gateway is identified by an IP address.
In action 850, the selected intermediate server 130 communicates with the selected ITSP gateway 145. A
suitable technique to connect with the selected ITSP
gateway 145 uses the H.323 protocol, both well known to those of skill in the art. In action 850, the Q.931 and H.295 protocols are conventional and described in the H.323 protocol. See for example "Digital Subscriber Signaling System No. 1 Network Layer - ISDN
User-Network Interface Layer 3 Specification for Basic Call Control" (ITU-T Recommendation Q.931) and "Line Transmission of Non-Telephone Signals - Control Protocol for Multimedia Communication (ITU-T

Recommendation H.245), which are incorporated herein by reference in their entirety.
As each ITSP gateway 145 may use a distinct style of H.323, the selected intermediate server 130 advantageously can support each distinct style of H.323. Without use of the selected intermediate server 130, the client 105 may have to support each distinct style of H.323. Such support may require voluminous software be uploaded to the client 105.
FIG. 9 schematically depicts operations of action 850 in more detail. In this embodiment, the communications of action 850 use the TCP/IP protocol.
In action 910, a connection with the specified destination audio communications device 150 is established. In one embodiment, action 910 further includes the actions 910-1 to 910-7.
In action 910-l, the selected intermediate server 130 provides the destination PSTN phone number to the selected ITSP gateway 145 to initiate a call using the conventional SETUP message which is defined by the Q.931 protocol. Action 910-1 corresponds to Q.931 SETUP 510 of FIG. 5.
In action 910-1, the selected intermediate server 130 next issues a message CALLPROCEED to the client (item 512, FIG. 5). The CALLPROCEED message communicates to the client 105 that the current call request is currently in processing state. In this embodiment, message CALLPROCEED includes an 8 byte value that identifies the call. Message CALLPROCEED
includes a unique Call Reference Value of, e.g., 8 bytes, that identifies a particular communication session. The selected intermediate server 130 maintains the status of each ongoing session.
In action 910-2, the selected ITSP gateway 145 dials the destination PSTN phone number. Action 910-2 corresponds to Dial 514 of FIG. 5.

In action 910-3, the PSTN signals to the selected ITSP Gateway 145 that the destination audio communications device 150 is notifying the destination user of an incoming voice communication. Action 910-3 corresponds to Ringback 516 of FIG. 5.
In action 910-4, the selected ITSP gateway 145 acknowledges to the selected intermediate server 130 of notification by the PSTN to the destination audio communications device using the conventional ALERT
message which is defined by the Q.931 protocol. Action 910-4 corresponds to Q.931 ALERT 5I8 of FIG. 5.
In action 910-5, the selected intermediate server 130 signals to the client that the destination user has been alerted and provides a "Call Reference Value", which is described later. Action 910-5 corresponds to the VSCP ALERT 520 of FIG. 5.
In action 910-6, the PSTN communicates to the selected ITSP gateway that the destination audio communications device has accepted the communication.
Action 910-6 corresponds to Answer 522 of FIG. 5.
In action 910-7, the selected ITSP gateway 145 communicates to the selected intermediate server 130 that the destination audio communications device has accepted the communication using the conventional connect signal which is defined by the Q.931 protocol.
Action 910-7 corresponds to Q.931 CONNECT 524 of FIG.
5.
In action 920, the communication standard between the selected intermediate server 130 and selected gateway 145 is set. In one embodiment, action 920 includes actions 920-1 to 920-2.
In action 920-1, the selected intermediate server 130 communicates the compression technique specified in action 820 and the media type (e. g., voice, video, data, or fax) to the selected ITSP gateway 145 using a conventional terminal capability set (TCS) message which is defined in the H.245 protocol. Action 920-1 corresponds to H.245 TCS 526 of FIG. 5.
In action 920-2, the selected ITSP gateway 145 signals receipt of the TCS message of action 935 to the selected intermediate server 130 using the conventional TCS ACK message which is defined in the H.245 protocol.
Action 920-2 corresponds to the TCS ACK 528 of FIG. 5.
In action 930, a communication relationship is established between selected intermediate server 130 and selected ITSP gateway 145. In one embodiment, action 930 includes actions 930-1 to 930-3.
In action 930-l, the selected intermediate server 130 identifies itself as the master to the selected ITSP gateway 145 using the conventional master slave determination (MSD) message that is defined in the H.245 protocol. Action 930-1 corresponds to the H.245 MSD 530 of FIG. 5.
In action 930-2, the selected ITSP gateway 145 signals receipt of the MSD of action 945 to the selected intermediate server 130 by sending the conventional MSD ACK that is defined in the H.245 protocol. Action 930-2 corresponds to the H.245 MSD
ACK 532 of FIG. 5.
In action 930-3, the selected intermediate server 130 signals to the selected ITSP gateway 145 that the master-slave process is complete using the conventional master MSD message that is defined in the H.245 protocol. Action 930-3 corresponds to the H.245 MSD
ACK 534 of FIG. 5.
In action 940, a voice channel is established between selected intermediate server 130 and selected ITSP gateway 145. In one embodiment, action 940 includes actions 940-1 to 940-4.
In action 940-1, the selected intermediate server 130 signals to the selected ITSP gateway 145 to open a voice channel from the selected intermediate server 130 signals to the selected ITSP gateway 145 using the conventional open logical channel (OLC) as defined in H.245. Action 940-1 corresponds to the H.245 OLC 536 of FIG. 5.
In action 940-2, the selected ITSP gateway 145 signals receipt of the OLC of action 965 to the selected intermediate server 130 using the conventional OLC ACK of H.245. Action 940-2 corresponds to the H.245 OLC ACK 538 of FIG. 5.
In action 940-3, the selected ITSP gateway 145 signals to the selected intermediate server to open a voice channel from the selected ITSP gateway to the selected intermediate server 130 signals using the conventional open logical channel (OLC) as defined in H.245. Action 940-3 corresponds to the H.245 OLC 540 of FIG. 5.
In action 940-4, the selected intermediate server 130 signals receipt of the OLC of action 975 to the selected ITSP gateway using the conventional OLC ACK as defined in H.245. Action 940-4 corresponds to the H.245 OLC ACK 542 of FIG. 5.
Referring to FIG. 8, in action 860, the selected intermediate server 130 notifies the client that a call is being connected by sending a CONNECT message, which corresponds to VSCP CONNECT 544 of FIG. 5. The following table provides a description of CONNECT.
Field Name Octet no.

Call Reference 1 to 8 Call Reference Value Value provided in the previous ALERT message.

Server-side 9 to 10 Type of the media Media Transport transport address. IPv4 Address Type is supported, although other protocols can be used.

WO 01124478 _ pCT1US00/24485 Server-side 11 to 14 Address (IP Address, in Media Transport this embodiment) of the Address selected ITSP gateway.

Server-side 15 to 16 Port number of the Media Transport selected ITSP gateway.

Port Number Called Party 17 to 18 Length of the Called Number Length Party Number.

Called Party 19 to N, Called Party Number Number where N is (E.164 - Maximum 128) the length of the called party number.

Server Side N to N+1 Protocol used for media Protocol type streaming. RTP is used, although other protocols can be used.

Server-side N+1 to N+2 Similar to the client-Media Type side media type described earlier.

Server-side N+3 to N+4 Similar to the Client-Payload Type side Payload Type described earlier.

Server-side N+5 to N+6 Maximum size of the Payload Max payload.

Frame Server-side N+7 Silence suppression Silence enabled.

Suppression Enable WO 01!24478 PCT/US00/24485 Server-side Echo N+8 Echo cancellation Cancellation enabled.
Enable Action 415 In action 415 (FIG. 4), the client 105 communicates with the selected ITSP gateway 145 using, for example, the RTP protocol. RTP is an independent standard protocol for encoding and transmitting multimedia streaming that is well known to those of ordinary skill in the art. Action 415 corresponds to RTP Data 546 of FIG. 5. Of course, other protocols can be used besides RTP, such as any other proprietary media streaming protocol.
In accordance with the RTP standard, program "strtp.dll", described in Appendix A, provides transmission of encoded voice. An exemplary technique to encode and decode voice is available from the DSP
Group of Santa Clara, CA. In this embodiment, program "tsd2.d11" includes the exemplary technique to encode and decode voice.
Thus voice streams are communicated directly between the client and selected ITSP gateway. This direct communication reduces delay of voice packet communications. Such delays introduce noticeable delays in voice communications.
In one embodiment, brief audio ads can be provided to users through the speaker of the client 105 prior to commencing an audio communication. The audio ads generate revenue that can be used to subsidize costs of communicating with the destination audio communications device 150.
Action 420 In action 420 (FIG. 4), the voice communication ends. For example, a client 105 issues a RELEASE (548, FIG. 5) to the selected intermediate server 130 when a user desires to terminate a talk. Similarly, the selected intermediate server 130 issues a RELEASE to the client 105 using, for example, TCP/IP, when a call recipient wishes to terminate a talk. In this embodiment, the "VEGA Server Source Files" described in Appendix A are used in action 420.
One exemplary manner to terminate a voice communication is as follows. The selected intermediate server 130 signals to terminate the H.323 session using for example a H.245 ESC message as defined in the H.245 standard to the selected ITSP gateway (see H.245 ESC
550 of FIG. 5). The selected ITSP gateway 145 then signals to terminate the H.323 session using for example a H.245 ESC message as defined in the H.245 standard to the selected intermediate server 130 (see H.245 ESC 552 of FIG. 5). Next, the selected ITSP
gateway 145 issues a hangup command to the PSTN to discontinue a session (see Hangup 554 of FIG. 5).
Next, the selected intermediate server 130 communicates to the selected ITSP gateway 145 to terminate the session using for example the Q.931 disconnect message defined in the Q.931 protocol (see Q.931 disconnect 556 of FIG. 5).
Thereafter, the selected intermediate server 130 frees resources such as other temporary allocated data structures used for the ended session for another session. Also the selected intermediate server 130 logs the end of the call to a Log Database. The Log Database records the Start Time, End Time, Success/Failure, Caller, Callee phone number. The Log Database is stored by the database server, described earlier and in Appendix B.
DTMF support When the user presses a digit on the website 700 (for example, for voice mail), the client 105 sends the digit to the selected intermediate server 130 using the DTMF message. The selected intermediate server 130, in turn, transfers the DTMF message to the selected ITSP
gateway using an H.245 message.
The following table provides parameters of the DTMF message.
Field Name Octet no. Brief Description Call Reference 1 to 8 Described earlier.

Value DTMF String 9 to 10 The length of the Length DTMF String.

DTMF String 11 to N, where DTMF characters. A

N is the maximum length of length of the the DTMF String is, DTMF String. for example, 128 bytes.

Communication halts At any time, communication halt can be generated by either the client, a selected intermediate server 130, or a remote client using VSCP RELEASE. For example, some communications or messages between a client and selected intermediate server 130 or remote client must be received within an allotted time. If the communications or messages are not received within an allotted time, the receiver issues a RELEASE message to the communication/ message sender to discontinue any communication on an initiated or active session.
The RELEASE message is used to end a TCP
connection. For example, the RELEASE message is used if the selected intermediate server or client do not receive a message, such as SETUP, CALLPROCEED, ALERT, wo omaa~s rcT~sooizaass or CONNECT, in an allotted time. The following table provides parameters of the RELEASE message.
Field Name Octet no.

Call Reference Value 1-8 Reason 9-10 The Call Reference Value field identifies a particular communication session. The following table provides potential values and associated meanings for each Reason field.
Reason Value Unknown reason 0x0001 No permission 0x0002 Unreachable Destination 0x0003 Destination Rejection 0x0004 User 0x0005 Client to remote client In client to remote client communication, the client and remote client communicate directly using the Internet or a private network. The clients communicate using messages TCP connect, VSCP SETUP, VSCP
CALLPROCEED, VSCP ALERT, VSCP CONNECT, RTP Data, and VSCP RELEASE described earlier at least with respect to FIG. 5. Thus in this embodiment, each of client and remote client use only the "Client side programs", described in Appendix A. The client initiates communication with a remote client using the TCP
connect message, in which the IP address and port of the remote client are specified. Thus, for example, the client and remote client are each identified by an IP address and port number.
Advantageously, each client does not need to support the full H.323 protocol, which would be wo omaa~s PCT/USOOn4485 necessary to communicate with an ITSP gateway. Rather, for client to remote client communications, only the RTP needs to be supported. Thus, the software needed by each client is minimized. Should the client request communication with a destination audio communications device, a selected intermediate server supports any necessary distinct implementation of the H.323 protocol needed to communicate with any ITSP gateway.
Modifications The above-described embodiments of the present invention are merely meant to be illustrative and not limiting. It will thus be obvious to those skilled in the art that various changes and modifications may be made without departing from this invention in its broader aspects. For example, system 100 could easily support video, data, or fax communications. Therefore, the appended claims encompass all such changes and modifications as fall within the true scope of this invention.

WO 01/24478 _ _ . PCT/US00/24485 APPENDIX A
Entry node programs A program "vgk.c" is executed by the entry node 120 to support communications between intermediate servers and any client. Program "vgk.c" is used in action 405 (FIGs. 4 and 8).
Client side programs The "Client side programs" are executed by the client 105 and support any communications to and from the client 105. Collectively, the client side programs are used in actions 610 and 620 of FIG. 6. In this embodiment, code segments provided in tables entitled "Java files", "Resource Files", "Microsoft COM Wrapper Class(Internet Explorer only)", "Microsoft COM (Common Object Model) related files for Internet Explorer", "Netscape Plugin related files for Netscape Communicator", "C++ Compiler(Microsoft Visual C++ 6.0) related files", "C++/Header Files", and "External Dependencies" are uploaded to a client.
Program "vegacomm.cpp", "vegacomm2.cpp", and "vegacomm.h" are compiled together to make up the main client side application.
Together, all of code segments listed under the C++/Header Files table make up "vscp.dll". Executing program "vscp.dsw" commences compilation of "vscp.dll".
Java files are used to build the Java applet. It is the main module of the client application. All the direct user interaction and user interface are implemented in these files.
Resource files contain the user interface and multimedia object definitions.
The COM files are used as an interface between Java Applet and the *.dll files.
The Netscape Plugin files allow control the java applet to control the sound card. Netscape plugin files for Netscape serves the same role that the COM
module does for MS Internet Explorer.
File "strtp.dll" supports RTP communication and voice encoding/decoding functions between the client 105 and any destination device (for example, PC to phone communications) or any remote client (for example, PC to PC communications) .
Java files File Description Comment AnswerDialog.java Yes/No message dialog class BrowserType.java class for detecting surrounding browser type ContactInfo.java Contains personal information and location information of Client.

DialDialog.java Dialing Dialog class DialDialogEvent.java Dialing Dialog event class MySocket.java socket utility class MyUtil.java utility class for frequently used methods VegaCommEvent.java VegaCommEvent class VegaCommWrapper.java browser-independent class for internal vscp methods Web2PhoneApplet.java main Java Applet class which communicates with Browsers and vscp engine (plugin or COM) Web2PhoneHelper.java Front-end class for Web2PhoneApplet class Resource Files File Description Comment vscp.rc vscp dll resource template, contains version information and resource data VegaComm.rgs resource file for registering VegaComm COM

class to Windows registry busy.wav busy sound Microsoft PCM 8000 Hz, 8 bit, mono format dialtone.wav dial tone sound Microsoft PCM 8000 Hz, 8 bit, mono format ringback.wav ring sound Microsoft PCM 8000 Hz, 8 bit, mono format ToneO.wav button 0 sound Microsoft PCM 8000 Hz, 8 bit, mono f o rma t Tonel.wav button 1 sound Microsoft PCM 8000 Hz, 8 bit, mono format Tone2.wav button 2 sound Microsoft PCM 8000 Hz, 8 bit, mono format Tone3.wav button 3 sound Microsoft PCM 8000 Hz, 8 bit, mono format Tone4.wav button 4 sound Microsoft PCM 8000 Hz, 8 bit, mono format Tone5.wav button 5 sound Microsoft PCM 8000 Hz, 8 bit, mono format Tone6.wav button f sound Microsoft PCM 8000 Hz, 8 bit, mono format Tone7.wav button 7 sound Microsoft PCM 8000 Hz, 8 bit, mono format Tone8.wav button 8 sound Microsoft PCM 8000 Hz, 8 bit, mono format Tone9.wav button 9 sound Microsoft PCM 8000 Hz, 8 bit, mono format Tonestar.wav button star(*) Microsoft PCM 8000 sound Hz, 8 bit, mono format Tonepnd.wav button pound(#) Microsoft PCM 8000 sound Hz, 8 bit, mono f o rma t Microsoft COM Wrapper Class(Internet Explorer only) File Description Comment IVegaCommEvent.j IVegaCommEvent generated from ava wrapper for vscp.dll by Microsoft MS

Java Visual J++ COM

Wrapper IVegaComm.java IVegaComm generated from wrapper for vscp.dll MS

Java tagCodecConstants Codec generated from .java constants vscp.dll definition class tagStatusConstant status generated from s.java constants vscp.dll definition class VegaComm.java VegaComm generated from wrapper for vscp.dll MS

Java Microsoft COM(Common Object Model) related files for Internet Explorer File Description Comment vscp.idl IDL(Interface Definition Language) file which defines the COM interfaces exposed to external Java classes vscpCP.h C stub file for COM generated from Connection Point interface vscp.idl vscp.h C stub file for COM generated from interface vscp.idl vscp i.c C source file which has generated from declarations for vscp.idl IID(Interface ID) and CLSID(Class ID) vscp p.c C source file which generated from contains proxy stub code vscp.idl for Distributed COM not using.

Netscape Plugin related files for Netscape Communicator File Description Comment npvscp.cpp C language uses COM internally implementation file for basic Netscape Plugin methods, VegaPlugin methods, VegaCommEvent methods npwin.cpp Win32 interface from Netscape for Netscape PluginSDK source Plugin stubs.c stub files for Netscape LiveConnect(Java to Plugin communication) technology VegaPlugin.java JRI(Java Raw Interface) declaration file for Netscape Plugin methods VegaCommEvent.j JRI(Java Raw ava Interface) declaration file for status update events com-serome Vega Cross-language generated from CommEvent.c Interface file VegaCommEvent.java for status update events methods which calls external Java classes com serome Vega Header file for generated from CommEvent.h status update VegaCommEvent.java events methods which calls external Java classes com serome Vega Cross-language generated from Plugin.c Interface file VegaPlugin.java for Netscape Plugin methods which is called by external java classes com serome Vega Header file for generated from Plugin.h Netscape Plugin VegaPlugin.java methods which is called by external Java classes SinkObj.h JRI<->COM

communication class(CSinkObj) C++ Compiler(Microsoft Visual C++
6.0) related files File Description Comment vscp.def declares DLL

export functions for use with COM

and Netscape Plugin vscp.clw C language class MSVC internal information file vscp.dsp Project File information vscp.dsw Project Workspace information stdafx.cpp files for MSVC internal standard AFX

f eatures C++/Header Files File Description Comment VegaComm.cpp implementation file for main file key features (CvegaComm) VegaComm2.cpp implementation file for key features (CvegaComm) VegaComm.h header file for VegaComm. cpp, VegaComm2 . cpp WaveCtrl.cpp Manipulates Microphone and Recording &

Speaker hardware Playing devices(CwaveCtrl) WaveCtrl.h header file for WaveCtrl.cpp stvscp.cpp Frames/Deframes VSCP

packets stvscp.h VSCP header files vscp.cpp dll main file vscp.h dll main header file External Dependencies File Description Comment stnet.h network API functions stnet.dll network API functions dll sterror.h stnet error definition strtp.h RTP header file strtp.dll RTP DLL Supports RTP

communication and voice encoding/decoding functions.

stg711.h 6.711, 6.723 codes DLL

header file tsd2.d11 6.711, 6.723 codes DLL

Intermediate server programs The "VEGA Server Source Files" are executed by the selected intermediate server and support any communications to and from the selected intermediate server.
VEGA Server Source Files File Description Comment Child.c Child process main routine and thread routine which handles each call h323stub.c H.323 stack calling routines for VEGA server Sendvscp.c VSCP packets sending routines Utils.c Miscellaneous routines Vserver.c Main routine which creates child processes and routes incoming calls to child processes stdb.c Performs user authentication by looking up the DB

Stdebug.c Debugging/Logging facility H.323 programs The programs of the "H.323 Stack Packages" are executed by the selected intermediate server and support any H.323 level communications between the selected intermediate server and the ITSP gateway. The programs of the H.323 Stack Packages are used to support an H.323 protocol based communication in process 850 of FIG. 9.
H.323 Stack Packages Package Description Comment Stasn ASN.1 facilities using OSS ASN.1 package sth245 H.245 abstraction layer (Session management) sth323m H.323 Multi-session (Toplevel API) Stnet TCP/IP abstraction layer stq931 Q.931 and H.225.0 abstraction layer (Call signaling) Stras RAS abstraction layer (Registration, Admission and Status) Strtp RTP abstraction layer (Real-Time Protocol) Stwin32 Win32 functions ported on Solaris 2.x The following table provides a correspondence between actions of process 400 and the programs described in Appendix A.

Actions Pro rams 405, 410, 415, C++/Header Files, C++

420. Compiler(Microsoft Visual C++

6.0) related files, Netscape Plugin related files for Netscape Communicator, Microsoft COM(Common Object Model) related files for Internet Explorer Microsoft COM Wrapper Class(Internet Explorer only), Resource Files, and Java files.

915 External Dependencies 410, 415, and Intermediate Server Source 420 Files 850 H.323 Stack Packages APPENDIX B: DATABASE
The following commands are issued by the web server to the data base server. The data base server replies using responses, described herein. FIG. 10 schematically depicts the relationship between clients 105-i and 105-j and the data base 1000. In one embodiment, the commands are transmitted using TCP/IP.
Commands The following table shows commands and associated values.
Command Value LOGIN 0x10 REGISTER 0x11 LOGOFF 0x12 GETSTATUS 0x13 UNREGISTER 0x14 ADDUSER 0x20 DELETEUSER 0x21 MODIFYUSER 0x22 GETUSER 0x23 ADDCONTACT 0x30 DELETECONTACT 0x31 MODIFYCONTACT 0x32 GETCONTACTLIST 0x33 GETCONTACTINFO 0x34 FINDUSERNAME 0x50 Return Codes The following table shows the return codes and associated values. The return codes are generated in response to a command.

Command Value RETCODE SUCCESS 0x00 RETCODE INVALID USERID 0x01 RETCODE INVALID CONTACTID 0x02 RETCODE INVALID USERNAME 0x03 RETCODE INVALID PASSWORD 0x04 RETCODE INVALID IPADDRESS 0x05 RETCODE INVALID PORT 0x06 RETCODE SERVER RROR 0x07 E

RETCODE ALREADY EXIST 0x08 RETCODE INVALID FOLDERID 0x09 RETCODE INVALID FOLDERNAME OxOa RETCODE LOGIN RST OxOb FI

RETCODE INVALID SESSIONID OxOc RETCODE ALREADY CONNETED OxOd RETCODE NO OWNER OxOe LOGIN
The LOGON command is a command to logon to the selected intermediate server. The LOGON command format is as follows.
Field Name Octet no. format Command 1 0x10 User Name 2-11 Null-terminated ASCII

String Password 12-21 Null-terminated ASCII

String Response to LOGIN
The format of the response to the LOGIN command follows.

Field Name Octet no.

Return Code 1 Session ID 2-33 The Return Codes are any of: RETCODE SUCCESS, RETCODE INVALID USERNAME, RETCODE INVALID PASSWORD, or RETCODE SERVER ERROR. The Session ID is described earlier.
DL'r"TCTL'D
The REGISTER command registers the client's IP
Address/Port information to the database. The REGISTER
command format is as follows.
Field Name Octet no.

Command 1 Session ID 2-33 IP Address 34-37 Port Number 38-39 Override Flag 40 Command: 0x11 Session ID: described earlier IP Address (IPv4) Port Number: Port Number of selected intermediate server Override flag is either NO OVERRIDE (0x0) . Do not replace the information if already exists OVERRIDE (0x01): Replace the information if already exists.
Response to REGISTER

The format of the response to the REGISTER command follows.
Field Name Octet no.

Return Code 1 User ID 2-5 The Return Code is any of: RETCODE SUCCESS, RETCODE-INVALID_SESSIONID, RETCODE-INVALID-IPADDRESS, RETCODE INVALID PORT, RETCODE ALREADY CONNETED, or RETCODE SERVER ERROR.
The User ID is described earlier.
LOGOFF
LOGOFF command specifies which session is to end.
The LOGOFF command format is as follows.
Field Name Octet Brief description no.

Command 1 0x12 Session ID 2-33 Described earlier.

Response to LOGOFF
No Response rc mamnmrrc GETSTATUS command is a request for status information of a user The GETSTATUS command format is as follows.
Field Name Octet Brief description no.
Command 1 0x13 User ID ~2-5 Described earlier User Name 6-15 Described earlier Response to GETSTATUS
The format of the response to the GETSTATUS
command follows.
Field Name Octet no.

Return Code 1 Status 2 IP Address 3-6 Port Number 7-8 The Return Code is any of the following:
RETCODE SUCCESS, RETCODE INVALID USERID, RETCODE INVALID USERNAME, or RETCODE SERVER ERROR.
The Status is any of the following:
STATUS NOTCONNECTED (0x00): User client not registered STATUS CONNETED (0x01): User client registered IP Address is described earlier.
Port Number is described earlier.
UNREGISTER
The UNREGISTER command is a request to unregister a client's IP Address/Port information from the database. The UNREGISTER command format is as follows.
Field Name Octet no.

Command 1 0x14 User ID 2-5 Described earlier.

User Name 6-15 Described earlier.

Response to UNREGISTER

No Response.
ADDUSER
The ADDUSER command is a request to add a new user to the database and provides associated information on the new user. The ADDUSER command format is as follows.
Field Octet no. Brief description Name Command 1 0x20 User Name 2-11 First 12-21 Name Last Name 22-41 Addressl 42-81 Address2 82-121 City 122-141 State 142-143 Zip Code 144-153 Phonel 154-173 Phone2 174-193 Fax 194-213 Email 214-277 Password 278-287 Described earlier.

Publish 288 Publish Option Option 'O': Publish user information in the public directory 'N': Do not publish user information Response to ADDUSER

The response to the ADDUSER command is the following format.
Field Name Octet no.

ReturnCode 1 The Return Code is any of the following:
RETCODE SUCCESS, RETCODE INVALID USERNAME, RETCODE INVALID PASSWORD, RETCODE ALREADY EXIST, or RETCODE SERVER ERROR.
DELETEUSER
The DELETEUSER command is a request to delete a user from the database. The DELETEUSER command format is as follows.
Brief description Command 1 0x21 Session ID 2-33 Described earlier Response to DELETEUSER
The response to the DELETEUSER command is the following format.
Octet no.

Return Code 1 The Return Code is any of RETCODE SUCCESS, RETCODE INVALID SESSIONID, or RETCODE SERVER ERROR.
MODIFYUSER
The MODIFYUSER command is a request to modify user information in the database. The MODIFYUSER command format is as follows. Any field that is not to change is 0x00.
Octet Brief Description Number Command 1 0x22 User Name 2-11 First Name 12-21 Last Name 22-41 Addressl 42-81 Address2 82-121 City 122-142 State 142-143 Zip Code 144-153 Phonel 154-173 Phone2 174-193 Fax 194-213 Email 214-277 Password 278-287 Described earlier.

Publish 288 Publish Option Option 'O': Publish user information in the public directory; or 'N': Do not publish user information.

Response to MODIFYUSER

WO 01/24478 - -. PCT/US00/24485 The response to the MODIFYUSER command is the following format.
Octet Return Code 1 The Return Code is any of the following:
RETCODE SUCCESS, RETCODE INVALID SESSIONID, or RETCODE SERVER ERROR, GETUSERINFO
The GETUSERINFO command is a request to retrieve user information from the database. The GETUSERINFO
command format is as follows.
Octet no. Brief Description Command 1 0x23 Session ID 2-33 Described earlier.

Response to GETUSERINFO
The response to the GETUSERINFO command is the following format.
Octet no. Brief Description Return Code 1 User Name 2-11 First Name 12-21 Last Name 22-41 Addressl 42-81 Address2 82-121 City 122-141 State 142-143 Zip Code 144-153 Phonel 154-173 Phone2 174-193 Fax 194-213 Email 214-277 Password 278-287 Described below.

Publish 288 Described Option earlier.

The Return Code is any of the following:
RETCODE SUCCESS, RETCODE INVALID SESSIONID, or RETCODE SERVER ERROR.
ADDCONTACTINFO
The ADDCONTACTINFO command is a request to add a new contact to the user's contact list stored the database. The ADDCONTACTINFO command format is as follows.
Octet no. Brief Description Command 1 0x30 Session ID 2-33 Described earlier.

Folder ID 34-35 2 byte Folder Identifier.

User Name 36-45 First Name 46-65 Last 66-85 Name Phonel Type 86 Described below.

Phonel 87-106 Phone2 Type 107 Described below.

Phone2 108-127 Phone3 Type 128 Described below.

Phone3 129-148 Phone4 Type 149 Described below.

Phone4 150-169 Email 170-233 Phone Types are any of the following:
HOME PHONE: Home Phone Number WORK PHONE: Work Phone Number CELL PHONE: Cell Phone Number PAGER PHONE: Pager Number OTHER PHONE: Other Number Response to ADDCONTACTINFO
The response to the ADDCONTACTINFO command is the following format.
Octet no.

Return Code 1 Contact ID 2-5 The Return Code is any of the following:
RETCODE SUCCESS, RETCODE INVALID SESSIONID, RETCODE INVALID USERNAME, RETCODE ALREADY EXIST, or RETCODE SERVER ERROR.
The Contact ID is a 4 byte Contact Identifier.
nor ~m~rnmmnr~mTt~T~n The DELETECONTACTINFO command is a request to delete contact information from a user's contact list that is stored in the database. The DELETECONTACTINFO
command format is as follows.
Octet Brief Description Command 1 0x31 Session ID 2-33 Described earlier.

Contact ID 34-37 Described earlier.

Response to DELETECONTACTINFO
The response to the DELETECONTACTINFO command is the following format.
8 7 6 5 4 3 2 Octet no.

Return Code 1 The Return Code is any of the following:
RETCODE SUCCESS, RETCODE INVALID SESSIONID, RETCODE INVALID CONTACTID, RETCODE NO OWNER, or RETCODE SERVER ERROR.
MODIFYCONTACTINFO
The MODIFYCONTACTINFO command is a request to modify a contact in a user's contact list that is stored in the database. The MODIFYCONTACTINFO command format is as follows.
Octet Brief Description Command 1 0 x 3 2 Session ID 2-33 Contact ID 34-37 Folder ID 38-41 User Name 42-51 First Name 52-71 Last Name 72-91 Phonel Type 92 Phonel 93-112 Phone2 Type 113 Phone2 114-133 Phone3 Type 134 Phone3 135-154 Phone4 Type 155 Phone4 156-175 Email 176-239 Response to MODIFYCONTACTINFO
The response to the MODIFYCONTACTINFO command is a one octet ~~Return Code".
The Return Code is any of the following:
RETCODE SUCCESS, RETCODE INVALID SESSIONID, RETCODE INVALID CONTACTID, RETCODE INVALID USERNAME, RETCODE ALREADY EXIST, RETCODE NO OWNER, or RETCODE SERVER ERROR.
GETCONTACTLIST
The GETCONTACTLIST command is a request for a list of contacts from the user's contact list based on provided search criteria. The GETCONTACTLIST command format is as follows.

Octet no. Brief description Command 1 0x3 3 Session ID 2-33 Folder ID 34-35 Starting Index 36-37 Part of the contacts that satisfies the search criteria. The retrieved contacts that has the index less than the starting index are discarded.

# of Entries 38-39 Number of entries to retrieve.

First Index 40 Retrieve the contacts Character that has a user name that starts with an alphabet between the first and last character.

Last Index 41 Retrieve the contacts Character that has a user name that starts with an alphabet between the first and last character.

Search String 87-150 A search string that is matched against the contact list.

Sort Option 151 The Sort Option is any of SORT LASTNAME ASC, SORT LASTNAME DES, SORT FIRSTNAME ASC, SORT FIRSTNAME DES, SORT USERNAME ASC, or SORT USERNAME DES.
Response to GETCONTACTLIST
The response to GETCONTACTLIST is a header followed by multiple contact entries.
Header Octet no.

# of Total Entries 1-2 # of Entries returned for this 3-4 query Each Contact Entr Octet Brief description 1-4 4 byte Contact Contact ID

Contact User ID 5-8 4 byte Contact User ID

First Name 9-28 Last Name 29-48 Phonel Type 49 Phonel 50-69 Phone2 Type 70 Phone2 71-90 Phone3 Type 91 WO 01/24478 pCT/US00/Z4485 Phone3 92-111 Phone4 Type 112 Phone4 113-132 Email 133-196 Null-terminated ASCII string The Phone Types are any of the following:
HOME PHONE (Home Phone Number), WORK PHONE (Work Phone Number), CELL PHONE (Cell Phone Number), PAGER PHONE (Pager Number), OTHER PHONE (Other Number).
GETCONTACTINFO
The GETCONTACTINFO command is a request for detailed information of a specific contact entry. The GETCONTACTINFO command format is as follows.
Octet Brief description Command 1 0x34 Session ID 2-33 User ID 34-37 Contact ID 38-41 Response to GETCONTACTINFO
The response to the GETCONTACTINFO command is the following format.

Octet Brief description Return Code Contact User ID 2-5 Contact User Name 6-15 First Name 16-35 Last Name 36-45 Phonel Type 46 Phonel 47-76 Phone2 Type 77 Phone2 78-97 Phone3 Type 98 Phone3 99-118 Phone4 Type 119 Phone4 120-139 Email 140-203 The Return Code is any of the following:
RETCODE SUCCESS, RETCODE INVALID SESSIONID, RETCODE INVALID USERID, RETCODE INVALID CONTACTID, RETCODE NO OWNER, RETCODE SERVER ERROR
The Phone Types are any of the following:
HOME PHONE (Home Phone Number) WORK PHONE (Work Phone Number) CELL PHONE (Cell Phone Number) PAGER PHONE (Pager Number) OTHER PHONE (Other Number) FTT~TTIiTCI: R>\TAMT~' The FINDUSERNAME command is a request for a list of users that match the first, last name and email.
The FINDUSERNAME command format is as follows.
Octet Brief description Command 1 0x50 First Name 2-21 Last Name 22-41 Email 42-105 Response to FINDUSERNAME
The response to the FINDUSERNAME command includes a header followed by multiple contact entries.
Header 8 7 6 5 4 3 2 1 Octet no.

# of Entries 1-2 Each User Entry 8 7 6 5 4 3 2 1 Octet no.

User Name 1-10 First Name 11-30 Last Name 31-50 Each of User Name, First Name, Last Name are Null-terminated ASCII strings.

APPENDIX C
The entry node maintains the IP Address, Port numbers, and the status information of selected intermediate servers. The entry node further routes a client's call request to an intermediate server based on the status information.
The entry node can be used for disabling or enabling intermediate servers. In the case of a failure of an intermediate server, a backup intermediate server can easily replace the dysfunctional intermediate server.
The entry node maintains a TABLE of information for all the intermediate servers. The entry node periodically broadcasts a REPORT-REQUEST packet to the intermediate servers, and all the intermediate servers register/report their information in response to the packet. Because the REPORT REQUEST packet is broadcasted periodically, new intermediate servers can be added without having to restart the entry node. In this embodiment, the REPORT REQUEST is transmitted using UDP (User Datagram Protocol) over IP.
The REPORT REQUEST packet includes an IP address and a port number. The IP Address is, e.g., a 4 byte IPv4 Address of the entry node. The port number is, e.g., a 2 byte port number that the entry node listens for response.
A SERVER REPORT packet is transmitted by an intermediate server in response to the REPORT REQUEST.
It contains the IP Address/Port information and the load information of the intermediate server 130. In this embodiment, the SERVER REPORT is transmitted using UDP/TCP/IP.
The following table describes fields in the SERVER REPORT packet.
Field Name Octet no.

IP Address Port Number 5-6 Number of Active Sessions 7-8 Max Number of Sessions 9-10 The IP Address is, e.g., a 4 byte IPv4 Address of the corresponding intermediate server. The Port Number is, e.g., 2 byte port number that the corresponding intermediate server listens for communications from the client. This port number is passed to the client upon request by the entry node. The Number of Active Sessions is the number of calls that the corresponding intermediate server is handling. This information is used by the entry node for distributing the client's call requests. The Max Number of Sessions is a maximum number of concurrent calls that the corresponding intermediate server is capable of handling.

WO 01/24478 PCT/US00/?A485 APPENDIX D: Messages Message transmission protocol A description of a suitable transport topology for the messages is provided. In this embodiment, messages are transmitted using TCP/IP. The following conventional TCP header is used to transport all messages.
Field Name Octet no.

Protocol Discriminator (hi-byte) 1 Protocol Discriminator (lo-byte) 2 Content Length (hi-byte) 3 Content Length (lo-byte) 4 The Protocol Discriminator species byte orders.
Byte order is the order used for forming a 'word'. Some platforms use the higher byte first, and some use the lower byte first. For example, to express the number '1', it is 00 O1 on some systems, and O1 00 on others.
Byte orders are different in different CPU platforms.
For example, Sun SPARC uses different byte order from Intel's. For network applications, which typically would pass data to another heterogeneous system, it is important to let the remote party which byte order scheme is being used.
In this embodiment, the Protocol Discriminator is 0x5354. The Content Length represents a total length of the packet, i.e., the header and + message content together.
Message header The following is a header for messages.
Field Name Octet no.

Message Type (hi-byte) I

Message Type (lo-byte) 2 Version Info - Major (hi-byte) 3 Version Info - Major (hi-byte) 4 Version Info - Minor (hi-byte) 5 Version Info - Minor (lo-byte) 6 The Message Type field species the type of message. The following tables provides associated values and messages.
Message Type Value SETUP 0x0001 CALLPROCEED 0x0002 CONNECT 0x0003 ALERT 0x0004 RELEASE 0x0005 DTMF 0x0006 STATUS 0x0007 The Version Info field specifies the Version Number of the message. Because the message protocol definitions may change in the future, by using the version info, the receiver can reject a message if it is a higher version than it supports.
Various Messages The following message can be used, but is not shown in FIG. 5.
STATUS. The client uses the STATUS message to report current status information to the selected intermediate server. The following table provides parameters of the STATUS message.
Field Name Octet no.

Call Reference Value 1-8 Status 9-10 The Call Reference Value field specifies a unique identifier (number) of the call session. The Status field species the status of the client. For example a value of 0x00 species the connection to the client is alive

Claims

What is claimed is:

1. A method of providing communications between a client and destination audio receiver, the method comprising the acts of:
accessing a web site;
providing link information to a entry node;
providing link information to an intermediate node:
accessing the intermediate node;
providing link information to a gateway node;
and accessing the gateway node.

2. The method of Claim 1, wherein the act of providing link information to an intermediate node comprises determining an intermediate node with the lowest activity level.

3. The method of Claim 1, wherein the act of providing link information to the gateway node further comprises determining a least cost gateway.

4. The method of Claim 1, wherein the gateway node comprises an ITSP gateway.

5. The method of Claim 1, further comprising using a PSTN associated with the destination audio receiver.

6. The method of Claim 5, wherein the destination audio receiver comprises a remote client.

7. The method of Claim 1, wherein the intermediate node establishes H.323 based communication with the gateway node.

8. The method of Claim 1, wherein the web site provides advertising and wherein the communications are free to select users.

9. An apparatus that provides communications between a client and destination audio receiver, the apparatus comprising:
at least one gateway server that is capable of communicating with the destination audio receiver;
at least one intermediate server that is capable of communicating with the at least one gateway server;
an entry node that is capable of communicating with the at least one intermediate server and the client, wherein the client signals the entry node to select an intermediate server, the selected intermediate server selects a gateway server, the selected intermediate server initiates communications with the gateway server, and the client and destination audio receiver communicate without use of the entry node.

10. The apparatus of Claim 9, wherein the destination audio receiver comprises a remote client.

11. The apparatus of Claim 9, wherein the apparatus provides free audio communications between the client and destination audio receiver by providing advertising to the client.

12. The apparatus of Claim 11, wherein the advertising comprises video advertisements.

13. The apparatus of Claim 11, wherein the advertising comprises audio advertisements.

14. The apparatus of Claim 9, wherein the destination audio receiver comprises a remote client.

15. A method of providing free audio communications to a user, the acts comprising:
providing an advertisement to the user;
providing a destination audio receiver identifier; and providing a signal path for audio communications using the destination audio receiver identifier.

16. The method of Claim 15, wherein the providing an advertisement further includes:
using a website to provide a visual advertisement.

17. The method of Claim 15, wherein the providing an advertisement further includes:
generating an audio advertisement.

18. The method of Claim 15, wherein the providing a signal path further includes:
providing link information to a entry node;
providing link information to an intermediate node;
accessing the intermediate node;
providing link information to a gateway node;
and accessing the gateway node.

19. The method of Claim 15 wherein the destination audio receiver comprises a remote client.

20. The method of Claim 19 wherein the destination audio receiver identifier comprises an IP address of the remote client.