WO2002003713A1

WO2002003713A1 - Voice-over-ip using h.323-enabled gr-1129 architecture

Info

Publication number: WO2002003713A1
Application number: PCT/US2001/020438
Authority: WO
Inventors: Li Zhang; Jeffrey P. Cassanova; Hong Gang Zhu; Robert B. Collicott
Original assignee: Bellsouth Intellectual Property Corporation
Priority date: 2000-06-29
Filing date: 2001-06-27
Publication date: 2002-01-10
Also published as: CA2411259A1; EP1295486A1; AU2001271521A1

Abstract

The invention provides a communications system and method for transporting data over a communications system. The system comprises a Service Switching Point communicating with a gateway device. Communication between the gateway device and the Service Switching Point is conducted using GR-1129 protocol. The gateway device may be capable of transporting data in accordance with a voice-based multimedia protocol, including the H.323 specifications. The system may further comprise a first communication device communicating with the Service Switching Point and a second communication device communicating with the Service Switching Point. The second communication device is capable of transmitting voice data to the Service Switching Point using an Internet Protocol, in accordance with the voice-based multimedia protocol. The system may further comprise a gatekeeper device communicating with a Service Control Point and the gateway device. The gatekeeper device administers communication with the gateway and is capable of transporting data in accordance with the voice-based multimedia protocol. Communication between the gatekeeper and the Service Control Point is conducted using packet-switched data. The Service Control Point includes a service package application capable of processing instructions received from the gatekeeper.

Description

VOICE-OVER-IP USING H.323-ENABLED GR-1129 ARCHITECTURE

Cross-Reference to Related Application The subject matter disclosed herein is related to the subject matter disclosed in co-pending Application Serial No. 09/606,836, filed on June 29, 2000, entitled "Voice-Over-JJP Call Forwarding."

Field of the Invention The invention relates to the field of communications systems. More specifically, the invention relates to the field of Voice-Over-IP communication.

Background of the Invention

With the creation of the World Wide Web (WWW), the Internet has exploded into a global data network. In the process, the Internet has made Internet Protocol (IP) the de facto standard for data networking. IP specifies the format of a message transmitted over the Internet. With IP, before the message is transmitted, it is divided into individual packets. Each packet contains the destination address in addition to a portion of the content of the message itself. Each packet is then transmitted individually and may even follow different routes to its destination. Once all the packets that form the message arrive at the destination, they are recompiled into the original message.

Recently, the transmission of voice-based communications on the Internet using IP, called "Voice-over-JJP" (VoIP) has gained wide acceptance in the telecommunications and data networking industries. VoIP operates on a standard set of protocols, called "H.323." H.323 is an "umbrella" of standards for all real-time multimedia communications, including VoIP, over packet-based networks like the Internet. These standards define how H.323 components should establish calls, exchange video and audio data, and participate in multi-party communications. The H.323 standards also define how H.323 components should interact with non-H.323 devices, like a telephone connected to a Public Service Switching Network (PSTN). Other VoIP multimedia protocols may include Session invitation Protocol, Session Description Protocol, and Simple Conference Control Protocol.

Unlike the packet-based IP network, the PSTN employs traditional circuit- switched architecture. Circuit-switched technology is a type of communications in which a dedicated line, or circuit, is established for the duration of a transmission to permit the transfer of data between two parties. Circuit-switching is ideal when data must be transmitted quickly and when the data must arrive in the same order in which it is sent. Although PSTN and IP networks are fundamentally different in terms of data routing and performance, an H.323 gateway provides an acceptable interface, thus making it possible for the networks to exchange voice and data traffic. Specifically, the H.323 gateway allows a VoIP client to communicate with non-H.323 entities, like a telephone on a PSTN.

To date, however, the H.323 gateway's marriage of the IP domain and the PSTN domain has granted only limited control of the interface. Therefore, there exists a need to create an architectural interface between the IP domain and the traditional PSTN domain that allows maximum "controllability."

Summary of the Invention The invention provides a communications system and method for transporting data over a communications system. The system comprises a Service Switching Point communicating with a gateway device. Communication between the gateway device and the Service Switching Point is conducted using GR-1129 protocol. The gateway device may be capable of transporting data in accordance with a voice-based multimedia protocol, including the H.323 specifications. The system may further comprise a first communication device communicating with the Service Switching Point and a second communication device communicating with the Service Switching Point. The second communication device is capable of transmitting voice data to the Service Switching Point using an Internet Protocol, in accordance with the voice-based multimedia protocol. The system may further comprise a gatekeeper device communicating with a Service Control Point and the gateway device. The gatekeeper device administers communication with the gateway and is capable of transporting data in accordance with the voice-based multimedia protocol. Communication between the gatekeeper and the Service Control Point is conducted using packet-switched data. The Service Control Point includes a service package application capable of processing instructions received from the gatekeeper. The inventive method comprises receiving packet-switched data from a first network appliance, receiving a communication request from another network appliance, and providing a communication path using GR-1129 protocol over a packet-switched network. The communication path is provided in response to the commumcation request and it allows communication between the first network appliance and the second network appliance. The method may further comprise transporting voice-based data over the communication path in accordance with a multimedia specification. The method also may comprise verifying registration of the first network appliance with the packet- switched network, and ensuring that the first network appliance has access to the communication path.

Brief Description of the Drawings

Other features of the invention are further apparent from the following detailed description of the presently preferred embodiments of the invention taken in conjunction with the accompanying drawings, of which:

Figure 1 is a simplified block diagram of an advanced intelligent telecommunications network (AIN);

Figure 2 is a message flow diagram detailing the exchange of information between an intelligent peripheral, a Service Control Point, and a Service Switching Point;

Figure 3 is a block diagram of a communications system, according to the invention;

Figure 4 is a flow diagram detailing how a subscriber accesses an Internet server and sets an Internet Call Waiting trigger on the Service Switching Point, according to the invention;

Figure 5 is a flow diagram detailing how the subscriber informs a public service telephone network (PSTN) and an H.323 network that it is VoIP-capable, according to the invention;

Figures 6A and 6B illustrate a flow diagram illustrating the setup of a communication path between the PSTN and the H.323 network, according to the invention; Figures 7A and 7B illustrate a flow diagram of the "Call Setup Messaging" that occurs between an H.323 gatekeeper, an H.323 gateway, and an H.323 client, according to the invention;

Figures 8A and 8B illustrate a flow diagram detailing the "Call Revert" functionality, according to the invention;

Figures 9A and 9B illustrate a flow diagram detailing the "Call Forward" functionality, according to the invention;

Figure 10 is a flow diagram illustrating what occurs when a caller terminates the call between a subscriber and the caller, according to the invention; Figures 11 A and 1 IB provide a flow diagram illustrating call termination when the subscriber terminates the call between the subscriber and the caller, according to the invention;

