MXPA01001372A - A method for allocating network resources - Google Patents

Abstract

Network resources for a call between a calling party and a called party are allocated. The network resources for the call are reserved based on a reservation request. The network resources are reserved before any one network resource from the reserved network resources is committed. The reserved network resources for the call arecommitted when a called party indicates acceptance for the call.

Description

METHOD, TO ASSIGN NETWORK RESOURCES BACKGROUND OF THE INVENTION The present invention relates in general to the assignment of network resources. More specifically, the present invention relates to reserving and committing the resources of the network based on an authorized quality of service. The H.323 known signaling architecture is a standard defined by the International Telecommunications Union (ITU) that describes how multi-media (multimedia) communications occur between terminals, networked equipment and services over local area networks (LANs) and Wide area networks (WANs) that do not provide a guaranteed quality of service (such as Internet Protocol (IP) networks). Quality of service is a measure of the quality of the communication service during a call, and may include, for example, the bandwidth, delay and latency associated with the call. In networks that use "best effort" distribution models without connection, the quality of service typically does not Ref: 127221 it is guaranteed; H.323 is a signaling architecture for such a network. The H.323 provides a range of deployment options that include signaling routed by the gatekeeper. In the H.323 standard, goalkeepers trace the map of the LAN address aliases to the IP addresses and provide address lookup when needed. Gatekeepers also exercise call control functions to limit the number of H.323 connections and the total bandwidth used by these connections in an H.323"zone". Although the doorman is not necessary within the H.323 standard, when a doorman is present in a network, the terminals of the network must make use of their services. In other words, the gatekeepers maintain the status information for each individual call and all call signaling must pass through the gatekeepers. The implementation of goalkeepers of the H.323 standard, however, suffers from several drawbacks. Firstly, the equipment associated with the goalkeepers needs to be extremely reliable, so that the goalkeeper is available throughout the course of the call. If the equipment related to the gatekeeper fails during a call, the call fails due to that the status information for the call kept only in the doorman is lost. Secondly, the equipment related to the doorman probably can not scale up in a low cost way due to the maintenance of the status information and that the performance of the messaging associated with H.323 is complex and with intense work of the processor. Finally, the theft of the service is possible by diverting the doormen to place unauthorized and unverified calls.

BRIEF DESCRIPTION OF THE INVENTION The resources of the network for a call between a calling party and a called party are assigned. The resources of the network for the call are reserved based on a reservation request. The resources of the network are reserved before any resource of the network of reserved resources of the network is compromised. The reserved resources of the network for the call are committed when a called party indicates the acceptance for the call.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 illustrates a network, according to one embodiment of the present invention. Figure 2 illustrates a flow chart for reserving network resources for a call, according to one embodiment of the present invention. Figure 3 illustrates a flow chart for performing two-phase signaling in the call connection, according to one embodiment of the present invention. Figure 4 illustrates a flow diagram for disconnecting a call, according to an embodiment of the present invention. Figure 5 illustrates a flow chart for moving a network address, according to an embodiment of the present invention. Figure 6 shows the flow of the call for an initial normal call setup or adjustment, according to an embodiment of the present invention. Figure 7 shows an exemplary signaling call flow for reserving resources in the network segment between the chars marginal for a voice call, according to one embodiment of the present invention. Figure 8 shows the flow of the call for a normal call termination, according to an embodiment of the present invention. Figure 9 shows the flow of the call for a call originating from a BTI but ending at the PSTN, according to one embodiment of the present invention. Figure 10 shows the flow of the call for a call originating in the PSTN, but ending in the IP telephony network, according to one embodiment of the present invention. Figure 11 shows the flow of the call for a normal disconnection to the PSTN, according to an embodiment of the present invention. Figure 12 shows the flow of the call for a call disconnected from the PSTN, according to an embodiment of the present invention. Figure 13 shows a call flow where the BTI is connected to an ad server, of termination, according to an embodiment of the present invention.

Figure 14 shows the call flow for Call Trace, according to an embodiment of the present invention. Figure 15 shows the flow of the call to change the established parameters of the call, according to an embodiment of the present invention. Figure 16 shows the flow of the call to activate a Call Forwarding service by use, according to an embodiment of the present invention. Figure 17 shows the flow of the call for Call Forwarding-All Calls when the BTI is available, according to one embodiment of the present invention. Figure 18 shows the flow of the call for the Call-All Calls when the terminating BTI is not available, according to one embodiment of the present invention. Figure 19 shows the call flow for Call-Busy when BTIT is available, according to one embodiment of the present invention. Figure 20 shows the flow of the Call-Busy call flow when BTIT is not available, according to one embodiment of the present invention. Figure 21 shows the call flow for Call Forward-No response when BTIT is available, according to one embodiment of the present invention. Figure 22 shows the call flow for Call Forward-No response when BTI is not available, according to one embodiment of the present invention. Figure 23 shows the call flow for the Call Distribution Flow of Caller ID / Caller Name, according to one embodiment of the present invention. Figure 24 shows a call flow for Call Waiting, according to an embodiment of the present invention. Figure 25 shows the call flow for the simple, alternative Three-Way Call with bridge connection in BTI0, according to one embodiment of the present invention. Figure 26 illustrates the first steps of a three-way call, according to one embodiment of the present invention.

Figure 27 shows the sequence of signaling messages exchanged in the conversion of two separate calls into a three-way call, according to one embodiment of the present invention. Figure 28 shows the flow of the call for the Three Way Call Bridge in the Network Call Flow-Host Hanging, according to one embodiment of the present invention. Figure 29 shows the call flow for the Three Way Call Bridge in the Network Call Flow-Participant Drape, according to one embodiment of the present invention. Figure 30 shows the flow of the Call for Call Transfer With Query Service when the host is disconnected, according to an embodiment of the present invention. Figure 31 shows the flow of the Call for Call Transfer without Query Service, according to an embodiment of the present invention. Figure 32 shows the flow of the call for the Return Call, according to an embodiment of the present invention.

DETAILED DESCRIPTION The embodiments of the present invention relate to a communication system having a combination of different types of networks, such as one or more data networks (based on, for example, packet switching), one or more telephone networks (such as the Simple Old Telephony Network (PSTN)), and / or the network or cable networks. Such a communication system may include intelligent end terminals that allow a service provider to provide various types of services involving different types of networks, and to exploit the capabilities of the end terminals. For example, packet telephony can be implemented in embodiments of the present invention where the voice can be received and transmitted by a telephone or a communication device (such as a personal computer) connected to the data network via a wired network . The embodiments of the present invention relate to the authorization of calls, to call signaling, to the management of network resources and to end-to-end signaling between communication devices (for example, phones, personal computers, etc.). Existing telephone services with a quality of service consistent with current standards can be supported, while a wider range of packet-enabled communications services can also be supported. The embodiments of the present invention allow the pricing and billing of communications services to differ based on the differences in service quality (eg, bandwidth, delay and / or latency) for the various calls. The embodiments of the present invention also allow smart endpoints to participate in supporting the characteristics of the services provided. These intelligent endpoints can be, for example, computers capable of telephoning, and inputs or accesses that interconnect conventional telephones to the data network. By exploiting the intelligence of these endpoints in supporting the characteristics of the services provided, the functionality (for example, the tasks associated with signaling) historically maintained only by the network can be efficiently divided between the entities of the network. communication network and smart endpoints connected to the communication network. In addition, the embodiments of the present invention protect against theft of the service, and minimize the cost and complexity associated with the provision of a reliable service. Contrary to known telephone networks, the embodiments of the present invention do not require high availability network servers that maintain the status of each individual call. Rather, the embodiments of the present invention can maintain state information only in the marginal routers and endpoints that are directly involved in a particular call. The following discussion is separated into sections for clarity. First, a general overview of the system of a communication network, according to one embodiment of the present invention, is discussed in Section 1 entitled "General System Overview". Then, the separate aspects according to the modalities of the present invention are considered: Section 2 entitled "Two Phase Resource Reserve", Section 3 entitled "Two Phase Signaling", Section 4"Coordination of Gateway in a Base by Call", Section 5 entitled "Network Address Translation", Section 6 entitled "Simulation Destination Call Sign". Finally, Section 7 entitled "Description of Protocol" details the protocols for signaling messages and Section 8 entitled "Signaling Architecture Call Flows" describes the call flows for the signaling architecture, which are applicable to the various aspects of the embodiments of the present invention. 1. General Overview of the System Figure 1 illustrates a network according to an embodiment of the present invention. The network 10 includes the communication network 100 which is connected to the gate controller 110 and the gate controller 111, to the devices 120 and 121 of the edge or margin of the network, and the input 130 of the telephone network. The gate controllers 110 and 111 are connected to the storage 140 and 141 of the database, respectively. The edge devices 120 and 121 of the network are connected to access networks 150 and 151, respectively. The networks of access 150 and 151 are connected to the 160 and 161 units of interconnection with the network, respectively. The interconnection units 160 and 161 with the network are connected to the telephone interconnection units (TIUs) 170 and 171, respectively, and to the communication devices 180 and 181, respectively. The TIUs 170 and 171 are connected to telephones 190 and 191, respectively. The input 130 of the telephone network is connected to the telephone network 135, which, in turn, is connected to the telephone 192. The communication network 100 can be a network that supports, for example, the signaling of the Internet Protocol ( IP), transport of IP media, and / or media transport in asynchronous transfer mode (ATM). The access networks 150 and 151 can be networks of wires or fibers capable of carrying voice and / or data transmissions. The telephone network 135 can be, for example, the Old Simple Telephony System (PSTN). The network interconnection units 160 and 161 can be, for example, cable modems (modulators-demodulators) designed for use on a television coaxial cable circuit. The 160 and 161 units of interconnection with the network they allow communication devices 180 and 181, respectively, to connect to access networks 150 and 151, respectively. The network interconnection units 160 and 161 also allow the TIUs 170 and 171, respectively (and in turn the telephones 190 and 191, respectively), to connect to the access networks 150 and 151, respectively. The marginal or network edge devices (NEDs) 120 and 121 are devices located at the edge of the communication network 100 that connects the communication network 100 to the access networks 120 and 121, respectively. The marginal devices or at the edge of the network can be, for example, routers or bridges or similar equipment that can connect the communication network 100 to the access networks 150 and 151. Because the NEDs 120 and 121 can be specifically implemented, for example as routers at the edge of the network, these units are also referred to herein as edge or edge routers (ERs). The edge devices 120 and 121 of the network can implement resource management and admission control mechanisms that allow the communication network 100 to provide security assurances. bounded loss per packet and delay required to ensure an authorized service quality for a call. In other words, devices at the edge of the network (e.g., network edge devices 120 and 121) can obtain authorization from an associated gate controller (e.g., gate controller 110 or 111, respectively) on a call-by-call basis before providing access, for example, to improved service quality through the communication network. In other words, the edge devices of the network can ensure that the improved service quality for a call from a particular party has been authorized, and for which the usage count is being performed. The edge devices of the network can generate accounting records for calls because these devices track the use of the resource within the communication network 100 for calls. Network edge devices may also implement Network Address Translation to support address privacy for called parties and / or calling parties, as described in more detail below.

The TIUs 170 and 171 are inputs or accesses between the telephones and the networks carrying packets, such as the access networks 150 and 151 and the communication network 100. The TIUs 170 and 171 can digitize, compress and package voice signals to from the telephone 190 and 191, respectively, to convert the analog voice to data packets for transport over the communication network 100, and vice versa. The TIUs 170 and 171 may be, for example, a simple stand-alone telephone device incorporating broadband interconnection, a high-speed data cable modem incorporating the interconnection unit (e.g., TIUs and their interconnection units). associated network can be combined in a simple device), or an advanced, advanced digital adjustment box that incorporates broadband interconnection. The TIUs 170 and 171 may for example be broadband interconnects for telephones; accordingly, these units are also referred to herein as broadband telephony interconnections (BTIs). The TIUs contain enough processing and memory to perform signaling and call control functions. More specifically, the TIUs 170 and 171 each include a processor and are capable of detecting changes in status information (e.g., detection of hung or off-hook status), picking of dialed digits (e.g., dual-tone multi-frequency signals (DTMF)), and participating in the implementation of telephone features for phones 190 and 191, respectively. TIUs 170 and 171 can also participate in end-to-end capacity negotiation as described below. Note that the term "end-to-end" refers to the association between two endpoints for a call. For example, where a call involves a calling party and a called party using telephones, the end-to-end association for the call may be between two telephone interconnection units. Thus, end-to-end messages, for example, could include messages that originate in a telephone interconnection unit and terminate in the other telephone interconnection unit where the messages are opaque to the other entities in the network that merely send the messages. messages (possibly after performing the translation and direction of the network as described later). For example, end-to-end messages can be routed between the telephone interconnection units with messages that are sent by the edge devices of the network and without the message being routed through the gate controllers. Alternatively, for example, when a call involves a calling party using a telephone, and a called party using a communication device (such as a personal computer), the end-to-end association for the call may be between the unit of telephone interconnection of the calling party and the interconnection unit of the called party network. The TIUs can maintain the information for the calls while they are in progress, with which certain service characteristics are implemented locally. For example, call waiting can be implemented locally, by detecting the impulse to hang up and controlling the active call. Similarly, the callback can be implemented locally by retaining the status information in the TIUs with respect to the most recent calls.

Note that TIUs 170 and 171 are considered as "distrustful" devices in the sense that the TIUs can operate the locally stored software (software) and are not necessarily under the direct control of the service provider (for example, the entity). which operates the communication network 100). Because the TIUs are distrustful devices, the information passed to the TIUs can be first encoded before it is given to the TIUs to guarantee the privacy. For example, the status information may be passed from the gate controllers 110 and / or 111 to the TIUs that store the status information for later use (thereby avoiding the need to maintain the status information for a call. in the gate controllers) first by encoding the status information; the status information retrieved from the TIUs can be subsequently verified via known coding techniques. In addition to coding the status information for the TIUs to maintain a cryptographic function of arbitrary choice of elements can be applied to the status information to detect the integrity of the status information (for example, detecting whether the status information has been altered or not by a distrustful entity). By applying a cryptographic value of arbitrary choice of elements to the status information, an arbitrary element choice value is produced that can be sent to and maintained by the TIUs. As a result, when the state information is retrieved from a TIU, the cryptographic function of arbitrary element choice can be applied to this recovered state information; if the same value of arbitrary choice of elements is produced, then the status information has not been altered, for example, in the TIU. The cryptographic functions of arbitrary choice of elements may be, for example, Modification Detection Codes (MDCs) or Messaging Authentication Codes (MACs). The gateway controllers 110 and 111 are attached platforms that have access to the authentication databases and the profile information of the clients on the storage 140 and 141 of the database, respectively. The gateway controllers 110 and 111 implement a group of service-specific control functions, for support communication services, such as authentication and authorization, translation of the number and routing of the call, control of the specific admission of the service, and support of the signaling and service characteristic. Gate controllers can authenticate signaling messages and authorize requests for service, so that communication devices and certain service features are only provided to authorized subscribers. In other words, upon receiving an initial setup or adjustment request message from a calling party, the gate controller can authenticate the identity of the calling party and authorize the service sought by the calling party. The gate controllers can translate or translate the dialed telephone numbers into communication network addresses (such as, for example, IP addresses) based on the routing logic of the call. For example, a source gate controller (e.g., gate controller 110) can translate a dialed telephone number into a communication network address, associated with the gate controller. termination input (for example, gate controller 111). The terminating gate controller may subsequently transfer the address of the communication network to the terminating endpoint (for example, BTI 171) to which the call must be routed. In an alternative embodiment, a simple dial telephone number may be mapped to multiple addresses of the communication network, for example, to allow signaling and endpoints of the means, associated with a call, to be distinct. Gate controllers can implement a wide range of service-specific admission control policies for communication services. For example, gate controllers can provide precedence for the particular call (for example, 911 emergency calls). The gate controllers can perform the admission control to implement the overload control mechanisms, similar to those used in the conventional telephony network (for example, the telephone network 135), for example, to restrict the number of calls to a particular site, or to restrict the frequency of preparation of the call to avoid signaling overload. These mechanisms can be invoked either dynamically or under administrative control. Gate controllers can support the signaling and service feature where service characteristics can not be supported only by the TIUs. For example, certain service features such as call transfer require the change of the endpoints involved in the calls; in such a case, the gate controllers change the gate parameters because the call transfer requires reauthorization by the gate controllers. Service characteristics that depend on the privacy of the caller's information, such as blocking the caller ID (identity), are implemented by the gate controllers. In addition, service features that require users to receive a consistent view of the operation of the feature even when a TIU is not operational are implemented by the gate controllers. For example, gate controllers can control the sending of the call when a TIU for a call is not operational. Gate controllers can be organized into domains where each gate controller is associated with a group of TIUs and the devices at the edge of the network that serve those TIUs. Although TIUs are not trusted entities, there is a trust relationship between a network edge device and its associated gate controller, because the gate controller acts as a security or prudence server that controls when the edge device of the network can provide improved quality of service. A trust relationship can also exist between gate controllers. A gate controller can act as a simple transaction server, so a failure of a gate controller does not affect associated calls that are in process. In one embodiment, a gate controller domain may include a primary gate controller and a secondary gate controller. If the primary gate controller fails, only calls in a transient state are affected (for example, calls that are being established including, for example, example, where network resources are being allocated). The TIUs associated with those affected calls in a transient state will attempt to be established in the secondary gate controller after a period of time has elapsed. All active calls (for example, calls in process) are not affected by the failure of a primary gate controller because the gate controller does not retain the status information for these active, stable calls. As a result, gate controllers easily and efficiently increase in scale as more gate controllers are required for the communication network. The input 130 of the telephone network may include a combination of a trunk input (not shown) and a signaling input (not shown). The trunk input can convert between a data format used on the data network 100 and the code modulation format pulsed (PCM) typically used for transmission over the telephone network 135. The signaling input may provide networking of the signaling between the signaling protocols of the embodiments of the present invention described below and conventional telephony signaling protocols such as ISUP / SS7 (for example, the User Part of the Integrated Services Digital Network / Signaling System 7). In an alternative embodiment, a media entry control protocol may be used to control the operation of a media input, separate from a signaling input. Although not shown in Figure 1, additional network entities (not shown) can be included in the network 10. For example, gate controllers can use other servers to implement the authorization or translation or translation functions. Similarly, the three-way call can be supported using audio bridges in the network 10. Note that although a limited number of network entities are shown in Figure 1 for simplicity of presentation, other entities in the network can be included in the network. network 10. For example, although only a single network interconnect unit (for example, a cable modem) is shown to be connected to a network interconnection unit alone, it is likely that multiple network interconnection units are connected to each network of access.

Similarly, although only a few marginal or edge devices of the network, a few gate controllers and a single telephone network input are shown connected to the communication network 100, many such devices can be connected to the communication network 100. Many other variations to the network 10 shown in Figure 1 are also possible. 2. Reserve Two-Phase Network Resources In the embodiments of the present invention, the network resources for a call between a calling party and a called party are assigned. The resources of the network for the call are reserved based on the reservation request. The resources of the network are reserved before any resource of the network coming from the reserved resources of the network is compromised. The resources of the reserved network, for the call, are committed when a called party indicates the acceptance of the call. The term "network resources" is used herein as the facilities of a communications network required for a call, and any ancillary services associated therewith. call. The resources of the network may include, for example, the capabilities or skills of the equipment within the communications network, necessary to establish and maintain a call to an appropriate quality of service. The equipment within the communications network may include, for example, routers, bridges and entrances within the communications network. The part called "indicates acceptance" for the call in a number of ways. For example, where the called party is using a telephone 190, the called party can indicate the acceptance of the call by lifting the handset, thereby causing a hang-up condition. Where the called party is using a communication device 181 (eg a personal computer), the called party can indicate acceptance by making an appropriate selection with the communication device 181 that initiates acknowledgment signaling (eg, a equivalent personal computer for an off-hook condition). Where the called party has an answering machine, the answering machine's timer can expire to connect the call.

