CA2216035A1 - Ip-pstn call processing server - Google Patents

Ip-pstn call processing server Download PDF

Info

Publication number
CA2216035A1
CA2216035A1 CA002216035A CA2216035A CA2216035A1 CA 2216035 A1 CA2216035 A1 CA 2216035A1 CA 002216035 A CA002216035 A CA 002216035A CA 2216035 A CA2216035 A CA 2216035A CA 2216035 A1 CA2216035 A1 CA 2216035A1
Authority
CA
Canada
Prior art keywords
call processing
processing server
pstn
call
computer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
CA002216035A
Other languages
French (fr)
Inventor
Jim Udall
Louis Payant
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Oyj
Original Assignee
Vienna Systems Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Vienna Systems Corp filed Critical Vienna Systems Corp
Priority to CA002216035A priority Critical patent/CA2216035A1/en
Publication of CA2216035A1 publication Critical patent/CA2216035A1/en
Abandoned legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/102Gateways
    • H04L65/1033Signalling gateways
    • H04L65/104Signalling gateways in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/102Gateways
    • H04L65/1023Media gateways
    • H04L65/103Media gateways in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • H04L65/102Gateways
    • H04L65/1043Gateway controllers, e.g. media gateway control protocol [MGCP] controllers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1069Session establishment or de-establishment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1083In-session procedures
    • H04L65/1095Inter-network session transfer or sharing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • H04L65/1096Supplementary features, e.g. call forwarding or call holding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/12Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M7/00Arrangements for interconnection between switching centres
    • H04M7/009Arrangements for interconnection between switching centres in systems involving PBX or KTS networks

Abstract

A call processing server operating in a computer environment to provide call processing features over computer-based networks such as the Internet or private Intranets and across the public switched telephone network.
In addition to transporting voice, fax etc. over the Internet, the server provides call processing features such as hold, conferencing, etc.

Description

CA 0221603~ 1998-08-27 IP/PSTN CALL PROCESSING SERVER

Field of the Invention This invention relates to computer-based networks such as the Internet or private Intranets and the public switched telephone network (PSTN) and more particularly to a call processing server running in a computer environment which offers powerful call processing features over the IP network and across the PSTN networks.

Background Call processing is normally associated with the technologies dealing with the establishment and control of calls amongst parties connected in a circuit switched network. This includes the making of calls, terminating calls and providing a variety of features such as hold, transfer, forward, conference, and many others. It is normally associated with PABX, Key Systems and Centrex based equipment and operates over the Public Switched Telephone Network (PSTN).
In recent years, computer systems have evolved from mainframe computers to personal computers to networked computers. Today, computers of all shapes and power operating under different operating systems connect together using the IP protocol (Internet Protocol) to form the Internet or private Internets also called Intranets.
The ability to provide voice services over IP networks and more importantly the ability to bridge voice communications across both the IP
and PSTN networks is a new problem and a variety of partial solutions have been introduced to address this challenge. Associated with these solutions are the following shortcomings:

a) Point to point calls over the IP network. Internet phones applications have been introduced offering voice services in a point to point fashion using proprietary voice encoding schemes.

CA 0221603~ 1998-08-27 b) Call processing over the IP network. At least one solution has been introduced offering powerful call features over the IP network but with no connectivity across the 800 million telephones available over the PSTN
network.

c) Voice transport over the IP network. Solutions providing an IP voice transport across fixed locations over the IP network are now becoming available. Call processing features providing call routing, call detail recording are generally not available.
d) Scalability. Many of the current solutions are not engineered as industrial, robust solutions capable of scaling to large configurations.

It is an object of the present invention to provide a call processing server which provides all of the call processing features normally associated with the PSTN across both the IP and PSTN networks.
Therefore, in accordance with the present invention there is provided in a computer environment a call processing server having a software application interfacing with a computer-based network and the Public Switched Telephone Network to provide access therebetween.

Brief Description of the Drawings The invention will now be described in greater detail with reference to the attached drawings wherein Figure 1 to 5 show various Internet /PSTN
interfaces.

