EP1190550A2 - Systeme de communications evolutif - Google Patents

Systeme de communications evolutif

Info

Publication number
EP1190550A2
EP1190550A2 EP00970450A EP00970450A EP1190550A2 EP 1190550 A2 EP1190550 A2 EP 1190550A2 EP 00970450 A EP00970450 A EP 00970450A EP 00970450 A EP00970450 A EP 00970450A EP 1190550 A2 EP1190550 A2 EP 1190550A2
Authority
EP
European Patent Office
Prior art keywords
client
gateway
communications
providing
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP00970450A
Other languages
German (de)
English (en)
Inventor
Wongyu Cho
Hyeonkuk Jeong
Woohyung Kim
Dyunduk Ahn
Doyon Kim
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Dialpad Communications Inc
Original Assignee
Dialpad Communications Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Dialpad Communications Inc filed Critical Dialpad Communications Inc
Publication of EP1190550A2 publication Critical patent/EP1190550A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1106—Call signalling protocols; H.323 and related
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H04M7/1285—Details of finding and selecting a gateway for a particular call

Definitions

  • the present invention relates to a method and apparatus for providing video and voice communications.
  • VoIP voice over internet protocol
  • PSTN public switched telephone network
  • 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.
  • 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.
  • RTP real-time protocol
  • 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).
  • a system 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.
  • communications between a personal computer and audio communications device is supported by at least one intermediate device.
  • the personal computer 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 .
  • communications between client and remote client are direct.
  • client and remote client communicate without need for the client to support H.323.
  • considerable software storage is avoided.
  • 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. 4, in accordance with an embodiment of the invention.
  • 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.
  • 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.
  • any client 105-1 to 105-N accesses system 100 through a public or private network such as the internet.
  • client 105 refers to any client 105-1 to 105-N unless otherwise specified.
  • 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.
  • 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.
  • PSTN public switched telephone network
  • 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 145-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.
  • PSTN public switched telephone network
  • ITSP gateway 145 refers to any ITSP gateways 145-1 to 145-N unless otherwise specified.
  • each ITSP gateway uses a distinct implementation of the H.323 protocol to support communications .
  • An exemplary embodiment of client 105 is a conventional personal computer (PC) .
  • PC personal computer
  • 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 NTTM or the Microsoft Windows 95TM Operating System (OS) , the IBM OS/2, the Apple MAC OS, or the UNIX OS such as the HP-UX OS.
  • an operating system such as the Microsoft Windows NTTM or the Microsoft Windows 95TM 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 NavigatorTM to access a web page with graphical content.
  • 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 hypertext transfer protocol (HTTP) or another transfer protocol for communicating between the server and the browser.
  • HTTP hypertext transfer protocol
  • the URL is transmitted to the host server which stores information corresponding to the URL.
  • 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 MicrosystemsTM, and uses either Microsoft NT 4.0, IIS, or UNIX operating system.
  • the website server supports requests from the user for features provided by the website.
  • 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.
  • 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.
  • intermediate server 130 refers to any intermediate server 130-1 to 130-X unless otherwise specified.
  • a distinct database server 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 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.
  • 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.
  • 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.
  • 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.
  • 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) .
  • 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.
  • FIG. 6 provides a suitable flow diagram of action 405 (FIG. 4).
  • 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.
  • 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.
  • 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.comTM, Excite.comTM, and jfax.comTM.
  • web site 700 and system 100 allow users to respond vocally to voice mail messages, electronic mails, or faxes.
  • the web site server uploads executable files that form "strtp.dll”, “stnet.dll”, “vscp.dll”, and “tsd2.dll” to the PC of client 105.
  • Such files and such *.dll files are listed in Appendix A.
  • action 620 the user enters a destination phone number, for example, into field 704 of the web site 700.
  • caption "address book” 706 of website 700 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.
  • 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.
  • a conventional graphical banner ad is displayed 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.
  • the client connects to a entry node 120 using, for example, the TCP/IP protocol.
  • 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 .
  • 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.
  • action 640 corresponds to the message entitled VEGA Server 504.
  • the contact information includes the IP address and port number of the selected intermediate server.
  • the IP Address is a 4 byte IPv4 address (IP version 4) 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.
  • 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 provides a description of a suitable technique whereby the entry node 120 monitors the activity level of intermediate servers 130.
  • 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
  • the entry node selects an intermediate server 130 having the lowest associated identification number.
  • Other selection methods can be used, such as random selection.
  • FIG. 8 provides a suitable flow diagram of action 410 (FIG. 4) .
  • Appendix A provides a description of programs used in action 410.
  • 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.
  • action 810 corresponds to (second occurring) "TCP Connect 506".
  • 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 the selected intermediate server 130.
  • the following table provides a description of fields used in message VSCP SETUP.
  • Field Client-side Media Type represents the transmitted media type.
  • 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.
  • 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”) .
  • selected 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.
  • the selected intermediate server In action 850, the selected intermediate server
  • the selected ITSP gateway 145 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.
  • the Q.931 and H.245 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.
  • each ITSP gateway 145 may use a distinct style of H.323, the selected intermediate server 130 advantageously can support each distinct style of
  • FIG. 9 schematically depicts operations of action 850 in more detail.
  • the communications of action 850 use the TCP/IP protocol.
  • action 910 a connection with the specified destination audio communications device 150 is established.
  • action 910 further includes the actions 910-1 to 910-7.
  • 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.
  • 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.
  • 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.
  • action 910-2 the selected ITSP gateway 145 dials the destination PSTN phone number.
  • Action 910-2 corresponds to Dial 514 of FIG. 5.
  • 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.
  • 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 518 of FIG. 5.
  • 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.
  • 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.
  • 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.
  • action 920 the communication standard between the selected intermediate server 130 and selected gateway 145 is set.
  • action 920 includes actions 920-1 to 920-2.
  • 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.
  • TCS terminal capability set
  • 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.
  • action 930 a communication relationship is established between selected intermediate server 130 and selected ITSP gateway 145.
  • action 930 includes actions 930-1 to 930-3.
  • Action 930-1 corresponds to the H.245
  • 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
  • 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
  • a voice channel is established between selected intermediate server 130 and selected
  • action 940 includes actions 940-1 to 940-4.
  • 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.
  • 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.
  • 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.
  • OLC open logical channel
  • Action 940-3 corresponds to the H.245 OLC 540 of FIG. 5.
  • 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.
  • 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.
  • CONNECT corresponds to VSCP CONNECT 544 of FIG. 5.
  • the following table provides a description of CONNECT.
  • 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.
  • 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.
  • other protocols can be used besides RTP, such as any other proprietary media streaming protocol.
  • program "strtp.dll" provides transmission of encoded voice.
  • An exemplary technique to encode and decode voice is available from the DSP Group of Santa Clara, CA.
  • program “tsd2.dll” includes the exemplary technique to encode and decode voice.
  • 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.
  • 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.
  • a client 105 issues a RELEASE (548, FIG. 5) to the selected intermediate server 130 when a user desires to terminate a talk.
  • 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.
  • 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).
  • the selected ITSP gateway 145 issues a hangup command to the PSTN to discontinue a session (see Hangup 554 of FIG. 5) .
  • 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,
  • the Log Database is stored by the database server, described earlier and in Appendix B.
  • the client 105 sends the digit to the selected intermediate server 130 using the DTMF message.
  • the selected intermediate server 130 transfers the DTMF message to the selected ITSP gateway using an H.245 message.
  • the following table provides parameters of the DTMF message.
  • 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.
  • the RELEASE message is used if the selected intermediate server or client do not receive a message, such as SETUP, CALLPROCEED, ALERT, or CONNECT, in an allotted time.
  • a message such as SETUP, CALLPROCEED, ALERT, or CONNECT.
  • the Call Reference Value field identifies a particular communication session.
  • the following table provides potential values and associated meanings for each Reason field.
  • 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
  • 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.
  • the client and remote client are each identified by an IP address and port number.
  • each client does not need to support the full H.323 protocol, which would be 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.
  • 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).
  • 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.
  • 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.
  • 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) .
  • the "VEGA Server Source Files" are executed by the selected intermediate server and support any communications to and from the selected intermediate server.
  • 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.
  • 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.
  • the commands are transmitted using TCP/IP.
  • the following table shows commands and associated values .
  • the following table shows the return codes and associated values.
  • the return codes are generated in response to a command.
  • the LOGON command is a command to logon to the selected intermediate server.
  • the LOGON command format is as follows.
  • the Return Codes are any of: RETCODE_SUCCESS, RETCODE_INVALID_USERNAME, RETCODE_INVALID_PASSWORD, or RETCODE_SERVER_ERROR.
  • the Session ID is described earlier.
  • the REGISTER command registers the client's IP Address/Port information to the database.
  • the REGISTER command format is as follows.
  • IP Address IPv4
  • Port Number Port Number of selected intermediate server Override flag is either
  • 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 command specifies which session is to end.
  • the LOGOFF command format is as follows.
  • GETSTATUS command is a request for status information of a user
  • the GETSTATUS command format is as follows.
  • 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
  • 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.
  • 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 .
  • the response to the ADDUSER command is the following format.
  • the Return Code is any of the following: RETCODE_SUCCESS, RETCODE_INVALID_USERNAME, RETCODE_INVALID_PASSWORD, RETCODE_ALREADY_EXIST, or RETCODE SERVER ERROR.
  • the DELETEUSER command is a request to delete a user from the database.
  • the DELETEUSER command format is as follows.
  • the response to the DELETEUSER command is the following format.
  • the Return Code is any of RETCODE_SUCCESS, RETCODE INVALID SESSIONID, or RETCODE SERVER ERROR.
  • 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.
  • the response to the MODIFYUSER command is the following format.
  • the Return Code is any of the following: RETCODE_SUCCESS, RETCODE_INVALID_SESSIONID, or RETCODE SERVER ERROR,
  • the GETUSERINFO command is a request to retrieve user information from the database.
  • the GETUSERINFO command format is as follows.
  • the response to the GETUSERINFO command is the following format.
  • the Return Code is any of the following: RETCODE_SUCCESS, RETCODE_INVALID_SESSIONID, or RETCODE SERVER ERROR.
  • 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 .
  • 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
  • the response to the ADDCONTACTINFO command is the following format .
  • 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.
  • 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.
  • the response to the DELETECONTACTINFO command is the following format.
  • the Return Code is any of the following: RETCODE_SUCCESS, RETCODE_INVALID_SESSIONID, RETCODE_INVALID_CONTACTID, RETCODE_NO_OWNER, or RETCODE SERVER ERROR.
  • 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.
  • 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.
  • 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.
  • the response to GETCONTACTLIST is a header followed by multiple contact entries.
  • 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) .
  • the GETCONTACTINFO command is a request for detailed information of a specific contact entry.
  • the GETCONTACTINFO command format is as follows.
  • the response to the GETCONTACTINFO command is the following format.
  • 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)
  • 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.
  • the response to the FINDUSERNAME command includes a header followed by multiple contact entries.
  • 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.
  • 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.
  • 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.
  • the SERVER_REPORT is transmitted using UDP/TCP/IP.
  • 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.
  • messages are transmitted using TCP/IP.
  • TCP/IP Transmission Control Protocol/IP
  • the following conventional TCP header is used to transport all messages .
  • the Protocol Discriminator species byte orders are 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 01 on some systems, and 01 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.
  • the Protocol Discriminator is 0x5354.
  • the Content Length represents a total length of the packet, i.e., the header and + message content together.
  • the Message Type field species the type of message.
  • the following tables provides associated values and messages .
  • 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.
  • 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.
  • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un système polyvalent (audio, vidéo, donnés et télécopie) assurant la liaison entre un ordinateur personnel d'origine et un dispositif de communications audio du type téléphone ou ordinateur personnel de destination. La liaison est d'abord établie avec un noeud d'entrée qui choisit un serveur intermédiaire, lequel sélectionne une passerelle de téléphonie sur Internet (ITSP), par exemple, afin d'assurer l'accès au dispositif de communications audio. Le serveur établit les communications audio ou vidéo avec la passerelle ITSP en utilisant par exemple la norme H.323. Le serveur demande ensuite à l'ordinateur personnel d'origine de communiquer directement avec la passerelle ITSP. Ainsi, le système assure de manière évolutive les communications audio ou vidéo dans un environnement de client 'maigre'.