Figure 12 provides an example of a "Caller ID" pop-up screen that may appear on a computer, according to the invention; and Figure 13 is an example of a "Call Redirect" pop-up screen that may appear on a computer, according to the invention.

Detailed Description of the Invention

GR-1129 Architectural Overview

Figure 1 is a block diagram of a data network 100 that provides communication to a subscriber 101 via a public switched telecommunication network (PSTN) 104 and an Internet 105. It should be appreciated that the term "communication" is used to include all data transmissions that may be exchanged between subscriber 101 and other network terminations. The relevant portion of PSTN 104 is shown as part of an Advanced

Intelligent Network (AIN) of a typical local exchange carrier. For brevity, only a basic explanation of the AIN-based PSTN is provided herein. Where PSTN 104 operates or is composed differently in an important aspect from that which would be understood by those skilled in the art, additional details are provided. For further information regarding PSTNs in general and their AIN aspects, the interested reader is referred to U.S. Patent No. 5,430,719, the Weisser, entitled "Mediation of Open Advanced Intelligent Network Interface by Shared Execution Environment," and is incorporated herein by reference.

As shown in Figure 1, PSTN 104 includes at least two different types of switching points: a Service Switching Point (SSP) 106 and a Service Control Point (SCP) 112. SSP 106 is a central switch that serves a designated group of subscriber lines 107 and thus acts as the hub of operations for PSTN 104. Although a PSTN may have a plurality of SSPs each connected to each other with trunk circuits and each serving vast regions of the PSTN, for the purpose of simplicity Figure 1 illustrates just one SSP. SSP 106 is coupled to a subscriber 101 via subscriber line 107. A subscriber line may also be referred to as a "calling line." SSP 106 is further coupled to Internet server 110 and to telephone 111 via subscriber lines 109 and 108, respectively.

Each calling line 107-109 typically is connected to terminating equipment. Terminating equipment may include a telephone 103 and 111, a personal computer 102, or a computer server 110. Although not shown, those skilled in the art will appreciate that such terminating equipment may include other communication devices, including facsimile machines and modems, for example. As shown in Figure 1, subscriber 101 may access data network 100 via subscriber line 107, using either computer 102 or telephone 103. Although a single calling line 107 is shown connecting subscriber 101 to data network 100, it should be appreciated that subscriber 101 may have a plurality of calling lines connected to PSTN 104. Each calling line 107-109 is assigned a ten-digit "directory number" (DN). Therefore, the term "directory number" is used to describe the number that is dialed or input by a caller or source to reach certain terminating equipment. A DN is commonly referred to as a "telephone number" or "calling line number." SSP 106 is further coupled to SCP 112. SCP 112 contains control logic and service-specific feature data, and is a centralized node in PSTN 104. Much of the intelligence behind the enhanced features of the ATN-based PSTN 104 resides in SCP 112, which typically is a computer-based device. SCP 112 also includes one or more subscriber databases 121. Subscriber database 121 may identify particular customers, like subscriber 101 and caller 113, and their subscribed services. Typically, SCP 112 is a repository of many service package applications (SPAs) 120, each associated with a particular service or enhanced feature available to customers (e.g., "800" SPA). In particular, SPA 120 is a program that queries database 121 and provides instructions to SSP 106 for how to handle the incoming call based on database 121 look-up. Therefore, for example, when subscriber 101 enters certain service-specific digits (e.g., *69 - "Call Return"), SPA 120 will conduct a look-up in database 120 to ensure that subscriber 101 has access to the requested service. If the look-up confirms subscriber's 101 access to the requested service, SPA 120 will direct SSP 106 to route the call accordingly.

Communication between SSP 106 and SCP 112 occurs on connection 116, and typically employs a Common Channel Signaling System No. 7 protocol or "SS7", well known to those skilled in the art. SS7 defines the procedures and protocol by which network elements in PSTN 104 exchange information over a digital signaling network to effect wireless and wireline call setup, routing and control. SS7 communication between SSP 106 and SCP 112 typically occurs over 56 or 64 kilobit per second (kbps) bidirectional channels called "signaling links." Signaling occurs "out-of-band" on dedicated channels rather than "in-band" on voice channels.

Within SSP 106 are defined a relatively small set of termination attempt triggers (TAT or trigger). A trigger 122 is an event associated to a particular subscriber line that generates a signal to be sent to SCP 112. For example, if subscriber 101 enters a certain sequence of numbers in addition to a called number, SCP 112 will interpret the significance of the sequence and set a trigger 122 on SSP 106. SCP 112 may then direct SSP 106 to route the call to the called number. When an incoming call from caller 113, for example, is made to subscriber 101, trigger 122 will be activated. Activating trigger 122 causes a signal to be sent to SCP 112. In response to the signal, SPA 120 in SCP 112 queries database 121 for processing instructions. The results of database 121 inquiry by SCP 112 are sent back to SSP 106 in the form of commands that instruct SSP 106 on how to process the call. The instructions may be to take some special action as a result of a customized calling service or enhanced feature available to subscriber 101. In response, SSP 106 routes the call in accordance with the instructions.

In ATN-based PSTN 104, SSP 106 also may be coupled to an intelligent peripheral (IP) 118. The term "intelligent peripheral" is used to refer to an AIN device that terminates an ISDN interface to an AIN Switching System. Functionally, IP 118 provides information to subscriber 101 and/or collects information from subscriber 101 via a circuit-switched bearer connection. IP 118 is dedicated to perform certain intelligent processes, including for example, voice and dual tone multi-frequency (DTMF) signal recognition, voice recognition, and messaging services. In operation, there are two ways for subscriber 101 to access ATN-based PSTN

104: (1) via computer 102 or (2) via telephone 103. First, subscriber 101 may enter the internet service provider's DN using computer 102. The DN is carried through a connection box 115 over subscriber line 107 using a point-to-point protocol (PPP), well known to those in the art. SSP 106 then routes the call to Internet server 110 located with the Internet service provider, allowing subscriber 101 to access Internet 105. Second, subscriber 101 may enter caller's 113 DN using telephone 103. Caller's DN is carried through a connection box 115 over subscriber line 107. SCP 112 then simply instructs SSP 106 to connect subscriber 101 to caller 113 over subscriber line 108.

Figure 2 is a message flow diagram detailing communication between SCP 112, SSP 106, and IP 118. Communication between SSP 106 and IP 118 is conducted over line 117 (as shown in Figure 1), and communication between SSP 106 and IP 118 is conducted over line 116 (as shown in Figure 1). Connection 117 may be a primary rate interface (PRI) Integrated Services Digital Network (ISDN) using Bell Communications Research, Advanced Intelligent Network (AIN) 0.1 Switch - Intelligent Peripheral Interface (TPI) Generic Requirements, GR-1129-CORE ("GR-1129 protocol"), well known to those in the art.