Detailed Description of the Invention The Vienna IP-PSTN call processing server is a software application running in an Open System computer environment such as Solaris or Windows NT and offers powerful call processing features over the IP network and across the PSTN networks.
Firstly, the server offers most of the commonly used features in a telephone system and all the features are independent on whether the end CA 0221603~ 1998-08-27 user i9 an IP based client running in a PC or a standard telephone running anywhere in the world over the PSTN network. Features such as transfer, forward and conference are all in this category.
Secondly, the IP-PSTN server is architectured to provide solutions that are scaleable to commercial and industrial environments. The ability to scale from a few clients to several hundred over a world wide network including the support of several PSTN gateways anywhere in the IP network provides corporate users as well as service providers with superior flexibility.
Thirdly, the IP-PSTN call processing server provides an environment for Computer Telephony application development. As a Microsoft TAPI and Active X service provider, it provides a powerful environment for applications such as distributed call center applications.
The invention is applicable to the following technologies:
a) Voice over Internet/Intranet and PSTN networks b) Fax over Internet/Intranet and PSTN networks c) Video over Internet/Intranet and PSTN networks d) Document collaboration over Internet/Intranet and PSTN networks e) Telephony over Internet/Intranet and PSTN networks f) PABX systems over Internet/Intranet and PSTN networks g) Multimedia personal computers including Windows 95, and Windows NT.

Currently, Vienna Systems software provides voice over IP calling capability. What is that? It is the basic ability to take an analog voice signal, digitize it so that it can be transferred in a computerized environment, compress it where necessary so that it won't create too much bandwidth consumption over that computer network, and packetize it into IP
packets so that it can be understood on the IP network.
There are many reasons for wanting to do this - but basically we want to do it because it can in some way save money. For example, we can eliminate the telephone network in our office - utilizing the data network instead. Or we can utilize the data network instead of the telephone network and save money on long distance calls. Or we can more efficiently use our data networks because we can use less of the dedicated bandwidth consuming resources dedicated to analog telephone traffic.

CA 0221603~ 1998-08-27 The Vienna system components installed on an IP network consist of:

Gateways (GW on diagram): provide the interface to the PSTN
- n per system a CP Server (Call Processing Server): provides call orchestration, setup and routing - 1 per system My.Way clients on Win '95 PCs: provides the end user's access to Vienna's telephony services phones attached at My.Way 10 clients with STAs provides telephone connection to PC through the Serial Terminal Adapter Several Configuration tools provide system management. They are mentioned in the course of the discussion on installing Vienna components. In version l.O gateway connections to the PSTN, either directly or through a PBX, are all via ISDN (BRI).
Several types of calls are supported:

PC to PC - A to B, or B to D
PC to PSTN - B to C, or A to C
PSTN to PC - C to B or to A

trunk considerations:

PSTN to PC - for the call to be answered, a client must be configured to be attendant (see client section) - if the trunk is attached to a PBX, it is usually possible to program the PBX to look like a regular incoming trunk to the Vienna system, provided that PBX supports BRI

PC phone calls take place utilizing a telephone adapted to the PC via Vienna's Serial Terminal Adapter (STA) or through the PC's sound card.
A PC to PC call involves the dialing of a 4 digit number. Dialing through to the PSTN requires dialing a 9' to signal to the CPS that an CA 0221603~ 1998-08-27 outside line is required. We control these calls completely because they are placed on phones controlled by the My.Way client monitored by the central call processing server. An incoming call, from the PSTN, on the other hand, is not 'aware' of our internal numbering system. Until we add auto-attendant support within the product, we simply route such calls to designated My.Way phone(s) attendants.
The toll bypass application, which is a separate product, provides additional features, which are discussed in later sections. Amongst other things it covers off the missing variation from the list of call types above - PSTN to PSTN calls. Toll bypass i8 a separately orderable system.
The Vienna product line is poised to enter into the video conferencing arena, and other such functionality related to the virtual office. Currently, the step beyond voice/IP capability supported is the ability to easily launch NetMeeting from My.Way clients.
The diagram shows a corporate intranet. On the LHS is a corporate LAN with three PCs, a CP Server and one Vienna Gateway. Attached to the Vienna gateway is a trunk connected to a PBX, and a trunk connected directly to the PSTN. Many trunks can be connected to a gateway - system capacity is discussed in a separate section. There is a phone at C
attached to the PSTN. There is a Vienna phone attached through a Vienna STA at A. A, D and B are all running My.Way clients. D is using the PC
sound card to talk over the Vienna system. The network cloud indicating the corporate intranet could just as well be the Internet, provided the corporation has provisioned the public interfaces to its network that would allow this. (As we all experience, access to the Internet via an Internet service provider (ISP), does not provide us with automatic access to anybody's private corporate network).
Vi is used to edit the Vienna Gateway configuration file, which is an ASCII text file. The vi editor is being run via a remote Telnet session.
This remote Telnet session could be run from within anywhere on the corporate intranet. Each gateway must be configured separately (with a Telnet session, if remotely) with the vi editor accessing the ASCII
configuration file on that gateway.
VC Tool is a configuration tool with a GUI. It can be run remotely.
It is shown in Figure 2 running on a PC in the UK, accessing the central CA 0221603~ 1998-08-27 Vienna Database, (VDB), in Canada. It can run on any Windows '95 PC on the corporate intranet. It configures all the centrally held information for all gateways and My.Way users on the system. VDB is resident on the same machine as the CP Server.
The My.Way configuration tool i8 part of the My.Way client but it also targets the central VDB. Each end user that runs My.Way runs their own personalized configuration items - accessing the central VDB.
After installing the Vienna System, without toll bypass, the following features/capabilities are present:
General Features:

~ PC to PC calls - with 4 digit extensions in the range 1000-7999.

~ PC to PSTN calls - must dial 9 to indicate an outgoing call. If call is sent to certain PBX's, an extra 9 may have to be dialed.

~ Dialing #5 first allows the user to select the trunk group to dial out on. Dial: #5<trunk group number X local number>.
~ The interface to the PSTN is provided through BRI lines. Gateway BRI
lines can be connected to a PBX or directly to the PSTN.

~ PSTN to PC calls can be achieved indirectly - CP server recognizes all My.Way clients designated as attendants. The first attendant to pick up the call will get the call.

~ PC calls can use voice input via phone attached to the My.Way PC with Vienna' 8 STA, or via PC sound card. The attached phone must be a 2500 set with standard DTMF signaling.

~ Some measure of toll bypass can be achieved in any type of call, PC to PC - (A to B in system diagram), PC to PSTN - (B to C), PSTN to PC - C
to B). These calls all involve distances such that a PSTN toll call would otherwise have been involved. What we have called the toll bypass CA 0221603~ 1998-08-27 product i8 additional purchased functionality. When installed, toll bypass applications reside at a number of gateways.