The resources of the network are "reserved" in the sense that the resources of the network required for a particular call can be identified before the called party is effectively connected to the calling party. These network resources may be reserved through the appropriate signal messages collectively referred to herein as a "reservation request". After the appropriate resources of the network have been reserved based on the reservation request, these resources of the network are compromised when the called party indicates the acceptance of the call. By committing the network resources only when the called party indicates the acceptance of the call, the accounting for the call can, for example, accurately track the time of the effective call while excluding the time of preparation for the call . The resources of the network are "committed" in the sense that an available resource of the network operates such that the voice information between the calling party and the called party is transported. Before the resources of the network are committed, the resources of the network are assigned for the call, but they are not configured to effectively carry the voice information for the call. By committing the reserved resources of the network once the called party indicates the acceptance of the call, the resources of the network are not configured wastefully before they are effectively needed. This may be particularly relevant for portions of the communication network where resources are limited, such as, for example, resources upstream within the cable network. The term "quality of service" is used herein to include, but is not limited to, the measurement of the quality of telecommunications service provided during a call. The quality of the service can be specified by a calling party, a called party or the service provider of the communications network, or any combination thereof. In other words, the quality of the service is "authorized" in the sense that the calling party and / or the called party specify a quality of service for the call, and the service provider can verify the specified quality of service for the service. call. For example, a calling party that transfers data (for example, instead of only transferring voice) you can subscribe for a service with a quality of service that has a large bandwidth and small latency; in such an example, a service provider may verify the subscription of the service for the particular quality of the service associated with the call for that particular calling party. Figure 2 illustrates a flow chart for reserving network resources for a call, according to one embodiment of the present invention. Figure 2 is a simplified view of the connection process to better illustrate the allocation of two phases of network resources. This process is in two phases in the sense that the resources of the network are first reserved and then committed in separate and distinct phases. In other words, the resources of the network are reserved first; Once the reservation process is completed, then the reserved resources of the network can be compromised. Other aspects of the entire process will be described in additional detail in other subsequent sections. Note that the components of the communication networks shown in Figure 1 are referred to in Figure 2 for convenience with stenographic or shorthand notation: the TIU 170 of origin (TIU0), which originates the marginal or edge device 120 of the network (NED0), the originating gate controller 110 (GCJ, the termination gate controller 111 (GCJ, the edge device of the termination network 121 (NEDJ, and termination TIU 171 (TIUJ) In step 210, an initial setup or adjustment message for a call between a calling party and a called party is sent from the originating TIU 170 to the remote control 110 source gateway and termination gate controller 111. For example, after receiving the preparation message in the origin gate controller 110, the preparation message (possibly modified with additional information) may be sent to the gate controller 111 termination through the communication network 100. In one embodiment, the preparation message may be for example in the form of a PREPARATION message described later in Section 7 entitled " Protocol description ". In step 220, a gate for the call is established in the edge device 121 of the termination network, after receiving the preparation message from the controller 111 of the termination gate. A "gate" is a call admission control mechanism that uses, for example, known packet filters in the marginal routers. In step 230, another gate for the call is established in the edge device 120 of the originating network. In one embodiment, the gates may have associated time limits on the duration of the gate; Such features may allow calls to be limited where, for example, calls are established with a prepaid calling card, which has a limited amount of call time that is prepaid. Note that when establishing the gates in the edge devices of the originating and terminating network, instead of the corresponding gateway controllers, the status information for the call is maintained in a network entity through the which the call is routed. In other words, the status information for a call can be maintained without maintaining the status information in a gate controller. Consequently, if a gate controller fails after the gates have been established for a call, the call can be maintained. He Establishing the floodgates for a call is discussed more fully later in Section 4 entitled "Gateway Coordination on a Base by Call". In step 240, a reservation message is sent from the origin TIU 170 to the origin NED 120. In step 250, a reservation message is sent from terminating TIU 171 to terminating NED 121. The reservation messages sent by the originating TIU 170 and the termination TIU 171 are a part of the reservation process where an allocation of the network resources is required, but the resources of the network do not yet need to be assigned or committed. The allocation of network resources includes verification that the quality of service desired by a TIU is not greater than the quality of service authorized by the corresponding gate controller; the gate controller authorizes a quality of service for a call using the authentication databases and the customer profile information about the storage of the associated database (for example, storage 140 and 141 of the database ).

In order to provide the telephone grade service over the network 10, the network 10 can provide loss per packet, bounded and the delay for the voice packets of a call when handling the active resources in the access networks 150 and 151, and the communication network 100. Because the edge devices of the network (eg, NEDs 120 and 121) within the path or connection path for a call may have constricted links in capacity ^, reservation requests for a call (and any associated messages) are sent end-to-end, which ensures that the resources of the network are available end-to-end. In one embodiment, because the access networks 150 and 151 may be of constrained capacity (at least in the upstream direction), resource management is performed on a per-call basis for the access networks 150 and 151. The management of resources in communication network 100, however, may be performed on a per-call basis or on a coarse-grained resource base (e.g., resources within communication network 100 may be reserved for multiple calls). at a given time). The handling of the resources within the portions of the communication network 100 can be made on a per-call basis, because some devices at the edge of the network with the communication network 100 may not have sufficient processing capacity to process a greater number of reservation messages, typical for high volume call traffic. Alternatively, the management of the resources within the portions of the communication network 100 may be performed on a multiple call basis if these portions of the communication network 100 are adequately provisioned (eg, sufficient capacity has been reserved by the reservation of multiple calls); in such cases, the edge devices of the network within these portions of the communication network 100 do not need to perform admission control per call. Accordingly, in one embodiment of the present invention, some edge devices of the network do control admission by flow to interpret reservation requests, while other edge devices of the network that are in regions rich in capacity of the data network 100, are provisioned to simply send their messages without interpretation.

The embodiments of the present invention can realize the reservation of resources in the communication network 100 in a unidirectional manner which thereby compensates for the routing asymmetries. In this way, when the originating TIU 170 sends a reservation request to the originating NED 120, and when the originating TIU 170 again receives an acknowledgment for the reservation request, two aspects of the connection are confirmed. First, the appropriate bandwidth for the call is available in both directions over the access networks 150 and 151. Second, the appropriate bandwidth for the call is available over the communication network 100. Steps 210 to 240 describe the process of reserving the resources of the network. At this point, the resources of the network that are going to be used for the call are reserved, but none of these resources of the network are still committed. In step 250, end-to-end messages are exchanged between the originating TIU 170 and the terminating TIU 171. As discussed previously, the term "end-to-end" refers to those associated between two endpoints, associated with a call. So, where a call involves a calling party and a called party using telephones, the end-to-end association for the call may be between the two telephone interconnection units; in this way, end-to-end messages could include messages originating in a telephone interconnection unit and terminating in the other telephone interconnection unit. End-to-end messages can include, for example, a ring or sound message from the originating TIU 170 to the termination TIU 171, a call signal message from the terminating TIU 171 to the originating TIU 170, and a connection message from the originating TIU 170. the 171 TIU termination to the origin TIU 170. The ringing message can signal the termination telephone 191 to sound, thereby indicating a incoming call. The call signal message can signal to the TIU 170 that the terminating telephone 190 is ringing. The connection message can signal to the originating TIU 170 that the called party has indicated acceptance of the call by, for example, picking up. Note that these end-to-end messages can be routed between the origin TIU 170 and the TIU 171 termination without being routed through the originating gate controller 110 or the terminating gate controller 111. In step 270, after the calling party and the called party are connected (eg, after the condition of pick-up by the called party and a connection message is being sent), a commit message is sent from the originating TIU 170 to the originating NED 120 and from the terminating TIU 171 to the terminating NED 121. In step 280, after receiving the commitment message in the originating NED 120, the gate established in the origin NED 120 in step 230 is opened. Similarly, in step 290, after receiving the commitment message in the terminating NED 121, the gate established in the terminating NED 120 in step 220 is opened. At this point, when the gates open on the NED 120 of origin and on the NED 121 of termination, the reserved resources of the network are committed. The commitment process may include verification by the NED that the effective quality of the service sought by the associated TIU is not greater than the quality of the service reserved during the reservation process.

The gate on the edge or edge edge router and the gate on the terminating edge router for each call open almost simultaneously (for example, within a few hundred milliseconds of each other) because, under conditions of normal operation, the calling party and the called party send the respective commitment message to their respective network edge devices substantially simultaneously. Similarly, under normal operating conditions, the calling party and the called party terminate the call and send the respective disconnection messages to their respective network edge devices, substantially simultaneously. The gate condition prevents billing for incomplete calls and prevents the theft of the service by two collided BTIs. By separating the reservation process from the commitment process, the embodiments of the present invention advantageously ensure that the resources of the network are available before effectively ringing the telephone at the far end (eg, the called party's telephone). This, of course, advantageously ensures that the usage record is not started until the end telephone Far be off the hook. As a result, billing of the call excludes calls that are not completed (for example, where the called party does not respond) and excludes the portion of the calls that occur before the called party answers. Although Figure 2 describes a modality for reserving resources of the network where the calling party and the called party were using telephones 190 and 191, respectively, through the TIUs 170 and 171, respectively, the process can be converted to analog for a calling party and / or a called party, using a communication device 180 and 181, respectively. Note that the status information for a call can be maintained without maintaining the status information in a gate controller. From the perspective of the originating gate controller, a gate preparation message for a call (e.g., a GATEWAY PREPARATION message described in Section 7 below) is received through a gate edge device. the network that connects a trusted network to a distrustful network. The status information for the call (for example, contained within a message GATE ALLOCATION (GATEALLOC) described in Section 7 below) is formatted in the gate controllers based on the call preparation message. The status information for the call is sent to the edge device of the source network without maintaining the status information in the originating gate controller and in the edge device of the terminating network, without maintaining the status information in the terminating gate controller. Note that the term "maintained" as used herein with reference to the status information is intended to include the storage and use of the status information while the call is being established, the call is in progress and the call is is being disconnected Although the status information may be temporarily stored in the gate controllers, the status information is not maintained in the gate controller because gate controllers do not use the status information (for example, for the processing of the call). ) while the call is being established, the call is in progress and the call is being disconnected. In fact, gate controllers do not need to store the state information after the status information has been provided to the edge routers of the network, because the status information for the call is accessed in the gate controllers, not the gate controllers. 3. Two-phase signaling In the embodiments of the present invention, the signaling messages are exchanged for a call between a calling party to a called party, in two phases. The signaling messages are exchanged in two phases in the sense that the messages for the initial preparation or adjustment of the call are exchanged in one phase, and the messages to connect the call are exchanged in a separate and distinct second phase. By separating the messages in the preparation of the call from the messages to connect the call, the last messages can be exchanged end-to-end without being routed through the gate controllers that prepare the call. Note that this concept of two-phase signaling is different from the concept of Reservation of resources of the two-phase network, in the sense that the signaling of two phases can be carried out in combination with or independent of the reservation of resources of the two-phase network. In other words, when performed in combination, messaging for two-phase signaling can be interspersed with messaging for the reservation of two-phase network resources; when they are done independently, the messages for each one may be different. The reservation of resources of the network of two phases refers to the reservation of resources of the network without compromising them, then committing those reserved resources. The two-phase signaling refers to the realization of the signaling to prepare the call, then once the call is ready (for example, whereby the authorized quality of the service is confirmed), the messages are exchanged end-to-end. A preparation message that has a destination address is sent from the calling party to the called party. A readout acknowledgment message is received for example in a gate controller from the called party if the destination address corresponds to the called party. The recognition message of Received preparation is sent to the calling party. The calling party and the called party exchanged the messages end-to-end if the calling party received the prepared acknowledgment message, sent, and if at least one of the party from the called party and the calling party sent a message from the called party. reservation to an associated network edge device. Figure 3 illustrates a flow chart for performing two-phase signaling in the call connection, according to one embodiment of the present invention. In step 310, the calling party picks up and dials a telephone number of the called party. For convenience, Figure 3 will be discussed where the calling party is using telephone 190 and the called party is using telephone 191. Of course, any number of arrangements is possible, as the calling party uses the communication device 180 In step 320, the originating TIU 170 collects the dialed digits. In step 330, the originating TIU 170 sends a preparation message to the originating gate controller 110. The preparation message can be sent through the network interconnection unit 160, the access network 150, the NED 120 and the network communication 100. In one embodiment, the preparation message may be, for example, in the form of a PREPARATION (SETUP) message described later in Section 7 entitled "Protocol Description". In step 340, the preparation message is sent from the origin gate controller 110 to the termination gate controller 111. In step 350, the preparation message is sent from the termination gate controller 111 to the termination TIU 171. (After receiving the preparation message, the originating gate controller 110 and the terminating gate controller 111, may establish a gate on the originating NED 120 and a gate on the terminating NED 121, as described in Section 2 above). In step 360, if the destination address of the preparation message corresponds to the terminating TIU 171, a preparation acknowledgment message is sent to the TIU 170. The preparation acknowledgment message can be sent, for example, via of the termination gate controller 111 and the origin gate controller 110. In one embodiment, the preparation acknowledgment message may be, for example, example, in the form of the STUPACK RECOGNITION message described later in Section 7 entitled "Description of the Protocol". In step 370, the network resources for the call are reserved. As described earlier in Section 2 entitled "Reservation of Two-Phase Network Resources", a reservation message is sent from the originating TIU 170 to the originating NED 120 and from the terminating TIU 170 to the terminating NED 121 , when an allocation of network resources is required but the resources of the network do not yet need to be assigned or committed. In steps 380 to 395, end-to-end messages are exchanged between the originating TIU 170 and terminating TIU 171 if the calling party received the readiness acknowledgment message sent to the originating TIU 170 in step 170 and if the calling party or the called party sent a reservation message to their NED. In other words, the end-to-end messages that refer to the call connection are exchanged only after the reservation messages have been exchanged and the reservation process is completed. This ensures that the The service is only provided to the calling party and the called party that have been authorized and authenticated for the call. This also ensures that the call is established for a specifically authorized quality of service and that the call is properly billed. In step 380, a ringing message is sent from the originating TIU 170 to the terminating TIU 171. The ringing message may signal the terminating telephone 191 to ring, thereby indicating an incoming call. In step 390, a return message or call signal is sent from the terminating TIU 171 to the originating TIU 170. The call signal message may signal the originating TIU 170 that the terminating telephone 190 is ringing. In step 395, a connection message is sent from terminating TIU 171 to the originating TIU 170. The connection message can signal to the originating TIU 170 that the called party has indicated the acceptance of the call, for example by the action of off-hook. These end-to-end messages can be routed between the originating TIU 170 and terminating TIU 171 without being routed through the source gate controller 110 or termination gate controller 111, because the status information for the call may be maintained without maintaining it in gate controllers 110 and 111. In addition, these end-to-end messages can be routed through the NEDs 120 and 121 opaquely. Note that when separating the signaling for a call that refers to the reservation process and that is related to the connection process, the concept of the dedicated telephone line, traditional for a telephone user can be replaced with a process that authenticates the calling party and the called party, and authorizes a desired quality of service on a per-call basis. In other words, only authenticated users reserve network resources for an authorized quality of service before these network resources are connected. Consequently, calls that have varying service qualities can be provided and suitably invoiced on a call-by-call basis. In addition, by separating signaling for a call into signals that refer to the reservation process and signals that refer to the process of connection, the gate controllers are involved in the signaling process where they are only necessary; during the reservation process. After the reservation process is complete, the originating and terminating gate controllers pass the status information for the call, for example, to the originating and terminating TIUs without maintaining the status information in the gate controllers. Gate controllers no longer need to be involved in the call and messaging related to the connection process can be sent end-to-end without being routed through the gate controllers. In other words, gate controllers are involved only during the initial start of the call, but not during the duration of the call. This results in a reduction of the message load for example by approximately a factor of three. Consequently, the amount of memory needed in the gate controllers is greatly reduced. In addition, gate controllers can be constructed without the typically strict requirements for reliability. 4. Coordination of Gate in a Base by Call As discussed in the preceding section, the reserved resources of the network can be compromised after the edge, originating, and terminating devices receiving the commitment messages indicate that the call has been connected. At this point, the gates associated with a call between a calling party and a called party can be opened in a coordinated manner. A timer associated with a first gate open on a device at the edge of the source network is started. A first open gate message is sent from the edge device of the originating network to the edge device of the terminating network. The first gate on the edge device of the originating network is disconnected if the stopwatch expires before at least one of the group of: (1) an acknowledgment based on the first message sent from the open gate that is received from the edge device of the terminating network, and (2) a second open gate message is received at the edge device of the originating network from the edge device of the terminating network after the edge device of the terminating network has opened a second gate associated with the called part. In step 400, a timer associated with a gate in the originating NED 120 is started after receiving a commitment message from the originating TIU 170. In step 410, a stopwatch associated with a gate on the terminating NED 121 is initiated after receiving a commitment message from terminating TIU 171. As described above in Section 2 entitled "Two-Phase Network Resource Reservation", the commitment message is sent from a TIU to the associated NED after the called party indicates an acceptance of the call (for example, by a connection message that is sent from the terminating TIU to the originating TIU). The steps in order 400 and 410 depend on the order in which the NEDs receive the commitment message from their associated TIUs. In step 420, an open gate message is sent from the originating NED 120 to the terminating NED 121. In step 430, an open gate message is sent from the terminating NED 121 to the originating NED 120. In one modality, the readiness acknowledgment message may be, for example, in the form of an OPEN GATE message (GATEOPEN) described later in Section 7 entitled "Description of the Protocol". The order in which steps 420 and 430 are performed, depends on the order in which steps 400 and 410 are performed. An open gate message is sent from one NED to the other NED to notify the other NED when a new one has been opened. gate for the call. In step 440, an open gate recognition message is sent from the originating NED 120 to the terminating NED 121 after the originating NED 121 receives the open gate message sent during step 430 by the NED 120 of termination. In step 450, an open gate recognition message is sent from the terminating NED 121 to the originating NED 120 after the terminating NED 120 receives the open gate message sent during step 420 by the NED 120 of origin. In one embodiment, the readiness recognition message may be, for example, in the form of an GATEOPENACK RECOGNITION message described later in Section 7 entitled "Description of the Protocol". The order in which steps 440 and 450 are performed depend on the order in which the open gate recognition messages are received. In conditional step 470, a determination is made as to whether the stopwatch for the gate on the originating NED 120 expired before (1) the originating NED 120 received the gate open recognition message from the terminating NED 121., or (2) the originating NED 120 received the gateway message opened from the terminating NED 121. If the timer expired before the condition was satisfied, then the process proceeds to step 475 where the gate on the originating NED 120 is closed and disconnected. If the timer did not expire before any connection was satisfied, then the process proceeds to step 477 where the gate in the originating NED 120 is allowed to remain open. In conditional step 480, a determination is made whether the stopwatch for the gate on the terminating NED 121 expired before (1) the terminating NED 121 received the gate recognition message opened from the originating NED 120, or (2) the NED 121 of termination received the open gate message from the source NED 120. If the timer expired before any condition was satisfied, then the process proceeds to step 485 where the gate on the terminating NED 121 is closed and disconnected. If the timer did not expire before any condition was satisfied, then proceed to step 487 where the gate on the terminating NED 121 is allowed to remain open. A gate "closes" in the sense that the call is no longer active even though the gate for the call remains set for the later possible use. For example, in a call having a call waiting feature, a first part can be connected to the other two parts and two gates (one per call) will be established in the edge device of the network associated with the first part. In this case, as the first part switches between calls, the temporarily inactive call will have an associated gate that closes; This closed gate can be reopened after the call is reactivated. A gate is "disconnected" in the sense that the call is no longer active and the gate for the call is deleted from the edge device of the network, associated. In such a case, for a call to be initiated, the process of booking network resources, complete, and the commitment process (see for example the discussion related to Figure 2) have to be repeated. The stopwatch in a gate ensures that the other gate related to the call is also opened within the period of the stopwatch, so that the billing for the call is correct and so that the theft of the service can be prevented. Without such gate coordination, any service provider could bill a party for a call where only one gate was opened (even if the calling party was not connected to the called party) or a service provider could be susceptible to theft of the gate. service for a call where only one gate is opened. Considering the latter, the theft of the service could occur without the coordination of the gates, for example, by two colluded TIUs: where the originating TIU can initiate a call and only the terminating TIU sends a local commit message, the simple gate it might not be disconnected for up to several minutes because the phone at the far end might be ringing; the originating BTI could then steal the service during this time. By sending the gateway message open from the edge device of the network with a gate open to the edge device of the network, without a corresponding peer gate, the second gateway for the call is secure to be established even if a gateway is not received. commitment message from the associated TIU (as might be the case if a service theft was attempted). The coordination of the gates can also be done at the end of a call. Just as an open gate message and an open gate recognition message is sent to the edge device of the network where the peer gate is established, a closed gate message and a closed gate recognition message can be sent on a gate that closes to the edge device of the network where the peer gate opens. In other words, when a call is terminated either by the calling party or by the called party, the terminating party has its gate closed and the peer gate is informed of the closure, so that the peer gate closes as well. . An example of message exchange for a gate that closes is shown in the Figure 8, and the associated discussion in Section 8 entitled "Signage Architecture Call Flows". By coordinating the locks of the floodgates, it can again be prevented the theft of the service by a TIU that works badly or badly. Consider the case where the originating TIU 170 calls the termination TIU 171 and pays for the call. If the calling party or the called party terminates the call, the gates in the NED 120 of origin and in the NED 121 of completion need to be closed. Because the originating TIU 170 is being billed for the call, the calling party has an incentive to issue a disconnect message to close the gate on the originating NED 120. The terminating TIU 171, however, can not be trusted to send the disconnect message to close the gate on the terminating NED 121. A closed gate message sent from the originating NED 120 may close the gate on the terminating NED 121 to prevent the terminating TIU 171 from placing another call and having that call invoiced to the party associated with the TIU 170. 7 . Translation of Network Management Because TIUs are distrustful entities, any information that a calling party or a called party wishes to keep private information, such as caller ID, or address information, must be accessible to the network but not to the other distrustful entities. This section describes the use of network address translations and coding techniques that allow gatekeepers to send status information to TIUs, where it is maintained in a way that makes private information opaque. In one mode, a call between a calling party and a called party, is connected. The information associated with the call is sent from the calling party to the called party without the called party receiving an address from the source, which indicates at least one of the group of a logical entity of the calling party and a geographical identity of the calling party. the calling party. The term "logical identity" is used in the present to include, for example, any aspect of the address of the source or of the destination address that indicates the specific identity of a calling party or called party. The term "geographical identity" is used herein to include, for example, an aspect of the address of the source or of the destination address indicating the particular geographic location of a calling party or the called party. Even where a network address has been modified or altered to protect the logical identity of a calling party or called party, the remaining aspects of the network address may reveal the general geographic location of the party. In one embodiment of the present invention, the information is sent from one party to another party without revealing either the logical identity or the geographical identity of a party. Figure 5 illustrates a flow diagram for moving or translating a network address, according to an embodiment of the present invention. In step 500, packets having the address of the source and destination are sent from the originating TIU 170 through the interconnection unit 160 of the originating network to the originating NED 120. The source address and destination address identify the calling party and the party locally call, respectively. These addresses are "local" in the sense that they are associated with particular portions of the networks (also referred to herein as "address domains"), such as the portions of the access network 150 and / or the network of communication 100 and / or other access networks (not shown in Figure 1). These local addresses are not sent outside of their respective address domains. To send packets outside the address domain, the destination needs to be identified by a global address, as described below. Table 1 illustrates an example of the source address (SA) and the destination address (DA) at this point.

Table 1 In step 510, the packets received in the NED 120 are transferred from the local addresses for the address domain within the access network 150 to the global addresses. Not only the destination address can be transferred or translated into a global address, but the address of the source can also be translated to a global address. Table 2 illustrates a translation or translation table for the call used in the NED 120. Note that the global addresses used for the call can be assigned dynamically, for example, on a call-by-call basis, so that when a call has finished, the global address can be reused by another unrelated call.

Table 2 In step 520, the packets are sent from the originating NED 120 to the terminating NED 121. At this point, the packets have the global address shown in Table 2. In step 530, the packets received in the terminating NED 121 are moved from the global addresses to addresses that are local to the address domain for which they are allocated. It includes termination access network 151. Table 3 illustrates a translation table for the call used in NED 121, to translate or translate global addresses to local addresses.

Table 3 In step 540, the packets translated or translated by the terminating NED 121 are sent through the access network 151 to the termination TIU 171. Table 4 illustrates the address of the source and the destination address for the packets for the call as the packets are transmitted through the termination access network 151, through the interconnection unit 161 of the terminating network to the termination TIU 171.

Table 4 The translated packets are received in terminating TIU 171 without revealing the local identity and geographic identity of the calling party. Note that the called party only has access to the address of the global source and to the global destination address which by themselves are translations or translations. Because the address of the calling source has been translated twice, once in the originating NED 120 and once in the terminating NED 121, the address information regarding the calling party has been altered beyond the recognition to the calling party. Once the call is completed, the translation or translation tables in the originating NED 120 and the terminating NED 121 can be deleted, and the global addresses can be disconnected for re-use in another call. For example, if the translation of the network address is incorporated into the functionality of the respective gateways, the global addresses can be disconnected when the gates are disconnected. In another mode, global addresses can be disconnected after a period of inactivity.

Figure 5 illustrates the process by which packets are sent from the origin TIU 170 to the termination TIU 171. Similarly, the packets sent from the terminating TIU 171 and the originating TIU 170 can be translated into the terminating NED 121 (inverse of translation or translation shown in Table 3) and again into the originating NED 120 (inverse of the translation or translation shown in Table 2). In this way, the address of the source and the destination address of the packets can be sent from the terminating TIU 171 to the originating TIU 170 without revealing the logical identity and geographical identity of the called party. The double translation of network addresses can be provided as a service to a subscriber by a service provider. In other words, a call can be connected where the calling party and / or the called party subscribe to the double translation service. Figure 5 illustrates the case where the privacy of the calling party and the address information of the called party are maintained: the source address and the destination address of the packets for the call are transferred as the packets are sent from the party that calls the called party and according to the packets for the call are sent from the called party to the calling party. The double translation service may be provided to one party (for example, only to the calling party or the called party) without providing the service to the other party. In such a case, for example where only the calling party has subscribed to the double translation service, the address of the first source for the packets sent from the originating TIU 170 are transferred in the originating NED 120 to a source address global, and the global address for these packets are transferred in the terminating NED 121 to a second local source address. As the packets are sent from the terminating TIU 171, the second address of the local source is translated in the terminating NED 121 to the address of the global source, and the address of the global source is moved to the address of the first source in the NED 120 of origin. In other words, where only one party has subscribed to the double translation service, the address associated with that part is moved twice. Consequently, the logical identity and the The geographical identity of that part is kept in the privacy of the other party for the call. The translation tables in the NED 120 of origin and in the terminating NED 121 can be prepared for a specific call and can then be deleted at the end of the call. This additionally ensures the privacy of the calling party and / or the called party, because the global addresses are not repeated. In addition, by releasing global addresses at the end of a call, global addresses can be reused for another call that has a different calling party and / or called party. Consequently, any potential shortening in the number of global addresses can be alleviated because the number of active calls at a single time is much less than the number of total parties calling and called parties. 6. Simulated Destination Call Sign In still another embodiment of the present invention, a call signal for a call between a calling party and a called party can be simulated. An associated connection acknowledgment with the call it is received where the calling party is located within a first network and the called party is located within a second network. A pre-stored callback signal, from a group of pre-stored callback signals, is selected where the pre-stored callback signal, selected, is associated with the second network. The pre-stored callback signal, selected, is sent to the calling party. The pre-stored callback signal may be, for example, a signal that is indicative of the network associated with the called party instead of a signal originating from that network. For example, a signal indicating a foreign network (eg, a network located in a foreign country) can be stored in a terminating TIU and provided within a callback message sent to the originating TIU. In such a case, the callback signal can simulate the callback signal for that foreign country, instead of relying on the effective callback signal originating in the foreign network. 7. Description of the Protocol This section contains details of the various protocols associated with the embodiments of the present invention. These include communication between BTI and the Gate Controller, between the BTI and the Edge Router, between the BTI and other BTIs, between the Gate Controller and the Edge Router, between the Edge Router and the Edge Router, and between the Gate Controller and the Gate Controller. All messages are given here in a text-based format, using a type / value structure. This is particularly easy for prototype implementations, and to describe the interactions between network elements. However, if any system components exist where memory is a serious limitation, it is possible that a binary format could be used to conserve cache space requirements. A simple message is: SETUP 0S55072 vl.O; DEST E164 8766; CALLER 8718 Bill Marsha11; AUTHID 3312120; CRV 21; CODING 53B, 6ms G.711 The messages consist of a sequence of type / value pairs. Each element of the sequence is separated by a semicolon; A semicolon at the end of the message is optional. The type and value are sequences of ascii characters, separated by blanks (for example, spaces or tabs). In general, each element contains at least two paragraphs or articles, the name of the type and the value of the parameter, but may contain several parameter values separated by blanks. The first element of each message can be in a standard format. The type of the first element is the name of the message, the first parameter is the transaction identifier, and the second parameter is the number version (for example, vi .0 here). The embodiments of the present invention can use an application layer retransmission scheme to achieve reliable transport of the messages. This can be done independently of any reliable, lower layer transmission protocol, because the signaling system must also recover from component failures and transactions Restart when a component has failed. This happens frequently after the component has received the acknowledgment, and has started the work on demand; This is until the application layer realizes that no response is coming and restarts the transaction. Therefore, the behavior of the elements of the network can be specified as if the underlying transport was merely UDP / IP, and does not provide separation, flow control, or error recovery. All exchanges of basic messages can be based on the transaction. It all starts with a request message issued by a client, and sent to a server. The client can provide a unique transaction identifier for each separate request, and provide that transaction identifier in the standard place in all messages. The client can ensure that the transaction identifier is not reused for any subsequent messages for a period of at least some specified interval (e.g., approximately 30 seconds).

A sample exchange begins with a client that forms a request message and sends it to the server: SETUP 1X64193 vl.O; < other material > The message type is SETUP (PREPARATION), the transaction identifier is 1X64193, and the message is using version 1.0. When the server has completed the work required by this transaction, it sends one of two possible responses. SETUPACK 1X64193 vl.O; < other material > or SETUPNAK 1X64193 vl.O; < other material > . The server can store all the requests it receives for some period of time (for example, 30 seconds). The server can also store its responses for some period of time (for example, 30 seconds) in case the answers were lost in the transmission and needed to be forwarded. If a client sends a request but does not receive a response within a reasonable time (which may vary based on the type of message), it forwards the original request, without any modification.

If a server receives a request message that it recognizes as a duplicate (same source, same transaction identifier, same type of message, not necessary to compare the message content), it forwards its response, if the response has been completed, or send a pseudo-r'espuesta: WORKING 1X64193 vl.O; The reception of a work message (WORKING) on the client indicates that the server has received the message, and the response has not yet been sent. It is reasonable for the client to use a longer timer instead of forwarding the request again. In some situations, for example the SETUP message, the normal processing time may exceed the period of the client's elapsed time. In this case, the server can immediately send the WORKING pseudo-response upon receipt of a request. The typical elapsed times that seem reasonable to use are: BTI for the Edge Router: 0.5 seconds initially, 1 second after the WORKING response; BTI for the Gate Controller: 1 second, 2 seconds after the WORKING response; The Controller of the Gateway for GC: 1 second, 2 seconds after the WORKING response. 7. 1 BTI for the Gate Controller The BTI initiates transactions with the Gate Controller to request a new connection to a remote called endpoint, or to request an enhanced service that is performed on an existing connection. In addition to the basic connections, this protocol makes it possible for all the call characteristics of the clients to be implemented, and provides conference control capability. This protocol can use significant intelligence in the BTI, allowing it to fully manage the user's interconnection and implement the new services for clients that constitute the primitives that exist in the signaling system of the modalities of the present invention. Messages initiated by the BTI include PREPARATION (SETUP), REDIRECT (REDIRECT), SPLICE (SPLICE), TRACE (TRACE), and PROFILE. SETUP is used to start a new connection. REDIRECT takes an existing connection and sends it to some other destination. SPLICE takes two existing connections and connects them together. TRACE generates a legal enforcement report of an abusive or harassing call. PROFILE makes it possible for the BTI to specify the customer's call handling services for times when the BTI can not be contacted (for example, power failure). 7. 1.1 PREPARATION (SETUP) SETUP is the basic message sent by a BTI to initiate a connection to another endpoint; an exemplary message is: SETUP 0S55072 vl.O; DEST E164 8766; CALLER 8718; AUTHID 3312120; CRV 21: SIGADDR wtm-bt i: 7685; DATAADDR wtm-bti: 7000 2 2; CODING 53B, 6ms, G.711 DEST specifies the destination of this call.

The first parameter in this field gives a name of address space to search; Valid address spaces are E164 (phone numbers standards), CINFO (sequence of the source from a previous call), and SERVICE (generic network service by name). The second parameter gives the telephone number / sequence of the source / effective service name. Additional parameters, if given, are passed through and given to the receiving end point. Examples of different uses of the DEST element are: DEST E164 8766 places a new call to a phone number. The second parameter is the number of the customer's dial plan (for example, centrex, nanp, etc.). DEST CINFO < sequence > places a return call to a previous caller, for example, the return call * 69. The second parameter is the sequence given in a SETUP, SETUPACK, or TRANSFER. DEST SERVICE bridge 3 places a call to a network service, in this example a bridge service for 3 parties. The second parameter is the name of the network service (for example, bridge, warning or announcement, etc.) and the additional parameters are given to that service for later interpretation. The CALLER gives the identity value of the caller for the line that is originating this call. The Gate Controller should verify that this caller ID is valid based on the AUTHID. Since the BTI is out of control, it can not be assured that the call is really coming from the line that it claims; however, it can be ensured that the caller id specified is one of the possible ones from this BTI. AUTHID is the authorization code given to this particular BTI from the OAMP system. This is changed periodically, for example, every ten minutes. CRV is the Call Reference Value assigned to the end of the BTI of this new call. CRV appears in all messages sent to the BTI, making it possible for the BTI to correctly assign the message to the appropriate call, and properly ignore messages that refer to previous call attempts. Note that there are multiple path conditions or routes if a client partially completes a call, hangs up, and then makes another call. BTI needs some mechanism to ignore old messages without the need to synchronize with all possible parties before processing a new request of the customer (for example, giving the customer another dial tone). SIGADDR is the name of the IP system and the port number that the called endpoint should use as a destination for all BTI-BTI messages. This can be the same address and port that are used by the Gate Controller to signal an incoming call, or it can be a separate port for the current call only. If this is the same port, then it is necessary to structure the messages such that the BTI can distinguish the GC-BTI messages from the BTI-BTI messages, whose embodiments of the present invention can. DATAADR is the name of the IP system and the port specification that the called endpoint must use as a destination for all voice data packets. The first parameter is a system name: port number, where the port number is the lowest port number in a group of consecutive ports. The second parameter gives the size of the group of consecutive ports. The third parameter, if present, gives any alignment requirements for the port numbers if it is necessary to move them in a PAT server. A voice-only telephone call, typical it will use two ports, the first for RTP and the second for RTCP, and will require the first port to be uniform. CODING specifies a list of possible encapsulations and coding methods that the originator will perform. Each parameter is at least three articles or subsections separated by commas, where the first article specifies a message size, the second article gives the interval between packages, the third article gives the coding algorithm, and the fourth and last article (optional) ) gives the additional parameters specific to the encoder. 7. 1.1.1 SETUP Recognition The response to a SETUP message is SETUPACK or SETUPNAK. A sample SETUPACK message is: SETUPACK 0S55072 vl.O; CRV 3712; SIGADDR 10.0.0.1:5134; DATAADDR . 0.0.1: 5136 2; CODING 53B, 6ms, G.711; GATEIP 135. 207.31.1: 7682; GATEID 17S63224; CINFO < SEQUENCE > CRV gives the Call Reference Value assigned by the remote endpoint, to identify all messages associated with the conversation. This must be included in all BTI-BTI messages. SIGADDR gives the address and port to use as a destination for all BTI-BTI signaling messages. DATAADDR gives the address and ports to be used as a destination for all voice data packets. The second parameter gives the number of consecutive ports assigned for this purpose. CODING gives the simple encapsulation and coding method of the choices presented in the SETUP message, which is acceptable for the BTI destination. The format of the parameter is identical to that previously given. GATEIP gives the IP address and the port number of the Edge Router that contains the gate that controls the access service for this connection. This is the destination address to use for all BTI-ER messages. GATEID gives the identification and authorization card assigned by the Edge Router for the gate assigned to this connection.

CINFO 'is a coded sequence of information from the Gate Controller, which contains a number of items or items of status information, required by the Gate Controller to adequately handle any future requests for advanced features for this call, for example, 3-way call, callback, transfer, etc. This must be stored unaltered by the BTI and returned to the unaltered Gate Controller, for any of these characteristics. 7. 1.1.2 SETUP error If the SETUP fails, the Controller Gateway will return an error indication to the BTI. A sample STUPNAK message is: SETUPNAK 0S55072 vl.O; ERROR Authorization failed ERROR gives an error message sequence, which could be displayed visually if the BTI had some method to do so. Otherwise, it provides some useful debugging information. 7. 1.2 REDIRECT The BTI sends a REDIRECT message to its Gate Controller when it wants a current call to be redirected to some other destination. A sample REDIRECT message is: REDIRECT 0S42115 vl.O; DEST E164 8720; CALLER 8766; AUTHID 6929022; CINFO 135.207.31.2.7650 / 135.207.31.1.7682 / 17S63224 / 10.0.12.221: 7685 / 10.0.12.221:7000-2-2/9733608718/21/10.0.12.221:7685 DEST gives the new desired destination of this call. This can be either an E164 number, a service name, or a CINFO sequence, just like in the SETUP message. CALLER gives the identity value of the caller for the line that is making the request. The Gate Controller should verify that this caller ID is valid based on the AUTHID. Since the BTI is out of our control, you can not be sure that the call is really coming from the line that it calls; however, it can be assured that the specified caller id is one of the possible ones from BTI.

AUTHID is the authorization code given to this particular BTI from the OAMP system. This is changed periodically, for example every ten minutes. CINFO is the previously encoded sequence provided by the Gate Controller, which tells the Gate Controller several pieces of information regarding the current call. 7. 1.2.1 Recognition REDIRECT If the Gate Controller is successful in directing the call to the new destination, it will respond with the REDIRECTACK message. One sample is: REDIRECTACK 0S42115 vl.O; 7. 1.2.2 REDIRECT error If the REDIRECT fails, the Gate Controller will return an error indication to the BTI. A sample message REDIRECTNAK is: REDIRECTNAK 0S55072 vl.O; ERROR Authorization failed The ERROR gives a sequence of error messages, which could be displayed visually if the BTI I had some method to do it like that. Otherwise, it provides some useful debugging information. 7. 1.3 SPLICE The BTI sends an SPLICE message to its Gate Controller when it wants two current calls to be connected to each other. A sample SPLICE message is: SPLICE 0S42161 vl.O; CALLER 8766; AUTHID 6929022; CINFOl 135.207.31.2: 7650 / 135.207.31.1: 7682 / 17S63224 / 10.0.12.221:7685/10.0.12.221:7000-2-2/9733608718/21/ 10.0.12.221:7685; CINF02 135.207.31.2:7650/135.207.22.1:7682/5S71731/ 10.3.7.150:7685/10.3.7.150:7000-2-2/9733608720/8839/ 10.3.7.150:7685 The CALLER gives the identity value of the caller for the line that is making the request. The Gate Controller should verify that this caller ID is valid based on the AUTHID. Since the BTI is out of control, it can not be assured that the call is really coming from the line that it claims; however, it can be ensured that the caller id specified is one of the possible ones from this BTI. AUTHID is the authorization code given to this particular BTI from the OAMP system. This is changed periodically, for example, every ten minutes. CINF01 is the previously encoded sequence supplied by the Controller of Gate, which tells the gate controller several pieces of information regarding the first call. CINFO 2 is the previously encoded sequence provided by the Controller of Gate, which tells the gate controller several pieces of information regarding the second call. 7. 1.3.1 Recognition of SPLICE If the Gate Controller is successful in directing the two calls to each other, it will respond with an SPLICEACK message. One sample is: SPLICEACK 0S42161 vl.O; 7. 1.3.2 SPLICE error If the SPLICE fails, the Gate Controller will return an error indication to the BTI. A sample SPLICENAK message is: SPLICENAK 0S55072 vl.O; ERROR Failed authorization ERROR gives an error message sequence, which could be displayed visually if the BTI had some method to do so. Otherwise it provides some useful debugging information. 7. 1.4 TRACE The BTI sends a TRACE message to its Gate Controller when it reports an abusive or harassing telephone call for legal enforcement. A sample TRACE message is: TRACE 0S42115 vl.O; CALLER 8766; AUTHID 6929022; CINFO 135.207.31.2: 7650 / 135.207.31.1: 7682 / 17S63224 / 10.0.12.221:7685/10.0.12.221:7000-2-2/9733608718/21/ 10.0.12.221:7685 CALLER gives the identity value of the caller for the line that is making the request. The Gatekeeper verifies that this caller ID is valid based on the AUTHID. Because the BTI is beyond the control of the service provider, the service provider can not be sure that the call is actually coming from the line it calls; however, the service provider can ensure that the identity of the caller specified is one of the possible ones from this BTI. AUTHID is the authorization code given to this particular BTI from the OAMP system. This is changed periodically, for example every ten minutes. CINFO is the previously encoded sequence provided by the Gate Controller, which tells the Gate Controller several pieces of information regarding the call. 7. 1.4.1 TRACE recognition If the information in the TRACE message is valid, the Gate Controller will respond with a TRACEACK message. A sample message is: TRACEACK 0S42115 vl., 0; 7. 1.4.2 TRACE error If the TRACE fails, the Controller Gateway will return an error indication to the BTI. A sample TRACENAK message is: TRACENAK 0S55072 vl.O; ERROR Authorization failed ERROR gives a sequence of error messages, which could be displayed visually if the BTI had some method to do so. Otherwise, it provides some useful debugging information. 7. 1.5 PROFILE The BTI sends a PROFILE message to its Gate Controller when the call is to be directed to a predetermined number to obtain the predetermined number. 7. 1.5.1 PROFILE recognition If the PROFILE is valid, the Gate Controller will respond with a PROFILEACK message. 7. 1.5.2 PROFILE error If the PROFILE fails, the Gate Controller will return an error indication to the BTI. A sample PROFILENAK message is: PROFILENAK 0S55072 vl.O; ERROR Failed authorization ERROR gives a sequence of error messages, which could be displayed visually if the BTI had some method to do so. Otherwise, it provides some useful debugging information. 7. 2 Gate Controller for the BTI The Gate Controller initiates messages to the BTI to inform you of incoming calls, or to inform you of a change in the status of a calling call. Messages initiated by the Gate Controller include SETUP, TRANSFER, and CALLHOLD. SETUP is used to inform the BTI of an incoming call, and to ask the BTI for the proper handling of this new call request. TRANSFER informs the BTI that a current call has been redirected to a new destination.1 CALLHOLD informs the BTI that the call has been placed on pause and to temporarily disconnect the resources used by this call. 7. 2.1 SETUP The Gate Controller informs a BTI of a call request that enters with a SETUP message. A sample message is: SETUP 4T93182 vl.O; DEST 9733608766; CALLER 9733608718; CRV 21; SIGADDR 10.0.0.1:4722; DATAADDR . 0.0.1: 4724 2 2; CODING 53B, 6ms, G .711; GATEIP 135. 207.22.1: 7682; GATEID 21S11018; CINFO < sequence > DEST is the destination address E164, as given by the originator and expanded to a global management plan by the Gate Controller. CALLER (optional) is the identity information of the caller. This element is only present if the client has subscribed to some variant of the caller id service. If the customer has subscribed to a caller's name service as well, the second parameter will contain the name of the caller. If the originator of the call has specified blocking the caller id, the first parameter will contain "anonymous".

CRV is the Call Reference Value assigned by the destination for this call. This must be included in all BTI-BTI messages to properly identify the call. SIGADDR gives the address and port number for the destination of all BTI-BTI signaling messages. DATAADDR gives the address and port number for the destination of the voice data packets. The second parameter (optional) gives the number of consecutive ports assigned. The third parameter (optional) gives the alignment information for the port numbers. CODING specifies a list of possible encapsulations and coding methods that the originator will perform. Each parameter is at least three articles or subsections separated by commas, where the first article specifies a message size, the second article gives the interval between packages, the third article gives the coding algorithm, and the fourth and last articles (optional) ) give the additional parameters specific to the encoder. GATEIP gives the IP address and port number of the Edge Router that contains the gate that controls the access service for this connection. This is the destination address to use for all BTI-ER messages. GATEID gives the identification and authorization card assigned by the Edge Router for the gate assigned for this connection. CINFO is a coded sequence that contains the internal status information of the Gate Controller, which will be stored in the BTI and returned with any future enhanced service request related to this call, for example the 3-way call, the transfer of call, etc. 7. 2.1.1 SETUP recognition If the BTI wants to accept the incoming call, specified in the SETUP message, it responds with SETUPACK. A sample SETUPACK message is: SETUPACK 4T93182 vl.O; CRV 2712; SIGADDR kkrama-bti: 7685; DATAADDR kkrama-bti: 7000 2 2; CODING 53B, 6ms, G.711 CRV is the Call Reference Value assigned by the BTI for this call. This is the value that will appear in all BTI-BTI messages to identify the specific call instance. SIGADDR is the address and port number where the BTI will listen to the BTI-BTI signaling messages. DATAADDR is the address and port numbers where the BTI will accept the voice data packets. The second parameter indicates the number of consecutive ports and the third parameter gives the necessary alignment if the part numbers are moved by a PAT server. CODING is the style of encapsulation and the coding method chosen, from those offered. 7. 2.1.2 SETUP error If the BTI does not want to accept the incoming call, it responds with SETUPNAK. A sample SETUPNAK message is: SETUPNAK 4T93182 vl.O; ERROR Busy; FORWARD E164 8800 ERROR gives a sequence of error messages, which could be displayed visually if the Gate Controller had some method to do so, and it can be passed back to the source BTI in a SETUPNAK message. FORWARD gives the new destination to which the call should be directed, as a result of the call forwarding algorithm implemented within the BTI. The structure of this element is identical to that of the DEST element of the BTI-GC SETUP message. 7. 2.2 TRANSFER TRANSFER messages are used by the Gate Controller to inform the BTI of a change in the destination of an existing call. The BTI must alter some parameters of destination, to communicate with this new destination. A message TRANSFER sample is: TRANSFER 0T5087 vl.O; CRV 21; REMCRV 1025; SIGADDR 135.207.31.3:6026; DATAADDR 135.207.31.3:6028 2; CODING 53B, 6ms, G .711; ROLE orig; CINFO < sequence > CRV gives the Reference Value of the Call, of the call that has been transferred. This parameter is intended to help the BTI determine the appropriate adjustments.

REMCRV is the Reference Value of the Call, assigned by the party at the other end of the call. This value must be used in all BTI-BTI communication. SIGADDR is the IP address and port for the BTI-BTI signaling messages to the other endpoint. DATAADDR is the IP address and the UDP port specification for the voice data packets. The second parameter, if present, gives the number of consecutive port numbers assigned for this connection. The third parameter, if present, says any necessary alignment for the port numbers. CODING tells the encapsulation scheme and the coding method to be used for this connection. ROLE says if the BTI should consider itself the originator or the terminator of this conversation. CINFO is a coded sequence of information regarding the other end of the conversation, to be stored in the BTI, for use for future enhanced services that may be required. 7. 2.2.1 Recognition TRANSFER If the BTI is able to identify the call given in the TRANSFER message, its internal state is adjusted, and resources are assigned to the new destination, which responds with TRANSFERACK. A sample TRANSFERACK message is: TRANSFERACK 0T5087 vl.O; 7. 2.2.2 TRANSFER error If the BTI does not want to accept the transferred call, it responds with TRANSFERNAK. A sample TRANSFERNAK message is: TRANSFERNAK 0T5087 vl.O; ERROR Reservation of resources to the new failed destination ERROR gives a sequence of error messages, which could be displayed visually if the Gatekeeper had some method to do so, and can be passed back to the originating system in a NAK message. 7. 2.3 CALLHOLD The BTI must be placed on pause while the gate adjustments are made. In most cases this is handled by the BTI-BTI HOLD message. In some situations, this must be done by the Gate Controller, and is done by issuing CALLHOLD messages. A sample CALLHOLD message is: CALLHOLD 2T10477 vl.O; CRV 21 CRV is the Call Reference Value assigned by the BTI for this conversation. 7. 2.3.1 Recognition CALLHOLD After the BTI has placed itself in a paused state, it responds with CALLHOLDACK. A sample CALLHOLDACK message is: CALLHOLDACK 2T10477 vl.O; 7. 2.3.2 CALLHOLD error If the BTI is unable to process the HOLD request, it responds with CALLHOLDNAK. A sample CALLHOLDNAK message is: CALLHOLDNAK 2T10477 vl.O; ERROR Illegal Call Reference Value ERROR gives a sequence of error messages, which could be displayed visually if the Gate Controller had some method to do so, and can be passed back to the originating system in a NAK message. 7. 3 BTI to Edge Router Resource allocation messages are exchanged between the BTI and the Edge Router for reservation and disconnection of network resources. These messages all have a reference to a "Gateway", which must have been initialized by a Gate Controller before the BTI resource reservation request. Messages initiated by the BTI include RESERVE, COMMIT, RERESERVE, RECOMMIT, RELEASE, HOLD and KEEPALIVE. RESERVE is the first normal step in the reservation protocol, where it asks for an allocation of resources but does not require that they be assigned. COMMIT asks for the effective allocation of resources to this conversation. RERESERVE is used in cases where the BTI already has some resources, either reserved or committed to it and wishes to use them to satisfy this new request. RECOMMIT serves a similar function when resources are going to be committed to this new connection. RELEASE is the indication of the BTI that a connection should be terminated. HOLD tells the Edge Router that the voice data stream is temporarily stopped, and to stop the periodic checking of the data stream, but to keep the resources as they are reserved. KEEPALIVE is sent periodically in the maintained or paused state, to the Edge Router, to maintain the resource reservation; A lack of keepalives (keep alive) indicates a call termination (probably undesirable). 7. 3.1 RESERVE The RESERVE message is sent by the BTI in the first stage of resource allocation. A sample message RESERVE is: RESERVE 0S55073 vl.O; GATEID 17S63224; BANDWIDTH 53B, 6ms GATEID is the identification of the gate, as assigned by the Edge Router. Included in this sequence is the security authorization that indicates that the sender is authorized to perform operations on this gate. BANDWIDTH is the specification of the effective bandwidth desired at this time. This is specified as the packet size, in bytes, and the inter-packet interval. This value is compared to the value (for example, in bits per second) by the Gate Controller in the GATEETUP message. 7. 3.1.1 Acknowledge RESERVE If the resource reservation is successful, which means that the bandwidth is available upstream and downstream in the access network, and the bandwidth is available in the Forward direction in the main network, the Edge Router responds with a RESERVACK message. A sample message is: RESERVEACK 0S55073 vl.O; 7. 3.1.2 RESERVE error If the resource reservation fails, the Edge Router responds with a RESERVENAK message. A sample message is: RESERVENAK 0S55073 vl.O; ERROR No upstream capacity available ERROR gives a sequence of error messages, which could be displayed visually if the BTI had some method to do so, or it can simply result in a fast busy signal. 7. 3.2 COMMIT The COMMIT message is sent by the BTI in the second stage of resource allocation. Upon receipt of a COMMIT message, the Edge Router resets the gate timer to a smaller interval (for example, approximately 2 seconds). If that chronometer expires before it is sent COMMITACK, the gate is finished. A sample COMMIT message is: COMMIT 0S55074 vl.O; GATEID 17S63224; BANDWIDTH 53B, 6ms GATEID is the identification of the gate, as assigned by the Edge Router. Included in this sequence is the security authorization that indicates that the sender is authorized to perform operations on this gate.

BANDWIDTH is the specification of the effective bandwidth desired at this time. This is specified as the packet size, in bytes, and the inter-packet interval. This value is compared to the value (for example, in bits per second) by the Gate Controller in the GATEETUP message. 1. 3.2.1 COMMIT recognition If the allocation of resources is useful, which means that the bandwidth has been allocated in the access network (for example via unsolicited grants), and the Edge Router has successfully coordinated with its Remote Edge Router in the other end of the call, the Edge Router responds with a COMMITACK message. A sample message is: COMMITACK 0S55074 vl. O; 1. 3.2.2 COMMIT error If the resource allocation fails, or the coordination with the remote gate does not complete within the allocated interval, the Edge Router responds with a COMMITNAK message. This is intended to be a very rare event, since it results in the caller hearing a first ringing tone, then becoming a fault tone. Such call defects are limited by the description of the service to only a few completed calls per million, although the deliberate cases of fraud that cause this error are not counted. A sample message is: COMMITNAK 0S55074 vl.O; ERROR Gate coordination failure ERROR gives a sequence of error messages, which could be displayed visually if the BTI had some method to do so, or it can simply result in a busy, fast signal. 7. 3.3 RERESERVE The RERESERVE message is sent by the BTI in the first stage of resource allocation when the BTI has a current assignment that the new connection will be reused. See Section 2 for information regarding the two-stage resource allocation scheme. A sample RERESERVE message is: RERESERVE 0S42110 vl.O; GATEID 5S71731; PREVGATEID 21S11018; BANDWIDTH 53B, 6ms GATEID is the identification of the gate, as assigned by the Edge Router. Included in this sequence is the security authorization that indicates that the sender or sender is allowed to perform operations on this gate. PREVGATEID is the identification of a compromised, existing gate, whose resources will be reused in the current connection. BANDWIDTH is the specification of the effective bandwidth desired at this time. This is specified as the packet size, in bytes, and the inter-packet interval. This value is compared to the value (for example, in bits per second) by the Gate Controller in the GATEETUP message. 7. 3.3.1 Recognition RERESERVE If the re-reservation of resources is successful, which means that the bandwidth is available upstream and downstream in the access network, and the bandwidth is available in the forward direction in the main network, the Router of Borde responds with a RERESERVACK message. A sample message is: RESERVEACK 0S42110 vl.O; 7. 3.3.2 RERESERVE error If the re-reservation of resources fails, the Edge Router responds with a RERESERVENAK message. A sample message is: RERESERVENAK 0S42110 vl.O; ERROR Illegal gateway identifier ERROR gives a sequence of error messages, which could be displayed visually if the BTI had some method to do so, or simply results in a fast busy signal. 7. 3.4 RECOMMIT The RECOMMIT message is sent by the BTI in the second stage of resource allocation when a previous assignment is going to be reused. See Section 2 for information regarding the two-stage resource allocation scheme. Upon receipt of a RECOMMIT message, the Edge Router resets the gate timer to a smaller interval (for example, approximately 2 seconds). If that timer expires before RECOMMITACK is sent, the gate is terminated. A RECOMMIT sample message is: RECOMMIT 0S42111 vl.O; GATEID 5S71731; PREVGATEID 21S11018; GATEID is the identification of the gate, as assigned by the Edge Router.

Included in this sequence is the security authorization that indicates that the sender or sender is allowed to perform operations on this gate. PREVGATEID is the identification of a compromised, existing gate, whose resources can be reused in the current connection. BANDWIDTH is the specification of the effective bandwidth desired at this time. This is specified as the packet size, in bytes, and the inter-packet interval. This value is compared to the value (for example, in bits per second) by the Gate Controller in the GATEETUP message. The value given in the COMMIT may be no greater than that of the value in the RESERVE message. 7. 3.4.1 Recognition of RECOMMIT If the allocation of resources is successful, which means that the bandwidth has been allocated in the access network (for example, via unsolicited grants), and the Edge Router has successfully coordinated with its Remote Edge Router in At the other end of the call, the Edge Router responds with a RECOMMITACK message. A sample message is: RECOMMITACK 0S42111 vl.O; 7. 3.4.2 RECOMMIT error If the resource allocation fails, or the coordination with the remote gate does not complete within the allotted range, the Edge Router responds with a RECOMMITNAK message. HE it pretends that this is a very infrequent event, since it results in the caller who hears a first ring tone, then becomes a fault tone. Such call defects are limited by the description of the service to only a few completed calls per million, although deliberate cases of fraud that cause this error are not counted. A sample message is: RECOMMITNAK 0S42111 vl.O; ERROR Gate coordination failure ERROR gives a sequence of error messages, which could be displayed visually if the BTI had some method to do so, or it can simply result in a fast busy signal. 7. 3.5 RELEASE The BTI sends the message RELEASE to the Edge Router when the call has been completed, and the resources are to be disconnected and billing stops. A sample message is: RELEASE 0S55075 vl.O; GATEID 17S63224 GATEID is the identification of the gate that was assigned for this conversation, and which now has to be disconnected. 7. 3.5.1 Recognition of RELÉASE The Edge Router always responds to a message RELEASE with RELEASEACK. If a gateway existed with the indicated identification, then it is closed, its resources are disconnected, a billing event is generated, and a GATECLOSE message is sent to the corresponding Edge Router at the other end of the connection. A sample message is: RELEASEACK 0S55075 vl.O; 7. 3.5.2 RELEASE error The Edge Router always responds to a RELAY with a RELEASEACK. There are no generated error indications. If the gate identification does not exist, the Edge Router assumes that the gate has already been closed by the remote end. 7. 3.6 HOLD If the BTI wishes to place a paused call, it must inform the Edge Router that its upstream data stream will stop. Otherwise, the Edge Router will interpret the lack of data as an indication to hang up and terminate the call. This is done by a HOLD message. A sample message is: HOLD 0S55090 vl.O; GATEID 17S63224 GATEID is the identification of the gate, as assigned by the Edge Router.

Included in this sequence is the security authorization that indicates that the sender or sender is allowed to perform operations on this gate. 7. 3.6.1 HOLD recognition If the pause operation is successful, which means that the bandwidth has been placed back into the pool of reserved but not yet committed, the Edge Router responds with a HOLDACK message. A sample message is: HOLDACK 0S55090 vl.O; 7. 3.6.2 HOLD error If the pause operation fails, the Edge Router responds with a HOLDNAK message. A sample message is: HOLDNAK 0S55090 vl.O; ERROR the gateway is not committed yet ERROR gives a sequence of error messages, which could be displayed visually if the BTI had some method to do so, or it can simply result in a fast busy signal. 7. 3.7 KEEPALIVE While there is a paused connection, it is necessary for BTI to periodically inform the Edge Router that it will still be alive and healthy, and that the reservation must be maintained. The lack of any traffic from the BTI is taken as evidence that the BTI has failed, or that some access component has failed and that the BTI is unable to request a call termination. The safe strategy is to end the call, instead of possibly charging the client for an interruption prolonged service. A sample message KEEPALIVE is: KEEPALIVE 21C3972 vl.O; GATEID 17S63224 GATEID is the identification of the gate, as assigned by the Edge Router. Included in this sequence is the security authorization that tells the sender or sender that they are allowed to perform operations on this gate. There is no error control or retransmission of KEEPALIVE messages. The interval between them is engineered to minimize the chances of false error detection. 7. 4 Border Router to BTI Messages are not initiated by the Edge Router. 7. 5 BTI to BTI There are several end-to-end messages that are exchanged in any signaling system, which are used to coordinate the state of the two extreme points in the consistent service provision. In the embodiments of the present invention ,. these are implemented as BTI-BTI signaling messages that are sent directly between the two BTIs involved in the conversation. These are formatted such that they can be processed by the same subroutines as the other messages. Messages exchanged between BTIs include RING, RINGBACK, CONNECT, HANGUP, HOLD and RINGTIMEOUT. RING is sent from the originator to the destination to indicate that everything looks ready and that the destination should ring the phone. RINGBACK is sent from the destination to the originator to indicate that the phone is ringing. CONNECT is sent from the destination to the originator when the called party answers the phone, or immediately after the reception of RING is that the called party is ready. HOLD is sent from any BTI to the other to indicate that the call will be placed on pause and to disconnect any currently held real-time resources. HANGUP and RINGTIMEOUT are information messages to indicate the status information that the BTI will receive by other mechanisms as well. 7. 5.1 RING The RING message is sent by the originating BTI when it has received the acknowledgment from its Edge Router that the resources are available for the call, and therefore it is the time to alert the destination user. A sample message is: RING 3712 vl.O; CRV 3712 CRV (optional) is the Reference Value of Call assigned by the destination BTI. This should appear in the message, but it can appear as either a transaction identifier, or as a separate element. The RING acknowledgment is either RINGBACK or CONNECT, not a separate RINGACK message. 7. 5.2 RINGBACK When a terminating BTI has completed the resource reservation sequence and received a RING message from the originating BTI, its appropriate response is either RINGBACK or CONNECT. RINGBACK is sent if the destination is not ready to receive the call yet, and the BTI is ringing the phone. CONNECT means that the destination is now ready, and that ringing sound is not needed (for example, - a voice response system). A sample message is: RINGBACK 21 vl.O; CRV 21; SOURCE local; TYPE waiting for CRV call (optional) is the Call Reference Value assigned by the originating BTI. This should appear in the message, but it can appear either as the transaction identifier, or as a separate element. SOURCE (optional) specifies whether the audible signal tone will be generated locally by the originating BTI, or whether the destination will generate the tone using the data stream. Due to the resource reservation scheme, SOURCE specified as "remote" can only appear when the destination is a trusted network element that does not need a gate to control access to the network. If not specified, the ringback tone is generated locally by the BTI. TYPE (optional) specifies one of several possible ringing audio sequences. The "wait for call" parameter value means the special tone sequence indicated by the call waiting alert signal that has been given. If the parameter is not given, or is not understood, it is defaulted to "normal". There is no explicit recognition in RINGBACK. However, if the originating BTI does not receive RINGBACK or CONNECT in response to its RING message, it will retransmit the RING until a response is received. 7. 5.3 CONNECT The CONNECT message is sent by the terminating BTI when the user has answered and the connection must be established. A response message is: CONNECT 21 vl.O; CRV 21 CRV (optional) is the Reference Value of Call assigned by the origin BTI. This should appear in the message, but it can appear either as the transaction identifier, or as a separate element. The recognition of the CONNECT message occurs via the COMMIT / COMMITACK exchange with the Edge Router. 7. 5.4 HANGUP This is an information message that is sent by any BTI to the other to indicate that the user is terminating the connection. A sample message is: HANGUP 3712 vl.O; CRV 3712 CRV (optional) is the Reference Value of Call assigned by the origin BTI. This should appear in the message, but it can appear either as the transaction identifier, or as a separate element. There is no recognition of the HANGUP message. There are multiple independent mechanisms that determine that a call has been completed and billing will end; since the system must recover from access link failures, failures in the BTI hardware / hardware (hardware / software), and power failures, each of which can prevent the BTI from sending the message of HANGUP. Therefore, its use is not critical. 7. 5.5 HOLD If the BTI expects to place a current call on pause, it must inform the other endpoint that its input data stream will stop. Otherwise, the other endpoint will interpret the lack of data as an indication to hang up and the call will end. This is done by a HOLD message. A sample message is: HOLD 21 vl.O; CRV 21 CRV (optional) is the Call Reference Value assigned by the originating BTI. This should appear in the message, but it can appear either as the transaction identifier, or as a separate element. Note that before stopping the data stream, the BTI must also inform its Edge Router that the data stream will stop, even the Edge Router will terminate the call. This is done via a BTI-ER HOLD message. 7. 5.5.1 HOLD recognition When a BTI has received a HOLD message from the other endpoint, it adjusts its threshold to Consider the dead connection, and respond with recognition. This message is: HOLDACK 3712 vl.O; CRV 3712 CRV (optional) is the Call Reference Value assigned by the originating BTI. This should appear in the message, but it can appear either as the transaction identifier, or as a separate element. 7. 5.6 RINGTIMEOUT This is an information message that is sent by the termination BTI to the originator, to indicate that the user has not responded within the interval they configured, and that the call will be sent. A sample message is: RINGTIMEOUT 3712 vl.O; CRV 3712 CRV (optional) is the Reference Value of Call assigned by the origin BTI. This should appear in the message, but it can appear either as the transaction identifier, or as a separate element. There is no error recovery for this message. This is information only, and it is used to tell the originating BTI to stop the tone of call signal, and that a transfer is imminent. Without this message the originating BTI will still receive a TRANSFER message from the Gate Controller and will handle the call in the same way. 7. 5.7 KEEPALIVE While there is a paused connection, it is necessary that the BTI periodically report its BTI peer that it is still alive and healthy, and that the connection must be maintained. The lack of any traffic from the BTI is taken as evidence that the BTI has failed, and that some access component has failed and that the BTI is unable to request a call termination. The security strategy is to terminate the call instead of possibly charging the customer for a prolonged service interruption. A sample message KEEPALIVE is: KEEPALIVE 3712 vl.O; CRV 3712 CRV (optional) is the Call Reference Value assigned by the originating BTI. This should appear in the message, but may appear either as the transaction identifier, or as a separate element. There is no error control or retransmission of KEEPALIVE messages. The interval between them is engineered to minimize the chances of detecting false errors. 7. 6 Gate Controller to the Edge Router The protocol between the Controller Gate and Edge Router is for resource control purposes and resource allocation policy. The Gate Controller implements all allocation policies, and uses that information to manage the group of gates implemented in the Edge Routers. The Gatekeeper initializes the gates with the specific source, destination and bandwidth constraints; once the BTI is initiated, it is able to request resource assignments within the limits imposed by the Gate Controller. Messages initiated by the Gate Controller include GATEALLOC, GATESETUP, GATEMODIFY, GATERELEASE, and GATEINFO. GATEALLOC assigns a new gate identifier. GATESETUP initializes all traffic and policy parameters for the gate, and adjusts billing information. GATEMODIFY is used to change any or all parameters of an existing gate. GATERELEASE signals the end of the connection, and that the gate and all its resources can be made available to any other applicant. GATEINFO is a mechanism through which the Gate Controller can find all the current status and parameter settings of an existing gate. 7. 6.1 GATEALLOC A GATEALLOC message is sent by the Gate controller to assign a new gate, and establish a gate identity (GateID), but without adjusting any of the specific parameters necessary for the gate operation. A GATEETUP must come later with the operating parameters. Upon receipt of a GATEALLOC, the Edge Router will start a stopwatch (for example, approximately 120 seconds), and if the gate has not entered the state of "commitment" in that time, it is released. A sample message GATEALLOC is: GATEALLOC 4T93176 vl.O; OWNER wtm-bti: 7685 OWNER specifies the name of the client this gateway will serve. 7. 6.1.1 GATEALLOC recognition A sample message from GATEALLOC is: GATEALLOCACK 4T93176 vl.O; GATEID 17S63224; CUSTUSAGE 3 GATEID is the sequence that identifies the gate that was assigned. This consists of at least two parts, with some separator (specific to the edge router) between them: the identity of the gate that was assigned, and a security code that must be given to the Edge Router in order to make any changes in the gate parameters. CUSTUSAGE tells the Controller Gate the number of simultaneous gates that the client currently has. This is calculated by a scan of all the current gates, comparing the OWNER parameter. If the number of gates assigned to a customer is inconsistent with the subscribed service, the Gate Controller can take the appropriate action. 7. 6.1.2 GATEALLOC error Errors in the allocation gates are reported by a GATEALLOCNAK message. A sample is: GATEALLOCNAK 4T93176 vl.O; ERROR No gates available ERROR gives a sequence of error messages, which could be displayed visually if the gate controller had some method to do so, and can be passed back to the BTI in a SETUPNAK message. 7. 6.2 GATESETUP The GATEETUP message is sent by the gate controller to the Edge Router to initialize the operational parameters of the gate. A sample GATEETUP message is: GATESETUP 4T93181 vl.O; OWNER kkrama-bti: 7685; SRCIP 10.3.7.151; DESTIP 10.0.0.1:4724; BANDWIDTH 53B, 6ms, G .711 ROLE term; REMGATEIP 135.207.31.1:7682; REMGATEID 17S63224; REFID 135.207.31.2:3612E5C:93178; BILLDATA 5123-0123-4567-8900 / 9733608718/9733608766 OWNER (optional) gives the name of the customer this gateway will serve. If this parameter is not given, then GATEID is mandatory. GATEID (optional) gives the sequence that identifies the gate, with the security code. If this parameter is not given, then OWNER is mandatory, and a new gate will be assigned. SRCIP identifies the IP address of the source that will appear in all data packets that go through the gate. Note that the source port number is not specified, and is not generally known or always constant. DESTIP is the destination IP address that will appear in the IP header, and the destination UDP port number that will appear in the UDP header. only the packages that match the IP Source / Destination IP / Destination Port will obtain the highest Quality of Service provided by the gateway.

BANDWIDTH specifies the maximum bandwidth that can be required through this gate. Although the parameter includes the coding style, it is not used by the gate. ROLE specifies whether the Edge Router is the originating or terminating side of this conversation. This is important only if the main reservation is bidirectional, and only one of the Border Routers needs to make the reservation. REMGATEIP is the address of the Edge Router at the other end of this connection. All ER-ER gate coordination messages have to be sent to this address and port. REMGATEID is the identity of the gate at the other end of the connection. REFID is the unique sequence that will appear in the billing records for this conversation. BILLDATA is the charge information that will appear in the billing records for this conversation. 7. 6.2.1 GATESETUP recognition A sample message GATESETUPACK is: GATESETUPACK 4T93181 vl.O; GATEID 21S11018; CUSTUSAGE 1 GATEID is the sequence that identifies the gate that was assigned. This consists of at least two parts, with some separator (specified in the edge router) between them: the identity of the gate that was assigned, and a security code that must be given to the Edge Router in order to effect any change in the parameters of the gate . CUSTUSAGE tells the gate controller the number of simultaneous gates the customer currently has. This is calculated by a scan of all the current gates, comparing the OWNER parameter. If the number of gates assigned to a client is inconsistent with the subscribed service, the gate controller can take the appropriate action. 7. 6.2.2 GATESETUP error Errors in the establishment of gates are reported by a GATESETUPNAK message. A sample is: GATESETUPNAK 4T93181 vl.O; ERROR No gates available ERROR gives a sequence of error messages, which could be displayed visually if the gate controller had some method to do so, and can be passed back to the BTI in a message SETUPNAK. 7. 6.3 GATEMODIFY The GATEMODIFY message is sent by the gate controller to the Edge Router to modify the operational parameters of an existing gate. A sample message GATEMODIFY is: GATEMODIFY 2T10486 vl.O; GATEID 17S63224; SRCIP 10.3.7.151; DESTIP 10.0.0.1:4724; BANDWIDTH 53B, 6ms, G.711; ROLE term; REMGATEIP 135.207.31.1:7682; REMGATEID 17S63224; REFID 135.207.31.2: 36123E5C: 93178; BILLDATA 5123-0123-4567- 8900/9733608718/9733608766 GATEID gives the sequence that identifies the gate, with the security code. SRCIP identifies the IP address of the source that will appear in all data packets that pass through the gateway. Note that the port number of the source is not specified, and this is generally unknown or always constant. DESTIP is the destination IP address and it will appear in the IP header, and the destination UDP port number that will appear in the UDP header. Only the packages that match or match the IP of the Destination Source / IP / Destination Port will obtain the highest Quality of Service provided by the gate. BANDWIDTH specifies the maximum bandwidth that can be required through this gate. Although the parameter includes the coding style, it is not used by the gate. ROLE specifies whether the Edge Router is the originating or terminating side of this conversation. This is important only if the main reservation is bidirectional, and only one of the Edge Routers needs to make the reservation. REMGATEIP is the address of the Edge Router at the other end of this connection. All the ER-ER gate coordination messages are going to be sent to this address and port. REMGATEID is the identity of the gate at the other end of the connection. REFID is the unique sequence that will appear in the billing records for this conversation. BILLDATA is the charge information that will appear in the billing records for this conversation. 7. 6.3.1 Recognition GATEMODIFY A sample message GATEMODIFYACK is: GATEMODIFYACK 2T10486 vl.O; GATEID 17S63224; CUSTUSAGE 1 GATEID is the sequence that identifies the gate that was assigned. This consists of at least two parts, with some separator (specified in the edge router) between them: the identity of the gate that was assigned, and a code of Security that must be given to the Edge Router in order to effect any change in the parameters of the gate. CUSTUSAGE tells the gate controller the number of simultaneous gates the customer currently has. This is calculated by a scan of the current gates, comparing the OWNER parameter. If the gate number assigned to a client is inconsistent with the subscribed service, the gate controller can take the appropriate action. 7. 6.3.2 GATEMODIFY error The errors in the modification of the gates are reported by a GATEMODIFYNAK message. A sample is: GATEMODIFYNAK 4T93181 vl.O; ERROR Illegal gate identification ERROR gives a sequence of error messages, which could be displayed visually if the gate controller had a method to do so, and can be passed back to the BTI in a SETUPNAK message. 7. 6.4 GATERELEASE When a Gatekeeper has transferred a connection, it sends a GATERELEASE message to the Edge Router to release any resources held by the endpoint that is not now part of the call. While the behavior is similar to a RELAY message from the BTI, it results in a different event recorded in the billing system, and this avoids normal gate coordination (since the corresponding gate at the other end of the original connection). has been redirected to another destination). A sample is: GATERELEASE 4T93181 vl.O; GATEID 17S63224 GATEID is the sequence that identifies the gate that was assigned. It consists of at least two parts, with some separator (specified by edge router) including: the identity of the gate that was assigned, and a security code that must be given to the Edge Router in order to make any changes in the parameters of the gate. ERROR gives a sequence of error messages, which could be displayed visually if the controller has a method to do so, and can be passed back to the BTI in a SETUPNAK message. 7. 6.4.1 Recognition GATERELEASE A GATERELEASE message always gives a response from GATERELEASEACK. A sample is: GATERELEASEACK 4T93181 vl.O; 7. 6.4.2 GATERELEASE error A GATERELEASE message always results in a response from GATERELEASEACK. If the GATEID parameter identifies an invalid gate, the Edge Router assumes that the gate has already been closed. 7. 6.5 GATEINFO When a Gate Controller wants to find the current parameter settings, or the current status, of a gate, it sends a GATEINFO message to the Edge Router. A sample is: GATEINFO 0T5082 vl.O; GATEID 17S63224 GATEID is the sequence that identifies the gate that was assigned. This consists of at least two parts, with some separator (specified by the edge router) between them: the identity of the gate that was assigned, and a security code that must be given to the Edge Router in order to perform any change in the parameters of the gate. 7. 6.5.1 Recognition of GATEINFO The message is sent by the Gate Controller to the Edge Router to modify the operational parameters of an existing gate. A sample GATEINFOACK message is: GATEINFOACK 0T5082 vl.O; GATEID 17S63224; STATE commit; SRCIP 10.3.151; DESTIP 10.0.0.1:4724; BANDWIDTH 53B, 6ms, G .711; ROLE term; REMGATEIP 135.207.31.1:7682; REMGATEID 17S63224; REFID 135.207.31.2: 36123E5C: 93178; BILLDATA 5123-0123-4567-8900 / 9733608718/9733608766 GATEID gives the sequence that identifies the gate, with the security code.

STATE gives the internal state of the gate, one of the following: preparation (setup), reserved (reserved), commitment (commit), or pause (hold). SRCIP identifies the IP address of the source that will appear in all data packets traveling through the gate. Note that the port number of the source is not specified, and is generally unknown or always constant. DESTIP is the destination IP address that will appear in the IP header, and the destination UDP port number that will appear in the UDP header. Only the packages that match the IP Source / Destination IP / Destination Port will obtain the highest Quality of Service provided by the gateway. BANDWIDTH specifies the maximum bandwidth that can be required through this gate. Although the parameter includes the coding style, it is not used by the gate. ROLE specifies whether the Edge Router is the originating or terminating side of this conversation. This is important only if the main reservation is bidirectional, and only one of the Border Routers needs to make the reservation.

REMGATEIP is the address of the Edge Router at the other end of this connection. All the coordination messages of the ER-ER gate will be sent to this address and port. REMGATEID is the identity of the gate at the other end of the connection. REFID is the unique sequence that will appear in the billing records for this conversation. BILLDATA is the charge information that will appear in the billing records for this conversation. 7. 6.5.2 GATEINFO error Errors in the search for gateway information are reported by a GATEINFONAK message. A sample is: GATEINFONAK 0T5082 vl.O; ERROR Illegal Gatekeeper Identification ERROR gives a sequence of error messages, which could be displayed visually if the Gatekeeper had a method to do so, and can be passed back to the BTI in a SETUPNAK message. 7. 7 Edge Router to Gate Controller Messages are not initiated by the Edge Router. 7. 8 Edge Router to Edge Router To prevent some types of theft of service fraud, it is necessary that the Edge Routers synchronize the gates at the opposite ends of a connection. In particular, a gateway that is "committed" at one end of a connection, but not at the other, can be used as a high-quality data connection, or can be used to fraudulently load a non-suspicious client for a connection prolonged Messages exchanged between the Edge Routers include GATEOPEN, and GATECLOSE. GATEOPEN is exchanged with the gate that has resources committed to it, and GATECLOSE is exchanged when those resources are disconnected. The timers within the gate implementation impose controls strict about the length of time that these exchanges can occupy. 7. 8.1 GATEOPEN The GATEOPEN message is sent by the Edge Router to its corresponding Edge Router at the other end of a connection to the reception of the COMMIT message from the BTI. A sample message is: GATEOPEN 21T6572; GATEID 17S63224; BANDWIDTH 53B, 6ms GATEID is the identification sequence for the remote gate, including the required security code. BANDWIDTH is the request for bandwidth received in the COMMIT message. 7. 8.1.1 Recognition of GATEOPEN Upon receipt of a GATEOPEN message, the Edge Router responds with a GATEOPENACK. A sample message is: GATEOPENACK 21T6572 vl.O; 7. 8.1.2 GATEOPEN error If some errors occur in the processing of a GATEOPEN, the Edge Router responds with GATEOPENNAK. Such a situation can occur when the remote gate temporarily suspends and disconnects the gate before the commitment sequence is completed. A sample message is: GATEOPENNAK 21T6572; vl.O; ERROR Invalid gate identifier ERROR gives a sequence of error messages, which could be displayed visually if the gate controller had a method to do so, and can be passed back to the BTI in a message SETUPNAK. 7. 8.2 GATECLOSE The GATECLOSE message is sent by the Edge Router to its corresponding Edge Router at the other end of a connection, upon receipt of the RELAY message from the BTI. The Edge Router disconnects any resources maintained by that gate, stops any unsolicited grants, offered over the upstream channel, and releases the gate. A sample message is: GATECLOSE 21T6583; GATEID 17S63224; GATEID is the identification sequence for the remote gate, including the required security code. 7. 8.2.1 Recognition GATECLOSE After receiving a GATECLOSE message, the Edge Router responds with a GATECLOSEACK. A sample message is: GATECLOSEACK 21T6583 vl.O; 7. 8.2.2 GATECLOSE error A GATECLOSE message always results in a response from GATECLOSEACK. If the GATEID parameter specifies an invalid gate, the Edge Router assumes that the gate has already been closed. 7. 9 Gate Controller to Gate Controller Messages exchanged between Gate Controllers include GCSETUP GCREDIRECT, and GCSPLICE. All occur in situations where the Gate Controller realizes that it can not complete a request due to the destination being served by a different Gate Controller. These messages pack the entire internal state, ask the remote Gate Controller to complete the desired function, then respond with updated status information. In a Gate Controller implementation it is likely that these messages will exist in an internal way to share the implementation of termination services. 7. 9.1 GCSETUP The GCSETUP message is exchanged between the Gate Controllers when different Gate controllers serve the originating and terminating endpoints of a call. This is basically formed by the packaging of all the partial state information that the Gate Controller has assembled, and requires the Gatekeeper Controller to complete the work necessary to initiate the connection. A sample message GCSETUP is: GCSETUP 4T93177 vl.O; DEST E164 9733608766; CALLER 9733608718 Bill Marshall; CRV 21; SIGADDR 135.207.31.1:6000; DATAADDR 135.207.31.1:6002 2 2; REMGATEIP 135. 207.31.1: 7682; REMGATEID 17S63224; CODING 53B, 6ms, G.711; REFID 135. 207.31.2: 36123E5C: 93178; BILLDATA 5123-0123-4567- 8900/9733608718/9733608766; CINFO 135.207.31.2:7650/135.207.31.1:7682/17S63224/10.0.12.221: 7685 / 10.0.12.221.-7000-2-2 / 9733608718/21 / 10.0.12.221:7685 DEST is the destination address for this connection . Its format is the same as in the SETUP message received from the BTI, except that the E164 number, if present, is expanded from the plan. local numbering of the client to the global numbering plan. CALLER is the identity of the caller and the name of the caller of the originator of the connection. From the SETUP message received from the BTI, the originating Gate Controller expanded the E164 number to a global numbering plan, and searched for the name of the caller. CRV is the Call Reference Value assigned by the originating BTI, copied from the SETUP message. SIGADDR is the IP address and port number of the destination to be used for BTI-BTI signaling messages. This is a global version of the address given in the SETUP message from the BTI, with the name for the translation of the given IP address, and with any NAT / PAT server translation included. DATAADDR is the IP address and port number that the destination must use for the data packets. This is a global version of the address given in the SETUP message from the BTI, with the translation of name and IP address made, and with any translation of the included NAT / PAT server. The second and third parameters (optional) in this element give the number of consecutive ports used, and the necessary alignment information for the start port number. REMGATEIP is the IP address and port number of the Edge Router that contains the gate that will be used for this conversation. This is the destination address for all ER-ER communication. REMGATEID is the gate identifier and the security code for the gateway within that Edge Router. CODING is the encapsulation methods offered and the coding styles offered by the originator of the call. REFID is a unique identifier assigned by the originating Gate Controller, which will appear in all Billing Registries. The REFID is intended to be unique within a period of several months. BILLDATA is the billing / accounting data that indicates the charge arrangement for this conversation. CINFO is a sequence generated by the originating Gate Controller that contains all the information needed for future enhanced services, which may involve the originator of the call. This will be coded and given to the destination BTI to store. The format is a list of many articles or subsections separated by hyphens, or of which the first is the IP address and port of the Gate Controller that constitute the sequence. Subsequent items or subsections in this sequence include the address / port of the Edge Router, the gate identifier, the signaling endpoint address, the data endpoint address, the reference value of the originator call, and the originator address for the initial call signaling. 7. 9.1.1 GCSETUP recognition When the termination gate controller has completed the call, it packs all its assembled status information and passes it back to the source gate controller in the GCSETUPACK message. A sample GCSETUPACK message is: GCSETUPACK 4T93177 vl.O; CRV 3712; SIGADDR 135.207.22.1:6142; DATAADDR 135.207.22.1:6146 2 2; REMGATEIP 135.207.22.1:7682; REMGATEID 21S11018; CODING 53B, 6ms, G .711; CINFO 135.207.31.2: 7650 / 135.207.22.1: 7682 / 21S11018 / 10.3.7.151: 7685 / 10.3.7.151: 7000-2-2 / 9733608766/3712 / 10.3.7.151: 7685 CRV is the Call Reference Value assigned to the destination BTI for this conversation. This is passed transparently from the SETUPACK message from the destination BTI. SIGADDR is the IP address and port number that the originator must use for BTI-BTI signaling messages. This is a global version of the address given in the SETUPACK message from the terminating BTI, with the translation of name to IP address made, and with any NAT / PAT server translation included. DATAADDR is the IP address and the port number that the originator should use for the data packets. This is a global version of the version given in the SETUPACK message from the termination BTI, with the translation of name and IP address made, and with any translation of NAT / PAT server included. The second and third (optional) parameters in this element give the number of consecutive ports used, and the necessary alignment information for the start port number. REMGATEIP is the IP address and port number of the Edge Router that contains the gateway that will be used at the conversation endpoint for this conversation. This is the destination address for all ER-ER communication. REMGATEID is the gate identifier and the security code for the gateway within that Edge Router. CODING is the encapsulation method and the coding style accepted by the call destination. REFID (optional) is a unique identifier assigned by the Gate Controller, which will appear in all Billing Registries. The REFID is intended to be unique within a period of several months. If this parameter appears, it will override the REFID assigned by the originating Gate Controller. BILLDATA (optional) is the billing / accounting data that indicates the arrangement of charge for this conversation. If this parameter appears, it will override the BILLDATA assigned by the originating Gate Controller. CINFO is a sequence generated by the Termination Gateway Controller that contains all the necessary information for future enhanced services that may involve the termination BTI. This will be coded and given to the source BTI to store. The format is a list of many articles or subsections separated by hyphens, or of which the first is the IP address and port of the Gate Controller that constitute the sequence. Subsequent items or subsections in this sequence include the address / port of the Edge Router, the gate identifier, the signaling endpoint address, the data endpoint address, the reference value of the destination call, and the destination address for the initial call signaling. 7. 9.1.2 GCSETUP error If the Termination Gateway Controller encounters an error while completing a connection request, it responds to the Source gate controller with a GCSETUPNAK message. A sample message is: GCSETUPNAK 4T93177 vl.O; ERROR No gates available ERROR gives a sequence of error messages, which could be displayed visually if the Gatekeeper had a method to do so, and can be passed back to the BTI in a SETUPNAK message. 7. 9.2 GCREDIRECT The GCREDIRECT message is exchanged between the Gate Controllers when different Gate Controllers serve the endpoints of origin and termination of a call. This is basically formed by the packing of all the partial state information that the first Gate Controller has assembled in its processing of a REDIRECT message, and which requires the Gatekeeper Controller to complete the work necessary to redirect the connection. A sample GCREDIRECT is: GCREDIRECT 0T5081 vl.O; DEST E164 9733608800; BILLDATA 5123-0123-4567- 8900/9733608718/9733608800; CINFO 135.207.31.2: 7650 / 135.207.31.1: 7682 / 17S63224 / 10.0.12.221: 7685 / 10.0.12.221: 7000-2-2 / 9733608718/21 / 10.0.12.221: 7685 DEST is the destination address for this new connection . Its format is the same as in the SETUP message received from the BTI, except that the E164 number, if present, is expanded from the customer's local numbering plan to the global numbering plan. BILLDATA is the billing / accounting data that indicates the arrangement or agreement of charges for the additional segment of this connection. CINFO is a sequence generated by the originating Gate Controller that contains all the necessary information for future enhanced services that may involve the originator of the call. This will be coded and given to the destination BTI to store. The format is a list of many articles separated by hyphens, of which the first is the IP address and the Gate Controller port that constitute the sequence. Subsequent items in this sequence include the address / port of the Edge Router, the gate identifier, the signaling endpoint address, the data endpoint address, the reference value of the originator call, and the address of the originator for the initial call signaling. 7. 9.2.1 Recognition GCREDIRECT If the Termination Gateway Controller is capable of successfully processing a GCREDIRECT request, it responds with a GCREDIRECTACK message. A sample message is: GCREDIRECTACK 0T5081 vl.O; REMGATEIP 135.207.22.1:7682; REMGATEID 21S11018 REMGATEIP is the IP address and port number of the Edge Router that is maintaining a gateway for the previous connection that has now been redirected. REMGATEID is the identification sequence for the gate in that Edge Router for the previous connection. 7. 9.2.2 GCREDIRECT error If the Termination Gateway Controller encounters an error while a redirection request is completed, it responds to the originating Gateway Controller with a message GCREDIRECTNAK A sample message is: GCREDIRECTNAK 0T5081 vl.O; ERROR No gates available ERROR gives a sequence of error messages, which could be displayed visually if the Gatekeeper had a method to do so, and can be passed back to the BTI in a NAK message. 7. 9.3 GCSPLICE If the Gate Controller that receives a SPLICE request from a BTI is not the one that generated the CINFOl sequence, it sends a GCSPLICE message to the Gate Controller. A sample message of this type is: GCSPLICE 7T1019 vl.O; CINFOl 135.207.31.2: 7650 / 135.207.22.1: 7682 / 9S1077 / 10.3.7.151: 7685 / 10.3.7.151: 7006-2-2 / 9733608766/3746 / 10.7.151: 7685; CINF02 135.207.31.2: 7650 / 135.207.22.1: 7682 / 5S71731 / 10.3.7.150: 7685 / 10.3.7.150: 7000-2-2 / 9733608720/8839 / 10.3.7.150: 7685 If the Gate Controller receives the request for The previous GCSPLICE is not the one that generated the sequence CINF02, the latter sends another GCSPLICE message to that third Gate Controller. A sample message of this second type is: GCSPLICE 7T1021 vl.O; CINF02 135.207.31.2: 7650 / 135.207.22.1: 7682 / 5S71731 / 10.3.7.150: 7685 / 10.3.7.150: 7000-2-2 / 9733608720/8839 / 10.3.7.150: 7685; SIGADDR 135.207.22.1:6162; DATAADDR 135.207.22.1:6164 2 2; CRV 3746; REMGATEIP 135.207.22.1:7682; REMGATEID 9S1077; CODING 53B, 6ms, G.711; REFID 135. 207.31.2: 26124C90: 7224; BILLDATA 6010-0203-0456- 7890/9733608766 / BRIDGE; CINFO 135.207.31.2:7650/135.207.22.1:7682/9S1077/ . 3.7.151: 7685 / 10.3.7.151: 7006-2-2 / 9733608766/3746 / . 3.7.151: 7685 CINFOl is the sequence previously supplied by the Gate Controller, which tells that Gate Controller various pieces of information regarding the first end point. This sequence was stored encoded by the BTI that originated the SPLICE request. Any CINFOl must be present in the message, or the group of fields that are determined from the Gateway Controller that unpacks CINFOl: SIGADDR, DATAADDR, CRV, REMGATEIP, REMGATEID, CODING, REFID and BILLDATA. With these fields present, the CINFOl sequence is coupled as CINFO. CINF02 is the sequence previously supplied by a Gate Controller, which tells that Gate Controller various pieces of information regarding the second end point. This sequence was stored encoded by the BTI that originated the SPLICE request. SIGADDR is the IP address and port number that the second endpoint should use for BTI-BTI signaling messages. This is a global version of the address given in the SETUP / SETUPACK message from the first point BTI final, with the translation of name to IP address made, and with any NAT / PAT server translation included. DATAADDR is the IP address and the port number that the second endpoint should use for the data packets. This is a global version of the address given in the SETUP / SETUPACK message from the first BTI endpoint, with the translation of name and IP address made, and with any NAT / PAT server translation included. The second and third parameters (optional) in this element give the number of consecutive ports used, and the necessary alignment information for the start port number. REMGATEIP is the IP address and the port number of the Edge Router that contains the gate that will be used at the end of the first BTI for this conversation. This is the destination address for all ER-ER communication. REMGATEID is the gate identifier and the security code for the gateway within that Edge Router. CODING is the method of encapsulation and coding style accepted by the first BTI.

REFID is a unique identifier assigned by the originating Gate Controller, which will appear in all Billing Registries. The REFID is intended to be unique within a period of several months. BILLDATA is the billing / accounting data that indicates the charge arrangement for this conversation. CINFO is a sequence generated by the originating Gate Controller that contains all the information necessary for future enhanced services, which may involve that BTI. This will be coded and given to the other BTI to store. The format is a list of many articles or subsections separated by hyphens, or of which the first is the IP address and port of the Gate Controller that constitute the sequence. Subsequent items or subsections in this sequence include the address / port of the Edge Router, the gate identifier, the signaling endpoint address, the data endpoint address, the reference value of the destination call, and the destination address for the initial call signaling. 7. 9.3.1 Recognition of GCSPLICE If the Termination Gateway Controller is capable of successfully processing a GCSPLICE request, it responds with a GCSPLICEACK message. If the GCSPLICE request was of the first type mentioned above, a sample recognition message is: GCSPLICEACK 7T1019 vl.O: If the GCSPLICE request was of the second type mentioned above, a sample recognition message is: GCSPLICEACK 7T1021 vl.O; SIGADDR 135.207.22.1:6166; DATAADDR 135.207.22.1:6168 2 2; CODING 53B, 6ms, G.711 REMGATEIP 135.207.22.1:7682; REMGATEID 5S71731; CRV 8839; REFID 135.207.31.2: 2124C90: 7224; BILLDATA 6010-0203-0456- 7890/9733608720/9733608766; CINFO 135.207.31.2: 7650 / 135.207.22.1: 7682 / 5S71731 / 10.3.7.150: 7685 / 10.3.7.150: 7000-2-2 / 9733608720/8839 / 10.3.7.150: 7685 SIGADDR is the IP address and port number that the first endpoint should use for BTI-BTI signaling messages. This is a global version of the address given in the SETUP / SETUPACK message from the second endpoint BTI, with the translation of name to given IP address, and with any NAT / PAT server translation included. DATAADDR is the IP address and the port number that the first endpoint should use for the data packets. This is a global version of the address given in the SETUP / SETUPACK message from the second endpoint BTI, with the translation of name and IP address made, and with any server translation NAT / PAT included. The second and third parameters (optional) in this element give the number of consecutive ports used, and the necessary alignment information for the start port number. REMGATEIP is the IP address and port number of the Edge Router that contains the gate that will be used at the end of the second BTI for this conversation. This is the destination address for all ER-ER communication.

REMGATEID is the gate identifier and the security code for the gateway within that Edge Router. CODING is the encapsulation method and coding style accepted by the second BTI. REFID (optional) is a unique identifier assigned by the Gate Controller, w will appear in all Billing Records. The REFID is intended to be unique within a period of several months. If this parameter appears, it will override the REFID assigned by the originating Gate Controller. BILLDATA (optional) is the billing / accounting data that indicates the arrangement or agreement of charges for this conversation. If this parameter appears, it will override the BILLDATA assigned by the originating Gate Controller. CINFO is a sequence generated by a Gate Controller that contains all the necessary information for future enhanced services that BTI may involve. This will be coded and given to the other BTI to store. The format is a list of many subsections or articles separated by hyphens, of w the first is the IP address and the controller's port.

Gate that constitutes the sequence. Subsequent subsections in this sequence include the address / port of the Edge Router, the gate identifier, the signaling endpoint address, the data endpoint address, the reference value of the destination call, and the address of destination for the initial call signaling. 7. 9.3.2 GCSPLICE error If the Termination Gateway Controller encounters an error while a splice request is completed, it responds to the originating Gateway Controller with a message GCSPLICENAK. A sample message is: GCSPLICENAK 4T93177 vl.O; ERROR No gates available ERROR gives a sequence of error messages, which could be displayed visually if the Gatekeeper had a method to do so, and can be passed back to the BTI in a NAK message. 7. 10 Edge Router to Billing Event Collector Messages sent by the Edge Router include CALLSTART, CALLEND, and CALLPARTIALEND. These messages are sent over a reliable transport mechanism, such as TCP / IP, which performs all the flow control and error control necessary to ensure reliable receipt of messages in the Billing Event Collector. The format of the messages is slightly different from other messages, since these are not transaction-based. These messages should also include a time clock. It is assumed here that the time clock will be added by the Billing Event Collector, who will perform its function in real time. However, if Border Routers are expected to accumulate event logs for a longer period of time and send them in a burst, then the Edge Router will need to record the time of each event and the messages should include that information as well. 7. 10.1 CALLSTART Whenever an Edge Router allocates resources for a gate, it issues a CALLSTART event log to the Billing Event Collector. A sample message is: CALLSTART 135.207.31.2:36123E5C:93178 5123-4567-8900 / 9733608718/8733608766 53B, 6ms The parameters for this message are: The unique reference ID for this call, which will be common in all registers billing related to the call. Billing information for this call, which consists of a multiple group of three entries: the account number to which the call will be charged, the E.164 number of the source for the call, the E.164 termination number for the call the three previous fields repeated as necessary for multiple call segments The bandwidth resources used or this call. 7. 10.2 CALLEND Whenever a Border Router disconnects resources for a gate, it issues a CALLEND event log to the Billing Event Collector. Note that this does not occur when a call is placed in HOLD, since the resources are still reserved for future use. A sample message is: CALLEND 135.207.31.2: 36123E5C: 93178 5123-4567-8900 / 9733608718/8733608766 53B, 6ms The parameters for this message are: The unique reference ID for this call, which will be common in all registers billing related to the call. Billing information for this call, which consists of a multiple group of three entries: the account number to which the call will be charged, the E.164 number of the source for the call, the E.164 termination number for the call the three previous fields repeated as necessary for multiple call segments The bandwidth resources used by this call. 7. 10.3 CALLPART IALEND Whenever an Edge Router is instructed by a Gate Controller to disconnect resources at one end of a conversation, but advised not to coordinate with the remote gate and disconnect all resources at both ends, this issues a CALLPARTIALEND event log to the Billing Event Collector. A sample message is: CALLPARTIALEND 135.207.31.2:36123 E5C: 93178 5123-4567-8900 / 9733608718/8733608766 53B, 6ms The parameters for this message are: The unique reference ID for this call, which will be common in all billing records related to the call. Billing information for this call, consisting of a multiple group of three items: the account number to which the call will be charged, the E.164 number of the source for the call E.164 termination number for the call the three previous fields repeated as necessary for multiple call segments The bandwidth resources used by this call. 7. 11 Gate Controller for the NAT / PAT Server Messages sent by the Gateway Controller include NATENQ and NATSETUP. The inquiry messages for the NAT / PAT server have a common structure for message element names. The first letter of the type name is either "L" or "G", indicating a request regarding a local or global address. The last portion of the type name is a number, which is used by the sender to match the answers with the questions. For example, a request message with a GADDR3 parameter will give a response with an LADDR3 parameter, and a request message with a LADDR7 parameter will give a response with a GADDR7 parameter. There is no requirement that the sequences of digits in the names of the parameters are consecutive, but they must be unique within the message. 7. 11.1 NATENQ A NATENQ message is sent by the Controller gateway to the NAT server to inquire about a possible entry in the translation tables, but without creating an entry if none currently exists. A sample message is: NATENQ 4T93174 vl.O; LADDR1 10.0.12.221:7685 LADDRx / GADDRx is the local / global address and the port number that the Gatekeeper is looking for. 7. 11.1.1 NATENQ recognition The response to a NATENQ message gives the translations found in the tables for the specific addresses. If no entry was found, its element is not present in the response message. A NATENQACK sample message is: NATENQACK 4T93174 vl.O; GADDR1 135.207.31.1:6000 GADDRx / GADDRx is the global / local address and the port number that the Gatekeeper is looking for. 7. 11.1.2 NATENQ error The only anticipated error that can occur in a NATENQ message is that the server does not perform a NAT / PAT function, and therefore does not recognize the request. A sample error response is: NATENQNAK 4T93174 vl.O; ERROR Request not acknowledged ERROR gives a sequence of error messages, which could be displayed visually if the Gatekeeper had a method to do so. Otherwise it provides some useful debugging information. This can also be passed back as part of the error indication from the request of the Gate Controller. 7. 11.2 NATSETUP A NATSETUP message is sent by the Gateway Controller to the NAT server to create entries in the translation tables. A sample message is: NATSETUP 4T93175 vl.O; LADDR1 10.0.12.221:7685; LADDR2 10.0.12.221:7000 2 2 LADDRx / GADDRx is the local / global address and the port number that the Gate Controller wants to enter to be established in the translation table. The second parameter, if present, gives the number of consecutive ports required. The third parameter, if present, gives any alignment constraints on the assigned port number. 7. 11.2.1 NATSETUP recognition The response to a NATSETUP message gives the translation entries either found or set in the translation tables. A sample NATSETUPACK message is: NATSETUPACK 4T93175 vl.O; GADDR1 135.207.31.1:6000; GADDR2 135.207.31.1:6002 2 GADDRx / GADDRx is the global / local address and the port number that the Gate Controller requested to be established. The second parameter (if present) indicates the number of consecutive ports assigned. 7. 11.2.2 NATSETUP error Any errors encountered while creating NAT / PAT entries will result in a NATSETUPNAK message. A sample error response is: NATSETUPNAK 4T93175 vl.O; ERROR Full translation table ERROR gives a sequence of error messages, which could be displayed visually if the Gate Controller had a method to do so. Otherwise it provides some useful debugging information. This can also be passed back as part of the error indication from the Gate Controller request. 8. Signage Architecture Call Flow This section presents the call flows to show the exchange of signaling for basic telephony services as well as 17Q Many features of Customer Call and CLASS (CLASS). 8. 1 Call Flow Terminology The following terminology describes the signaling call flows that can be used by the embodiments of the present invention. The symbols are used to represent parties involved in the flow of the call (for example, Gate Controllers) and the information that is exchanged (for example, Call Parameters). Each of these is often followed by a subscript indicating which one is being specifically referred. The common subscripts are 0 for origin, T for completion, F for sending, B for bridge, and TR for transfer. For example, in a simple telephone conversation, BTI0 refers to the origin BTI, and BTIT to the terminating BTI, and similarly for E.164t, ER0, ERT, GC0, GCT, etc. All messages and parameters are described in detail in the following section: Protocol description.

Call Flow Symbols BTI - Band Telephony Interconnection Wide - or a modem (modulator-demodulator) by cable equipped by ER telephony - Edge Router: The cable modem termination system that serves as the BTI GID - Identity (ID) of the gate: Identification of the "gate" within the edge router assigned to this call. GC - Gate controller that serves the BTI Cl - Call information: Information regarding the call through the network. This information includes the E.164 address, the IP address of the BTI, the IP address of the service gate controller, the IP address of the service ER, and the GID of the gate in the ER. [CI] (GC) - Coded information regarding the BTI that is given to others outside the network, for storage. This is signed and coded by the indicated Gate Controller.

BID - Billing identity: call identifier for billing purposes; intended to be unique not only within the entire network, but not to be reused for a significant period of time. Both edge routers involved in a call report this identifier in the call detail records. TID - Transaction ID: Identifier of a message; intended only to be locally unique for the duration of a messaging / response transaction. E.164 - CN phone number - Caller directory name LA - Local IP address (established when BTI turns on) GA - global IP address (set via NAT when BTI starts a session) PN - port number used by BTIs for a particular connection AI - Authentication information, simple sequence per subscriber, common across all lines served by a BTI. This sequence is signed and encoded by a network server, and is verified by the Gate Controllers for each transaction. $ - call accounting information, such as the customer's account number, to be included in the billing information for the current call. Given for ER as part of the permit to open the gate. In some cases, for example the sending of the call, two separate account numbers will be included to indicate a split charge arrangement for the call. In addition to loading the information, the accounting information includes parameters that place annotations on the call that is going to be established. Some parameters may include maximum call duration and transmission priority. CP - Call parameters (for example, the compression standard) for this call. CP0 are the parameters offered by the originator of the call, CPT are those accepted by the termination system. or - indicates that the translation or translation of the network address is performed in the ANN-INFO ER - Ad information: parameter indicating to an ad server which ad to reproduce.

CF - Flag indicating that the call is sent over all calls or busy, is active. T - Flag indicating that the transfer of the call is active. CTOR - Cut through the disconnection flag on: indicates that the edge router should cut through the call in the reception direction when the BTI reserves broadband.

SGCP Parameters: The S-R-SGCP parameter that indicates that a connection must be opened in the sending and receiving directions. The parameter S-NR-SGCP indicates that a connection should be opened only in the sending direction (upstream). Parameter NS-R-SGCP indicates that a connection should be opened only in the receiving direction (downstream).

SS7 symbols: IAM- Initial Address Message ACM- Complete Address Message E-ACM- Complete Address Message Early ANM- Response Message REL- Disconnection Message RLC- Complete Disconnection Message SUS- Suspension Message RES- Summary Message 8. 2 Basic Call Flows 8.2.1 Connection Figure 6 shows the call flow for a normal call preparation, according to an embodiment of the present invention. The preparation of the call involves the establishment of an IP signaling and the bearer channel between the BTIs through a packet network. The signaling channel uses the IP transmission "better than the best effort" through the network. Signaling reliability is ensured within the application. In the access portion of the network (between the edge router (ER) and the BTI), the bearer channel uses an "unsolicited grant" as defined by MCNS vi .1 to maintain a constant bit rate channel. The ER "colors" the carrier packets of "high QoS" to give them higher priority than the "best effort Qos" packages over the main portion of the network (between the ERs). Some of the aspects of the basic connection call flow are: Digit collection - The BTI0 needs to recognize when a complete telephone number is dialed, so it can package the number in a setup message (SETUP) and send it over the GC0 for translation or translation. Translation or Network Address Translation (NAT) for the BTI of origin - the ER carries out the translation or translation of the network address between local addresses (NetlO) for each of the BTIs and global addresses. Each ER is assigned with a group of global addresses. The ER assigns a global address to a BTI when the BTI attempts to communicate outside of its local area, or when a gate controller requires a global address to be assigned to a BTI.

Authentication - BTI GC0 authenticates the BTI after the reception of a preparation message (SETUP). The authentication information (AI) needs to be provisioned in the BTI in the BTI registry. The GC0 also performs the service-specific admission control. For example, if a Gate Controller knew that a specific destination area was overloaded with traffic, it could block a call preparation. Gate Assignment - GCs request that a gate be assigned to ER0 for this call. The ER0 responds with a gate ID (GID0) to be used for the call. GC0 adds this information to the Call Information record (CI0) for this call. Billing Identifier (BID) - While an initial call attempt is processed, the Gatekeeper assigns a globally unique Billing Identifier (BID) to the call. Such a unique identifier could be, for example, the IP address of the Gate Controller followed by a time clock, followed by a call sequence number. It is intended that this identifier be unique over the various billing cycles, and make it possible for the system to invoice correctly match all the records related to a simple call. Number Translation - The E.164t address is translated or translated by the Gate Controllers to the local IP address of the terminating BTI and the terminating ER. If the GC0 can not translate or translate the E.164t address by itself, it identifies a gate controller (GCJ that can perform the translation or translation) GC0 sends the preparation message (GCSETUP) of GC0, with the additional information in it, or on the GCT for processing.This simplifies the security of the ER , since it only accepts orders or commands from a small group of well-known Gate Controllers Accounting Information ($) - In addition to loading the information (for example, the account number), the accounting information includes the parameters They place annotations of the call to be established, some parameters can include the maximum duration of the call and the priority of transmission In several situations involving the sending of a call, the charge for the call will be divided between two or more subscribers In this way, the parameter "$" in the messages can Contain several account codes with information regarding the proper assignment of charges to each one. "Gate Opening" - The Gate Controller gives permission for an ER to allow a BTI to prepare an "unsolicited grant". He ER also "colors" the carrier channel packets so that they have "high QoS" to a specific destination address. If an ER does not receive permission to "open the gate" for high priority packets, it does not allow unsolicited granting or high priority packets. This permission is based on a specific source IP address and a specific destination IP address, and the limits on resources that the endpoints can use. The accounting information ($) in the ER gate preparation message provides the bounds on these resources. • Call information (CI0 and CIJ - information regarding a BTI, including its address E.164, its Gateway Controller address, its ER address, and the GID within the ER. Each endpoint of a call receives this information with respect to the other endpoint, signed and coded by the local Gate Controller, to prevent unauthorized description or tampering by the BTI. This call information is subsequently used for the Call Trace (* 57), Callback (* 69), and in the preparation of the Three Way Call. • Negotiation of capacity - BTIs have the ability to negotiate the parameters of the call (CP) (for example, coding) in the exchange of SETUP message. If additional negotiation is necessary, this can be achieved before the commitment of resources is made. • Reservation of Access Resource - An unsolicited MCNS grant protocol is used to reserve a constant bit rate channel in the network access portion. The reservation of access comes in two parts, which is required for the application in telephony. In the first step, the "reservation" ensures that broadband will be available when necessary, but does not effectively allocate the bandwidth nor does it "open the gate". The reservation is obtained before the telephone rings destination. Only when the destination user answers the second step, the "commitment", assign the bandwidth and start billing for the call happens. To protect resources, only a certain number of outstanding reservations are allowed by BTI. • Main Resource Reservation - DOSA allows the possibility of a reservation protocol of main resources, different, than that used for the access portion of the network. This is the task of ER to process the access reservation message and translate it into the appropriate message sequence for the main resources. When the ER recognizes the reservation with an acknowledgment message (ACK), this means that the access resources are available for the call and any major resources that this CMTS needs to reserve, to support the flow that has been reserved. At this point it is safe to start the bell phase. An example of a reservation of principal resources is shown in Section 6.2.2. • Commitment - This is the second step of the access reservation sequence. The commitment is made when an effective connection has to be done and billing is initiated. The ER and the network previously reserved the resources, and kept them for this particular conversation. The ER issues a call detail record for the billing system at this time. • Compuerta Coordination - In order to avoid certain theft of service scenarios, the opening and closing of the gates within the network needs to be coordinated between the ERs. Open gate (GATEOPEN) is an ER for the ER message that indicates that the gate has been opened at the far end of the call. Call Parameters at the far end are passed to the BTI so that it checks if it is in accordance with the parameters that are in the far-end gate. 2. 2 Main reservation Figure 7 shows an exemplary signaling call flow for the reservation of resources in the network segment between the edge routers for a voice call, according to an embodiment of the present invention. This is a potential master reservation model; however, different procedures can achieve the same result. In one modality, a separate mechanism is used for the reservation of access from the main reservation. This leaves the BTI interaction with the ER independent of the main network between the ERs. In one modality, the reservation of resources is initiated by a sender and only reserves resources for the packages that are generated by that sender or sender, for example, the reservations are unidirectional. This is consistent with the shipping model used in IP networks in which trajectories can be asymmetric. However, the reservation message (RESERVE) used on the access network has different semantics: bidirectional reservation capacity over the access network. Because the end-to-end routing between two edge routers can change during the duration of a call, RESERVE messages can be periodically transmitted from either end to refresh the reservation (although this is not shown in Figure 7). The IP source address in the message RESERVE contains the address of the ER source. The destination IP address in the RESERVE message is that of BTIT. The reservation message identifies: GA0 (the global IP address of BTI, PNC (the port number of BTI0 for this call), GAT (global IP address of the BTIJ, PNT (port number of BTI0 for this call) as The owner of the reservation After preparing the bidirectional access reservation, the ER sends a main reservation message (BACKBONERESERVE) through the intermediary main routers to BTIT.The routers are unable to process the BACKBONERESERVE message to them without any processing In this example, the reception of the RESERVEACK to a BTI indicates that the resources have been reserved in the sending and receiving addresses in the access channel, and in the sending direction in the backbone. 2. 3 Disconnection Figure 8 shows the flow of the call for a normal call termination, according to an embodiment of the present invention. When a BTI detects hanging or idle condition, it sends a HANGUP message from end to end to the other BTI and a disconnection message (RELEASE) to the ER. In response to the RELEASE command, the ER closes the gate and issues a call end (CALLEND) to the billing system that indicates that the call has been completed and that billing must stop. Note that there are a number of error conditions that will cause this disconnection sequence, such as BTI failures, power failures, wiring plant failures, and mains failures. In all cases, it is desirable to stop billing at the end of the useful connection, and not to charge the customer for a service outage (possibly prolonged). 8. 2.4 Calls ending in the PSTN Figure 9 shows the flow of the call for a call originating from a BTI, but ending at the PSTN, according to an embodiment of the present invention. In the call flow, GCT recognizes that E.164t terminates outside the IP network. GCT identifies the SGWT and the TGWT appropriate. The GCT initiates a gate preparation (GATESETUP) to the ERT with the Cut Through the Reserve flag (CTOR) adjusted to indicate that the one-way voice path from the PSTN to BTI0 must be established once it is required the reserve. GCT then sends the preparation (SETUP) to the SGWT. SGWT assigns a trunk identified by the IP port number, PNT on the TGWT for the call. SGWT also searches in CP0 to determine the call parameters that will be used for this call (CPJ.) After receiving the preparation acknowledgment (SETUPACK) from SGWT, GCT asks GC0 to include the CTOR flag GC0 prepares the gate on the originating end of the call including the CTOR flag indicating that ERs must open the voice path to the reserve BTIs GC0 also includes the CTOR flag on the SETUPACK message to the BTI0, so that BTI0 does not generate its own signal of call, but it uses the call signal from the far end of the network, if additional capacity negotiation is necessary, this can be done at this point, once the parameters of the call are known, SGWT uses the message of SGCP to create connection (CREATECONNECTION) to inform TGWT about the potential call. Included in this message are all the parameters that TGWT needs to reserve the necessary bandwidth and translate between the IP packets and the TDM trunk. Also included in this message is a REQUEST FOR NOTIFICATION SGCP (SGCP NOTIFICATIONREQUEST), which requests that TGWT notify SGWT when the reservation is recognized by ERT. TGWT sends a reservation message requesting the appropriate QoS on the network for the call. The trunk entry needs to send this reservation message (versus the SGW) since the reservation needs to be along the path of the bearer channel. After a successful reservation TGWT sends the SGCP notification (SGCP NOTIFY) to SGWT. Once SGWT receives the ringing message (RING) from BTI0 and the NOTIFY from TGWT, SGWT sends the Initial Address Message SS7 (IAM) to the PSTN to prepare the connection between the TGWT and the final destination. After reception of the Complete SS7 Address Message (ACM), which indicates that the destination telephone is available and ringing, SGWT sends the ringing message (BIN0) to BTI0 and BTI0 reproduces the signal tone call that you are receiving from the network to the client. When the destination telephone picks up, an answer message SS7 (ANM) is received by SGWT. SGWT sends the connection (CONNECT) back to the BTI0 and uses the connection to modify (MODIFYCONNECTION) the SGCP message to indicate to the TGWT that it needs to change the connection to a two-way connection, and send the commitment (COMMIT) to the network to open the gate in both directions. There are special cases when SS7 messages are received, which cause the call to flow to change. Some of these cases are described below: The Complete Early Steering Message (E-ACM) - when an E-ACM message is received from the SS7 network instead of the ACM, the voice connection needs to be established in both directions (sending and reception). An example of how this is used by the PST to indicate when a call 800 is being routed to an IVR system to determine where the call should ultimately be routed. After the call is routed and the far end answers, SGW0 receives an ANM.

Busy - If the PSTN network or the called party is busy, the SS7 network returns a busy indication with cause code in response to the IAM. SGW0 needs to send a busy message (BUSY) with a cause code instead of RINGBACK to BTI0 so that the BTIC will play busy busy fast or busy to the client. 8. 2.5 Calls that originate from the PSTN Figure 10 shows the flow of the call for a call originating in the PSTN, but terminating in the IP telephony network according to an embodiment of the present invention. The IAM message is the first indication that the call is destined from the PSTN to a BTI. The IAM message is received by the SGW0 which subsequently sends a SETUP message to GCs. The preparation proceeds as normal through the IP network. The CTOR flag is not necessary since the call signal or termination announcements will not be generated from the IP network. The signaling flow is similar to when a call is destined for the PSTN (see section previous). SGCP messages are used between SGWs and TGW0. 8. 2.6 Call Release to the PSTN Figure 11 shows the flow of the call for a normal release to the PSTN, according to an embodiment of the present invention. This call flow assumes that the BTI originated the call. If the call is originated in the PSTN, SGWT could send a message to suspend SS7 (SUS). This tells the PSTN that the phone in the BTI was hung, but the call is not disconnected until a stopwatch expires (for example, 14 seconds). If the phone is off-hook before the timer expires, a message to resume SS7 (RES) is sent. 2. 7 Disconnection of the PSTN call Figure 12 shows the flow of the call for a call disconnected from the PSTN, according to an embodiment of the present invention. The flow of the call assumes that the call originated in the PSTN. 8. 2.8 E911 Emergency Service To support E911 emergency calls, the GC0 must route the call to the E911 call center associated with the calling number. The E911 call center can be reached via an entry or it can be an E911 call center that is supported in the packet network. The originating telephone number and additional information can be obtained when the call center E911 has to send a preparation acknowledgment message (SETUPNACK) to the GCT as in the call flows for the caller ID distribution / caller name . Otherwise, the call flows for call preparation remain unchanged. The BTI that originates a 911 call must not disconnect the call when the user hangs up. This requires BTI0 to detect that the dialed number is 911 and alters its local hang processing accordingly. A call to an operator for assistance can be transferred by the operator to an E911 center. In this case, the entry or the final system to which the operator is connected must send an end-to-end message to the BTI0 that instructs it to alter its processing. hang up. This message must be authenticated by the BTI0 as it is being sent by a trusted network entity before the BTI0 changes its hanging processing. Authentication is required so that an arbitrary endpoint can not instruct a BTI to alter hanging processing. 8. 2.9 Completion Announcements In some cases when a call can not be completed, the customer hears an announcement or notice of termination. The handling of the announcement or termination notice can be invoked when the dialed number has changed or can not be moved, or as a result of a limitation of network resources (for example, "busy trunk line") or a network problem . Because the BTI contains processing and storage, common termination announcements can be handled locally by the BTI in response to an error indication. For example, common messages such as "The number you dialed is not in service, please check the number and dial again" or the signal "trunk line Busy "can be stored locally in the BTI." In the first case, the GC0 returns an error message to the BTIs indicating that the dialed number can not be transferred.In the second case, a router returns an error message to the BTI0 As a result of an admission control failure during the processing of a COMMIT message, the error messages indicate to the BTIs which advertisement should be reproduced.Some services require that the advertisement be personalized, perhaps based on the origin number, the marked number, time of day, or administrative controls.Thus, in general, the announcements or notices are a function of the known conditions for the Gate Controller.In this case, there are two options to support the announcements or warnings The BTI may be sent by the gate controller to the BTI as a data message to be played by the BTI Alternatively, the BTI may connect to an ad server of the BTI. e termination. These alternatives may also be used to support the common announcements or termination notices described above.

Figure 13 shows a call flow where the BTI is connected to a termination announcement server according to an embodiment of the present invention. The management of the announcement or notice of termination can be invoked either by the GCQ or the GCT in response to a SETUP message. The Gateway Controller routes the call to an announcement server or termination notice and interacts with the server to control the announcement it reproduces. Call accounting information ("$") that is used for the call, indicates that the call is not billed. 8. 2.10 CALEA Interception CALEA requires the ability to intercept (capture) calls from a subscriber line and provide additional information associated with these calls, such as the dialed number, and the time and duration of the call. Since the BTI is not considered a trusted device, the support for the CALEA interception must be implemented within the network, and must not be detectable by any party that participates in the call. Our solution to the problem requires that the ER be able to multicast information that flows from each party in the call to the other party or parties, and an additional final system or entry (an "interception server") that can distribute the bearer channel information to the authorities. This multiple broadcast capability requires that each packet that matches a function be routed to the intercept server, in addition to being normally routed. The filter function is discussed later. A proposed procedure to the problem does not rely on connection processing in the ER to intercept a line. In this procedure, when authorities request that a line be intercepted, an administrative system sends a message to the originating ER instructing it to broadcast stereophonicly two channels (multiple broadcast) the bearer channel to the intercept server. The filter specifies the local IP address of the BTI associated with the line being intercepted, the address of the intercept server, and may also specify the port number associated with the bearer channel. However, since the port numbers associated with the bearer channel (voice) can be dynamically assigned by the BTIs of origin and termination, the administrative server is unable to specify this information. If the filter function does not contain the port number information, it could cause all packets associated with the BTI to be intercepted, which may not be desirable since these packets may include data packets that can not be legally intercepted. Thus, this procedure is possible in the present architecture, but it may be desirable to have a method that only intercepts the bearer channel without intercepting additional channels. In another mode, the Gate Controller supports the interception. When authorities request that a line be intercepted, the database record associated with the line is modified to indicate that the line must be intercepted. When a SETUP message arrives at the Gate Controller (this may be either a Gate Controller or a Gate Controller), the Gate Controller searches the database register and notices that the line must be intercepted . The Gateway Controller sends a message containing the address of the intercept server to the ER. This information can be included as part of the "open gate" message. The Gate Controller also sends a message containing the dialed number to the interception server. The ER sends messages at the beginning and end of the call to the intercept server. These additional messages provide the additional information required by CALEA. In this solution, only new calls can be intercepted. The calls that exist before the interception information is provisioned in the GC, will not be multicast to the intercept server. 2. 11 Call Trace Figure 14 shows the call flow for the Call Trace, according to one embodiment of the present invention. BTIT (the recipient of the call that needs to be traced) sends a simple trace message (TRACE) to GCT containing its own authentication information, and the connection information received from the GCT for the incoming call, more recent. GCT verifies the connection information (Cl) by decoding and verifying the signature. If it is valid, the number E.164 content within the CI is reported for legal enforcement, along with the identity of the client making the report. 8. 2.12 Interruption by the operator The interruption by the operator is a combination of the CALEA intercept described in section 7.2.10 and the three-way call described in section 7.3.4. 8. 2.13 Operator Services Operator services will be initially supported by IP telephone clients by going through a PSTN entry. In the future, operator services may be on the network of IP. 8. 2.14 Change of Media Call Resources In some cases, a call in progress may need to change the established parameters of the call. For example, if a call is prepared using low speed compression or proportion of bits (for example, 16 kbps G.728) and after the call is answered the BTI detects a modem tone (modulator-demodulator), the BTI needs to change the bearer channel to a G.711 channel of 64 kbps not compressed Figure 15 shows the flow of the call to change the established parameters of the call, according to an embodiment of the present invention. Gate Controllers do not need to be involved in a half call resource change, as long as the Gate Controller account information distributed to the ER during call preparation is consistent with the resource change request. For example, if the BTI requests a channel with greater bandwidth or higher priority than the one that allows the account information, the ER could deny the request. As with normal call preparation, there is a two-step process of Reservation then Commitment to change the call parameters of the average call. 8. 3 Main call flows 8.3.1 Call Transmission The call transmission service allows a call destined for an E.164 address to be redirected to another E.164 address. Redirection can occur in all calls, only in busy status, only in the absence of response, or in a combination of either busy or no response. Call Transmission is a popular service, and is used for other services (for example, voice mail) to redirect calls. If a BTI is not available and the transmission of the call is active, all calls destined for the BTI must be transmitted or forwarded. At least three parties are involved in all types of Call Transmission service: The Origin Location (BTIs) - the location that places the call that is to be transmitted. The Termination Location (BTIJ - the location that has the active call transmission.

The Transmission Location (BTIJ - the location to which the calls are being transmitted.) Notwithstanding the type of Call Transmission (All Calls, Busy, No Answer), the transmission number can be specified by the customer on a basis per use, or be pre-provisioned (specified when the customer closes the contract for the Call Transmission service.) If the transmission number is pre-provisioned, the BTI and the Gate Controller serving that customer store the transmission number. the transmission number is specified on a per-use basis, the customer dials a code (eg, * 72) and the transmission number to activate the Call Transmission In all cases, the Origin Location must not receive the number In the case of the Call Transmission - Without Answer, the Origin Location can know that the call is being transmitted, Figure 16 shows the flow of the call. a call to activate a call-by-use transmission service, according to an embodiment of the present invention. The BTI recognizes that the client marked the code to activate the call transmission, and persuade the customer for the transmission telephone number. This information is sent to the Gate Controller in a PROFILE message. The Gate Controller validates that the transmission number maps the map either to a BTI that the Gate Controller knows or to another Gate Controller. The Gate Controller verifies to be sure that the customer is subscribed to the call transmission service, and if so, activates the service and stores the transmission number for later use. The following sections describe the call flows for each of the types of Call Transmission Service for when the BTI is available and when the BTI is not available. 8. 3.1.1 Call Transmission - All Calls Figure 17 shows the call flow for Call Transmission - All Calls when the BTI is available, according to one embodiment of the present invention. The first part of the call flow is the same as the one shown in Figure 6: Connecting Call Flow.

When the SETUP message is received by the terminating BTI, it recognizes that the Call Transmission - All Calls, is active. It sends a special SETUPACK message to the Termination Gate Controller indicating that the Call Transmission is active. The Gate Controller recognizes the call transmission response, closes the gate on the ER that is opened for this call (using the GATERELEASE message) and sends the transmission number on the GCs along with the account information, so that the transmitted portion of the call can be billed to the BTIT. The Gateway Controller prepares the call to the transmission number as usual, except that the billing information can be maintained for both portions of the call. Figure 18 shows the Call Flow for Call Transmission - All Calls when the terminating BTI is not available 'according to one embodiment of the present invention. In this case, the GCT interrupts the BTIT SETUP message. The GCT verifies the client profile and determines that the call transmission is active and proceeds as if it obtained a Call Transmit response from the BTIT. 8. 3.1.2 Call Transmission - Busy Figure 19 shows the call flow for Call-Busy Transmission when the BTIT is available, according to one embodiment of the present invention. The first part of the call flow is the same as the one shown in Figure 6: Connecting Call Flow. When the SETUP message is received by the BTIT, it recognizes that the designated line is currently off-hook and that the Call-Busy Transmission is active. It sends a special SETUPACK message to the GCT indicating that the call transmission is active. The GCT recognizes the response of the Call Transmission. The rest of the call flow is identical to Figure 17: Call Transmission - All Calls / BTI available. Figure 20 shows the call flow for Call-Busy Transmission when the BTI is not available, according to one embodiment of the present invention. This flow is identical to Figure 18: Call Transmission - All Calls / BTI Call Flow Not Available. 8. 3.1.3 Call Transmission - No Answer Figure 21 shows the flow of the call for the Call Transmission - No Answer when the BTIT is available, according to an embodiment of the present invention. The first part of the call flow is the same as the one shown in Figure 6: Connecting Call Flow. The BTIT recognizes that the Call Transmission-No Response feature is active, and interrupts after the correct number of ringing sounds. A RINGTIMEOUT message is sent to the originator to stop the call signal, and a message is sent to the GCT to initiate the transmission operation. The REDIRECT message contains the new E.164F address. GCT decodes the call information, and retrieves the billing information for this subscriber. If the call transfer or transfer feature is subscribed, it passes the GCREDIRECT message back to the GC0 with the appropriate billing information. REDIRECT messages serve two purposes, this call transmission function and also a blind transfer function (transfer without consultation). Since the Controller Compuerta does not know which application is active, it must assume a transfer of data that is in progress and inform the BTI0 that it will be interrupted. This is done via the CALLHOLD / CALLHOLDACK exchange. If the BTIQ has a conversation state, the BTI0 tells the ER0 to temporarily suspend its reservation of resources; then it recognizes the CALLHOLD command of the GCs. GCT then recognizes to the BTIT that REDIRECT was successful. At this point, the GCs handles this call identically to the initial call, by moving E.164F to a Gate Controller address and passing a GCSETUP message to the GCT • The GCF, ERF, and BTIF actions are identical to those shown in Figure 6 for GCT, ERF, and BTIF. When GC0 receives the acknowledgment for its GCSETUP message instead of performing a GATEETUP, it modifies the settings of the gate already assigned via a GATEMODIFY command. When completed, the new destination information is passed to the BTIs via a TRANSFER message. GATEMODIFY and TRANSFER are identical to the messages made for the three-way call and for the call transfer. After resources are reserved for this call, BTI0 sends a RING command, and the answer is either RINGBACK (if the new destination is hung and is now ringing), or CONNECT (if the new destination is now ready). The latter could typically be the case within interactive voice response systems. After the CONNECT message, the resources are compromised and the communication channel is opened. Figure 22 shows the call flow for Call Transmission - No Answer when the BTI is not available, according to one embodiment of the present invention. This flow is identical to Figure 18: Call Transmission - All Calls / BTU Call Flow Not Available. 8. 3.2 Caller ID Distribution / Caller Name The following describes two alternatives for implementing the Caller ID / Caller Name distribution, with the embodiments of the present invention. The first thing is to have the ID information of the BTIT request caller on reception of the SETUP from the GCT. This request is sent to the GCT, which recognizes the Caller ID flag and check if the customer's line has subscribed for the Caller ID / Caller Name services. GCT returns the telephone number (E.1640) and the caller's name (CNJ of the originator of the call) Subsequently, the BTIT returns a SETUPACK as usual, if the subscriber to BTIT is subscribed to the services such as Call Rejection Anonymous or Call Selection, then SETUPACK may not be returned by the BTIT Finally, when the BTIT sounds the phone (assuming this is a "black phone" with the traditional caller ID box), then the Caller ID and the Name of the Caller are presented to the Caller ID box between the 1st and 2nd ringing sounds.If the user's phone is more intelligent, this information can be presented as a message that is interpreted and displayed visually. Figure 23 shows the flow of the call for this alternative 1. Another alternative for the implementation of the caller ID distribution / caller's name is to have GCT that verifies if the BTIT is subscribed to the service , upon receipt of each call. If so, the caller's telephone number (E.164Q) and the caller's name (CNs) are sent in the SETUP message to BTIT about each call that enters. The BTI can either accept (SETUPACK) or reject (SETUPNACK) the call based on E.164s and CN0. This alternative does not require additional messaging between the GCT and the BTIT to achieve the caller ID / caller ID distribution services. 8. 3.3 Call Waiting Figure 24 shows a call flow for a Call Waiting, according to an embodiment of the present invention. Initially, is there a call in progress between the BTI0? and the BTIT. A second call from the BTI02 to the BTIT is established up to the reservation access point and main bandwidth. BTI02 reserves the channel as normal, but the BTIT uses a RERESERVE message to indicate that it does not need a new access reservation, but only needs to associate the new gateway (GIDT2) in the ER with the existing access reservation for the gate (GIDTJ The messages "RING" and "RINGBACK" are exchanged between the new BTI02 and the BTIT.The BTIT now inserts a "call waiting tone" in the original call in progress, to indicate to the user that there is a second call that enters. When the user "hangs up instantly", then the BTIT sends a HOLD message to the BTIoi and receives an acknowledgment for this message. Subsequently, the BTIT completes the call to BTI02 by sending a CONNECT message. Instead of having another allocation of resources for the BTIT for this new call, the modalities of the present invention reallocate the existing resources. The BTIT sends a RECOMMIT message with the Gate IDs of the two calls (GIDT? And GIDT2) so that ERT can reassign the resources from the first to the second call. In addition, a new CALLSTART event is sent to the billing server. When BTI0? obtains the HOLD message, it asks the ER01 to suspend the allocation of its resources on the MCNS channel using the HOLD message until a future COMMIT message is sent from the BTI0 ?. Does BTI01 send the periodic KEEPALIVE message to ER0? and BTIT to ensure that the bandwidth is not reassigned to other calls. 8. 3.4 Three-way call 8.3.4.1 Three-way call - Condition on BTI Bridge Figure 25 shows the flow of the call for the alternative of Three-Way Calling Simple with the bridge connection in the BTI0 according to an embodiment of the present invention. In the flow, a second call is prepared as a totally new call using the separate resources in BTI0, the access network, and the main network. When the client wishes to complete the three-way call (indicated by the second instant call), the BTIo bridges the calls with each other. 8. 3.4.2 Three-Way Call - Network Bridge Connection This section describes the use of a bridge located on a server within the network. Figure 26 illustrates the first steps of a three-way call, according to one embodiment of the present invention. The client begins with an existing call, either one that he places or one that he receives. When the switch hook flashes, that call is placed on pause. A HOLD message is sent to the destination, indicating this change, and HOLDACK is sent in response. Both ends then inform their ERs that the isochronous transmission will be temporarily interrupted, but to keep the resources compromised, via the HOLD message to the ER. The periodic KEEPALIVE messages are sent to each end and the ERs to achieve this. The BTI0 then plays the originating dial tone, and receives the full E.164 address of the additional party to call. This new call proceeds as shown in Figure 6 for the normal preparation of the call. At the resource reservation exchange point, ER0 has assigned two gates (the original with the parameters of the first call, and the new one with the parameters for this call), the upstream access resources are reserved for a call, and the backbone has reserved the resources for both calls. When the third party answers, the second call is established using the resources reserved for GID02. This state is identical to that of the call waiting, when a call is paused and the subscriber is speaking on a second call. Because the subscriber The second call began, however, instead of receiving that call, the last twinkling of the hook commands a three-way call instead of a switch to the first conversation. Figure 27 shows the sequence of the signaling messages exchanged in the conversation of the two separate calls in a three-way call, according to one embodiment of the present invention. BTIs allocates a conference bridge when creating a third connection to a special server on the network. The bridge server will take an arbitrary number of input currents and generate an output current for each; each output is the sum of all entries except for the contribution of the corresponding entry. When the input number exceeds a small number (for example 3), the bridge performs silent detection at each input to reduce accumulated noise. Once the host establishes the connection to the bridge, each of the participants of the three-way call needs to be informed of the new destination, and needs to have their gateways modified appropriately. This function is identical to that performed for Call Transmission no response, and involves the BTI0 that sends a REDIRECT message for each existing connection. The REDIRECT function involves two steps. The first is a GATEMODIFY message to the ER that modifies the parameters of the gate. This message includes the new destination address for the data packets, as well as the new billing information. The second is a TRANSFER message to the BTI, which tells you to switch to a new destination to send and receive packets. Prior to the recognition of this message, the BTI makes an exchange of reservation of resources with the indicated end point (in this case, the bridge) to ensure that network resources are available. The GATEMODIFY message sent to the ER includes the charge information ($). Calls from each end point to the bridge involve the divided charge; the originator of the call pays only for the call equivalent to its marked destination, and the party making the three-way call pays for the extra segment to the bridge. This is similar to what is done for the Call Transmission.

The GATEMODIFY message sent to the ER also includes a Billing Identifier, BID. This unique identifier is given to all the ERs involved in the three-way call, so that the billing records produced can be agreed later. The BID used for the call is the only ID assigned to the BTIs for bridge connection. The TRANSFER message sent to the BTI includes the updated CIB information, coded by the local GC. This information replaces the previous information. CIB contains enough information to allow one of the participants in this three-way call to add another party and assign an additional bridge; the use of this CIB for a return call or for a call trace will result in errors. It is possible for one of the participants in the three-way call, who also subscribes to the three-way calling service, to add another party. The call flow is identical to Figure 27, except that one of the endpoints is not a BTI but rather the first bridge. The bridge handles the TRANSFER messages in the same way as the BTI, allowing this cascade service.

This sequence assumes that the bridge is located within the network, and does not need global address or gateways to be assigned. The GC0 is identified as the Gate Controller that serves the bridge, and there is no ER and does not need programming upstream of access lines. If the bridge were rather located outside the network, then additional exchanges could be required to establish the gates and the allocation of bandwidth upstream. These exchanges could be identical to those for the normal establishment of the call. There are two separate cases for hanging sequences. If the originator of the three-way call hangs up, it sends the message RELEASE to its local ER and a HANGUP message to the bridge. The bridge sends HANGUP messages to the other two portions of the call and also GATECLOSE messages to its ERs. This sequence is shown in Figure 28. If a participant in a three-way call is disconnected, it is desired that the bridge be disconnected and the call reverted back to a normal two-part call. Figure 20 shows the sequence of messages necessary to perform this function. The bridge receives a message HANGUP from a participating BTI, and sends an SPLICE message to its GC, giving the connection information (Cl) for the two portions of the call that are going to be spliced together. The GCs inform the ERs via a command GATEMODIFY, of the new destination of the data packets, and inform the BTIs, via a TRANSFER command, of the new destination. In cases of errors, such as when the resource reservation exchange fails to allocate main bandwidth for direct connection, the bridge may remain involved in the call with the remaining two parties. 8. 3.5 Call Transfer There are two different call transfer services. Call Transfer with consultation is a very similar service for the Three Way Call, except that when the originator of the three way call is disconnected, the two remaining parties can still continue talking. Call Transfer without Query is similar to Call Transfer, except that the transmission can be made after a call is established. 8. 3.5.1 Call Transfer with Query Call Transfer with Query is very similar to the three-way call, except that when the client (or host) hangs up the phone, the call between the two remaining participants can continue. The billing also continues as if both parts of the call are still in place. The majority of call flows for the preparation of a Call Transfer with Query are identical to those of the three-way call (Figure 26, Figure 27, and Figure 29). The only call flow that is different is when a host disconnects. Figure 30 shows the flow of the call for the Call Transfer with Query service, when the host is disconnected, according to an embodiment of the present invention. As with the Three Way Call, the call is reverted to a simple two-way call between the two participants. However, the Billing for the call continues as if there were a three way call. For the Call Flow of the Call Transfer with Query, the following events have preceded the hanging action of the host: BTITI has originated a call to the BTID and the billing records (BIDT? / O) for this part or portion of the call are being generated by the BTI0 has put the BTIT? paused and prepared a new call to the BTIT2. The billing records (BID0 / T2) for this part of the call are being generated by the ER0. The BTI0 has joined the two parties of the call in a three-way call using a network bridge. At this point, when the host hangs up, the gate on the guest edge router (ER0) is closed and the billing associated with that gateway (BIDO / T?) Is terminated. GC0 retrieves the information associated with this billing record (including the globally unique BID) of the ER0 using the GATEINFO request and transfer the billing information to one of the participating ERs. The participating ER that receives this information (ERT2 in the flow of the call), generates a new billing record for the part associated with BID0 / t2- During the processing of the invoice, the two billing records for BID0 / T2 are associated using the unique BID, of so that the call can be properly billed. 8. 3.5.2 Call Transfer Without Consultation As shown in Figure 31, the Call Transfer Without Query is very similar to Call Transfer-No Answer. 8. 3.6 Return Call It is possible for GC0 to implement the callback service by storing the number of the most recent incoming call (caller ID) in the Gatekeeper, and then returning the call in a SETUP request. However, this requires the Gate Controller to retain the associated status for each phone. It may be desirable to allow the final system (for example, the BTI) to retain this state, by simplifying the Gate Controller. Unfortunately, if the incoming call was From a subscriber who had blocked the caller id, it is important to keep the caller ID information private, as it can not be made available to the final system. The solution is for the GC to send the caller ID information to the BTI in a digitally signed and encoded form, with each SETUP request. When a user dials the code * 69 to activate the callback service, the BTIs include the information encoded in the SETUP request to the GC0. If the GC0 successfully decodes and validates the information, and the client subscribes to the Return Call service, it returns the call as if a normal SETUP request was processed to the number associated with the most recent incoming call.

It is noted that in relation to this date, the best method known to the applicant to carry out the aforementioned invention is that which is clear from the present description of the invention.

Claims (44)

CLAIMS Having described the invention as above, the content of the following claims is claimed as property:

1. A method for allocating network resources for a call of a calling party and a called party, characterized in that the method comprises: reserving a plurality of network resources for the call, based on a reservation request, the plurality of resources of the network is reserved before any network resource from the plurality of reserved resources of the network is compromised; and committing the reserved plurality of network resources for the call, when the called party indicates acceptance for the call.

2. The method according to claim 1, characterized in that the plurality of resources of the network for the call are reserved based on a quality of service, authorized by a service provider.

3. The method according to claim 1, characterized by further comprising: recording the initial use for the call, once the reserved plurality of resources of the network are compromised.

4. The method according to claim 1, characterized in that it further comprises: recording the purpose of use for the call after a termination condition.

5. The method according to claim 1, characterized in that it further comprises: opening a first gate in an edge device of the originating network, on the basis that the called party indicates the acceptance for the call; opening a second gate in an edge device of the terminating network, based on the fact that the called party indicates the acceptance for the call; and the reserved plurality of network resources is compromised after the first gate and the second gate open.

6. The method according to claim 1, characterized in that it further comprises: opening a first gate in an edge device of the originating network, on the basis that the called party indicates the acceptance for the call; the opening of a second gate in the edge device of the termination network, based on the fact that the called party indicates an acceptance for the call, the first gate and the second gate are substantially simultaneously opened; and the reserved plurality of network resources are committed after the first gate and the second gate open.

7. The method according to claim 1, characterized in that it further comprises: the opening of a first gate in a source network edge device, based on which the called party indicates the acceptance for the call, a first network and a second one network are connected by the source network edge device, the first network is distrusted, and the second network is a trusted network; the opening of a second gate in a terminating network edge device, based on which the called party indicates the acceptance for the call, the second network and the third network are connected by a terminating network edge device, being the third network, distrustful; and the reserved plurality of network resources is compromised after the first gate and the second gate open.

8. The method according to claim 1, characterized in that it further comprises: the opening of a first gate in an originating network edge device, on the basis that the called party indicates the acceptance for the call; the opening of a second gate in a termination network edge device based on which the called party indicates acceptance for the call; the reserved plurality of resources of the network is compromised after the first gate and the second gate are opened; and the disconnection of the first gate and the second gate when the call is terminated by at least one of the group of the calling party and the called party.

9. The method according to claim 1, characterized in that it further comprises: the opening of a first gate in an originating network edge device, on the basis that the called party indicates the acceptance for the call; 'opening a second gate in a terminating network edge device, based on which the called party indicates acceptance for the call; the reserved plurality of resources of the network is committed after the first gate and the second gate open; and the coordination of the disconnection of the first gate and the second gate substantially simultaneously when the call is terminated by at least one of the group of the calling party and the called party.

10. The method according to claim 1, characterized in that at least one from the group of the calling party and the called party is distrustful.

11. A method for allocating network resources for a call between a calling party and a called party, characterized in that it comprises: the reception, from a gate controller, of a plurality of gate parameters for the call; the establishment of a first gate for the call, based on the plurality of gate parameters, a plurality of resources of the network being reserved after the first gate is established and before any resource of the network is committed of the plurality of reserved network resources; and the opening of the first gate for the call when the called party indicates the acceptance for the call, the plurality of resources of the network for the call is committed after the first gate opens.

12. The method according to claim 11, characterized in that the plurality of resources of the network for the call are reserved based on a quality of service authorized by a service provider.

13. The method according to claim 11, characterized in that it further comprises: recording the initial use of the call, once the reserved plurality of resources of the network are compromised.

14. The method according to claim 11, characterized in that it also comprises: the record of the end of use for the call after a termination condition.

15. The method according to claim 11, characterized in that it further comprises: the reception from a source interconnection unit of a reservation request for the call; the first gate that is established after receipt of the reservation request for the call; Y the plurality of gate parameters received from the gate controller that define an authorized service quality for the call.

16. The method according to claim 11, characterized in that it further comprises: the reception of a commitment message from an interconnection unit associated with at least one of the group of the calling party and the called party, wherein the first gate is opens on a network edge device after receiving the commitment message, a first network and a second network are connected by the edge device of the network, the first network is distrustful and is associated with at least one of the group of the calling party and the called party, the second network is trusted, and the gate controller is connected to the second network.

17. The method according to claim 11, characterized in that: a commitment message is received from an interconnection unit associated with at least one of the calling party and called party group, wherein the first gate opens on a network edge device after receiving the message from commitment, a first network and a second network are connected by the edge device of the network, the first network is distrustful and is associated with at least one of the group of the calling party and the called party, the second network is trusted, the gate controller is connected to the second network, a second gate is established on a second edge device of the network, based on at least one of the group of the plurality of gate parameters and the reservation request, and the second gate engages in a second network edge device substantially simultaneously with the first gate that is engaged.

18. The method according to claim 11, characterized in that it further comprises: the disconnection of the first gate when the call is terminated by at least one of the group of the calling party and the called party.

19. The method according to claim 11, characterized in that it further comprises: the disconnection of the first gate when the call is terminated by at least one of the group of the calling party and the called party, a second gate is established in a second device network edge, based on at least one of the group of the plurality of gate parameters and the reservation request, the second gate is engaged in the second network edge device, substantially simultaneously with the first gate that is compromise, the first gate and the second gate are disconnected substantially simultaneously when the call is terminated by the minus one from the calling party group and the called party.

20. A computer-readable medium, characterized in that it has stored on it instructions to allocate resources for a call between a calling party and a called party, the instructions, when executed by a processor cause the processor: to receive, from a gate controller , a plurality of gate parameters for the call; establish a first gate for the call based on the plurality of gate parameters, a plurality of network resources that are reserved after the first gate is established and before any resource of the network is compromised, coming from the plurality of reserved network resources; and open the first gate for the call when the called party indicates an acceptance for the call, the plurality of resources of the network for the call is committed after the first gate opens.

21. A computer readable medium according to claim 20, characterized in that the plurality of network resources for the call are reserved based on a quality of service authorized by a service provider.

22. A computer readable medium according to claim 20, characterized in that it has stored on it instructions that when executed by the processor further cause the processor: to register the initial use for the call once the reserved plurality of resources of the network are engaged.

23. A computer-readable medium according to claim 20, characterized in that it has stored thereon instructions that when executed by the processor further cause the processor: to record the purpose of use for the call after a terminating condition.

24. A computer readable medium according to claim 20, characterized because it has stored on it the instructions that when executed by the processor also cause the processor: receives from a source interconnection unit a reservation request for the call, being the first one established after the reception of the reservation request for the call, and the plurality of gate parameters received from the gate controller define an authorized service quality for the call.

25. A computer readable medium according to claim 20, characterized in that it has stored thereon instructions that when executed by the processor further cause the processor: to receive a commitment message from an interconnection unit associated with at least one of the group of the calling party and the called party, wherein the first gate is opened in a network edge device after receiving the commitment message, a network and a second network are connected by the edge device of the network , the first network is distrustful and is associated with at least one of the group of the calling party and the called party, the second network is trusted, and the gate controller is connected to the second network.

26. The computer readable medium according to claim 20, characterized in that it further comprises: the reception of a commitment message from an interconnection unit associated with at least one of the group of the calling party and the called party, wherein the first gate is opened in a network edge device after receiving the commitment message, a first network and a second network are connected by the network edge device, the first network is distrustful and is associated with at least one of the first group of the calling party and the called party, the second network is trusted, the gate controller is connected to the second network, a second gate is established in the second network edge device, based on at least one of the group of the plurality of gate parameters and the reservation request, and the second gate is compromised in the second network edge device, substantially simultaneously with the first gate that is compromised.

27. A computer readable medium according to claim 20, characterized in that it has stored on it instructions that when executed by the processor further cause the processor: disconnect the first gate when the call is terminated by at least one of the group of the calling party and the called party.

28. A computer-readable medium according to claim 20, characterized in that it has stored on it instructions that when executed by the processor also cause the processor: disconnect the first gate when the call is terminated by at least one of the group of the calling party and the called party, a second gate that is established in the router of the terminating edge, based on at least one of the group of the plurality of gate parameters and the reservation request, with the second gate being engaged in the terminating edge router, substantially simultaneously with the first gate that is compromised, the first gate and the second gate are simultaneously disconnected when the call is terminated by at least one of the calling party group and the called party.

29. A method for assigning resources for a call between a calling party and a called party, characterized in that it comprises: the reception of a request for preparation from a calling party, in a controller of the gate of origin: and the sending from the controller of the origin gateway to a source network edge device, a plurality of parameters of gateway based on the readiness request, wherein the edge device of the originating network connects a first network to a second network, the resources of the network for the call are reserved based on the plurality of gate parameters, the resources reserved network are compromised when the called party indicates acceptance for the call.

30. The method according to claim 29, characterized in that the initial use for the call is recorded once the reserved resources of the network are compromised.

31. The method according to claim 29, characterized in that the purpose of use for the call is recorded after a termination condition.

32. The method according to claim 29, characterized in that it further comprises: sending, from the edge device of the originating network towards an edge device of the terminating network, the reservation request; Y the establishment of a first gate for the call in the origin edge router, based on the plurality of gate parameters, the origin edge router connects a first network to a second network, wherein the second gate for the call is established in the edge device of the terminating network, based on the reservation request, the edge device of the termination network connects the second network to a third network, the reserved resources of the network include the resources coming from the first network, the second network and the third network.

33. The method according to claim 32, characterized in that the first network and the third network are distrusted, and the second network is trusted.

34. The method according to claim 32, characterized in that it further comprises: the disconnection of the call in the first gate and in the second gate, when the call is terminated by at least one of the calling party group and the called party.

35. The method according to claim 32, characterized in that it further comprises: the coordination of the disconnection of the call in the first gate and in the second gate, substantially simultaneously when the call is terminated by at least one of the party group calling and the called party.

36. The method according to claim 29, characterized in that at least one of the group of the calling party and the called party are distrustful.

37. A computer readable medium that has stored in this instructions to allocate resources for a call between a calling party and a called party, the instructions, when executed by a processor cause the processor: receive a preparation request from a calling party at a source gate controller; and sending, from the originating gate controller to a source network edge device, a plurality of gate parameters based on the readiness request, the edge device of the originating network connects a first network to a second one. net; the resources of the network for the call are reserved based on the plurality of parameters of the gate, the resources of the reserved network being committed when the called party indicates an acceptance for the call.

38. The computer-readable medium according to claim 37, characterized in that it has stored in it instructions that when executed by the processor also cause the processor: register the use for the call once the resources of the reserved network are compromised.

39. The computer readable medium according to claim 37, characterized in that it has stored therein instructions that when executed by the processor further cause the processor: record the end of use for the call once the condition of hanging the call.

40. The computer-readable medium according to claim 37, characterized in that it has stored in it instructions. that when executed by the processor further cause the processor: to send, from the edge device of the originating network to an edge device of the terminating network, the reservation request; and establishing a first gate for the call in the origin edge router, based on the plurality of gate parameters, the origin edge router connects a first network to a second network, a second gate for the call to be established in a terminal device of the termination network, based on the request of reservation, the terminating network edge device connects the second network to a third network, the reserved resources of the network include resources from the first network, the second network and the third network.

41. The computer readable medium according to claim 37, characterized in that the first network and the third network are distrusted, and the second network is trusted.

42. The computer readable medium according to claim 37, characterized in that it has stored in it instructions that when executed by the processor further cause the processor: disconnect the call in the first gate and in the second gate, when the call is terminated by at least one of the group of the calling party and the called party.

43. The computer readable medium according to claim 37, characterized in that it has stored in it instructions that when executed by the processor they further cause the processor to: coordinate the disconnection of the call at the first gate and the second gate, substantially simultaneously when the call is terminated by at least one of the calling party group and the party call.

44. The computer readable medium according to claim 37, characterized in that at least one of the first group of the calling party and the called party are distrustful.