EP00970450A 1999-09-24 2000-09-06 Systeme de communications evolutif Withdrawn EP1190550A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US40189899A 1999-09-24 1999-09-24
US401898 1999-09-24
PCT/US2000/024485 WO2001024478A2 (fr) 1999-09-24 2000-09-06 Systeme de communications evolutif

Publications (1)

Publication Number Publication Date
EP1190550A2 true EP1190550A2 (fr) 2002-03-27

Family

ID=23589696

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00970450A Withdrawn EP1190550A2 (fr) 1999-09-24 2000-09-06 Systeme de communications evolutif

Country Status (8)

Country Link
EP (1) EP1190550A2 (fr)
JP (1) JP2003530732A (fr)
KR (1) KR20010050717A (fr)
CN (1) CN1415159A (fr)
AU (1) AU7983000A (fr)
BR (1) BR0006923A (fr)
CA (1) CA2343754A1 (fr)
WO (1) WO2001024478A2 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002088876A2 (fr) * 2001-04-27 2002-11-07 The Boeing Company Procede et systeme conçus pour un adressage virtuel dans un reseau de communications
WO2006010193A1 (fr) * 2004-07-30 2006-02-02 Cockatu Pty Limited Communication vocale sur l'internet
CN1893426B (zh) * 2005-07-08 2010-08-04 中国电信股份有限公司 实现私网视讯终端穿越防火墙的方法和系统
GB2443889A (en) 2006-11-20 2008-05-21 Skype Ltd Method and system for anonymous communication
GB0623621D0 (en) 2006-11-27 2007-01-03 Skype Ltd Communication system
GB0623622D0 (en) 2006-11-27 2007-01-03 Skype Ltd Communication system

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6430282B1 (en) * 1995-09-29 2002-08-06 Nortel Networks Limited Methods and apparatus for originating voice calls
JP3517052B2 (ja) * 1996-03-19 2004-04-05 富士通株式会社 音声通信システムにおけるゲートウェイ選択制御システム
US6031836A (en) * 1996-09-13 2000-02-29 Lucent Technologies Inc. Web-page interface to telephony features
GB9711788D0 (en) * 1997-06-06 1997-08-06 Northern Telecom Ltd Method and interface for connecting communication traffic between narrowband and broadband networks
JPH114292A (ja) * 1997-06-12 1999-01-06 Hitachi Ltd 通信システム
JP3263339B2 (ja) * 1997-07-18 2002-03-04 日本電信電話株式会社 インターネット・電話網統合利用方法及びそのシステム
JPH1155327A (ja) * 1997-08-05 1999-02-26 Matsushita Electric Ind Co Ltd 代理サーバの接続制御サーバ，代理サーバ，及びネットワーク制御方法
IL135131A0 (en) * 1997-09-16 2001-05-20 Transnexus Llc Internet telephony call routing engine

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0124478A2 *