My.Way Client features:

Several calls can be managed at a My.Way client. One call can be active, with n calls on hold. In version 1.0 call conferencing i6 not available. Basic call management i~ provided:

~ dial ~ answer ~ hang up ~ hold ~ retrieve ~ transfer ~ call forward ~ divert In addition:
~ any My.Way can be configured to be an attendant, receiving incoming calls from the PSTN
~ My.Way clients can participate in extension groups - this allows calls to be routed to a 'group' - e.g. a Help Desk group ~ a very important ability is the ability to very easily launch NetMeeting data conferencing software from within My.Way Configuration is a basic service provided by network management.
Understanding configuration also helps us to understand Vienna features in greater detail.
Most of the items below are fleshed out in greater detail in following sections. We are interested in configuration from the network and systems management perspective because we need to provide it as a i n; 1~ in any network management toolset that we provide. We focus on the data perspective of configuration - attempting to divorce Lnformation from CA 0221603~ 1998-08-27 the presentation that accesse6 it, or even the underlying architecture.
The diagrams in the following sections represent tables of configuration data. By abstracting configuration in this way we can more easily quantify and qualify system management requirements and or changes.

~ Configure Gateway ASCII text file with vi editor to know where server is, and configure other minor parameters such as the location of the log file.

~ Ping CP Server and any Gateways you intend to configure.
They must be up and running.

~ Check VDB process up and running. Start VDB if necessary.

~ With VC Tool :

~ Configure Gateways ~ Configure Clients ~ Configure Groups' ~ Exten~ion ~ Trunk ~ Subnet ~ Each client is configured as they are added to the system with the Configuration Component of My.Way Client.

CA 022l603~ l998-08-27 ~ B~C~
/
Gateway G.711 SC BUS
Gateway 1 Alaw/Mulaw Cards ~_~ 15 Gateway 2 Alaw/Mulaw Cards 1 - ~DSP C~ds Gateway 9 Alaw/Mulaw Cards 1 - 15 Resource DSP Load DSP 0 DTMF, lucent DSP

DSP 4 (opt daughter) DSP 5 (opt daughter) DSP 6 (opt daughter) DSP 7 (opt daughter) BRI Properties Circuit O enabled, SPIDS, tel #'s, PBX connect, frame sequencing, switch type, country, called party filtering Circuit 1 Circuit 2 Circuit 3 Circuit 4 Circuit 5 Circuit 6 Circuit 7 As the tables above imply, there are a number of gateways, and each gateway has a number of optional cards installed on it. The Digital Signal Processing (DSP) cards provide many services required at various stages of the call. For example, DTMF tone detection, encoding and decoding of voice data, echo cancellation, silence detection and supression. The BRI cards provide PSTN connectivity - either directly, or by attaching the circuit to a PBX. BRI service, not unlike telephone service, i5 provisioned from a telco.

CA 0221603~ 1998-08-27 Configuring the hardware i5 straightforward. Almost all of the configuration is dictated by the service purchased, or the physical location in which the gateway resides. There are three exceptions:

BRI circuit attached to a PBX or not BRI trunk enabled (present) or not called party filtering (whether to reject calls that have called information that does not agree with the BRI number) All of the rest of the BRI configuration items - SPIDS, tel#s, frame sequencing, switch type, and country are determined by the service purchased or your location. A-law or Mulaw encoding, the only configuration item at the gateway, is determined by the country you are in.
It is worthy of note that support for PBX i6 just a yes/no item on the BRI circuit configuration. The check box here tells the ISDN stack that the trunk in question is connected to a PBX and is the only PBX
configuration item in the system. We provide little direct PBX support.
Conceptually, we are not passing a call into a PBX, we are passing a call through the PBX. In an ideal world the PBX trunk looks just like any other trunk to the eyetem. We do not directly eupport PBX featuree. It ie not our intention to provide deeper PBX eupport when we add T1 initially. For now, we will have that level of configuration required to make a trunk coming from a PBX, or a trunk attached directly to the PSTN, conceptually the eame.
DSP configuration ieeuee are discussed in the next eection.
As we noted in the previous section, DSP resources provide the services required to provide call services such as DTMF tone detection during various phases of the call. Up to 8 DSP resources can be installed on a single DSP card, depending on whether a DSP daughter card is present.
(If not, there are 4 DSP resources). These resources are used in various phases of the call, as they come and go on the system.
Each DSP is configured to accept a particular DSP load. The DSP load determines what services it can provide the various phases of a call:

CA 0221603~ 1998-08-27 A DTMF load provides DTMF tone detection when toll bypass is handling a call. When this resource is in use it means that DTMF signals on the line can be recognized and understood. Currently, DTMF resources are used only at call setup time and then released.

A Lucent l oad provides Lucent compression/decompression on the call.
We have licensed this technology from Lucent. This resource is used during the entirety of the call.

A g. 711 l oad provides the service required for uncompressed calls on the network.

Generally, the administrator will want to configure the Vienna system so that calls on the same subnet, or between high bandwidth links, will use uncompressed voice - i.e. the g.711 codec. (There is some debate about this because apparently compressed voice is very good quality - and less data on the network is always a good thing.) The administrator will generally configure the system so that calls between gateways on different subnets will use compression - i.e. the Lucent codec.
To complicate thing~, one load with smc capability must also be present per gateway. It has been combined with Lucent and DTMF
functionality. The load choices are:

g.711 - used during the duration of calls with no compression - can handle 6 simultaneous calls Lucent - can provide Lucent compression/decompression on 2 simultaneous SmcDTMF - has smc and can also provide DTMF detection on 16 simultaneous calls SmcLucent - has smc and can provide Lucent compression decompression on 2 simultaneous calls Supposing you had a single DSP card with 4 DSP chip~ on it. Then your choices would be:

CA 022l603~ l998-08-27 (1 SmcDTMF OR 1 SmcLucent) AND 0-3 (Lucent OR g.711) As an example: Suppose you choose 1 SmcDTMF load, and 3 g.711 loads - you would have the capacity required to support DTMF detection on 16 simultaneous calls and the ability to handle 18 simultaneous uncompressed calls. This balance might be okay for a single gateway where only uncompressed calls are used since it is unlikely that all 16 calls would be in the same phase at the same time.

Note 1: Currently we are considering changing the system requirements for DTMF resources. The plan is to detect DTMF at any time during the call.
This makes sense because DTMF tones are frequently generated after call setup when a telephone answering systems answers the call. Since these tones do not survive well in transmission over the IP network, the plan is to detect DTMF, suppress it, and regenerate it at the other end of the call. This means that DTMF resources are required for the duration of the call. Obviously, the DTMF loads will have to change to support this since with the current structure this would limit a gateway to 16 calls. (One smc load per gateway, all calls require a DTMF resource.) Note 2: We also sell the Voxware codec. A disk is provided that loads the codec over the Lucent codec after the system is installed.

A very superficial treatment i5 given here of these configuration items as they are largely self evident.

Client Pl.r lics Username 1 pa~wu~ directory name, ~ n~ion, power offforward, class of service Username 2 Username 3 Username 4 . . .
Username usedfor aufhenhcation Password usedfor authentication Directory Name name used within the telephone directory Fxt~n~ion user 's 4 digit extension number Power offForward what to do if My. Way is disabled Class of Service class of serl~ice name - see below CA 0221603~ 1998-08-27 C ass of Semce r~O~ S
C ass 1 dialing r~ctri~tionc, pd~:iwol~l restrictions, off hook type, default trunk group C:ass 2 Cass3 C: ass 4 . . .
Creating a class of service allows the system administrator to apply a set of user privileges to a group of users.