As shown in Figure 2, when IP 118 is needed to interact with subscriber 101, SCP 112 sends a "Send_To_Resource" message 201 to SSP 106 that requests that subscriber 101 be connected to IP 118. "Send_To_Resource" message 201 includes data such as the network address of IP 118, an optional answer supervision indicator for SSP 106, and variable call processing information needed by IP 118 (e.g., resource type, function to be performed, announcement ID). SSP 106 then interprets IP's 118 network address from "Send_To_Resource" message 201 and uses ISDN access Q.931/Q.932 protocol, well known in the art, to set up a connection to TP 118. The variable TP call processing information contained in "Send_To_Resource" message 201 is sent by SSP 106 to TP 118 in an ISDN access "Setup" message 202. TP 118 responds to "Setup" message 202 with a "CONNect" message 203, indicating that it is prepared to handle SSP's 106 requested communication. SSP 106 then acknowledges with a "CONNect ACK" message 204. At this point, SSP 106 has established a connection with TP 118 and is ready to exchange information with SSP 106. When TP 118 completes the requested function, it returns any resultant data to SSP 106 via Q.931/Q.932 signaling protocol in a "DISConnect" message 205. SSP 106 then repackages the resultant data and informs SCP 112 of the completion via a "Resource_Clear" transaction capabilities application protocol (TCAP) signaling message 206. TCAP is one layer of the SS7 protocol. TCAP messages are used to support non circuit-related, connectionless information exchange. For example, TCAP messages may be used to send queries to databases and to return the database response. If, on the other hand, SSP 106 was unable to make a connection to TP 118 (e.g., all of the circuits to TP 118 are busy), SSP 106 will notify SCP 112 of the problem, via "Resource_Clear" message 206.

Using the GR-1129 control capabilities between SSP 106 and TP 118, along with the Q.931/Q.932 protocol for setup and breakdown purposes, allows subscriber 101 to interact with TP 118. In particular, the GR-1129 protocol creates a connection between subscriber 101 and TP 118 via a voice channel in SSP 106. This voice channel allows TP 118 to use its internal resources and functionality to exchange information with subscriber 101. Also, the GR-1129 protocol permits SSP 106 the exchange of data between TP 118 and SCP 112. Q.931 is a well-known protocol, used between SSP 106 and TP 118, that manages fixed bandwidth circuit switched channels in order to establish, maintain, and clear ISDN network connections, like connection 117. More specifically, Q.931 is a specification for network layer of the Digital Subscriber Signaling System No. 7 that handles the user-network interface for control of ISDN calls, using out-of-band signaling on the D-channel to control calls.

H.323-Enabled GR-1129 Architecture

Figure 3 is a block diagram of a communication network 300 for interfacing

PSTN 104 with an H.323 Network 302, according to the invention. The diagram is similar to Figure 1, except that SSP 106 is coupled to H.323 Network 302, instead of TP

118. In addition, a speaker 315 and a microphone 316 are connected to computer 102. As will be discussed, speaker 315 and microphone 316 allow subscriber 102 to communicate with caller 113 using computer 102. Also, two software applications are installed on computer 102: (1) an H.323 client 311 and (2) an ICW VoTP client 312. As will be discussed, these two software applications permit subscriber 101 to communicate with caller 113, as well as to re-direct caller's 113 incoming call over the TP -based network.

H.323 is a specification for defining how voice, video, and data traffic will be transported on the Internet. These standards define how components that are built in accordance with the H.323 specification will set-up communications, exchange compressed audio and video, participate in multi-party conferences, and operate with non H.323 components. Just as SSP 106 communicated with TP 118 (as shown in Figure 1) in accordance GR-1129-CORE protocol, H.323 gateway 303 will communicate with SSP 106 using the same protocol. As will be discussed, such protocol allows SCP 112 to maintain controllability over the communications between PSTN 104 and H.323 network 302.

As shown in Figure 3, H.323 network 302 includes an H.323 gatekeeper 304 coupled to an H.323 gateway 303 via interface 307. H.323 gatekeeper's 304 primary responsibility is to provide call control services for registered H.323 endpoints, like computer 102 for subscriber 101. Interface 307 provides communication between H.323 gatekeeper 304 and H.323 gateway 303 using H.323 protocol techniques, well known to those in the art. H.323 gatekeeper 304 translates alias addresses to transport addresses. This function is particularly important where a phone on the circuit-switched network is attempting to call a PC on an TP network. It is also important when determining the location of H.323 gateway 303 in PSTN 104. H.323 gateway 303 may be a commercially available gateway unit, for example, MAX6000 manufactured by LUCENT TECHNOLOGIES, INC. H.323 gatekeeper 304 may be a commercially available gatekeeper unit, for example, ELEMEDIA manufactured by LUCENT TECHNOLOGIES, INC., and modified to communicate with SCP 112, as described throughout. H.323 gatekeeper 304 is coupled to SCP 112 over connection 305.

Communication between H.323 gatekeeper 304 and SCP 112 over connection 305 is conducted using transaction control protocol/Internet protocol (TCP/IP) techniques, well known in the art. SCP 112 includes an ICW SPA 308 and a database 309. Similar to SPA 120 and database 121, discussed with reference to Figure 1, SCP 112 conducts a look-up in database 309 using ICW SPA 308 to confirm that subscriber 101 has subscribed to certain services, hi this case, however, the services determined by database 309 and ICW SPA 308 relate to ICW VoIP services.

H.323 gateway 303 is coupled to SSP 106 over a connection 301. Similar to connection 117, as discussed with reference to Figure 1, connection 301 may be an ISDN PRI connection using Q.931 signaling protocol and GR-1129 protocol, well known to those in the art. Alternatively, connection 301 also may be an ISDN Basic-Rate Interface (BRI), well known to those in the art. Connection 301 carries signaling messages and serves circuit-switched connections, including call-associated signaling related to SSP's 106 processing of "Send_To_Resource" message 201 (discussed with reference to Figure 2), call originations, and call terminations. A connection that is made from SSP 106 to H.323 network 302 in response to a "Send_To_Resource" message is referred to as a "Send_To_Resource-connection" and is abbreviated as "STR- connection."

