CA2352961C

CA2352961C - Voice over data telecommunications network architecture

Info

Publication number: CA2352961C
Application number: CA2352961A
Authority: CA
Inventors: Isaac K. Elliott; Steven P. Higgins; Andrew John Dugan; Jon Peterson; Robert L. Hernandez; Rick D. Steele; Bruce W. Baker; Rich Terpstra; Jonathan S. Mitchell; Jin-Gen Wang; Harold Stearns; Eric Zimmerer; Ray Waibel; Kraig Owen; Shawn M. Lewis
Original assignee: Level 3 Communications LLC
Current assignee: Level 3 Communications LLC
Priority date: 1998-11-20
Filing date: 1999-11-22
Publication date: 2011-02-01
Anticipated expiration: 2019-11-22
Also published as: US20080013531A1; EP2317710A3; EP1131926B1; US8089958B2; US8693347B2; CA2352961A1; US20120177195A1; US8036214B2; US20040022237A1; US8085761B2; US8270421B2; EP1131926A1; US7564840B2; US20080025294A1; US20080025295A1; AU1631900A; US20130070757A1; WO2000031933A1; EP1131926A4; EP2317711B1

Abstract

The present invention describes a system and method for communicating voice and data over a packet-switched network that is adapted to coexist and communicate with a legacy PSTN. The system permits packet switching of voice calls and data calls through a data network (112) from and to any of an LEC, a customer facility or a direct IP connection on the data network. The system includes soft switch sites (104, 106), gateway sites (108, 110), a data network (112), a provisioning component (117), a network event component (116) and a network management component (118). The system interfaces with customer facilities (128, 132) (e.g., a PBX) carrier facilities (126, 130) (e.g., an LEC) and legacy signaling networks (114) (e.g., SS7) to handle calls between any combination of on-network and off-network callers.

Description

CA 02352961 2001-05-22 f ~ f A
DEMANDES OU BREVETS VOLUMINEUX
LA PRESENTS PARTIE DE CETTE DEMANDS OU CE BREVET
COMPREND PLUS D'UN TOME.
CEC1 EST LE TOME 'I DE
NOTE: ~ Pour les tomes additionels, veuillez contacter le Bureau canadien des brevets THiS SECTION OF THE APPL1CATION/PATENT CONTAINS MORE
THAN ONE VOLUME , THIS 1S VOLUME ~ , OF
NOTE: For additional volumes please contact the Canadian Patent Office Voice Over Data Telecommunications Network Architecture Background of the Invention Field of tl:e Invention The present invention relates generally to telecommunications networks and, more particularly, to a system and method for providing transmission of voice and data traffic over a data network, including the signaling, routing and manipulation of such traffic.
Related Art The present invention relates to telecommunications, and in particular to IO voice and data communication operating over a data network. The Public Switched Telephone Network (PSTN) is a collection of different telephone networks owned by different companies which have for many years provided telephone communication betweew users of the network. Different parts of the PSTN network use different transmission media and compression techniques.
Most long distance calls are digitally coded and transmitted along a transmission line such as a TI line or fiber optic cable, using circuit switching technology to transmit the calls. Such calls are time division multiplexed (TDM) into separate channels, which allow many calls to pass over the lines without interacting. T'he channels are directed independently through multiple circuit switches from an originating switch to a destination switch. Using conventional circuit switched communications, a channel on each of the TI lines along which a call is transmitted is dedicated for the duration of the call, whether or not any information is actually being transmitted over the channel. The set of channels being used by the call is referred to as a "circuit."
Telecommunications networks were originally designed to connect one device, such as a telephone, to another device, such as a telephone, using switching services. As previously mentioned, circuit-switched networks provide a dedicated, fixed amount of capacity (a "circuit") between the two devices for the entire duration of a transmission session. Originally, this was accomplished manually. A human operator would physically patch a wire between two sockets to form a direct connection from the calling party to the called party. More recently, a circuit is set up between an originating switch and a destination switch using a process known as signaling.
Signaling sets up, monitors, and releases connections in a circuit-switched system. Various signaling methods have been devised. Telephone systems fonmerly used in-band signaling to set up and tear down calls. Signals of an in-band signaling system are passed through the same channels as the information being transmitted. Early electromechanical switches used analog or multi-frequency (MF) in-band signaling. Thereafter, conventional residential telephones used in-band dual-tone multiple frequency (DTMF) signaling to connect to an end office switch. Here, the same wires (and frequencies on the wires) were used to dial a number (using pulses or tones), as are used to transmit voice information. However, in-band signaling permitted unscrupulous callers to use a device such as a whistle to mimic signaling sounds to commit fraud (e.g., to prematurely discontinue billing by an interexchange Garner (IXC), also known as a long distance telephone company).
More recently, to prevent such fraud, out-of band signaling systems were introduced. Out-of band signaling uses a signaling network that is separate from the circuit switched network used for carrying the actual call information.
For example, integrated services digital network (ISDN) uses a separate channel, a data (D) channel, to pass signaling information out-of band. Common Channel Interoffice Signaling (CCIS) is another network architecture for out-of band signaling. A popular version of CCIS signaling is Signaling System 7 (SS7).

is an internationally recognized system optimized for use in digital telecommunications networks.
SS7 out-of band signaling provided additional benefits beyond fraud prevention. For example, out-of band signaling eased quick adoption of advanced features (e.g., caller id) by permitting modifications to the separate signaling network. In addition, the SS7 network enabled long distance "Equal Access" (i.e., 1+ dialing for access to any long distance carrier) as required under the terms of the modified final judgment (MFJ) requiring divestiture of the Regional BeII Operating Companies (RBOCs) from their parent company, AT&T.
An SS7 network is a packet-switched signaling network formed from a variety of components, including Service Switching Points (SSPs), Signaling Transfer Points (STPs) and Service Control Points (SCPs). An SSP is a telephone switch which is directly connected to an SS7 network. All calls must originate in or be routed through an SSP. Calls are passed through connections between SSPs. An SCP is a special application computer which maintains information in a database required by users of the network. SCP databases may include, for example, a credit card database for verifying charge information or an "800" database for processing number translations for toll-free calls. STPs pass or route signals between SSPs, other STPs, and SCPs. An STP is a special application packet switch which operates to pass signaling information.
The components in the SS7 network are connected together by links.
Links between SSPs and STPs can be, for example, A, B, C, D, E or F links.
Typically, redundant links are also used for connecting an SSP to its adjacent STPs. Customer premises equipment (CPE), such as a telephone, are connected to an SSP or an end office (EO) switch.
To initiate a call in an SS7 telecommunications network, a calling party using a telephone connected to an originating EO switch, dials a telephone number of a called party. The telephone number is passed from the telephone to the SSP at the originating EO (referred to as the "ingress EO") of the calling party's local exchange carrier (LEC). A LEC is commonly referred to as a local telephone company. First, the SSP will process triggers and internal route rules based on satisfaction of certain criteria. Second, the SSP will initiate further S signaling messages to another EO or access tandem (AT), if necessary. The signaling information can be passed from the SSP to STPs, which route the signals between the ingress EO and the terminating end office, or egress EO.
The egress EO has a port designated by the telephone number of the called party.
The call is set up as a direct connection between the EOs through tandem switches if I 0 no direct trunking exists or if direct trunking is full. If the call is a long distance call, i.e., between a calling party and a called party located in different local access transport areas (LATAs), then the call is connected through an inter exchange Garner (IXC) switch of any of a number of long distance telephone companies. Such a long distance call is commonly referred to as an inter-LATA
15 call. LECs and IXCs are collectively referred to as the previously mentioned public switched telephone network (PSTN).
Emergence of competitive LECs (CLECs) was facilitated by passage of the Telecommunications Act of 1996, which authorized competition in the local phone service market. Traditional LECs or RBOCs are now also known as 20 incumbent LECs (ILECs). Thus, CLECs compete with ILECs in providing local exchange services. This competition, however, has still not provided the bandwidth necessary to handle the large volume of voice and data communications. This is due to the limitations of circuit switching technology which limits the bandwidth of the equipment being used by the LECs, and to the 25 high costs of adding additional equipment.
Since circuit switching dedicates a channel to a call for the duration of the call, a large amount of switching bandwidth is required to handle the high volume of voice calls. This problem is exacerbated by the fact that the LECs must also handle data communications over the same equipment that handle voice 30 communications.

W.O 00/31933 PCT/US99/27658 -S-If the PSTN were converted to a packet-switched network, many of the congestion and limited bandwidth problems would be solved. However, the LECs and IXCs have invested large amounts of capital in building, upgrading and maintaining their circuit switched networks (known as "legacy" networks) and are S unable or unwilling to jettison their legacy networks in favor of the newer, more powerful technology of packet switching. Accordingly, a party wanting to build a packet-switched network to provide voice and data communications for customers must build a network that, not only provides the desired functionality, but also is fully compatible with the SS7 and other, e.g., ISDN and MF, switching I 0 networks of the legacy systems.
Currently, internets, intranets. and similar public or private data networks that interconnect computers generally use packet switching technology. Packet switching provides for more efficient use of a communication channel as compared to circuit switching. With packet switching, many different calls (e.g., IS voice, data, video, fax, Internet, etc.) can share a communication channel rather than the channel being dedicated to a single call. For example, during a voice call, digitized voice information might be transferred between the callers only SO% of the time, with the other SO% being silence. For a data call, information might be transferred between two computers 10% of the time. With a circuit 20 switched connection, the voice call would tie-up a communications channel that may have SO% of its bandwidth being unused. Similarly, with the data call, 90%
of the channel's bandwidth may go unused. In contrast, a packet-switched connection would permit the voice call, the data call and possibly other call information to all be sent over the same channel.
2S Packet switching breaks a media stream into pieces known as, for example, packets, cells or frames. Each packet is then encoded with address information for delivery to the proper destination and is sent through the network.
The packets are received at the destination and the media stream is reassembled into its original form for delivery to the recipient. This process is made possible WO 00/31933 PCT/US99l27658 using an important family of communications protocols, commonly called the Internet Protocol (IP).
In a packet-switched network, there is no single, unbroken physical connection between sender and receiver. The packets from many different calls share network bandwidth with other transmissions. The packets are sent over many different routes at the same time toward the destination, and then are reassembled at the receiving end. The result is much more efficient use of a telecommunications network than could be achieved with circuit-switching.
Recognizing the inherent efficiency of packet-switched data networks such as the Internet, attention has focused on the transmission of voice information over packet-switched networks. However, such systems are not compatible with the legacy PSTN and therefore are not convenient to use.
One approach that implements voice communications over an IP network requires that a person dial a special access number to access an IP network.
Once the IP network is accessed, the destination or called number can be dialed.
This type of call is known as a gateway-type access call.
Another approach involves a user having a telephone that is dedicated to an IP network. This approach is inflexible since calls can only be made over the IP network without direct access to the PSTN.
What is needed is a system and method for implementing packet-switched communications for both voice calls and data calls that do not require special access numbers or dedicated phones and permit full integration with the legacy PSTN.

Summary of the Invention The present invention is a system and method for communicating both voice and data over a packet-switched network that is adapted to coexist and communicate with a PSTN. The system permits efficient packet switching of voice calls and data calls from a PSTN Garner such as, for example, a LEC, IXC, a customer facility or a direct IP connection on the data network to any other LEC, IXC, customer facility or direct IP connection. For calls from a PSTN
Garner, e.g., LEC or IXC, the invention receives signaling from the legacy SS7 signaling network or the ISDN D-channel or from inband signaling trunks. For calls from a customer facility, data channel signaling or inband signaling is received. For calls from a direct IP connection on the data network, signaling messages can travel over the data network. On the call destination side, similar signaling schemes are used depending on whether the called party is on a PSTN
carrier, a customer facility or a direct IP connection to the data network.
The system includes soft switch sites, gateway sites, a data network. a provisioning component a network event component and a network management component. The system of the invention interfaces with customer facilities (e.g., a PBX), carrier facilities (e.g., a PSTN carrier, a LEC (e.g., ILECs and CLECs), an independent telephone company (ITC), an IXC, an intelligent peripheral or an enhanced service provider (ESP)) and legacy signaling networks (e.g., SS7) to handle calls between any combination of on-network and off network callers.
The soft switch sites provide the core call processing for the voice network architecture. Each soft switch site can process multiple types of calls including calls originating from or terminating at off network customer facilities as well as calls originating from or terminating at on-network customer facilities.
Each soft switch site receives signaling messages from and sends signaling messages to the signaling network. The signaling messages can include, for example, SS7, integrated services digital network (ISDN) primary rate interface _g_ (PRI) and in-band signaling messages. Each soft switch site processes these signaling messages for the purpose of establishing new calls through the data network and tearing down existing calls and in-progress call control functions.
Signaling messages can be transmitted between any combination of on-network and off network callers.
Signaling messages for a call which either originates off network or terminates off network can be carried over the out-of band signaling network of the PSTN via the soft switch sites. Signaling messages for a call which both originates on-network and terminates on-network can be carned over the data network rather than through the signaling network.
The gateway sites originate and terminate calls between calling parties and called parties through the data network. The soft switch sites control or manage the gateway sites. In a preferred embodiment, the soft switch sites use a protocol such as, for example, the Internet Protocol Device Control (IPDC) protocol, to 1 S manage network access devices in the gateway sites to request the set-up and tear-down of calls. However, other protocols could be used, including, for example, network access server messaging interface (NMI) and the ITU media gateway control protocol (MGCP).
The gateway sites can also include network access devices to provide access to network resources (i.e., the communication channels or circuits that provide the bandwidth of the data network). The network access devices can be referred to generally as access servers or media gateways. Exemplary access servers or media gateways are trunking gateways (TGs), access gateways (AGs) and network access servers (NASs). The gateway sites provide for transmission of both voice and data traffic through the data network. The gateway sites also provide connectivity to other telecommunications carriers via trunk interfaces to carrier facilities for the handling of voice calls. The trunk interfaces can also be used for the termination of dial-up modem data calls. The gateway sites can also provide connectivity via private lines and dedicated access lines (DALs), such as T1 or ISDN PRI facilities, to customer facilities.

The data network connects one or more of the soft switch sites to one or more of the gateway sites. The data network routes data packets through routing devices (e.g., routers) to destination sites (e.g., gateway sites and soft switch sites) on the data network. For example, the data network routes Internet protocol (IP) packets for transmission of voice and data traffic from a first gateway site to a second gateway site. The data network represents any art-recognized data network including the global Internet, a private intranet or intemet, a frame relay network, and an asynchronous transfer mode (ATM) network.
The network event component collects call events recorded at the soft switch sites. Call event records can be used, for example, for fraud detection and prevention, and billing.
The provisioning event component receives provisioning requests from upstream operational support services (OSS) systems such as, for example, for order-entry, customer service and customer profile changes. The provisioning component distributes provisioning data to appropriate network elements and maintains data synchronization, consistency, and integrity across multiple soft switch sites.
The network management component includes a network operations center (NOC) for centralized network management. Each network element(NE) (e.g., soft switch sites, gateway sites, provisioning, and network event components, etc.) generates simple network management protocol (SNMP) events or alerts. The NOC uses the events generated by each network element to determine the health of the network and to perform other network management functions.
In a preferred embodiment, the invention operates as follows to process, for example, a long distance call (also known as a 1+ call). First, a soft switch site receives an incoming call signaling message from the signaling network.
The soft switch site determines the type of call by performing initial digit analysis on the dialed number. Based upon the information in the signaling message, the soft switch site analyzes the initial digit of the dialed number of the call and determines that it is a I + call. The soft switch site then queries a customer profile database to retrieve the originating trigger plan associated with the calling customer. The query can be made using, for example, the calling party number S provided in the signaling message from the signaling network. This look-up in the customer profile database returns subscription information. For example, the customer profile may indicate that the calling party has subscribed to an account code verification feature that requires entry of an account code before completion of the call. In this case, the soft switch site will instruct the gateway site to collect the account code digits entered by the calling party. Assuming that the gateway site collects the correct number of digits, the soft switch site can use the customer profile to determine how to process the received digits. For account code verification, the soft switch site verifies the validity of the received digits.
Verification can result in the need to enforce a restriction, such as a class of service (COS) restriction (COSR). In this example, the soft switch site can verify that the account code is valid, but that it requires that an intrastate COSR
should be enforced. This means that the call is required to be an intrastate call to be valid. The class of service restriction logic can be performed within the soft switch site using, for example, pre-loaded local access and transport areas (LATAs) and state tables. The soft switch would then allow the call to proceed if the class of service requested matches the authorized class of service. For example, if the LATH and state tables show that the LATH of the originating party and the LATA of the terminating party are in the same state, then the call can be allowed to proceed. The soft switch site then completes customer service processing and prepares to terminate the call. At this point, the soft switch site has f nished executing all customer service logic and has a 10-digit dialed number that must be terminated. To accomplish the termination, the soft switch site determines the terminating gateway. The dialed number (i.e., the number of the called party dialed by the calling party) is used to select a termination on the data network. This termination may be selected based on various performance, availability or cost criteria. The soft switch site then WO 00/31933 PC'f/US99/27658 communicates with a second soft switch site associated with the called party to request that the second soft switch site allocate a terminating circuit or trunk group in a gateway site associated with the called party. One of the two soft switch sites can then indicate to the other the connections that the second soft S switch site must make to connect the call. The two soft switch sites then instruct the two gateway sites to make the appropriate connections to set up the call.
The soft switch sites send messages to the gateway sites through the data network using, for example, IPDC protocol commands. Alternately, a single soft switch can set up both the origination and termination.
10. The present invention provides a number of important features and advantages. First, the invention uses application logic to identify and direct incoming data calls straight to a terminating device. This permits data calls to completely bypass the egress end office switch of a LEC. This results in significant cost savings for an entity such as an Internet service provider (ISP), 15 ILEC, or CLEC. This decrease in cost results partially from bypass of the egress ILEC end office switch for data traffic.
A further advantage for ISPs is that they are provided data in the digital form used by data networks (e.g., IP data packets), rather than the digital signals conventionally used by switched voice networks (e.g., PPP signals).
20 Consequently, the ISPs need not perform costly modem conversion processes that would otherwise be necessary. The elimination of many telecommunications processes frees up the functions that ISPs, themselves, would have to perform to provide Internet access.
Another advantage of the present invention is that voice traffic can be 25 transmitted transparently over a packet-switched data network to a destination on the PSTN.
Yet another advantage of the invention is that a very large number of modem calls can be passed over a single channel of the data network, including calls carrying media such as voice, bursty data, fax, audio, video, or any other data formats.
Further features and advantages of the invention, as well as the structure and operation of various embodiments of the invention, are described in detail below with reference to the accompanying figures.
Brief Description of the Figures The present invention will be described with reference to the accompanying figures, wherein:
FIG. I is a high level view of the Telecommunications Network of the present invention;
FIG. 2A is an intermediate level view of the Telecommunications Network of the present invention;
FIG. 2B is an intermediate level operational call flow of the present invention;
FIG. 3 is a specific example embodiment of the telecommunications network including three geographically diverse soft switch sites and multiple geographically diverse or collocated gateway sites;
FIG. 4A depicts a block diagram illustrating the interfaces between a soft switch and the remaining components of a telecommunications network;
FIG. 4B provides a Soft Switch Object Oriented Programming (OOP) CIass Definition;
FIG. 4C provides a Call OOP Class Definition;
FIG. 4D provides a Signaling Messages OOP Class Definition;

WO 00/31933 PC'f/US99/27658 FIG. 4E provides an IPDC Messages OOP Class Definition;
FIG. 4F depicts a block diagram of interprocess communication including the starting of a soft switch command and control functions by a network operations center;
FIG. 4G depicts a block diagram of soft switch command and control startup by a network operations center sequencing diagram;
FIG. 4H depicts a block diagram of soft switch command and control registration with configuration server sequencing diagram;
FIG. 4I depicts a block diagram of soft switch accepting configuration infonmation from configuration server sequencing diagram:
FIG. SA depicts a detailed block diagram of an exemplary soft switch site including two SS7 Gateways communicating with a plurality of soft switches which are in turn communicating with a plurality of Gateway sites;
FIG. SB provides a Gateway Messages OOP Class Definition;
FIG. SC depicts a block diagram of interprocess communication including soft switch interaction with SS7 gateways;
FIG. SD depicts a block diagram of interprocess communication including an access server signaling a soft switch to register with SS7 gateways;
FIG. SE depicts a block diagram of a soft switch registering with SS7 gateways sequencing diagram;
FIG. 6A depicts an Off Switch Call Processing Abstraction Layer for interfacing with a plurality of on-network and off network SCPs;
FIG. 6B depicts an Intelligent Network Component (INC) Architecture;
FIG. 6C depicts an INC architecture including On-net Services Control Points (SCPs);

FIG. 6D depicts an INC architecture including On-net and Off net SCPs and customer Automatic Call Distributors (ACDs);
FIG. 7A provides a Configuration Server OOP Class Definition;
FIG. 7B depicts a block diagram of interprocess communication including soft switch interaction with configuration server;
FIG. 8A depicts Route Server Support for a Soft Switch Site including a plurality of collocated or geographically diverse route servers, soft switches, and Trunking Gateway and Access gateway sites;
FIG. 8B provides a Route Server OOP Class Definition;
FIG. 8C provides a Route Objects OOP Class Definition;
FIG. 8D provides a Pools OOP Class Definition;
FIG. 8E provides a Circuit Objects OOP Class Definition;
FIG. 8F depicts a block diagram of interprocess communication including soft switch interaction with route server (RS);
FIG. 9 depicts a block diagram of an exemplary Regional Network Event Collection Point Architecture (RNECP) including a master data center having a plurality of master network event database servers;
FIG. 1 OA depicts a detailed block diagram of an exemplary gateway site;
FIG. lOB depicts a block diagram of interprocess communication including soft switch interaction with access servers;
FIG. I lA depicts a detailed block diagram of an exemplary Trunking Gateway High-Level Functional Architecture;
FIG. 11 B depicts a detailed flow diagram overviewing a Gateway Common Media Processing Component on the Ingress side of a trunking gateway;

- I S-FIG. 1 I C depicts a detailed flow diagram overviewing a Gateway .
Common Media Processing Component on the Egress side of a trunking gateway;
FIG. 12 depicts a detailed block diagram of an exemplary Access Gateway High-Level Functional Architecture;
FIG. I 3 depicts a detailed block diagram of an exemplary Network Access Server High-Level functional architecture;
FIG. 14 depicts an exemplary digital cross connect system (DACS);
FIG. I S depicts an exemplary Announcement Server Component Interface Design;
1 ~ FIG. 16A depicts an exemplary data network interconnecting a plurality of gateway sites and a soft switch site;
FIG. 16B depicts a exemplary logical view of an Asynchronous Transfer Mode (ATM) network;
FIG. 17A depicts an exemplary signaling network including a plurality of 15 signal transfer points (STPs) and SS7 gateways;
FIG. 17B depicts another exemplary embodiment showing connectivity to an SS7 signaling network;
FIG. 17C depicts a block diagram of an SS7 signaling network architecture;
20 FIG. 18 depicts a block diagram of the provisioning and network event components;
FIG. 19A depicts a block diagram of a data distributor in communication with a plurality of voice network elements;

FIG. 19B depicts a more detailed description of a data distributor architecture including voice network elements and upstream operational support services applications;
FIG. 19C depicts an exemplary embodiment of a data distributor and voice network elements;
FIG. 19D depicts a block diagram of provisioning interfaces into the SCPs from the data distributor;
FIG. 19E illustrates a data distributor including BEA M3, a CORBA-compliant interface server 1936 with an imbedded TUXEDO layer;
FIG. 19F depicts a detailed example embodiment block diagram of the BEA M3 data distributor of the provisioning element;
FIG. 19G depicts a block diagram illustrating a high level conceptual diagram of the BEA M3 CORBA-compliant interface;
FIG. 19H depicts a block diagram illustrating additional components of the high level conceptual diagram of the BEA M3 CORBA-compliant interface;
FIG. 19I depicts a block diagram illustrating a data distributor sending data to configuration server sequencing diagram;
FIG. 20 depicts a block diagram of a Master Network Event Database (MNEDB) interfacing to a plurality of database query applications;
FIG. 21 A depicts an exemplary network management architecture;
FIG. 21B depicts an outage recovery scenario illustrating the occurrence of a fiber cut, latency or packet loss failure in the Data Network;
FIG. 21 C depicts an outage recovery scenario including a complete-gateway site outage;

FIG. 21 D further depicts an outage recovery scenario including a complete-gateway site outage:
FIG. 21E depicts an outage recovery scenario including a complete soft switch site outage;
FIG. 21 F further depicts an outage recovery scenario including a complete soft switch site outage;
FIG. 21 G depicts a block diagram of interprocess communication including a NOC communicating with a soft switch;
FIG. 22A depicts a high-level operational call flow;
FIG. 22B depicts a more detailed call flow;
FIG. 22C depicts an even more detailed call flow;
FIG. 23A depicts an exemplary voice call originating and terminating via SS7 signaling on a Trunking Gateway;
FIG. 23B depicts an exemplary data call originating on a SS7 trunk on a franking gateway (TG);
FIG. 23C depicts an exemplary voice catl originating on a SS7 trunk on a franking gateway and terminating via access server signaling on an access gateway (AG);
FIG. 23D depicts an exemplary voice call originating on an SS7 trunk on a franking gateway and terminating on an announcement server (ANS);
FIG. 24A depicts an exemplary voice call originating on an SS7 trunk on a network access server and terminating on a franking gateway;
FIG. 24B Data Call originating on an SS7 trunk and terminating on a NAS;

FIG. 24C depicts an exemplary voice call originating on an SS7 trunk on a NAS and terminating via access server signaling on an AG;
FIG. 24D depicts an exemplary data call on a NAS with callback outbound reorigination;
FIG. 25A depicts an exemplary voice call originating on access server trunks on an AG and terminating on access server trunks on an AG;
FIG. 25B depicts an exemplary data call on an AG;
FIG. 25C depicts an exemplary voice call originating on access server trunks on an AG and terminating on SS7 signaled trunks on a TG;
I 0 FIG. 25D depicts an exemplary outbound data call from a NAS via access server signaling to an AG;
FIG. 26A depicts a more detailed diagram of message flow for an exemplary voice call received over a TG;
FIG. 26B depicts a more detailed diagram of message flow for an exemplary voice call received over a NAS;
FIG. 26C depicts a more detailed diagram of message flow for an exemplary data call over a NAS;
FIGs. 27-57 depict detailed sequence diagrams demonstrating component intercommunication during a voice call received on a NAS or TG or a data call received on a NAS;
FIG. 27 depicts a block diagram of a call flow showing a soft switch accepting a signaling message from an SS7 gateway sequencing diagram;
FIG. 28 depicts a block diagram of a call flow showing a soft switch getting a call context message from an IAM. signaling message sequencing diagram;

FIG. 29A depicts a block diagram of a call flow showing a soft switch processing an IAM signaling message including sending a request to a route server sequencing diagram;
FIG. 29B depicts a block diagram of a call flow showing a soft switch starting processing of a route request sequencing diagram;
FIG. 30 depicts a block diagram of a call flow showing a route server determining a domestic route sequencing diagram;
FIG. 31 depicts a block diagram of a call flow showing a route server checking availability of potential terminations sequencing diagram;
FIG. 32 depicts a block diagram of a call flow showing a route server getting an originating route node sequencing diagram;
FIG. 33A depicts a block diagram of a call flow showing a route server calculating a domestic route for a voice call sequencing diagram;
FIG. 33B depicts a block diagram of a call flow showing a route server calculating a domestic route for a voice call sequencing diagram;
FIG. 34 depicts a block diagram of a call flow showing a soft switch getting a call context from a route response from a route server sequencing diagram;
FIG. 35 depicts a block diagram of a call flow showing a soft switch processing an IAM message including sending an IAM to a terminating network sequencing diagram;
FIG. 36 depicts a block diagram of a call flow showing a soft switch processing an ACM message including sending an ACM to an originating network sequencing diagram;

FIG. 37 depicts a block diagram of a call flow showing a soft switch processing an ACM message including the setup of access devices sequencing diagram;
FIG. 38 depicts a block diagram of a call flow showing an example of how a soft switch can process an ACM sending an RTP connection message to the originating access server sequencing diagram;
FIG. 39 depicts a block diagram of a call flow showing a soft switch processing an ANM message sending the ANM to the originating SS7 gateway sequencing diagram;
FIG. 40 depicts a block diagram of a call teardown flow showing a soft switch processing an REL message with the terminating end initiateing teardownsequencing diagram;
FIG. 41 depicts a block diagram of a call flow showing a soft switch processing an REL message tearing down all nodes sequencing diagram;
FIG. 42 depicts a block diagram of a call flow showing a soft switch processing an RLC message with the terminating end initiating teardown sequencing diagram;
FIG. 43 depicts a block diagram of a call flow showing a soft switch sending an unallocate message to route server for call teardown sequencing diagram;
FIG. 44 depicts a block diagram of a call flow showing a soft switch unallocating route nodes sequencing diagram;
FIG. 45 depicts a block diagram of a call flow showing a a soft switch processing call teardown and deleting call context sequencing diagram;
FIG. 46 depicts a block diagram of a call flow showing a route server calculating a domestic route sequencing diagram for a voice call on a NAS;

FIG. 47 depicts a block diagram of a call flow showing a soft switch getting call context from route response sequencing diagram;
FIG. 48 depicts a block diagram of a call flow showing a soft switch processing an IAM sending the IAM to the terminating network sequencing diagram;
FIG. 49 depicting a block diagram of a call flow showing calculation of a domestic route for a data call sequencing diagram;
FIG. 50 depicts a block diagram of a call flow showing a soft switch getting call context from route response sequencing diagram;
FIG. 51 depicts a block diagram of a call flow showing a soft switch processing an IAM connnecting the data call sequencing diagram;
soft switch receiving and acknowledging receipt of a signaling message from an SS7 GW sequencing diagram;
FIG. 52 depicts a block diagram of a call flow showing a soft switch IS processing an ACM message including sending an ACM to an originating network sequencing diagram;
FIG. 53 depicts a block diagram of a call flow showing a soft switch processing an ANM message including sending an ANM to an originating network sequencing diagram;
FIG. 54 depicts a block diagram of a call flow showing a soft switch processing an RCR message sequencing diagram;
FIG. 55 depicts a block diagram of a call flow showing a soft switch processing an RLC message sequencing diagram;
FIG. 56 depicts a block diagram of a call flow showing a soft switch processing an ACM message sending an ACM to the originating network sequencing diagram;

FIG. 57 depicts a block diagram of a call flow showing a soft switch processing an IAM setting up access servers;
FIG. 58A depicts a block diagram of the H.323 architecture for a network-based communications system defining four major components, including, terminals, gateways, gatekeepers, and multipoint control units;
FIG. 58B depicts an exemplary H.323 terminal;
FIG. 59 shows an example H.323/PSTN Gateway;
FIG. 60 depicts an example collection of all terminals, gateways, and multipoint control units which can be managed by a single gatekeeper, i 0 collectively known as an H.323 Zone;
FIG. 61 depicts an exemplary MCU of the H.323 architecture;
FIG. 62 depicts a block diagram showing a soft switch in communication with an access server;
FIG. 63 depicts a flowchart of an Access Server Side Inbound Call 1 S Handling state diagram;
FIG. 64A depicts a flowchart of an Access Server Side Exception Handling state diagram;
FIG. 64B further depicts a flowchart of an Access Server Side Exception Handling state diagram;
20 FIG. 65 depicts a flowchart of an Access Server Side Release Request Handling state diagram;
FIG. 66 depicts a flowchart of an Access Server Side TDM Connection Handling state diagram;
FIG. 67A depicts a flowchart of an Access Server Side Continuity Test 25 Handling state diagram;

w0 00/31933 PCT/US99/27658 FIG. 67B further depicts a flowchart of an Access Server Side Continuity Test Handling state diagram;
FIG. 68A depicts a flowchart of an Access Server Side Outbound Call Handling Initiated by Access Server state diagram;
FIG. 68B further depicts a flowchart of an Access Server Side Outbound Call Handling Initiated by Access Server state diagram;
FIG. 69 depicts a flowchart of an Access Server Outbound Call Handling Initiated by Soft Switch state diagram;
FIG. 70A depicts an exemplary diagram of an OOP Class Definition; and I 0 FIG. 70B depicts an exemplary computer system of the present invention.
In the figures, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The figure in which an element first appears is indicated by the leftmost digits) in the reference number.

Detailed Description of the Preferred Embodiments I. High level description This section provides a high-level description of the voice over IP network architecture according to the present invention. In particular, a structural implementation of the voice over IP (VOIP) network architecture is described at a high-level. Also, a functional implementation for this structure is described at a high-level. This structural implementation is described herein for illustrative purposes, and is not limiting. In particular, the process described in this section can be achieved using any number of structural implementations, one of which is described in this section. The details of such structural implementations will be apparent to persons skilled in the relevant arts based on the teachings contained herein.
A. Structural description FIG. I is a block diagram 100 illustrating the components of the VOIP
architecture at a high-level. FIG. 1 includes soft switch sites 104, 106, gateway sites 108, 110, data network 1I2, signaling network 114, network event component 116, provisioning component I17 and network management component 118.
Included in FIG. 1 are calling parties 102,122 and called parties 120,124.
Calling parties 102, 122 are homed to gateway site 108. Calling parties 102, are homed to gateway site 108. Called parties 120, 124 are homed to gateway site 110. Calling party 102 can be connected to gateway site 108 via trunks from carrier facility 126 to gateway site 108. Similarly, called party 120 can be connected to gateway site 110 via trunks from carrier facility I 30 to gateway site -'75-1 I 0. Calling party 122 can be connected to gateway site 108 via a private line or dedicated access line (DAL) from customer facility 128 to gateway site 108.
Similarly, called party 124 can be connected to gateway site I 10 via a private line or a DAL from customer facility 132 to gateway site 110.
Calling party 102 and called party 120 are off network, meaning that they are connected to gateway sites 108, 110 via the Public Switched Telephone Network (PSTN) facilities. Calling party 122 and called party 124 are on-network, meaning that connect to gateway sites 108, 110 as direct customers.
1. Soft Switch Sites Soft switch sites 104, 106 provide the core call processing for the voice network architecture. Soft switch sites 104, 106 can process multiple types of calls. First, soft switch sites 104, 106 can process calls originating from or terminating at on-network customer facilities 128, I 32. Second, soft switch sites 104, 106 can process calls originating from or terminating at off network customer facilities 126, 130.
Soft switch sites 104, 106 receive signaling messages from and send signaling messages to signaling network 114. For example, these signaling messages can include SS7, primary rate interface (PRI) and in-band signaling messages. Soft switch sites 104, 106 process these signaling messages for the purpose of establishing new calls from calling parties 102, 122 through data network 112 to called parties 120, 124. Soft switch sites 104, 106 also process these signaling messages for the purpose of tearing down existing calls established between calling parties 102, 122 and called parties 120, 124 (through data network 112).
Calls can be transmitted between any combination of on-network and off network callers.

In one embodiment, signaling messages for a call which eiti~er originates from an off network calling party 102, or terminates to an off=network called party 120, can be carried over out-of band signaling network 1 I4 from the PSTN
to soft switches 104, 106.
In another embodiment, signaling messages for a call which either originates from an on-network calling party I22, or terminates to on-network called party 124, can be carried in-band over data network 112 or over a separate data network to soft switch sites 104, 106, rather than through signaling network I 14.
IO Soft switch sites 104, 106 can be collocated or geographically diverse.
Soft switch sites 104,106 can also be connected by redundant connections to data network 112 to enable communication between soft switches 104, 106.
Soft switch sites 104, 106 use other voice network components to assist with the processing of calls. For example, gateway sites 108, 110 provide the means to originate and terminate calls on the PSTN. In a preferred embodiment, soft switch sites 104, 106 use the Internet Protocol Device Control (IPDC) protocol to control network access devices known as media gateways in gateway sites 108, 110, and to request, for example, the set-up and tear-down of calls.
The IPDC protocol is described below with reference to Tables 144-185.
Alternatively, any protocol understood by those skilled in the art can be used to control gateway sites 108, 110. One example of an alternative protocol is the Network Access Server (NAS) Messaging Interface (NMI) Protocol, discussed in U.S. Patent Application entitled "System and Method for Bypassing Data from Egress Facilities", filed concurrently herewith, Attorney Docket No.
1757.0060000 , the contents of which are incorporated herein by reference in their entirety. Another example of a protocol is the Media Gateway Control Protocol (MGCP) from the Internet Engineering Task Force (IETF).

Soft switch sites 104, 106 can include other network components such as a soft switch, which more recently can also be known as a media gateway controller, or other network devices.
2. Gateway Sites Gateway sites 108, I 10 provide the means to originate and terminate calls between calling parties 102,122 and called parties I 20,124 through data network 112. For example, calling party 122 can originate a call terminated to off network called party 120, which is homed to gateway site 1 I O via carrier facility 130.
Gateway sites I08, 110 can include network access devices to provide access to network resources. An example of a network access device is an access server which is more recently commonly known as a media gateway. These devices can include trunking gateways, access gateways and network access servers. Gateway sites 108, 110 provide for transmission of, for example, both voice and data traffic through data network 1 I2.
I S Gateway sites 108, 110 are controlled or managed by one or more soft switch sites 104, 106. As noted, soft switch sites I 04, I 06 can communicate with gateway sites 108, 110 via the IPDC, NMI, MGCP, or alternative protocols.
Gateway sites 108, 110 can provide trunk interfaces to other telecommunication carriers via carrier facilities 126,130 for the handling of voice calls. The trunk interfaces can also be used for the termination of dial-up modem data calls. Gateway sites 108, 110 can also provide private lines and dedicated access lines, such as T1 or ISDN PRI facilities, to customer facilities 128, 132.
Examples of customer facilities 128,132 are customer premises equipment (CPE) such as, for example, a private branch exchange (PBX).
Gateway sites 108, 110 can be collocated or geographically diverse from one another or from other network elements (e.g. soft switch sites 104, 106).

Gateway sites 108, 110 can also be connected by redundant connections to data .
network 112 to enable communication with and management by soft switches 104, 106.
3. Data Network Data network 112 connects one or more soft switch sites 104, 106 to one or more gateway sites 108, 110. Data Network 112 can provide for routing of data through routing devices to destination sites on data network 112. For example, data network l I2 can provide for routing of Internet protocol (IP) packets for transmission of voice and data traffic from gateway site 108 to gateway site 110. Data Network 112 represents any art-recognized data network.
One well-known data network is the global Internet. Other examples include a private intranet, a packet-switched network, a frame relay network, and an asynchronous transfer mode (ATM) network.

4. Signaling Network Signaling network 114 is an out-of band signaling network providing for transmission of signaling messages between the PSTN and soft switch sites 104, 106. For example, signaling network 114 can use Common Channel Interoffice Signaling (CCIS), which is a network architecture for out-of band signaling. A
popular version of CCIS signaling is Signaling System 7 (SS7). SS7 is an internationally recognized system optimized for use in digital telecommunications networks.

5. Network Event Component Network event component 1 I6 provides for collection of call events recorded at soft switch sites 104, 106. Call event records can be used, for example, for fraud detection and prevention, traffic reporting and billing.

6. Provisioning Component Provisioning component 117 provides several functions. First, provisioning component I I7 receives provisioning requests from upstream operational support services (OSS) systems, for such items as order-entry, customer service, and customer profile changes. Second, provisioning component l I7 distributes provisioning data to appropriate network elements. Third, provisioning component 117 maintains data synchronization, consistency, and integrity across multiple soft switch sites 104, 106.

7. Network Management Component Network management component 118 can include a network operations center (NOC) for centralized network management. Each network element(NE}
of block diagram 100 can generate simple network management protocol (SNMP) events or alerts. The NOC uses the events generated by a NE to determine the health of the network, and to perform other network management functions.

WO 00/31933 PCfNS99/27658 B. Operational description The following operational flows describe an exemplary high level call scenario for soft switch sites 104, 106 and is intended to demonstrate at a high architectural level how soft switch sites 104, 106 process calls. The operational S flow of the present invention is not to be viewed as limited to this exemplary illustration.
As an illustration, FIG. 22A depicts a simple operational call flow chart describing how soft switch sites 104, 106 can process a Iong distance call, also known as a 1+ call. The operational call flow of FIG. 22A begins with step 2202, in which a soft switch site receives an incoming signaling message. The call starts by soft switch site 104 receiving an incoming signaling message from Garner facility 126 via signaling network 114, indicating an incoming call from calling party 102.
In step 2204, the soft switch site determines the type of call by performing initial digit analysis. Based upon the information in the signaling message, the soft switch site 104 analyzes the initial digit of the dialed number of the call and determines that it is a 1+ call.
In step 2222, soft switch site 104 can select a route termination based on the dialed number (i.e., the number of called party 120 dialed by calling party 102) using least cost routing. This route termination can involve termination off data network 1 I 2 or off onto another data network. Soft switch site 104 can then communicate with soft switch site 106 to allocate a terminating circuit in gateway site 1 I 0 for this call.
In step 2224, soft switch site 104 can indicate connections to be made to complete the call. Soft switch site 104 or soft switch site 106 can return a termination that indicates the connections that must be made to connect the call.

In step 2226, soft switch sites 104, 106 instruct the gateway sites to make connections to set up the call. Soft switch sites 104, 106 can send messages through data network 112 (e.g. using IPDC protocol commands) to gateway sites 108, 110, to instruct the gateway sites to make the necessary connections for S setting up the call origination from calling party 102, the call termination to called party 120, and the connection between origination and termination.
In step 2228, soft switch sites I 04, 106 generate and send network events to a repository. Soft switch sites 104, I 06 can generate and send network events to network event component 116 that are used, for example, in detecting and preventing fraud, and in performing billing.
In step 2230, network management component 118 monitors the telecommunications network 100. All network elements create network management ever. is such as SNMP protocol alerts or events. Network management component I I 8 can monitor SNMP events to enable management 1 S of network resources.
FIG. 22B details a more complex operational call flow describing how soft switch sites 104, 106 process a long distance call. FIG. 22B inserts steps 2206, 2208 and 2220 between steps 2204 and 2222 of FIG. 22A.
The operational call floe of FIG. 22B begins with step 2202, in which a soft switch site receives an incomy~g signaling message. The call starts by soft switch site 104 receiving an incominL signaling message from carrier facility via signaling network 114, indicating an incoming call from calling party 102.
In step 2204, the soft switch site determines the type of call by performing initial digit analysis. Based upon the information in the signaling message, the soft switch site 104 analyzes the initial digit of the dialed number of the call and determines that it is a I + call.
In step 2206, the soft switch site queries a customer profile database to retrieve the originating trigger plan associated with the calling customer.
With a 1 + type of cal l, the logic within the soft switch knows to query the customer profile database within soft switch site 104 to retrieve the originating trigger plan for the calling party. The step 2206 query can be made using the calling party number. The customer profile lookup is performed using as the lookup key, the originating number, i.e., the number of calling party 102, provided in the signaling message from signaling network 114.
In step 2208, the lookup returns subscription information. For example, the customer profile can require entry of an account code. In this example, the customer profile lookup can return an indication that the customer, i.e., calling party 102, has subscribed to an account code verification feature. A class of service restriction can also be enforced, but this will not be known until account code verification identifies an associated account code.
In step 2220, soft switch site 104 completes customer service processing and prepares to terminate the call. At this point, soft switch site 104 has finished executing all customer service logic and has a 10-digit dialed number that must be terminated.
In step 2222, soft switch site 104 can select a route termination based on the dialed number (i.e., the number of called party 120 dialed by calling party 102) using least cost routing. This route termination can involve termination off data network 112 or off onto another data network. Soft switch site 104 can then communicate with soft switch site 106 to allocate a terminating circuit in gateway site 110 for this call.
In step 2224, soft switch site 104 can indicate connections to be made to complete the call. Soft switch site 104 or soft switch site 106 can return a termination that indicates the connections that must be made to connect the call.
In step 2226, soft switch sites 104,106 instruct the gateway sites to make connections to set up the call. Soft switch sites 104, 106 can send messages through data network 112 (e.g. using IPDC protocol commands) to gateway sites 108, 110, to instruct the gateway sites to make the necessary connections for setting up the call origination from calling party 102, the call termination to called party 120, and the connection between origination and termination.
In step 2228, soft switch sites 104, 106 generate and send network events to a repository. Soft switch sites 104, 106 can generate and send network events to network event component I 16 that are used, for example, in detecting and preventing fraud, and in performing billing.
In step 2230, network management component 118 monitors the telecommunications network 100. All network elements create network management events such as SNMP protocol alerts or events. Network management component 118 can monitor SNMP events to enable management of network resources.
FIG. 22C details an even more complex operational call flow describing how soft switch sites 104, 106 can be used to process a long distance call using project account codes and class of service restrictions. FIG. 22C inserts steps 2210 through 2218 between steps 2208 and 2220 of FIG. 22B.
The operational call flow of FIG. 22C begins with step 2202, in which a soft switch site receives an incoming signaling message. The call starts by soft switch site 104 receiving an incoming signaling message from carrier facility via signaling network 114, indicating an incoming call from calling party 102.
In step 2204, the soft switch site determines the type of call by performing initial digit analysis. Based upon the information in the signaling message, the soft switch site 104 analyzes the initial digit of the dialed number of the call and determines that it is a I + call.
In step 2206, the soft switch site queries a customer profile database to retrieve the originating trigger plan associated with the calling customer.
With a I+ type of call, the logic within the soft switch knows to query the customer profile database within soft switch site I 04 to retrieve the originating trigger plan for the calling party. The step 2206 query can be made using the calling party number. The customer profile lookup is performed using as the lookup key, the originating number, i.e., the number of calling party 102, provided in the signaling message from signaling network 114.
In step 2208, the lookup returns subscription information. For example, the customer profile can require entry of an account code. In this example, the customer profile lookup can return an indication that the customer, i.e., calling party 102, has subscribed to an account code verification feature. A class of service restriction can also be enforced, but this will not be known until account code verification identifies an associated account code.
In step 2210, soft switch site 104 instructs gateway site 108 to collect account codes. Using the information in the customer profile, soft switch site can use the IPDC protocol to instruct gateway site 108 to collect a specified number of digits from calling party 102.
In step 2212, soft switch site 104 determines how to process received digits. Assuming gateway site 108 collects the correct number of digits, soft switch site 104 can use the customer profile to determine how to process the received digits. For account code verification, the customer profile can specify whether the account code needs to be validated.
In step 2214, soft switch site 104 verifies the validity of the received digits. Ifthe account code settings in the customer profile specify that the account code must be verified and forced to meet certain criteria, soft switch site performs two functions. Because "verify" was specified, soft switch site 104 queries a database to verify that the collected digits meet such criteria, i.e., that the collected digits are valid. Because "forced" was specified, soft switch site 104 also forces the calling customer to re-enter the digits if the digits were not valid.
In step 2216, verification can result in the need to enforce a restriction, such as a class of service (COS) restriction (COSR). In this example, soft switch site 104 can verify that the code is valid, but that it requires, for example, that an intrastate COSR should be enforced. This means that the call is required to be an intrastate call to be valid. The class of service restriction logic can be performed within soft switch site 104 using, for example, pre-loaded local access and transport areas (LATAs) and state tables.
If project account codes (PACs) are not used, class of service (COS) S restrictions can be applied based on originating ANI or ingress trunk group.
In step 2218, soft switch 104 allows the call to proceed if the class of service requested is permitted. For example, if the LATA and state tables show that the LATAs of originating party (i.e., calling party 102) and terminating party (i.e. called party 120), must be, and are, in the same state, then the call can be allowed to proceed.
In step 2220, soft switch site 104 completes customer service processing and prepares to terminate the call. At this point, soft switch site 104 has finished executing all customer service logic and has a 10-digit dialed number that must be terminated.
In step 2222, soft switch site 104 can select a route termination based on the dialed number (i.e., the number of called party 120 dialed by calling party 102) using least cost routing. This route termination can involve termination off data network 112 or off onto another data network. Soft switch site 104 can then communicate with soft switch site 106 to allocate a terminating circuit in gateway site 110 for this call.
In step 2224, soft switch site 104 can indicate connections to be made to complete the call. Soft switch site 104 or soft switch site 106 can return a termination that indicates the connections that must be made to connect the call.
In step 2226, soft switch sites 104, 106 instruct the gateway sites to make connections to set up the call. Soft switch sites 104, 106 can send messages through data network 112 (e.g. using IPDC protocol commands) to gateway sites 108, 110, to instruct the gateway sites to make the necessary connections for setting up the call origination from calling party 102, the call termination to called party 120, and the connection between origination and termination.
In step 2228, soft switch sites 104, 106 generate and send network events to a repository. Soft switch sites 104, 106 can generate and send network events S to network event component 116 that are used, for example, in detecting and preventing fraud, and in performing billing.
In step 2230, network management component lI8 monitors the telecommunications network 100. All network elements create network management events such as SNMP protocol alerts or events. Network management component I 18 can monitor SNMP events to enable management of network resources.
The intermediate level description and specific implementation example embodiments sections, below, will describe additional details of operation of the invention. For example, how soft switch site 104 performs initial digit analysis to identify the type of call and how to process the call will be discussed further.
The sections also provide details regarding how soft switch sites 104,106 interact with the other components of the voice network architecture.
II. Intermediate Level Description This section provides an intermediate level description of the VOIP
network architecture according to the present invention. A structural implementation of the VOIP network architecture is described at an intermediate level. Also, a functional implementation for this structure is described at an intermediate level. This structural implementation is described herein for illustrative purposes, and is not limiting. In particular, the process described in this section can be achieved using any number of structural implementations, one of which is described in this section. The details of such structural implementations will be apparent to persons skilled in the relevant arts based on the teachings contained herein.
A. Structural Description FIG. 2A is a block diagram further illustrating the components of VOIP
S architecture 100 at an intermediate level of detail. FIG. 2A depicts telecommunications system 200. Telecommunications system 200 includes soft switch site 104, gateway sites 108,110, data network 1 I 2, signaling network 114, network event component 116, provisioning component 117 and network management component I 18. Included in FIG. 2A are calling parties 102, I22 and called parties 120, 124.
Soft switch site 104 includes soft switch 204, SS7 gateways 208, 210, service control point {SCP) 214, configuration server/ configuration database (CDB) 206, route server 212, signal transfer points (STPs) 250, 252, and regional network event collection point (RIVECP) 224. Table I below describes the functions of these network elements in detail.
Tabte 1 Soft swift/: component Description soft switch (SS) Soft switches are call control components responsible for processing of signaling messages, execution of call logic and control of gateway site access devices.

SS7 gateways (SS7 GV~ SS7 gateways provide an interface between the SS7 signaling network and the soft switch.

Ta ble 1 Soft switclr component Description service switching points Service switching points (SSP) are the portions of backbone switches providing SS7 functions.
For example, any switch in the PSTN is an SSP if it provides SS7 functions.

A soft switch is an SSP.

signal transfer point (STP)Signal transfer points route signaling messages from originating service switching points (SSPs) to destination SSPs.

service control point (SCP)Service control points provide number translations for toll free services and validation of project account codes for PAC services.

configuration server/ configurationConfiguration servers are servers database (CDB) managing customer profiles, voice network topologies and configuration data. The configuration database is used for storage and retrieval of such data.

route server (RS) Route servers are responsible for selection of least cost routes through the network and allocation of network ports.

regional network event Route servers are responsible collection point for (RNECP) selection of least cost routes through the network and allocation of network ports. regional network event collection points are points in the network that collect call event data.

Gateway site 108 includes trunking gateway (TG) 232, access gateway (AG) 238, network access server (NAS) 228, digital cross-connect system (DACS) 242 and announcement server (ANS) 246. TG 232. AG 238, and NAS
228 are collectively known as access server 254. Similarly, gateway site I IO
includes TG 234, AG 240, NAS 230, DACS 244 and ANS 248. TG 234, AG
240, and NAS 230 are collectively known as access server 256. Gateway sites 108,1 I 0 provide trunk, private line and dedicated access line connectivity to the PSTN. Table 2 below describes the functions of these network elements in detail.
Ta ble 2 Gateway site component Description franking gateway (TG) A franking gateway provides full-duplex PSTN to IP conversion for co-carrier and feature group D (FG-D) trunks.

access gateway (AG) An access gateway provides full-duplex PSTN to IP conversion for ISDN-PRI and T1 digital dedicated access lines (DALs).

network access server (NAS)A network access server provides modem access to an IP network.

digital access and cross-connectA digital access and cross-connect system (DACS) system is a digital switching system used for the routing and switching of T-1 lines and DS-0 circuits of lines, among multiple T-1 ports.

announcement server (ANS) An announcement server provides a network with PSTN terminating announcements.

Data network 112 provides the network bandwidth over which calls can be connected through the telecommunications system. Data network 112 can be, for example, a packet switched data network including network routers for routing traffic through the network.
Signaling network 1 I 4 includes signal transfer points (STPs) 216, 218 and signaling control points (SCPs) associated with each network node. Table 3 below describes the functions of these network elements in detail.

Ta ble 3 Signaling network componentDescription signal transfer points Signal transfer points route (STPs) signaling messages from originating service switching points (SSPs) to destination SSPs.

service control point (SCP)Service control point provide number translations for Toll Free services and validation of project account codes (PAC) for PAC

services.

service switching point Service switching points (SSPs) are the portions of backbone switches providing SS7 functions.
For example, any switch in the PSTN is an SSP if it provides SS7 functions.

A soft switch is an SSP.

Network management component 118 includes the means to manage a network. Network management component 1 I 8 gathers events and alarms related to network events. For example, event logs can be centrally managed from a network operations center (NOC). Alerts and events can be communicated to the NOC via the simple network management protocol (SNMP)). Table 4 below describes the functions of these network elements in detail.
Tabte 4 Network management componentDescription network operations center Network operations center (NOC) is a centralized location for gathering network management events and for managing various network elements via the SNMP protocol.

WO 00/31933 PCT/US99/2'7658 Table 4 Network management componentDescription simple network management Simple network management protocol (SNMP) protocol provides site filtering of element alarms and messages before forwarding them to the NOC.

Network event component 116 includes master network event database (MNEDB) 226. Table SA below describes the functions of this network element in detail.
Table 5A

Nehvork event component Description master network event databaseMaster network event database is a (MNEDB) centralized server/ database that collects call event records from regional network event collection points (RNECPs). It serves as a depository for the event records.

Provisioning component 117 includes data distributor (DD) 222. Table SB below describes the functions of this network element in detail.
Table SB

Provisioning component Description data distributor (DD) The data distributor distributes service requests and data from upstream Operational Support Systems (OSS) to network elements.

It maintains synchronization of redundant network resources.

B. Operational Description The following operational flow describes an exemplary intermediate level call scenario intended to demonstrate at an intermediate architectural level how call processing is handled. The operational flow of the present invention is not to be viewed as limited to this exemplary illustration.
FIG. 2B depicts an exemplary call flow 258. FIG. 2B illustrates interaction between a franking gateway, a soft switch, a configuration server and a route server in order to connect a call through telecommunications network 200.
FIG. 2B details a call flow from TG 232 of gateway site 108, controlled by soft switch site 104, to TG 234 of gateway site I 10, controlled by soft switch site 106.
(Soft switch site 106 is illustrated in FIGS. 1 and 3.) Soft switch site 106, including soft switch 304, route server 314, and configuration server 312, is further described below in the Specific Example Embodiments section, with reference to FIG. 3.
Included in call flow 258 is a description of how soft switch 204 can process a 1+ long distance call that uses project account codes (PACs) with class of service (COS) restrictions. Call flow 258 also assumes that the origination and termination for the call uses SS7 signaling, i.e., that the call comes into network 200 via trunks from carrier facilities 126,130, to franking gateways 232, 234.
Exemplary call flow 258 begins with step 259. In step 259, soft switch 204 receives an incoming IAM signaling message from an SS7 GW 208, signaling an incoming call from calling party 102 on carrier facility 126 of a co-carrier.
In step 260, soft switch 204 sends IPDC commands to franking gateway 232 to set up a connection (e.g. a DSO or DS 1 circuit) between carrier facility I 26 and TG 232 described in the received IAM signaling message. In step 262, franking gateway 232 sends an acknowledgement message to soft switch 204.

Based upon the information in the IAM message, soft switch 204 performs initial digit analysis on the dialed number, i.e., the number of called party 120, and determines that the incoming call is a 1+ call.
In step 263, application program logic within soft switch 204 deternlines that, with this type of call, i.e., a 1+ call, soft switch 204 should query a customer profile database within configuration server 206, to retrieve the originating customer trigger plan 290 for calling party 102.
The customer profile lookup is performed in configuration server 206 using the originating automatic number identification (ANI) of calling party as the lookup key.
In step 264 the customer profile lookup returns to soft switch 204 an indication that the calling party 102 has subscribed to project account codes (PAC). Examples of PACs include billing codes. They provide a mechanism for a network customer, such as a law firm, to keep an accounting of which of their clients to bill. Example call flow 258 will also perform a class of service (COS) restriction, but this will not be known by soft switch 204 until account code verification identifies an associated account code requiring the COS
restriction.
Alternatively, the customer profile information can reside in route server 212, enabling route server 212 to perform the functions of configuration server 206, in addition to its own functions.
In step 267, using the information in the customer profile (i.e., customer trigger plans 290) of configuration server 206, soft switch 204 uses the IPDC
protocol to instruct franking gateway 232 to collect the specified number of digits, representing the project account code, from calling party 102.
In step 268, the digits are sent from franking gateway 232 to soft switch 204. Assuming that franking gateway 232 collected the correct number of digits, soft switch 204 uses the customer profile of configuration server 206 to determine how to process the received digits. For project account codes {PACs), the w0 00/31933 PCT/US99/27658 customer profile in configuration server 206 specifies whether the project account code needs to be validated.
If the project account code settings in the customer profile of configuration server 206 specify that the project account code is "verified and forced," then soft switch 204, in step 265, can query SCP 214 with the collected digits to verify that they are valid. Table 129 below provides alternative PAC
settings.
In step 266, SCP 214 returns an indication that the project account code is valid, and it requires that an intrastate class of service (COS) restriction should be enforced. The class of service (COS) restriction logic can be performed within soft switch 204, using pre-loaded LATA and state tables from configuration server 206.
If a PAC is not used, the COS restriction can be applied based on ANI or ingress trunk group.
If the LATA and state tables from configuration server 206 show that the originating LATA (i.e., the LATH of calling party 102) and the terminating LATA (i.e., the LATH of called party 120) are in the same state, then the call is allowed to proceed.
At this point, soft switch 204 has f nished executing all customer service logic and has a 10-digit DDD number (i.e., the phone number of called party 120), that must be terminated.
In step 269, soft switch 204 queries route server 212 to receive a call route and to allocate circuits to connect the call. Route server 212 is responsible for using the DDD number to select a least cost route through data network 112, and allocating a terminating circuit for this call.
Additional information on how soft switch 204 interacts with route server 212 and terminating soft switch 304 is described in the Specific Implementation Example Embodiments Section below, in the section entitled Route Server.

In step 270, route server 212 returns a route that indicates the connections that soft switch 204 must make to connect the call.
In step 274, soft switch 204 communicates with soft switch 304 to allocate ports in franking gateway 234 of gateway site 110, for termination of the call.
Soft switch 304 is located in a central soft switch site 106. In step 276, soft switch 304 queries port status 298 of route server 314 to identify available ports in franking gateway 234. In step 278, route server 314 returns an available port to soft switch 304. In steps 280 and 282, soft switch 304 communicates with franking gateway 234 to allocate a port for termination of the call to called party 120.
In step 284, soft switch 304 communicates with soft switch 204 to indicate terminating ports have been allocated.
In steps 286 and 288, soft switch 204 communicates with franking gateway 232 in order to notify franking gateway 232 to set up an RTP session (i.e.
an RTP over UDP over IP session) with franking gateway 234 and to permit call traffic to be passed over data network 112.
The Specific Implementation Example Embodiments Section, in the next section, describes additional information about, for example, how soft switch performs initial digit analysis to identify the type of call, and how to process the call. The next section also describes how soft switch 204 interacts with other components of the voice network architecture 200 in transmitting the call.
III. Specific Implementation Example Embodiments Various embodiments related to structures, and operations between these structures described above are presented in this section (and its subsections).
These embodiments are described herein for purposes of illustration, and not limitation. The invention is not limited to these embodiments. Alternate embodiments (including equivalents, extensions, variations, deviations, etc., of the embodiments described herein) will be apparent to persons skilled in the relevant arts based on the teachings contained herein. The invention is intended and adapted to include such alternate embodiments.
Specifically, this section provides a detailed description of the VOIP
network architecture according to the present invention. A structural implementation of the (VOIP) network architecture is described at a low-level.
Also, a functional implementation for this structure is described at a low-level.
A. Structural description A more detailed structural description of telecommunications network 200 will now be described.
1. Soft Switch Site FIG. 3 is a block diagram illustrating a more detailed implementation of telecommunications network 200. Specifically, FIG. 3 illustrates telecommunications network 300 containing three geographically diverse soft switch sites. These soft switch sites include western soft switch site 104, central soft switch 106, and eastern soft switch 302.
Telecommunications network 300 also includes a plurality of gateway sites that may be collocated or geographically diverse. These gateway sites include gateway sites 108a, 108b, 1 l0a and 1 l Ob.
Data network 112 can route both signaling and transport traffic between the regional soft switch sites and regional gateway sites. For example, data network 112 can be used to route traffic between western soft switch site 104 and gateway site 1 I Oa. Signaling and transport traffic can also be segregated and sent over separate data networks. As those skilled in the art will recognize, data network 112 can be used to establish a data or voice connection among any of the aforementioned gateway sites 108a,108b,1 I Oa and 11 Ob under the control ofany of the aforementioned soft switch sites I 04, 106 and 302.
Western soft switch site 104 includes soft switch 204x, soft switch 204b, and soft switch 204c. Soft switches 204a, 204b, 204c can be collocated or geographically diverse. Soft switches 204a, 204b, 204c provide the features of redundancy and high availability.
Failover mechanisms are enabled via this architecture, since the soft switches can act as one big switch. Soft switches 204a, 204b, 204c can intercommunicate via the inter soft switch communication protocol, permitting access servers to reconnect from one soft switch to another.
Western soft switch site 104 includes SS7 gateway (GW) 208, configuration server/configuration database (CS/CDB} 206a and mute server (RS) 212a. To provide high availability and redundancy, western soft switch site I

includes a redundant SS7 GW, a redundant CS/CDB and a redundant RS.
Specifically, western soft switch site 104 includes SS7 GW 210, CS/CDB 206b and RS 212b.
Soft switches 204a, 204b and 204c are connected to SS7 GWs 208, 210, CS/CDBs 206x, 206b and RSs 212a, 2I2b via redundant ethernet switches (ESs) 332, 334 having multiple redundant paths. This architecture enables centralization of SS7 interconnection to gain economies of scale from use of a lesser number (than conventionally required) of Iinks to signaling network 114, to be shared by many access servers in gateway sites. ESs 332, 334 also provide connectivity to routers (Rs) 320, 322. Routers 320, 322 respectively provide redundant connectivity between redundant ESs 332, 334 and data network 112.
As noted, included in telecommunications network 300 are central soft switch site I06 and eastern soft switch site 302. Central soft switch site 106 and eastern soft switch site 302 respectively include identical confgurations to the .
configuration of western soft switch site 104. Central soft switch site I06 includes SS7 GWs 308, CS/CDBs 312, RSs 314, soft switches 304a, 304b, 304c, ESs 336, 338, and Rs 324, 326. Similarly, eastern soft switch site 302 includes S SS7 GWs 3I0, CS/CDBs 3I6, RSs 318, soft switches 306a, 306b, 306c, ESs 340, 342, and Rs 328 and 330.
Gateway site 108a includes TG 232a, NAS 228a, AG 238a and DACS
242x. Gateway sites 108b,1 I 0a and 1 I Ob have similar configurations to gateway site 108a. Gateway site 108b includes TG 232b, NAS 228b, AG 238b and DACS
242b. Gateway site I l0a includes TG 234a, NAS 230a, AG 240a and DACS
244a. Finally, gateway site 1 I Ob includes TG 234b, NAS 230b, AG 240b; and DACS 244b. The details of gateway site 108a, 108b, 1 l0a and 1 lOb will be further described below with reference to FIG. 10A.
a. Soft Switch Referring back to FIG. 2A, soft switch 204 provides the call processing function for telecommunications network 200. Call processing refers to the handling of voice and data calls. There are a number of important call processing functions handled by soft switch 204. Soft switch 204 processes signaling messages used for call setup and call tear down. These signaling messages can be processed by in-band or out-of band signaling. For an example of out-of band signaling, SS7 signaling messages can be transmitted between signaling network 114 and soft switch 204. (Soft switch 204 refers to soft switches 204a, 204b and 204c.) Another call processing function performed by soft switch 204 is preliminary digit analysis. Preliminary digit analysis is performed to determine the type of call arriving at soft switch 204. Examples of calls include toll free calls, 1+ calls, 0+ calls, 011+ calls, and other calls recognized by those skilled in the art.
One important feature of soft switch 204 is communicating with CS/CDB
S 206 to retrieve important customer information. Specifically, soft switch queries CS/CDB 206 to retrieve a customer trigger plan. The customer trigger plan effectively identifies the service logic to be executed for a given customer.
This trigger plan is similar to a decision tree pertaining to how a call is to be implemented. Subsequently, soft switch 204 executes the customer trigger plan.
This includes the processing of special service calls requiring external call processing, i.e., call processing that is external to the functions of telecommunications network 200.
Another important function soft switch 204 is communicating with RS
212 to provide network routing information for a customer call. For example, soft switch 204 can query RS 212 to retrieve the route having the least cost from an off network calling party 102 (homed to gateway site 108) to an off network called party 120 (homed to gateway site 110) over data network 112. Upon finding the least cost route, soft switch 204 allocates ports on TGs 232, 234.
As described in detail below, soft switch 204 can also be used to identify the least cost route termination and allocate gateway ports over AGs 238, 240 between an on-network calling party 122 (homed to gateway site 108) and an on-network called party 124 (homed to gateway site 110).
Soft switch 204 also communicates with AGs 238, 240, TGs 232, 234, and NASs 228, 230 over data network 112. Although AGs 238, 240, TGs 232, 234 and NASs 228, 230 can communicate with a plurality of soft switches, as illustrated in FIG. 3, these network nodes (referred to collectively as access servers 254a, 254b, 256a, and 256b) are respectively assigned to a primary soft switch. This primary soft switch, e.g., soft switch 204, assumes a primary responsibility or control of the access servers. In addition, the access servers can be as respectively assigned to secondary switches, which control the access servers in the event that the primary soft switch is unavailable.
Referring back to FIG. 3, western soft switch site 104, central soft switch site I 06 and eastern soft switch site 302 are geographically diverse. For example, western soft switch site 104 can be a soft switch site located in San Diego, CA.
Central soft switch site 106 can be a soft switch site located in Denver, CO.
Eastern soft switch site 302 can be a soft switch site located in Boston, MA.
It is permissible that additional network nodes are provided at any of soft switch sites 104, 106 and 302. For example, additional elements, including, e.g., SS7 GW 208, CDB 206a, and RS 212a can be collocated at western soft switch site 104. Examples of other supporting elements of western soft switch site I

are an announcement server (ANS), a network event collection point (NECP), an SCP, and on-network STPs. Referring to the more detailed implementation of FIG. 2A, telecommunications network 200 includes ANSs 246, 248, NECP 224, SCP 214, and STPs 250, 252.
(1) Soft Switch Interfaces FIG. 4A is a block diagram illustrating the interfaces between soft switch 204 and the remaining components oftelecommunications network 200. The soft switch interfaces of FIG. 4A are provided for exemplary purposes only, and are not to be considered limiting. Soft switch 204 interfaces with SS7 GWs 208, via soft switch-to-SS7 GW interface 402. One example of interface 402 is an SS7 integrated services digital network (ISDN) user part (ISUP) over a transmission control protocol/intetnet protocol (TCP/IP). Soft switch 204 interfaces with configuration server 206 over interface 406. In an example embodiment, interface 406 is a TCP/IP connection.

Soft switch 204 interfaces with RNECP 224 over interface 410. In an example embodiment, interface 410 is a TCP/IP connection.
Soft switch 204 interfaces with route server 212 over interface 408. In an example embodiment, interface 408 is a TCP/IP connection.
Soft switch 204 interfaces with SCP 214 over interface 404. In an example embodiment, interface 404 is a TCP/IP connection.
Soft switch 204 interfaces with announcement servers 246, 248 over interface 416. In an example embodiment, interface 416 can include the IPDC
protocol used over a TCP/IP connection.
Soft switch 204 interfaces with TGs 232, 234 over interface 412. In an example embodiment, interface 412 can include the IPDC protocol used over a TCP/IP connection.
Soft switch 204 interfaces with AGs 238, 240 over interface 414. In an example embodiment, interface 414 can include the IPDC protocol used over a 1 S TCP/IP connection.
In one embodiment, soft switch 204 is an application software program running on a computer. The structure of this exemplary soft switch is an object oriented programming model discussed below with reference to FIGs. 4B-4E.
Another interface to soft switch 204 (not shown) is a man-machine interface or maintenance and monitoring interface (MMI). MMI can be used as a direct controller for management and machine actions. It should be noted that this is not intended to be the main control interface, but is rather available to accommodate the need for on-site emergency maintenance activities.
Yet another interface permits communication between soft switches 204, 304. A soft switch-to-soft switch interface will be described further with reference to FIG. 2B. A soft switch 204-to-soft switch 304 interface permits communication between the soft switches 204, 304 that control the originating call-half and terminating call-half of call flow 258. The soft switch 204-to-soft switch 304 interface allows soft switches 204, 304 to set up, tear down and manage voice and data calls. Soft switch 204 to soft switch 304 interface can allow for a plurality of inbound and outbound signaling types including, for example, SS7, ISDN, and in-band E&M signaling.
In telephony, E&M is a trunking arrangement generally used for two-way (i.e., either side may initiate actions) switch-to-switch or switch-to-network connections. E&M signaling refers to an arrangement that uses separate leads, called respectively the "E" lead and the "M" lead, for signaling and supervisory purposes. The near-end signals the far-end by applying -48 volts DC ("VDC") to the "M" lead, which results in a ground being applied to the far end's "E"
lead.
When -48 VDC is applied to the far-end "M" lead, the near-end "E" lead is grounded. "E" lead originally stood for "ear," i.e., when the near-end "E"
lead was grounded, the far end was calling and "wanted your ear." "M" originally stood for "mouth," because when the near-end wanted to call (i.e., to speak to) the far end, -48 VDC was applied to that lead.
When a PBX wishes to connect to another PBX directly, or to a remote PBX, or to an extension telephone over a leased voice-grade line (e.g., a channel on a T-1 ), the PBX can use a special line interface. This special line interface is quite different from that which the PBX uses to interface to directly-attached phones. The basic reason for the difference between a normal extension interface and a long distance interface is that the respective signaling requirements differ.
This is true even if the voice signal parameter, such as level and two-wire, four-wire remain the same. When dealing with tie lines or trunks, it is costly, inefficient, and too slow for a PBX to do what an extension telephone would do, i.e., to go off hook, wait for a dial tone, dial, wait for ringing to stop, etc. The E&M tie trunk interface device is a form of standard that exists in the PBX, T-multiplexer, voice-digitizer, telephone company world. E&M signaling can take on a plurality of forms. At least five different versions exist. E&M signaling is the most common interface signaling method used to interconnect switching signaling systems with transmission signaling systems.
The sample configuration depicted in FIG. 2B, can use a soft switch 204-to-soft switch 304 protocol. In FIG. 2B, the access servers depicted are franking gateways 232, 234. TGs 232, 234 are connected to the switch circuit network (SCN), i.e., signaling network 114, via SS7 trunks, ISDN trunks, and in-band trunks. The originating soft switch 204 can receive a call over any of these trunks. The signaling information from these SS7, ISDN, and in-band trunks is processed by soft switch 204 to establish the originating call-half. The signaling information processed by soft switch 204, can be used to determine the identity of terminating soft switch 304. The identity of terminating soft switch 304 is required to complete the call.
Originating soft switch 204 can then communicate the necessary information to complete the call, via an inter-soft switch communication (ISSC) protocol. Terminating soft switch 304 can be required to be able to establish the terminating call-half on any of the supported trunk types. The ISSC protocol can use a message set that is structured similarly to the IPDC protocol message set.
The messages can contain a header followed by a number of tag-length-value attributes. The incoming signaling message for the call being placed. can be carried in a general data block of one of the attribute value pairs (AVPs).
The other AVPs, can contain additional information necessary to establish a voice-over-IP connection between the originating and terminating ends of the call.
b. S S 7 Gateway SS7 gateways (GWs) 208, 210 wilt now be described further with reference to FIG. 2A and FIG. SA. In FIG. 2A, SS7 GWs 208, 210 receive signaling messages from signaling network 114 and communicate these messages to soft switch 204. Specifically, for SS7 signaled trunks, SS7 GWs 208, 210 can receive SS7 ISUP messages and transfer them to soft switch 204. SS7 GWs 208, 210 can also receive signaling messages from soft switch 204 and send SS7 ISUP
messages out to signaling network 114.
(1) SS7 Gateway Example Embodiment In an example embodiment, SS7 GWs 208, 210 can be deployed in a two (2) computing element (CE) cluster 207, depicted in FIG. SA. SS7 GWs 208, 210, in two-CE-cluster 207 can fully load-share. SS7 GWs 208, 210 can intercommunicate as represented by connection 530 to balance their loads. Load-sharing results in a completely fault resilient hardware and software system with no single point of failure. Each SS7 GW 208, 210 can have, for example, six two-port cards for a total of twelve links to signaling network I I 4.
In an example embodiment, SS7 GWs 208, 210 are application programs running on a computer system. An exemplary application program providing SS7 GW 208, 210 functionality is OMNI SIGNALWARE (OMNI), available from I S DGM&S, of Mount Laurel, NJ. OMNI is a telecommunications middleware product that runs on a UNIX operating system. An exemplary operating system is the SUN UNIX, available from SUN Microsystems, Inc. of Palo Alto, CA. The core of OMNI resides logically below the service applications, providing a middleware layer upon which telecommunications applications can be efficiently deployed. Since the operating system is not encapsulated, service applications have direct access to the entire operating environment. Because of OMNI's unique SIGNALWARE architecture, OMNI has the ability to simultaneously support variants of SS7 signaling technology (ITU-T, ANSI, China and Japan).
The SIGNALWARE architecture core is composed of the Message Transfer Part (MTP) Layer 2 and Layer 3, and Service Connection Control Part (SCCP). These core protocols are supplemented with a higher layer of protocols to meet the needs of a target application or service. OMNI supports multiple protocol stacks simultaneously, each potentially with the point code format and protocol support of one of the major SS7 variants.
OMNI SIGNALWARE Application Programming Interfaces (APIs) are found on the higher layers of the SS7 protocol stack. OMNI APIs include: ISDN
User Part (ISUP), Telephony User Part (TUP), Transaction Capabilities Application Part (TCAP), Global System for Mobile Communications Mobile Application Part (GSM MAP), EIA/TIA Interim Standard 41 (IS-41 MAP), Advanced Intelligent Network (AIN), and Intelligent Network Application Part (INAP).
(2) SS7 Gateway-to-Soft Switch Interface Figure SA depicts SS7 gateway to soft switch distribution 500. Soft switches receive signaling messages from signaling gateways. Specifically, for SS7 signaled trunks, SS7 GWs 208, 210 send and receive signals from signaling network 114. SS7 GWs 208, 210 communicate with soft switches 204a, 204b, 204c, via redundant connections from the soft switches 204a, 204b, 204c to distributions 508, 510, of SS7 GWs 208, 210 respectively. SS7 GWs 208, 210 together comprise a CE cluster 207.
Based upon an SS7 network design, a pair of SS7 gateways receive all signaling traffic for the franking gateway (TG) circuits serviced by the soft switches at a single soft switch site. Specifically, a pair of SS7 GWs 208, receive all signaling traffic for circuits serviced by soft switch site 104.
Signals serviced by soft switch site 104 enter telecommunications network 200 from gateway sites 108, 502, 110.
In an example embodiment, 96 circuits are serviced by each gateway site 108, 502, 110. Gateway site 108 includes TGs 232a, 232b. Gateway site 110 includes TGs 234a, 234b. Gateway site 502 includes TGs 504, 506.

A circuit is identified by a circuit identification code (CIC). TG 232a includes line card access to a plurality of circuits including CICs 1-48 512 of gateway site 108. TG 232b provides line card access to CICs 49-96 514 of gateway site 108. TG 504 provides line card access to CICs 1-48 516. TG 506 provides line card access to CICs 49-96 518 of gateway site 502. TG 234a provides line card access to CICs 1-48 520. TG 234b provides line card access to CICs 49-96 522 of gateway site I 10. Thus, CICs I-48 S 12, 516, 520, and CICs 49-96 514, 518, 522 are the trunking gateway circuits serviced by soft switch site 104.
IO In an example embodiment, soft switches are partitioned such that any single soft switch will only service a subset of circuits serviced at a given soft switch site. For example, soft switch 204a can service CICs 1-48 512. 516, while soft switch 204b services CICs 49-96 5 I 4 and CICs I -48 520, and soft switch 204c services CICs 49-96 518, 522. In order to assure that ail signaling messages for a particular call get to the correct one of soft switches 204a, 204b.
204c, it is necessary to partition SS7 signaling across the available soft switches based upon the circuits that each soft switch services.
It is much more efficient to run SS7 links to soft switches than to each individual access server (compare to the conventional approach requiring an link to each SSP). Centralization of SS7 signaling traffic interconnection enables benefits from economies of scale, by requiring less SS7 interconnection links.
An exemplary technique for distributing circuits across soft switches 204a, 204b, 204c is based upon the originating point code (OPC), destination point code (DPC), and CIC. OPC represents the originating point code for a circuit group, i.e., the point code of a local exchange carrier (LEC) switch, or signal point(SP). For example, the LEC providing CICs 1-48 512, and CICs 49-96 514 can have an OPC 524 of value 777. The LEC providing CICs I-48 516, and CICs 49-96 518 can have an OPC 526 of value 888. The LEC switch providing CICs 1-48 520, and CICs 49-96 522 has an OPC 528 of value 999.
Similarly, DPC represents the destination point code for a circuit group, i.e., the point code of soft switch site 104. Soft switch site 104 has a point code 529 of value 111, and an alternate point code 531 of value 444. Soft switch site 104 can act as one big switch using a flat network design of the present invention.
This flat network design simplifies routing of calls.
To support distribution of circuits across soft switches 204a, 204b, 204c, SS7 GWs 208, 210 can include a lookup table that allows each signaling message to be routed to the correct soft switch 204a, 204b, 204c. The lookup table can route signaling messages to the correct soft switch 204a, 204b, 204c based upon the OPC, DPC, and CIC fields. This lookup table is built on SS7 GWs 208, 210 based upon registration messages coming from soft switches 204x, 204b, 204c.
In an example embodiment, each time a TG boots up, the TG finds a soft switch to service its circuits. For example, when TG 232a is powered up, TG
232a must find a soft switch 204a, 204b, 204c to service its circuits, i.e.
CICs 1-48 512. In an exemplary technique, TG 232a sends registration messages to soft switch 204a to register circuits CICs 1-48 512. Upon receipt of these registration messages the soft switch 204a registers these circuits with SS7 GWs 208, 210, at soft switch site 104. The circuit registration messages sent to the SS7 gateways are used to build the type of table shown in Table 6.

WO 00/3t933 PCT/US9912'7658 Table 6 OPC, DPC, CIC Value re istration re uest Message Type SS7 atewa circuit re istration S OPC Originating point code for the circuit group. Equals the LEC oint code.

Primary DPC Primary destination point code for the circuit rou . E uals the Soft Switch site int code.

Alias DPC Alias DPC for the Soft Switch site Start CIC Starting Circuit Identification Code for the circuit rou End CIC Ending Circuit Identification Code for the circuit rou Servicing Soft SwitchUnique Identifier for the Soft ID Switch that will service re uests for the OPC, DPC, CIC values Servicing Soft SwitchIP address for the Soft Switch IP that will service address re uests for the OPC, DPC, CIC
values Servicing Soft SwitchPort number that the Soft Switch IP is listening on for Port inc_omin si_nalin messa es.

Prima /S
d /T
i ry The Soft Switch identifies itself econ as the primary, ary ert ary identification secondary or tertiary contact for signaling messaees for the s ecified OPC, DPC and CIC.

The format of a registration message is shown in Table 7. Table 7 includes the mapping of circuits to soft switches.
The messages used by soft switches 204a, 204b, 204c to register their circuits with SS7 GWs 208, 210 contain information for the OPC, DPC and circuit range, i.e., the CICs that are being registered. Each message also contains information about the soft switch that will be servicing the signaling messages for the circuits being registered.
The soft switch information includes an indication of whether this soft switch is identified as the primary servicing point for calls to these circuits, the secondary servicing point or the tertiary servicing point. The gateway uses this indicator in failure conditions. when it cannot contact the Soft Switch that is currently servicing a set of circuits.

Table 7 OPC DPC CIC ran a So t Switch 777 1 I I 1-48 204a 888 111 1-48 204a 888 1 11 49-96 204c 999 1 I 1 49-96 204c Figure SA illustrates, and Table 7 represents in tabular form, the associations between circuit trunk groups of TGs 232a, 2326, 516, S 18, 520, and soft switches 204a, 2046, 204c. SS7 GWs 208, 210 distribute incoming SS7 signaling messages to the soft switch 204a, 2046, 204c listed as associated with the particular circuit in the circuit to soft switch mapping lookup table, (i.e., Table 7). For example, when the LEC switch, or signaling point, associated with OPC 524 (having point code 777) sends a call to TG 2326 over CIC 55 (of CICs 49-96 514), an IAM message can be created and routed. The IAM includes the following information:
( 1 ) OPC 777 (originating LEC has a point code 777), (2} DPC 111 (soft switch site 104, the "switch" that the LEC believes it is trunking to, has point code 111 ), and (3) CIC 55 (the circuit selected by the LEC has circuit identifier code 55).
The IAM message can then be routed by signaling networkl 14 (i.e., the SS7 network) to SS7 GWs 208, 210 at soft switch site 104, having point code 111.
SS7 GWs 208, 210 can perform a lookup to Table 7, to identify which of soft switches 204a, 2046, 204c is handling the particular circuit described in the IAM
message. In the example above, the IAM message having OPC 524 of value 777, DPC of value I I 1 and CIC 55 can be routed to soft switch 2046.
SS7 GWs 208, 210 will now be discussed further with reference to FIG.
17A. FIG. 17A depicts an exemplary signaling network environment 1700.

FIG 17A includes signaling network 114 Specifically, signaling network I 14 can be an SS7 national signaling network. FIG. I 7A depicts three soft switch sites interfacing via a plurality of STPs to SS7 network 114.
FIG. 17A includes soft switch sites 104, 106, 302. Western soft switch site 104 includes three soft switches 204a, 204b, 204c redundantly connected to routers 320, 322 and SS7 GWs 208, 210 via ethernet switches 332, 334. SS7 GW
208 and SS7 GW 210 communicate via a TCP/IP connection 1702 and serial link 1704.
Similarly, central soft switch site 106 includes soft switches 304a, 304b, 304c redundantly connected to routers 324, 326 and SS7 GWs 308a, 308b via ethernet switches 336, 338. SS7 GW 308a and SS7 GW 308b communicate via TCP/IP connection 1706 and serial link 1708.
Finally, eastern soft switch site 302 includes soft switches 306a, 306b, 306c redundantly connected to routers 328, 330 and SS7 GWs 310a, 310b via I S ethernet switches 340, 342. SS7 GW 310a and SS7 GW 310b communicate via TCP/IP connection 1710 and serial link 1712.
FIG. 17A also includes data network 112 connected to soft switch sites 104, 106, 302 via routers 320, 322,. routers 324, 326 and routers 328, 330, respectively. Data network 112 can carry data including control message information and call traffic information. Data network 112 can also carry in-band type signaling information and ISDN signaling information, via IPDC messages.
Out-of band signaling, such as, e.g., SS7 signaling, information is communicated to (i.e. exchanged with) soft switch sites 104, 106, 302 via SS7 GWs 208, 210, SS7 GWs 308a, 308b, and SS7 GWs 310a, 310b from signaling network 114.
SS7 signaling messages are transferred through signaling network 114 from STP to STP until arriving at a final destination. Specifically, signaling messages intended for soft switch sites 104, 106, 302, are routed via packet switched SS7 signaling network 114 to STPs 216, 218 which are part of the SS7 national signaling network 114. STP services (i.e., STPs and A-F links) can be provided by an SS7 signaling services provider, such as, e.g., Transaction Network Services (TNS).
Table 19 defines SS7 signaling links. Some of the SS7 links used are as follows. STPs 216, 218 are linked together by a C-link. STPs 216, 218 are linked by redundant D-links 1730 to STPs 250a, 252a, I 722, 1724, 250b, 252b.
STPs 216, 2I 8 can also be linked by redundant D-links 1730 to STPs 1718,1720, 1714, 1716, though this is not shown.
STP pairs 250a, 252a are linked together by one or more C-links 1728.
Likewise, STP pairs 1722, 1724, STP pairs 250b, 252b, STP pairs 1718, 1720, and STP pairs 1714, 1716 can be linked together by C-links.
STPs 1714, 1716, 250a, 252a, 1722, 1724, 250b, 252b, 1718, and 1720 can be linked by one or more A-links 1726 to SS7 GWs 208, 210, 308a, 308b, 310x, and 31 Ob: Thus, signaling messages from anywhere in signaling network 114 may be routed by STPs 2I6, 218 through STPs 1714, 1716, 250a, 252a, 1722, 1724, 250b, 252b, 1718, 1720, to SS7 GWs 208, 210, 308a, 308b, 310a, and 310b of soft switch sites 104, 106, and 302. SS7 GWs 208, 210, 308a, 308b, 310a, and 310b thus route messages through packet switched STPs to signaling network 114.
SS7 GWs 208, 210, 308a, 308b, 310a, and 310b use a separate physical interface for all simple network management protocol (SNMP) messages and additional functions that may be defined. Exemplary functions that may be defined include provisioning, updating, and passing special alarms, and performance parameters to the SS7 GW from the network operation center (NOC) of network management component 118.

c. Signal Transfer Points (STPs) Signal transfer points (STPs) 216, 218 are the packet switches of signaling network I14. More specifically, STPs are the packet switches of the SS7 network. STPs 250, 252 are the STPs interfacing with SS7 GWs 208, 210 ofsoft switch site 104. STPs 216, 218 receive and route incoming signaling messages toward the proper destination.
STPs 250, 252 also perform specialized routing functions. STPs are customarily deployed in pairs. While elements of a pair are not generally collocated, they work redundantly to perform the same logical function.
STPs have several interfaces. STP interfaces are now described, with reference to FIGS. 17A and 17B. The interfaces can be described in terms of the links used. Table 19 shows links used in SS7 architectures.
The first interface comprises one or more D-links 1730 from off network STPs 250, 252 (as shown in FIG. 2A) to on-network STPs 216, 218. D-links connect mated STPs at different hierarchical levels to one another. Qn-network STPs 216, 218, as well as STPs 1714, 1716, 1722, 1724, 1718 and 1720 are part ofthe national SS7 signaling network 114. Additional D-links 1730 can connect STPs 216, 218 to STPs 250a, 252a, STPs 1722, 1724, STPs 250b. 252b, and STPs 1718 and 1720.
The second interface comprises C-links. C-links connect mated STPs together. An example are C-links 1728 between STP 250a and 252a. C-links 1728 enable STPs 250a, 252a to be linked in such a manner that they need not be co-located. Similarly, STPs 250b, 252b, STPs 1718, 1720, STPs I722, 1724, STPs 1714, 1716, and STPs 216, 218 can also be respectively linked via C-links.
The third interfaces to STPs comprise A-links and E-links. A-links connect STPs to SSPs and SCPs. E-links are special links that connect SSPs to remote STPs, and are used in the event that A-links to home STPs are congested.

The entire soft switch site is viewed as an SSP to a signaling network. A-links or E-links can be used to connect any of STPs 1714, 1716, 250a, 252a, 1722, 1724, 250b, 252b, 1718 and 1720 respectively to soft switch sites 104, 106, at SS7 GWs 208, 210, 308a, 308b, 3 I Oa and 310b. In an example embodiment, each of SS7 GWs 208, 210, 308a, 308b, 310a, 310b can have, for example, twelve (12) A-links 1726 distributed among STPs 250a, 252a, 250b, 252b and STPs 1714, 1716, 1722, 1724, 1718, 1720. By using the plurality of A-links, the soft switch sites 104, 106, 302 have a fully redundant, fully meshed, fault tolerant signaling architecture.
STPs 250a, 252a, 250b, 252b use a separate physical interface for all SNMP messages and additional functions that can be defined. Additional functions that can be defined include provisioning, updating, and passing special alarms and performance parameters to and from STPs 250a, 252a, 250b, 252b and network operation center (NOC) of network management component 118.
In another embodiment of the invention, as illustrated in FIG. 17B, soft switch sites 104,106, 302 have additional soft switches and SS7 GWs.
Additional soft switches and SS7 GWs can be used, for example, for handling additional traffic and for testing of alternative vendor soft switches and SS7 GWs.
FIG. 17B includes SS7 gateway to SS7 signaling network alternative embodiment 1740. FIG. 17B includes signaling network 114 interfacing to western soft switch site 104, central soft switch site 106, and eastern soft switch site 302. Signaling network 114 includes STPs 216, 218 connected via multiple D-Links 1730 to STPs 250x, 252a, 250b, 252b. In an example embodiment STP
250a and STP 252a are connected together by C-Links 1728. In an alternative embodiment, STPs 250a, 252a and STPs 250b, 252b can be linked by quad B-Links. B-links connect mated STP pairs to other mated STP pairs. STPs 2SOa, 252a, 250b, 252b are connected by multiple redundants A-Links 1726 to SS7 GWs in soft switch sites 104, 106, 302.

Western soft switch site 104 includes SS7 GWs 208, 210. which can communicate via a TCP/IP connection and a serial link. SS7 GWs 208, 210 are connected to soft switches 204a, 204b, and 204c. In addition, western soft switch site 104 includes soft switch 1742 and SS7 GW 1744 connected to STPs 250a and 252a. Also western soft switch site 104 includes soft switch 1746 and SS7 GW 1748 connected to STPs 250a, 252a.
Central soft switch site 106 includes SS7 GWs 308a, 308B which can communicate via a TCP/IP connection or a serial link. SS7 GWs 308a, 308b connect soft switches 304a, 304b and 304c to STPs 250a and 252a. Central soft switch site 106 also includes soft switch 1750 and SS7 GWs 1752 connected to STPs 250a, 252a. Central soft switch site 106 also includes soft switch 1754 connected to SS7 GW I756, which is connected to STPs 250a, 252a.
Eastern soft switch site 302 includes SS7 GWs 310a, SS7 GW 310b, which can communicate over TCP/IP and over a serial link. SS7 GWs 310a, I S 310b connect soft switches 306x, 306b and 306c to STPs 250b and 252b.
Eastern soft switch site 302 also includes soft switch 1758 connected to SS7 GW 1760, which is connected to STPs 250b, 252b. Eastern soft switch site 302 also includes soft switch 1762, which is connected to SS7 GW 1764 which is in turn connected to STPs 250b, 252b.
Alternative embodiment 1740, by including additional soft switches and SS7 gateways, permits additional redundancy and enables testing of alternate devices for connection to signaling network 114 via STPs 250a, 252a, 250b, 252b, 216 and 218.
( 1 ) STP Example Embodiment STPs 250, 252, in an example embodiment, can be a TEKELEC Network Switching Division's EAGLE STP. An EAGLE STP, available from TEKELEC

of Calabasas, CA, is a high speed packet switch designed to support SS7 signaling. STPs 250, 252 can be equipped with a plurality of links. In an example embodiment, STPs 250, 252 can support up to, for example, 84 links.
For example, in a preferred embodiment, 14 links can be used initially, and additional links can be added in the future. In a preferred embodiment, several additional features can be added to STPs 250, 252.
(a) Global Title Translation In a preferred embodiment, STPs 250, 252 can have global title translation capability. Global title translation uses global title information. Global title information is information unrelated to signaling network address, which can be used to determine the appropriate destination of a message. Global title translation can support translations from, for example, one to twenty-one digits.
For example, translations can be assigned to translation types from 0 to 225.
In a preferred embodiment, STPs 250, 252 can support up to, for example, 1,000 global title translation requests per second, per application service module (ASM).
(b) Gateway Screening Software In a preferred embodiment, STPs 250, 252 include a gateway screening software feature. EAGLE STP can support user definitions of up to 64 screen sets In this embodiment, each screen set can accommodate up to 2,000 condition statements (or rules) with the gateway screening software. Gateway screening can be performed on all in-bound messages from another network. Gateway screening can also be performed on all outgoing network management messages.
Since gateway screening can occur on the link interface modules (LIMs) and the application service modules (ASMs), the deployment of the gateway screening feature does not impact link throughput capacity, and can contribute to less than milliseconds increase to cross-STP delays.
(c) Local Number Portability (LNP) In a preferred embodiment, local number portability (LNP) can be integrated into the EAGLE architecture of STPs 250, 252. An advantage of the integration of LNP functionality is that it eliminates the need for costly external LNP databases, and associated transmission equipment. In one embodiment, LNP portability can support, complete scalabilty in configurations ranging from 500,000 translation entries and up to more than several million translation entries for very large metropolitan serving areas (MSAs}.
(d) STP to LAN Interface In a preferred embodiment, the STP-to-LAN interface of the EAGLE
architecture can allow the user to connect external data collection or processing systems directly to STPs 250, 252 via a TCP/IP protocol. In this embodiment, the STP-to-LAN interface could be used to carry SS7 signaling over IP packets.
(e) ANSI to ITU Gateway In a preferred embodiment, STPs 250, 252 can include a feature referred to as the ANSI-ITU gateway feature. In a preferred embodiment, the ANSI-ITU
feature of STPs 250, 252 allows STPs 250, 252 to interconnect three types of signaling networks, i.e., ITU international, ITU national and ANSI, by means of three different message signaling unit (MSU) protocols. In a preferred embodiment of STPs 250, 252, the ANSI-ITU feature can allow a smooth transition from an all-ANSI network to a combined ANSI-ITU network.
d. Services Control Points (SCPs) FIG. 6A depicts off switch called processing abstraction diagram 600 showing communication mechanisms between soft switch and STPs. FIG. 6A
includes at the gateway-facing layer, soft switch processing 604 which can use the IPDC protocol 602, or alternatively, the Network Access Server (NAS) Messaging Interface (NMI) protocol to interface with access servers, or the messaging gateway control protocol (MGCP). IPDC protocol 602 provides a protocol for communications between soft switches and respectively TGs, AGs, NASs and ANSs. Soft switch processing 604 uses IPDC for gateway communication and uses off switch call processing 606 to access SCPs 608, 614, 618, 620.
SS7 TCAP 608 is connected to SCP 610 an off network SCP, via STP
250. IP TCAP 614 is connected to SCP 612. SCP 616 is connected to custom IP
618. SCP 214 is an on-network SCP and is connected via INAP/IP 620.
FIG. 6A represents how some interfaces to soft switch 204 sit on top of a common interface used by soft switch 204 to handle off switch call processing.
SCPs and other devices, such as route servers, can use this common interface.
For example, SCP 610 is an off network or off switch SCP, meaning that it is not within soft switch site 104.
Off switch call processing abstraction layer 606 is intended to be a flexible interface, similar to TCAP in function, that allows interaction between any type of SCP (or other call processing logic) and soft switch 204. The abstraction layer is so designed that interfaces to a set of call processors supporting a specific function (e.g:, 800 service), contain the same types of data, and can all map arguments to data elements supported by off switch call processing abstraction layer 606. The field values for messages supplied by off switch call processing abstraction layer 606 are identified in this section (i.e., describing SCPs) and also in the section describing route servers below.
The SCPs can be off switch call processing servers, which support intelligent services within the telecommunications network SCPs 610, 612, and 616 can support such services as, for example, account code verification and toll free/800 services, local number portability (LNP), carrier ID identification, and card services.
Other services and capabilities of SCPs 610, 612, and 616 include basic toll-free services, project account code (PAC) services, local number portability (LNP) services, 800 carrier ID services, calling name (CNAM) services, advanced toll-free/network automatic call distribution (ACD) services, customer premise toll-free routing services, one number (or follow-me) services, and SCP
gateway for customer premises equipment (CPE) route selection services. These services are recognized by those skilled in the art.
Additional services and capabilities can include intelligent peripherals.
Intelligent peripherals can include calling card, debit card, voicemail, unified messaging, conference calling, and operator services. These peripherals are recognized by those skilled in the art.
FIG. 6B illustrates intelligent network architecture 622. FIG. 6B includes gateway site 110, communicating via data network 112, to soft switch 204. The communication can be performed by the H.323 protocol or the IPDC protocol.
Soft switch 204 gains signaling information from signaling network 114 via STP
250, through SS7 gateway 208.
Gateway site 110, in intelligent network architecture 622, is connected to multiple off network service providers. Off network service providers include local exchange Garner (LEC) 624, inter-exchange (IXC) carrier 626 and operator services service bureau 628. Thus calls coming in from LEC 624 or from IXC
626 into gateway site 110, if identified as an operator call, may be routed to off network operator services 628.
Soft switch 204 does nat dictate any particular SCP interface, but it is assumed that this interface will support the following types of interactions:
(I) route request; (2) route response; (3) call gapping; and (4) connect to resource.
A route request is a message sent from soft switch 204 to an external SCP
610. The route request is sent to request a translation service from SCP 610, for example, to translate disclosed digits to a destination number.
A route response is a message sent from SCP 610 to soft switch 204 in response to a route request. The route response includes a sequence of prioritized destinations for the call. SCPs that perform routing can return a list of prioritized destinations. These destinations can be, for example, any combination of destination numbers or circuit groups. If SCP 610 returns a destinations number, soft switch 204 can attempt to route to that destination number using the least cost routing logic included in route server 212. If SCP 610 returns a circuit group, the soft switch 204 can use route server 212 to select an available circuit in that group. Soft switch 204 can try to terminate to the specified destinations in the prioritized order that the destinations are returned from SCP 610.
The interface that can be used by soft switch 204, in order to interact with SCPs 214, 610, 612, and 616, is called the off switch call processing (OSCP) interface. This interface is also used for route server 212 and any other call processing engines. OSCP is represented in FIG. 6A as off switch call processing abstraction layer 606. Tables 8, 9, 10, and 11 identify the fields in the OSCP
route request and route response messages, which are necessary for 800 and account code processing service calls.

Table 8 800 Route Request SCP Route Request800 SCP - Route Request Value Parameter Message Type 800 Route Re uest Call Reference Uni ue call identifier Requesting Soft-SwitchSoft Switch ID

Bearer CapabilityVoice, Data or Fax Destination type DDD (an 8XX number was dialed) Destination Dialed 8XX number Originating LATH LATH from IAM or from DAL rofile Calling Number ANI

Originating stationII-di its from IAM or DAL rofile type Collected Digits Not Used for 800 rocessin .

Table 9 Account Code Route Request OSCP Route Request Account Code SCP - Route Request Parameter I~alue Message Type Account Code Route Re uest Call Reference Uni ue call identifier Requesting Soft-SwitchSoft Switch ID

Bearer Capability Not used for Account Code rocessin Destination type Not used for Account Code rocessin Destination Not used for Account Code rocessin Originating LATH LATH from IAM or from DAL rofile Calling Number ANI

Originating stationII-di its from IAM or DAL rofile type Collected Digits Not Used for Account Code rocessin _ Table 10 ' 800 Route Response OSCP Route Re nest 800 SCP - Route Res onse Virtue Parameter Mess a T 800 Route Res nse Call Reference Uni ue call identifier Result Code Success/fail Number of responses Number of res nses sent from the SCP

Destination circuit Terminating circuit group for group - I the first route if the SCP identifies circuit rou s Destination circuit Not used for 800 rocessin Table 10 800 Route Response OSCP Route Re nest Parameter800 SCP - Route Res nse Value Outpulse digits - I Out ulse di its for selected termination Destination number - Destination number for the 1 first route Destination Soft SwitchNot used for 800 rocessin Destination circuit Terminating circuit group for group - N the Nth route, if the SCP identifies circuit rou s Destination circuit Not used for 800 rocessin - N

Outpulse digits - N Outpulse digit format for selected circuit on the Nth route Destination number - Destination number for the N Nth route Destination Soft SwitchNot used for 800 rocessin~
- N

Table I 0 Account Code Route Response OSCP Route Request Parameter Account Code SCP
- Route Response Value Call Reference Uni ue call identifier Result Code Success/fail Number of responses 0 - this is a success/fail res onse 15 Destination circuit group Not used for accountr - 1 code i ocess Destination circuit - I Not used for accountn code i rocess Outpulse digits - 1 Not used for accountn code i rocess Destination number - 1 Not used for accountn code i rocess Destination Soft Switch - 1 Not used for accountn code i rocess 20 Destination circuit group Not used for accountn - N code i rocess Destination circuit - N Not used for accountn code i rocess Outpulse digits - N Not used for accountn code r i ocess Destination number - N Not used for accountn code i rocess Destination Soft Switch - N Not used for accountn code r i ocess n 25 A route response can also include an indication to initiate a call gapping for a congested call. Call gapping refers to a message sent from an SCP to a soft switch to control the number and frequency of requests sent to that SCP. The call gapping response can indicate a length of time for which gapping should be active, as well as a gap interval, at which the soft switch should space requests 30 going to the SCP. Call gapping can be activated on the SCP for each individual service supported on the SCP. For example, if SCP 2I4 supports 800 and project WO 00/31933 PC'T/US99/27658 account code queries, it may gap on 800, but not on project account codes.
Alternatively, SCP 214 can gap on project codes but not on 800, or can gap on both or neither.
A connect-to resource is a response that is sent from the SCP to the soft S switch in response to a route request for requests that require a call termination announcement to be played.
FIG. 6C illustrates additional off switch services 630. For example, calling card interactive voice response (IVR) 632 services can be provided off switch, similarly to operator services 628. FIG. 6C also depicts on-switch SCP
services. Specifically, project account codes (PAC) SCP 2I4a and basic toll-free SCP 214b communicate with soft switch 204 via an INAP/IP protocol 620.
Project account codes are discussed further below. Basic toll-free services are also discussed further below.
FIG. 6D depicts additional services 634. For example, FIG. 6D depicts I S service node/IP 656, which can be a voice services platform with a voice over IP
(VOIP) interface on data network 112. In addition, network IVR 654 is depicted.
Network IVR 654 is an IVR that connects to data network 112. Network IVR
654 can communicate with soft switch 204 via the IPDC protocol. Network IVR
654 is also in communication with an advanced toll-free SCP 648, via the SR
3511 protocol.
Advanced toll-free SCP 648 is in communication with soft switch 204 via INAP/IP protocol 620. Advanced toll-free SCP 648 is also in communication with computer telephony integration (CTI) server 650. CTI server 650 can communicate with an automatic call distributor (ACD) 652.
FIG. 6D also depicts an IP client connected via a customer network into data network 112. Specifically, IP-Client 660 is connected to data network 112 via customer network 658. Customer network 658 is connected to data network 112 and communicates via an H.323 protocol or via IPDC protocol 602 through data network 1 I2 to soft switch 204. Soft switch 204 is in communication with SS7 gateway 208 via a TCAP/SS7 608 protocol. SS7 gateway 208 is in turn in communication with STP 208 via a TCAP/SS7 608 protocol. STP 208 in turn can communicate with SCPs in the SS7 network via the TCAP/SS7 608 protocol.
Specifically, STP 208 can communicate with local number portability (LNP) SCP
636 and also 800 carrier SCP 610. Soft switch 204 can still communicate with PAC SCP 214A and basic toll-free SCP 214B via an INAP/IP 620 protocol. Soft switch 204 can also communicate with an SCP gateway 638 via an INAP/IP 620 protocol. SCP gateway 638 can be used to communicate with customer premises toll-free 640 facilities. Customer premises toll-free 640 facilities can communicate with computer telephony integration (CTI) server 642. CTI server 642 can be in communication with an automatic call distributer (ACD) 644.
The H.323 Recommendation will now be briefly overviewed with reference to FIGS. 58A-61. The H.323 standard provides a foundation for, for example, audio, video, and data communications across IP-based networks, including the Internet. By complying with the H.323 Recommendation, multimedia products and applications from multiple vendors can interoperate, allowing users to communicate without concern for compatibility. H.323 will be the foundation of future LAN-based products for consumer, business, entertainment, and professional applications.
H.323 is an umbrella recommendation from the International Telecommunications Union (ITU} that sets standards for multimedia communications over Local Area Networks (LANs) that do not provide a guaranteed Quality of Service (QoS). These networks dominate today's corporate desktops and include packet-switched TCP/IP and IPX over Ethernet, Fast Ethernet and Token Ring network technologies. Therefore, the H.323 standards are important building blocks for a broad new range of collaborative, LAN-based applications for multimedia communications.
The H.323 specif cation was approved in 1996 by the ITU's Study Group 16. Version 2 was approved in January 1998. The standard is broad in scope and includes both stand-alone devices and embedded personal computer technology as well as point-to-point and multipoint conferences. H.323 also addresses call control, multimedia management, and bandwidth management as well as interfaces between LANs and other networks.
H.323 is part of a larger series of communications standards that enable videoconferencing across a range of networks. Known as H.32X, this series includes H.320 and H.324, which address ISDN and PSTN communications, respectively.
FIG. 58A depicts a block diagram of the H.323 architecture for a network-based communications system 5800. H.323 defines four major components for network-based communications system 5800, including: terminals 5802, 5804 and 5810, gateways 5806, gatekeepers 5808. and multipoint control units 5812.
Terminals 5802, 5804, 5810 are the client endpoints on the LAN that provide real-time, two-way communications. All terminals must support voice communications; video and data are optional. H.323 specifies the modes of 1 S operation required for different audio, video, and/or data terminals to work together. It is the dominant standard of the next generation of Internet phones, audio conferencing terminals, and video conferencing technologies.
All H.323 terminals must also support H.245, which is used to negotiate channel usage and capabilities. FIG. 58B depicts an exemplary H.323 terminal 5802. Three other components are required: Q.93I for call signaling and call setup, a component called Registration/Admission/Status (RAS), which is a protocol used to communicate with a gatekeeper 5808; and support for RTP/RTCP for sequencing audio and video packets.
Optional components in an H.323 terminal are video codecs, T.120 data conferencing protocols, and MCU capabilities (described further below).
Gateway 5806 is an optional element in an H.323 conference. FIG. 59 depicts an example H.323 gateway. Gateways 5806 provide many services, the most common being a translation function between H.323 conferencing endpoints and othertetminal types. This function includes translation between transmission formats (i.e. H.225.0 to H.221 ) and between communications procedures (i.e.

H.24S to H.242). In addition, gateway 5806 also translates between audio and video codecs and performs call setup and clearing on both the LAN side and the switched-circuit network side. FIG. S9 shows an H.323/PSTN Gateway 5806.
In general, the purpose of gateway 5806 is to reflect the characteristics of S a LAN endpoint to an SCN endpoint and vice versa. The primary applications of gateways 5806 are likely to be:
~ Establishing links with analog PSTN terminals.
~ Establishing links with remote H.320-compliant terminals over ISDN-based switched-circuit networks.
~ Establishing Iinks with remote H.324-compliant terminals over PSTN
networks Gateways 5806 are not required if connections to other networks are not needed, since endpoints may directly communicate with other endpoints on the same LAN. Terminals communicate with gateways 5806 using the H.24S and 1 S Q.931 protocols.
With the appropriate transcoders, H.323 gateways 5806 can support, terminals that comply with H.310, H.321, H.322, and V.70.
Many gateway 5806 functions are left to the designer. For example, the actual number of H.323 terminals that can communicate through the gateway is not subject to standardization. Similarly, the number of SCN connections, the number of simultaneous independent conferences supported, the audio/video/data conversion functions, and inclusion of multipoint functions are left to the manufacturer. By incorporating gateway 5806 technology into the H.323 specification, the ITU has positioned H.323 as the glue that holds the world of 2S standards-based conferencing endpoints together.
Gatekeeper 5808 is the most important component of an H.323 enabled network. It acts as the central point for all calls within its zone and provides call control services to registered endpoints. In many ways, an H.323 gatekeeper acts as a virtual switch.

Gatekeepers 5808 perform two important call control functions. The first is address translation from LAN aliases for terminals and gateways to IP or IPX
addresses, as defined in the RAS specification. The second function is bandwidth management, which is also designated within RAS. For instance, if a network S manager has specified a threshold for the number of simultaneous conferences on the LAN, the Gatekeeper 5808 can refuse to make any more connections once the threshold is reached. The effect is to limit the total conferencing bandwidth to some fraction of the total available; the remaining capacity is left for e-mail, file transfers, and other LAN protocols. FIG. 60 depicts a collection of all terminals, gateways 5806, and multipoint control units 5812 which can be managed by a single gatekeeper 5808. This collection of elements is known as an H.323 Zone.
An optional, but valuable feature of a gatekeeper 5808 is its ability to route H.323 calls. By routing a call through a gatekeeper, it can be controlled more effectively. Service providers need this ability in order to bill for calls placed through their network. This service can also be used to re-route a call to another endpoint if a called endpoint is unavailable. In addition, a gatekeeper 5808 capable of routing H.323 calls can help make decisions involving balancing among multiple gateways. For instance, if a call is routed through a gatekeeper 5808, that gatekeeper 5808 can then re-route the call to one of many gateways based on some proprietary routing logic.
While a gatekeeper 5808 ,is logically separate from H.323 endpoints, vendors can incorporate gatekeeper 5808 functionality into the physical implementation of gateways 5806 and MCUs 5812.
Gatekeeper 5808 is not required in an H.323 system. However, if a gatekeeper 5808 is present, terminals must make use of the services offered by gatekeepers 5808. RAS defines these as address translation, admissions control, bandwidth control, and zone management.
Gatekeepers 5808 can also play a role in multipoint connections. To support multipoint conferences, users would employ a Gatekeeper S 808 to receive H.245 Control Channels from two terminals in a point-to-point conference. When _77_ the conference switches to multipoint, the gatekeeper can redirect the H.245 Control Channel to a multipoint controller, the MC. Gatekeeper 5808 need not process the H.245 signaling; it only needs to pass it between the terminals 5802, 5804, 5808 or the terminals and the MC.
S LANs which contain Gateways 5806 could also contain a gatekeeper 5808 to translate incoming E.164 addresses into Transport Addresses. Because a Zone is defined by its gatekeeper 5808, H.323 entities that contain an internal gatekeeper 5808 require a mechanism to disable the internal function so that when there are multiple H.323 entities that contain a gatekeeper 5808 on a LAN, the entities can be configured into the same Zone.
The Multipoint Control Unit (MCU) 5812 supports conferences between three or more endpoints. Under H.323, an MCU 5812 consists of a Multipoint Controller (MC), which is required, and zero or more Multipoint Processors (MP). The MC handles H.245 negotiations between all terminals to determine common capabilities for audio and video processing. The MC also controls conference resources by determining which, if any, of the audio and video streams will be muiticast. MCU 2112 is depicted in FIG. 61.
The MC does not deal directly with any of the media streams. This is left to the MP, which mixes, switches, and processes audio, video, and/or data bits.
MC and MP capabilities can exist in a dedicated component or be part of other H.323 components. A soft switch includes some functions of an MP. An access server, also sometimes referred to as a media gateway controller, includes some of the functions of the MC. MCs and MPs are discussed further below with respect to the IPDC protocol.
Approved in January of 1998, version 2 of the H.323 standard addresses deficiencies in version 1 and introduces new functionality within existing protocols, such as Q.931, H.245 and H.225, as well as entirely new protocols.
The most significant advances were in security, fast call setup, supplementary services and T.120/H.323 integration.

( 1 ) Project Account Codes Project Account Codes can be used for tracking calls for billing, invoicing, and Class of Service (COS) restrictions. Project account code (PAC) verifications can include, for example, types Unverified Unforced, Unverified Forced, Verified Forced, and Partially Verified Forced. A web interface can be provided for a business customer to manage its accounts. The business customer can use the web interface to make additions, deletions, changes, and modifications to PAC translations without involvement of a carner's customer service department.
An example of call processing using PACs follows. PAC SCP 214a of FIG. 6C can receive validation requests from Soft-Switch 204 after Soft-Switch 204 has requested and received PAC digits. The PAC digits can be forwarded to SCP 214a for verification. When SCP 214a receives this request, SCP 214a can compare the entire PAC, if the PAC type is Verified Forced, against a customer PAC table. SCP 214a can compare only the verified portion of the PAC, if the PAC type is Partially Verified Forced, against the customer PAC table.
The PAC digits can be sent from Soft-Switch 204 to SCP 214a in the 'Caller Entered Digits' field. The indicated customer can be sent from Soft-Switch 204 to SCP 214a in the 'Customer' field.
(2) Basic Toll-Free Basic Toll-Free Service SCP 214b can translate a toll free (e.g., 800 and 888) number to a final routing destination based on a flexible set of options selected by a subscriber. Basic toll-free service supports e.g., 800 and 8XX
Service Access Codes. Subscriber options can include, for example: 1 ) routing based on NPA or NPA-NXX of calling party; 2) routing based on time of day and day of week; 3) routing based on percent distribution; 4) emergency override routing; and 5) blocking based on calling party's NPA or NPA-NXX or ii-digits.
An exemplary embodiment of basic toll-free SCP 214b is a GENESYS
Network Interaction Router available from GENESYS of San Francisco, CA.

The GENESYS Network Interaction Router product suite provides Basic Toll-Free service. Soft-Switch 204 can send route requests to SCP 214b for any Toll Free numbers that Soft-Switch 204 receives. SCP 214b can then attempt to route the call using a route plan or trigger plan that has been defined for that Toll Free (dialed) number. SCP 214b can have several possible responses to a soft switch routing request, see Table 10 above. Using the subscriber routing option (described in the previous paragraph) SCP 214b can return a number translation for the Toll Free number. For example, SCP 214b can receive a dialed number of 800-202-2020 and return a DDD such as 303-926-3000. Alternatively, SCP
214b can return a circuit identifier. SCP 214b usually returns a circuit identifier when the termination is a dedicated trunk to a customer premise equipment (CPE). Then if SCP 214b determines that it can not route the call or has determined to block the call (per the route plan), SCP 214b returns a 'route to resource' response to Soft-Switch 204 with an announcement identifier. In this case Soft-Switch 204 can connect the calling party with Announcement Server 246 for the playing of an announcement and then disconnect the caller.
SCP 214b can store call events in CDR database tables on SCP 214b.
CDR database tables can then be replicated to Master Network Event Database 226 using a data distributor 222, such as, for example, the Oracle Replication Server.
e. Configuration Server (CS) or Configuration Database (CDB) The configuration server 206 will now be described in greater detail with reference to FIG. 2. Configuration server 206 supports transaction requests to a database containing information needed by network components. Configuration server 206 supports queries by voice network components during initialization and call processing. The data contained within conf guration server 206 databases can be divided into two types. The first type of data is that used to initialize connections between components. Examples of such data used to initialize connections between network components include the following: IP

address and port numbers for all servers that soft switch 204 must communicate with; information indicating initial primary/secondary/tertiary configurations for server relationships; configuration information for access gateways 23 8, 240 and trunking gateways 232, 234; number and configuration of bays, modules, lines and channels (BMLC); relationship of module, line and channels to originating point code (OPC), destination point code (DPC) and circuit identification code (CIC) values; relationship of module, line and channels to trunk groups; call processing decision trees for soft switch processing; mapping of OPC, DPC and CIC values soft switches 204; mapping of access server 254, 256 ports to dedicated access line (DAL) identifiers and customer IDs; tables necessary to support class of service (COS) restrictions; local access transport area (LATA) tables; state tables; and blocked country code tables.
The second set of data can be categorized as that data needed by soft switch 204 for use during call processing. This type of data includes customer I S and DAL profiles. These profiles define the services that a customer has associated with their ANIs or DALs. This information can include information describing class of service restrictions and account code settings.
The database of configuration server 206 contains voice network topology information as well as basic data tables necessary for soft switch 204 call processing logic. Configuration server 206 is queried by soft switches 204 at start-up and upon changes to this information in order to set up the initial connections between elements of telecommunications network 200.
Configuration server 206 is also queried by soft switches 204 in order to configure initial settings within soft switch 204.
Configuration server 206 contains the following types of information: IP
address and port numbers for all servers that soft switch 204 must communicate with; information indicating initial primary/secondary/tertiary configurations for server relationships; configuration information for AGs 238, 240 and TGs 232, 234; call processing decision trees for soft switch 204 call processing;
mapping of OPC, DPC and CIC values to soft switch 204: mapping of access server 254, 256 ports to DALs and customer IDs; and tables necessary to support COS
restrictions.
Configuration information for AGs and TGs includes: number and configuration of bays, modules, lines and channels; relationship of modules, line and channels to OPC, DPC and CIC values; and relationship of module, line and channels to trunk groups.
Tables necessary to support class of service restrictions include: LATA
tables; state tables; and blocked country code tables.
Configuration server 206 also contains information related to customer trigger plans and service options. Customer trigger plans provide call processing logic used in connecting a call. Configuration server 206 information is queried during call processing to identify the service logic to be executed for each call.
The information that soft switch 204 uses to look-up customer profile data is the ANI, trunk ID or destination number for the call. The information that will be returned defines the call processing logic that is associated with ANI, trunk ID
or destination number or trunk group.
Table 12 includes an example of a customer profile query.
Table 12 Customer Profile Query Customer Pro tie ue Value Field Customer identificationDDD, DAL ID, Customer ID
type Customer identificationThe value for the DDD, Trunk ID

Table 13 includes an example of a customer profile query response provided by configuration server 206.
Table 13 Customer Profile Query Response Customer Profile Response-:~~~
Field Customer identification DDD, Trunk ID
type Customer Identification The value for the DDD Trunk ID

Table Customer Profile Query Response Customer Profile Response Field Value Class of Service restriction None Type Intrastate IntraLATA

Domestic Domestic and selected international Selected International List When the class of service ID restriction type is domestic and selected international destinations, this is an index to the list of allowed international destinations.

Account Code Type None Verified Forced Unverified Forced Unverified Unforced Partiall Verified Forced Account code length 2 - 12 di its Local Service Area, State, LATH, For queries on numbers, these fields are and Country identify the geographic information that is necessa to rocess the call.

Configuration server 206 interfaces to components. Configuration server 206 receives provisioning and reference data updates from data distributor 222 of provisioning component 222. Configuration server 206 also provides data to soft switch 204 for call processing. Configuration server 206 is used by soft switch 204 to retrieve information necessary for initialization and call processing.
Information that soft switch 204 retrieves from configuration server 206 during a query is primarily oriented towards customer service provisioning and gateway site 108, 110 port configuration. Configuration server 206 database tables 1 S accessible to soft switch 204 include the following: toll free number to SCP type translation; SCP type to SCP translation; CICs profiles; ANI profiles summary;
ANI profiles; account code profiles; NPAINXX; customer profiles; customer location profiles; equipment service profiles; trunk group service profile summaries; trunk group services; high risk countries; and selected international destinations.
Configuration server 206 uses a separate physical interface for all SNMP
messages and additional functions that may be defined. Examples of additional functions that may be defined include provisioning, updating, and the passage of special alarms and performance parameters to configuration server 206 from the NOC.
In an alternative embodiment, the functionality of configuration server 206 can be combined with that of route server 2I2 in a single network component. In an additional embodiment of the invention. the functions of either or both of CS 206 and RS 212 can be performed by application logic residing on soft switch 204.
f. Route Server (RS) FIG. 8A depicts route server support for an exemplary soft switch site I 0 800. FIG. 8A includes route server 212a and route server 212b. Route servers 212a and 212b are connected via redundant connections to soft switches 204x, 204b and 204c. Soft switches 204x, 204b and 204c are in turn connected to gateway sites via data network 112 (not For example, soft shown). switch 204a is in communication with TG 232a and TG Similarly soft switch 232b. 204b is in communication with AG 238a and TG Soft switch 204c is 234a. in turn in communication with AG 238b and AG 240a. It would be apparent to a person skilled in the art that additional TGs and AGs, as well as other gateway site devices, (such as a NAS device) can also be in communication with soft switches 204a, 204b and 204c.
Route server 212 will now be described in further detail with reference to FIG. 2. Route server 2I2 provides at least two functions. Route server 212 performs the function of supporting the logic for routing calls based upon a phone number. This routing, performed by route server 212, results in the selection of one or more circuit groups for termination.
Another function of route server 212 is the tracking and allocation of network ports. As shown in FIG. 8A, route server 212 (collocated with other components at soft switch site 104) services routing requests for all soft switches 204a, 204b, 204c at that site. Therefore, route server 212 tracks port resources for all TGs 232a, 232b and 234a and AGs 238a, 238b and 240a that are serviced by soft switches 204a, 204b and 204c at soft switch site 104.

( I ) Route Server Routing Logic The routing logic accepts translated phone numbers and uses anywhere from full digit routing to NPA-based routing to identify a terminating circuit group. Routing logic selects the translation based upon the best match of digits in the routing tables. An exemplary routing table is illustrated as Table 14.
Table 14 Number Routing Table Number Terminating Priority Load Circuit Grou 303-926-3000 34 1 50%

303-926-3000 56 1 50%

303-926 76 i In Table 14, there are five entries that can match the dialed number "303-926-3000". The first route choice is the one that has a full match of digits with priority one. Since there are two entries with full matching digits, and which are marked as priority one, the load should be distributed as shown in the load column, (i.e., 50% load share is distributed to the first, and 50% load share is distributed to the second). The second route choice is the entry with a full digit match, but marked with the lower priority of two. The third route match is the one that has a matching NPA-NXX. The last route choice is the one that has a matching NPA only.
In situations where there are multiple route choices for a DDD number (i.e., the number of called party 120) route server 212 must take into consideration several factors when selecting a terminating circuit group. The factors to be considered in selecting a terminating circuit group include: ( 1 ) the percent loading of circuit groups as shown in the load column of Table 14; (2) the throttling use of trunk groups to avoid overloaded networks; (3) the fact that end office trunk groups should be selected before tandem office trunk groups; and (4) routing based upon negotiated off network carrier agreements.
Agreements should be negotiated with off network carriers to provide the flexibility to route calls based upon benefits of one agreement another. The following types of agreements can be accounted for: ( I ) commitments for the number of minutes given to a carrier per month or per year; (2) the agreement that for specific NPA or NPA-NXX sets, one carrier may be preferred over another;
(3) the agreement that international calls to specific countries may have preferred carriers; (4) the agreement that intra-LATH or intra-state calls originating for certain areas may have a preferred carrier in that area; and (5) the agreement that extended area service calls may have a preferred carrier.
The logic for route server 212 can include routing for international calls.
In the example shown in Table 14, it is possible to have fully specified international numbers, or simply specified routing, for calls going to a particular country. As with domestic numbers, the routing logic should select the table entry that matches the most digits within the dialed number, (i.e. the number of called party 120).
(2) Route Server Circuit Management Once a terminating circuit group has been identified, route server 212 needs to allocate a terminating circuit within the trunk group. The selection of a terminating circuit is made by querying the port status table. Table I SA
shows an exemplary port status table. The results of a query to port status Table 1 SA
yields the location and allocation of a circuit. Route server 212 can use algorithms to select circuits within the trunk group. Each circuit group can be tagged with the selected algorithm that should be used when selecting circuits within that group.
Example algorithms to select circuits within the group include: ( I ) the most recently used circuit within a circuit group; (2) the least recently used circuit within a circuit group; (3) a circular search, keeping track of the last used circuit and selecting the next available circuit; (4} the random selection of an available -$6-circuit within a circuit group; and (5) a sequential search of circuits within a circuit group, selecting the lowest numbered available circuit. Table 15A
illustrates the association between a circuit group and the selection algorithm that should be used to allocate ports from that group.
Table 15A

Circuit Group Parameters Circuit rou Selection al orithm 34 Random 35 Least recentl used Table i5B

Port Status Circuit rou Port Status 34 3-4-6-1 Avail 34 3-4-6-2 In-use 34 3-4-6-3 avai I

avai I

Table 15B includes the circuit group (that a port is a member of), a port identifier, and the current status of that port. The port identifier shown in Table 1 SB assumes the type of port identification currently used in the IPDC
protocol, where the port is represented by a bay, module, line and channel (BMLC). It would be apparent to persons skilled in the art that other methods of identifying a port can be used.
The function of route server 212 is to provide least-cost routing information to soft switch 204, in order to route a call from calling party 102 to called party 120. In addition to providing routing information, route server allocates ports for terminating calls on the least cost routes, e.g., allocating ports within TGs 232, 234. Route server pair 2I2 is located at each of soft switch sites 104,106, 302 and services all soft switches 204a, 204b, 204c, 304a, 304b, 304c, 306x, 306b and 306c at that site. (Refer to Fig. 3.}

w0 00/31933 PCT/US99/27658 _87_ Route server 212 interacts with at least two other voice network components. Route server 212 interacts with configuration server 206.
Conf guration server 206 is used to retrieve initial information on route server 212 start-up to set up the initial routing tables in preparation for receiving requests from soft switches 204a, 204b and 204c, for example.
Route server 212 also interfaces with soft switch 204. Soft switch 204 can send route requests to route server 212 that contain either a phone number or a circuit group. Route server 212 can perform its least cost routing logic to first select a terminating circuit group for the call. Using that circuit group, route server 212 can then select and allocate a terminating circuit.
A description of the messages and model of interaction between route server 212 and soft switch 204 follows. Route server 212 is used by soft switch 204 to identify the possible network terminations for a call. Soft switch 204 passes a DDD number, an international DDD (IDDD) number, or a circuit group to mute server 212 in a "route request" message. Using this information from soft switch 204, route server 212 can return the port on an AG 238, 240 or TG 232, 234 that should be used to tenminate this call. Using this port information, soft switch 204 can then signal the originating and terminating TG or AG to connect the call through data network 112.
The route server 212 will now be described further with reference to FIG. 2B. FIG. 2B depicts a sample call flow 258, illustrating how soft switch interacts with route server 212 to identify a terminating port for a call.
In exemplary call flow 258, the call originates and terminates at different sites, specifically, gateway sites 108, and 110. Since exemplary call flow 258 originates and terminates at different sites, the cooperation of the originating soft switch 204 and terminating soft switch 304 and route servers 212, 314, respectively to identify the terminating circuit. Portions of the call flow will now be described in greater detail.
As depicted in step 259, for calls arriving on SS7 signal trunks, soft switch 204 receives call arrival notifications in the form of IAM messages.
Upon WO 00/31933 PCT/US99l27658 _88_ receipt of the IAM message from SS7 GW 208, soft switch 204 performs some initial digit analysis to determine the type of the call.
In step 260, for calls involving customer features, soft switch 204 can use the ANI of calling party 102 (i.e., the telephone number of calling party 102) to query a customer prof le database in configuration server 206. This is done to identify the originating customer's feature set. Each customer's feature set is known as a "trigger plan" for origination of the calf. A trigger plan can be thought of as a flowchart which branches based on certain triggering events dependent on the caller's identity. Customer trigger plans 290 reside in a customer profile on configuration server 206.
In step 262, the customer profile database of configuration server 206 returns the customer trigger plan 290 to soft switch 204. Soft switch 204 can perform any processing necessary to implement the customer's specified originating triggers.
Application logic in soft switch 204 can then generate a translated number or an identification of the terminating circuit group for this call. For example, in the case of an 800 call, a translation may be requested as in step 265 of an SCP
214. SCP 214 converts the 800 number into a normal number for termination, and in step 266 returns the number to soft switch 204.
In step 267, in order to translate the translated number or circuit group into an egress port, soft switch 204 makes a route request to route server 212.
The routing logic uses the NPA-NXX-~S;XXX to identify the terminating circuit group. Upon identifying the terminating circuit group, the route logic queries a circuit group to soft switch mapping table in route logic 294 of route server 212, to identify the target soft switch that handles the identified termination.
For example, the target soft switch may be soft switch 304. It is important to note that there can be multiple route choices, and therefore there can be multiple soft switches 204, 304 supporting a single route request.
In step 268, route server 212 responds to soft switch 204 with the terminating circuit group. In this example, the terminating circuit group is included in trunks connected to trunking gateway 234, which is serviced by a different soft switch (namely soft switch 304) than originating soft switch 204.
Therefore, route server 212 responds with the terminating circuit group and identifies soft switch 304 as the soft switch that harid'les that terminating circuit group.
In step 269, originating soft switch 204 initiates the connection from the origination to the termination, by requesting a connection from the originating trunking gateway 232. Trunking gateway 232, upon receipt of the set-up request from soft switch 204, allocates internal resources in trunking gateway 232.
TG 232 manages its own ports. In an example embodiment, TG 232 uses real time protocol (RTP) over UDP, and RTP sessions, which are ports used to implement an RTP connection. In step 270, TG 232 returns to soft switch 204 the IP address and listed RTP port.
In step 274, originating soft switch 204 issues a call setup command to terminating soft switch 304. This is the command identified by route server 212.
In step 276, soft switch 304 queries route server 314 to determine the termination port for the call. Specifically, soft switch 304 queries port status 298 of route server 314. The query in step 276, "passes in" as a parameter the terminating circuit group.
In step 278, route server 314 allocates a termination port and returns the allocated termination port to terminating soft switch 304.
In step 280, terminating soft switch 304 instructs the identified end point (i.e., trunking gateway 234) to reserve resources, and to connect the call.
Terminating soft switch 304 passes in an IP address and an RTP port corresponding to the port that was allocated by originating TG 232.
In step 282, terminating TG 234 returns the allocated resources for the call to soft switch 304. For voice over IP (VOIP) connections, this includes the listed port and IP address for the terminating TG 234.
In step 284, terminating soft switch 304 returns to originating soft switch 204 the IP address of TG 234.
In step 286, originating soft switch 204 communicates with originating TG 232 in order to inform originating TG 232 of the listed port that was allocated by terminating TG 234. At this point, originating TG 232 and terminating TG
234 have enough information to exchange full duplex information.
In step 288, originating TG 232 acknowledges the receipt of the communication from soft switch 304 to soft switch 204.
Table 16A shows fields that can be included in a route request sent from soft switch 204 to route server 212. The route request can contain either a DDD
number or a circuit group that requires routing. The route request message can also contain information about the call, collected from the IAM message, that is necessary to perform routing of this call. The route request message can also contain information about the call, necessary to perform routing of the call, which is obtained from the processing of the call. For example, in the case of an call, this information can be a translated number.
i Table 16A

Values for Route Request sent to tl:e Route Server OSCP Route Request ParameterRoate Server - Route Re nest Message Type Value Route Server Route Re uest Call Reference Uni ue call identifier Requesting Soft Switch Soft Switch ID

Bearer Capability Voice, Data or Fax Destination type DDD or circuit rou Destination Fully translated DDD (or IDDD) number or circuit rou ID

Originating LATH LATH from IAM or from DAL
Calling Number roflle ANI

Originating station type iI-di its from IAM or DAL
Collected Digits rofile Not Used for Route Server Table 16B shows fields which can be included in a response corresponding to the route response, sent from route server 212 back to soft switch 204.
Alternatively, each route response can include one route termination, and multiple consecutive route terminations can be determined with multiple route request/response transactions.

Table 16B

Values fur Route Response sent from tl:e Route Server Customer Profile QueryRoute Server - Route Response Fleld Value Message Type Route Server Route Res onse Call Reference Uni ue catl identifier Result code Success/Fail Number of responses Number of responses sent from the route server Destination circuit Terminatin circuit rou for the group - 1 first route Destination circuit Terminating circuit allocated - 1 by the route server for the first route Out ul di it p Outpulse digit format for selected se circuit on g s -the first route Destination number Destination number for the first - 1 route Destination Soft SwitchSoft switch servicing the circuit - ! group for the first route Destination circuit Terminatin circuit rou for the group - N Nth route Destination circuit Terminating circuit allocated - N by the route server for the Nth route Outpulse digits - N

Outpulse digit format for selected circuit on the Nth route Destination number Destination number for the Nth - N route Destination Soft SwitchSoft switch servicing the circuit - N group for the Nth route The route response message can contain a plurality of route terminations for the DDD or circuit group that was passed in as a parameter to route server 212. For example, the route response message can include 1 to 5 route choices.
Each of the route choices of the route response message can include various fields of information. For example, etch route choice can include the following information: the circuit group, the circuit, the outpulse digits, the destination ntunber and the destination soft switch 304. Alternatively, each route response can include one route termination and multiple consecutive route terminations can be determined with multiple route request/route response transactions.
In situations where the selected circuit group is managed by the same route server 212 that serviced the route request. the response for that route can contain all the information about the destination. This is possible because route server 212 can identify and allocate the circuit within the circuit group.
In situations where another route server 314 services the selected circuit group, the response for that route only contains the circuit group and the destination soft switch 304. Originating soft switch 204 can then make a request to terminating soft switch 304 to query the terminating route server 314 for a circuit within the identified circuit group. The terminating soft switch 304 can then control the termination of the call.
g. Regional Network Event Collection Point (RNECP) Referring back to FIG. 2A, regional network event collection points (RNECPs) 224 serve as collection points for real-time recorded call events that can be used by other systems. Soft switch 204 generates call data. This call data can be collected during call processing. Call data can also be generated by capturing events from other network elements. These network elements include internal soft switch site 104 components and external components. External components include SCPs 214, intelligent peripherals (IPs), AGs 238,240, TGs 232, 234, and signaling components, such as STPs 250,252, SSPs, and off switch SCPs.
Soft switch 204 provides call event data to RNECPs 224. Call data can be collected by a primary and secondary server at each RNECP 224, using high availability redundancy to minimize the possibility of potential data loss.
Data from RNECPs 224 can then be transmitted in real-time to a centralized server, called the master network event database (MNEDB) 226. The MNEDB is discussed further below, with reference to FIG. 20.
FIG. 9 depicts a network event collection architecture 900. FIG. 9 includes western soft switch site 104, central soft switch site 106 and eastern soft switch site 302. Soft switch sites 104. 106, 302 are illustrated as including RNE
CPs for collecting events and routing events to a master database.
Specifically, western soft switch site 104 has soft switches 204a, 204b, 204c communicating via a local area network to RNECPs 224a, 224b. RNECPs can include disks 914, 916. RNECPs 224a, 224b can be in direct communication with, as well as can take a primary and a secondary role in communicating with, soft switches 204a, 204b, 204c.

RNECPs 224a, 224b can route network events through management virtual private network (VPN) 910 to master network event data center 912.
Network events come through management VPN 910 and can be routed via redundant paths to MNEDB server 226a and/or MNEDB 226b. MNEDBs 226a and 226b can communicate with one another. MNEDB 226a uses disks 926a as primary storage for its database. MNEDB 226a also uses disks 926b for secondary storage. Similarly MNEDB 226b uses primary and secondary disks, 926x, 926b.
MNEDB 226a and MNEDB 226b can be collocated or can be geographically diverse. Thus master data center 912 can be either in one geographical area or in multiple locations. , Management VPN 910 also collects events from the other soft switch sites, i.e., central soft switch site 106 and eastern soft switch site 302.
Central soft switch site 106 includes soft switches 304a, 304b, 304c redundantly connected via a LAN to RNECPs 902 and 904. RNECP 902 has disks 918 and 920.
Eastern soft switch site 302 includes soft switches 306a, 306b, 306c, redundantly connected via a LAN. RNECPs 906 and 908 RNECP 906 can have disks 922 and 924.
RNECPs 902 and 904 of central soft switch site 106 and RNECPs 906 and 908 of eastern soft switch site 302 can route network events for storage in disks 926x, 926b of MNEDBs 226a, 226b.
This is done by routing network events via management VPN 910 to master data center 912. The soft switches generate event blocks and push event block data to the RNECPs. (Event blocks are recorded call events that are created during call processing.) Each RNECP 224a, 224b, 902, 904, 906 and 908 forwards collected event blocks (EBs) to (MNEDBs) 226a, 226b, which are centralized databases.
RNECPs 224a, 224b, 902, 904, 906 and 908 use separate physical interfaces for all SNMP messages and additional functions that may be defined. Additional functions that can be defined include provisioning, updating, and passing special alarm and/or performance parameters to RNECPs from the network operation center (NOC).
RNECPs 224a, 224b, 902, 904, 906 and 908 are used by soft switches 204a, 204b, 204c, 304a, 304b, 304c, 306a, 306b and 306c to collect generated call events for use in such services as preparation of billing and reporting. At specific points throughout the duration of a call, soft switches 204a, 204b, 204c, 304a, 304b, 304c, 306a, 306b and 306c take the information that the soft switches have collected during call processing and push that data to the RNECPs.
Multiple types of data are logged by the soft switches during call processing of a normal one plus (1+) long distance call using account codes.
Examples of data logged by an exemplary soft switch 204 include: a call origination record on the originating side, call termination information on the terminating side, an account code record, egress routing information, answer information on the originating side, call disconnect information on the originating side, call disconnect information on the terminating side, and final event blocks with call statistics.
Exemplary soft switch 204 can record data during call processing. Soft switch 204 transfers call events from RNECP 224 to MNEDB 226 for storage.
This call event data, stored in MNEDB 226, can be used by various downstream systems for post-processing. These systems include, for example, mediation, end-user billing, carrier access billing services (CABS), fraud detectionlprevention, capacity management and marketing.
There are at least two types ofEBs. Example Mandatory and Augmenting event blocks can be explained as follows.
Mandatory EBs are created by soft switch 204 during the initial point-in-call analysis. Initial point-in-call analysis includes going off hook, (picking up the telephone set) call <insert> setup, initial digit analysis (i.e., digit analysis prior to any external database transactions or route determinations).
Since other events such as, for example, session/call answer, and SCP
transactions, can occur during call processing, soft switch 204 can create augmenting EBs. Augmenting EBs are EBs which can augment the information found in a mandatory EB. Events such as, for example, route determination, and answer indication, can be recorded in an augmenting EBs.
Examples of mandatory and augmenting EBs follow. For a complete illustration of these EBs, the reader is referred to Tables 20-143 and the corresponding discussions below. Specifically, Tables 20-48 provide mandatory EBs, Tables 49-60 provide augmenting EBs, and Tables 61-143 provide the call event elements that comprise the Ebs.
( I ) Example Mandatory Event Blocks EBs The following event blocks are examples of Mandatory Event Blocks:
EB 0001 - Domestic Toll (TG Origination);
EB 0002 - Domestic Toll (TG Termination);
EB 0003 - Domestic Toll (AG Origination);
EB 0004 - Domestic Toll (AG Termination);
EB 0005 - Local (TG Origination);
I5 EB 0006 - Local (TG Termination);
EB 0007 - Local (AG Origination);
EB 0008 - Local (AG Termination);
EB 0009 - 8XX/Toll-Free (TG Origination);
EB 0010 - 8XX/Toll-Free (TG Termination);
EB 0011 - 8XX/ToII-Free (AG Origination);
EB 0012 - 8XX/ToII Free (AG Termination);
EB 0013 - Domestic Operator Services (TG Termination);
EB 0014 - Domestic Operator Services (AG Origination};
EB 0015 - Domestic Operator Services (OSP Termination);
EB 0016 - International Operator Services (TG Origination);
EB 0017 - International Operator Services (AG Origination);
EB 0018 - International Operator Services (OSP Termination);
EB 0019 - Directory Assistance/555-1212 (TG Origination);
EB 0020 - Directory Assistance/555-1212 (AG Origination);
EB 0021 - Directory Assistance/555-1212 (DASP Termination);

w0 00/31933 PCT/US99/27658 EB 0022 - OSP/DASP Extended Calls (Domestic);
EB 0023 - OSP/DASP Extended Calls (International);
EB 0024 - International Toll (TG Origination);
EB 0025 - International Toll (AG Origination);
EB 0026 - International Toll (TG Termination);
EB 0027 - International Toll (AG Termination);
EB 0040 - IP Origination; and EB 0041 - IP Termination.
(2) Augmenting Event Blocks EBs The following event blocks are examples of Augmenting Event Blocks:
EB 0050 - Final Event Block;
EB 0051 - Answer Indication;
EB 0052 - Ingress Trunking Disconnect Information;
EB 0053 - Egress Trunking Disconnect Information;
EB 0054 - Basic 8XX/Toll-Free SCP Transaction Information;
EB 0055 - Calling Party (Ported) Information;
EB 0056 - Called Party (Ported) Information;
EB 0057 - Egress Routing Information (TG Termination);
EB 0058 - Routing Congestion Information;
EB 0059 - Account Code Information;
EB 0060 - Egress Routing Information (AG Termination); and EB 0061 - Long Duration Call Information.
h. Software Object Oriented Programming (OOPS) Class Definitions (1) Introduction to Object Oriented Programming (OOP) In an example embodiment, soft switch site 104 comprises a plurality of object oriented programs (OOPs) running on a computer. As apparent to those skilled in the art, soft switch site 104 can alternatively be written in any form of software.
(a) Object Oriented Programming (OOP) Tutorial OOPs can be described at a high level by defining object oriented programming classes. For example, in an embodiment of the present invention, soft switch 204 comprise an OOP written in an OOP language. Example languages include C++ and JAVA. An OOP model is enforced via fundamental mechanisms known as encapsulation, inheritance and polymorphism.
Encapsulation may be thought of as placing a wrapper around the software code and data of a program. The basis of encapsulation is a structure known as a class. An object is a single instance of a class. A class describes general attributes of that object. A class includes a set of data attributes plus a set of allowable operations (i.e., methods). The individual structure or data representation of a class is defined by a set of instance variables.
Inheritance is another feature of an OOP model. A class (called a subclass) may be derived from another class, (called a superclass) wherein the subclass inherits the data attributes and methods of the superclass. The subclass may specialize the superclass by adding code which overrides the data and/or methods of the superclass, or which adds new data attributes and methods.
Thus, inheritance represents a mechanism by which subclasses are more , precisely specified. A new subclass includes all the behavior and specification of all of its ancestors. Inheritance is a major contributor to the increased programmer efficiency provided by the OOP. Inheritance makes it possible for developers to minimize the amount of new code they have to write to create applications. By providing the significant portion of the functionality needed for a particular task, classes on the inheritance hierarchy give the programmer a head start to program design and creation.

Polymorphism refers to having one object and many shapes. It allows a method to have multiple implementations selected based on the type of object passed into a method and location. Methods are passed information as parameters. These are parameters passed as both a method and an invocation of a method. Parameters represent the input values to a function that the method must perform. The parameters are a list of "typed" values which comprise the input data to a particular message. The OOP model may require that the types of the values be exactly matched in order for the message to be understood.
Object-oriented programming is comprised of software objects that interact and communicate with each other by sending one another messages.
Software objects are often modeled from real-world objects.
Object-oriented programs of the present invention are hardware platform independent. Client computer 7008 in a preferred embodiment is a computer workstation, e.g., a Sun UltraSPARC Workstation, available from SUN
Microsystems, Inc., of Palo Alto, CA, running an operating system such as UNIX. Alternatively a system running on another operating system can be used, as would be apparent to those skilled in the art. Other exemplary operating systems include WindowslNT, Windows98, OS/2, Mac OS, and other UNIX-based operating systems. Exemplary UNIX-based operating systems include solaris, IRIX. LINUX, HPUX and OSF. However, the invention is not limited to these platforms, and can be implemented on any appropriate computer systems or operating systems.
An exemplary computer system is shown in FIG. 70B. Other network components of telecommunications network 200, such as, for example, route server 212 and configuration server 206, can also be implemented using computer system 7008 shown in FIG. 70B. Computer system 7008 includes one or more processors 70I2. Processor 7012 is connected to a communication bus 7014.
Client computer 7006 also includes a main memory 7016, preferably random access memory (RAM), and a secondary memory 7018. Secondary memory 7018 includes hard disk drive 7020 and/or a removable storage drive 7022. Removable storage drive 7022 reads from and/or writes to a removable storage unit 7024 in a well known manner. Removable storage unit 7024 can be a floppy diskette drive, a magnetic tape drive or a compact disk drive.
Removable storage unit 7024 includes any computer usable storage medium having stored therein computer software and/or data, such as an object's methods and data.
Client computer 7008 has one or more input devices, including but not limited to a mouse 7026 (or other pointing device such as a digitizer). a keyboard 7028, or any other data entry device.
Computerprograms (also called computer control logic), including object oriented computer programs, are stored in main memory 7016 and/or the secondary memory 7018 and/or removable storage units 7024. Computer programs can also be called computer program products. Such computer programs, when executed, enable computer system 7008 to perform the features of the present invention as discussed herein. In particular_ the rnr.,.",tPr programs, when executed, enable the processor 7012 to perform the features of the present invention. Accordingly, such computer programs represent controllers of computer system 7008.
In another embodiment, the invention is directed to a computer program product comprising a computer readable medium having control logic (computer software) stored therein. The control logic, when executed by processor 7012, causes processor 7012 to perform the functions of the invention as described herein.
In yet another embodiment, the invention is implemented primarily in hardware using, for example, one or more state machines. Implementation of these state machines so as to perform the functions described herein will be apparent to persons skilled in the relevant arts.
(2) Software Objects in an OOP Environment Prior to describing the class definitions in detail, a description of an exemplary software object in an OOP environment is described.

FIG. 70A is a graphical representation of a software object 7002.
Software object 7002 is comprised of methods and variables. Far example software object 7002 includes methods 1-8 7004 and variables Vi-VN 7006.
Methods 7004 are software procedures that, when executed, cause software S objects variables 7006 to be manipulated (as needed) to reflect the effects of actions of software object 7002. The performance of software object 7002 is expressed by its methods 7004. The knowledge of software object 7002 is expressed by its variables 7006.
In object oriented programming, software objects 7002 are outgrowths (or instances) of a particular class. A class defines methods 7004 and variables that are included in a particular type of software object 7002. Software objects 7002 that belong to a class are called instances of the class. A software object 7002 belonging to a particular class will contain specific values for the variables contained in the class. For example, a software class of vehicles may contain objects that define a truck, a car, a trailer and a motorcycle.
In object oriented programming, classes are arranged in a hierarchical structure. Objects that are defined as special cases of a more general class automatically inherit the method and variable definitions of the general class. As noted, the general class is referred to as the superclass. The special case of the general class is referred to as the subclass of the general class. In the above example, vehicles is the general class and is, therefore, referred to as the superclass. The objects (i.e. truck, car, trailer, and motorcycle) are all special cases ofthe general class, and are therefore referred to as subclasses of the vehicle class.
(3) Class Definitions Example OOP class definitions are now described. The functions performed by the methods included in the class definitions, and the type of information stored in and/or passed as parameters in the variables of the classes depicted, will be apparent to those skilled in the art.

(a) Soft Switch Class FIG. 4B depicts a soft switch OOP class 418. Soft switch class 418 may be instantiated to create a soft switch application object. Related OOP
classes will be described with reference to FIGS. 4C, 4D and 4E.
Soft switch class 418 includes variables 420 and methods 422. Variables 420 include information about a soft switch 204, including soft switch 204's identifier (ID), error message information, RNECP information, alarm server information, and run time parameters. Variables 420 can be used to provide information to the methods 422 included in soft switch class 4I8.
Methods 422 can include a method to start a soft switch to receive information, to receive a message, to receive a response to a message, and to perform updates. Methods 422 also include the means to read configuration data, to acknowledge messages, to get call context information from a signaling message, and to get call context information from an IPDC message. Methods 422 also include the means to get call context information from a route response, to get call context information from a route server message, and to forward messages.
FIG. 4B includes SS7 gateway proxy 424 which can have inter-object communication with soft switch class 418. FIG. 4B also includes route server proxy 426 and configuration server proxy 428, which can also have inter-object communication. These proxies can also be instantiated by soft switch class 418 objects.
FIG. 4B also includes route response 430, signaling message 432, and IPDC message 434, which can be passed parameters from soft switch class 418.
FIG. 4F depicts a block diagram 401 of interprocess communication including the starting of a soft switch command and control functions by a network operations center. Diagram 401 illustrates intercommunications between network operations center (NOC) 21 I 4, soft switch 204 and configuration server (CS) 206. NOC 2114 communicates 404 with soft switch 418 to startup soft switch command and control. Soft switch command and control startup registers 405 soft switch 204 with CS 206 by communicating 411 with CS proxy 702, and accepts configuration information for soft switch 204 from CS 206.
FIG. 4G depicts a block diagram of soft switch command and control startup by a network operations center sequencing diagram 413, including message flows 415, 417, 419, 421 and 423.
FIG. 4H depicts a block diagram of soft switch command and control registration with configuration server sequencing diagram 425, including message flows 427, 429, 431 and 433.
FIG. 4I depicts a block diagram of soft switch accepting configuration information from configuration server sequencing diagram 435, including message flows 437, 439, 441, 443, 445 and 447.
(b) Call Context Class FIG. 4C illustrates a call context class 438 OOP class definition. Call context class 438 includes variables 440 and methods 442.
1 S Variables 440 can be used to store information about call context class objects 438. For example, variables 440 can include signaling message information for an incoming message, signaling message information for an outgoing message, a time stamp, and the number of stored signaling messages.
Methods 442 include various functions which can be performed by call context class 438. For example, methods 442 include a call context message which passes parameters identifying a call event and a signaling message.
Other methods 442 include a function to get an IAM message, to get a call event identifier, to get an originating network ID, to get a terminating network ID, to get a signaling message, and to get a subroute. Methods 442 also include the means to add an ACM message, an ANM message, an REL message, an RLC message, a connect message, and a route response message. Methods 442 also permit call context class 438 to set various states as, for example, that an ACM was sent, an IAM was received, an RTP connect was sent, a CONI was received, a connect was sent, an answer was sent, an REL was sent, that the system is idle, that an ANM was sent, or that an RLC was sent. Methods 442 can also get a route.

FIG. 4C also includes route response 430. call context repository 444, call event identifier 448, and network ID 452. Call context repository 444 includes methods 446. Methods 446 include a register function, a function to get call context, and to find call context. Call event identifier 448 includes the function of identifying a call event 450.
(c) Signaling Message Class FIG. 4D includes signaling message class 432 OOP class definition.
Signaling message class 432 includes variables 456 and methods 458. Variables 456 include an originating message and a type of the message.
Classes 481 inherit from classes 432, i.e. class 432 is the base class for SS7 signaling messages.
Methods 458 include various signaling message functions which can pass vanous parameters and receive various parameters. Parameters which can be sent by signaling message functions include the request/response header (Rhs), the signaling message, the network ID, the port, the route response, the IPDC
message and the soft switch information. Methods 458 also include the function to set the originating ingress port, to set the network identifier, to get a message type, and to get a network identifier.
FIG. 4D also includes network ID 452 and route response 430. Network ID 452 can communicate with signal message class objects 432. Route response 430 can receive parameters passed by signaling message class objects 432.
FIG. 4D also includes ACK message 460, IAM message 464, ACM message 468, ANM message 472, REL message 476, and RLC message 480, collectively referred to as SS7 signaling message class definitions 481. Each message of message class definition 481 includes various functions. For example ACK
message 460 includes methods 462, i.e., the ACK message function. IAM
message 464 includes methods 466. Methods 466 include several functions, such as, for example the IAM message function, the get dialed digits function, the get NOA function and the get ANi function. ACM message 468 includes method 470, which includes function ACM message. ANM message 472 includes methods 474, which includes the ANM message function. REL message 476 includes methods 478, which includes the REL message functions. RLC message 486 includes methods 482, which includes the RLC message functions.
(d) SS7 Gateway Class FIG. SB includes SS7 gateway OOP class definition 532 and SS7 gateway proxy class definition 424. SS7 gateway class 532 includes variables 534, including runtime parameters, STP information, point code, and alias point code for an SS7 gateway.
FIG. SC depicts a block diagram 536 of interprocess communication including soft switch interaction with SS7 gateways. Diagram 536 illustrates intercommunications between SS7 gateways (SS7 GW) 208 and soft switch 204.
SS7 GW 208 communicates 538, 540 with soft switch 418: Soft switch 418 communicates 538 with SS7 GW proxy 424 accepting signaling messages from SS7 gateways 208. Soft switch 418 communicates 540 with SS7 GW proxy 424 sending signaling messages to SS7 gateway 208. In sending signaling messages, soft switch 204 uses 542 command and control registration of the soft switch with SS7 gateway 208.
FIG. SD depicts a block diagram 542 of interprocess communication including an access server signaling a soft switch to register with SS7 gateways.
Diagram 542 illustrates intercommunications between access server 232x, soft switch 204 and SS7 gateway 208. Access server 232a communicates 544 with soft switch 418. Soft switch accepts IPDC messages from access servers from interaction with the servers. This communication extends 544 the soft switch command and control which registers soft switch 204 with SS7 gateways 232a.
This registration uses 546 interaction between the soft switch and SS7 gateway 424. SS7 gateway 424 communicates 548 with the soft switch 418.
FIG. SE depicts a block diagram of a soft switch registering with SS7 gateways sequencing diagram 550, including message flows 552-564.

- I OS-(e) IPDC Message Class FIG. 4E illustrates IPDC message OOP class definition 434. IPDC
message 434 includes variables 484 and methods 486. Variables 484 include an IPDC identifier for an IPDC message. Methods 486 include IPDC message functions, which pass such parameters as the route node container, RHS, IPDC
message, an IN port, an OUT port, and a bay module line channel (BMLC).
Methods 486 include the get message type function, the get call event identifier function (i.e. passing the call event identifier variable), and the get IPDC
identifier function (i.e., passing the IPDC identifier variable).
(fJ Call Event Identifier Class FIG. 4E includes call event identifier 448 in communication with IPDC
message class 434, and route node container class 488 also in communication with IPDC message class 434 for passing parameters.
FIG. 4E also includes exemplary IPDC messages 495, which inherit from IPDC base class 434. IPDC messages 495 include ACR message 490, ACSI
message 492, CONI connect message 494, connect message 496, RCR message 498, RTP connect message 454. and TDM cross connect message 497. IPDC
messages can include various methods. For example, ACR message 490 can include ACR message function 493. Similarly connect message 496, RCR
message 498, and RTP connect message 454, can include connect message function 491, RCR message function 489, RTP connect function methods, respectively.
(g) Configuration Proxy Class FIG. 7A illustrates configuration server proxy OOP class definition 702.
Configuration server proxy 702 includes methods 704. Methods 704 include mulfiple functions. For example, methods 704 include the register function, the get configuration data function, the update function. the update all function, and the get data function.
FIG. 7B depicts a block diagram 706 of interprocess communication including soft switch interaction with configuration server (CS) 206. Diagram 706 illustrates intercommunications between CS 206 and soft switch 204. CS
206 communicates 708, 710 with soft switch 418. Soft switch 418 communicates 708 with CS proxy 702 to register soft switch 204 with CS. Soft switch 418 communicates 710 with CS proxy 702 to permit soft switch 204 to accept configuration information from CS 206.
(h) Route Server Class FIG. 8B depicts route server class diagram 802. Class diagram 802 includes route server OOP class definition 804. Route server class 804 includes variables 806 and methods 808.
Variables 806 include, for a respective route server 212, an identifier (ID), a ten digit table, a six digit table, a three digit table, a treatment table;
a potential term table, an local serving area (LSA) table, a circuit group (CG) table, an destination AD table, a runtime parameters and an alarm server.
Methods 808 include several functions. For example methods 808 include a start function, a receive message function, a receive request function, an update function, a process function and a digit analysis function.
FIG. 8B includes route server proxy class 426.
FIG. 8B also includes route request class 430, from route objects superclass 803, which is passed parameters from route server class 804.
FIG. 8B also includes route server message class 810, also from route objects superclass 803, similarly receiving parameters from route server class 804.
FIG. 8B also includes configuration server proxy class 428, which is in communication with route server class 804.
FIG. 8B also includes RTP pool class 812, chain pool class 814 and modem pool class 818, all of which are from superclass pools 805, and are in communication with route server class 804. Circuit pool class 816, which is also from a superclass 805, is also in communication with route server class 804:
(i) Route Objects Class FIG. 8C illustrates superclass route objects 803 in greater detail. FIG. 8C
includes route response OOP class definition 430. Route response class 430 includes variables 820 and methods 822.
Variables 820 include the type of a route response and a version~of the route response. Methods 822 include several functions. For example, methods 822 include the route response function, the get type of route response function, the get call evem identifier function. the get originating out BMLC function, the get originating IP function, the get terminating out BMLC function, the get terminating IP function, and the get terminating network ID function.
FIG. 8C includes route calculator class 824, including methods 826, which include a calculate function.
I S FIG. 8C includes route server message class 8 I 0, including methods 828.
Methods 828 include several functions, including the route server message function, and the get BMLCs function.
FIG. 8C includes call event identifier class 448. Network call event identifier 448 is in communication with route response class 430.
FIG. 8C also depicts route request class 832 in communication with call event identifier class 448. Route request class 832 includes variables 834 and methods 836.
Variables 834 include the nature of address, the dialed digits, the ANI, version, and the jurisdiction information parameters, of route request class 832.
Methods 836 include multiple functions. Methods 836 include the route request function, the get dialed digits function, the get nature ofaddress function, and the get network ID function. Network ID class 452 is in communication with route request class 832. Potential term container class 844 is in communication with route response class 430.

Route class 840 is in communication with route response class 430.
Route class 840 includes methods 842. Methods 842 include several functions.
For example methods 842 can include a route function, a get next function, a begin function, an end function, a get current function, an add route node function, and an end function. Route node class 846 is in communication with route class 840.
Route node 846 includes variables 848 and methods 850. Variables 848 include a BMLC, an IP, a location, and a bay name for a particular route node.
Methods 850 include several functions. For example methods 850 can include a get OPC function, a get DPC function, a get terminating CIC (TCIC) function a get IP function, a reserve function, a route node function, a get type function, a match function, a get pool function and a get BMLC function.
Call event identifier class 448 is in communication with route node class 846. Route node class 846 has additional route node subclasses 851. Route node subclasses 85I include MLC route node class 852, modem route node class 856, RTP route node class 858 and treatment route node class 862. MLC route node class 852 includes methods 854. Methods 854 includes several functions. For example methods 854 can include a match function, an are you available function, a get BMLC function and an unreserve function.
RTP route node class 858 includes methods 860. Methods 860 include several functions, e.g., a get address port pair function. Treatment route node class 862 includes variables 864, e.g., an announcement to play variable. RTP
route node class 858 has two subclasses. i.e. IP address class 866 and IP port class 868.
Finally, FIG. 8C includes route node container class 488. Route node container class 488 includes methods 853. Methods 853 can include several functions, e.g., a begin function, a get current function, and a next function.
FIG. 8F depicts a block diagram 894 of interprocess communication including soft switch interaction with route server (RS) 2I2. Diagram 894 illustrates intercommunications between RS 212 and soft switch 204. RS 804 accepts 896 route requests from soft switch 418 and sends 898 route responses from RS 804 to soft switch 418. Soft switch manages ports by using RS 804 to process 899 unallocate messages from soft switch 418.
(j) Pool Class FIG. 8D depicts superclass pool class 870. Pool class 870 includes methods 872, including a get route node function and a find route node function.
Pool class 870 has a plurality of subpool classes 871.
Subpool classes 871 include modem pool class 818, real-time transport protocol (RTP) pool class 812, and chain pool class 814. RTP pool class 812 includes methods 876. .
Methods 876 include several functions, including a get originating route node function, a get terminating out route node function and a get route node function. Chain pool class 814 includes methods 878, including a get function, a get route node function, a get chain pair function and a get route node function.
In communication with modem pool class 818 is modem route node class 856, which is a subclass from route objects 803. In communication with chain pool class 814 is chain pair class 874. Chain pair class 874 includes methods 880, including a match MLC route node function, a match function and an are you available function. Chain pair class 874 is in communication with MLC route node class 852, i.e., a subclass of route objects class 803.
(k) Circuit Pool Class FIG. 8E illustrates circuit pool class 816 having methods 886. including a get circuit function. In communication with circuit pool class 816 is a circuit class 882 having methods 888, including a get route node function. In communication with circuit class 882 is circuit group class 884 having variables 890 and methods 892. Variables 890 include a trunk group reference and a type for circuit groups of circuit group class 884. Methods 892 include an any available function. Method ID class 452 is in communication with circuit class 882. FIG. 8E also includes module line channel (MLC) route node class 852 from the route objects superclass.
2. Gateway Site FIG. I OA depicts a more detailed drawing 1000 of gateway site 108.
FIG. l0A includes gateway site I08 comprising TG 232, NAS 228, AG 238, DACS 242 and announcement server ANS 246. TG 232, NAS 228 and AG 238 collectively are referred to as access server 254. DACs 242 could also be considered an access server 254 if it can be controlled by soft switch 204.
TG 232, NAS 228 and AG 238 are connected via an IP interface I O connection to data network 1 I2. TG 232, NAS 228, AG 238 are connected via separate interface to network management component 118. Specifically, TG 232 is connected to network management component 118 via interface 1002. NAS
228 is connected to network management component 118 via interface 1004.
Also, AG 238 is connected to network management component 118 via interface 15 1006.
In addition, FIG. l0A includes ANS 246, which as pictured is connected directly via the IP connection to data network 1 I 2. Alternatively, the ANS
can functionally exist in other areas of the telecommunications network. For example, ANS 246 can functionality exist in TG 232. as depicted by ANS 1008, 20 TG 232 having ANS functionality 1008. Similarly, ANS functionality (shown as ANS 1010) can be provided by AG 238.
FIG. l0A includes customer facility 128, providing access for calling party 122 to AG 238 via a direct access line or dedicated access line (e.g., a PRI
or T1). In a preferred embodiment, signaling for calling party 122 is carried 25 inband between customer facility I28 and AG 238 via a signaling channel, e.g., an integrated services digital network (ISDN) data channel (D-channel).
Calling party 102, on the other hand, is connected via carrier facility I26 to DACS
242, in order to provide connectivity to TG 232 and NAS 228. In a preferred embodiment, signaling for calling party 102 is carried out-of band over signaling 30 network 114, as shown in FIG. 10A.

FIG. lOB depicts a block diagram 1012 of interprocess communication including soft switch interaction with access servers such as trunking gateway 232a. Diagram 1012 illustrates intercommunications between access server 232a and soft switch 204. Soft switch 418 accepts I O I 4 IPDC messages from access server 232x. Soft switch 418 sends 1016 IPDC messages to access server 232a.
a. Trunking Gateway (TG) A TG is a gateway enabling termination of PSTN co-carrier trunks and feature group-D (FG-D) circuits. FIG. 11 A illustrates an exemplary TG 232.
Gateway common media processing is illustrated in FIGS. 11 B and 11 C below.
Gateway common media processing on the ingress side will be described with reference to FIG. 11 B. Gateway common media processing on the egress side will be described with reference to FIG. 11 C.
Specifically, FIG. I 1 A depicts a trunking gateway high level functional architecture I I 00 for TG 232. FIG. 11 A includes calling party I O2, connected via carrier facility I26 to DS3 trunks, which in turn provide connection to TG
232.
Signaling for a call from calling party 102 is carried via out-of band signaling network I 14, through SS7 gateway 208, to soft switch 204. This is shown with signaling 1118.
TG 232 is controlled by soft switch 204, via the IPDC protocol 1 I 1 G
through data network 112. TG 232 includes PSTN interface card 1102 connecting TG 232 to the incoming DS3 trunks from the PSTN. PSTN interface card 1102 is connected to ~ time division multiplexed (TDM) bus I 104.
TDM bus I 104 takes the incoming DS3 trunks and separates the trunks, using time division multiplexing, into separate DS 1 signals 1106. DS 1 I 106 can be encoded/decoded via, for example, DSP-based encoder/decoder 1108.
Encoder/decoder 1108 typically performs a voice compression, such as 6.723.1, 6.729, or simply breaks out 6.711 64 kbps DSO channels. Encoder/decoder 1108 is connected to packet bus 1110, for packetizing the incoming digital signals. Packet bus 1110, in turn, is connected to IP Interface cards 1112-1114.
IP Interface cards 1112-1114 provide connectivity to data network 112 for transmission of VOIP packets to distant gateways and control messages to soft switch 204.
TG 232 also includes network management IP interface 1002 for receiving and sending network management alarms and events via the simple network management protocol (SNMP) to network management component 118.
Trunks can handle switched voice traffic and data traffic. For example, trunks can include digital signals DS1-DS4 transmitted over T1-T4 carriers.
Table 17 provides typical carriers, along with their respective digital signals, number of channels, and bandwidth capacities.
Table 17 Number of Designation of Bandrvidtlt Digital signalchannels in carrier Megabits per second (Mbps) DSO 1 None 0.064 DS 1 24 T 1 1.544 DS2 96 TZ 6.3 i 2 DS3 672 T3 44.73 6 DS4 4032 T4 274.176 Alternatively, trunks can include optical carriers (OCs), such as OC-1, OC-3, etc. Table 18 provides typical optical carriers, along with their respective synchronous transport signals (STSs), ITU designations, and bandwidth capacities.
Tab le 18 Electrical International Optical carriersignal, or Telecommuni- Bandwidth in (OC) signal synchronous cations UnionMegabits per transport signal(ITU) second (Mbps) (STS) terminology OC-1 STS-1 5 i .84 STS-3 STM-1 155.52 -,-,-,-- --Tab le 18 Electrical International Optical carriersignal, or Telecommuni- Bandwidth in (OC) signal sYncl:ronous cations UnionMegabits per transport (ITU) second (Mbps) signal terminology (STS) OC-9 STS-9 STM-3 466.56 OC-12 STS-12 STM-4 622.08 OC-18 STS-18 STM-6 933.12 OC-24 STS-24 STM-8 1244.16 OC-36 STS-36 STM-12 1866.24 OC-48 STS-48 STM-16 2488.32 With reference to FIGs. 2A and 11 A, TGs 232 and 234 can receive call control messages from and send messages to soft switch 204, via the IPDC
protocol. Soft switch site 104 implements a signaling stack, e.g., an SS7 signaling network stack, for communications with legacy PSTN devices. On the ingress side of the telecommunications network, ingress trunking gateway 232 seizes a circuit as a call is initiated (i.e. assuming calling party 102 is placing a call to called party 120).
As the circuit is seized at call initiation, SS7 signaling network 114 begins the process of setting up a call, by sending messages via SS7 GW 208 to soft switch 204. As the call progresses, ingress TG 232 can receive commands from soft switch 204 to complete the call through ingress TG 232 and out through the virtual voice network via the IP interface 11 I4 to a destination gateway.
On the egress side of the network, this process is reversed to complete the call through the interconnected network to egress trunking gateway 234 and ultimately to called party 120.
FIG. l 1B depicts gateway common media processing components on the ingress side 1140. FIG. 11 B begins with incoming media stream 1 I 42. From incoming media stream 1142, tone detection 1144 can occur and then data detection 1146 can occur or tone detection 1144 can be bypassed (see path 1148), as disabled/enabled by soft switch 204 via IPDC. From data detection 1146, silence detection/ suppression 1150 can be performed. Next, a coder I I 52 can be processed and then the packet stream can be transferred, as shown in 1154.
FIG. 1 I B is now described with respect to ingress trunking gateway 232.
Incoming media stream 1142 must be processed as it passes through ingress gateway 232 to complete the call via the IP core data network 112.
The first process that takes place is data detection process 1146. Data detection process I 146 attempts to detect the media type of the call traffic.
The media type of the call traffic can include voice, data and modem. The media type information can be passed via IPDC protocol to soft switch 204 for process determination.
In one embodiment, no additional processing is required. In another embodiment, a compression/decompression software component (CODEC) that is used in performing media processing, can be selected based on data detection process 1 I46. Specifically, if the data is determined to be modem traffic and if a suitable CODEC exists for the data rate, soft switch 204 can choose to incorporate this CODEC on the stream. Alternatively, if the call is a voice call, soft switch 204 can select the CODEC optimized for voice processing and current network conditions. In an embodiment of the invention, data calls can always be processed with the default bit rate CODEC.
In silence detection and suppression process I I S0, silence in a voice call can be detected and suppressed, yielding potential decreases in the volume of transmission of packets carrying no digitized voice, due to silence.
In encoding process 1152, once a CODEC has been chosen by soft switch 2~ 204 or the decision is made to use the default CODEC, the media stream passes through a digital signal processor (DSP) I 108 to apply an appropriate compression algorithm. This compression processing algorithm can take the media stream as a traditional stream from the traditional voice world and transform it into a stream suitable for digital packetization. Once these packets have been formed, ingress TG 232 can process the packets into IP packets and prepare the packets for transport through the IP backbone 112 to egress TG 234.

On the egress side of the network, packetized media is converted back to a digital stream. Specifically, egress TG 234 can take the packets from data network 112 and decompress them and decode them with the same DSP process and algorithm used on the ingress side of the network.
FIG. I 1 C depicts exemplary gateway common media processing components on the egress side 1120. FIG. 1 I C begins with egress TG 234 receiving packets 1122. Next, packets are buffered to compensate for fitter 1124, and comfort noise I 126 can be inserted into the call. Comfort background noise process 1126 can provide reassurance to the party on the other end of the call that I O the call has not been interrupted, but instead that the other party is merely being silent. Next, decoding process 1128 can be performed by DSP 1108 and echo processing 1130 can detect and cancel echo. Finally, digital bit stream media, (e.g., a DSO), is transferred to a telephony interface (e.g., a DS3 port).
Additional media stream processing functions internal to TGs 232, 234 15 can include, for example, the ancillary processes of silence detection and suppression I 150, voice activation, and comfort noise insertion I 126. The media stream processing functions include. for example, the major core functionality needed for TGs 232, 234.
Other functional components needed in trunking gateways 232, 234 can 20 also be included. Other functional components can include the provisioning and maintenance of trunking gateways 232, 234.
( I ) Trunking Gateway Interfaces TGs 232, 234 provide voice network connectivity to the traditional public switched telephone network (PSTN). TGs 232, 234 can accept co-carrier and 25 feature group-D (FG-D) trunks. It would be apparent to those skilled in the art that TGs 232, 234 can accept other telecommunications trunks. TGs 232, 234 allow for termination of SS7 signaled calls to and from telecommunications network 200.
TGs 232, 234 can convert the media stream into packets for transmission 30 over data network 112. TGs 232, 234 also provide a management interface for remote management, control and configuration changes. TGs 232. 234 can interface to multiple components of telecommunications network 200. For example, TGs 232, 234 can interface with, for example, the PSTN for carrying media, soft switch 204 for communication of control messages from soft switch 204, the voice network interface of data network 112 for carrying packetized voice media, and network management component I 18 for sending SNMP alerts to the network operation center (NOC).
TGs 232, 234 interface to the PSTN via co-carrier or FG-D trunks. These trunks are groomed via DACS 242, 244, to allow multiple two-way 64 kilobits per second (KPS) circuits to pass the media stream into and out of TGs 232, 234.
The PSTN interface to TGs 232. 234 provides all low level hardware control for the individual circuits and allows the interface to look like another switch connection to the PSTN network.
TGs 232, 234 also interface with soft switch 204. Referring to FIG. 4A, the TG to soft switch interface 412 is used to pass information needed to control the multiple media streams. Soft switch 204 controls ali available circuit channels that connect through TGs 232, 234. TG to soft switch interface 4I2 uses the physical IP network interface cards (NICs) 1112-1114 to send and receive control information to and from soft switch 204 using the IPDC protocol. The IPDC protocol will be described in greater detail below.
Referring to FIG. 11 A, TGs 232. 234 interface with a voice virtual private network (VPN) that is overlaid on an IP data network 112. The TG to voice VPN
interface sends or receives voice packets on the IP side of the network from TGs 232, 234 to other network components, e.g., to another of TGs 232, 234. TG to voice VPN interface, in a preferred embodiment, can physically be a 100 Baser Ethernet interface, but can be logically divided into virtual ports that can be addressable via soft switch 204. The media stream can be connected through this interface, i.e., the TG to voice VPN interface, to a distant connection with a real-time transport protocol (RTP) connection.
TGs 232, 234 can also interface with network management component (NMC) 118 for the purposes of communicating network management SNMP

alerts. The TGs 232, 234 to SNMP interface is a management interface that can be connected to NMC 118 of the network management network through a dedicated connection on TGs 232, 234. SNMP messages that are generated at TGs 232, 234 can be passed to the network operations center (NOC) through the TG to SNMP interface. In addition, messages and commands from the NOC can be passed to TGs 232, 234 through this interface for several purposes including, for example, network management, configuration and control.
b. Access Gateway (AG) An AG is a gateway that enables customers to connect via a Direct Access I 0 Line (DAL) from their customer premise equipment (CPE), such as. for example, a private branch exchange (PBX). to the telecommunications network. The AG
terminates outgoing and incoming calls between the CPE, the telecommunications network and the PSTN.
FIG. 12 depicts an AG high level functional architecture 1200. FIG. 12 includes calling party 122, connected via customer facility 128 to DAL (e.g., either an ISDN PRI or a T1 DAL). A PRI DAL is connected from the PSTN-to-PSTN interface card 1202a. PSTN interface card 1202a includes ISDN signaling and media, meaning it includes both bearer channels (B-channels) for carrying media and data channels (D-channels) for carrying ISDN signaling information.
A T1 DAL can be connected from the PSTN to a PSTN interface card 1202b, supporting T1 in-band channel associated signaling (CAS). PSTN
interface cards 1202a, 1202b are connected to TDM bus 1204. Using TDM bus 1204, incoming T1 and PRI signals are broken into separate DS1 signals 1206.
DS 1 1206 is then encoded via DSP-based encode/decode I 208. After encoding via DSP-based encode/decode 1208, the signal is packetized via packet bus 1210, to be transmitted via IP interface cards 1212-1214, over data network 112. iP packets containing signaling information (e.g., D-channel) are routed to soft switch 204. IP packets containing media are transmitted to other media gateways, i.e. access servers such as an AG or TG

IP interface card 1214 includes both control and signaling information in its packets. This is illustrated showing IPDC protocol control information and signaling information 1218.
AG 238 delivers signaling information inband over data network 112 to soft switch 204. Accordingly, calling party 122 need not have its customer facility 128 have connectivity with SS7 signaling network 114.
AG 238 is functionally equivalent to TG 232. AG 238 differs from TG
232 only in the circuit types and scale of the terminated circuits supported.
The circuit types and scale of terminated circuits supported drives the tine side cards I 0 and signaling that AG 238 provides to a PBX or other customer facility 128. The circuit associated and in-band signaling provided by the PBX or customer facility 128 must be passed from AG 238 to soft switch 204 via the IPDC protocol. AG
238 receives call-processing information from soft switch 204.
( 1 ) Access Gateway Interfaces AGs 238, 240 interface to several components of telecommunications network 200. The interfaces of AGs 238, 240 include interfaces facing the network, i.e., data network 112, and network management component I 18, as described for TGs 232, 234 above. AGs 238, 240 also interface on the line side, through line side card interfaces. which can be needed to support in-band TI
and ISDN primary rate interface (ISDN PRI) circuits.
In-band T1 and ISDN PRI interfaces can be provisioned on an as-needed basis on AGs 238, 240, to support the equipment that can terminate the circuit on the far end. The ISDN PRI can support standard ISDN circuit associated D-channel signaling in the 23 B+ 1 D, NB+1 D and NB+2D (bearer (B-) and data (D-) channel) configurations. For the in-band signaling T1 configuration, the circuit can support wink start or loop start signaiing.
The next six paragraphs briefly introduce wink start, loop start, and ground start signaling as would be apparent to a person having ordinary skill in the relevant communications signaling art.

Wink start refers to seizing a circuit by using a short duration signal. The signal is typically of a 140 millisecond duration. The wink indicates the availability of an incoming register for receiving digital information from a calling switch. Wink starts are used in telephone systems which use address signaling.
Loop start refers to seizing a circuit using a supervisory signal. A loop start signal is typically generated by taking the phone off hook. With a loop start, a line is seized by bridging a tip and ring (i.e., the wires of the telephone line) through a resistance. A loop start trunk is the most common type of trunk found in residential installations. The ring lead is connected to -48 V and the tip lead is connected to 0 V (i.e., connected to ground). To initiate a call, a "loop"
ring can be formed through the telephone to the tip. A central office (CO) can ring a telephone by sending an AC voltage to the ringer within the telephone. When the telephone goes off hook, the DC loop is formed. The CO detects the loop and the fact that it is drawing a DC current, and stops sending the ringing voltage.
Ground starting refers to seizing a trunk, where one side of a two-wire trunk (the ring conductor of the tip and ring) is temporarily grounded to get a dial tone. Ground starts are typically used for CO to PBX connections. Ground starting is effectively a handshaking routine that is performed by the CO and PBX. The CO and PBX agree to dedicate a path so that incoming and outgoing calls cannot conflict, so that "glare" cannot occur.
The PBX can check to see if a CO ground start trunk has been dedicated.
In order to see if the trunk has been dedicated, the PBX checks to see if the tip lead is grounded. An undedicated ground start trunk has an open relay between 0 V (ground) and the tip lead connected to the PBX. If the trunk has been dedicated, the CO will close the relay and ground the tip lead.
In a ground start, the PBX can also indicate to the CO that it requires a trunk. The PBX has a PBX CO caller circuit. The PBX CO caller circuit can call a CO ground start trunk. The PBX CO caller circuit briefly grounds the ring lead causing DC current to flow. The CO detects the current flow and interprets it as a request for service from the PBX.

"Glare" occurs when both ends of a telephone line or trunk are seized at the same time for different purposes or by different users. Glare resolution refers to the ability of a system to ensure that if a trunk is seized by both ends simultaneously, then one caller is given priority, and the other is switched to another trunk.
AGs 238 and 240 interface to the PSTN via T1 CAS signaling and ISDN
PRI trunks. ISDN PRI trunks are groomed via the DACS 242 and 244 to allow multiple two-way 64 kps circuits to pass signaling information circuits to pass signaling information and the media stream into and out of AGs 238 and 240.
The AG to PSTN interface provides all low level hardware control for the individual circuits. The AG to PSTN interfaces, specifically, PSTN interface cards 1202a and 1202, also allow the interface to look like a switch connection to the PSTN network.
AG to soft switch interface 414 can be used to pass information needed to control multiple media streams. Soft switch 204 can control all available circuit channels that connect through AGs 238, 240. AG to soft switch interface 414 can use the physical voice network interface card to send and receive control information to and from soft switch 204 using the IPDC protocol.
AGs 238, 240 can have a separate physical interface to network management component (NMC) I18. AG 238 has network management IP
interface 1006, which sends network management alarms and events in the SNMP protocol format to NMC 118. The AG to NMC interface can be used for delivery of SNMP messages and additional functions. Examples of additional functions that can be defined include, for example, functions for provisioning, updating, and passing special alarms and performance parameters to AGs 238, 240 from the network operation center (NOC) of NMC 118.
c. Network Access Server (NAS) NASs 228, 230 accept control information from soft switch 204 and process the media stream accordingly. Modem traffic is routed to the internal processes within NASs 228, 230 to terminate the call and route the data traffic out to data network 112. The reader is directed to U.S. Patent Application entitled "System and Method for Bypassing Data from Egress Facilities", filed concurrently herewith, Attorney Docket No. 1757.0060000, which is incorporated herein by reference in its entirety, describing with greater details the interaction between NASs 228, 230 and control server soft switch 204.
FIG. 13 depicts a NAS high-level architecture 1300. FIG. 13 includes calling party 102 calling into carrier facility 126. Its signaling information is routed via out-of band signaling network 114 to SS7 GW 208. The signaling information 1318 is sent to soft switch 204.
NAS 228 receives trunk interfaces from the PSTN at PSTN interface card 1302. PSTN interface card 1302 is connected to TDM bus 1304.
TDM bus 1304, in turn, can break out separate DS 1 signals 1306. These DSI signals 1306 can be terminated to modems 1308. Modem 1308 can convert the incoming data stream from a first format to a second format over packet bus 1310 to IP interface card 1312 or 1314. It is important to note that IP
interfaces 1312 and 1314 are the same.
Interface card 1312 carries media (e.g., data, voice traffic, etc.) over data network 112. The media can be sent over multiple routers in data network 112 to the media's final destination. IP interface card 1314 transmits packets of information through data network 112 to soft switch 204, including control information 1316 in the IPDC protocol format. Interface cards I 312 and 1314 can also perform additional functions NAS 228 includes network management interface card (NMIC) 1004, for providing network management alarms and events in an SNMP protocol format to network management component 118.
( I ) Network Access Server Interfaces Telecommunications network 200 supports interaction with NASs via communication of control information from soft switch 204. The interfaces between NASs 228, 230 and the other network components of telecommunications network 200, can be identical to those found on TGs 232, 234, with the exception of the FG-D interface.
NASs 228, 230 can interface to the PSTN via co-carrier trunks. The co-carrier trunks can be groomed via the DACS 242, 244, to allow multiple two-way 64 kps circuits to pass the media stream into and out of NASs 228, 230. The NASs to PSTN interface provides all low level hardware control for the individual circuits. The NASs to PSTN interface looks like another switch connection to the PSTN network.
NASs 228, 230 interface with soft switch 204 in order to pass information required to control the multiple media streams. Soft switch 204, via the NASs to soft switch interface, can control all available circuit channels that connect through NASs 228, 230. The interface between NASs 228, 230 and soft switch 204 uses the physical voice network interface card (NIC) to send and receive control information to and from soft switch 204 and NASs 228, 230 via the IPDC
protocol.
NASs 228, 230 can interface with the backbone network of data network 112. The NASs to backbone interface of data network 112 can allow the media stream to access the data network 112 and to terminate to any termination with an IP address including public Internet and world wide web sites, and other Internet service providers (ISP). This modem traffic media stream can be separate from any voice data media stream that is carried over the backbone.
Modem traffic can enter NASs 228, 230 in the form of serial line interface protocol (SLIP) or a point to point protocol (PPP) protocol and can be terrrtinated to modems and can then be converted into another protocol, such as, for example, an IPX, an Apple Talk, a DECNET protocol, an RTP protocol, an Internet protocol (IP) protocol, a transmission control protocol/ user datagram protocol (UDP), or any other appropriate protocol for routing to, for example, another private network destination.
NASs 228, 230 can use a separate physical interface for communication of SNMP alerts and messages to NMC 118. The NAS to NMC interface can be used for additional functions. Examples of additional functions that can be defined include, for example, provisioning, updating, and passing special alarms, and performance parameters to NASs 228, 230 from the network operations center (NOC).
d. Digital Cross-Connect System (DACS) . FIG. 14 illustrates exemplary DACS 242 in detail. DACS 242 is a time division multiplexer providing switching capability for incoming trunks.
Referring to FIG. 14, voice and data traffic comes into DACS 242 from carrier facility 126 on incoming trunks. DACS 242 receives a signal from soft switch 204 (over data network I 12) indicating how DACS 242 is to switch the traffic. Depending on the signal provided by soft switch 204, DACS 242 can switch the incoming traffic onto either circuits directed to TG 232. or circuits directed to NAS 228.
More generally, a DACS 242 is a digital switching machine, employed to manage or "groom" traffic at a variety of different traffic speeds. Grooming functions of DACS 242 include the consolidation of traffic from partly filled incoming lines with a common destination and segregation of incoming traffic of differing types and destinations. A traditional DACS 242 can have one of several available architectures. Example architectures, which accommodate different data rates and total port counts, include narrowband (or I/0), wideband (or 3/1), and broadband (or 3/3).
As backbone traffic has grown, with increased data traffic, there is an emerging need for even higher capacity DACS 242, having interface speeds of OC-48 and beyond, as well as cell and packet-switching capabilities to accommodate the increasing data traffic.
As data traffic continues to grow, increasing the demands of telecommunications networks, and as through-put speeds increase, DACS (e.g., DACS 242) are migrating to include higher-speed switching matrices capable of terabit throughput. DACS 242 can also include high-speed optical interfaces.
Telecommunications network 200 can also make use of virtual DACS
(VDACS). VDACS are conceptually the use of a computer software controlled circuit switch. For example, a DACS can be built which is capable of intercommunicating with a soft switch via, a protocol such as, for example, Internet protocol device control (IPDC), to perform the functionality of a DACS.
In one embodiment of the invention, a NAS is used to terminate co-carrier, or local trunks, and a TG is used to terminate long distance trunks.
In such a system, if a voice call were to come in over a NAS, then the voice call could be transmitted to the TG for termination. One approach that can be used to terminate this voice call includes occupying an outgoing channel to transmit the call out of the NAS and into the TG. Another approach uses a commendable DACS, a VDACS. The VDACS can cross-connect on command, so as to act as a commendable circuit switch. In practice, the soft switch can send a command down to the VDACS via IPDC, for example. A VDACS can be built by using a traditional DACS with the addition of application program logic supporting control and communication with a soft switch.
e. Announcement Server (ANS) Referring back to FIGS. 2A and 10A, ANSs 246, 248 store pre-recorded announcements on disk in an encoded format. ANSs 246, 248 provide telecommunications network 200 with the ability to play pre-recorded messages and announcements, at the termination of a call. For example, ANSs 246, 248 can play a message stating that "ali circuits are busy."
In one embodiment, the functionality of ANSs 246, 248 can be included in TG 232 and/or AG 238. The features of this embodiment are dependent on the amount of resources in TG 232 and AG 238. This internal announcement server capability is shown in FIG. i OA, including, for example, ANS 1008 in TG 232 and ANS 1010 in AG 238. It would be apparent to those skilled in the art that ANS functionality can be placed in other systems, such as, for example, soft switch 204 and NAS 1004.
In another embodiment, ANSs 246, 248 are applications running on one or more separate servers. as shown in FIG. 15. FIG. 15 depicts an announcement server (ANS) component interface design 1500. FIG. 15 includes ANS 246, which is in communication with TG 232, AG 238 and soft switch 204 over data network 1 I2. ANS 246 can be controlled by soft switch 204 via the IPDC
protocol. ANS 246 can send network management alerts and events to network management component (NMC) 118. Data distributor 222 can send announcement files to ANS 246.
A benefit of providing separate ANSs 246, 248 is that a more robust database of announcements can be stored and made available for use by the soft switch than is supported in conventional networks. Another benefit of a separate ANS 246, 248 is that less storage is required in TGs and AGs since the announcement functionality is supported by the server of ANSs 246, 248 server.
ANSs 246. 248 can be controlled by one or more soft switches to play the voice messages, via the IPDC protocol.
After determining that an announcement should be played, Soft switch 204 chooses an ANS 246 or 248 that is closest to the point of origination for the call, if available. The ANS and gateway site establish a real-time transport protocol (RTP) session for the transmission of the voice announcement. Then ANS 246 or 248 streams the file over RTP to the terminating gateway. When the message is complete, ANSs 246, 248 can replay the message or disconnect the call.
ANSs 246, 248 can store the message files in each of the media coder/decoders (CODECs) that the network supports. ANSs 246, 248 can send announcements stored in the format of the 6.711, 6.726, and 6.728, and other standard CODECs. The soft switch can direct ANS 246, 248 to play announcements using other CODECS if the network enters a state of congestion.
Soft switch 204 can also direct ANS 246, 248 to play announcements using other CODECs if the gateway or end client is an IP client that only supports a given CODEC. In another embodiment, the CODEC of an announcement can be rriodified while the announcement is playing.
ANS 246 will now be described with greater detail with reference to FIG. I5. ANS 246 has several interfaces. ANS interfaces include the provisioning, control, alarming, and voice path interfaces. ANS 246 also has several data paths. The path from ANS 246 to TG 232 or to AG 238, have a common voice path interface (i.e., which is the same for TG 232 and AG 238).
The voice path interface can use RTP and RTCP.
In a preferred embodiment, ANS 246 to soft switch 204 interface provides for a data path using the Internet protocol device control (IPDC) protocol to control announcement server 246.
The ANS 246 to SNMP agent in network management component 118 data path is used to send alarm and event information from ANS 246 to SNMP
agent via SNMP protocol.
Data distributor 222 to announcement server 246 data path carries announcement files between announcement server 246 and data distributor 222.
The provisioning interface downloads, via a file transfer protocol (FTP}, encoded voice announcement files to announcement server 246.
1 S Announcement server 246 uses a separate physical interface for all SNMP
messages and additional functions that can be defined. Examples of additional functions that can be defined include provisioning, updating, and passing of special alarms and performance parameters to announcement servers 246 from NOC 2114.
In another embodiment, announcement server 246 is located in soft switch site 104. It would be apparent to those skilled in the art that announcement server 246 could be placed in other parts of telecommunications network 200.
3. Data Network In an example embodiment, data network 112 can be a packet-switched network. A packet-switched network such as, for example, an ATM network, unlike a circuit switch network, does not require dedicated circuits between originating and terminating locations within the packet switch network. The packet-switched network instead breaks a message into pieces known as packets of information. Such packets are then encapsulated with a header which designates a destination address to which the packet must be routed. The packet-switched network then takes the packets and routes them to the destination designated by the destination address contained in the header of the packet.
FIG. 16A depicts a block diagram of an exemplary soft switch/gateway network architecture 1600. FIG. 16A illustrates a more detailed version of an exemplary data network 112. In an exemplary embodiment, data network I 12 is a packet-switched network, such as, for example, an asynchronous transfer mode (ATM) network. FIG. 16 includes western soft switch site I 04 and gateway sites 108, 110 connected to one another via data network I 12. Data is routed from western soft switch 104 to gateway sites 108, 110 through data network 112, via a plurality of routers located in western soft switch site I04 and gateway sites 108, 110.
Western soft switch site 104 of FIG. 16A includes soft switches 204x, 204b, 204c, SS7 GWs 208, 210, CSs 206a, 206b, RSs 212a, 212b and RNECPs 224a, 224b, alI interconnected by redundant connections to ethernet switches 1 S (ESs) 332, 334. ESs 332. 334 are used to interconnect the host computers attached to them, to create an ethernet-switched local area network (LAN). ESs 332, 334 are redundantly connected to routers 320, 322. The host computers in the local area network included in western soft switch site 104 can communicate with host computers in other local area networks, e.g., at gateway sites 108, 110, via routers 320, 322.
Gateway site 108 of FIG. 16A includes TGs 232a. 232b, AGs 238a, 238b and NASs 228a, 228b, 228c, interconnected via redundant connections to ESs 1602, 1604. ESs 1602, 1604 interconnect the multiple network devices to create a LAN. Information can be intercommunicated to and from host computers on other LANs via routers 1606, I 608 at gateway site 108. Routers 1606, 1608 are connected by redundant connections to ESs 1602, 1604.
Gateway site 110 of FIG. I 6A includes TGs 234a, 234b, AGs 240x, 240b, and NASs 230a, 230b, 230c, connected via redundant connections to ESs 1610, 1612 to form a local area network. Ethernet switches (ESs) 1610,1612 can in turn intercommunicate information between the LAN in gateway site 110 and LANs at other sites, e.g., at western soft switch site I 04 and gateway site 108 via routers 1614, 1616. Routers 1614, 1616 are connected to ESs 1610, 1612 via redundant connections.
Routers 320, 322 of western soft switch site 104, routers 1606, 1608 of gateway site 108, and routers 1614, I 616 of gateway site 110 can be connected via NICs, such as, for example, asynchronous transfer mode (ATM) interface cards in routers 320, 322,1606,1608, 1614, I 616 and physical media such as, for example, optical fiber link connections, and/or copper wire connections.
Routers 320, 322, 1606, 1608, 1614, 1616 transfer information between one another and intercommunicate according to routing protocols.
a. Routers Data network 112 can include a plurality of network routers. Network routers are used to route information between multiple networks. Routers act as an interface between two or more networks. Routers can find the best path between any two networks, even if there are several different networks between the two networks.
Network routers can include tables describing various network domains.
A domain can be thought of as a local area network (LAN) or wide area network (WAN). Information can be transferred between a plurality of LANs and/or WANs via network devices known as routers. Routers look at a packet and determine from the destination address in the header of the packet the destination domain of the packet. If the router is not directly connected to the destination domain, then the router can route the packet to the router's default router, i.e. a router higher in a hierarchy of routers. Since each router has a default router to which it is attached, a packet can be transmitted through a series of routers to the destination domain and to the destination host bearing the packet's final destination address.

b. Local Area Networks (LANs) and Wide Area Networks (WANs) A local area network (LAN) can be thought of as a plurality of host computers interconnected via network interface cards (NICs) in the host computers. The NICs are connected via, for example, copper wires so as to permit communication between the host computers. Examples of LANs include an ethernet bus network, an ethernet switch network, a token ring network, a fiber digital data interconnect (FDDI) network, and an ATM network.
A wide area network ( WAN) is a network connecting host computers over a wide area. In order for host computers on a particular LAN to communicate with a host computer on another LAN or on a WAN, network interfaces interconnecting the LANs and WANs must exist. An example of a network interface is a router discussed above.
A network designed to interconnect multiple LANs and/or WANs is known as an Internet. An Internet can transfer data between any of a plurality of networks including both LANs and WANs. Communication occurs between host computers on one LAN and host computers on another LAN via, for example, an Internet protocol (IP) protocol. The IP protocol requires each host computer of a network to have a unique IP address enabling packets to be transferred over the Internet to other host computers on other LANs and/or WANs that are connected to the Internet. An Internet can comprise a router interconnecting two or more networks.
The "Internet" (with a capital "I") is a global Internet interconnecting networks alI over the world. The Internet includes a global network of computers which intercommunicate via the Internet protocol (IP) family of protocols.
An "intranet" is an Internet which is a private network that uses Internet software and Internet standards, such as the Internet protocol (IP). An intranet can be reserved for use by parties who have been given the authority necessary to use that network.

c. Network Protocols Data network 112 includes a plurality of wires, and routes making up its physical hardware infrastructure. Network protocols provide the software infrastructure of data network 112.
Early network protocols and architectures were designed to work with specific proprietary types of equipment. Early examples included IBM systems network architecture (SNA) and Digital Equipment Corporation's DECnet.
Telecommunications vendors have moved away from proprietary network protocols and technologies to mufti-vendor protocols. However, it can be difficult for all necessary vendors to agree on how to add new features and services to a mufti-vendor protocol. This can be true because vendor-specific protocols can in some cases offer a greater level of sophistication. For example, initial versions of asynchronous transfer mode (ATM) completed by the ATM
Forum did not have built-in quality of service (QoS) capabilities. Recent releases of the specification added those features, including parameters for cell-transfer delay and cell-loss ratio. However, interoperability among equipment of different vendors and device performance still need improvement.
The IETF is working on defining certain Internet protocols (IP) "classes of service". IP classes of service could provide a rough equivalent to ATMs QoS.
IP classes of service is included as part of the IETF's integrated services architecture (ISA). ISA's proposed elements include the resource reservation protocol (RS VP), a defined packet scheduler, a call admission control module, an admission control manager, and a set of policies for implementing these features (many of the same concepts already outlined in ATM QoS).
( 1 ) Transmission Control Protocol/Internet Protocol (TCP/IP) The Internet protocol (IP) has become the primary networking protocol used today. This success is largely a part of the Internet, which is based on the transmission control protocol/internet protocol (TCP/IP) family of protocols.

TCP/IP is the most common method of connecting PCs, workstations, and servers. TCP/IP is included as part of many software products, including desktop operating systems (e.g., Microsoft's Windows 95 or Windows NT) and LAN
operating systems. To date, however, TCP/IP has lacked some of the desired features needed for mission-critical applications.
The most pervasive LAN protocol to date, has been IPX/SPX from Novell's NetWare network operating system (NOS). However, IPX/SPX is losing ground to TCP/IP. Novell has announced that it will incorporate native IP
support into NetWare, ending NetWare's need to encapsulate IPX packets when carrying them over TCP/IP connections. Both UNIX and Windows NT servers can use TCP/IP. Banyan's VINES, IBM's OS/2 and other LAN server operating systems can also use TCP/IP.
(2) Internet Protocol (IP)v4 and IPv6 IPv6 (previously called next-generation IP or IPng) is a backward-compatible extension of the current version of the Internet protocol, IPv4.
IPv6 is designed to solve problems brought on by the success of the Internet (such as running out of address space and router tables). IPv6 also adds needed features, including circuiting security, auto-configuration, and real-time services similar to QoS. Increased Internet usage and the allocation of many of the available IP
addresses has created an urgent need for increased addressing capacity. IPv4 uses a 32-byte number to form an address, which can offer about 4 billion distinct network addresses. In comparison, IPv6 uses 128-bytes per address, which provides for a much larger number of available addresses.
(3) Resource Reservation Protocol (RSVP) Originally developed to enhance IPv4 with QoS features, RSVP lets network managers allocate bandwidth based on the bandwidth requirements of an application. Basically, RSVP is an emerging communications protocol that signals a router to reserve bandwidth for real-time transmission of data, video, and audio traffic.
Resource reservation protocols that operate on a per-connection basis can be used in a network to elevate the priority of a given user temporarily. RSVP
runs end to end to communicate application requirements for special handling.
RSVP identifies a session between a client and a server and asks the routers handling the session to give its communications a priority in accessing resources.
When the session is completed, the resources reserved for the session are freed for the use of others.
RSVP offers only two levels of priority in its signaling scheme. Packets are identified at each router hop as either low or high priority. However, in crowded networks, two-level classification may not be sufficient. In addition, packets prioritized at one router hop might be rejected at the next.
Accepted as an IETF standard in 1997, RSVP does not attempt to govern who should receive bandwidth, and questions remain about what will happen when several users ail demand a large block of bandwidth at the same time.
Currently, the technology outlines a first-come, first-served response to this situation. The IETF has formed a task force to address the issue.
Because RSVP provides a special level of service, many people equate QoS with the protocol. For example, Cisco currently uses RSVP in its IPv4-based internetwork router operating system to deliver IPv6-type QoS features.
However, RSVP is only a small part of the QoS picture because it is effective only as far as it is supported within a given clientlserver connection.
Although RSVP allows an application to request latency and bandwidth, RSVP does not provide for congestion control or network-wide priority with the traffic flow management needed to integrate QoS across an enterprise.
(4) Real-time Transport Protocol (RTP) RTP is an emerging protocol for the Internet championed by the audio/video transport workgroup of the IETF. RTP supports real-time transmission of interactive voice and video over packet-switched networks. RTP

W.O 00/31933 PCT/US99/27658 is a thin protocol that provides content identification, packet sequencing, timing reconstruction, loss detection, and security. With RTP, data can be delivered to one or more destinations, with a limit on delay.
RTP and other Internet real-time protocols, such as the Internet stream protocol version 2 (ST2), focus on the efficiency of data transport. RTP and other Internet real-time protocols are designed for communications sessions that are persistent and that exchange large amounts of data. RTP does not handle resource reservation or QoS control. Instead, RTP relies on resource reservation protocols such as RSVP, communicating dynamically to allocate appropriate bandwidth.
RTP adds a time stamp and a header that distinguishes whether an IP
packet is data or voice, allowing prioritization of voice packets, while RSVP
allows networking devices to reserve bandwidth for carrying unbroken multimedia data streams.
Real-time Control Protocol (RTCP) is a companion protocol to RTP that analyzes network conditions. RTCP operates in a mufti-cast fashion to provide feedback to RTP data sources as well as all session participants. RTCP can be adopted to circumvent datagram transport of voice-over-IP in private IP
networks.
With RTCP, software can adjust to changing network loads by notifying applications of spikes, or variations. in network transmissions. Using RTCP
network feedback, telephony software can switch compression algorithms in response to degraded connections.
(5) IP Mufti-Casting Protocols Digital voice and video comprise of large quantities of data that, when broken up into packets, must be delivered in a timely fashion and in the right order to preserve the qualities of the original content. Protocol developments have been focused on providing efficient ways to send content to multiple recipients, transmission referred to as mufti-casting. Mufti-casting involves the broadcasting of a message from one host to many hosts in a one-to-many relationship. A network device broadcasts a message to a select group of other devices such as PCS or workstations on a LAN, WAN, or the Internet. For example, a roofer might send information about a routing table update to other roofers in a network.
Several protocols are being implemented for IP multi-casting, including upgrades to the Internet protocol itself. For example; some of the changes in the newest version of IP, IPv6, will support different forms of addressing for uni-cast {point-to-point communications), any cast (communications with the closest member of a device group), and mufti-cast. Support for IP mufti-casting comes from several protocols, including the Internet group management protocol (IGMP), protocol-independent mufti-cast (PIM) and distance vector mufti-cast routing protocol (DVMRP). Queuing algorithms can also be used to ensure that video or other mufti-cast data types arrive when they are supposed to without visible or audible distortion.
Real-time transport protocol (RTP) is currently an IETF draft. designed for end-to-end, real-time delivery of data such as video and voice. RTP works over the user datagram protocol (UDP), providing no guarantee of in-time delivery, quality of service (QoS), delivery, or order of delivery. RTP works in conjunction with a mixer and translator and supports encryption and security.
The real-time control protocol (RTCP) is a part of the RTP definition that analyzes network conditions. RTCP provides mandatory monitoring of services and collects information on participants. RTP communicates with RSVP
dynamically to allocate appropriate bandwidth.
Internet packets typically move on a first-come, first-serve basis. When the network becomes congested, Resource Reservation Protocol (RSVP) can enable certain types of traffic, such as video conferences. to be delivered before less time-sensitive traffic such as E-mail for potentially a premium price.
RSVP
could change the Internet's pricing structure by offering different QoS at different prices.
The RSVP protocol is used by a host, on behalf of an application, to request a specific QoS from the network for particular data streams or flows.
Roofers can use the RSVP protocol to deliver QoS control requests to all necessary network nodes to establish and maintain the state necessary to provide the requested service. RSVP requests can generally, although not necessarily, result in resources being reserved in each node along the data path.
RSVP is not itself a routing protocol. RSVP is designed to operate with current and future uni-cast and multi-cast routing protocols. An RSVP process consults the local routing database to obtain routes. In the mufti-cast case for example, the host sends IGMP messages to join a mufti-cast group and then sends RSVP messages to reserve resources along the delivery paths of that group.
Routing protocols determines where packets are forwarded. RSVP is concerned with only the QoS of those packets as they are forwarded in accordance with that routing.
d. Virtual Private Networks (VPNs) A virtual private network (VPN) is a wide area communications network operated by a telecommunications carrier that provides what appears to be dedicated lines when used, but that actually includes trunks shared among all customers as in a public network. A VPN allows a private network to be configured within a public network.
VPNs can be provided by telecommunications carriers to customers to provide secure, guaranteed, long-distance bandwidth for their WANs. These VPNs generally use frame relay or switched mufti-megabyte data service (SMDS) as a protocol of choice because those protocols define groups of users logically on the network without regard to physical location. ATM has gained favor as a VPN protocol as companies require higher reliability and greater bandwidth to handle more complex applications. VPNs using ATM offer networks of companies with the same virtual security and QoS as WANs designed with dedicated circuits.
The Internet has created an alternative to VPNs, at a much lower cost, i.e.
the virtual private Internet. The virtual private Internet (VPI) lets companies connect disparate LANs via the Internet. A user installs either a software-only or a hardware-software combination that creates a shared, secure intranet with VPN-style network authorizations and encryption capabilities. A VPI normally uses browser-based administration interfaces.
( I ) VPN Protocols A plurality of protocol standards exist today for VPNs. For example, IP
security (IPsec), point-to-point tunneling protocol (PPTP), layer 2 forwarding protocol (L2F) and layer 2 tunneling protocol (L2TP). The IETF has proposed a security architecture for the Internet protocol (IP) that can be used for securing Internet-based VPNs. IPsec facilitates secure private sessions across the Internet between organizational firewalls by encrypting traffic as it enters the Internet and decrypting it at the other end, while allowing vendors to use many encryption algorithms, key lengths and key escrow techniques. The goal of IPsec is to let companies mix-and-match the best firewall, encryption, and TCP/IP protocol products.
(a) Point-to-Point Tunneling Protocol (PPTP) Point-to-point tunneling protocol (PPTP} provides an alternate approach to VPN security than the use of IPsec. Unlike IPsec, which is designed to link two LANs together via an encrypted data stream across the Internet, PPTP
allows users to connect to a network of an organization via the Internet by a PPTP
server or by an ISP that supports PPTP. PPTP was proposed as a standard to the IETF
in early 1996. Firewall vendors are expected to support PPTP.
PPTP was developed by Microsoft along with 3Com, Ascend and US
Robotics and is currently implemented in WINDOWS NT SERVER 4.0, WINDOWS NT WORKSTATION 4.0, WINDOWS 95 via an upgrade and WINDOWS 98, available from Microsoft Corporation of Redmond, Washington.
The "tunneling" in PPTP refers to encapsulating a message so that the message can be encrypted and then transmitted over the Internet. PPTP, by creating a tunnel between the server and the client, can tie up processing resources.
(b) Layer 2 Forwarding (L2F) Protocol Developed by Cisco, layer 2 forwarding protocol (L2F) resembles PPTP
in that it also encapsulates other protocols inside a TCP/IP packet for transport across the Internet, or any other TCP/IP network, such as data network 112.
Unlike PPTP, L2F requires a special L2F-compliant router (which can require changes to a LAN or WAN infrastructure), runs at a lower level of the network protocol stack and does not require TCP/IP routing to function. L2F also provides additional security for user names and passwords beyond that found in PPTP.
(c) Layer 2 Tunneling Protocol (L2TP) The layer 2 tunneling protocol (L2TP) combines specifications from L2F
with PPTP. In November 1997, the IETF approved the L2TP standard. Cisco is putting L2TP into its Internet operating system software and Microsoft is incorporating it into WINDOWS NT 5Ø A key advantage of L2TP over IPsec, which covers only TCP/IP communications, is that L2TP can carry multiple protocols. L2TP also offers transmission capability over non-IP networks. L2TP
however ignores data encryption, an important security feature for network administrators to employ VPNs with confidence.
Data network I 12 will now be described in greater detail relating to example packet-switched networks. It will be apparent to persons having skill in the art that multiple network types could be used to implement data network I
12, including, for example, ATM networks, frame relay networks, IP networks FDDI
WAN networks SMDS networks, X-25 networks, and other kinds of LANs and WANs.

It would be apparent to those skilled in the art that other data networks could be used interchangeably for data network 112 such as. for example; an ATM, X.25, Frame relay, FDDI, Fast Ethernet, or an SMDS packet switched network. Frame relay and ATM are connection-oriented services. Switched multi-megabyte data service (SMDS) is a connection-oriented mass packet service that offers speeds up to 45 Mbps. Originally, SMDS was intended to fill the gap for broadband services until broadband ISDN (BISDN) could be developed. Because the infrastructure for BISDN is not fully in place, some users have chosen SMDS.
i 0 e. Exemplary Data Networks ( I } Asynchronous Transfer Mode (ATM) ATM is a high-bandwidth, low-delay, packet-switching, and multiplexing network technology. ATM packets are known as "cells." Bandwidth capacity is segmented into 53-byte fixed-sized cells, having a header and payload fields.
ATM is an evolution of earlier packet-switching network methods such as X.25 and frame relay, which used frames or cells that varied in size. Fixed-length packets can be switched more easily in hardware than variable size packets and thus result in faster transmissions.
Each ATM cell contains a 48-byte payload field and a 5-byte header that identifies the so-called "virtual circuit" of the cell. ATM can allocate bandwidth on demand, making it suitable for high-speed combinations of voice, data, and video services. Currently, ATM access can perform at speeds as high as 622 Mbps or higher. ATM has recently been doubling its maximum speed every year.
In an example embodiment, data network 112 is an asynchronous transfer mode (ATM) network. An ATM cell of data network 112 includes a header (having addressing information and header error checking information), and a payload (having the data being carned by the cell).
ATM is a technology, defined by a protocol standardized by the International Telecommunications Union (ITU-T), American National Standards Institute (ANSI), ETSI, and the ATM Forum. ATM comprises a number of building blocks, including transmission paths, virtual paths, and virtual channels.
Asynchronous transfer mode (ATM) is a cell based switching and multiplexing technology designed to be a general purpose connection-oriented transfer mode for a wide range of telecommunications services. ATM can also be applied to LAN and private network technologies as specified by the ATM
Forum.
ATM handles both connection-oriented traffic directly or through adaptation layers, or connectionless traffic through the use of adaptation layers.
ATM virtual connections may operate at either a constant bit rate (CBR} or a variable bit rate (VBR). Each ATM cell sent into an ATM network contains addressing information that establishes a virtual connection from origination to destination. All cells are transferred, in sequence, over this virtual connection.
ATM provides eitherpermanent or switched virtual connections (PVCs or SVCs).
ATM is asynchronous because the transmitted cells need not be periodic as time slots of data are required to be in synchronous transfer mode (STM}.
ATM uses an approach by which a header field prefixes each fixed-length payload. The ATM header identifies the virtual channel (VC). Therefore, time slots are available to any host which has data ready for transmission. If no hosts are ready to transmit, then an empty, or idle, cell is sent.
ATM permits standardization on one network architecture defining a multiplexing and a switching method. Synchronous optical network (SONET) provides the basis for physical transmission at very high-speed rates. ATM
also supports multiple quality of service (QoS) classes for differing application requirements, depending on delay and loss performance. ATM can also support LAN-like access to available bandwidth.
The primary unit in ATM, the cell, def nes a fixed-size cell with a length of 53 octets (or bytes) comprised of a five-octet header and 48-octet payload.
Bits in the cells are transmitted over a transmission path in a continuous stream.
Cells are mapped into a physical transmission path, such as the North American DS 1, DS3, and SONET; European, E 1, E3, and E4; ITU-T STM standards; and various local fiber and electrical transmission payloads. All information is multiplexed and switched in an ATM network via these fixed-length cells.
The ATM cell header field identifies the destination, cell type, and priority., and includes six portions. An ATM cell header includes a generic flow control (GFC), a virtual path identifier (VPI), a virtual channel identifier (VCI), a payload type (PT), a call loss priority (CLP), and a header error check (HEC).
VPI and VCI hold local significance only. and identify the destination. GFC
allows a multiplexer to control the rate of an ATM terminal. PT indicates whether the cell contains user data, signaling data, or maintenance information.
CLP indicates the relative priority of the cell, i.e., lower priority cells are discarded before higher priority cells during congested intervals. HEC detects and corrects errors in the header.
The ATM cell payload f eld is passed through the network intact, with no error checking or correction. ATM relies on higher-layer protocols to perform I S error checking and correction on the payload. For example, a transmission control protocol (TCP) can be used to perform error correction functions. The fixed cell size simplifies the implementation of ATM switches and multiplexers and enables implementations at high speeds.
When using ATM, longer packets cannot delay shorter packets as in other packet-switched networks, because long packets are separated into many fixed length cells. This feature enables ATM to carry CBR traffic, such as voice and video, in conjunction with VBR data traffic, potentially having very long packets, within the same network.
ATM switches take traffic and segment it into the fixed-length cells, and multiplex the cells into a single bit stream for transmission across a physical medium. As an example, different kinds of traffic can be transmitted over an ATM network including voice, video, and data traffc. Video and voice traffic are very time-sensitive, so delay cannot have significant variations. Data, on the other hand, can be sent in either connection-oriented or connectionless mode.
In either case, data is not nearly as delay-sensitive as voice or video traffic, conventionally. Conventional, however, data traffic is very sensitive to loss.

WO 00/31933 PCT/US99/2765$

Therefore, ATM conventionally must discriminate between voice, video, and data traffic. Voice and video traffic requires priority and guaranteed delivery with bounded delay, while data traffic requires, simultaneously, assurance of low loss.
According to the present invention, data traffic can also carry voice traffic, making it also time-dependent. Using ATM, in one embodiment, multiple types of traffic can be combined over a single ATM virtual path (VP), with virtual circuits (VCs) being assigned to separate data, voice, and video traffic.
FIG. 16B depicts graphically the relationship 1618 between a physical transmission path 1620, virtual paths (VPs) 1622, 1624 and 1626, and virtual channels (VCs) 1628, 1630, 1632, 1634, 1636, 1638, 1640, 1642, 1644, 1646, 1648 and 1650. A transmission path I 620 includes one or more VPs 1622, 1624 and 1626. Each VP 1622, 1624 and 1626 includes one or more VCs 1628, 1630, 1632,1634,1636,1638, 1640, 1642, 1644, 1646, 1648 and 1650. Thus, multiple VCs 1628-1650 can be trunked over a single VP and 1622. Switching can be performed on either a transmission path 1620, VPs 1622-1626, or at the level of VCs 1628-1650.
The capability of ATM to switch to a virtual channel level is similar to the operation of a private or public branch exchange (PBX) or telephone switch in the telephone world. In a PBX switch, each channel within a trunk group can be switched. Devices which perform VC connections are commonly called VC
switches because of the analogy to telephone switches. ATM devices which connect VPs are commonly referred to as VP cross-connects, by analogy with the transmission network. The analogies are intended for explanatory reasons, but should not be taken literally. An ATM cell-switching machine need not be restricted to switching only VCs and cross-connection to only VPs.
At the ATM layer, users are provided a choice of either a virtual path connection (VPC) or a virtual channel connection (VCC). Virtual path connections (VPCs) are switched based upon the-virtual path identifier (VPI) value only. Users of a VPC can assign VCCs within a VPI transparently, since they follow the same route. Virtual channel connections (VCCs) are switched upon a combined VPI and virtual channel identifier (VCI) value.

Both VPIs and VCIs are used to route calls through a network. Note that VPI and VCI values must be unique on a specific transmission path (TP).
It is important to note that data network 112 can be any of a number of other data-type networks, including various packet-switched data-type networks, in addition to an ATM network.
(2) Frame Relay Alternatively, data network 112 can be a frame relay network. It would be apparent to persons having ordinary skill in the art, that a frame relay network could be used as data network 112. Rather than transporting data in ATM cells, data could be transported in frames.
Frame relay is a packet-switching protocol used in WANs that has become popular for LAN-to-LAN connections between remote locations. Formerly frame relay access would top out at about 1.5 Mbps. Today, so-called "high-speed"
frame relay offers around 45 Mbps. This speed is still relatively slow as compared with other technology such as ATM.
Frame relay services employ a form of packet-switching analogous to a streamlined version of X.25 networks. The packets are in the form of frames, which are variable in length. The key advantage to this approach it that a frame relay network can accommodate data packets of various sizes associated with virtually any native data protocol. A frame relay network is completely protocol independent. A frame relay network embodiment of data network 112 does not undertake a lengthy protocol conversion process, and therefore offers faster and less-expensive switching than some alternative networks. Frame relay also is faster than traditional X.25 networks because it was designed for the reliable circuits available today and performs less-rigorous error detection.

w0 00/31933 PCT/US99rZ7658 (3) Internet Protocol (IP) In an embodiment, data network 112 can be an Internet protocol (IP) network over an ATM network. It would be apparent to persons having ordinary skill in the art, that an Internet protocol (IP) network (with any underlying data link network) could be used as data network I 12. Rather than transporting data in ATM cells, data could be transported in IP datagram packets. The IP data network can lie above any of a number of physical networks such as, for example, a SONET optical network.
4. Signaling Network FIG. 17C illustrates signaling network 114 in greater detail. In an embodiment of the invention, signaling network I 14 is an SS7 signaling network.
The SS7 signaling network 114 is a separate packet-switched network used to handle the set up, tear down, and supervision of calls between calling party and called party 120. SS7 signaling network 114 includes service switching points (SSPs) 104, I 06,126 and 130, signal transfer points (STPs) 216, 2I 8, 250a, 250b, 252a and 252b, and service control point (SCP) 610.
In SS7 signaling network I14, SSPs 104, 106, 126 and 130 are the portions of the backbone switches providing SS7 functions. The SSPs 104, 106, 126 and 130 can be, for example, a combination of a voice switch and an SS7 switch, or a computer connected to a voice switch. SSPs 104, 106, 126 and 130 communicate with the switches using primitives, and create packets for transmission over SS7 signaling network 114.
Carrier facilities 126, 130 can be respectively represented in SS7 network 114 as SSPs 126, 130. Accordingly, the connections between carrier facilities I26 and 130 and signaling network 114 (presented as dashed lines in FIG. 2A) can be represented by connections 1726b and 1726d. The types of these links are described below.

STPs 216, 218, 250a, 250b, 252a and 252b act as routers in the SS7 network, typically being provided as adjuncts to in-place switches. STPs 216, 218, 250a, 250b, 252a and 252b route messages from originating SSPs 104 and 126 to destination SSPs 106 and 130. Architecturally, STPs 216, 218, 250x, 250b, 252a and 252b can be and are typically provided in "mated pairs" to provide redundancy in the event of congestion or failure and to share resources (i.e. load sharing is done automatically). As illustrated in FIGS. 17A, 17B
and 17C, STPs 216, 2I 8, 250a, 250b, 252a and 252b can be arranged in hierarchical levels, to provide hierarchical routing of signaling messages. For example, mated STPs 250a, 252a and mated STPs 250b, 252b are at a first hierarchical level, while mated STPs 216, 218 are at a second hierarchical level.
SCP 610 can provide database functions. SCP 610 can be used to provide advanced features in SS7 signaling network I 14, including routing of special service numbers (e.g., 800 and 900 numbers), storing information regarding subscriber services, providing calling card validation and fraud protection, and offering advanced intelligent network (AIN) services. SCP 610 is connected to mated STPs 216 and 218.
In SS7 signaling network 1 I 4, there are unique links between the different network elements. Table 19 provides definitions for common SS7 links.
Mated STP pairs are connected together by C links. For example, STPs 216 and 218, mated STPs 250a and 252a, and mated STPs 250b and. 252b are connected together by C links 1728a, 1728b, 1728c, 1728d, 1728e and 1728f, respectively. SSPs 104 and 126 and SSPs 106 and 130 are connected together by F links 1734 and 1736, respectively.
Mated STPs 250a and 252a and mated STPs 250b and 252b, which are at the same hierarchical level, are connected by B links 1732a, 1732b, 1732c and 1732d. Mated STPs 250a and 252a and mated STPs 216 and 218, which are at different hierarchical levels, are connected by D links 1730a, 1730b, 1730e and 1730f. Similarly, mated STPs 250b and 252b and mated STPs 216 and 218, which are at different hierarchical levels, are connected by D links 1730c,1730d, 1730g and 1730h.

SSPs 104 and 126 and mated STPs 250a and 252a are connected by A
links 1726a and 1726b. SSPs 106 and 130 and mated STPs 250b and 252b are connected by A links 1726c and 1726d.
SSPs 104 and 126 can also be connected to mated STPs 216 and 218 by E links (not shown). Finally, mated STPs 216 and 218 are connected to SCP 610 by A links 608a and 608b.
For a more elaborate description of SS7 network topology, the reader is referred to Russell, Travis, Signaling System #7, McGraw-Hill, New York, NY
10020, ISBN 0-07-054991-5, which is incorporated herein by reference in its entirety.
Table Z9 Port Status SS7link terminologyDefinitions Access (A) linksA links connect SSPs to STPs, or SCPs to STPs, providing network access and database access through the STPs.

Bridge (B) finksB links connect mated STPs to other mated STPs.

Cross (C) links C links connect the STPs in a mated pair to one another.

During normal conditions, only network management messages are sent over C links.

Diagonal (D) D links connect the mated STPs at links a primary hierarchical level to mated STPs at a secondary hierarchical level.

Extended (E) E links connect SSPs to remote mated links STPs, and are used in the event that the A links to home mated STPs are congested.

Fully associatedF links provide direct connections (F) between local SSPs links (bypassing STPs) in the event there is much traffic between SSPs, or if a direct connection to an STP is not available. F finks are used only for call setup and call teardown.

a. Signal Transfer Points (STPs) Signal transfer points (STPs) are tandem switches which route SS7 signaling messages long the packet switched SS7 signaling network 114. See the description of STPs with reference to FIG. 17A, in the soft switch site section, and with reference to FIG. 17C above.
b. Service Switching Points (SSPs) Service switching points (SSPs) create the packets which carry SS7 signaling messages through the SS7 signaling network 114. See the description of SSPs with reference to FIG. 17C, above.
c. Services Control Points (SCPs) Services control points (SCPs) can provide database features and advanced network features in the SS7 signaling network 114. See the description of SCPs with reference to FIG. 17B in the soft switch site section, and with reference to FIG. I7C above.
5. Provisioning Component FIG. I 8 depicts a provisioning component and network event component architecture 1800. FIG. 18 includes a spool-shaped component (including provisioning component 117 and network event component 116), and three soft switch sites, i.e. western soft switch site 104. central soft switch site 106 and eastern soft switch site 302.
The top elliptical portion of the spool-shaped component, illustrates an embodiment of provisioning component 117, including operational support services (OSS) order entry (O/E) component 1802, alternate order entry component 1804 and data distributors 222a and 222b. In an example embodiment, data distributors 222a and 222b comprise application programs.

In a preferred embodiment, data distributors 222a and 222b include ORACLE 8.0 relational databases from Oracle Corporation of Redwood Shores, CA, Tuxedo clients and a BEA M3 OBJECT MANAGEMENT SYSTEM, CORBA-compliant interface, available from BEA Systems, Inc. of San Francisco, CA, with offices in Golden, CO. BEA M3 is based on the CORBA distributed objects standard. BEA M3 is a combination of BEA OBJECTBROKER CORBA
ORB (including management, monitoring, and transactional features underlying BEA TUXEDO), and an object-oriented transaction and state management system, messaging and legacy access connectivity. BEA M3 is scalable, high performance, designed for high availability and reliability, supports transactions, includes CORBA/IIOP ORB, security, MIB-based managment, supports fault management, dynamic load balancing, gateways and adapters, client support, mufti-platform porting, data integrity, management, reporting and TUXEDO
Services.
In another embodiment, data distributors 222a and 222b include an application program by the name of automated service activation process (ASAP) available from Architel Systems Corporation of Toronto, Ontario.
Customer service request calls can be placed to a customer service office.
Customer service operators can perform order entry of customer service requests via OSS 1802 order entry (O/E) 1803 system. In the event of the unavailability of OSS O/E 1802, customer service requests may be entered via alternate O/E
1804. Customer service requests .are inputted into data distributors 222a and 222b for distribution and replication to configuration servers 312a, 312b, 206a, 206b, 316a and 316b which contain customer profile database entries. In addition, provisioning requests can be performed. Replication facilities in data distributors 222a and 222b enable maintaining synchronization between the distributed network elements of telecommunications network 200.

a. Data Distributor Referring to FIG. 18 data distributors 222a and 222b receive service requests from upstream provisioning components such as, e.g., OSS systems.
Data distributors 222a and 222b then translate the service requests and decompose the requests into updates to network component databases. Data distributors 222a and 222b then distribute the updates to voice network components in soft switch sites and gateway sites. FIG. 19A depicts examples of both the upstream and downstream network components interfacing to data distributors 222 and 222b.
FIG. 19A depicts data distributor architecture 1900. FIG. 19A includes a data distributor 222 interfacing to a plurality of voice network elements.
Voice network elements illustrated in FIG. 19A include SCPs 214a and 214b, configuration servers 206a, 3 I2a and 3 I 6a route servers 212a, 2I2b, 314a, 314b, 316a and 316b TGs 232 and 234, AGs 238 and 240, and SS7 GWSI 208 and 210.
In addition, data distributor 222 interfaces to a plurality of services.
Services include provisioning services 1902, customer profiles/order entry services 1803, OSS I 802, route administration services 1904, service activation services 1906, network administration services 1908, network inventory services 1910 and alternate data entry (APDE) services 1804.
Data distributor 222 has a plurality of functions. Data distributor 222 receives provisioning requests from upstream OSS systems, distributes provisioning data to appropriate network elements and maintains data synchronization, consistency and integrity across data centers, i.e., soft switch sites 104, 106, 302.
A more detailed architectural representation of one embodiment of data distributor 222 is provided in FIG. 19B. Data distributor 222 accepts various requests from multiple upstream OSS systems 1922,1924,1926,1928 and APDE
1804.
Services request processes (SRPs) 1938 manage the upstream interface between data distributor 222 and OSS systems 1922-1928. SRPs 1938 are developed to support communication between individual OSS systems 1802,1922-1928, APDE 1804 and data distributor 222.
A common service description layer 1936 acts as an encapsulation layer for upstream applications. Common service description layer 1936 translates service requests from upstream OSS systems 1922-1928 and APDE 1804 to a common format. Common service description layer 1936 buffers the distribution logic from any specific formats or representations of OSS 1922-I 928 and APDE
1804.
Distribution layer 1930 includes the actual distribution application logic resident within data distributor 222. Distribution layer 1930 manages incoming requests, performs database replications, maintains logical work units, manages application revisions, performs roll-backs when required, maintains synchronization, handles incoming priority schemes and priority queues, and other data distribution functions. Distribution layer 1930 includes access to multiple redundant high-availability database disks 1940, 1942, which can include a database of record.
Updates are distributed downstream through a network element description layer 1932. Network element description layer 1932 is an encapsulation layer that insulates data distributor 222 from the individual data formats required by specific network element types. A network element processor (NEP) 1934 performs a role analogous to SRP 1938, but instead for downstream elements rather than upstream elements. NEPs I934 manage the physical interface between data distributor 222 and heterogeneous network elements 1943, i.e. the down stream voice network elements to which data distributor 222 distributes updates. Heterogeneous network elements 1943 include SCPs 214a and 214b, configuration servers 206a, 212a and 216a, route servers 212x, 212b, 314a, 314b, 316a and 3 I6b, TGs 232 and 234, AGs 238 and 240, and SS7 GWs 208 and 210. Each NEP 1934 handles a particular type of heterogeneous network elements, e.g., route servers.
In addition to upstream feeds to OSS systems 1922-1928 and downstream feeds to heterogeneous network elements 1943, data distributor 222 allows WO 00/31933 PC'f/US99/27658 updates directly to distribution layer 1930 via APDE 1804. APDE I 804 enables update of distribution layer 1930 and allows updates to the network in the unlikely event that an emergency update is required when interfacing OSS
systems 1922-1928 upstream application are out of service or down for S maintenance activity. APDE 1804 the alternate provisioning order entry system, can comprise a small local area network including several PCs and connectivity peripherals. APDE 1804 provides a backup for OSSs 1922-1928.
In a preferred example embodiment of data distributor 222, data distributor 222 is an application program BEA M3 available from BEA Systems, Inc. of San Francisco, CA. In another example embodiment, data distributor 222 could be another application program capable of distributing/replication/rollback of software such as, for example, AUTOMATED SERVICE ACTIVATION
PROCESS (ASAP) available from Architel of Toronto, Canada. Example upstream operational support services (OSS) components include application 1 S programs which perform multiple functions. FIG. 19C illustrates some example OSS applications 1802 including provisioning application 1902, customer profiles/order entry application 1803, route administration application 1904, service activation triggers 1906, network administration application 1908, network inventory application 1910, alternate provisioning data entry application (APDE) 1804, and trouble ticketing application (not shown). Browsing tools can also be used, such as, for example, a browsing or query application programs.
FIG. 19C illustrates a more detailed view of an example embodiment of data distributor 222. Data distributor 222 includes distribution layer 1930 interfacing to database disks 1940 and 1942. Distribution layer 1930 of FIG. I

interfaces to common service description layer 1936. In an example embodiment, common service description layer 1936 is a common object request broker architecture (CORBA) compliant server such as, for example, BEA M3 from BEA Systems, Inc. of San Francisco, CA. Alternate provisioning data entry (APDE) 1804 interfaces to CORBA server 1936. Upstream voice provisioning components, i.e., operational support services (OSS) 1922-1928, include application components 1802 and 1902-19I 0. Provisioning component 1902 has a CORBA client in communication with CORBA server common service description layer 1936. Customer profiles/order entry 1802 includes a CORBA
client interface into CORBA server common service description layer 1936.
Similarly, routing administration 1904, network inventory 1910, network administration I 908 and service triggers 1906 all interface via CORBA clients to CORBA server common service description layer 1936. Distribution layer 1930 also interfaces to downstream voice network elements via an application program, i.e., network element description layer 1932. In an exemplary embodiment, network element description layer 1932 is an application program running on a work station, such as, for example BEA TUXEDO, available from BEA Systems, Inc.. Voice network element configuration servers 206, 312a and 314a interface via a TUXEDO client to TUXEDO server network element description layer 1932. Routing servers 212a, 212b, 314a, 314b, 316a and 316b interface via a TUXEDO client to TUXEDO server network element description layer 1932, as well. Similarly, SS7 GWs 208 and 210, SCPs 214a and 214b, AGs 238 and 240, and TGs 232 and 234, interface to TUXEDO server network element description layer 1932 via TUXEDO clients. Preferred embodiment BEA TUXEDO
available from BEA Systems, Inc. of San Francisco, CA (Colorado Springs and Denver/Golden, CO office) supports among other functions, rollback and data integrity features. FIG. 19C also includes database of record (DOR} 1940, 1942.
FIG. 19E includes a more detailed illustration of a specific example embodiment of the data distributor and provisioning element 116. FIG. 19E
includes DOR 1940 and 1942, which can be in a primary/secondary relationship for high availability purposes. DORs 1940,1942 can have stored on their media, images of the Route Server and Co~guration Server databases. In one embodiment, the functions of route server 314a and configuration server 312a are performed by the same physical workstation element, a routing and configuration database (RCDB). DOR 1940 can be used for referential integrity. ORACLE
relational database management (RDBMS) databases, e.g., ORACLE 8.0 RDBMS can support the use of a foreign key between a database and an index.
DOR 1940 can be used to maintain integrity of the database. DOR 1940 sets constraints on the RCDB databases. DOR 1940 is used to maintain integrity of RCDB data and can be used to query data without affecting call processing. DOR
1940 supports parity calculations to check for replication errors.
FIG. 19E includes distribution layer 1930 which can be used to distribute service level updates oftelecommunications network system software to network elements using database replication features of, e.g., ORACLE 8Ø Other business processes demand updating the software on network elements. For example, other business processes requiring updates include, NPA splits. NPA
splits, occur when one area code becomes two or more area codes. An NPA split can require that thousands of rows of numbers must be updated. FIG. 19E
includes an automated tool to distribute changes, i.e. a routing administration toot (RAT) 1904.
FIG. 19E also includes data distributor common interface (DDCI) 1999, which can be thought of as an advanced programming interface (API) functional calls that OSS developers can invoke in writing application programs. OSS
applications include programs such as, e.g., provisioning, order management and billing, (each of which can require the means to provision the RCDB. i.e., RS
and CS, or can provide updates to the database of record (DOR).
FIG. 19E illustrates a data distributor including BEA M3, a CORBA-compliant interface server 1936 with an imbedded TUXEDO layer. BEA M3 communicates through the CORBA server interface 1936 to CORBA- compliant clients. Other examples of CORBA compliant distributed object connectivity software includes, for example, VISIGENICS VISIBROKER, available from Inprise Corporation, of Scotts Valley, CA.
DOR 1940 includes aplurality ofrelational database tables including each EO, NPA, NXX, LATA, and state. Each EO can home to 150,000 NPA/NXXs.
Multiple inputs must be replicated into DOR 1040. For example, Lockheed Martin Local Exchange and Routing Guide (LERG) 1941 includes twelve (12) tables maintained by the industry including flat files which are sent to a carrier each month. FIG. 19E demonstrates an exemplary monthly reference data update process 1957. Monthly, a LERG 1941 compact disk (CD) is received by the carrier including changes to all of the 12 tables. Process 1957 includes merging an image snapshot of DOR 1940 with the LERG CD and storing the results in a temporary routing database (shown) to create a discrepancy report. This process can be used to yield a subset of the NPA/NXXs which have changed, which can then be audited and used to update the production DOR 1940 if found to be necessary. Once an updated version of the database is prepared, the database update can be sent to data distributor 1930 for distribution to all the relevant network elements.
IO FIG. 19F depicts an even more detailed example embodiment block diagram 1958 of BEA M3 data distributor of provisioning element 1 I 6. Diagram 1958 shows the flow of a provisioning request from OSS 1802 or APDE 1804 through BEA M3 CORBA interface 1936 through queues to data distributor 1930 for distribution/replication through queue servers 1995a,1995b,1995c, and I S queues 1996a. 1996b, 1996c for dispatch to geographically diverse RCDBs 212a, 206 (RSs and CSs at remote soft switch sites) through dispatch servers 1997a, 1997b, 1997c and DBProxyServers 1998a. 1998b, 1998c, 1998d, 1998e and 1998f.
Operationally, when a provisioning request comes in from OSS 1802, the 20 request enters a queue. Priority queuing is enabled by BEA TUXEDO. Tuxedo creates a plurality of queues in order to protect database integrity, e.g., a high, medium and low priority queue. An example of the use of queues might be to place a higher priority on customer updates that to LERG updates, which are less time sensitive. Requests can be categorized in queues based on dates such as, for 25 example, the effective date of the request, the effective deactivation date. Once categorized by date, the updates can be stored with a timestamp placed on them, and can then be placed in a TUXEDO queue.
TUXEDO permits the use of down word transaction in its mufti-level queuing architecture. This permits pulling back transactions, also known as 30 "rolling back" a replication/update, so updates will occur to all of or none of the databases. In some instances one network element can be removed from the WO 00/31933 PCT/US99rZ7658 network, but this is done rarely. For an example. in the event of RCDB
crashing, the NOC can remove the crashing RCDB from the network configuration and thus it might not be capable of being updated.. However, for normal situations of the network, updates are either performed on all elements or no updates are performed.
FIG. 19G depicts a block diagram illustrating a high level conceptual diagram of the CORBA interface 1960. CORBA IDL Interface 1936 includes routing provisioning 1966, common configuration provisioning (configuration server provisioning) 1803, provisioning factory 1902, routing factory 1968, common configuration factory 1970, routing services 1908, 1910, common configuration services 1960 and SQL translator I 972. SQL translator 1972 takes the application API calls and translates them into structured query language queries for queuing for eventual invocation against database of record 1940.
FIG. 19H depicts a block diagram 1962 illustrating additional components of the high level conceptual diagram of the CORBA interface 1960.
CORBA IDL Interface 1936 includes routing administration 1904, routing validation 1974, routing administration factory 1980, composite updates 1976, batch updates 1982, and projects 1978. SQL translator 1972 can take the application API calls and translate them into structured query language queries for queuing for eventual invocation against project database 1984.
FIG. 19I depicts a block diagram illustrating a data distributor sending data to configuration server sequencing diagram I 964 including message flows 1986-1994.
( 1 ) Data Distributor Interfaces Data distributor 222 receives service requests from upstream OSS systems 1922, 1924, 1926 and 1928. OSS service requests appear in the form of provisioning updates and administrative reference updates.
Provisioning updates include high-level attributes required to provision a customer's telecommunications service. Example high-level attributes required for provisioning include, for example, customer automatic number identification (ANI), and trunk profiles; class of service restrictions (COSR) and project account codes (PAC) profiles; AG and TG assignments: and toll-free number to SCP translation assignments.
Administrative reference updates include high-Ievel attributes required to support call processing. Example high-level attributes required to perform administrative updates include, for example, 3/6/10 digit translation tables, international translation tables and blocked country codes.
Alternate provisioning data entry (APDE) 1804 replicates OSS
functionality supported at the interface with data distributor 222. APDE 1804 can provide an alternative mechanism to provide provisioning and reference data to data distributor 222 in the event that an OSS 1922-1928 is unavailable.
FIG. I 9D illustrates data distributor 222 passing provisioning information from upstream OSSs 1922-1928 to downstream SCPs 214. A plurality of tables are distributed from data distributor 222 to each SCP 214. Exemplary data tables distributed include a PAC table, an ANI table, blocking list tables, numbering plan area (NPA)/NXX tables, state code tables, and LATH tables. Each of these tables is maintained at the customer level to ensure customer security.
FIG.19D illustrates block diagram 1946 depicting provisioning interfaces into SCPs. SCP 214 can receive customer and routing provisioning from data distributor 222. Data distributor 222 distributes customer database tables to SCP
214. Data distributor 222 also distributes route plan updates of configurations to SCP 214. Customer tables are updated through a database replication server. An exemplary database replication server is an ORACLE database replication server, available from ORACLE of Redwood Shores, CA. ORACLE replication server performs replication functions including data replication from data distributor to SCP 1952 and route plan distribution from data distributor to SCP 1954. These functions are illustrated in FIG. 19D originating from ORACLE databases 1940 and 1942 of data distributor 222 and replicating to an ORACLE database in SCP
214. ORACLE databases 1940 and 1942 in data distributor 222 are updated via toll-free routing provisioning 1950 from SCP 1902. ORACLE databases 1940 and 1942 of data distributor 222 can also be updated via order entry application 1802 including customer tables 1948 of OSS systems 1922-1928. Routing plans are updated via an SCP vendor's proprietary interfaces. Specifically, toll-free routing provisioning 1950 may be updated via a computer 1902 which interfaces to data distributor 222.
Referring to FIG. 19C, data distributor 222 passes provisioning and configuration information from upstream OSS systems 1922-1928 (primarily the provisioning system) to configuration servers 206a, 312a and 314a. A plurality of tables are distributed from data distributor 222 to each configuration server.
Exemplary tables distributed include, for example, toll-free numbers to SCP-type tables, SCP-type to SCP tables, carrier identification code (CIC) profile tables, ANI prof le summary tables, ANI profile tables, account code profile tables, NPA/NXX tables, customer profile tables. customer location profile tables, equipment service profile tables, trunk group service profile summary tables, trunk group service tables, high risk country tables. and selected international destinations tables.
Data distributor 222 passes administrative and reference information from upstream OSS systems 1922-1928 to route server 2I2. A plurality of tables are distributed from data distributor 222 to route servers 212a, 212b, 314a, 314b, 316a and 316b. Exemplary tables distributed include country code routing tables, NPA routing tables, NPA/NXX routing tables. ten-digit routing tables, route group tables, circuit group tables, and circuit group status tables.
Data distributor 222 passes administrative configuration information to TGs 232 and234.
Data distributor 222 passes administration configuration information to AGs 238 and 240.
Data distributor passes administrative configuration information to SS7 gateways 208 and 210. The administrative configuration information sent can be used in the routing of SS7 signaling messages throughout signaling network 114.
Data distributor 222 uses a separate physical interface for all SNMP
messages and additional functions that can be defined. Additional functions that can be defined include, for example, provisioning, and passing special alarm and performance parameters to data distributor 222 from the network operation center (NOC).
6. Network Event Component FIG. 18 depicts the provisioning component and network event component architecture 1800. FIG. 18 includes a spool-shaped component (comprising provisioning component I 17 and network event component 116), and three soft switch sites, i.e. western soft switch site 104, central soft switch site 106 and eastern soft switch site 302.
The spindle portion of the spool-shaped component includes western soft switch site 104. Western soft switch site 104 includes configuration servers 206a and 206b, route servers 212a and 212b, soft switches 204a. 204b and 204c, and network event collection points, i.e., RNECPs 224a and 224b. FIG. 18 also includes central soft switch site 106 including configuration servers 312a and 312b, route servers 314a and 314b, soft switches 304a. 304b and 304c, and 1 S RNECPs 902 and 904.
FIG. 18 also includes eastern soft switch site 302 including configuration servers 316a and 316b, route servers 318a and 3 I 8b, soft switches 306a. 306b and 306c and RNECPs 906 and 908.
As depicted in FIG. 18. network call events are collected at regional network event collection points via RNECPs 902, 904, 224a, 224b; 906 and 908, at the regional soft switch sites 104, 106 and 302. which are like FIFO
buffers.
A call record can be created by the ingress soft switch. The ingress soft switch can generate a unique identifier (UID) for the call based, for example. on the time of origination of the call. Ingress related call event blocks can be generated throughout the call and are forwarded on to the RNECPs for inclusion in a call event record identified by the UID. The call event records can be sent from the RNECPs to master network event data base NEDB 226a and 226b for storage in database disks 926a, 926b and 926c for further processing using application programs such as, for example, fraud DB client I 806, browser 1808, statistics DB
client 1810 and mediation DB client 1812. In one embodiment, a version of the call record including all call event blocks as of that time, can be forwarded from the RNECPs to the NEDB on a periodic basis, to permit real-time, mid-call call event statistics to be analyzed. The call records can be indexed by the UID
associated with the call. In one embodiment, a copy of a call event record for a call, including ingress call event blocks, remains in the RNECP until completion of the phone call. In completing a phone call, the ingress soft switch and egress soft switch can communicate using inter soft switch communication, identifying the call by means of the UID. A load balancing scheme can be used to balance storage and capacity requirements of the RNECPs. For example, in one embodiment, calls can be assigned. based on origination time, i.e., a UID can be assigned to a specific RNECP(based, e.g., on time of origination of the call) for buffered storage. The egress soft switch can similarly generate and forward call event blocks to the same or another RNECP for inclusion in the call event record.
In one embodiment, all the call event blocks for the call record for a given call are sent to one RNECP which maintains a copy throughout the call(i.e. even if interim copies are transmitted for storage). In one embodiment, the call event record is removed from the RNECP upon completion of the call to free up space for additional calls.
The bottom elliptical portion of spool-shaped component, illustrates an embodiment of network event component 116 including master NEDBs 226a and 226b having database disks 926a, 926b and 926c. MNEDBs 226a and 226b can be in communication with a plurality of applications which process network call event blocks. For example, a fraud DB client 1806, a browser 1808, a statistics DB client 1810, and a mediation DB client 1812 can process call event blocks (EBs).MNEDBs 226a and 226b can be in set up in a primary and secondary mode.
a. Master Network Event Database (MNEDB) The master network event database (MNEDB) 226 is a centralized server which acts as a repository for storing call event records. MNEDB 226 collects data from each of RNECPs 224 which transmit information real-time to MNEDB

226. MNEDB 226 can also be implemented in a primary and secondary server strategy, wherein RNECPs 224 are connected to a primary and a secondary MNEDB 226 for high availability redundancy. MNEDB 226 can store call event blocks (EBs) received from RNECPs 224 organized based on a unique call/event identifier as the primary key and a directional flag element as the secondary key.
MNEDB 226 can serve as the "database of record" for downstream systems to be the database of record. Downstream systems include, for example, an accounting/billing system, a network management system, a cost analysis system, a call performance statistics system, a carrier access billing system (CABS), fraud IO analysis system, margin analysis system, and others. MNEDB 226, in a preferred embodiment, has enough disk space to store up to 60 days of call event records locally.
MNEDBs 226 can create and feed real-time call event data to downstream systems. Real-time call event data provides significant advantages over call event data available in conventional circuit-switched networks. Conentional circuit-switched networks can only provide call records for completed calls to downstream systems. The advantages of real-time call event data include, for example, fraud identification and prevention, and enablement of real-time customized customer reporting and billing (e.g., billing based on packets sent).
( 1 ) MNEDB Interfaces MNEDBs 226 collect recorded call event blocks (EBs) from RNECPs 224. MNEDB 226 correlates the EBs and forwards the data to various downstream systems.
FIG. 20 illustrates master data center architecture 2000. FIG. 20 includes master data center 2004 having MNEDBs 226a and 226b. MNEDBs 226a and 226b have multiple redundant high availability disks 926a and 926b which can be arranged in a primary and secondary fashion for high availability redundancy.
MNEDBs 226a and 226b intercommunicate as shown via communication line 2006.

w0 00/31933 PC"T/US99/27658 MNEDBs 226a and 226b are in communication via multiple redundant connections with a plurality of downstream application systems. Downstream application systems include, for example, browser system 1808, fraud DB client system 1806, carrier access billing system (CABS) DB client 2002, statistics DB
client 1810 and mediation DB client 1812.
MNEDBs 226a and 226b provide recorded call event record data to fraud database client 1806 in real-time. Real-time call event data allows fraud DB
client 1806 to detect fraudulent activities at the time of their occurrence, rather than after the fact. Traditional circuit-switched networks can only identify fraud after completion of a call, since event records are "cut" at that time. Real-time fraud detection permits operations personnel to take immediate action against fraudulent perpetrators. MNEDBs 226a and 226b provide recorded call event data to CABS DB client 2002. CABS DB client 2002 uses the recorded call event data to bill other LECs and IXCs for their usage of telecommunications I S network 200, using reciprocal billing.
MNEDBs 226a and 226b provide recorded call data to statistics DB client 1810. Statistics DB client 1810 uses the recorded call event data to assist in traffic engineering and capacity forecasting.
MNEDBs 226a and 226b can provide recorded call event data to mediation DB client 1812, in one embodiment. Mediation DB client 212 normalizes the recorded call data it receives from MNEDBs 226a and 226b and provides a data feed to a billing system at approximately real-time.
MNEDBs 226a and 226b use a separate physical interface for all SNMP
messages and additional functions that can be defined to communicate with network management component 118. Additional functions can include, for example, provisioning, updating and passing special alarm and performance parameters to MNEDBs 326a and 326b from the network operation center (NOC) of network management component 118.

WO 00/31933 PC'f/US99/27658 (2) Event Block Definitions Definitions of the Event Blocks (EBs} that can be recorded during call processing are detailed in this section.
(a} Example Mandatory Event Blocks (EBs) Definitions Table 20 below provides a definition of event block (EB) 0001. EB 0001 defines a Domestic Toll (TG origination), which can be the logical data set generated for all Domestic Long Distance calls, originating via a Trunking Gateway, i.e., from facilities ofthe PSTN. Typically, these calls can be PIC-calls, originating over featuring group-D (FGD) facilities.
Table 20 EB 0001- Domestic Toll (TG origination) Element Element Number Number of Characters Event Block Code 0 6 IS Uni ue Call/Event Identifieri 26 Call Event Block Se uence82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. $p Directional Fla 77 1 Connect Date 3 8 .

Connect Time 4 9 Callin Pa Cate o 6 3 Ori inatin Number 7 1 ~

Customer Identification 80 12 Customer Location Identification81 12 Overseas Indicator g 1 Terminatin NPA/CC 9 5 Terminatin Number NANP I0 1 p Call T a Identification 79 3 Carrier Selection Information51 2 Carrier Identification 12 Code In ress Trunkin Gatewa 52 In ress Carrier Connect 72 g Date In ress Carrier Connect I3 9 Time In ss Trunk Grou Number 15 4 In ress Circuit Identification16 Code Trunk Grou T a 7g WO 00/31933 PC'f/US99/27658 Table ZO

EB 0001- Domestic Toll (TC origination) Element Element NumberNumber of Characters In ress Ori inatin Point 17 9 Code In ress Destination Point18 g Code Jurisdiction Information 30 Table 21 below provides a definition of event block (EB) 0002. EB 0002 defines Domestic Toll (TG termination), which can be the logical data set generated for all Domestic Long Distance calls terminating via a Trunking Gateway to the PSTN.
Table 21 EB 0002 - Domestic Toll (TC termination) Element Element NumberNumber of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence82 2 Number Soft-Switch !D 2 6 Soft Switch Version ID. SO 4 Directional Fla 77 I

Connect Date 3 8 Connect Time Callin Party Cate or I (>

Ori inatin Number ' 7 10 Overseas Indicator g 1 Terminatin NPA/CC 9 5 Terminatin Number (NANP 10 I 0 CaI1 T a Identification 79 Carrier Identification I2 4 Code Jurisdiction Information 30 Table 22 below provides a definition of event block (EB) 0003. EB 0003 defines Domestic Toll (AG origination), which can be the logical data set generated for all Domestic Long Distance calls, originating via an Access Gateway, i.e., entering via a DAL or ISDN P1ZI line.

Table 22 EB 0003 - Domestic Toll (AG
origination) Element Element Number of Number Characters Event Block Code 0 6 Uni ue Call/Event Identifier 1 26 Call Event Block Se uence 82 2 Number Soft-Switch 1D 2 6 Soft Switch Version ID. 50 4 Directional Fla 77 I

Connect Date 3 g Connect Time 4 9 Callin Pa Cate o 6 3 Ori inatin Number 7 10 Customer Identification 80 12 I S Customer Location Identification81 12 Overseas Indicator g 1 Terminatin NPA/CC 9 Terminatin Number (NANP 10 10 Call T a Identification 79 3 Carrier Selection Information51 2 Carrier Identification Code 12 4 In ress Access Gatewa 36 In ress Trunk Grou Number 15 4 In ress Circuit Identification16 4 Code Trunk Grou T a 7g Table 23 below provides a definition of event block (EB) 0004. EB 0004 defines Domestic Toll (AG termination). which can be the logical data set generated for all Domestic Long Distance calls. terminating via an Access Gateway to a DAL or PRI
Table 23 EB 0004 - Domestic Toll (AC termination) Element Element NumberNumber of Characters Event Block Code 0 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. SO 4 Directional Fia 7~ 1 Connect Date 3 g Connect Time 4 9 Table 23 EB 0004 - Domestic Toll (AG termination) Element Element NumberNumber of Cltaracters Callin Partv Cate o 6 3 Ori inatin~ Number 7 10 Overseas Indicator g 1 Terminatin NPA/CC 9 Terminatin Number NANP) 10 10 Call T a Identification 79 3 Carrier Identification 12 4 Code Table 24 below provides a definition of event block (EB) 0005. EB 0005 defines Local (TG origination), which can be the logical data set generated for all local calls, originating via a Trunking Gateway from a facility on the PSTN.
Table 24 EB OOOS - Local (TG origination) Element Element Number of Number Characters Event Block Code 0 6 Uni ue Call/Event Identifier 1 26 Call Event Block Se uence Number 82 2 Soft-Switch !D 2 6 Soft Switch Version ID. 50 4 Directional Fla 77 1 Connect Date --" 3 g Connect Time 4 9 Callin Pa Cate o 6 3 Ori inatin Number 7 10 Terminatin NPA/CC 9 5 Terminatin Number (NANP 10 10 Call T a Identification 79 3 In ress Trunkin Gatewa 52 6 In ress Carrier Connect Date 72 8 In ress Carrier Connect Time 13 9 In ress Trunk Grou Number 1 S 4 In ess Circuit Identification 16 4 Code Trunk Grou T a 78 3 In ress Ori inatin Point Code 1 ~ g In ess Destination Point Code 18 9 Jurisdiction Information 30 6 -16$-Table 2$ below provides a definition of event block (EB) 0006. EB 0006 defines Local (TG termination), which can be the logical data set generated for all local calls terminating via a Trunking Gateway to facilities of the PSTN.
Table 25 EB 0006 - Local (TG terminationj Element Element Number of Number Characters Event Block Code 0 6 Uni ue Call/Event Identifier 7 26 Call Event Block Se uence Number 82 2 Soft-Switch ID 2 6 Soft Switch Version ID. $0 4 Directional Fla 77 1 Connect Date 3 8 Connect Time 4 9 Callin Partv Cate o 6 3 Ori inatin Number 7 10 Terminatin NPA/CC 9 $

Terminatin Number (NANP 10 10 Call T a Identification 79 3 Table 26 below provides a definition of event block (EB) 0007. EB 0007 defines Local (AG origination), which can be the logical data set generated for all local calls, originating via an Access Gateway.
Table 26 EB 0007- Local (AG origination]

2$ Etemerrt Element NumberNumber of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. $0 Directional Fla 77 I

Connect Date 3 8 Connect Time 4 9 Callin Pa Cate o 6 3 Ori inatin Number 7 10 Customer Identification 80 12 _ [ Customer Location Identification81 12 J

Table Z6 EB 0007 - Local (AG origination) Element Element NumberNumber of Characters Terminatin NPA/CC 9 Terminatin Number NANP) 10 i0 Call T a Identification 79 3 In ress Access Gatewa 36 7 In ress Trunk Grou Number15 In ress Circuit Identification16 4 Code _ ~ Trunk Group Type ~ 78 3 Table 27 below provides a definition of event block (EB) 0008. EB 0008 defines Local (AG termination), which can be the logical data set generated for all local calls, terminating via an Access Gateway.
Table 27 EB 0008 - Local (AG termination) Element Element Number Number of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. Sp 4 Directional Fla 77 1 Connect Date 3 8 Connect Time Callin Pa Cate o 6 2 Ori inatin Number Terminatin NPA/CC 9 Terminatin Number (NANP 10 10 Call T a Identification 79 3 Table 28 below provides a definition of event block (EB) 0009. EB 0009 defines 8XX/Toll-Free (TG origination), which can be the logical data set generated for Toll-Free (8XX) calls, originating via a Trunking Gateway from facilities of the PSTN.

Table 28 EB 0009 - 8XXlToll Free (TG origination) Element Element Number Number of Characters Event Block Code 0 6 $ Uni ue Call/Event Identifier1 26 Call Event Block Se uence82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. $p Directional Fla 77 1 Connect Date 3 g Connect Time 4 9 Callin Pa Cate o 6 3 Ori inatin Number 7 1 p Dialed NPA 2$ 3 1$ Dialed Number 26 7 Call T a Identification 79 3 In ress Trunkin Gatewa $2 6 In ress Carrier Connect 72 g Date In ress Carrier Connect 13 9 Time In ress Trunk Grou Number1$

In ress Circuit Identification16 Code Trunk Grou T a 7g In ress Ori inatin Point 17 9 Code In ress Destination Point18 9 Code 2$ Table 29 below provides a definition of event block (EB) 00 i 0. EB 0010 defines 8XX/Toll-Free (TG termination), which can be the logical data set generated for Toll-Free (8XX)s calls, terminating via a Trunking Gateway to the facilities of the PSTN.
Table 29 EB 0010 - 8XXlToll Free (TG termination) Element Element Number Number of Characters Event Block Code p 6 Uni ue Call/Event Identifier1 26 Cal) Event Block Se uence82 2 Number 3$ Soft-Switch ID 2 6 Soft Switch Version ID. 5p Directional Fla 77 1 Connect Date 3 g Connect Time 4 g Callin Pa Cate o 6 3 Table 29 EB 0010 - 8XXlToI! Free (TG termination:) Element Element Number Number of Characters Ori inatin Number 7 10 Dialed NPA 25 3 Dialed Number 26 7 Destination NPA/CC 27 5 Destination Number 28 10 Ca(I T a Identification 79 3 Table 30 below provides a definition of event block (EB) 0011. EB 0011 defines 8XX/Toll-Free (AG origination), which can be the logical data set generated for Toll-Free (8XX) calls, originating via an Access Gateway.
Table 30 EB 0011- SXXlT'oll Free (AG origination) Element Element Number Number of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Cal( Event Block Se uence 82 2 Number Soft-Switch 1 D 2 6 Soft Switch Version ID. 5p Directional Fla 77 I

Connect Date 3 8 Connect Time 4 9 Callin Party Cate o 6 3 Ori inatin Number 7 10 ~

Dialed NPA 25 3 Dialed Number 26 7 Call T a Identification 79 3 In ress Access Gatewa 36 7 In ress Trunk Grou Number I S 4 In ress Circuit Identification16 Code Trunk Grou T a 7g 3 Table 31 below provides a definition of event block (EB) 0012. EB 0012 defines 8XX/Toll-Free (AG termination), which can be the logical data set generated for Toll-Free (8XX)s calls, terminating via an Access Gateway.

WO 00!31933 PCT/US99/27658 Table 31 EB 0012 - 8XXlToI! Free (AG termination) Element Element Number Number of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Cal) Event Block Se uence82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. 50 Directional Fla 77 1 Connect Date 3 8 Connect Time 4 9 Callin Pa Cate o 6 3 Ori inatin Number 7 10 Dialed NPA 25 Dialed Number 26 7 Destination Number 28 10 Destination NPA/CC 27 Call T a Identification 79 3 Table 32 below provides a definition of event block (EB) 0013. EB 0013 defines Domestic Operator Services (TG origination). which can be the logical data set generated for all Domestic Operator Assisted calls, originating via a TG.
The actual billing information (which can include the services utilized on the operator services platform (OSP): 3rd party billing, collect, etc.) can be derived from the OSP.
Table 32 EB 0013 - Domestic Operator Services (TG origination) Element Element Number Number of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID $0 Directional Fla 77 I

Connect Date 3 8 Connect Time 4 9 Callin Pa Cate o 6 3 Ori inatin Number 7 10 Customer Identification 80 12 Table 32 EB 0013 - Domestic Operator Services (TC origination) Element Element Number Number of Characters Customer Location Identification8I 12 Terminatin NPA/CC 9 S

Terminatin Number (NANP 10 10 Call T a Identification 79 3 S In ress Trunkin Gatewa 52 6 In ress Carrier Connect 72 g Date In ress Carrier Connect 13 9 Time In ress Trunk Grou Number15 In ress Circuit Identification16 Code Trunk Grou T a 7g 3 In ress Ori inatin Point 17 g Code In ress Destination Point18 9 Code Table 33 below provides a definition of event block (EB) 0014. EB 0014 defines Domestic Operator Services (AG origination), which can be the logical data set generated for all Domestic Operator Assisted calls, originating via an AG.
The actual billing information (which can include the services utilized on the OSP) can be derived from the OSP.

Table 33 _.

EB 0014 - Domestic Operator Services (AC origination) Element Element Number Number of Characters Event Block Code 0 6 Uni ue CalUEvent Identifier1 26 Call Event Block Se uence82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. SO

Directional Fla 77 1 Connect Date 3 8 Connect Time 4 9 Callin Pa Cate o 6 3 Ori inatin Number 7 10 Customer Identification 80 ' 12 Customer Location Identification81 ; 2 Terminatin NPA/CC 9 S

Terminatin Number (NANP) 10 10 Call T a identification 79 3 ~ Ingress Access Gatewa 36 ~

Table 33 EB 0014 - Domestic Operator Services (AG origination) Element Element Number Number of Characters In ress Trunk Grou Number 15 In ress Circuit Identification16 Code ~ Trunk Group Type ~ 78 3 Table 34 below provides a definition of event block (EB) 0015. EB 0015 defines Domestic Operator Services (OSP termination), which can be the logical data set generated for all Domestic Operator Assisted calls, terminating to the OSP. The actual billing information(which can include the services utilized on the OSP) can be derived from the OSP.
Table 34 EB 001 S - Domestic Operator Services (OSP termination) Element Element NumberNumber of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. 50 4 Directional Fla 77 I

Connect Date 3 g Connect Time 4 9 Callin Pa Cate o 6 3 Ori inatin Number 7 Ip Terminatin NPA/CC 9 5 Terminatin Number I0 10 Call T Identification 79 O rator Trunk Grou Number 69 4 O erator Circuit Identification70 4 Code Trunk Grou T a 78 3 Table 35 below provides a definition of event block (EB) 0016. EB 0016 defines International Operator Services (TG origination), which can be the logical data set generated for all International Operator Assisted calls, originated via a TG. The actual billing information(which can include the services utilized on the OSP) can be derived from the OSP.

Tabl e 35 EB 0016 - International ator Services ination) Oper (TG orig Element Element NumberNumber of Characters Event Block Code 0 6 Uni ue Call/Event IdentifierI 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. SO 4 Directional Fla 77 1 Connect Date 3 8 Connect Time 4 9 Callin Pa Cate o 6 3 Ori inatin Number 7 10 Customer Identification 80 12 Customer Location Identification81 12 Terminatin NPA/CC 9 5 Terminatin Number International)74 14 Catl T a Identification 79 3 fn ress Trunkin Gatewa 52 6 In ress Carrier Connect 72 g Date In ress Carrier Connect 13 9 Time In ress Trunk Grou Number I S 4 In ress Circuit Identification16 4 Code Trunk Grou T a 7g 3 In ress Ori inatin Point I7 9 Code In ress Destination Point 18 9 Code Table 36 below provides a definition of event block (EB) 001 7. EB 0017 defines International Operator Services (AG origination), which can be the logical data set generated for all International Operator Assisted calls, originated via an AG. The actual billing information(which will include the services utilized on the OSP) can be derived from the OSP.
Table 36 EB 0017- Internatioi:al Operator Services (AG
origination) Element Element NumberNumber of Characters Event Block Code 0 6 Uni ue Call/Event IdentifierI 26 Calt Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version 1D. 50 4 Table 36 EB 0017- International Operator Services (AG
origination) Element Element NumberNuntber of Characters Directional Fla 77 1 Connect Date 3 8 Connect Time 4 Callin Pa Cate o 6 3 Ori inatin Number 7 10 Customer Identification 80 12 Customer Location Identification81 12 Terminatin NPA/CC 9 5 Terminatin Number (International74 14 Call T a Identification 79 3 In ress Access Gatewa 36 6 In ress Trunk Grou Number 15 4 In ress Circuit Identification16 4 Code Trunk Grou T a 78 3 i 5 Table 3 7 below provides a definition of event block (EB) 0018. EB 0018 defines International Operator Services (OSP termination), which can be the logical data set generated for all International Operator Assisted calls.
terminating to the OSP. The actual billing information(which will include the services utilized on the OSP) can be derived from the OSP.
Table 37 EB U018 - International Operator Services (OSP
termination) Element Element NumberNumber of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. Sp 4 Directional Fla 77 1 Connect Date 3 8 Connect Time 4 9 Callin Pa Cate o 6 3 Ori inatin Number 7 10 Terminatin NPA/CC 9 S

Terminatin Number International74 10 Call T Identification 79 3 O rator Trunk Grou Number 69 4 Table 37 EB 0018 - International Operator Services (OSP
termination) Element Element NumberNumber of Characters O erator Circuit Identification70 Code Trunk Grou T a 7g 3 Table 38 below provides a definition of event block (EB) 0019. EB 0019 defines Directory Assistance/555-I 212 (TG origination), which can be the logical data set generated for 555-1212 calls, originating via a TG from the PSTN.
Table 38 EB 0019 - Directory AssistancelSSS-1212 (TC origination) Element Element NumberNumber of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. SO 4 Directional Fla 77 1 Connect Date 3 8 Connect Time 4 9 Callin Pa Cate o 6 3 Ori inatin Number 7 10 Customer Identification 80 12 Customer Location Identification81 12 Terminatin NPA/CC 9 5 Call T a Identification 79 In ress Trunkin Gatewa 52 In ress Carrier Connect 72 g Date In ress Carrier Connect 13 g Time In ress Trunk Grou Number 15 4 In ress Circuit Identification16 Code Trunk Grou T a 7g 3 In ress Ori inatin Point 17 9 Code In ress Destination Point 18 9 Code Table 39 below provides a definition of event block (EB) 0020. EB 0020 defines Directory Assistance/555-1212 (AG origination), which can be the logical data set generated for 555-12I2 calls, originating via an AG on a DAL.

WO 00/31933 PC'T/US99/27658 Table 39 EB OU20 - Directory AssistancelSSS-1212 (AG origination) Element Element NumberNumber of Characters Event Block Code 0 6 Uni ue Call/Event IdentifierI 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. 50 4 Directional Fla ~~ 1 Connect Date 3 g Connect Time 4 9 Callin Pa Cate o 6 3 Ori inatin Number 7 1 p Customer Identification 80 12 Customer Location Identification81 12 Terminatin NPA/CC 9 Cali T a Identification 79 3 In ress Access Gatewa 36 6 In ress Trunk Grou Number 15 4 In ress Circuit Identification16 4 Code Trunk Grou T a 78 3 Table 40 below provides a definition of event block (EB) 0021. EB 0021 defines Directory Assistance/555-1212 (Directory Assistance Services Platform (DASP) termination), which can be the logical data set generated for 555-1212 calls, terminating to the DASP.
Tabte 40 EB 0021- Directory AssistancelSSS-1212 (RASP termination) Element Number Number of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. 50 4 Directional Fla T7 I

Connect Date 3 g Connect Time 4 9 Callin Pa Cate o 6 3 Ori inatin Number 7 I p Terminatin NPA/CC 9 Table 40 EB 0021- Directory AssistancelSSS-1212 (DASP termination) Element Element NumberNumber of Clraracters Call T a Identification 79 3 In ress Access Gatewa 3( DA Trunk Grou Number 75 4 DA Circuit Identification 76 4 Code Trunk Grou T a 7g Table 41 below provides a definition of event block (EB) 0022. EB 0022 defines OSP/DASP Extended Calls (Domestic), which can be the logical data set generated for all Domestic Operator and Directory Assisted calls that are extended back to telecommunications network 200 for termination.
Table 41 EB 0022 - OSPlDASP Extended Calls (Domestic) Element Element Number Number of Characters Event Block Code 0 6 Uni ue Call/Event IdentifierI 26 IS Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. 50 Directional Fla 77 1 Connect Date 3 8 Connect Time Callin Pa Cate o 6 3 Ori inatin Number 7 10 Overseas Indicator g Terminatin NPA/CC 9 Terminatin Number (NANP) 10 10 Call T a Identifcation 79 3 In ress Trunkin Gatewa 52 6 In ss Carrier Connect Date 72 g In ress Carrier Connect 13 9 Time In ress Trunk Grou Number In ress Circuit Identification16 Code Trunk Grou T 78 3 Table 42 below provides a definition of event block (EB) 0023. EB 0023 defines OSP/ DASP Extended Calls (International), which can be the logical data set generated for all International Operator and Directory Assisted calls that are extended back to the telecommunications network 200 for termination.
Table 42 EB 0023 - OSPlDASP Extended Calls (International) S Element Element Number Number of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. $0 4 Directional Fla 77 1 Connect Date 3 g Connect Time 4 9 Callin Pa Cate o 6 3 1 S Ori inatin Number 7 10 Overseas Indicator g 2 Terminatin NPA/CC 9 $

Terminatin Number International)74 14 Call T a Identification 79 In ress Trunkin Gatewa $2 In ress Carrier Connect 72 g Date In ress Carrier Connect 13 9 Time In ress Trunk Grou Number 15 4 In ress Circuit Identification16 4 Code Trunk Grou T a 78 3 Table 43 below provides a definition of event block (EB) 0024. EB 0024 defines International Toll (TG Origination), which can be the logical data set generated for all International Long Distance calls, originating via a Trunking Gateway from facilities of the PSTN. Typically, these calls can be PIC-calls, originating over FGD facilities.
Table 43 EB 0024 - International Toll (TG Origination) Element Element Number Number of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Table 43 EB 0024 - International Toll (TG Origination) Element Element Number Number of Characters Soft-Switch 1D 2 6 Soft Switch Version ID 50 4 Directional Fla 77 1 Connect Date 3 8 Connect Time 4 g Callin Pa Cate o 6 3 Ori inatin Number 7 10 Customer Identification 80 12 Customer Location Identification81 12 Overseas Indicator g 2 Terminatin NPA/CC g Terminatin Number Intl.) 74 1.4 Call T a Identification 79 3 Carrier Selection Information51 2 Carrier Identification 12 4 Code In ress Trunkin Gatewa 52 6 In ress Carrier Connect 13 9 Time In ess Trunk Grou Number I S 4 In ress Circuit Identification16 4 Code In ress Ori inatin Point 17 g Code In ress Destination Point 18 9 Code Jurisdiction Information 30 Trunk Grou T a 78 3 Table 44 below provides a definition of event block (EB) 0025. EB 0025 defines International Toll (AG Origination), which can be the logical data set generated for all International Long Distance calls, originating via an Access Gateway.
Table 44 EB 0025 - International Toll (AG Origination) Element Element Number Number of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. 50 4 Directional Fla 77 1 Connect Date 3 8 Table 44 EB 0025 - International Toll (AG Origination) Element Element Number Number of Characters Connect Time 4 g Callin Part Cate o 6 3 Ori inatin Number 7 10 Customer Identification 80 12 Customer Location Identification81 12 Overseas Indicator g 1 Terminatin NPA/CC 9 5 Terminatin Number Intl. 74 14 Call T a Identification 79 3 Carrier Selection Information$1 2 Carrier Identification 12 4 Code In ress Access Gatewa 36 6 In ress Trunk Grou Number 15 4 In ress Circuit Identification16 4 Code Trunk Grou T a 78 3 Table 45 below provides a definition of event block (EB) 0026. EB 0026 defines International Toll (TG Termination). which can be the logical data set generated for all International Long Distance calls terminating via a Trunking Gateway to facilities of the PSTN.
Table 45 EB 0026 - International Toll (TG Termination) Element Element Number Number of Characters Event Block Code 0 6 Uni ue CalllEvent Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. $0 4 Directional Fla 77 1 Connect Date 3 8 Connect Time 4 Callin Pa Cate o 6 3 Ori inatin Number 7 10 Table 45 EB 0026 - lnternatior:al Toll (TG Termination) Element Element Number Number of Characters Overseas Indicator g 1 Terminatin NPA/CC 9 S

Terminatin Number (Intl. 74 14 Call T a Identification 79 S Carrier Identification Code12 4 Jurisdiction Information 30 Trunk Grou T a 7g 3 Table 46 below provides a definition of event block (EB) 0027. EB 0027 defines International Toll (AG Termination), which can be the logical data set generated for all International Long Distance calls, terminating via an Access Gateway to a DPL or PRI.
Table 46 EB 0027- International Tnl! (AG Termination) Element Element Number Number of Characters 1 S Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence ! 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. SO 4 Directional Fla ~ 77 1 Connect Date Connect Time 4 9 Cailin Pa Cate o 6 3 Ori inatin Number 7 10 2S Overseas Indicator g 1 Terminatin NPA/CC g Terminatin Number (Intl.) 74 14 Cail T Identification 79 3 Carrier Identification 12 4 Code Trunk Grou T a 7g 3 Table 47 below provides a definition of event block (EB) 0040. EB 0040 defines IP Origination, which can be the logical data set generated for ALL IP
originations.

Table 47 EB 004U - IP Origination Element Element Number Number of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. 50 4 Directional Fla 77 1 Connect Date 3 g Connect Time 4 9 Ori inatin Number 7 Customer Identification 80 12 Customer Location Identification81 12 Terminatin NPA/CC 9 Terminatin Number 10 10 Call T identification 79 3 Ori inatin IP Address 63 12 In r. Securi Gatewa IP Address65 12 ~ Ingress Firewall IP Address67 12 ~

Table 48 below provides a definition of event block (EB) 0041. EB 0041 defines IP Termination, which can be the logical data set generated for ALL IP
terminations.
Table 48 EB 0041- IP Termination Element Element Number Number of Cl:aracters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. SO 4 Directional Fla 77 1 Connect Date 3 g Connect Time 4 9 Ori inatin Number 7 10 Terminatin NPA/CC 9 5 Terminatin Number (NANP 10 I O

Call T a Identification 79 3 Terminatin IP Address 64 12 E r. Securi Gatewa IP Address66 12 ~ Egress Firewall IP Address68 j 12 ~

(b) Example Augmenting Event Block (EBs) Definitions Table 49 below provides a definition of event block (EB) 0050. EB 0050 defines a Final Event Block, which can be used as the FINAL Event Block for ALL calls/events. It signifies the closure of a call/event.
Table 49 EB OOSO - Fir:al Event Block Element Element NumberNumber of Characters Event Block Code 0 Uni ue Call/Event Identifier 1 26 Call Event Block Se uence Number 82 Soft-Switch ID 2 6 Soft Switch Version ID. SO 4 Directional Fla ~~ 1 End Date 40 g End Time 39 9 Ela sed Time I 1 10 Audio Packets Sent Sg g Audio Packets Received 6p g Audio Packets Lost 61 g Audio B tes Transferred 62 g Table 50 below provides a definition of event block (EB) 0051. EB 0051 defines Answer Indication, which can be used as to indicate whether or not a call/session was answered or unanswered. If the cal I was unanswered, the Answer Indicator element will indicate that the call was not answered and the Answer Time element will contain the time that the originating party went on-hook.
--Table 50 EB OOSI - Answer Indication Element Element Number Number of Ckaracters Event Block Code 0 Uni ue Call/Event Identifier1 26 Call Event Block Se uence g2 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. SO 4 Table 50 EB OOSI - Answer Indication Element Element Number Number of Characters Directional Fla ~~ 1 Answer Indicator 5 I

Answer Date 41 g Answer Time 42 g Table 5 I below provides a definition of event block (EB) 0052. EB 0052 defines Ingress Trunking Disconnect Information which can contain Ingress Ttunking Disconnect information. The release date and time of the ingress circuit used in the call can be recorded. This EB can be extremely important to downstream systems (i.e. cost analysis/CABS analysis) that may need to audit the bills coming from LECs/CLECs/Carriers.

Table 51 ..__.'-.-EB OOS2 - Ingress Trunking Disconnect Information Element Element Number Number of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. 50 4 Directional Fla ~~ I

In ress Carrier Disconnect 44 g Date in ress Carrier Disconnect 43 g Time Table 52 below provides a definition of event block (EB) 0053. EB 0053 defines Egress Trunking Disconnect Information, which can contain Egress Trunking Disconnect information. The release date and time of the egress circuit used in the call can be recorded. This EB can be extremely important to downstream systems (i.e. cost analysis/CABS analysis) that can need to audit the bills coming from LECs/CLECs/Carriers.

Table 52 EB 0053 - Egress Trunking Disconnect Information Element Element Number Number of Cl:aracters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. 50 4 Directional Fla 77 1 E ress Carrier Disconnect 46 8 Date E ress Carrier Disconnect 45 9 Time Table 53 below provides a definition of event block (EB) 0054. EB 0054 defines Basic 8XX/Toll-Free SCP Transaction Information, which can be used for all basic toll-free (8XX) SCP transactions.
Table 53 EB OOS4 - Basic 8XXlToll-Free SCP Transaction Information Element Element Number Number of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. 50 4 Directional Fla 77 1 Transaction Identification31 9 Database Identification 34 3 Transaction Start Time 32 9 Transaction End Time 33 g Carrier Selection Information51 2 Carrier Identification 12 4 Code Overseas Indicator g Destination NPA/CC 27 5 Destination Number 28 10 Customer Identification 80 12 Customer Location Identification81 12 Alternate Bitlin Number 29 10 Table 54 below provides a definition of event block (EB) 005. EB 0055 defines Calling Party (Ported) Information, which can be used to record information in regards to a Calling Party Number that has been ported.
Table 54 EB OOSS - Calling Party (Ported) Information Element Element Number Number of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. 50 4 Directional Fla 77 1 Location Routin Number 48 I I

~ LRN Supporting Information49 ~ 1 ~

I S Table 55 below provides a definition of event block (EB) 0056. EB 0056 defines Called Party (Ported) Information, which can be used to record information in regards to a Called Party Number that has been ported.
Table 55 EB OOS6 - Called Party (Ported) Information Element Element Number Number of Characters Event Block Code 0 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. SO 4 Directional Fla 77 Location Routin Number 48 11 LRN Su rtin Information 49 I

Table 56 below provides a definition of event block (EB) 0057. EB 0057 defines Egress Routing Information (TG termination), which can be used to record the egress routing information (i.e., terminating via the PSTN).

Table 56 EB OOS7- Egress Routinb Information (TG termination) Element Element Number Number of Characters Event Block Code 0 6 $ Uni ue Call/Event IdentifierI 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. SO 4 Directional Fla 77 I

E ress Routin Selection 54 2 E ress Trunkin Gatewa 53 6 E ress Carrier Connect 73 g Date E ress Carrier Connect 19 9 Time E ress Trunk Grou Number 21 4 E ress Circuit Identification22 4 Code Trunk Grou T a 78 3 E ress Ori inatin Point 23 9 Code E ress Destination Paint 24 9 Code Table 57 below provides a definition of event block (EB) 0058. EB 0058 def nes Routing Congestion Information, which can be used to record routes/ttunks that were unavailable (e.g., due to congestion, failure, etc.) during the route selection process in soft switch 204. EB 0057 (for TG termination) and EB 0060 (for AG termination) can be used to record the ACTUAL route/trunk used to terminate the call. This information can be extremely valuable to, for example, traffic engineering, network management, cost analysis.
Table 57 EB OOSB - Routing Congestion Information Element Element Number Number of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 CaII Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. 50 4 Directional Fla 77 1 Routin Attem t Time 57 9 Routin Attem t Date 58 g E ress Routin Selection 54 2 E ress Trunkin Gatewa 53 6 Table 57 EB OOSB - Routing Congestion Information Element Element Number Number of Characters E ress Trunk Grou Number 21 4 Con estion Code 55 2 Table 58 below provides a definition of event block (EB) 0059. EB 0059 defines Account Code Information, which can be used for all calls requiring account codes.
Table 58 EB OOS9 - Account Code Injormatiorr Element Element Number Number of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. 5p 4 Directional Fla 7~ I

Account Code T a 71 1 Account Code 38 14 Account Code Validation 56 1 Fla Table 59 below provides a definition of event block (EB) 0060. EB 0060 defines Egress Routing Information (for AG termination), which can be used to record the egress routing information (i.e., terminating via an AG).
__ _ Table 59 EB 0060 - Egress Routing Information (AG termination) Element Element Number Number of Event Block Code 0 Characters 2~ Uni ue Call/Event IdentifierI 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. 50 4 Directional Fla 77 1 E ress Routin Selection 54 2 Table 59 EB 0060 - Egress Routing Injorntation (AG termination) Element Element Number Number of Characters E ress Access Gatewa 37 6 E ress Carrier Connect Date73 $

E ress Carrier Connect Time19 E ress Trunk Grou Number 21 4 E ress Circuit Identification22 4 Code Trunk Grou T a 78 3 Table 60 below provides a definition of event block (EB) 006I . EB 0061 defines Long Duration Call Information, which can be used to record a timestamp of long duration calls. Soft switch 204 can generate this block when a call has been up for a duration that spans over two midnights. Subsequent LDCI EBs can be generated after each additional traverse of a single midnight. As an example, if a call has been up from 11:52 pm on Monday, through 4:17 pm on Thursday (of the same week). then TWO EB 0061 s can be generated for the call. One can be generated at midnight on Tuesday. the other can be generated at midnight on Wednesday.
Table 60 EB 0061- Long Duration Call Information Element Element NumberNumber of Characters Event Block Code 0 6 Uni ue Call/Event Identifier1 26 Call Event Block Se uence 82 2 Number Soft-Switch ID 2 6 Soft Switch Version ID. SO 4 Directional Fla 77 I

Lon Duration Sequence Number_ 2 _ 83 Lon Duration Event Time 84 9 Lon Duration Event Date 85 8 (3) Example Element Definitions Elements are the building blocks of Event Blocks (EBs). Event Blocks are logical groupings of elements. Each element can contain information that is collected during call/event processing, whether from, for example, signaling messages, external databases (SCPs and intelligent peripherals (IPs}), Access GTGs, customer attributes, or derived by a soft switch. All of the elements contain information that is used by various downstream systems. Downstream systems include, forexample, billing/mediation, traffic engineering, carrieraccess billing, statistical engines, cost analysis engines, and marketing tools.
Example Call Elements include the following:
Element 0 - Event Block Code;
Element 1 - Unique Call/Event Identifier;
Element 2 - Soft-Switch ID;
Element 3 - Connect Date;
Element 4 - Connect Time;
Element 5 - Answer Indicator;
Element 6 - Calling Party Category;
Element 7 - Originating Number;
Element 8 - Overseas Indicator;
Element 9 - Terminating NPA/CC;
Element 10 - Terminating Number;
Element 11 - Elapsed Time;
Element 12 - Carrier Identification Code;
Element 13 - Ingress Carrier Connect Time;
Element 14 - Ingress Carrier Elapsed Time;
Element 15 - Ingress Trunk Group Number;
Element 16 - Ingress Circuit Identification Code;
Element 17 - Ingress Originating Point Code;
Element 18 - Ingress Destination Point Code;
Element 19 - Egress Carrier Connect Tirne;
Element 20 - Egress Carrier Elapsed Time;

Element 21 - Egress Trunk Group Number;
Element 22 - Egress Circuit Identification Code;
Element 23 - Egress Originating Point Code;
Element 24 - Egress Destination Point Code;
Element 25 - Dialed NPA;
Element 26 - Dialed Number;
Element 27 - Destination NPA/CC;
Element 28 - Destination Number;
Element 29 - Alternate Billing Number;
Element 30 - Jurisdiction Information;
Element 31 - Transaction Identification;
Element 32 - Transaction Start Time;
Element 33 - Transaction End Time;
Element 34 - Database Identification:
Element 36 - Ingress Access Gateway;
Element 37 - Egress Access Gateway;
Element 38 - Account Code;
Element 39 - End Time;
Element 40 - End Date;
Element 41 - Answer Date;
Element 42 - Answer Time;
Element 43 - Ingress Carrier Disconnect Time;
Element 44 - Ingress Carrier Disconnect Date;
Element 45 - Egress Carrier Disconnect Time;
Element 46 - Egress Carrier Disconnect Date;
Element 47 - Announcement Identification;
Element 48 - Location Routing Number;
Element 49 - LRN Supporting Information;
Element 50 - Soft Switch Version;
3fl Element 51 - Carrier Selection Information;
Element 52 - Ingress Trunking Gateway;

W4 00/31933 PCT/US99/2~658 Element 53 - Egress Trunking Gateway;
Element 54 - Egress Routing Selection;
Element 55 - Egress Route Congestion Code;
Element 56 - Account Code Validation Flag;
Element 57 - Routing Attempt Time;
Element SS - Routing Attempt Date;
Element 59 - Audio Packets Sent;
Element 60 - Audio Packets Received;
Element 6I - Audio Packets Lost;
Element 62 - Audio Bytes Transferred;
Element 63 - Originating IP Address;
Element 64 - Terminating IP Address;
Element 6S - Ingress Security Gateway IP Address;
Element 66 - Egress Security Gateway IP Address;
1 S Element 67 - Ingress Firewall IP Address;
Element 68 - Egress Firewall iP Address;
Element 69 - Operator Trunk Group Number;
Element 70 - Operator Circuit Identifccation Code;
Element 71 - Account Code Type;
Element 72 - Ingress Carrier Connect Date;
Element 73 - Egress Carrier Connect Date;
Element 74 - Terminating Number (International);
Element 75 - DA Trunk Group Number;
Element 76 - DA Circuit Identification Code;
Element 77 - Directional Flag;
Element 78 - Trunk Group Type;
Element 79 - Call Type Identification;
Element 80 - Customer Identification;
Element 8I - Customer Location Identification;
Element 82 - Call Event Block Sequence Number;
Element 83 - Long Duration Sequence Number;

Element 84 - Long Duration Event Time; and Element 85 - Long Duration Event Date.
(4) Element Definitions Element definitions recorded during call processing are defined in this section.
Table 61 below provides a definition of element 0. Element 0 defines an Event Block Code element, which contains a code that can be mapped/correlated to a type of call/event. The EB code can be used for parsing and data definition for downstream systems.
An example of this element follows: EB0012.
Table 61 Element 0 - Event Block Code ASCII Cl:aracters Meanin I-2 EB constant) 3-6 Event Block Code Table 62 below provides a definition of element 1. Element 1 defines an Unique Call/Event Identifier (UCEI), which can be used to correlate all events (EBs} for a particular call/session. The correlation can be done in the MNEDB.
An example of this element follows: BOS00219980523123716372001.
Table 62 _ __-Element 1- Unique CalUEvent Identifier (UCEI) ASCII Cl:aractersMeanin I-3 Site Identification 3-6 Node Identification 7- I 4 Date IS-23 Connect Time 24-26 Se uence Number*
* a CPf111Pf11i0I.....r7,17____ J
n ~~e...._ - ..-~..-.._.». ..,.....",. ~r,,, """,~~~~nu ~ms~~ rrom u-yyN can be incremented, then appended to each UCEI. This will allow differentiation ofcalls/events that are processed at the same Site, on the same Node (soft switch), on the same date, at exactly the same time(down to the ms).

WO 00/31933 PCT/US99l27658 Table 63 below provides a definition of element 2. Element 2 defines a Soft-Switch ID element, which contains the soft switch identification number.
This can indicate which soft switch recorded the call event data.
An example of this element follows: BOS003.
Table 63 Element 2 - Soft Switch ID

ASCII CharactersMeanin 1-3 Three Letter Ci ID

4-6 Soft Switch Number Table 64 below provides a definition of element 3. Element 3 defines a Connect Date element, which contains the date when the call was originated.
An example of this element follows: 19980430.
Table 64 Elemenr 3 -Connect Date ASCII CharactersMeanin 1-4 Year 5-6 Month 7-8 Da Table 65 below provides a definition of element 4. Element 4 defines a ~0 Connect Time element, which contains the time when the soft switch received an IAM.
An example of this element follows: 125433192.
Table 65 Elemer:t 4 -Connect Time ASCII CharactersMeanin 1-2 Hours 3-4 Minutes S-6 Seconds Milliseconds Table 66 below provides a definition of element 5. Element 5 defines an Answer Indicator element, which states whether or not a call/session was answered/unanswered.
An example of this element follows: 1.
Table 66 Element S - Answer Indicator ASCII CharactersMeanin I 0 = Answered ( = Unanswered Table 67 below provides a definition of element 6. Element 6 defines a Calling Party Category element. which contains whether a call was originated from, for example, a Hotel, a Prison. a Cell Phone. a pay phone, a PVIPS, and an inward wide area telephone service (INWATS), based on the Calling Party Category received in the Initial Address Message (IAM), derived from a soft switch, or received from a database external from the soft switch.
An example of this element follows: 1.
Table 67 Element 6 -Calling Party Category ASCII CharactersMeanin 1-3 000 = PVIPS

001 = Pre a Coin 002 = Hotel/Motel 003 = IP Phone 008 = INWATS Terminatin OI 8 = Prison Table 68 below provides a definition of element 7. Element 7 defines an Originating Number element, which contains the NPA NXX-XXXX (DN) that originated the call.
An example of this element follows: 3039263223.

Table 68 Element 7 - Originatii:~
Number ASCll Cl:aractersMeanin 1-10 Ori inatin Number Table 69A below provides a definition of element 8. Element 8 defines an Overseas Indicator element, which provides the digit length of an overseas call. as well as whether or not an NPA was dialed or implied/derived from the soft switch. This element is crucial to downstream systems (i.e., billing/mediation) which need to differentiate between NPAs and CCs.
An example of this element follows: O 1 D.
Table 69A

Element 8 - Overseas Indicator ASCII CharactersMeanin 1-2 00 = NPA Dialed B the Customer not an overseas call) 01 =NPA Im lied/Derived B Soft Switch 02 = Non-North American Numberin Plan Termination 03 = 7 Di it Overseas Number 04 = 8 Di it Overseas Number OS = 9 Di it Overseas Number 06 = 10 Di it Overseas Number 07 = 11 Di it Overseas Number 08 = 12 Disit Overseas Number 09 = 13 Di it Overseas Number 10 = 14 Di it Overseas Number 11 = 15 Disit Overseas Number Table 69B below provides a definition of element 9. Element 9 defines a Terminating Numbering Plan Area/Country Code (NPA/CC) element, which contains either the NPA of the dialed number for domestic calls, or up to five characters of the overseas number dialed. Today, country codes (CCs} can be up to 3 digits and the national significant number can be up to 14 digits (since December 31,1996), for a total of no more than 15 digits. If the call is domestic, the first two characters can be 00(padding), the next three characters can be the NPA, and the last character can be the delimiter.
An example of this element follows: 00303D.

w0 00/31933 PCT/US99/27658 Table 69B

Element 9 - Terminrttin~
Numbering Plan ArealCountry Code NPAlCC

ASCII Cl:aractersMeanin I-2 Overseas Ex ander Positions NPA

Table 69C below provides a definition ofelement I 0. Element 10 defines a Terminating Number North American Numbering Plan (NANP) element, which contains the NXX-LINE of the dialed number for domestic calls. The terminating number element should be populated for ALL calls that require a terminating number for billing.
An example of this element follows: 9263223.
Table 69C

Element IO -Terminating Number North American Numbering Plan (NANP) ASCII CharactersMeanin Four Di it Line Number Table 70 below provides a definition of element 11. Element I I defines an Elapsed Time element, which contains the elapsed time (duration) of a completed call/session. The time can be GMT.
An example of this element follows: 123716372 i Table 70 Element ll -Elapsed Time ASCII CharactersMeanin I-2 Hours 4-5 Minutes 6-7 Seconds 8-10 ~ Milliseconds Table 71 below provides a definition of element 12. Element 12 defines a Carner Identification Code element, which contains the toll carrier's identification code. This can be an extremely useful element for downstream systems (i.e. billing), that need to parse records for wholesale customers!

An example of this element follows: 0645 Table 71 Element 12 - Carrier Identification Code ASCII Characters Meanin 1-4 Carrier Identification Code Table 72 below provides a definition of element 13. Element 13 defines an Ingress Carner Connect Time element, which contains the time that the ingress trunk/circuit was seized for a call, that is, when an ACM was sent towards the PSTN. This element can be important to downstream systems (i.e. cost analysis/CABS analysis) that may need to audit the bills coming from LECs/CLECs/Carriers.
An example of this element follows: 123716372 Table 72 Element 13 -Ingress Carrier Connect Time ASCII CharactersMeanin 1-2 Hours 3-4 Minutes 5-6 Seconds Milliseconds Table 73 below provides a definition of element 14. Element 14 defines an Ingress Carrier Elapsed Time element, which contains the elapsed time(duration) that the ingress trunk/circuit was in use(from seizure to release) for both answered and unanswered calls/sessions. This element can be important to downstream systems (i.e. cost analysis/CABS analysis) that may need to audit the bills coming from LECs/CLECs/Carners.
An example of this element follows: 123716372.

Table 73 Element 14 -Ingress Carrier Elapse ASCII Cl:aractersMeattin I -2 Hours Minutes 5-6 Seconds Milliseconds Table 74 below provides a definition of element 15. Element 15 defines an Ingress Trunk Group Number element. which contains the Trunk Number on the originating/ingress side of a call. The information can be derived from either TG or AG, or from a correlation table, using Element 16 - Ingress Circuit Identification Code, Element 17 - Ingress Originating Point Code, and Element 18 - Ingress Destination Point Code, to correlate to a specific trunk group.
This element can be important to downstream systems (i.e. cost analysis/CABS
analysis) that may need to audit the bills coming from LECs/CLECs/Carriers.
This can also assist traffic engineers in trunk sizing.
An example of this element follows: 1234.
Table 74 Element !S -Ingress Trunk Group Number ASCll ClearactersMeanin I-4 Trunk Grou Number Table 75 below provides a definition of element 16. Element 16 defines an Ingress Circuit Identification Code element, which contains the circuit number/id of the circuit used on the originating/ingress side of a call. The information can be derived from either TG or AG. or from the Circuit Identification Code (CIC) field in the IAM.
An example of this element follows: 0312 Table 75 Element 16 - Ingress Circuit Identification Code 3~ ASCII Charnr~m.~~ 11.~A....:»,.

Table 75 Element 16 - Ingress Circuit Identification Code I-4 Ctrcutt Identification Code/Trunk Member Number Table 76 below provides a definition of element 17. Element 17 defines an Ingress Originating Point Code (IOPC) element, which contains the ingress OPC.
An example of this element follows: 212001001.
Table 76 Element 17-Ingress Originating Pint Code ASCII CharactersMeanin I-3 Network (0-255) 4-6 Cluster (0-255 7-9 Member 0-255 Table 77 below provides a definition of element 18. Element 18 defines an Ingress Destination Point (IDC) Code.
An example of this element follows: 213002002.
Table 77 ----_,__._ Element 18 -Ingress Destination Point Code ASCII CharactersMeanin I-3 Netw_o_rk (0-255 4-6 Cluster (0-255 7-9 Member (0-255) Table 78 below provides a definition of element 19. Element I 9 defines an Egress Carrier Connect Time element, which contains the time that the egress trunk/circuit was seized for a call. The time can be derived from the Access or Trunking Gateways, or from the Initial Address Message. This element can be important to downstream systems (i.e. CABS) that need this information to BILL
other LECs/CLECs/Carriers.
An example of this element follows: 123716372.

Table 78 Element l9 -Egress Carrier Connect Time ASCII Cl:aractersMeanin 1-2 Hours Minutes 5-6 Seconds Milliseconds Table 79 below provides a definition of element 20. Element 20 defines an Egress Carrier Elapsed Time element, which contains the elapsed time (duration) that the egress trunk/circuit was in use (from seizure to release) for both answered and unanswered calls/sessions. This element can be important to downstream systems (i.e. CABS) that need this information to BILL other LECs/CLECs/Carriers.
An example of this element follows: 123716372.
' Table 79 Element 20 -Egress Carrier Elapse! Time ASCII CharactersMeanin 1-2 Hours 3-4 Minutes 5-6 Seconds M~ll~seconds Table 80 below provides a definition of element 21. Element 21 def nes an Egress Trunk Group Number element, which contains the Trunk Number on the terminating/egress side of a call. The information can be derived from either TG or AG, or from a correlation table, using Element 22 - Egress Circuit Identification Code, Element 23 - Egress Originating Point Code, and Element - Egress Destination Point Code, to correlate to a specific trunk group. This element can be important to downstream systems (i.e. cost analysis/CABS
analysis) that may need to audit the bills coming from LECs/CLECs/Carriers.
An example of this element follows: 4321.

WO 00/31933 PCI'/US99/27658 Table 80 Element 2! -Egress Trunk Group Number ASCII CharactersMeanin I-4 Trunk Grou Number Table 81 below provides a definition of element 22. Element 22 defines an Egress Circuit Identification Code element, which contains the circuit number/id of the circuit used on the terminating/egress side of a call. The information can be derived from either TG or AG, or from the Circuit Identification Code (CIC) field in the IAM message.
An example of this element follows: 0645.
Table 81 Element 22 -Egress Circuit Identification Cole ASCII CharactersMeanin I-4 Circuit Identification Code/Trunk Member Number Table 82 below provides a definition of element 23. Element 23 defines an Egress Originating Point (EOP) Code.
An example of this element follows: 212001001.
Table 82 Element 23 -Egress Originating Point Code ASCII CharactersMeanin I-3 Network (0-255 4-6 Cluster (0-255 Member (0-255 Table 83 below provides a definition of element 24. Element 24 defines an Egress Destination Point (EDP) Code.
An example of this element follows: 213002002.

Table 83 Element 24 - Egress Destination Point Code ASCII Characters Meaning I-3 Network (0-255) Cluster (0-255 Member (0-2551 Table 84 below provides a definition of element 25. Element 25 defines a Dialed NPA element, which contains the 8XX code for a toll-free call.
An example of this element follows: $88.
[ Table 84 II Element 1S - Dialed NPA

Table 85 below provides a definition of element 26. Element 26 defines a Dialed Number element, which contains the NXX-LINE of the dialed number for domestic toll-free calls. The terminating number element has seven significant characters and a sign (delimiter) character.
An example of this element follows: 4532609.
__ Table 85 Element 26 - Dialed Number ASCII Characters Meanin Four Di it Line Number Table 86 below provides a definition of element 27. Element 27 defines a Destination NPA/CC element, which contains the Numbering Plan Area (NPA) for domestic calls and the Country Code (CC) for international calls. This information is SCP derived for 8XX calls. The element is right justified and padded (with Os) if necessary.
An example of this element follows: 00303D.

Table 86 Element 27 -Destination NPAlCC

ASCII Cl:aractersMeanin 1-2 Overseas Ex ander Positions Table 87 below provides a definition of element 28. Element 28 defines a Destination Number element, which contains the NXX-LINE ofthe destination number for domestic toll-free calls. This number is the routing number returned from a SCP 800 query. The terminating number element has seven signif cant characters and a sign (delimiter) character. The terminating number element should be populated for ALL calls that require a terminating number for billing.
An example of this element follows: 9263223D.
Table 87 Element 28 - Destination Number I S ASCII Characters Meanin Four Di it Line Number Table 88 below provides a definition of element 29. Element 29 defines an Alternate Billing Number field element, which contains the billing number obtained from the optional billing number data received from SCP.
An example of this element follows: 3039263223D.
Table 88 Element 29 -Alternate Billing Number ASCII CharactersMeanin 1-l0 Alternate Billin Number Table 89 below provides a definition of element 30. Element 30 defines a Jurisdiction Information element, which contains the NPA-NXX of the originating Switch. This information can be contained in the Initial Address Message.

An example of this element follows: 303926D.
Table 89 Element 30 -Jurisdiction Information ASCII CharactersMeanin 7 Delimiter Table 90 below provides a definition of element 31. Element 31 defines a Transaction Identification element, which contains a unique identification number for each external request to a SCP, an Intelligent Peripheral (IP), or some other database.
An example of this element follows: 0000012673.
Table 90 Element 31-Transaction Identification ASClI CharactersMeanin 1-9 Transaction ID

Table 91 below provides a definition of element 32. Element 32 defines a Transaction Start Time element, which contains the time that the Soft Switch sent an external request to an SCP, an Intelligent Peripheral (IP); or some other database.
An example of this element follows: 124312507.
Table 91 Element 32 -Transaction Start Time ASCII CharactersMeanin 1-2 Hours 3-4 Minutes 5-6 Seconds Milliseconds Table 92 below provides a definition of element 33. Element 33 defines a Transaction End Time element, which contains the time that the Soft Switch received a response from an external request to a SCP, an Intelligent Peripheral (IP), or some other database.
An example of this element follows: 102943005.
Table 92 Element 33 -Transaction End Time ASCII CharactersMeanin 1-2 Hours 3-4 Minutes 5-6 Seconds 7-9 Milliseconds ' Table 93 below provides a definition of element 34. Elemem 34 defines a Database Identification element, which contains the SCP, Intelligent Peripheral (IP), or some other database's identification number, that a transaction was performed.
An example of this element follows: 005.
Table 93 Element 34 -Database Identification ASCII CharactersMeanin 1-3 Database ID number Table 94 below provides a definition of element 36. Element 36 defines an Ingress Access Gateway element, which contains the AG identification number.
An example of this element follows: BOS003.

Table 94 Element 36 -Ingress Access Gateway ASCII ClraractersMeanin 1-3 Three Letter Ci ID

4-6 Trunkin Gatewa Number Table 95 below provides a definition of element 37. Element 37 defines an Egress Access Gateway element, which contains the AG identification number.
An example of this element follows: BOS003.
Tabie 95 Element 37- Egress Access Gateway ASCII Cl:aractersMeanin I-3 Three Letter Ci ID

4-6 Trunkin Gatewa Number Table 96 below provides a definition of element 38. Element 38 defines an Account Code element, which contains the length of the account code, as well as the actual account code digits that were entered.
An example of this element follows: 06000043652678.
Table 96 Element 38 -Accoui:t Code ASClI CharactersMeanin 1-2 Account Code Len th 00 = 2 Di it Account Code Ol = 3 Di it Account Code 02 = 4 Di it Account Code 03 = 5 Di it Account Code 04 = 6 Di it Account Code OS = 7 Di it Account Code 06 = 8 Di it Account Code 07 = 9 Di it Account Code 08 = 10 Di it Account Code 09 = l 1 Di it Account Code Table 96 Element 38 -Account Code ASCII CharactersMeanin 11 = 12 Di it Account Code 3 - 14 Account Code Di its * The Account Code digits can be right justified and padded with Os.
Table 97 below provides a definition of element 39. Element 39defines an End Time element, which contains the time when the call completed. The time should be recorded after both parties, originating and terminating, go on-hook.
An example of this element follows: 032245039.
Table 97 Element 39 -End Time ASCII CharactersMeanin I -2 Hours 3-4 Minutes 5-6 Seconds 7-9 Milliseconds Table 98 below provides a definition of element 40. Element 40 defines an End Date element. which contains the date when the call was completed.
An example of this element follows: 19980218.
Table 98 ._ -.

-Element 40 -End Date ASCII CharactersMeanin 1-4 Year 5-6 Month 7-8 Da Table 99 below provides a definition of element 41. Element 41 defines an Answer Date element. which contains the date when the call was answered.
An example of this element follows: 19980513.

Table 99 Element 4l -Answer Date ASCII CharactersMeanin l -4 Year 5-6 Month 7-8 Da Table 100 below provides a definition of element 42. Element 42 defines an Answer Time element, which contains the time when the terminating station went off hook. The timer could start when the Soft Switch receives an answer message. If the call was unanswered. the Answer Time wi l l contain the time that the originating party went on-hook.
An example of this element follows: 023412003.
Table 100 Element 42 -Answer Time ASCII CharactersMeanin I -2 Hours 3-4 Minutes 5-6 Seconds Milliseconds Table I OI below provides a definition of element 43. Element 43 defines an Ingress Carrier Disconnect Time element. which contains the time that the ingress trunk/circuit was released for a call. The time will either be derived from the Access or Trunking Gateways, or from the Release Message. This element can be important to downstream systems (i.e. cost analysis/CABS analysis) that may need to audit the bills coming from LECs/CLECs/Carriers.
An example of this element follows: 041 I 52092.

Table 101 Element 43 -Ingress Carrier Disconnect Time ASCII CharactersMeanin 1-2 Hours 3-4 Minutes 5-6 Seconds 7-9 Milliseconds Table 102 below provides a definition of element 44. Element 44 def nes an Ingress Carrier Disconnect Date Disconnect Date element, which contains the date when the ingress trunk/circuit was released for a call.
An example of this element follows: 19980523.
Table 102 Element 44 -Ingress Carrier Disconnect Date Disconnect Date ASCII CharactersMeanin 1-4 Year 5-6 Month 7-8 Da Table 103 below provides a definition of element 45. Element 45 defines an Egress Carner Disconnect Time element, which contains the time that the egress trunk/circuit was released for a call. The time will either be derived from the Access or Trunking Gateways. or from the Release Message. This element can be extremely important to downstream systems (i.e. CABS) that need this information to BILL other LECs/CLECs/Carriers.
An example of this element follows: 041152092.
Table 103 Element 4S -Egress Carrier Disconnect Time ASCII CharactersMeanin 1-2 Hours 3-4 Minutes 5-6 Seconds 7-9 Milliseconds Table 104 below provides a definition of element 46. Element 46 defines an Egress Carrier Disconnect Date element, which contains the date when the egress trunk/circuit was released for a call.
An example of this element follows: 19981025D.
Table 104 Element 46 -Egress Carrier Disconnect Date ASCII CharactersMeanin 1-4 Year 5-6 Month 7-8 Da Table 105 below provides a definition of element 47. Element 47 defines an Announcement Identification element, which contains the announcement number (correlating to an announcement) that was invoked during call processing.
An example of this element follows: 0056D.
Table 105 Element 47 -Announcement Identification ASCII CharactersMeanin 1-4 Announcement ID

Table 106 below provides a definition of element 48. Element 48 defines a Location Routing Number (LRN) element, which contains the Location Routing Number. Depending on the EB being created (EB 0055 or EB 0056), this field contains the LRN for the Calling Party Number (if ported) or the LRN for the Called Party Number (if ported).
An example of this element follows: 13039263223D.

Table 106 Element 48 -Location Routing Number ASClI CharactersMeanin 1 Pa Identifier I = Callin Pa 2 = Called Pa 2-1 I Location Routin Number Table 107 below provides a definition of element 49. Element 49 defines a LRN Supporting Information element, which contains the source/system where the LRN was derived.
An example of this element follows: 1.
Tabie 107 Element 49 -LRN Supporting Information ASCII CharactersMeanin I LRN Source Indicator I = LNP Database SCP

2 = Derived from the SS

3 = Si nalin Data Table 108 below provides a definition of element 50. Element 50 defines a Soft Switch Version element. which contains the current software version that is operating on the soft switch.
An example of this element follows: O 150.
Table 108 Element SO -Soft Switch Version ASCII CharactersMeanin I-2 SS Version Number Prefix 2-4 SS Version Number Suffix) Table 109 below provides a definition of element 51. Element 51 defines a Carrier Selection Information element, which contains the toll carrier selection method. This allows downstream systems, such as end-user billing and fraud, to parse records based on carrier selection methods (e.g., pre-subscription, dial-around/casual-calling.) An example of this element follows: O1.
Table 109 Element SI -Carrier Selection Information ASCII CharactersMeanin 1-2 Carrier Selection Method O1 = Pre-Subscribed 02 = SS Derived 03 = SCP Derived 04 = Carrier Designated by Caller at Time of Call casual-call/dial-around Table 110 below provides a definition of element 52. Element 52 defines an Ingress Trunking Gateway element, which contains the TG identification number.
An example of this element follows: BOS003.
Table 110 Element S2 - Ingress Trunking Gateway ASCII Characters Meanin 1-3 Three Letter Ci ID

4-6 Trunkin Gatewa Number Table 111 below provides a definition of element 53. Element 53 defines an Egress Trunking Gateway element, which contains the TG identification number.
An example of this element follows: DEN003.

Table 111 Element 53 -Egress Trunking Gateway ASCII CharactersMeanin I-3 Three Letter Ci ID

~ 4-6 ~ Trunking Gateway Number Table 112 below provides a definition of element 54. Element 54 defines an Egress Routing Selection.
An example of this element follows: 02.
Table 112 Element S4 -Egress Routing Selection ASCII CharactersMeanin I-2 Final Route Selection/Choice O1 = 1 st route choice 02 = 2nd route choice 03 = 3rd route choice 04 = 4th route choice OS = 5th route choice Table 112 below provides a definition of element 55. Element 55 defines an Egress Route Congestion Code element, which contains the reason for congestion on a trunk.
An example of this element follows: O 1.
Table 113 Element SS -Egress Route Congestion Cole ASCU CharactersMeaning 1-2 Route Congestion Code O1 = Circuit Congestion 02 = Circuit Failure 03 = QoS Not Available Table 114 below provides a definition of element 56. Element 56 defines an Account Code Validation Flag element, which contains a flag that specifies whether or not the account code validation was successful.
An example of this element follows: 1.

Table 114 Element S6 -Account Cole vulidution Flub ASClI CharactersMeaning I Account Code Validation Flag 0 = AC Validation NOT Successful 1 = AC Validation Successful Table I 15 below provides a definition of element 57. Element 57 defines a Routing Attempt Time element. which contains the time that an unsuccessful routing attempt was made on a trunk. This information can be useful to downstream Network Management and Traffic Engineering systems.
An example of this element follows: 102943005.
Table 115 Element S7 -Routing Attempt Time ASCII CharactersMeaning I -2 Hours 3-4 Minutes 5-6 Seconds 7-9 Milliseconds Table 116 below provides a definition of element 58. Element 58 defines a Routing Attempt Date element. which contains the date that an unsuccessful routing attempt was made on a trunk. This information can be useful to downstream Network Management and Traffic Engineering systems.
An example of this element follows: 19980430.
Table 116 Element S8 -Routing Attempt Dute element ASCII CharactersMeaning 1-4 Year 5-6 Month 7-g Day WO 00/31933 PCT/US99l27658 Table 1 I 7 below provides a definition of element 59. Element 59 defines an Audio Packets Sent element, which contains the number of audio packets that were sent from an AG or TG during a session.
An example of this element follows: 000043917.
Tabe 117 Element S9 -Audio Packets Sent ASCll CharactersMeanin 1-9 Audio Packets Table 118 below provides a definition of element 60. Element 60 defines an Audio Packets Received element, which contains the number of audio packets that were received by an AG or TG during a session.
An example of this element follows: 000043917.
Table 118 Element 60 -Audio Packets Received ASCII CharactersMeanin 1-9 Audio Packets Table I 19 below provides a definition of element 6I . Element 61 defines an Audio Packets Lost element. which contains the number of audio packets that were lost during a session.
An example of this element follows: 000043917.
Table 119 Element 61- Audio Packets Lost ASCII CharactersMeanin 1-9 Audio Packets Table 120 below provides a definition of element 62. Element 62 defines an Audio Bytes Transferred element, which contains the total number of audio packets that were transferred sent from an AG or TG during a session.

An example of this element follows: 000023917.
Table 120 Element 62 -Audio Bytes Transferred element ASCII CharactersMeanin 1-9 Audio Bytes Table 121 below provides a definition of element 63. Element 63 defines an Originating IP Address element, which contains the Internet Protocol (IP) address of the originator.
An example of this element follows: 205123245211.
Table 121 Element 63 -Originating IP Address ASCII ClearactersMeanin i-3 Class A Address 4-6 Class B Address 7-9 Class C Address 10-12 Class D Address Table 122 below provides a definition of element 64. Element 64 defines a Terminating IP Address element. which contains the Internet Protocol (IP) address of the termination.
An example of this element follows: 205123245211.
Table 122 Element 64 -Terminating IP Address ASCII CharactersMeanin 1-3 Class A Address 4-6 Class B Address 7-9 Class C Address 10-12 Class D Address Table 123 below provides a definition of element 65. Element 65 defines an Ingress Security Gateway IP Address element, which contains the Internet WO 00/31933 PCT/US99/Z7b58 Protocol (IP) address of the security gateway on the ingress portion of a call/session.
An example of this element follows: 205123245211.
Table 123 Element 6S -Ingress Security Gateway IP Address ASCII CharactersMeanin 1-3 Class A Address 4-6 Class B Address 7-9 Cfass C Address ( 10-12 ~ Class D Address Table 124 below provides a definition of element 66. Element 66 defines an Egress Security Gateway IP Address element. which contains the Internet Protocol (IP) address of the security gateway on the egress portion of a calUsession.
An example of this element follows: 205123245211.
Table 124 Element 66 -Egress Security Gateway IP Address ASCII Cl:aractersMeanin 1-3 Class A Address 4-6 Class B Address 7-9 Class C Address 10-12 Class D Address Table 125 below provides a definition of element 67. Element 67 defines an Ingress Firewall IP Address element, which contains the Internet Protocol (IP) address of the security gateway on the ingress portion of a call/session.
An example of this element follows: 205123245211.

WO 00/31933 PCT/US99/2765$

Table 125 Element 67 -Ingress Firewall IP Address ASCII CharactersMeaning 1-3 Class A Address 4-6 Class B Address 7-9 Class C Address 10-12 Class D Address Table 126 below provides a definition of element 68. Element 68 defines an Egress Firewall IP Address element, which contains the Internet Protocol (IP) address of the security gateway on the egress portion of a call/session.
An example of this element follows: 205123245211.
Table 126 Element 68 -Egress Firewall IP Address ASCII CharactersMeanin 1-3 Class A Address 4-6 Class B Address 7-9 Class C Address 10-12 Class D Address Table 127 below provides a definition of element 69. Element 69 defines an Operator Trunk Group Number element, which contains the trunk group number for the trunk selected to the Operator Services Platform (OSP).
An example of this element follows: 1234.
Table 127 Element 69 -Operator Trunk Group Number ASCII CharactersMeanin 1-4 rTrunk Group Number Table 128 below provides a definition of element 70. Element 70 defines an Operator Circuit Identification Code (CIC) element, which contains the circuit number/id of the circuit used for an Operator service call.
An example of this element follows: 0312.

w0 00/31933 PCT/US99/27658 Table 128 Element 70 -Operator Circuit Identiftcation Code ASCII CharactersMeanin I-4 Circuit Identification Code/Trunk Member Number Table 129 below provides a definition of element 71. Element 71 defines an Account Code Type element, which contains a value associated with the type of account used in the call.
An example of this element follows: 1.
Table 129 Element 7l -Account Code Type ASCll CltaractersMeanin I Account Code Type I = Verified Forced 2 = Verified Unforced 3 = Unverified Forced 4 = Unverified Unforced Table 130 below provides a definition of element 72. Element 72 defines an Ingress Carrier Connect Date element, which contains the date when the ingress trunk/circuit was seized.
An example of this element follows: 19980513.
Table 130 Element 72 -Ingress Carrier Connect Date ASCll CharactersMeanin I -4 Year 5-6 Month 7-8 Day 9 Delimiter Table 131 below provides a definition of element 73. Element 73 defines an Egress Carrier Connect Date element. which contains the date when the egress trunk/circuit was seized.
An example of this element follows: 19980513.

WO 00/31933 PC'T/US99/27658 Table 131 Element 73 -Egress Carrier Connect Date .

ASCII CharactersMeanin i -4 Year 5-6 Month 7-8 Day Table 132 below provides a definition of element 74. Element 74 defines a Terminating Number (International) element, which contains the overseas number that was dialed for domestic calls. The terminating number element should be populated for ALL calls that require a terminating number for billing.
This field can be right justified, padded with Os.
An example of this element follows: 34216273523482.
Table 132 Element 74 -Terminating Number (International) ASCII CharactersMeanin 1-14 Overseas Number Table 133 below provides a def nition of element 75. Element 75 defines a DA Trunk Group Number element, which contains the trunk group number for the trunk selected to the directory assistance (DA) service provider.
An example of this element follows: 1234.
Table 133 Element 7S -DA Trunk Group Number ASCII CharactersMeanin 1-4 Trunk Group Number Table 134 below provides a definition of element 76. Element 76 defines a DA Circuit Identification Code element, which contains the circuit number/id.
of the circuit used for a DA service call.
An example of this element follows: 0312.

Table 134 Element 76 -DA Circuit Identification Code ASCII CharactersMeanin 1-4 Circuit Identification Code/Trunk Member Number Table I 3 5 below provides a definition of element 77. Element 77 defines a Directional Flag element, which contains a flag that specifies whether a call event block is an ingress or an egress generated block.
An example of this element follows: 1.
Table 135 Element 77 -Directional Flag ASCII ClraractersMeanin 1 0 = Ingress ~ = Egress Table I 36 below provides a definition of element 78. Element 78 defines a Trunk Group Type element, which contains a type identification number, which maps to a type/use of a trunk. The element can be useful to downstream systems, such as mediation/billing, fraud, etc. This element can also be used in call processing.
An example of this element follows: 001.
Table 13b Element 78 -Trunk Group Type ASCll Cl:aractersMeanin I-3 Trunk Group Type Table 137 below provides a definition of element 79. Element 79 defines a Call Type Identification element, which contains a call type identification number, which maps to a type of a call. The element can be useful to downstream systems, such as, for example, mediation/billing, fraud. This element can also be used in call processing. This element can be derived during LSA analysis.

An example of this element follows: 001.
Table I37 Element 79 -Call Type Identification ASCII CharactersMeaning ~ I-3 Cali Type Identification Table 138 below provides a definition of element 80. Element 80 defines a Customer Identification element, which contains a customer account number.
An example of this element follows: 000000325436.
Table 138 Element 80 -Customer Identification ASCII CharactersMoaning I-12 Customer Identification Table 139 below provides a definition of element 81. Element 81 defines a Customer Location Identification element. which contains a customer location identification number.
An example of this element follows: 000000000011.
Table 139 Element 81 -Customer Location Identification ASCII Cl:aractersMeanin I-12 Customer Location Identification Table 140 below provides a def nition of element 82. Element 82 defines a Call Event Block Sequence Number element, which contains a sequence number for each event block created by the soft switch for a particular call.
An example of this element follows: 03.

Table 140 Element 82 -Cull Event Bluck Sequence Number ASCII CharactersMeaning I-2 Call Event Block Sequence Number Table 141 below provides a definition of element 83. Element 83 defines a Long Duration Sequence Number element, which contains a sequence number for each long duration call (LDC) event block created by the soft switch for a particular call.
An example of this element follows: 03.
Table 141 Element 83 -Lung Duration Sequence Number ASCII CharactersMeanin 1-2 Long Duration Sequence Number Table 142 below provides a definition of element 84. Element 84 defines a Long Duration Event Time element, which contains the time when the soft switch generated the LDC Event Block.
An example of this element follows: I 20000002.
Table 142 Element 84 -Long Duration Event Tin:e ASCll CharactersMeaning 1-2 Hours 3-4 Minutes 5-6 Seconds 7-9 Milliseconds Table 143 below provides a definition of element 85. Element 85 defines a Long Duration Event Date element, which contains the date when the soft switch generated the LDC Event Block.
An example of this element follows: 19980430.

-224- .
Table 143 Element 85 -Long Duration Event Date ASCII CharactersMeanin 1-4 Year 5-6 Month 7-8 Day 7. Network management component Telecommunications network 200 includes network management component 118 which can use a simple network management protocol (SNMP) to trap alarm conditions within and receive network alerts from hardware and software elements of the network. FIG. 21 A illustrates in detail SNMP network management architecture 2100. SNMP network management architecture 2100 is organized into a plurality of tiers and layers (not shown).
Tier 1 addresses hardware specific events that are generated on each respective hardware and software system. Generally, hardware vendors provide tier 1 functionality in the form of a management information base (MIB).
Tier 2 is designed to capture operating system specific events and is also available as a commercially sold product in the form of an MIB from a software vendor.
Tier 3 is related to events generated by customized software running on the platform.
In one embodiment of the invention, tiers 1 and 2 are provided by a hardware vendor, for example, from Sun Microsystems of Palo Alto, CA. Tier 1 and 2 MIBs are designed to provision, update, and pass special event and performance parameters to a network operations center (NOC), pictured as NOC
2114 in FIG. 21 A.
Tier 3 can support alarm transmission from software applications and can be designed and implemented via a customized software solution from a third party vendor. Software applications can call a standardized alarm transport application programming interface (API) to signal events and alarms within the software code. The vendor supplied alarm API can redirect events to a local alarm manager application. There can be one instance of a local alarm manager application on each customized platform or computer in the network. The local alarm manager can log events to a disk-based database. The local alarm manager can also log events to a disk-based log file and can then forward the events from the database or log file to a specialized MIB component. The specialized MIB
component can then divert this information to a regional SNMP agent at each geographical location, i.e., at each soft switch site 104, 106 and 302, or gateway site 108a, 108b,108C,108D,108E,1 I Oa, l l Ob, 1 I Oc, 1 l OD and 110E.
Regional SNMP agents can then route all incoming network management events or alarms to master SNMP managers 2102 and 2104 at the NOC 2114.
a. Network operations center (NOC) FIG. 21 A includes Network Operations Center (NOC) 2114 in SNMP
network management architecture 2100. Soft switch sites 104, 106 and 302 include a plurality of network components each 'having their own SNMP agents.
For example, soft switch site 104 includes RNECP 224a and 224b having their own SNMP agents. Soft switch site 104 also includes configuration servers 206a and 206b, soft switches 204a, 204b and 204c, route servers 212a and 212b, SS7 GWs 208 and 210, and ESs 332 and 334, each having their own SNMP agents.
Soft switch site I04 can also include one or more redundant SNMP servers 2110 and 2112 for collecting regional SNMP alerts. SNMP servers 21 I 0 and 2112 can maintain log files of network management events. SNMP servers 2110 and 2112 can then send events and alarms upstream to NOC 2114 of network management component 118. NOC 2114 can include one or more centralized SNMP manager servers 2102 and 2104 for centrally managing telecommunications network 200.
Soft switch sites 106 and 302 can have similar SNMP agents in network components included in their sites.
Gateway sites 108a, I 08b, 108c, 108d, I 08e, 11 Oa, I I Ob, I l Oc, 11 Od and 1 l0e include multiple gateway site components which can each have their SNMP
agents. For example, gateway site 108a can include TGs 232a and 232b which WO 00/31933 PCT/US99~'27658 have SNMP agents 1002. Gateway site 108a can also include AGs 238a and 238b having SNMP agents 1006. Gateway sites 108a can also include ESs 1602 and 1604 and routers 1606 and 1608 having their own SNMP agents. Gateway site 108a can also have one or more SNMP servers 2106 and 2108 for gathering SNMP alerts, events and alarms at gateway site 108a, from SNMP agents such as, for example, SNMP agents 1002 and 1006. SNMP servers 2106 and 2108 can then forward network management events and alarms to NOC 2114 for centralized network management processing.
b. Simple Network Management Protocol (SNMP) Simple network management protocol (SNMP) events generated by network elements can enable NOC 2114 to determine the health of the voice network components and the rest of telecommunications network 200. Tier 1 and tier 2 MIBs can be purchased as commercially off the shelf (COTS) components, or are provided with computer hardware and operating systems. Events generated 1 S within the customized third tier can be prioritized according to multiple levels of severity. Prioritization can allow a programmer to determine the level of severity of each event generated and sent to NOC 2114. Customized alarm managers resident in each computer system can serve as alarm logging components and transport mechanisms for transport to downstream SNMP agents. Personnel working at NOC 2114 can log into a computer system to analyze special alarm conditions and to focus on the cause of the SNMP alarms. Multiple alarm conditions can be registered at NOC 2114. A local log file can store all events processed by a local alarm manager application. For example, local alarm manager applications can reside in SNMP servers 2106 and 2108 at gateway site 108a, and at SNMP servers 2110 and 2112 of soft switch site 104. The local log files can serve as a trace mechanism to identify key network and system event conditions generated on the computer systems.

c. Network Outage Recovery Scenarios FIG. 2I B illustrates an example outage recovery scenario 21 I 6. Outage recovery scenario 21 I 6 can be used in the event of, for example, a fiber cut, a period of unacceptable latency or a period of unacceptable packet loss failure in data network 112.
FIG. 21 B includes a calling party 102 placing a call to called party 120.
Calling party 102 is connected to carrier facility 126. Called party 120 is connected to carrier facility 130. A call path from calling party 102 to called party 120 is illustrated between carrier facility 126 and carrier facility 130 over a normal call path route 2118 through DACS 242 and 244 and TGs 232 and 234 of gateway sites 108 and 110, respectively. Normal call path route 2118 would go through, in succession, TG 232. one of ESs 1602 and 1604, one of routers 1606 and I 608, data network I 12, one of routers 1614 and I 616, one of ESs and 1612, and TG 234, before exiting DACs 244 to connect to earner facility 130.
Assuming a fiber cut occurs. or excessive latency or packet loss failure occurs in data network 112, outage recovery scenario 2116 routes the call over backup call path 2117 of FIG. 21 B. Backup call path 2117 takes a call which originated from carrier facility 126 through DACS 242 to TG 232, and connects the call back out through DACS 242 to an off network carrier 2115 which connects the call traffic for termination at carrier facility 130. By using off network routing via off network carrier 2115, service level agreements (SLA) can be maintained providing for a higher percentage of network uptime and a higher level of audio quality.
Outage recovery scenario 2116 would cover any failure or degradation in a network device which falls after TG 232 including IP media processes within TG 232, in normal call path route 21 I6, assuming that TG 232 can still be controlled so as to route the call out over DACS 242 over backup call path to off network carrier 2115.

(1) Complete Gateway Site Outage FIG. 21 C depicts an example network outage recovery scenario 2120.
Outage recovery scenario 2120 envisions a complete gateway site outage.
Specifically, gateway site 108 is illustrated as experiencing a complete gateway outage. In such a scenario, normal call path 2I 18 will never be received by the internal network telecommunications network 200. In outage recovery scenario 2120, the call is rerouted via carrier facility routing from carrier facility 126 over backup call path 2122 through off network carrier 21 I 5 to carrier facility I
30 for termination to called party 120. For calls placed from carrier facility 126 and other carrier facilities which are serviced from failed gateway site 108, CIC
overflow routing tables in carrier facility 126 will automatically reroute traffic through off network carrier 21 I5.
FIG. 2I D illustrates outage recovery scenario 2124 depicting another complete gateway site outage, different from that illustrated in FIG. 21C. In FIG. 21 D, it is gateway site 110 that has experienced a complete gateway site outage. In such a scenario, call path 2118 from calling party 102 does reach an on-network device TG 232, but the call is placed to a called party on failed gateway site 110. Backup call path 2126, is rerouted via soft switch overflow routing from TG 232 over DACS 242 to off network carrier 211 S for termination at Garner facility 130 of called party 120. For calls placed from the area served by operating gateway site 108, attempting to terminate at failed gateway site 110, soft switch 204 overflow routing automatically reroutes call traffic through off network carrier 211 S.
(2) Soft Switch Fail-Over Anticipating the possibility of a failure of a soft switch 204 of soft switch site I 04 it is important that existing calls (i.e. those placed through an associated gateway device, e.g., TGs 232 and 234 of gateway sites 108 and 110, respectively) not be impacted by the failure. In one embodiment of the invention, it is possible that some calls that are in the process of being established might be lost, such that a calling party 102 might have to re-dial to connect. In order to preserve calls set up and managed by failed soft switch 204, back-up soft switch 304 has access to the states of the stable calls managed by failed soft switch 204.
Once the back-up soft switch 304 initiates fail-over, it notifies the primary and secondary SS7 GWs 208 and 308 that the back-up soft switches 204 and 304 are now the contact points for signaling messages that had previously been targeted for failed soft switch 204.
(3) Complete Soft Switch Site Outage Scenario FIGs. 21E and 21F illustrate outage recovery scenarios 2132 and 2140 involving a complete soft switch site outage. FIG. 21 E depicts soft switch site coverage of various gateway sites. Specifically, FIG. 21 E illustrates western soft switch site 104, central soft switch site 106 and eastern salt switch site 302.
Western soft switch site 104 is responsible for controlling all access servers 1 S and 256 in circle 2136. Central soft switch site 106 is responsible for controlling all access servers 254 and 256 within circle 2134. Similarly, eastern soft switch site 302 is responsible for controlling all access servers 254 and 256 within circle 2138.
Western soft switch site 104 thus is responsible for controlling access servers 254 and 256 (not shown) in gateway sites 2135a, 2135b, 2135c, 2135d and 2135e.
Central soft switch site 106 is responsible for controlling access servers 254 and 256 (not shown) in gateway sites 2133a, 2133b, 2133c, 2133d, 2133e and 2133f.
Eastern soft switch site 302 is responsible for controlling access servers 254 and 256 (not shown) which are located in gateway sites 2139a, 2139b, 2139c, 2139d, 2139e and 2139f.
FIG. 21 F illustrates outage recovery scenario 2140 depicting a complete soft switch site outage. Specifically, central soft switch site 106 has failed or been shut down for maintenance in outage recovery scenario 2140. Failure of WO 00/31933 PC"T/US99/Z7658 central soft switch site 106 means that central soft switch site 106 can no longer control access servers 254 and 256 (not shown) which lie within circle 2134.
Specifically, access servers 254 and 256 which lie within gateway sites 2133a-2133f cannot be controlled by central soft switch site 106.
FIG. 21 F illustrates how western soft switch site 104 and eastern soft switch site 302 can take over control of gateway sites 2133a-2133f to overcome the outage of central soft switch site I06. Specifically, western soft switch site 104 can take over control of gateway sites 2I33a, 2133d, 2133e and 2133f.
Similarly, eastern soft switch site 302 can take over control of gateway sites 2133b and 2133c. Thus, access servers 254 and 256 located in gateway sites 2133a, 2133b, 2133c, 2133d, 2133e and 2133f can seemlessly be controlled by soft switch sites 106 and 302 in other geographies. It would be apparent to persons having ordinary skill in the art that other outage scenarios could be similarly remedied via communication between soft switch sites I04, 106 and 302.
FIG. 21 G depicts a block diagram 2146 of interprocess communication including a NOC 2114 communicating with a soft switch 204. NOC 2114 communicates 2148 to soft switch 418 to startup command and control. Soft switch 418 communicates 21 SO in order to send alarms and network management alerts to NOC 2114. NOC 2114 communicates 2152 in order to shut down soft switch 418 command and control. Soft switch 418 can also accept management instructions from NOC 2114 at startup 2154 or at shutdown 2156.
8. Internet Protocol Device Control (IPDC) Protocol a. IPDC Base Protocol The IPDC base protocol described below, provides the basis for the IP
device control family of protocols. The IPDC protocols include a protocol suite.
The components of the IPDC protocol suite can be used individually or together to perform multiple functions. Functions which can be performed by the IPDC
protocol suite include, for example, connection control, media control, and signaling transport for environments where the control logic is separated from the access server 254 and 256. The IPDC protocol suite operates between the media gateway controller and the media gateway. The media gateway controller can be thought of as soft switch 204. The media gateway can be thought of as access servers 254 and 256, including, for example, TGs 232 and 234, AGs 238 and 240 and NASs 228 and 230. The corresponding entities of media gateway controller and the media gateway are the call control and media control portions of the H.323 gateway.
IPDC acts to fulfill a need for protocols to control gateway devices which sit at the boundary between the circuit-switched telephone network and the Internet and to terminate circuit-switched trunks. Examples of such devices include NASs 228 and 230 and voice-over-IP gateways, also known as access servers 254 and 256, including TGs 232 and 234 and AGs 238 and 240. This need for a control protocol separate from call signaling arises when the service I S control logic needed to process calls lies partly or wholly outside the gateway devices. The protocols implement the interface between soft switch 204 and access servers 254, 256. IPDC views access servers 254 and 256, also known as media gateways, as applications which may control one or more physical devices.
In addition to its primary mandate, IPDC can be used to control devices which do not meet the strict definition of a media gateway such as DACS 242 and 244 and ANSs 246 and 248. IPDC builds on a base provided by DIAMETER.
DIAMETER has a number of advantages as a starting point including, for example, built-in provision for control security, facilities for starting up the control relation, and ready extensibility both in modular increments and at the individual command and attribute level. DIAMETER is specifically written for authentication, authorization and accounting applications. Calhoun, Rubins, "DIAMETER based protocol", July 1998. The DIAMETER based protocol specification was written by Pat Calhoun of Sun Microsystems, Inc. and Alan C.
Rubins of Ascend Communications.
The IPDC protocol includes a message header followed by attribute-value-pairs (AVPs) an IPDC command is a specialized data object which indicates the purpose and structure of the message which contains the IPDC
command. The command name can be used to denote the message format.
A DIAMETER device can be a client or server system that supports the DIAMETER based protocol. Alternatively, a DIAMETER device can support extensions in addition to the DIAMETER based protocol.
An IPDC entity can be any object, logical or physical, which is subject to control through IPDC or whose status IPDC must report. Every IPDC entity has a type. Types of IPDC entities include, for example, a media gateway type, a physical_gateway type, a station type, an equipment holder type, a transport termination type, an access termination type, a trunk_termination type, a signaling termination type, a device type, a modem type, a conference- port type, a fax-port type, a stream source type, a stream recorder type, an RTP~ort type, an ATM spec type, an H323 spec type, and a SIP spec type.
An IPDC protocol endpoint can be used to refer to either of the two parties to an IPDC control session, i.e. the media gateway controller (e.g., soft switch 204), or the media gateway (e.g., access servers 254 and 256). To the extent that IPDC can be viewed as providing extensions to DIAMETER, an IPDC
protocol endpoint can also be a DIAMETER device.
A transaction can be a sequence of messages pre-defined as part of the definition of IPDC commands which constitute that sequence. Every message in the sequence can carry the same identifier value in the header and the same transaction-originator value identifying the originator of the transaction.
DIAMETER packets or IPDC messages can be transmitted over UDP or TCP. Each DIAMETER service extensions draft can specify the transport layer.
For UDP, when a reply is generated the source and destination ports are reversed.
IPDC requires a reliable, order-preserving transport protocol with minimal latency so that IPDC control can be responsive to the demands of call processing.
UDP combined with a protocol description satisfies these requirements, and is therefore the default transport protocol for IPDC. It would apparent to those skilled in the art that network operators can choose to implement transmission control program (TCP) instead for greater security, or for other reasons.

The IPDC base protocol is a publically available document published on the Internet. It is important to note, that the IPDC based protocol is a document in a so called, "Internet-draft," as of the time of the writing of this publication.
Internet-drafts are working documents of the Internet engineering task force (IETF), its areas, and its working groups. Other groups can also distribute working documents as Internet-drafts. Internet-drafts can be updated, replaced or obsoleted by other documents at any time.
It would be apparent to someone skilled in the art that an alternative base protocol could be used.
Command AVPs include a plurality of DIAMETER based commands and additional IPDC commands. For example, DIAMETER base commands include, for example, command-unrecognized-1ND, device-reboot-IND, device-watchdog IND, device-feature-query, device-feature-reply, device-config-REQ, and device config-answer. Additional IPDC commands include, for example, command ACK and message-reject.
In addition to command AVPs, a plurality of other AVPs exist, including, for example, DIAMETER base AVPs, and additional IPDC AVPs. DIAMETER
base AVPs include host-IP-address, host-name, version-number, extension-ID, integrity-check-vector, digital-signature, initialization-vector, time stamp, session-ID, X509-certificate, X509-certificate-URL, vendor-name, finmware-revision, result-code, error-code. unknown-command-code, reboot-type, reboot-timer, message-timer, message-in-progress-timer, message-retry-count, message-forward-count and receive-window. Additional IPDC AVPs include, for example, transaction-originator and failed-AVP-code.
Protection of data integrity is enabled using the integrity-check-vector, digital signatures and mixed data integrity AVPs.
AVP data encryption is supported including, for example, shared secrets, and public keys. Public key cryptography support includes, for example, X509-certificate, X509-certificate-URL, and static public key configuration.

b. IPDC Control Protocol The IPDC is a control protocol that facilitates the delivery of voice and data services requiring interconnection with an IP network. The IPDC protocol permits a soft switch control server to control a media gateway or access server.
IPDC includes signaling transport, connection control, media control and device management functionality. These control functions include creation, modification, and deletion of connections; detection and generation of media and bearer channel events; detection of resource availability state changes in media gateways; and signal transport.
Alternatively, other protocols can be used to provide this control. For example, the network access server messaging interface (NMI) protocol or the media gateway control protocol (MGCP). The MGCP protocol from the Internet engineering task force (IETF) supports a subset of the functionality of the IPDC
protocol plus the simple gateway control protocol(SGCP) from Bellcore and CISCO. SGCP includes connection control and media control (i.e. a subset of IPDC media control) functionality.
IPDC protocol allows a call control server, i.e. a soft switch 204, to command a circuit network to packet network gateway (a media gateway), i.e. an access server 254, provides the control mechanism to for setting up, tearing down and managing voice and data calls. The term packet network gateway is intended to allow support for multiple network types including, for example, an IP
network and an ATM network, data network 112. In addition, the IPDC protocol supports the management and configuration of the access server 254. The following types of messages are described in this document: start-up messages describing access server start-up and shut-down; configuration messages describing access server, soft switch and telco interface query and configuration; maintenance messages describing status and test messages; and call control messages describing call set-up tear-down and query for data, TDM and packet-switched calls.
The architecture in which IPDC operates incorporates existing protocols wherever possible to achieve a full interconnection of IP-based networks with the global switched telephone network (GSTN). The architecture accommodates any GSTN signaling style. including. for example, SS7 signaling, ISDN signaling and in-band signaling. The architecture also accommodates an interface with H.323 voice-over-IP networks.
A modification to the H.323 architecture can allow H.323 networks to be seamlessly integrated with SS7 networks.
Until now, H.323 protocols have been defined assuming that an H.323 to GSTN gateway uses an access signaling technique such as ISDN or in-band access signaling for call set-up signaling on the GSTN. The H.323 architecture did not readily accommodate the use of SS7 signaling for call set-up via H.323 gateways, creating a gap in the standards. Until now, H.323 standards have distinguished between mufti-point processor (MP) functions and mufti-point controller (MC) functions only in the definition of mufti-point control units (MCUs). Recent international telecommunications union (ITU) work on H.323 version III has considered extending the concept of MC/MP separation to H.323 gateways as well as MCUs. Separation of the MC function from the H.323 gateway can allow SS7 to be properly interconnected with an H.323 network. By separating the MC function from the MP function, a separate SS7 signaling gateway, such as, for example, SS7 GW 208, can be created to interconnect the SS7 network with the H.323 network. Such an SS7 gateway can implement the H.323 gateway MC function as a signaling interface shared among multiple H.323 gateway MP functions.
At least five functions must be performed in order to interface an H.323 network to a GSTN network. The functions include, for example, a packet network interface, H.323 signal intelligence, GSTN signaling intelligence, a media processing function and a GSTN circuit interface.
In an H.323 gateway which interfaces with an in-band signaled or ISDN-signaled GSTN trunk, all ofthese five functions could be performed with a H.323 gateway. However, in a H.323 gateway which interfaces with a SS7 signaled trunk, the functionality could be more optimally partitioned to allow for a group of SS7 links to be shared among multiple H.323 gateway MP functions. For WO 00/31933 PCT/()S99/27658 example, an H.323 gateway MC function could include, for example, a packet network interface, H.323 signaling intelligence, and GSTN SS7 signaling intelligence. In addition, an H.323 gateway MP function could include a packet network interface, a media processing function, and a GSTN circuit interface.
Thus, the H.323 gateway functionality could be separated into the H.323 gateway MC function and the H.323 gateway MP function.
In another embodiment, the MC function could be further partitioned. For example, H.323 gateway MC function could include a packet network interface, H.323 signaling intelligence, and a packet network interface. An SS'7 gateway could include additional MC functions, such as, for example, a packet network interface, and a GSTN SS7 signaling intelligence. The physical separation ofthe H.323 gateway MC function from the SS7 gateway provides several advantages, including, for example, more than one SS7 gateway can be interfaced to one or more MC functions, allowing highly reliable geographically redundant configurations; service logic implemented at the H.323 gateway MC function (or at an associated gatekeeper) can be provisioned at a smaller number of more centralized sites, reducing the amount of data replication needed for large-scale service implementation across an H.323 network; and SS7 gateway to H.323 gateway MC functional interface could be a model for other signaling gateways, such as, for example, an ISDN NFAS gateway. a channel-associated C7 signaling gateway, and a DPNSS gateway. In fact, once service providers have implemented service logic at the H.323 gateway MC function for their SS7 signaled trunks, the following anomalies become apparent, for example, service providers will likely want to exercise the same or similar service logic for their ISDN and in-band signal trunks as well as their SS7 signaled trunks; and service providers will want to incorporate media processing events into the service logic implemented at the H.323 gateway MC function (or at an associated gatekeeper).
The IPDC protocol is intended to interface the MC function with the MP
function in H.323 to GSTN gateways. Based upon events detected in the signaling sueam, the H.323 gateway MC function must be able to create, delete, and modify connections in the H.323 gateway MP function. Alsa, the H.323 gateway MC function must be able to create or detect events in the media stream which only the H.323 gateway MP function has access to. A standardized protocol is needed to allow an H.323 gateway MC function to remotely control one or more H.323 gateway MP functions. Therefore, IPDC was created to allow H.323 gateway MC function to remotely control one or more H.323 gateway MP
functions. Specifically, soft switch 204 can remotely control one or more access servers 254.
The IPDC protocol uses the terminology of bay, module, line and channel A bay is one unit, or set of modules and interfaces within an access server A stand-alone access server 254 or a mufti-shelf access server 254 can constitute a single bay. A module is a sub-unit that sits within a bay. The module is typically a slot card that implements one or more network line interfaces, e.g., a dual span T 1 card. A line is a sub-unit that sits within a module. The line is typically a physical line interface that plugs into a line card, e.g., a T1. A
channel is a sub-unit within a line. The channel is typically a channel within a channelized line interface, e.g., one of the 24 channels in a channelized T1.
All numbers in the IPDC protocol should be in binary, and coded in network byte order (big endian or motorola format). The format for date/time fields is a 4 bytes integer expressing the number of seconds elapsed since January 1, 1990 at 0:00.
The soft switches 204 and 304 (e.g., primary/secondary/tertiary, etc.) are completely hot-swappable. Switching to a backup soft switch 204 does not require fall back in call processing states or other IPDC-level operation on access server 254. Both soft switches 204 and 304 follow the operations of the other soft switch, precisely.
The message exchange as defined in IPDC can be implemented over any IP base protocol. Suggested protocols include, e.g., TCP and UDP.
Access server 254 can include the following configuration items: IP
addresses and TCP or UDP ports of any number of soft switches 204 to which access server 254 should connect; bay number (8 bytes, in alpha numeric characters); system type (9 bytes. in alpha-numeric characters); and protocol version supported.
An IPDC packet can have the following components included in its format, for example, a protocol ID, a packet length, a data field tag, a data field length, data flags, an optional vendor ID, data and padding. For example, a protocol ID may exist in a first byte. Packet length can be a 2 byte field appearing second, a single byte reserved field can then occur followed by a 4 byte data field tag. Next a 2 byte data field length can be used, followed by a single byte data flag, and a single byte reserved field. Next, a 4 byte optional vendor ID
can exist. Next, the data included in the body of the message can contain a variable number of 4 byte aligned tag, length, value combinations. Finally, a byte data and single byte padding field can be placed in the IPDC packet. For all IPDC messages, the message type and transaction ID are required attribute value pairs.
The message code must be the first tag following the header. This tag is used in order to communicate the message type associated with the message.
There must only be a single message code tag within a given message. The value of this tag for each message type may be found below.
The transaction ID is assigned by the originator of a transaction. The transaction ID must remain the same for all messages exchanged within a transaction. The transaction ID is a 12-byte value with the following tag, length, value format: the first 4 bytes can contain a data field tag; the next two bytes can include the data field length; the next byte can contain flags; the next byte is reserved; the next 4 bytes can contain an originator ID; the following 4 bytes can contain originator ID; and in the last 4 bytes there can exist in the first bit the originator, and in the remaining bytes the transaction correlator 31 bits.
c. IPDC Control Message Codes Table 144 below provides a listing of the names and corresponding codes for control messages transmitted between Soft Switch 204 and Access Servers WO 00/31933 PCT/US99l27658 254 and 256. Also included are the source of each message and the description for each message. For example. the NSUP message is transmitted from Access Server 254 to Soft Switch 204. informing Soft Switch 204 that Access Server is coming up.
Ta ble 144 Mess age Codes Name Code Source Description NSUP 0x00000081AS Notify the soft switch that the access server is coming up ASUP 0x00000082SS Acknowledgment to NSUP

NSDN 0x00000083AS Notify the soft switch that the access server is about to reboot RST 0x00000085SS Request system reset - Drop I all channels ARSTI 0x00000086AS Reset in progress - awaiting Reboot command RST2 0x00000087SS Request system reset (Reboot command) ARST2 0x00000088AS Reboot acknowledgment MRJ Ox000000FFSS or Message reject.
AS

RSI 0x00000091SS Request system information NSt 0x00000092AS Response to RSI

RBN 0x00000093SS Request bay number NBN 0x00000094AS Response to RBN

SBN 0x00000095SS Set bay number ABN 0x00000096AS Acknowledgment to SBN

RMI 0x00000097SS Request module information NMI 0x00000098AS Notify module information RLI 0x00000099SS Request line information NLI Ox0000009AAS Notify line information RCI Ox0000009BSS Request channel information NCI Ox0000009CAS Notify channel information SLI Ox0000009DSS Set line information ASLI Ox0000009EAS Acknowledgment to SLI

SDEF Ox0000009FSS Set Default Settings ADEF Ox000000A0AS Accept Default Settings RSSI Ox000000A SS Request soft switch information NSSI Ox000000A2AS Notify soft switch information SSSI Ox000000A3SS Set soft switch information ASSSI Ox000000A4AS Acknowledgment to SSSI

RSSS Ox000000A5SS Request soft switch status Ta ble 144 Mess age Codes Name Code Source Description NSSS Ox000000A6AS Notify soft switch status RMS 0x00000041SS Request module status RLS 0x00000043SS Request line status RCS 0x00000045SS Request channel status S NMS 0x00000042AS Notify module status NLS 0x00000044AS Notify line status NCS 0x00000046AS Notify channel status SMS 0x00000051SS Set a module to a given state SLS 0x00000053SS Set a line to a given state SCS 0x00000055SS Set a group of channels to a given state RSCS 0x00000056AS Response to SCS

PCT 0x00000061SS Prepare channel for continuity test APCT 0x00000062AS Response to PCT

SCT 0x00000063SS Start continuity test procedure with far end as loopback (Generate tone and check for received tone) ASCT 0x00000064AS Continuity test result RTE Ox0000007DSS or Request test echo AS

ARTS Ox0000007EAS or Response to RTE
SS

RTP Ox0000007BSS Request test ping to given IP address ATP Ox0000007CAS Response to RTP

LTN 0x00000071SS Listen for tones ALTN 0x00000072AS Response to listen for tones STN 0x00000073SS Send tones ASTN 0x00000074AS Completion result of STN
command RCS/ 0x00000001SS Request inbound call setup ACS/ 0x00000002AS Accept inbound call setup CON/ 0x00000003AS Connect inbound call (answer) RCSO 0x00000005AS or Request outbound call setup SS

ACSO 0x00000006SS or Accept outbound call setup AS

CONO 0x00000007SS or Outbound call connected AS

RCST 0x00000009SS Request pass-through call setup (TDM
conncetion between two channels) ACST Ox0000U00AAS Accept pass-through call RCON 0X00000013SS Request Connection ACON 0X00000014AS Accept Connection MCON 0X00000015SS Modify connection AMCN 0X00000016AS Accept modify connection RCR 0x0000001 SS or Release channel request l AS

ACR r 0x00000012AS or Release channel complete Table Message Codes Name Code Source Description NOTI 0x00000017 AS, SS Event notification to the soft switch RNOT 0x00000018 SS, AS Request event notification from the access server d. A Detailed View of the IPDC Protocol Control Messages The following section provides a more detailed view of the control messages transmitted between Soft Switch 204 and Access Server 254.
( 1 ) Startup Messages Table 145 below provides the Startup messages, the parameter tags, the parameter descriptions (associated with these messages) and the R/O status.
Table 145 Startup (registration and de-registration) Parameter Message Tag Parameter Description RlO

NSUP - Notify Ox000000C0Message Code R
Access Server coming Ox000000C1Transaction ID R
up 0x00000001Protocol version implemented.R

0x00000002System ID R

0x00000003System type R

0x00000004Maximum number of modulesR
(cards) on the system (whether present or not).

0x00000005Bay number. R

ASUP - Ox000000C0Message Code R

Acknowledgment Oxpp0000C1Transaction ID R
to NSUP 0x00000002System ID R

NSDN - Notify Ox000000C0Message Code R
Access Server coming Ox000000C1Transaction ID __ R
down (about to reboot)0x00000002System ID R

This message will be sent by the access server when it has been asked to reset (jor instance, from the console, etc.) WO 00/31933 PCT/US99l27658 Parameter Message Tag Parameter Description R/p RST1 - Request Ox00C0 Message Code R
system reset - Drop Ox000000CTransaction I D R
all channels 1 0x00000002System ID R

ARSTt - Reset Ox000000C0Message Code R
in progress - awaitingOx000000C1Transaction 1D R
R
b e 0x00000002System ID R
oot command RST2 - Request Ox000000C0Message Code R
system reset (Reboot Ox000000C1Transaction ID R
command) 0x00000002System ID R

ARST2 - Reboot Ox000000C0Message_Co_de R

acknowledgment Ox000000C1Transaction ID R
' 0x00000002System ID R

0x00000006Result code R

(2) Protocol Error Messages Table 146 below provides the Protocol error messages, the parameter tags, the parameter descriptions (associated with these messages) and the R/O
status.
Table 146 Protocol Error handling Parameter Message Tag Parameter Description RlO

MRJ - Message Ox000000C0Message Code R
reject Ox000000C1Transaction ID R

Ox000000FDCause Code Type R

Ox000000FECause code R

This message is generated by the access server or soft switch when a message is received with an error, such as an irrvalid message code, etc.
The cause code indicates the main reason why the message was rejected (3) System Configuration Messages Table 147 below provides the System configuration messages, the parameter tags, the parameter descriptions (associated with these messages), the R/O status and any notes associated with the message.
Table 147 .

System configuration Parameter Message Tag Parameter DescripliotrRlO Notes RSI - Request This message system does information not contain any frelds.
the receiving access server returns an NSI
message.

NSl - Notify Ox000000C0Message Code R
system information Ox000000C1Transaction R
(response ID
R
I

to 0x00000001Protocol versionR
) implemented S (initially, set to 0).

0x00000002System ID R

0x00000003System type R

0x00000004Maximum numberR
of modules (cards) on the system (whether present or not).

0x00000005Bay number R

This message is sent as a response to a RSI request.

RBN - Request This message bay does number not contain any frelds, the receiving access server returns an NBN
message.

NBN - ResponseOx000000C0Message Code R
to ~~

RBN Ox000000CTransaction R

_ 0x00000005Bay number R

This message is sent as a response to a RBN request.

SBN - Set bay Ox000000C0Message Code R
number Ox000000C2Transaction ~~~
ID ~ R

0x00000005Bay number R

ASBN - Ox000000C0Message Code R

AcknowledgmentOx000000CTransaction R
to 1 ID
SBN

0x00000005Bay number R

This message N
is sent request.
as a response to a SB

SDEF - Set Ox000000C0Message Code R
Default Settings Ox000000CTransaction R
I ID

WO 00/31933 PCT/US99/2?658 Table 147 ~~.~

System configuration Parameter Message Tag Parameter DescriptionRlD Notes 0x00000007Module number O !f module number is not specified, all changes apply to all modules/lines/ch annels within the bay.

Ox0000000DLine number O If line number is not specified, all changes apply to all lines/channels within the specified module.
If line number is specified, module number must also be specified.

0x00000015Channel number O If channel number is not specified, all changes apply to all channels within the specified line. If channel number is specified, module number and line number must also be specified.

0x00000070Encoding Type O Required ( 1 byte) only 0x00000071Silence SuppressionO when a change to Activation Timer the setting is 0x00000072Comfort Noise O desired.

Generation 0x00000073Packet Loading O

0x00000074Echo CancellationO

0x00000075Constant DTMF O
Tone Detection on/off 0x00000076Constant MF O
Tone Detection on/off 0x00000077Constant Fax O
Tone Detection on/off WO 00/31933 ~ PCT/US99/27658 _ Table 1_47 System configuration Parameter Message Tag Parameter DescriptionRlO Notes 0x00000078Constant Modem O
Tone Detection on/off 0x00000079Programmable O
DSP

Algorithm activation Ox0000007AProgrammable O
DSP

Algorithm deactivation Ox0000007BConstant PacketO
Loss Detection on/off Ox0000007CPacket Loss O
Threshold Ox0000007DConstant LatencyO

Threshold Detection on/off Ox0000007ELatency ThresholdO

0x00000084Signaling channelO
QoS

0x00000085Signaling channelO
QoS

value (variable length) Ox0000006EForward SignalingO

Events to the Soft Switch This message is used to configure default settings within the access server.
If no module is specified, default settings will apply to all modulesllineslchannels in the bay.
ljno Gne number is specified, default settings will apply to all lineslchannels within a module.
if no channel number is specified the default settings will apply to all channels within a line.

ADEF - Accept Ox000000C0Message Code R

Default SettingsOx000000C1Transaction ~~
ID R

0x00000007Module number O The setting for these fields are Ox0000000DLine number O the same as those 0x00000015Channel number O Posed in on the SDEF message.

0x00000048Set Channel R
Status Result This message is sent from the access server to the soft switch on response to a SDEF
message.

(4) Telephone Company Interface Configuration Messages Table 148 below provides the Telephone Company (Telco} interface configuration messages, the parameter tags, the parameter descriptions (associated with these messages), the R/O status and any notes associated with the message.
Table 148 Telco int erface configuration Parameter Message Tag Parameter DescriptionRlO Notes RMI - RequestOx000000C0Message Code R

module informationOx000000C1Transaction R
ID

0x00000007Module number R

NMI - Notify Ox000000C0Message Code R

module informationOx000000C Transaction R

(response 0x00000007Module number R
to RMI) Ox0000000AModule type R

Ox0000000BModule capabilitiesR

0x00000008Number of linesR
(or items, depending on card type).

Ox0000003ANumber of failedR
lines (or items, depending on card tYPe).

0x00000009External name R
(i.e., "8tl-card", etc.) in ASCII
format.

RLI - RequestOx000000C0Message Code R
line information Ox000000C Transaction R

0x00000007Module number R

Ox0000000DLine number R

NLI - Notify Ox000000C0Message Code R
line information Ox000000C Transaction R

(response 0x00000007Module number R
to RLI) Ox0000000DLine number R

Ox0000000ENumber of channelsR

Ox0000000FExternal name R
in ASCII
format 0x00000010Line coding R

0x00000011Framing R

0x00000012Signaling type R

Table 148 Telco interface configuration Parameter Message Tag Parameter DescriptionRlO Notes 0x_00000013In-band signalingR
details 0x00000041T1 front-end R
type 0x00000042TI CSU build-outR

0x00000043T1 DSX-1 line R
length RC1- Request Ox000000C0Message Code R

channel informationOx000000C1Transaction ID R

0x00000007Module number R

Ox0000000DLine number R

0x0000001Channel number R
S

_ _ Table 148 ~~~~~~

Telco interface configuration Paranrc Message ter Parameter DescriptionRlO Notes Tag NCI - Notify Ox000000C'0Message Code R
channel information Ox000000CTransaction ID R
i (response to px00000007Module number R
RCI) ~

Ox0000000D~.,ine number R

0x00000015Channel number R

0x00000016Channel status R

0x00000017Bearer CapabilityR
of the Channel (BCC) or type of the active call, when a call is present 0x00000018Calling Party O Required number only if h t 0x00000019Dialed Phonr O e channel number has an active call.

0x0000001Timestamp of R
A the last channel status toansition 0x00000040Access Server O Required Cull only if Identifier the channel has an active call.

SLI - Set lineOx000000C0Message Code R

information Ox000000C1Transaction ID R

0x00000007Module number R

Ox0000000DLine number R

Ox0000000FExternal name O Required in ASCII only if format the value is to be changed in the access server.

0x00000010Line coding O Required only if 0x0000001Framing p the value I ~ is to be 0x00000012Signaling type O :hanged . in the access server.

0x00000013In-band signalingO Valid for details telco 0x00000041T1 front-end O nterface type i cards 0x00000042TI CSU build-outO only.

0x00000043TI DSX-1 line O
length ASLI - New Ox000000C0Message Code R
line information Ox000000C1Transaction 1D R
ACK

0x00000007Module number R

Ox0000000DLine number R

This message is sent as a response to a SL! reguest.

n DEMANDES OU BREVETS VOLUMINEUX

COMPREND PLUS D'UN TOME.
CECi EST LE TOME 'I DE
NOTE: ~ Pour les tomes additionels, veuillez contacter le Bureau canadien des brevets JUMBO APPLICATIONS/PATENTS
THiS SECTION OF THE APPL1CAT10N/PATENT CONTAINS MORE
THAN ONE VOLUME
THIS IS VOLUME ~ , OF
NOTE: For additional volumes please contact the Canadian Patent Office

Claims

What Is Claimed Is:

1. A system for processing media traffic over at least one data network, comprising:
a media gateway for converting media traffic from a first media format to a second media format; and a soft switch for converting signaling information from a first signaling format to a second signaling format and for externally controlling said media gateway in response to said signaling information.

2. The system of claim 1, wherein said media gateway comprises:
a trunking gateway.

3. The system of claim 2, wherein said first signaling format comprises:
an out of band signaling format.

4. The system of claim 3, wherein said out of band signaling format comprises:
an SS7 signaling format.

5. The system of claim 4, wherein said second signaling format is selected from the group consisting of:
an H323 format:
a SIP format; and a packetized version of any one of ISDN format, Q.931 format, channel-associated signaling format and SS7 signaling format.

6. The system of claim 4, further comprising:
a signaling gateway for converting a first protocol suite used to transmit said signaling information to a second protocol suite.

7. The system of claim 6, wherein said first protocol suit comprises:
a standard SS7 protocol suite.

8. The system of claim 7, wherein said second protocol suit is selected from the group consisting of:
TCAP messages encapsulated in IP packets;
ISUP messages encapsulated in IP packets;
INAP messages encapsulated in IP packets; and TUP messages encapsulated in IP packets.

9. The system of claim 1, wherein each of said first and second media formats are selected from the group consisting of:
a circuit switched format; and a packet switched format.

10. The system of claim 9, wherein said circuit switched format is selected from the group consisting of:
a PCM encoded audio format;
a modem format; and a fax format.

11. The system of claim 10, wherein said packet switched format is selected from the group consisting of:
an ATM format;
an IP format; and a frame relay format.

12. The system of claim 9, wherein said packet switched format is selected from the group consisting of:
an ATM format;
an IP format; and a frame relay format.

13. The system of claim 1, wherein said soft switch externally controls said media gateway using a control protocol selected from the group consisting of internet protocol device control, simple gateway control protocol, media gateway control protocol, and H.323 format.

14. The system of claim 1, wherein said soft switch further comprises:
means for determining whether said media traffic received at said media gateway comprises a voice call or a data call;
means for instructing said media gateway to terminate the call at a modem for transmission over a first data network if the call is a data call; and means for instructing said media gateway to terminate said call at a second media gateway via an RTP connection over a second data network if the call is a voice call.

15. The system of claim 14, wherein said first data network and said second data network comprise the same data network.

16. The system of claim 1, further comprising:
a plurality of said media gateways; and a plurality of said soft switches, each soft switch being capable of converting signaling information from said first signaling format to said second signaling format and externally controlling each of said media gateways in response to said signaling information.

17. The system of claim 1, wherein said soft switch comprises:
means for externally controlling low-level functionality of said media gateway in response to said signaling information, said low-level functionality including connection control, media control and device management.

18. The system of claim 17, wherein said connection control functionality comprises creation, deletion and modification of connections.

19. The system of claim 17, wherein said media control functionality comprises detection and generation of media and bearer channel events.

20. The system of claim 17, wherein said device management functionality comprises detection of resource availability and state changes in said media gateway.

21. A system for processing media traffic over at least one data network, comprising:
a media gateway for converting signaling information from a first signaling format to a second signaling format and for converting media traffic from a first media format to a second media format, and a soft switch for externally controlling said media gateway in response to said signaling information.

22. The system of claim 21, wherein said media gateway comprises:
an access gateway.

23. The system of claim 21, wherein said first signaling format comprises:
an in-band signaling format.

24. The system of claim 23, wherein said in-band signaling format is selected from the group consisting of:

an ISDN format; and a channel-associated signaling format.

25. The system of claim 24, wherein said second signaling format is selected from the group consisting of:
an H323 format;
an SIP format; and a packetized version of any one of ISDN format, Q.931 format, channel-associated signaling format and SS7 signaling format.

26. The system of claim 21, wherein each of said first and second media formats are selected from the group consisting of:
a circuit switched format; and a packet switched format.

27. The system of claim 26, wherein said circuit switched format is selected from the group consisting of:
a PCM encoded audio format;
a 64kbps channel format;
a 56kbps channel format;
a modem format; and a fax format.

28. The system of claim 27, wherein said packet switched format is selected from the group consisting of:
wireless terrestrial format;
wireless satellite format;
ATM format;
IP format; and frame relay format.

29. The system of claim 26, wherein said packet switched format is selected from the group consisting of:
wireless terrestrial format;
wireless satellite format;
ATM format;
IP format; and frame relay format.

30. The system of claim 21, wherein said soft switch externally controls said media gateway using a control protocol selected from the group consisting of internet protocol device control, simple gateway control protocol and media gateway control protocol.

31. The system of claim 21, wherein said soft switch further comprises:
means for determining whether said media traffic received at said media gateway comprises a voice call or a data call;
means for instructing said media gateway to terminate the call at a modem for transmission over a first data network if the call is a data call; and means for instructing said media gateway to terminate said call at a second media gateway via an RTP connection over a second data network if the call is a voice call.

32. The system of claim 31, wherein said first data network and said second data network comprise the same data network.

33. The system of claim 21, further comprising:
a plurality of said media gateways; and a plurality of said soft switches, each soft switch being capable of converting signaling information from said first signaling format to said second signaling format and externally controlling each of said media gateways in response to said signaling information.

34. The system of claim 21, wherein said soft switch comprises:
means for externally controlling low-level functionality of said media gateway in response to said signaling information, said low-level functionality including connection control, media control and device management.

35. The system of claim 34, wherein said connection control functionality comprises creation, deletion and modification of connections.

36. The system of claim 34, wherein said media control functionality comprises detection and generation of media and bearer channel events.

37. The system of claim 34, wherein said device management functionality comprises detection of resource availability and state changes in said media gateway.