Dialing Restrictions whether user has access to outside and/or access to long distance service Password Restrictions the length of time password is active Off-Hook Type whether the user automatically gets an outside line or not when they pick up the receiver Default Trunk Group trunk group from which to select an outside line for all PSTN calls You will recall that My.Way clients can be configured to be part of a group, so that calls can be directed on a departmental basis - e.g. the Help Desk Department. This is where this feature is configured. Extension groups work by utilizing special Extensions 8500-8599, which associate a 20 number of clients with the same extension. When CP Server sees a number within this range, it looks for the characteristics of the extension group and directs the call accordingly. The ring hunt type specifies whether the hunt for a free extension runs in a continuous loop left at the last allocated call, or always starts from the top of the list looking for a free extensions.

CA 022l603~ l998-08-27 Extension Group Ring Hunt My.Way Clients Number Extension group ring hunt (list of My.Way clients) number A type Extension group number B
Extension group number X
Extension group number ~

You will recall that My.Way clients can be configured to have an associated trunk group. When a My.Way client attempts to make an outgoing call, an outgoing trunk must be selected. A trunk group specifies a number of trunks that can be selected for an outgoing call. This group can then be assigned to any number of My.Way clients. Trunk groups are numbered 400 - 799. Each trunk group simply associates a number of trunks.
Any trunk from anywhere on the system can be allocated to a particular trunk group. Ring hunt type as for extension groups.

Trunk Group Number Ring Hunt Properties Trunk group number A ring hunt ring hunt type, group type members Trunk group number B
Trunk group number X
Trunk group number ~

Subnet groups provide a mechanism for the system administrator to control whether a code is used or not on a call. The algorithm is very simple. When a call is set up on the CP Server, the IP address of the caller and the IP address of the callee become know. (Even if not until an attendant answers the call. . .). The algorithm i9 ag followg:

IF the IP addresses are in different subnet groups, compress the call with the Lucent codec (Voxware, if a Voxware system).
ELSE use g.711 encoding and don't compress the call CA 0221603~ 1998-08-27 Subnet Group Properties subnet group A group members ¦M~nb~
subnet group B
subnet group X
subnet group ~

Subnet Group subnet group name Group Members a set of subnet/netmask pairs Subnet Group A Properties Member A (Subnet/Netmask, Subnet/Netmask . . .) Member B
Member X

A number of client specific features are set with My.Way configuration. Most of the configuration items below are in the category of user preferences, or are dictated by the setup - for example whether the client is dial up or not, whether the client is using the sound card or Vienna phone. The one exception i9 'Attendant Console'. This feature allowe incoming calls to be directed to the My.Way client.

Client Properties clientl Display features, audio features, telephony/network options, address book, speed button config client 2 client 3 You will recall that in the non toll bypass Vienna system, incoming calls from the PSTN are routed to the My.Way clients that have been designated as attendants. With toll bypass installed, incoming calls on designated trunks are automatically authenticated and routed through the Vienna system to a desired gateway. The system has been designed so that CA 0221603~ 1998-08-27 routing and authentication options can be programmed by the provider, or the Vienna default authentication and routing capabilities can be used.
This extends the basic capabilities of the system to allow for PSTN to PSTN
calls, so that, for example, an ISP can provide long distance telephone service to clients. The same authentication and routing services are also available for PSTN to PC calle when toll bypass is installed.
The toll bypass application enables callers to bypass standard long distance telephone calls by utilizing the nearest Vienna gateway system, and passing the call over the IP network through to the Vienna PSTN gateway with a PSTN connection closest to the caller's desired destination. As in the non toll bypass system, all calls are orchestrated by the CP Server.
Please refer to the next section, where toll bypass applications have been added to the system diagram.
Toll bypaes applications reside on a Vienna gateway which is going to accept incoming toll bypass calls. Each application monitors a specified range of incoming trunks. In this way, different routing and authentication methods can be designated for different sets of incoming trunks. The Vienna Services Node provides a flexible mechanism for authenticating, routing and billing the incoming call. One Services Node provides centralized call authentication, routing and billing information services for the entire system. It can reside on a separate node, or on the same node as a toll bypass application. There is a default version of the Vienna Services Node which is shipped with the product. The Services Node's published RPC (remote procedure call) interface allows customers to completely customize their routing, authentication and billing services.
The toll bypass applications are added to Gateways which will accept incoming toll bypa~s calls. There is no need to install toll bypass on gateway~ where only outgoing calls will pass - since the capability to pass an outgoing call to a gateway is part of the Vienna system without toll bypass installed. When toll bypass is installed:

the toll bypass application(s): -monitor incoming calls on specified trunk ranges CA 0221603~ 1998-08-27 -plays IVR messages such as those requesting digits a.s.o. using g.711 encoding -collects up to 2 sets of DTMF digits (authentication and called number) -passes CDRs, (call detail records) to Services Node when the call ends -keeps local CDRs 10 the Services Node: -accepts and verifles 2 sets of DTMF digits -(trunk #, and local# by default) -provides trunk #, local # and sends them to the CP Server -utilizes it's algorithms for least cost routing a.s.o. in the latter mentioned step -keeps centralized CDR (Call Detail Records) -can run on a separate machine And, as before in the system without toll bypass:
CP Server (Call Processing server): provides call orchestration and routing - 1 per system Gateways (GW on diagram): provide the interface to the PSTN
- n per system My.Way clients on Win '95 PCs: provides the end uaer's access to Vienna's telephony services phones attached at My.Way clients with STAs: provides telephone connection to PC through the STA

As shown in Figure 3:
PC to PC calls remain unchanged PC to PSTN calls remain unchanged PSTN to PC:

CA 0221603~ 1998-08-27 if call in to the system will be through a trunk not assigned to toll bypass, behaviour is as if toll bypass is not present if a call in to a 4 digit number is placed onto a trunk being monitored by toll bypass the call will behave according to the dictates of the Services Node routing table (l.e. the 4 digit route must be in the routing table) PSTN to PSTN calls -described below An incoming call goes through several states. It gets answered, authenticated, and routed. At each call stage, the Services Node is sent information, and it replies with an indication as to what to do next. The API to the Vienna Services Node is a published API - meAn i ng that customers can provide their own authentication and billing instructions. A default Services Node is shipped with the Vienna toll bypass application software.
It expects a gateway number at the authentication stage, and the local number at the routing stage.
At the authentication and routing stages, called and calling party information or DTMF tone generated information can be used. (To use called and calling party information, the information has to be provided (perhaps purchased) from the CO.) For example, an incoming caller can be authenticated based on an entered DTMF passcode - or based on the callers number which is passed to the system automatically from the telco. Or perhaps not authenticated at all.
The Services Node Configuration tool configures the services node and sets up the authorization and routing files that are used by all gateways running toll bypass. This configuration tool is in addition to all the configuration noted earlier for the non toll bypass application.
After in~talling the Vienna Toll Bypass Subsystem, without toll bypass, the following features/capabilities are present:
~ multiple toll bypass applications on each gateway allow different routing and authentication for different sets of incoming trunks ~ central Vienna Services Node - for billing, authentication, Call Detail Records (CDR) CA 0221603~ 1998-08-27 ~ CDRs are optionally collected at each gateway (for its incoming calls) ~ length of call monitoring with call warning at administrator defined time-out period ~ publiehed Services Node API allowing for customer specific authentication and routing ~ Services Node for authentication and routing i9 DTMF or called info ~ the Services Node is very flexible allowing each step in the answer process to be programmed or skipped ~ authorization and routing is available for phone to PC calls ~ calls can be suspended for maintenance on the server ~ default Services Node routes based on trunk and local number ~ Services Node translation table can be can establish a private numbering plan or E.164 type numbering system Here is an overview of the configuration procedure:

~ Configure the Services Node:

~ location of error log file ~ location of CDR file ~ location of authentication files available to toll bypass applications ~ location of routing files available to toll bypass applications ~ enable/disable global call time-out monitoring ~ enable/disable global CDR recording CA 0221603~ 1998-08-27 ~ Configure Service Groups:

~ configure the range of trunks to be monitored by the toll bypa6s app ~ configure authorization and routing options ~ configure location of Services Node ~ configure AVI messages to be played ~ configure digit collection properties ~ configure call monitoring properties ~ location of local CDR file While particular embodiments of the invention have been described and illustrated it will be apparent to one skilled in the art that numerous changes can be implemented. It is to be understood that all such changes will fall within the scope of the invention as defined by the appended claims.

CA 022l603~ l998-08-27 Glossary 2500 set The "normal" single-line touch-tone desk telephone. It replaced the old 500 sets that had the rotary dial (and did dial pulse signaling).

Alaw The voice coding standard used in Europe, New Zealand and Australia for coding the analog signal into a digital bit stream.

analog voice signal A non digital voice transmission method. Basically, signals generated in analog transmi~sion are analogous to the signal input.
The telephone in your house generates analog signals. As opposed to the signal encoding used in digital transmission.

API Application Programming Interface A programming interface for developers that provides an abstraction of the service provided by the product the interface supports. It is the way that the developer obtains access to the service or application functionality provided by the interface.
BRI Basic Rate Interface ISDN. A type of ISDN service that provides 2 B
channels and one D channel per physical connection. A Vienna ISDN card provides support fo 8 BRI circuits with 8 physical connectors. An ISDN B
channel can handle one call, meaning that 16 calls are supported with one Vienna BRI interface.

CDR Call Detail Record. The record containing the details of a call.

codec COmpression/DECompression. Compresses and decompresses analog voice signals to the digital form required for digital transmission systems - the Internet is one. Codec is also used to refer to coding/decoding in general. For example g.711 is a codec (coding/decoding) technique that does not provide compression.

CA 0221603~ 1998-08-27 corporate intranet An IP network internal to a company that offers similar features and services as the Internet. External users generally have no access to a company's Intranet.

DSP Digital Signal Processor A programmable device for sampling and modifying electrical signals. CD players, electronic music synthesizers, and PC sound cards are examples of devices using DSPs to produce audio effects.
DTMF Dual Tone Multi Frequency. The tones generated by pressing the buttons on a standard telephone handset. These tones are used by the Toll Bypass system to collect digits for authorization codes and dialed phone numbers .

E.164 A standard for assigning numbers to telephone lines put forth by the CCITT, an international standards body.

G.711 An algorithm used for digital telephone sets on digital PBX andISDN channels which produces digital audio at 64 Kbps. This is the algorithm used by Vienna for uncompressed voice transmission.

Internet The world's largest computer network. The world's largest experiment in anarchy. That which we know as the Internet. Difficult to define, but basically a huge, public TCP/IP network, the most recent face of which is provided by WEB browsers such as Internet Explorer and Netscape, with service purchase by Internet Service Providers.

intranet - see corporate intranet IP - see TCP/IP

ISDN (integrated services digital network) An international telec~ lnications standard for transmitting voice, video, and data over digital lines running at 64K-bps. ISDN uses circuit-switched bearer CA 0221603~ 1998-08-27 channels (B channels) to carry voice and data and a separate data channel (D channel) for control signals and slower speed data via a packet-switched network. This out-of-band D channel allows for features such as call forwarding, call waiting, and advice of charge.

ISP - Internet Service Provider A company that provides access to the Internet to end users and corporations.

IVR Interactive Voice Response. This i5 the method of walking a caller through the process of entering account numbers and phone numbers. When a caller phones into the local gateway the service provider can record a set of voice messages and prompts that will ask the caller to enter the required information to establish a call.

Lucent or Lucent Codec A compression decompression codec licensed to Vienna from the Lucent corporation. It provides 7.3kb compression.

Mulaw The voice coding standard not used primarily in Japan and North America for coding the analog signal into a digital bit stream.
PBX Private Branch Exchange. This refers to a switch used by a private company to route phone calls internally at their place of business. These private switches can be connected together to create a private network.
These switches are also usually connected to the PSTN to enable callers to phone from their business to external phone numbers.

PRI Primary Rate Interface ISDN. A type of ISDN service that provides ISDN circuits with 1 physical connector. Each circuit has 23 B channels and one D channel. Each B channel can handle one call, m~Ani n9 that 23 calls are supported with one PRI interface. In Europe and other places, PRI service has 30, instead of 23, B channels.

PSTN - Public Switched Telephone Network The telephone network. The one that you use every day when you pick up the phone.

CA 0221603~ 1998-08-27 smc - Signaling Message Channel ZZZ

SNMP Simple Network Management Protocol SNMP is part of the TCP/IP
protocol suite. It is a widely adopted protocol used for network management.

STA Serial Terminal Adapter The Vienna adapter allows the my.way client to adapt their telephone to the PC. You plug your telephone into it and it connects to a serial port of your PC. It also supports a connection to the PBX so that if you are not using your My.Way client. Your phone is attached instead to the PBX.

Tl or T-l A type of digital transmission link. It's capacity is 1.544 Mbits/6. A Tl link has the capacity to service 24 simultaneous 64 Kbps calls. (El is the European counterpart and runs at 2.048Mbits/s.) TCP/IP Transmission Control Protocol/Internet Protocol A set of protocols for intercommunicating between networked computers. As the name implies, it is the adopted protocol of the Internet which is the basis of the WWW (World Wide Wed) and so on.

telco A telephone company. Like Bell Canada or BC Tel or one of the RBOCs in the state (Regional Bell Operating Company).

Telnet A program that allows you to connect to other computers that support Telnet on the Internet. It allows you to have a remote terminal session with the targeted computer. The user interface capability is very limited.

toll bypass call A call placed over the Internet that would have otherwise involved long distance charges.

toll bypass application Vienna Systems add on application that monitors designated groups of trunks on a Vienna Gateway and provides for the CA 0221603~ 1998-08-27 flexible authenticating and routing of toll bypass calls between Vienna gateways.

Trunk A trunk is a communication line between two switching sy~tems.
For our purposes a trunk is one BRI B channel, or 1 T1 channel. Each can service a single call.

Claims (17)

1. In a computer environment, a call processing server having a software application interfacing with a computer-based network and the public switched telephone network (PSTN) to provide access therebetween.
2. A call processing server as defined in claim 1 wherein said computer-based network is the Internet.
3. A call processing server as defined in claim 1 wherein said computer-based network is an Intranet.
4. A call processing server as defined in claim 1 providing voice over said computer base network and said PSTN.
5. A call processing server as defined in claim 1 providing facsimile service over said computer-based network and said PSTN.
6. A call processing server as defined in claim 1 providing video over said computer-based network and said PSTN.
7. A call processing server as defined in claim 1 providing document collaboration over said computer-based network and said PSTN.
8. A call processing server as defined in claim 1 providing telephony service over said computer-based network and said PSTN.
9. A call processing server as defined in claim 1 providing PABX systems over said computer-based network and said PSTN.
10. A call processing server as defined in claim 1 wherein said computer environment includes a multimedia personal computer and said application software includes Windows 95 and Windows NT.
11. A call processing server as defined in claim 1 providing call processing features.
12. A call processing server as defined in claim 11 wherein said call processing features include call transfer.
13. A call processing server as defined in claim 11 wherein said call processing features include call forwarding.
14. A call processing server as defined in claim 11 wherein said call processing features include conference calling.
15. A call processing server as defined in claim 1 being scaleable to commercial and industrial environments.
16. A call processing server as defined in claim 15 providing access to PSTN gateways in said computer-base network.
17. A call processing server as defined in claim 1 providing support for computer-telephony application development.
CA002216035A 1997-09-17 1997-09-17 Ip-pstn call processing server Abandoned CA2216035A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CA002216035A CA2216035A1 (en) 1997-09-17 1997-09-17 Ip-pstn call processing server

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CA002216035A CA2216035A1 (en) 1997-09-17 1997-09-17 Ip-pstn call processing server

Publications (1)

Publication Number Publication Date
CA2216035A1 true CA2216035A1 (en) 1999-03-17

Family

ID=29275034

Family Applications (1)

Application Number Title Priority Date Filing Date
CA002216035A Abandoned CA2216035A1 (en) 1997-09-17 1997-09-17 Ip-pstn call processing server

Country Status (1)

Country Link
CA (1) CA2216035A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8077844B2 (en) 1996-08-26 2011-12-13 Xugave Holding De Llc Dial up telephone conferencing system controlled by an online computer network

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8077844B2 (en) 1996-08-26 2011-12-13 Xugave Holding De Llc Dial up telephone conferencing system controlled by an online computer network
US8855278B2 (en) 1996-08-26 2014-10-07 Xugave Holding De Llc Dial up telephone conferencing system controlled by an online computer network

Similar Documents

Publication Publication Date Title
CA2256728C (en) A telephone doubler arrangement
US6804224B1 (en) System and method for providing telephone service having private branch exchange features in a voice-over-data network telephony system
US9942410B2 (en) Controller for the intelligent interconnection of two communication networks, and method of use for same
US5742596A (en) Network based distributed PBX system
US8036208B2 (en) Telephone network interface bridge between data telephony networks and dedicated connection telephony networks
US9264544B2 (en) Automated attendant multimedia session
WO2001080470A1 (en) System providing integrated services over a computer network
CA2270047A1 (en) Method and apparatus for selecting one voice gateway from multitude of voice gateways, which shall serve a remote application
KR20100044203A (en) Method, modem and server for bridging telephone calls into internet calls
US7016675B1 (en) System and method for controlling telephone service using a wireless personal information device
US6937703B1 (en) Connection of a computer to a telephone exchange
JP3002667B2 (en) Call system
JP2001127883A (en) Internet telephone system
CA2216035A1 (en) Ip-pstn call processing server
CA2303840A1 (en) System and method for integrating voice on network with traditional telephony
KR20030063063A (en) Method and Apparatus for Exchanging a Rout of Telephone Call by Using an IP-PBX
EP1290818B1 (en) System providing integrated services over a computer network
JP2002101232A (en) Talking system using internets
MXPA99011647A (en) Telecommunication system

Legal Events

Date Code Title Description
FZDE Discontinued