SSP 106 includes an ICW trigger 310. As will be discussed, ICW trigger 310 is similar to trigger 122, discussed with reference to Figure 1, except that ICW trigger 310 is set in response to an ICW subscriber feature. H.323 gateway 303 and H.323 gatekeeper 304 are coupled to a router 320, and router 320 is coupled to Internet 105 via connection 306. Connection 306 is a TCP/IP connection with a bandwidth capable of transporting H.323 communication between H.323 gateway 303 and Internet 105. Router 320 may be a commercially available router, for example, CISCO 7500 series router available from CISCO SYSTEMS INC. As with most routers familiar to those in the art, router 320 allows Internet server 110 and/or Web site 114 to communicate and transfer data between H.323 gateway 303 and H.323 gatekeeper 304, located in H.323 Network 302. Router 320 may provide physical address determination, and use data headers and a forwarding table to determine the destination of data packets from Internet In general, the invention allows subscriber 101, connected to PSTN 104 using computer 102 over a PPP connection 107, and caller 113, connected to PSTN 104 over a plain old telephone service (POTS) connection 108, to communicate with each other such that SCP 112 maintains control over the communication path. In this way, SCP 112 may not only permit subscriber 101 to answer caller's 113 call using VoTP, but SCP 112 also may perform various operations on the call, including allowing subscriber 101 to redirect the call, for example. There are two main processes for establishing such a connection between subscriber 101 and caller 113: (1) VoTP registration by subscriber 101; and (2) voice path setup between subscriber 101 and caller 113. In the VoTP registration process, subscriber 101 informs both PSTN 104 components and H.323 network 302 elements of its VoTP capability. Voice path setup involves the process of establishing a communication path between VoTP-registered 2subscriber 101 and another party attempting to contact subscriber 101 (e.g., caller 113).

Subscriber VoIP Registration