Also Published As

Publication number Publication date
WO2001024478A2 (fr) 2001-04-05
CN1415159A (zh) 2003-04-30
CA2343754A1 (fr) 2001-04-05
JP2003530732A (ja) 2003-10-14
BR0006923A (pt) 2002-04-30
WO2001024478A3 (fr) 2002-01-17
AU7983000A (en) 2001-04-30
KR20010050717A (ko) 2001-06-15

Similar Documents

Publication Publication Date Title
US8793338B2 (en) Providing content delivery during a call hold condition
AU2002345133B2 (en) Method and apparatus for obtaining data information
US8634412B2 (en) Session initiation protocol (SIP) message incorporating a multi-purpose internet mail extension (MIME) media type for describing the content and format of information included in the SIP message
US6298120B1 (en) Intelligent processing for establishing communication over the internet
US7283515B2 (en) Internet telephony network and methods for using the same
CN103634490B (zh) 一种用于使得使用sip的企业网络能够存活的网关
US6999458B2 (en) Internet telephony network and methods for using the same
KR100415023B1 (ko) 무선 통신망을 통한 병행 인터넷 프로토콜 기반 음성 및데이터 서비스
US20050073999A1 (en) Delivery of profile-based third party content associated with an incoming communication
US20020101853A1 (en) Caller identification and voice/data synchronization for internet telephony and related applications
US7230945B2 (en) Method for sending dual-tone multi-frequency signal using voice over internet protocol
WO2008011143A2 (fr) Système et procédé d'autorisation de service de dispositif mobile
WO2008095084A1 (fr) Technique permettant de transmettre des informations secondaires à un équipement utilisateur
US20030112932A1 (en) Call charging notification
EP2130352A2 (fr) Technique de fourniture d'objets de données avant l'établissement d'appel
US20030003898A1 (en) Utilizing parallel available services over a wireless network
US20040059820A1 (en) Method and apparatus of communications over a network
WO2001024478A2 (fr) Systeme de communications evolutif
CN1222193C (zh) 通信网络
EP1275233B1 (fr) Procede, systeme de communication interreseau et agencement dans un reseau de communication
JP3821752B2 (ja) インターネット電話における広告宣伝システム
KR100369809B1 (ko) 브이오아이피를 이용한 이중톤다중주파수 신호 전송방법
Headquarters Cisco Gatekeeper External Interface Reference, Version 4.2
JP2000324256A (ja) インターネット電話装置

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

AK Designated contracting states

Kind code of ref document: A2

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

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20020718