In the VoTP registration process, subscriber 101 must notify PSTN 104 components and H.323 network 302 elements that it is ICW and VoJJP-capable. Figure 4 is a flow diagram detailing how subscriber 101 accesses Internet server 110 and sets ICW trigger 310 on SSP 106. As shown in Figure 4, in step 401, subscriber 101 uses computer 102 to make a PPP connection, familiar to those in the art, with the Internet service provider's Internet server 110. This communication traverses line 107, passes through SSP 106, and over line 109 to Internet server 110 (as shown in Figure 3). Computer 102 includes software capable of making the PPP connection with Internet server 110, for example DIAL-UP NETWORKING, available from MICROSOFT Corporation. Along with entering Internet server's 110 DN, subscriber 101 may use computer 102 to enter certain additional, service-specific digits. As discussed with reference to Figure 1, these service-specific digits may be any sequence of numbers, and are assigned by the telephone service provider to notify PSTN 104 elements (i.e., SSP 106 and SCP 112) of the services available to customers, like subscriber 101. For example, a certain sequence of digits, like *29, may alert PSTN 104 elements that subscriber 101 has purchased "Internet Call Waiting" features. In step 402, SSP 106 receives from subscriber 101 the calling number (i.e., subscriber's 101 DN), the called number (i.e., Internet server 110 DN), subscriber's 101 TP address and any additional service-specific digits entered by subscriber 101. SSP 106 passes the data onto SCP 112. If subscriber 101 previously has ordered the "Internet Call Waiting" with the local telephone service provider, in step 405, SCP 112 runs ICW SPA 308 and creates a subscriber entry in database 309. In step 407, SCP 112 sets a trigger 310 in SSP 106. Setting trigger 310 in SSP 106 allows subscriber 101 access to "Internet Call Waiting" services while browsing Internet 105.

In step 408, after setting trigger 310, SCP 112 instructs SSP 106 to route subscriber 101 to the entered DN, in this case, the Internet server's 110 access number. Subscriber 101 may now access Internet 105 via Internet server 110 in step 409. Access with Internet 105 may be achieved with a browser-based software product, for example, INTERNET EXPLORER by MICROSOFT Corporation. Because trigger 310 was set in SSP 106 when subscriber 101 accessed Internet server 110, any incoming call to subscriber 101 will encounter trigger 310.

As subscriber 101 browses Internet 105, computer 102 must inform PSTN 104 components and H.323 network 302 elements that it is VoIP-capable. Figure 5 is a flow diagram detailing how subscriber 101 uses computer 102 to inform PSTN 104 components and H.323 Network 302 elements that it is VoIP-capable. In step 501, ICW VoTP client 312 on computer 102 software sends a "Registration" signal to SCP 112 via SSP 106 and Internet 105. The "Registration" signal may include existing parameters, like subscriber's DN, subscriber's TP address, and/or the version of H.323 client software that the subscriber is operating. ICW VoTP client 312 may be a commercially available computer software, for example BellSouth' s "Internet Call Waiting," modified to permit VoTP communication, as described herein. In step 502, SCP 112 sends a "Registration Acknowledge" signal back to ICW VoTP client 312 on computer 102. The "Registration Acknowledge" signal from SCP 112 includes the previous information from the registration, including H.323 gatekeeper's 204 TP address, and subscriber's 101 user identification and password. In step 503, ICW VoTP client 312 is now registered with SCP 112. In step 504, H.323 gatekeeper's 304 TP address subsequently is passed from ICW SPA 308 to ICW VoTP client 312 an on to H.323 client 311 on computer 102. H.323 client 311 may be any of a number of commercially available products including, for example, NETMEETING by MICROSOFT Corporation. In this case, NETMEETTNG may be modified to allow subscriber 101 to communicate with H.323 gatekeeper 304 and direct caller's 113 incoming call as desired. Identifying H.323 gatekeeper's 204 TP address to H.323 client 311 in step 504 allows computer 102 to register with H. 323 gatekeeper 204 via SSP 106 and Internet server 110. The registration process takes place using the H.323 Registration, Admission, and Status (RAS) messaging protocol, well known to those in the art. In particular, in step 507, H.323 client 311 sends a "Registration Request" (RRQ) signal to H.323 gatekeeper 304. In step 508, H.323 gatekeeper 304 responds by sending a "Registration Confirm" (RCF) message back to H.323 client 311. At this point, subscriber 101 is registered with H.323 gatekeeper 304 using H.323 client 311, in step 509. Therefore, components in both PSTN 104 and H.323 network 302 now are alerted to subscriber's 101 ability to receive voice calls over TP, and in particular to direct those calls in various ways using "Call Waiting" techniques.

Voice Path Setup Between Subscriber and Caller

Voice path setup involves the process of establishing a communication path between VoTP -registered subscriber 101 and another party attempting to contact subscriber 101 (e.g., caller 113). Figures 6A and 6B provide a flow diagram illustrating the setup of communication path 301 between PSTN 104 and H.323 network 302. As shown in Figure 6A, as subscriber 101 browses Internet 105, caller 113 uses telephone 111 to dial subscriber's 101 DN in step 601. In step 602, caller's 113 call enters SSP 106 via subscriber line 108 and encounters trigger 310 set earlier by SCP 112 on SSP 106 in response to subscriber's 101 previous call to internet server 110. In step 603, in response to trigger 310, SSP 106 queries SCP 112 for further instruction. In step 604, SCP 112 sends a "Call Notification" signal via TCP/IP connection 107 and Internet server 110 to ICW VoTP client 312 on subscriber's 101 computer 102. "Call Notification" signal may include the caller's subscribed name and DN. hi step 604, in response to the "Call Notification" signal, ICW VoTP client 312 notifies subscriber 101 that caller 113 is calling by providing, for example, a pop-up screen on computer 102. Figure 12 provides an example of a "Caller ID" pop-up screen 1201 that may appear on computer 102. As shown in Figure 12, "Caller TD" pop-up screen 1201 may provide information regarding the incoming call, for example, caller's name 1207 and caller's telephone number 1208. Using "Caller TD" pop-up screen 1201, ICW VoTP client 212 also may provide subscriber 101 with a list of options for handling caller's 113 incoming call. These options may be divided into two main categories: (1) answer caller 113 using non- VoTP; and (2) answer caller 113 using VoTP. Specifically, "Caller TD" pop-up screen 1201 may provide the following selections buttons: "Answer" 1202, "Forward" 1203, "Hold" 1204, "Ignore" 1205, and "VoTP " 1206. "Answer" selection button 1202 may allow subscriber 101 to communicate with caller 113 using telephone 103. In this case, subscriber 101 terminates PPP connection 107 and redirects caller 113 to a traditional POTS connection, so as to communicate using subscriber's 101 telephone 103. "Forward" selection button 1203 may allow subscriber to redirect caller 113 to another party (not shown in Figure 3). In this case, caller 113 either may be routed to a third party's telephone or a third party's TP connection. Subscriber 101 may specify the precise destination of the forwarded call by entering an identifier value in alphanumeric text-entry box 1206. The value in alphanumeric text-entry box 1206 may be a telephone number for the third party, or an TP address of the third party. In this way, subscriber 101 is able to direct caller 113 either to the third party's telephone for voice communication or to the third party's computer for VoTP communication. "Hold" selection button 1204 may allow subscriber 101 to place caller 113 in a temporary waiting status. "Ignore" selection button 1205 may allow subscriber 101 to simply disregard caller's 113 attempt to contact subscriber 101. hi this instance, caller 113 may hear a "busy" signal, be directed to a "unavailable" pre-recorded voicemail program resident either on computer 102 or in PSTN 104, or hear the phone continually ring without being answered. Finally, "VoTP" selection button 1206 may allow subscriber 101 to receive caller's 113 incoming call using VoTP techniques over computer 102. Unlike "Forward" selection button 1203 where subscriber 101 may be permitted to enter an TP address of a third party, "VoTP" selection button 1206 automatically may direct subscriber 101 to communicate with caller 113 using H.323 client 311 on computer 102. Subscriber 101 may now communicate with caller 113 using VoTP techniques (i.e., using microphone 316 and speaker 315 on computer 102 to communicate with caller 113 over the TP connection).

A different signal will be sent from ICW VoTP client 312 to SCP 112, depending on the selected option. It should be appreciated that the described alternatives are not exhaustive. It should also be appreciated that each alternative may be initiated before subscriber 101 communicates with caller 113, as described, or at any time during subscriber's 101 communication with caller 113.

Referring back to Figure 6 A, in step 606, subscriber 101 may decide to answer caller 113 using VoTP techniques, over TP connection 107. In this case, subscriber 101 selects "VoTP" selection button 1206, and H.323 client 311 sends a signal back to SCP 112. In step 607, SCP 112 then sends a "Call Request" signal to H.323 gatekeeper 304 over TCP/IP connection 305. The "Call Request" signal may include data indicating the caller's number, the called number, and whether or not the GR-1129 protocol is being used. Referring now to Figure 6B, in step 608, H.323 gatekeeper 304 determines whether H.323 gateway 303 has sufficient bandwidth to handle the call, and whether subscriber 101 's DN has been registered with H.323 gatekeeper 304. If H.323 gatekeeper 304 does not have sufficient bandwidth to complete the communication or if subscriber 101's DN has not been registered with H.323 gatekeeper 304, in step 609 a rejection response is sent back to SCP 112 from H.323 gatekeeper 304. hi step 613, SCP 112 instructs SSP 106 to route caller's 113 call to subscriber's 101 telephone 103 (i.e., the telephone number originally dialed by caller 113). In particular, H.323 gatekeeper 304 responds to SCP 112 with a "Call Request Acknowledge" (CRA) signal. CRA signal may include the calling number (i.e., caller's 113 DN), called number (i.e., subscriber's 101 DN), and a "Status" value. If H.323 gatekeeper 304 does not have sufficient bandwidth to complete the communication or if subscriber 101 's DN has not been registered with H.323 gatekeeper 304, "Status" field in the CRA signal will have a non-zero value.

The precise non-zero value will depend on the nature of the insufficient information or error in H.323 gatekeeper 304. For example, if the result is insufficient information relating to subscriber's 101 failure to previously register with H.323 gateway 303, SCP 112 will send a "Connection Failed" message to subscriber's 101 computer 102. In this case, ICW VoTP client 312 may provide indication to subscriber 101 that the VoTP connection failed. ICW VoTP client 312 may also prompt subscriber 101 to direct caller's 113 call in a different manner. For example, as previously described with reference to Figure 12, subscriber 101 may be prompted to disconnect TP connection 107 and take caller's 113 call over a POTS connection using telephone 103, to forward the failed VoTP call to a third party (not shown), or to route caller 113 to a voicemail application. ICW VoTP client 312 then sends a signal back to SCP 112 through SSP 106, corresponding to subscriber's 101 selection. SCP 112 will then command SSP 106 to direct the call accordingly.

If, on the other hand, H.323 gatekeeper 304 has sufficient information (e.g., subscriber 101 has previously registered with H.323 gatekeeper 304) and if H.323 gateway 303 has sufficient bandwidth to complete the transaction, the "Status" signal will have a zero value. SSP 106 will then route the call to H.323 gateway 303 on PRI connection 301 using Q.931 signaling protocol and GR-1129 protocol methods between SSP 106 and H.323 gateway 303. Q.931 is the recommended protocol for call signaling messages on the ISDN PRI D channel between an SSP 106 and H.323 gateway 303, and is well known in the art. The GR-1129 protocol allows a connection between caller 113 and H.323 gateway 303 via a voice channel in SSP 106. The GR-1129 protocol is used in order for SCP 112 to hold the control for each ongoing call. It also allows H.323 gateway 303 to use its internal resources and functionality to exchange information with subscriber 101.

As a result of the zero value for "Status" signal, in step 610, SCP 112 sends a message to SSP 106 that requests that subscriber 101 be connected to H.323 network 302. In particular, SCP 112 sends a "Send_To_Resource-connection" (STR-connection) TCAP message to SSP 106 to request the use of resources within H.323 network 302. The "Send_To_Resource message" includes data such as the network address of H.323 gateway 303, an optional answer supervision indicator for SSP 106, and variable H.323 gateway 303 call processing information (e.g., resource type, function to be performed, announcement TD). In this case, the TCAP message is being used to transport the STR- connection message between SCP 112 and SSP 106, and must be kept open for the duration of the communication between subscriber 101 and caller 113. While a connection between SSP 106 and H.323 gateway 303 is active, additional interactions may be required between H.323 gatekeeper 304 and SCP 112. Such interactions may occur, for example, when H.323 gatekeeper 304 determines that it needs to send data to SCP 112 or needs to request data from SCP 112. As a result of this communication, SCP 112 instructs SSP 106 to connect caller to H.323 gateway 303 using GR-1129 protocol. In step 611, SSP 106 connects caller to H.323 gateway 303 using GR-1129 protocol. hi step 612, aware that H.323 gateway 303 is needed to interact with subscriber 101, after receiving the STR-connection message from SCP 112, SSP 106 sends a "Setup" message to H.323 gateway 303. "Setup" message is similar to "Setup" message 202 sent by SSP 106 to TP 118, as described with reference to Figure 2. SSP 106 then uses certain messages on a D channel on ISDN PRI interface 301 to set up a bearer channel between SSP 106 and H.323 gateway 303, and to carry AIN service-related information from SSP 106 and H.323 gateway 303. The subsequent communication between SSP 106 and H.323 gateway 303 is similar to that between SSP 106 and TP 118, as discussed with reference to Figure 2.

After receiving the call from SSP 106, H.323 gateway 303 queries H.323 gatekeeper 304 on how to handle the routed call. Figures 7A and 7B provide a flow diagram of the "Call Setup Messaging" that occurs between H.323 gatekeeper 304, H.323 gateway 303, and H.323 client 311. As shown in Figure 7A, in step 701, H.323 gateway 303 sends an "Admission Request" (ARQ) signal to H.323 gatekeeper 304. In step 702, H.323 gatekeeper 304 responds to H.323 gateway 303 with an "Admission Confirm" (ACF) signal. ARQ and ACF signals make a threshold determination as to whether H.323 gateway 303 will be permitted by H.323 gatekeeper 304 to transport an H.323 communication between subscriber 101 and caller 113. In step 703, H.323 gatekeeper 304 conducts a "CalledPartyTD" to TP address mapping, and then instructs H.323 gateway 303 to initiate the VoTP connection to subscriber's 101 TP address. This identifies to H.323 gateway 303, H.323 client 311 on subscriber's 101 computer 102. H.323 gateway 303 uses this information to send a "Setup" message to H.323 client 311 on subscriber's 101 computer 102 via H.323 gatekeeper 304, in step 704. In step 705, H.323 client 311 responds to H.323 gateway 303 with a "Call Proceeding" signal, sent via H.323 gatekeeper 304. In step 706, H.323 client 311 also sends an ARQ signal back to H.323 gatekeeper 304. h step 707, H.323 gatekeeper 304 responds to H.323 client 311 with an ACF signal. In step 708, an "Alerting" signal is sent from H.323 client 311 to H.323 gateway 303 via H.323 gatekeeper 304. As shown in Figure 7B, in step 709, the "Alerting" signal is followed by a

"Connect" signal from H.323 client 311 to H.323 gateway 303 via H.323 gatekeeper 304. Once the "Connect" signal is accepted by H.323 gatekeeper 304, H.323 gateway 303 is permitted to route caller's 113 call in step 710. In step 711, H.323 gatekeeper 304 sends a "Call Completed" (CCD) signal to SCP 112. The CCD signal includes the caller DN (i.e., caller's 113 DN) and the called DN (i.e., subscriber's 101 DN). step 712, a bi-directional Real-Time Control Protocol (RTCP) is established between H.323 client 311 and H.323 gateway 303. RTCP provides feedback on the transmission and reception quality of data carried between H.323 client 311 and H.323 gateway 303. For example, RTCP may provide sender reports, receiver reports, and source description. At this point, a Real-Time Protocol (RTP) stream is established from H.323 client 311 to H.323 gateway 303, in step 713. In step 714, the RTP stream is established from H.323 gateway 303 to H.323 client 311. The RTP stream, often used for data with real-time characteristics like H.323 multimedia audio and video, provides various delivery services between H.323 client 311 and H.323 gateway 303. These services include payload identification, sequence numbering, time-stamping, and delivery monitoring for example. Finally, in step 715, subscriber 101 is able to communicate with caller 113. In particular, ICW VoTP client 312 seizes computer's 102 speaker 315 and microphone 316, via a sound card (not shown) internal to computer 102. Subscriber 101 will hear caller's 113 voice over speaker 315, and be able to respond using microphone 316. Therefore, in sum, the connection between subscriber 101 and caller 113 is made over the following route: from caller 113 telephone 111 over subscriber line 108 through SSP 106; over ISDN PRI 301 to H.323 gateway 303; over Internet connection 306 through Internet 105 and onto Internet Server 110; back through SSP 106 over PPP connection 109; over PPP subscriber line 107 to subscriber 101 via computer 102. Call Revert and Call Forward

Once the call between caller 113 and subscriber 101 is connected using VoTP techniques as described above, the GR-1129 protocol allows SCP 112, and thus subscriber 101 certain control over the communication. In general, the GR-1129 protocol allows SCP 112 to "re-take" control of the voice path once it has been established between subscriber 101 and caller 113 (as described above). Two examples of this increased level of available "controllability" include "Call Revert" and "Call Transfer." In the context of "Internet Call Waiting," "Call Revert" allows subscriber 101 to revert the completed VoTP connection with caller 113 to a POTS connection using telephone 103. Subscriber 101 may decide to conduct such a reversion, for example, because caller 113 on the VoTP connection is not understandable. "Call Transfer," on the other hand, allows subscriber 101 to transfer caller 113 to a third party's (not shown) VoTP or POTS connection. Figures 8A and 8B provide a flow diagram detailing the "Call Revert" functionality and Figures 9A and 9B provide a flow diagram detailing the "Call Transfer" functionality. Figure 13 is an example of a "Call Redirect" pop-up screen 1301 and will be discussed throughout the description of Figures 8A, 8B, 9A and 9B.

As shown in Figure 8 A, in step 801, subscriber 101 is communicating with caller 113 using VoIP, as described above. For any number of reasons, in step 802, subscriber 101 decides whether he/she wishes to terminate the VoTP communication. In step 802, subscriber 101 decides whether he/she simply wishes to "hang-up" the VoTP connection and the entire call. As shown in Figure 13, "Call Redirect" pop-up screen 1301 may appear on computer 102 to provide subscriber 101 a "Hangup" selection button 1302 to accomplish this function. If subscriber 101 wishes to do so, the entire communication is tenninated, in step 803. If, on the other hand, subscriber 101 does not wish to "hang-up" the call, in step 804 subscriber 101 decides whether he/she wishes to end the commumcation using VoTP and "revert" the call and communicate with caller 113 using telephone 103. One reason, for example, may be that the quality of the VoTP connection is unsatisfactory, making it difficult for subscriber 101 to communicate with caller 113. If subscriber 101 wishes to continue communicating with caller 113 using VoTP, subscriber 101 simply continues to communicate with caller 113 in step 801. If subscriber 101 wishes to revert caller's 113 call to telephone 103, in step 805, subscriber 101 uses "Call Redirect" pop-up screen 1301 to select a "Revert." selection button 1303. In step 806, in response to subscriber's 101 selection of "Revert" selection button 1303, ICW VoTP client 312 sends a "Call Forward" signal to SCP 112. "Call Forward" signal includes subscriber's 101 DN and the DN to which the call will be reverted, which in the case of "Call Revert" also is subscriber's 101 DN. In step 807, "Call Redirect" pop-up screen 1301 may instruct computer 102 to disconnect its modem connection. As shown in Figure 8B, in step 808, SCP 112 waits for a "TermmationNotification" as a result of the disconnected modem in step 807. Once SCP

112 receives "TermmationNotification", SSP 106 sends a TCAP

"TermmationNotification" signal to SCP 112, in step 809. In step 810, SCP 112 sends a "Call Forward" message to H.323 gatekeeper 304 to alert H.323 gatekeeper 304 of a pending call transfer or revert function. TCP/IP connection 305 remains between SCP 112 and H.323 gatekeeper 304. "Call Forward" message includes subscriber's 101 DN, caller's 113 DN, and a non-zero value for a "Revert Field" signal. The value of the "Revert Field" signal will vary depending on whether subscriber 101 wishes to revert caller 113 to telephone 103 or forward caller 113 to a third party (not shown). In step 811, SCP 112 sends to SSP 106 a TCAP "Cancel_Resource." hi step 812, SSP 106 disconnects PRI connection 301 between SSP 106 and H.323 gateway 303 and sends a "Resource_Cleared" message to SCP 112. In step 813, SCP 112 instructs SSP 106 to forward the call to the DN of subscriber 101, and in step 814, SSP 103 forwards the call to the specified DN.

Figures 9A and 9B illustrate a flow diagram detailing the "Call Transfer" functionality. As shown in Figure 9A, in step 901, subscriber 101 is communicating with caller 113 using VoTP, as described above. In step 902, subscriber 101 decides whether he/she wishes to end the communication using VoTP and "forward" the caller's

113 to a third party. If subscriber 101 wishes to continue communicating with caller 113 using VoTP, subscriber 101 simply continues to communicate with caller 113 in step 901. If subscriber 101 wishes to forward caller's 113 call to a third party, in step 903, subscriber 101 uses ICW VoTP client 212 to select the "Call Transfer" functionality. This may be accomplished, for example, by using a "Transfer" selection button 1304 on "Call Redirect" pop-up screen 1301, as shown in Figure 13. In response to subscriber's 101 selection of "Transfer" selection button 1304 on "Call Redirect" pop-up screen 1301, ICW VoTP client 312 queries subscriber 101 to enter a transfer destination identifier, in step 904. This identifier may be either an TP address or a DN for a third party. In step 905, ICW VoTP client 312 sends a "Call Forward" signal to SCP 112. "Call Forward" signal includes subscriber's 101 DN and a transfer DN. In this instance, the transfer DN is the entry made by subscriber 101 when queried by ICW VoTP client 312. In step 906, SCP 112 sends to H.323 gatekeeper 304 subscriber's 101 DN, caller's 113 number, and coπesponding "forward" value for the "Revert field" signal, h step 907, SCP 112 sends to SSP 106 a TCAP "Cancel_Resource" releasing PRI connection 301. Releasing PRI connection 301, although not required, is preferred in order to free resources on H.323 gateway 303. However, the path between subscriber 101 and Internet 105 remains. As shown in Figure 9B, in step 908, SSP 106 cancels connection 301 between

SSP 106 and H.323 gateway 303, and SSP 106 sends a "Resource_Cleared" message to SCP 112. In step 909, SCP 112 instructs SSP 106 to forward the call to the DN of subscriber 101, and in step 910, SSP 106 forwards call to the specified DN.

Although Figures 8 A, 8B, 9 A and 9B describe reverting and forwarding caller's 113 communication by deciding how to do so after the call has been received, it should be appreciated that these decisions maybe predetermined, before subscriber 101 receives caller's 113 communication. For example, before receiving caller's 113 communication, subscriber 101 may preset a certain designator relating either to subscriber's 101 telephone 103, or a third party's (not shown) telephone number or TP address. In this way, subscriber 101 may redirect all incoming communications to a voice-based PSTN connection using telephone 103. Alternatively, subscriber 101 may establish a preset designator, depending on caller's 113 identity. For example, subscriber 101 may preset all communications received from a certain family member to a voice-based PSTN connection, while presetting all other communications to be forwarded to his/her' s administrative assistant's voice-based or IP-based communication channel. Terminating the VoTP Connection

Communication between subscriber 101 and caller 113 may be tenninated by either party. The process for terminating communication varies, depending on who terminates the call and at what point in the communication the call is terminated. Figure 10 is a flow diagram illustrating what occurs when caller 113 terminates the call between subscriber 101 and caller 113. In step 1001, caller 113 wishes to terminate the communication. In step 1002, it is determined whether SCP 112 has sent CRQ signal to H.323 gatekeeper 304 yet. If not, the call is simply terminated in step

1003. If, on the other hand, caller 113 wishes to terminate the call by hanging-up telephone 111 after SCP 112 sends the CRQ signal to H.323 gatekeeper 304, in step

1004, it is determined whether the connection to subscriber 101 has been established. If the connection is not yet established, in step 1005, SSP 106 sends a TCAP "Resource_Cleared" message to SCP 112. "Resource_Cleared" message is used by SSP 106 to notify SCP 112 that it has performed the termination. In step 1006, SCP 112 sends a "Disconnect" message to H.323 client 311 and ICW VoTP client 312, thus terminating the call, in step 1007. If in step 1004, it is determined that caller 113 terminated the call after the voice path is setup with subscriber 101, in step 1008, SSP 106 sends a "Resource_Cleared" message to SCP 112. In step 1009, SCP 112 then waits for a hangup message from H.323 gatekeeper 304. In step 1010, SCP 112 then sends a TCAP "Cancel_Resource" message to SSP 106, terminating PRI connection 301 with H.323 gateway 303. The call is then terminated in step 1007.

On the other hand, subscriber 101 may wish to terminate the communication. Figures 11A and 1 IB provide a flow diagram illustrating what Occurs when subscriber 101 terminates the call between subscriber 101 and caller 113. As shown in Figure 11A, in step 1101, subscriber 101 wishes to terminate the call with caller 113. As with caller's 113 termination, in step 1102, it is determined whether SCP 112 has sent CRQ signal to H.323 gatekeeper 304 yet. If, subscriber 101 wishes to terminate the call after SCP 112 sends the CRQ signal to H.323 gatekeeper 304, in step 1105, it is determined whether the connection to subscriber 101 has been established. If the connection is not yet established, in step 1106, SSP 106 sends a TCAP "TerminationNotification" message to SCP 112. In step 1107, SCP 112 sends a "Call Terminated" (CTD) message to H.323 gatekeeper 304, terminating TCP/IP connection 305. In step 1108, SCP 112 sends a TCAP "Cancel_Resource" message to SSP 106. If, on the other hand, subscriber 101 wishes to terminate the call before CRQ signal has been sent, teπnination will be the same except that the CTD message will not be sent to H.323 gatekeeper 304. hi particular, in step 1103, SSP 106 sends a TCAP "TerminationNotification" message to SCP 112. In step 1104, SCP 112 sends a TCAP "Cancel_Resource" message to SSP 106.

If, in step 1105, subscriber 101 wishes to terminate the established VoTP connection, subscriber selects a disconnect option on ICW VoTP client 312, in step 1109. In step 1110, a "Hangup" signal is sent from ICW VoTP client 312 to H.323 client 311. In step llll, H.323 gateway 303 and H.323 client 311 both send a "Disconnect Request" (DRQ) signal to H.323 gatekeeper 304.

As shown in Figure 1 IB, in step 1112, H.323 gatekeeper 304 sends a "Hangup" signal to SCP 112. "Hangup" signal includes caller DN (i.e., caller 113 DN) and called DN (i.e., subscriber 101 DN). In response to "Hangup" signal, in step 1113, SCP 112 then sends a TCAP "Cancel_Resource" signal to SSP 106 to release caller's 113 subscriber line 108. In step 1114, H.323 gatekeeper 304 sends a "Disconnect Confirm" (DCF) signal both to H.323 gateway 303 and to H.323 client 311. In step 1117, subscriber 101 determines whether he/she wishes to exit H.323 client 311 on computer 102. If the user does not wish to exit H.323 client 311, H.323 client 311 simply remains active on computer 102, in step 1118. If, on the other hand, subscriber 101 wishes to exit H.323 client 311, in step 1115, H.323 client 311 sends an "Unregister Request" (URQ) signal to H.323 gatekeeper 304. In step 1116, H.323 gatekeeper 304 responds with a "Unregister Confirm" (UCF) signal back to H.323 client 311. Notably, if ICW VoTP client 312 is exited on computer 102, then H.323 client

311 un-registers with H.323 gatekeeper 304. Otherwise, if ICW VoTP client 312 stays opened, H.323 client 311 remains registered with H.323 gatekeeper 304 even after caller 113 terminates the call. This allows subscriber 101 to continue to browse Internet 105 without needing to re-register with H. 323 gatekeeper 304. Accordingly, subscriber 101 is prepared should another party (not shown) attempt to contact subscriber 101 in the same manner as caller 113 while subscriber 101 browses Internet 105. The invention is directed to a communications system and method for transporting data, but is not limited to, the transport of voice data, regardless of any specific description in the drawing or examples set forth herein. It will be understood that the invention is not limited to use of any of the particular components or devices herein. Indeed, this invention can be used in any application that requires the transmission of data. Further, the system disclosed in the invention can be used with the method of the invention or a variety of other applications. For example, although the invention was described in the context of H.323 protocol methods, it should be appreciated that the invention may be used with other multimedia protocols including Session Invitation Protocol, Session Description Protocol, and Simple Conference Control Protocol.

While the invention has been particularly shown and described with reference to the presently prefeπed embodiments thereof, it will be understood by those skilled in the art that the invention is not limited to the embodiments specifically disclosed herein. Those skilled in the art will appreciate that various changes and adaptations of the invention may be made in the form and details of these embodiments without departing from the true spirit and scope of the invention as defined by the following claims.

Claims

What is Claimed is:

1. A communications system, comprising: a Service Switching Point; and a gateway device communicating with said Service Switching Point, wherein communication between said gateway device and said Service Switching Point is conducted using GR-1129 protocol, and wherein said gateway device provides an interface between disparate networks.

2. The system of claim 1, further comprising a gatekeeper device communicating with a Service Control Point and said gateway device, wherein said gatekeeper device administrates communication with said gateway.

3. The system of claim 2, wherein packet-switched data is communicated between said gatekeeper and said Service Control Point.

4. The system of claim 2, wherein said gateway device and said gatekeeper device are capable of transporting data in accordance with a voice-based multimedia protocol.

5. The system of claim 2, wherein said Service Control Point includes a service package application capable of processing instructions received from said gatekeeper.

6. The system of claim 1, further comprising a first communication device communicating with said Service Switching Point.

7. The system of claim 6, wherein circuit-switched data is communicated between said Service Switching Point and said first commumcation device.

8. The system of claim 6, wherein voice-based data is communicated between said first communication device and said Service Switching Point.

9. The system of claim 6, wherein said first communication device is a telephone.

10. The system of claim 1, further comprising a second communication device communicating with said Service Switching Point.

11. The system of claim 10, wherein said second communication device is capable of transmitting data in accordance with a voice-based multimedia protocol.

12. The system of claim 10, wherein said second communication device is capable of transmitting voice data to said Service Switching Point using an Internet Protocol.

13. The system of claim 10, wherein said second communication device is a computer.

14. The system of claim 13, wherein said computer includes a microphone and a speaker.

15. The system of claim 1, wherein said disparate networks include a packet-switched network and a circuit-switched network.

16. A method for communicating between a packet-switched data network and another network, comprising: receiving packet-switched data from a first network appliance; receiving a communication request from another network appliance; and providing a communication path using GR-1129 protocol over a packet- switched network in response to said communication request, wherein said communication path allows communication between said first network appliance and said second network appliance.

17. The method of claim 16, further comprising transporting voice-based data over said communication path in accordance with a multimedia specification.

18. The method of claim 16, further comprising verifying registration of said first network appliance with said packet-switched network.

19. The method of claim 16, further comprising verifying that said first network appliance has access to said communication path.

20. The method of claim 16, further comprising providing a packet-switched network connection to said first network appliance.

21. A communication service platform, comprising: a Service Switching Point; a gateway device communicating with said Service Switching Point, wherein communication between said gateway device and said Service Switching Point is conducted using GR-1129 protocol, and wherein said gateway device is capable of transporting data in accordance with a voice-based multimedia protocol; a gatekeeper device communicating with said gateway device, wherein said gatekeeper device regulates communication with said gateway, and wherein said gatekeeper device is capable of transporting data in accordance with said voice-based multimedia protocol; and a Service Control Point communicating with said gatekeeper and said service switching point, wherein packet-switched data is communicated between said gatekeeper and said Service Control Point, and wherein said Service Control Point includes a service package application capable of processing instructions received from said gatekeeper.

22. The system of claim 21, further comprising a first communication device communicating with said Service Switching Point, wherein said first communication device is capable of transmitting voice data.

23. The system of claim 21, further comprising a second communication device communicating with said Service Switching Point, wherein said second commumcation device is a personal computer with a microphone and a speaker capable of transmitting voice data to said Service Switching Point using an Internet Protocol, in accordance with said voice-based multimedia protocol.