U.S. patent application number 11/498409 was filed with the patent office on 2007-05-31 for system and method for providing call management services in a virtual private network using voice or video over internet protocol.
This patent application is currently assigned to Westell Technologies, Inc.. Invention is credited to Paul V. Harrington, Rodger D. Higgins, William J. Noll, George W. Turner.
Application Number | 20070121590 11/498409 |
Document ID | / |
Family ID | 38015799 |
Filed Date | 2007-05-31 |
United States Patent
Application |
20070121590 |
Kind Code |
A1 |
Turner; George W. ; et
al. |
May 31, 2007 |
System and method for providing call management services in a
virtual private network using voice or video over Internet
protocol
Abstract
A system and method for providing call management services in a
Virtual Private Network of the present invention uses the
advantages of end-to-end Internet Protocol signaling. The system
and method of the present invention includes a user profile which
offers both a customer address and a user name as search keys. The
method includes locating the called party who may be at a
multiplicity of possible physical locations, evaluating the calling
and called party privileges, routing preferences and busy/idle
status for establishing permission to set up the call, determining
an optimum route to establish the telephone call. Due to the system
and method of the present invention, the telephone call takes the
optimum route and preferably the most direct route to the
destination with a high probability of completion.
Inventors: |
Turner; George W.; (Nepean,
CA) ; Noll; William J.; (Bristol, IL) ;
Harrington; Paul V.; (Naperville, IL) ; Higgins;
Rodger D.; (Aurora, IL) |
Correspondence
Address: |
MCDONNELL BOEHNEN HULBERT & BERGHOFF LLP
300 S. WACKER DRIVE
32ND FLOOR
CHICAGO
IL
60606
US
|
Assignee: |
Westell Technologies, Inc.
Aurora
IL
|
Family ID: |
38015799 |
Appl. No.: |
11/498409 |
Filed: |
August 3, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09739716 |
Dec 18, 2000 |
|
|
|
11498409 |
Aug 3, 2006 |
|
|
|
Current U.S.
Class: |
370/352 |
Current CPC
Class: |
H04M 7/006 20130101;
H04L 61/157 20130101; H04L 61/1547 20130101; H04L 29/12122
20130101; H04L 29/1216 20130101; H04L 12/66 20130101; H04M 7/009
20130101 |
Class at
Publication: |
370/352 |
International
Class: |
H04L 12/66 20060101
H04L012/66 |
Claims
1-50. (canceled)
51. A method for allowing a calling party to influence a call
routing decision prior to call completion, comprising in
combination: receiving a call request for a subscriber from a
calling party; determining that the subscriber is not available;
invoking a logic tree to determine what options are available for
routing a call, wherein the logic tree matches data associated with
the subscriber and data associated with the calling party to
determine what options are available; and providing the calling
party with the available options prior to establishing the call in
a signaling message.
52. The method of claim 51, wherein determining that the subscriber
is not available includes determining that the subscriber is
currently on a call, has invoked a call forwarding feature, or has
invoked a restricting feature.
53. The method of claim 51, wherein the data associated with the
subscriber includes routing preferences, bandwidth reservation, and
overriding busy status.
54. The method of claim 51, wherein the data associated with the
calling party includes an identification of the calling party's
work group and role within the work group.
55. The method of claim 51, wherein the options are selected from
the group consisting of terminating the call request, redirecting
the call request, and completing the call request.
56. The method of claim 55, wherein redirecting the call request
includes redirecting the call request to a destination selected
from the group consisting of another number associated with the
subscriber, a number associated with a current location of the
subscriber, a number associated with another person, a call
attendant, and a voice messaging system.
57. The method of claim 55, wherein completing the call request
includes interrupting an active call that includes the
subscriber.
58. The method of claim 51, wherein the logic tree receives the
data associated with the subscriber and the calling party via
Session Initiation Protocol messaging.
59. The method of claim 51, further comprising receiving from the
calling party a selection of one of the available options for
routing the call and routing the call based on the selection.
60. A method for providing call management services in a wired
Virtual Private Network that supports user mobility, comprising in
combination: receiving a call request for a subscriber roaming in
the wired Virtual Private Network, wherein the call request
includes at least one of a name and a first number assigned to the
subscriber, and wherein the subscriber has registered his current
location in the network using a second number assigned to the
location; translating the at least one name and first number
assigned to the subscriber to the second number assigned to the
location; obtaining a profile for the subscriber using the at least
one of a name and a first number assigned to the subscriber; and
completing the call request at the subscriber's current location
based on the profile.
61. The method of claim 60, further comprising determining whether
the subscriber is present in the Virtual Private Network.
62. The method of claim 60, wherein the subscriber registers his
current endpoint by providing the first number and a password prior
to receiving the call request.
63. The method of claim 60, wherein the endpoint is assigned to
another subscriber in the network.
64. The method of claim 60, wherein the subscriber's profile
includes routing preferences, bandwidth reservation, overriding a
busy status.
65. The method of claim 60, wherein the subscriber's profile is
located in a centralized database that maintains subscriber
profiles for subscribers of the network.
66. The method of claim 65, wherein the centralized database
arranges the subscriber profiles in a hierarchy.
67. The method of claim 60, wherein obtaining a profile for the
subscriber includes performing a query of a directory server.
68. The method of claim 60, wherein obtaining a profile for the
subscriber includes propagating information within a call setup
message.
69. The method of claim 60, further comprising assigning the
endpoint to the subscriber.
70. The method of claim 60, further comprising associating the
subscriber's profile with the second number assigned to the
endpoint.
71. The method of claim 60, wherein the second number serves as a
global address for location management within the network.
72. The method of claim 71, wherein the global address is stored in
the subscriber's profile.
73. The method of claim 60, wherein the second number is provided
to a Public Switched Telephone Network as a caller
identification.
74. A telephone network system for providing call management
services, comprising in combination: a call agent that receives a
call request from a calling party for a subscriber of a wired
network, wherein the call request includes at least one of a name
and a number associated with the subscriber; a directory server
that translates the at least one name and number associated with
the subscriber into a current network address, wherein the current
network address is a number associated with a physical location of
the subscriber in the wired network; and a portability server that
provides the subscriber's current network address to the directory
server.
75. The system of claim 74, wherein the portability server allows
the subscriber to identify his current physical location in the
wired network.
76. The system of claim 74, wherein the directory server matches
preferences and privileges of the calling party and the subscriber
prior to completing a call.
77. The system of claim 74, wherein the directory server downloads
service logic from a centralized database to the call agent.
78. The system of claim 74, wherein the call agent is assigned to a
gateway, and controls and manages data for the gateway.
79. The system of claim 78, wherein the call agent assigned to the
gateway exchanges signaling messages with another call agent
assigned to another gateway to set up inter-gateway calls.
Description
FIELD OF THE INVENTION
[0001] This present invention relates to a system and method for
providing communication services over a network. More specifically,
it relates to Call Management Services in a Virtual Private Network
using Voice or Video over Internet Protocol.
BACKGROUND OF THE INVENTION
[0002] Call Management Services (CMS) allow the calling and called
parties to exercise control over call set-up functions within a
network. Call set-up includes dialing, wait time and time to move
through central offices and long distance services. Typically,
there are both originating and terminating versions of these Call
Management Services. Originating versions address decisions such as
which route to take to complete the call, or what action to take
upon encountering a busy signal. Terminating versions include the
ability to selectively ignore calls, or route them to a handling
mechanism. The handling mechanism provides for a treatment for a
call and results in an outcome other than a successful call
completion to the desired party. It includes, but is not limited to
a busy signal, message service, attendant or administrative
assistant answering.
[0003] Call Management Services are widely deployed in the Public
Switched Telephone Network, having been marketed for many years
under the acronym CLASS.sup.SM, which stands for Custom Local Area
Signaling Services. Most private networks, such as Virtual Private
Networks (VPN), have deployed proprietary versions of these
services, which function in an equivalent manner using capabilities
of the current Signaling System 7 (SS7). Virtual Private Networking
is a widely deployed generic business service offering which
provides customers with a closed user group environment across a
plurality of physical locations. There are several subsets of
Virtual Private Networking, one of the better-known being Wide Area
Centrex (WAC). The CLASS services include Automatic Recall (AR),
Automatic Callback (AC), Selective Call Forwarding (SCF), Selective
Call Acceptance, Selective Call Rejection (SCR), and the variations
thereof. Automatic Callback and Automatic Recall are similar
services. Automatic Recall attempts to call back the last party who
called the customer, where as Automatic Callback is invoked during
an initial attempt by the customer when a busy line is encountered.
Automatic Recall is typically not used in private networks since
these networks strive to provide a correct disposition for all
incoming calls.
[0004] Traditional Call Management Services suffer from several
serious shortcomings such as: 1) the features are invoked after the
network has made major routing decisions, for example, a call is
allowed to progress through the network to the called party's line
before it is redirected; 2) the features recognize calling and
called network interface points or endpoints instead of specific
users, making them useless and inappropriate in an environment
where users roam amongst a multiplicity of network interface
points; 3) the end-to-end signaling capability is limited by
antiquated technology; and 4) service portability, the ability to
roam while retaining access to personalized CMS features, is not
supported.
[0005] Several Voice or Video over Internet Protocol (VoIP)
telephony solutions have been proposed and/or implemented. However,
these solutions tend to emphasize the new capabilities provided by
Internet Protocol technology, such as multimedia integration,
rather than addressing improvements to existing call-based
services. Moreover, these solutions often introduce questionable
practices which may undermine the Quality of Service (QoS) to which
business customers have become accustomed. Overly aggressive,
compression of bandwidth, lack of regard for the scarcity of global
Internet Protocol addresses, or alerting the target station or
endpoint before call completion is guaranteed are a few examples of
some of the issues that result from current solutions.
[0006] Therefore, it is desirable to enhance Call Management
Services to overcome various shortcomings of the present day
services and to extend these enhancements to cover new multimedia
calls, without jeopardizing Quality of Service (QoS).
SUMMARY OF THE INVENTION
[0007] The system and method of the present invention takes full
advantage of end-to-end Internet Protocol signaling in order to
enhance Call Management Services capability for both calling and
called parties. This is accomplished while allowing the user
continued use of a conventional circuit-switched voice transport
network, such as the Public Switched Telephone Network (PSTN), to
guarantee the Quality of Service (QoS) that Virtual Private Network
(VPN) users have come to expect.
[0008] The system and method of the present invention uses a
two-layer numbering scheme. The first or lower layer comprises the
Directory Numbers from the North American Numbering Plan (NANP), as
assigned by a Local Exchange Carrier (LEC) or a neutral Industry
number administrator. These may be, for example, geographic
numbers, permanently associated with a specific rate center. This
base layer is translated into a physical local Internet address
associated with an endpoint or other network termination point
within the VPN. The second or higher layer of numbers identifying
individual users, are assigned by the customer's administrator, and
remain with these users wherever they are located in the network.
The Directory Numbers (DN) are also the Network Addresses (NA). The
artificial numbers assigned to specific users are the Customer
Addresses (CA). A Directory Server performs the translation from
Customer Address to Network Address and vice versa.
[0009] The system and method of the present invention includes a
user profile which offers both the Customer Addresses (CA) and the
user name as search keys. These fields are linked and normalized
within the signaling mechanism to the CA which allows the calling
and called users to opt for the identifier of their choice. In
addition, a caller with an appropriate alphanumeric terminal can
enter user names instead of Customer Addresses to reach the called
party.
[0010] In accordance with a preferred embodiment, the method for
providing Call Management Services in a Virtual Private Network
using Voice or Video over Internet Protocol (VOIP) includes a
multi-step process for setting up a call, which is assumed to
involve customers located at two different private network
switching nodes. It should be noted that VoIP may also include a
hybrid call comprising voice, video and data elements. The method
includes locating the called party who may be at a multiplicity of
possible physical locations at the normal site, or in an
environment where users can roam; evaluating the calling and called
party privileges, routing preferences, and busy/idle status for
establishing permission, herein after known as the matching
decision, to set up the call; determining the optimum route, herein
after known as the routing decision, and the appropriate technology
such as, Voice or Video over Internet Protocol versus Public
Switched, or a hybrid of both, Telephone Network (PSTN), to set up
the voice and video paths; and establishing the voice transport
path and matching the actual incoming call with the anticipated
call at the terminating network interface point. Only in the final
step of this process is there an actual attempt to establish a
telephone call in the conventional sense.
[0011] Some of the benefits provided by the system and method of
the present invention include the call taking the most direct route
to the most appropriate destination with a high probability of
completion. By offering the option of either IP or PSTN call
completion, with equivalent feature functionality, Quality of
Service is as good or better than with a traditional
circuit-switched Virtual Private Network. Methods are provided to
conserve scarce global resources such as PSTN Directory Numbers and
global IP addresses. The foregoing and other features and
advantages of the system and method for providing Call Management
Services in a Virtual Private Network using Voice or Video over
Internet Protocol will be apparent from the following more
particular description of preferred embodiments of the system and
method as illustrated in the accompanying drawings in which like
reference characters refer to the same parts throughout the
different views.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] Preferred embodiments of the present invention are described
with reference to the following drawings, wherein:
[0013] FIG. 1 is a diagram illustrating a preferred embodiment of
the network topology of the system for providing Call Management
Services in a Virtual Private Network in accordance with the
present invention;
[0014] FIGS. 2A and 2B are diagrams illustrating the Directory
Server data structure in accordance with a preferred embodiment of
the present invention;
[0015] FIG. 3 is a diagram illustrating Directory Server
translations and attribute fields in accordance with a preferred
embodiment of the present invention;
[0016] FIGS. 4A-4C are flowcharts illustrating a method for
handling intra-gateway calls in accordance with a preferred
embodiment of the present invention;
[0017] FIGS. 5A-5C are flowcharts illustrating a method for
handling inter-gateway calls in accordance with a preferred
embodiment of the present invention;
[0018] FIGS. 6A-6D are flowcharts illustrating a method for
handling incoming external calls in accordance with a preferred
embodiment of the present invention;
[0019] FIGS. 7A and 7B are flowcharts illustrating a method for a
matching decision in accordance with a preferred embodiment of the
present invention;
[0020] FIG. 8 is a flowchart illustrating a method for a routing
decision in accordance with a preferred embodiment of the present
invention;
[0021] FIG. 9 is a flowchart illustrating a method for a
translation decision in accordance with a preferred embodiment of
the present invention;
[0022] FIGS. 10A-10C are flowcharts illustrating a method for
implementing service portability in accordance with a preferred
embodiment of the present invention;
[0023] FIG. 11 is a flowchart illustrating a method for
implementing service portability for an outgoing call in accordance
with a preferred embodiment of the present invention;
[0024] FIG. 12 is a flowchart illustrating a method for
implementing service portability for an incoming call from a Public
Switched Telephone Network using a Directory Server process in
accordance with a preferred embodiment of the present invention;
and
[0025] FIGS. 13A and 13B are flowcharts illustrating a method for
default routing upon Internet Protocol (IP) network failure in
accordance with a preferred embodiment of the present
invention.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
[0026] The present invention is directed to a system and method for
providing Call Management Services (CMS) in a Virtual Private
Network (VPN) using Voice or Video over Internet Protocol (VoIP).
It should be noted that "VoIP" refers to voice or video over
Internet Protocol, or a hybrid call comprising voice, video, and
data elements. Virtual Private Network system and method using
Voice over Internet Protocol is described in an application by
George W. Turner et al., filed on Aug. 10, 2000 which corresponds
to U.S. Ser. No. 09/636,191, the entire teachings of which is
incorporated herein by reference.
Call Handling Network Topology
[0027] FIG. 1 is a diagram illustrating a network topology of the
system 10 for providing Call Management Services in a Virtual
Private Network in accordance with a preferred embodiment of the
present invention. The system and method of the present invention
describes the handling of calls that originate and terminate within
an exemplary Virtual Private Network such as, for example, Centrex.
For the sake of demonstrating the features of the system, it is
assumed that at least two of the users are at separate network
nodes and that the Public Switched Telephone Network (PSTN)
circuit-switched network 12 is a call routing option between these
nodes. The nodes are assumed to have a one-to-one relationship with
PSTN exchanges, and more specifically with a single Centrex switch,
although an actual solution is not limited by such constraints. It
is further assumed that it is a requirement that callers be
identified by number and name, both being addresses that can be
called back.
[0028] User "A" 34 has a Network Address (NA) of 313-555-2001 and a
Customer Address (CA) of 2001. User "B" 36 has a NA of 313-555-2002
and a CA of 2002. User "C" 38 is in a different Numbering Plan Area
(NPA) and has a NA of 709-555-3001 and a CA of 3001. Different NPAs
are selected to emphasize the geographic separation of parties "A"
and "C". In a preferred embodiment, although the last four digits
of the NA and the CA are the same for the three users, there is no
fixed relationship between the numbers, as is the case with
traditional Centrex.
[0029] Users "A" 34 and "B" 36 are served by an Internet Protocol
(IP) gateway "X" 14 whereas user "C" 38 is served by IP gateway "Y"
16. The gateways depicted herein by a single block may comprise a
multiplicity of separate residential and trunk gateways, as well as
a separate. signaling gateway. Communication between the
residential and trunk gateways is via a Real Time Protocol (RTP)
running on a managed IP network. For the sake of simplicity, these
elements are depicted and are considered to constitute a single VPN
network node having one global IP address per customer domain name
for person locator services, as well as a single SS7 point code for
PSTN signaling. An IP signaling protocol such as Session Initiation
Protocol (SIP) handles communications between the call agents 18,
26 in the two gateways 14, 16, via a managed IP network 22. A Media
Gateway Control Protocol (MGCP), or equivalent agent to client
control protocol, enables control and management of data
communications equipment operating at the media gateways 14, 16
using the call agents 18, 26 as media gateway controllers. Thus,
the gateways 14, 16 are in communication with their respective call
agents 18, 26 using MGCP. MGCP bridges between the circuit-based
PSTN and Internet Protocol technology based networks. For further
details regarding MGCP, see information available through the Level
3 Communications Website at www.level3.com and the Bellcore Website
www.telcordia.com. While the preferred embodiment is described with
respect to the use of MGCP, any suitable agent to client gateway
control protocol may be used such as the Simple Gateway Control
Protocol.
[0030] The managed IP network 22 may also support voice
associations between the gateways 14, 16 using a suitable Internet
RTP. For the sake of simplicity, the transport facility supporting
the RTP associations between the gateways 14, 16 has been omitted
from FIG. 1. It can-be assumed to physically coexist in the
aforementioned managed IP network along with the signaling path
from gateway 14 to call agent 18, thence from call agent 18 to call
agent 26 via paths 20, 22 and 24, and finally from call agent 26 to
gateway 16. RTP supports transport of real-time data like
interactive voice and video over packet switched networks. RTP,
which includes sequence numbers for purposes of reconstructing data
in real-time order is used to communicate between the endpoints of
users A and B and the respective gateways 14, 16. While any
suitable protocol may be used, the media (i.e., the voice signal)
is preferably transported using RTP, which itself is carried inside
of a User Datagram Protocol (UDP). RTP is described in H.
Schulzrinne et al., "RTP: A Transport Protocol for Real-Time
Applications," IETF RFC 1889, January 1996, which is incorporated
herein by reference.
[0031] In traditional wireline PSTN networks, the first six digits
of a NA i.e., the NPA-NXX are permanently associated with a
particular gateway; they never roam from the assigned IP gateway.
Thus, they can be used for network routing amongst IP gateways
without the need to consult a database or directory server. In a
particular embodiment, if the private network is global, the NAs
may have a prefix for "country codes".
[0032] In a particular embodiment, global IP addresses are only
assigned on the basis of one per customer per gateway. This
strategy is intended to alleviate the critical shortage of IP point
codes. Addresses used for particular endpoints are local. Thus, a
SIP redirection server capability for a person locator service is
impractical because such servers are required to return global IP
addresses, and the local IP addresses used herein would be
meaningless. Instead, a SIP proxy server is incorporated in a
preferred embodiment of the system 10 of the present invention.
Because the basic SIP functionality of query state awareness is
enhanced to allow short-term awareness of calls in progress, the
functionality is identified as that of a "person locator server"
instead of a SIP proxy server. This person locator function is
provided amongst a multiplicity of networks and a SIP message is
sent to different networks or different endpoints within a network
to locate a particular user.
[0033] In a particular embodiment, traffic carried over the managed
IP network is prioritized according to a method that gives
signaling messages highest priority, followed by real-time voice
and then real-time video packets. Data not associated with calls in
progress is assigned the lowest priority. Signaling has the highest
priority because of its essential role in eliminating congestion by
taking down calls; voice is next because packet delays result in
noise and distortion that is extremely noticeable to users of this
traditional lifeline service; video is more forgiving because the
most recent image can be retained until information is available to
update it. Network throughput is provisioned so that the
transmission rates for data are acceptable, except in rare and
unusual circumstances. The average delay of the lowest priority
service is monitored and the results are used to assist in routing
decisions, as are described herein after.
[0034] The conversion from a CA to a NA and vice versa takes place
in a Directory Server 30. This Directory Server 30 is fully
replicated at each gateway 14, 16. Changes in the associations
between CAs and NAs are immediately propagated to all servers,
allowing roaming users to be accommodated. In a particular
embodiment, the server associated with the gateway where the user
and/or system administrator is physically located, at the time of a
status change, serves as the master for updating all other servers.
One server is designated as the master for periodic network audits.
It is considered impractical for the Directory Servers to be aware
of per-call transient data such as the busy/idle status of network
termination points or endpoints 40, 42, 44. Thus, while the
Directory Servers can accommodate roaming users, they cannot give a
final NA. In a preferred embodiment, this assignment is performed
by the call agent 18, 26 in the destination gateway, acting on
pre-programmed instructions provided to it by a Directory Server
30. The Domain Name Server 28 translates a Network Address or
Internet name into a local Internet address which identifies the
physical termination or endpoint within the network. The Domain
Name Server 28 is replicated at each gateway 14, 16. A Portability
Server 32 is also replicated at each gateway 14, 16. The
Portability Server 32 provides the ability for a customer to take
his telephone number from one physical location to another. The
Portability Server 32 interacts with a user who is in the process
of moving from one physical location to another. It authenticates
the request to port by prompting the user to log on, then matching
the user-supplied name and password with data on file. If
successful, it packages the necessary porting data and sends it to
the Directory Server as a dynamic update.
[0035] FIGS. 2A and 2B are diagrams illustrating the Directory
Server data structure in accordance with a preferred embodiment of
the present invention. The Directory Server 30 contains classes of
objects and attributes of objects in some cases that can be defined
as follows: [0036] Network Address (NA) Class 62: There is one NA
object 64, 66, 68 for every recognized customer termination or
endpoint 40, 42, 44. The instance record contains attributes
describing key capabilities of the termination such as, but not
limited to, whether it is on or off the network, the feature set
that can be supported, and data bandwidth. The record also contains
two flags, one of which is set if the assigned user has roamed to
another location, and the other if the endpoints or network
termination points currently have an active guest user. There are
fields for the currently active CA which is important to the
process of translating from NA to CA, and the assigned CA. It
should be noted that the two CAs are the same, unless a guest user
is present. [0037] Master Logic Tree: This is the stem class for
the configuration classes which follow. [0038] Configuration
Classes: Built on the Master Logic Tree super class, the
Configuration Classes are provided by the equipment vendor to
represent a suite of likely CMS feature configurations. In a
particular embodiment, these pre-packaged suites are selected by
the system administrator as the foundation for the Business Unit
Profile. All that the system administrator needs to do is fill in a
few key attributes that apply to all users within the Business
Unit. The sizes of lists and tables are examples of such
attributes. [0039] Business Unit Profile 70: The Business Unit (BU)
is the smallest definable entity to be independently managed by the
customer's system administrator. Business Unit Profiles are object
instances of the aforementioned Configuration Classes. They are at
the base of a hierarchy comprised of, but not limited to, sections,
districts, and departments or other organizational entities. A
reference number tracks their position in the hierarchy. Additional
levels can be inserted if required. The data record contains
attributes describing the feature set available to users within the
BU, a template describing how the originating and terminating CMS
features should interact, data shared by all BU members such as
master speed call lists, and other capabilities considered
convenient to be managed at the BU level. This profile yields
graphical displays such as logic trees for the "Matching Decision
Tree" and the "Routing Decision Tree", which are described herein
after. [0040] User Profile 72: There is one user profile object 74,
76, 78 for each recognized user in the customer's organization.
Sub-classes are used to denote the user's status and privileges,
and special sub-classes are available for assignment to endpoints
where a telephone can be connected in public areas or conference
rooms. The instance record can contain a large number of
attributes, of which only a few are essential to the description of
the exemplary embodiments that follow. The most important of these
is the CA, which is defined separately herein after. This is
followed by the NA where the user is currently located and the
assigned NA, the former being the key to the CA to NA translation.
In a preferred embodiment, the two NAs are the same, unless the
user has roamed to another location. A flag is set if the current
NA is not the user's assigned NA. A reference number is another
attribute in the user profile that ties the user to a specific
Business Unit Profile. A public and several private name fields
follow. These are followed by personal data for the features
identified in the business unit profile. The business unit profile
includes, but is not limited to, a personal speed call list and
selective call forwarding. A speed call list allows the user to
have a list of eight numbers. The actual numbers to be used, if
any, appear in the user's profile. Selective call forwarding
allows, for example, the user to identify and forward numbers or
CA's up to a limit established by the administrator in the BU
profile. The actual numbers to be forwarded, as well as the
forwarded to numbers appear in the user's profile. Data entered
into the user profile is constrained by the business unit profile,
particularly in terms of table entry size and permissible number
ranges. Other personal data are likely to be required, such as
passwords for remote access when requesting a service port. [0041]
Customer Address (CA): This is an attribute of the user profile
object. It has special significance because of its role as a search
key in translations between network addresses and user
profiles.
[0042] FIG. 3 is a diagram illustrating Directory Server
translations and attribute fields in accordance with a preferred
embodiment of the present inventions. The key attributes of the NA
object 102 and user profile object 104 can be arranged as fields in
a data record associated with the object instance. The dashed lines
are cross-references for the translations: the current customer
address attribute 110 of the NA object 102 points to the
appropriate user profile object 104; conversely, the current
network address attribute 122 of the user profile object 104 points
to the appropriate network address object 102.
[0043] In a particular embodiment, the primary search key for an NA
is the Directory Number assigned by the serving Local Exchange
Carrier (LEC) or neutral third party number administrator. This is
the ID field, identified as ID 106. The user profile object 104 has
two search keys, the ID field ID 118 and the user name 119. The ID
field ID 118 contains the CA, and in a particular embodiment is the
primary key for use by intra-VPN queries. In another preferred
embodiment, off network queries in IP mode can use the user name
field 119 as a search key, such as in SIP:
johnsmith@bigcorp.com.
[0044] There are four sources of data for a typical internal call
involving two parties--the two CAs and their associated user
profiles, plus the two NA's and the physical endpoint descriptions
they contain. The Directory Server has access to the data in the
four sources during the course of a translation. This data is
sufficient to complete the translation function for most calls. The
exceptions are addressed by the Matching Decision Tree described
herein after.
[0045] All calls, for example, user to user, user to PSTN, and PSTN
to user, are processed by the Directory Server (DS) before they can
be completed. Once this processing has been carried out, a "DS"
flag is set so that subsequent queries to a Directory Server, if
required for other reasons, do not perform the CA/NA translations.
Segments added to established calls for adding additional
capabilities in a multimedia environment, transferring, forwarding,
or conferencing are treated as new calls. In a preferred
embodiment, call agents are not permitted to perform final routing
to an IP network endpoint unless the DS flag on the incoming call
has been set. This is a Quality of Service (QoS) safeguard intended
to avoid completion of mishandled calls. Calls from NAs with no
assigned CA are not permitted. In a particular embodiment, such
call attempts may be default routed to the system administrator for
assignment of a CA.
Processing System
[0046] An operating environment for the system 10 includes a
processing system with at least one high speed processing unit and
a memory system. In accordance with the practices of persons
skilled in the art of computer programming, the present invention
is described with reference to acts and symbolic representations of
operations or instructions that are performed by the processing
system, unless indicated otherwise. Such acts and operations or
instructions are sometimes referred to as being
"computer-executed", or "processing unit executed."
[0047] It will be appreciated that the acts and symbolically
represented operations or instructions include the manipulation of
electrical signals by the processing unit. An electrical system
with data bits causes a resulting transformation or reduction of
the electrical signal representation, and the maintenance of data
bits at memory locations in the memory system to thereby
reconfigure or otherwise alter the processing unit's operation, as
well as other processing of signals. The memory locations where
data bits are maintained are physical locations that have
particular electrical, magnetic, optical, or organic properties
corresponding to the data bits.
[0048] The data bits may also be maintained on a computer readable
medium including magnetic disks, optical disks, organic disks, and
any other volatile or non-volatile mass storage system readable by
the processing unit. The computer readable medium includes
cooperating or interconnected computer readable media, which exist
exclusively on the processing system or is distributed among
multiple interconnected processing systems that may be local or
remote to the processing system.
BASIC CALL SETUP
Intra-Gateway
[0049] FIGS. 4A and 4B are flowcharts illustrating a method for
handling intra-gateway calls in accordance with a preferred
embodiment of the present invention. Per step 152, user "A" on IP
gateway "X" dials 2002 to reach user "B" on the same residential
gateway. The gateway passes the requests to the call agent per step
154. The call agent associated with user "A" receives a CA (2002)
from the user as the dialed number and after checking the validity
of the dialed digits per step 156, assigns an NA (313-555-2001) as
the calling user's identity at step 160. Each call agent maintains
a table cross-referencing stations or endpoints to NAs, both being
relatively static physical addresses. A query is launched to the
Directory Server per step 162, which performs a dual translation
per steps 168, 170, converting the CA to an NA and vice versa.
[0050] Thus, the dialed CA (2002) becomes an NA (313-555-2002). The
user's identity, in particular, the NA assigned to the endpoint
being used to make the call (313-555-2001) becomes a CA (2001).
Upon receipt of the response, the originating call agent recognizes
that the called party is within the gateway at step 176 and can
therefore process the call internally. This is a major decision
point, leading either to a process that can be completed internally
or one that involves interaction with a call agent at another
gateway.
[0051] Having decided to proceed internally, the call agent
negotiates the "Matching Decision Tree" per step 178 which is
described, in detail herein after. This decision tree matches the
preferences and privileges of the two parties and arrives at a
decision. This involves the granting or alternatively, denying of
permission to set up a call and the return of an appropriate NA. If
the call is approved for completion, per step 180, the NA should be
unchanged from that supplied by the Directory Server, since this
server manages the dynamics of "service portability" for roaming
users. However, since the busy/idle status of the terminating
station or endpoint is known only to the associated call agent, and
cannot be anticipated by the Directory Server, the final result
might be the NA of a voice mailbox, administrative assistant, call
attendant or even an external PSTN destination such as home
telephone number. In step 183, the number provided by the Matching
Decision Tree, if altered from that provided by the Directory
Server, is examined to ensure the destination is still internal. If
it is, the call flow proceeds to step 184;
[0052] otherwise the flow proceeds to step 192 in FIG. 4C.
[0053] FIG. 4C describes the handling of calls where the Matching
Decision Tree has identified an external destination, either in the
PSTN or in another customer's VPN of the type described herein. The
call flow encounters the decision 192 which differentiates a PSTN
destination from an IP destination. If the destination is in the
PSTN, the call agent instructs the trunk gateway to set up the call
in step 194. Alternatively, if the destination is another similar
VPN, the call agent launches simultaneous SIP person locator
queries to the Directory Servers in one or more other networks. The
queries may be, but not limited to, of the form <sip:
johnsmith@othercorp.com> and the expected response is a PSTN
Directory Number, or a treatment indicator. The functionality of
the remote Directory Server is described herein after, in a sub
section entitled "Interworking in Native Mode". Assuming the
response from at least one other network is acceptable, as per step
198, and a PSTN Directory Number is returned, the call flow
proceeds to step 193. Otherwise the call is given a treatment. In a
particular embodiment, treatment in this case may be a voice
message to the effect that the user is currently away from his desk
and is not logged onto the network; please leave a message.
[0054] Once the final NA is known, the call agent in gateway "X"
composes the Internet address for user "B", for example,
3135552002@bigcorp1.com. The associated Domain Name Server (DNS)
uses the Internet name to generate a local Internet Protocol
address that accesses the endpoint where user "B" is currently
located per step 186. Set up instructions to the gateway are sent
per step 188. User "B" receives a caller identity display which
shows the calling number as 2001 and the calling name as "John
Smith" at step 190. The calling user's name is provided by the
Directory Server in step 170.
Inter-Gateway
[0055] FIGS. 5A-5C are flowcharts illustrating a method for
handling inter-gateway calls in accordance with a preferred
embodiment of the present invention. The earlier steps of the
flowcharts are the same as illustrated in FIG. 4A. User "A" on IP
gateway "X" dials 3001 to reach user "C" on gateway "Y". The call
agent associated with user "A", also known as the originating call
agent, receives, a CA (3001) from the user as the dialed number and
assigns an NA (313-555-2001) as the caller's identity. A query is
launched to the Directory Server, which converts the CA (3001) to
709-555-3001. The caller's identity is converted from the NA
(313-555-2001) to 2001. Upon receipt of the response, the
originating call agent recognizes that the called party is within
the private network, but at a location outside of gateway "X". This
is a major decision point. In a particular embodiment, the call
agent recognizes the NPA and Central Office (CO) code of the NA
(i.e., 709-555) as being associated with IP gateway "Y". If CO
codes are portable across local calling areas, it may be necessary
to perform 10-digit analysis in order to associate an NA with a
particular gateway. In such cases a Local Number Portability (LNP)
database can be consulted to convert the NA to an appropriate
Location Routing Number (LRN). The CO code portion of the LRN can
then be used to make the determination. Accordingly, the
originating call agent composes a Session Initiation Protocol (SIP)
person locator query or message containing the caller's identity
(CA) and the destination address (NA), as well as all relevant call
data that might be required by advanced features. It sends this
message to gateway "Y" per step 204. The SIP message is used to
transfer user A's business unit and privilege information,
multimedia service requirement specifiers, as well as any other
information needed by the terminating call agent. Additionally,
advanced end-to-end features which rely on the capabilities of IP
signaling take advantage of this end-to-end, pre call setup SIP
conversation. For example, in the case of a multimedia call, the
voice portion might be established via the PSTN while the video
component is split off and conveyed end-to-end via the managed IP
network. To facilitate such end-to-end associations in an
environment which conserves global resources, local IP addresses
are exchanged at this point. A combination of a global gateway IP
address plus the local IP address within that gateway is then used
to establish such associations.
[0056] The call agent at gateway "Y" notes the person locator
nature of the SIP message and proceeds to function as a proxy
server for the originating call agent in gateway "X". Use of local
IP addresses for individual endpoints makes a SIP redirection
server impractical; hence in a particular preferred embodiment the
person locator server is a SIP proxy server capable of fulfilling
the initial query by remaining aware of its state. This involves
negotiation of the "Matching Decision Tree" per step 206. The
preferences and privileges of the two parties are matched and a
decision is made. As before, this involves the granting or denying
of permission to set up a voice path and the return of an
appropriate NA. The busy/idle status of the terminating station or
endpoint is only known to the call agent in gateway "Y", and is not
anticipated by the Directory Server or the originating call agent
in gateway "X". The call agent at gateway "Y" concludes by
returning a SIP response message containing permission for the call
or lack thereof, an updated NA, if necessary, and a reference token
(hereinafter referred to as "the token"). A record of the
transaction, including, but not limited to, all pertinent history
details such as the calling user's name, CA, and "class of
service", is stored in co-located short-term memory per step 210 as
a dynamic object. A timer is set against the called station to
ensure against intrusion by other incoming calls until the one in
progress has been completed, a typical user-settable value being in
the range from approximately 15 to 60 seconds. During this
interval, which should normally be no longer than 4 seconds, the
called station does not receive dial tone on attempted call
originations and other incoming calls receive the busy line
treatment specified in the called user's profile. Should the timer
expire before receipt of the call, the dynamic object representing
the call in progress object is eliminated, and the access embargo
on the called station is removed.
[0057] Upon receipt of a response from the call agent in gateway
"Y", the originating call agent in gateway "X" prepares to set up a
call per step 222. It is assumed permission for call setup has been
granted; otherwise, the originating call agent would have been
requested to provide the calling user with treatment, for example,
a busy signal and the call attempt would have been aborted. In step
215, the number provided by gateway Y is examined to ensure the
destination is still internal. If it is not, the call flow proceeds
to step 192 in FIG. 4C. Assuming an internal call, the call flow
proceeds to step 216. The call agent consults the "Routing Decision
Tree" per step 216 which is described herein after. This decision
tree can conclude in step 218 that the call is to be aborted due to
lack of appropriate voice transport facilities, an end-to-end VoIP
association is to be established between the gateways with or
without bandwidth reservation, or that an end-to-end call through
the circuit-switched PSTN is to be attempted. For the purposes of
this example, it is assumed that the PSTN is to be used for voice
transport per step 224.
[0058] The originating call agent directs trunk gateway "X" to set
up a PSTN call to the provided NA, which is equivalent to the
Directory Number (DN) of the target network termination point. This
is populated into the Called Party Number parameter of the
Signaling System 7 (SS7) Initial Address Message (IAM). The IAM is
a message sent in the forward direction as part of the Integrated
Services Digital Network (ISDN) User Part Call set up protocol. The
IAM is a Mandatory Message which initiates seizure of an outgoing
circuit and which transmits address and other information relating
to the routing and handling of a call. The aforementioned token is
populated into the characters of the Generic Name parameter of the
said IAM. Finally, the NA of the calling station is populated into
the Calling Party Number parameter, per standard PSTN practice.
Thus a total of three SS7 IAM parameters are involved in conveying
the necessary VPN call setup information between gateways. The
PSTN, using traditional routing procedures, which may or may not
involve functionality for Local Number Portability, routes the call
to gateway "Y". Trunk gateway "Y" passes the request to the call
agent per step 226 and recognizes the DN as one being managed by
the same call agent that performed the aforementioned person
locator proxy server function. Upon boot up, each call agent
advises the residential and trunk gateways about the endpoints or
network termination points which it manages. The gateways store
this information for subsequent use. This lo functionality is
described in the Media Gateway Control Protocol (MGCP).
Consequently, all transactions involving a particular DN are
handled by the same call agent, in particular, a mated pair of call
agents. Accordingly, the terminating call agent is notified and
given information about the incoming call.
[0059] The terminating call agent is anticipating a call from the
indicated NA, i.e., this particular call. Upon performing the
capture, the terminating call agent gets the token from the Calling
Name field and uses it to retrieve the history of the call from its
short-term memory per step 234, as well as to provide a secure
association between the granting of permission and the actual
incoming call. Since all the necessary data is now available, the
call agent composes the Internet address for user "C", i.e.,
7095553001@bigcorp2.com. The call is completed even if the called
station is currently off-hook, in which case the step of applying
alerting tone is bypassed. The associated Domain Name Server (DNS)
uses the Internet name to generate a local Internet Protocol
address per step 242 that accesses the endpoint where user "C" is
currently located. User "C" receives a caller identity display
which shows the calling number as 2001 and the calling name as
"John Smith" at step 246. The calling user's name was provided by
the Directory Server in gateway "X", transported through the
managed IP network on the initial SIP message, stored in the
terminating call agent's short-term memory, and subsequently
retrieved on receipt of the call from the PSTN.
External Call Handling
[0060] In a preferred embodiment, CAs cannot begin with the digits
"8", "9", or "0", these being reserved for private trunk network
access, escape to the PSTN, and attendant services, respectively.
Thus, the Directory Server is set up to recognize these prefix
digits and bypass the normal translation algorithms. For example,
if the call is destined for the PSTN, neither the dialed number nor
the caller's NA is translated.
[0061] FIGS. 4A and 6D are flowcharts illustrating a method for
handling outgoing external calls in accordance with a preferred
embodiment of the present invention. Assuming an outgoing call to
the PSTN per step 152, the aforementioned user "A" dials the PSTN
number, for example, 9-313-555-7860. The call agent associated with
user "A" receives the full PSTN number as the dialed digits and
assigns an NA (313-555-2001) as the caller's identity per step 160.
A query is launched to the Directory Server per step 162, which
recognizes the escape code and declines to translate either number
per step 164. Both are returned to the call agent unchanged per
step 312 (from FIG. 6D), with the DS flag set to indicate that the
translation function has been completed. The call agent then
requests trunk gateway X to set up a call to the PSTN. Because the
call is destined for the PSTN, the Generic Name parameter of the
SS7 IAM contains a proper calling name and not a "token".
[0062] FIGS. 6A-6C are flowcharts illustrating a method for
handling incoming external calls in accordance with a preferred
embodiment of the present invention. For an incoming call from the
PSTN, the PSTN user at 313-555-7860 calls user "A" in the private
network by dialing 313-555-2001 at step 262. The PSTN routes this
call via conventional means to gateway "X" at step 264. If the call
agent has call-in-progress records saved, and is awaiting internal
inter-gateway network calls to complete step 268, the incoming NA
is tested against these records for a match per step 270. Because
the call originated in the PSTN, no match is found. If a match is
found, this identifies the terminating leg of an inter-gateway
Virtual Private Networking call per step 234 of FIG. 5B. The call
agent assigned to the Directory Number launches a query to the
Directory Server with the received digits and the caller's identity
in step 272. The Directory Server recognizes this as a call from
the PSTN and declines to translate either number at step 274. Both
the dialed number and the caller's ID are returned to the call
agent unchanged in step 276, with the DS flag set. The Matching
Decision Tree 276 is optimized to process calls that originate and
terminate within the customer's network, and is therefore keyed to
recognized CAs. Because this call is coming from the PSTN, the
caller cannot be identified, only the calling PSTN station.
Therefore, the matching process sequence is required to recognize
the external call, or a call directed to the Portability Server,
described herein after, via a NA_Not_Translated (NNT) flag set by
the call agent, and substitute the caller's Directory Number in
place of the anticipated incoming CA. In step 277, the number
provided by the Matching Decision Tree is examined to ensure the
destination is still internal, since it is possible for a user to
forward an external incoming call to another external destination.
If it is still internal, the call flow proceeds to step 278;
otherwise the flow proceeds to step 192 in FIG. 4C. Assuming the
called NA has an assigned CA, the call agent composes an Internet
name, i.e., 3135552001@bigcorp1.com. The associated DNS then uses
this name to establish an association with the physical endpoint
where user "A" is currently located at step 284. The situation
where user "A" has roamed to another location is described herein
after in the section regarding "service portability." In a
particular embodiment, had the target NA not had an assigned CA, or
had there been no such NA, the caller would have been given "no
such number" treatment.
[0063] It is possible for a user to call another internal user by
dialing the escape code plus the called user's full ten-digit
Directory Number. This may be a strategy a user employs to
circumvent routing restrictions during network overload or failure
conditions. For this reason and also to facilitate the network
survivability aspect described herein after, when presented with an
outgoing call, the Directory Server is required to confirm that the
destination is external to the private network. It does this by
searching through the NAs for a match with the dialed DN. If a
match is found, the customer has the option of providing the caller
with a treatment and a voice message. If the call is allowed to
proceed, the call agent must be advised to insert a null token into
the Generic Name parameter of the SS7 IAM. On incoming calls, the
Directory Server is also required to confirm that the caller is
external to the private network. It does this by searching through
the NAs for a match with the caller's ID. If there is no match, the
call agent is advised to pass the calling name field to the called
party unchanged. If the caller is internal to the private network,
i.e., an internal call has been completed via the PSTN, the call
agent expects a valid token in the name field. A token value of
zero causes the call agent to implement the default routing
feature. Described herein after, and illustrated in FIG. 6C, the
default routing feature is used by a terminating call agent in the
VPN to reconstruct the calling user's profile and to re-negotiate
the Matching Decision Tree during a network failure condition.
Matching Decision Tree
[0064] The Matching Decision Tree is invoked when the decision
whether or not to set up a call, or the final destination of a
call, is not obvious. Otherwise, an immediate exit of this process
sequence occurs and the call is established to the NA already
provided by the Directory Server. Ambiguity is introduced when the
called user is on the phone, i.e., busy, has invoked a version of
the call forwarding features, or has activated a restricting
feature such as "do not disturb". In such a preferred embodiment,
the call flow complexity is increased. This increase in complexity
is addressed by the Matching Decision Tree. User identities are
normalized to be CAs. Thus, if a caller enters a user name instead
of a CA to reach a desired user, the name is translated to a CA in
the Directory Server before being presented to the Matching
Decision Tree. As stated herein before, the logic in the Matching
Decision Tree depends on CAs. When users enter data into their
profiles for the Matching Decision Tree, such as specific users in
Selective Call Forwarding, they may enter either a CA, a PSTN
Directory Number (DN) for outside calls, or an internal user name.
If a user name is entered instead of a CA, the administrative
function that builds the user's profile consults the Directory
Server for a translation of the name into a CA. Thus, in a
particular embodiment, it is either a CA or a PSTN DN, as
appropriate, that identifies the caller in the Matching Decision
Tree.
[0065] The Matching Decision Tree is the organization of the call
flow for a particular application, expressed in a tree-like logic
structure. A generic logic tree is a template consisting of
decision points where variable data are evaluated against fixed
criteria and decisions taken. In a particular embodiment, the
criteria are supplied to the call agent by the Directory Server,
either periodically as dictated by changes, or in response to a
direct query. The criteria for the matching function come from
pre-programmed data obtained via the terminating user's profile.
Because the logic tree is a generic template, and can be filled in
by the Directory Server, the terminating user can roam throughout
the network while retaining full terminating CMS feature
functionality. The variable data includes the caller's CA and class
of service. The class of service consists of two parts: 1) a code
which identifies the work group within the organization, for
example, but not limited to, business unit, section, district, and
department; and 2) a value which identifies the caller's privileges
and status within the work group. The data also includes per-call
transient state information known only to the call agent, for
example, busy/idle status of the terminating endpoint or network
termination point, Call Forward All (CFA) invoked, Do Not Disturb
invoked, or Selective Call Acceptance features activated.
[0066] The functionality described herein above bears some
similarity to the Service Creation Environment envisaged for the
PSTN's Advanced Intelligent Network (AIN). In a method in
accordance with a preferred embodiment, the call agent plays the
role of the Services Control Point (SCP) while the Directory Server
plays the role of the Services Management System (SMS). The
analogous SCPs are those provided by IntereXchange Carriers (IXCs)
to deliver value-added 800 features to their customers. In a
preferred embodiment, having an AIN version of the SCP, the full
ten digits of an 800 number direct the call flow to a file
containing a Flexible Service Logic (FSL) tree that describes the
features, their datafill, and their method of interworking, for a
specific 800 customer. FSL is the concept of supplementing
application program logic through the use of non-executable code,
i.e., data. Typical FSL features include time-of-day routing,
day-of-week routing, overflow on busy routing, and location finder
based on the caller's number. The SMS is an operations support
system used to facilitate the provisioning and-administration of
service data required by the SCP. In an idealized version, an IXC
employee uses a Graphical User Interface (GUI) on the SMS to
assemble a customer's logic tree using icons from a pallet that
represent the features. The SMS downloads the finished FSL tree to
the SCP where it is used to direct real time call flow. In the
functionality described herein, the customer's network
administrator creates the user's logic tree, which then resides in
the user profile in the Directory Server. The Directory Server
downloads the FSL tree to the call agent. In FSL, the logic the
data represents is stored in a decision graph. However, the
flexibility can be greatly constrained with acceptable results, in
particular, the features can be placed in a rigid hierarchy. Some
features can be placed at the top of the tree whereas others can be
placed at the bottom. For example, a feature which determines an
outcome based on the caller's identity or privilege is best placed
at the top of the tree. Features such as time-of-day routing or
Call Forwarding All (CFA) are best placed near the bottom because
some of the options they provide may only be available to
privileged or anticipated callers.
[0067] FIGS. 7A and 7B are flowcharts illustrating a method for a
Matching Decision Tree. In particular, they describe a redirection
example, in accordance with a preferred embodiment of the present
invention. It should be noted that users are identified by their
CAs, rather than by their NAs. This allows calling and called users
to roam amongst a multiplicity of NAs while preserving the validity
of the matching logic tree's decisions. As identified herein
before, because calls from the PSTN do not have CAs, it is
necessary to identify such calls and substitute the caller's
Directory Number for the expected CA. The system administrator has
assigned the business unit a simple two-level hierarchy. The top
level is Selective Call Forwarding (SCF) on "busy/no answer" of the
terminating network station or endpoint. The second level, which is
the bottom level in this example, is time-of-day routing. This
hierarchy is captured in a business unit profile "XYZ". The user,
who is a member of the "XYZ" group, decides to enable SCF and
supplies two numbers in the user profile to be given the treatment,
each of which represents a branch in the tree from this decision
point. A third branch represents "else," or all other numbers. All
three branches encounter the second level in the hierarchy, namely
time-of-day routing. The user decides to enable time-of-day (TOD)
routing on the first two branches only. For the sake of simplicity,
time of day routing has two output legs or segments, normal
business hours, and "else". Each branch of the tree ultimately
terminates on either a choice of treatment or an alternative
NA.
[0068] In a particular embodiment, there are five branches in
total. The following table, Table 1 shows one possible format for a
message from the Directory Server to the call agent, intended to
fill a logic tree template with the data required to illustrate the
example: TABLE-US-00001 TABLE 1 MESSAGE DESCRIPTION true the SCF
feature node 3 branches to follow 1,1 branch identity 2001 data for
the branch (a CA) true the TOD feature node 2 branches to follow
1,1,1 branch identity start time & end time data for the branch
(normal business day) stop & attendant termination of branch
and treatment (an NA) 1,1,2 branch identity "else" data for the
branch (default) stop & home phone termination of branch and
treatment (a directory number) 1,2 branch identity 2002 data for
the branch true the TOD feature node 2 branches to follow 1,2,1
branch identity start time & end time data for the branch
(normal business day) stop & attendant termination of branch
and treatment (an NA) 1,2,2 branch identity "else" data for the
branch (default) stop & voice message termination of branch and
treatment (an NA) 1,3 branch identity "else" data for the branch
(default) false the TOD feature node 1 branches to follow 1,3,1
branch identity stop & voice message termination of branch and
treatment (an NA) / end of file
[0069] The ability to place both parties in the same business unit,
"XYZ" in this case, provides compartmentalized closed user
sub-groups within the customer's network. This allows the behavior
of the CMS features to be tailored to the requirements of
individual business unit managers. For example, user names on
internal calls can be "Paul", "Sue", or "Bill". Calls between
business units can be augmented with a business name as well as the
user name. Calls to the PSTN can use the corporate name. In another
example, the business unit manager can exercise intrusive features
such as "barge-in" or interrupt when calling subordinates.
[0070] Any number of branches in the Matching Decision Tree can
identify destinations that are external to the customer's VPN,
being either in the PSTN or in the similar VPNs of other customers.
In the latter case, the user may enter a plurality of domain names
as potential destinations and all are queried simultaneously. Given
the ambiguity in potential destination types, the Matching Decision
Tree sets a flag in the return message indicating internal,
external, or external IP.
[0071] In order to illustrate the call flow in FIGS. 7A and 7B, it
is assumed that Selective Call Forwarding (SCF) #1 contains the CA
2001, representing User "A". The called user is User "B".
[0072] Calls are made during the normal business day (NBD). User
"B" is in the office but is on the phone.
[0073] User A initiates the call flow depicted in FIGS. 4A and 4B.
At step 178 the call flow enters the more detailed flow chart as
depicted in FIG. 7A. At step 352, User "A" is recognized by the
2001 CA and the call flow is directed to step 362. Because it is
during the normal business day, the call is directed to step 360
which returns the NA of an attendant. At step 184, in FIG. 4B, the
call agent notes that the NA received from the Matching Decision
Tree is different from the one received from the Directory Server.
It uses the updated NA to establish the call. The call is received
by a voice attendant who, for example, can advise User "B" of
receipt of an important call.
[0074] User "n" initiates a call to User "B". Upon reaching the
Matching Decision Tree, this call proceeds through steps 352 and
354 and emerges at "H" in FIG. 7B. This is because its CA was not
found in the selective call forwarding data, resulting in execution
of the "else" legs. Because User "n" is not in the same business
unit as User "B", call flow is directed by step 366. to step 368
which returns the NA of the voice messaging system.
[0075] User "B" is called by the department manager. The call
proceeds as described above to step 366. At step 366, the calling
and called user are determined to be in the same business unit,
causing call flow to proceed to step 370. At step 370 it is
determined by a comparison of user privileges that the caller is
allowed to invoke special procedures to reach this user, causing
the flow to proceed to step 372. Step 372 may either be
pre-programmed to interrupt User "B's" call or to signal the caller
for further instruction, as business unit data. If an interrupt is
appropriate, the NA provided by the Directory Server is left
unchanged, a flag denoting this interrupt decision is set in the
call-in-progress record, and when User "B" gets the call, interrupt
is invoked. If interrupt is declined, step 376 might be programmed
to allow ring-again with reservation to be activated. Ring-again
with reservation causes the called station to notify the calling
station via an IP message when User "B" is off the phone. The
reservation feature freezes the state of User "B's" station for a
pre-determined interval, for example, 60 seconds--30 seconds to
alert the caller, 15 seconds to establish a worst case PSTN
connection, and 15 seconds for margin, until the department manager
has had a chance to establish the call. Ring-again with reservation
is set up in step 378 and an appropriate treatment code is returned
to the originating call agent.
Routing Decision Tree
[0076] FIG. 8 is a flowchart illustrating a method for a routing
decision in accordance with a preferred embodiment of the present
invention. The Routing Decision Tree follows the example of the
Matching Decision Tree described herein before. The criteria are
supplied to the originating call agent by the Directory Server,
either periodically as dictated by changes, or in response to the
original address translation query. The criteria for the routing
function comes from pre-programmed data obtained via the
originating user's profile. Because the logic tree is a generic
template, and can be filled in by the Directory Server, the
originating user can roam throughout the network while retaining
full originating CMS feature functionality. The variable data
includes the NA returned by the terminating call agent in the
distant gateway, performance data from both the PSTN and the
managed IP network, as well as--in a multimedia environment--the
type of call the calling user wishes to make. The latter is
transient data, known only to the call agent.
[0077] In the preferred embodiment, the performance of the lowest
priority IP service on the managed network is continuously
monitored. This is non call-related data service and there must be
an amount of such traffic sufficient to provide a good buffer. When
service degrades below a certain level, users with sufficient
privileges are offered the option of completing calls, or the voice
component of multimedia hybrid calls, via the PSTN. Users with the
highest privilege level may be offered the PSTN as the first choice
at step 402 with a fall back to VoIP at step 404.
[0078] The method 400 regarding the Routing Decision Tree begins
with the determination if the PSTN is the preferred option for this
user, and in the case of calls involving advanced features, if the
requested type of call can be supported over the PSTN, at step 402.
If not, then it is determined if VoIP is an acceptable option per
step 404. If yes, VoIP is returned as the choice for routing. If
PSTN is the selected option for the particular user then it is
determined if there are any trunks available at step 408. A trunk
is a communication circuit switched channel, either real or virtual
between two switching systems. If trunks are available, then per
step 410, PSTN is returned as the choice. If however, no trunks are
available, then it is determined from the calling user's profile if
an expensive route privilege is available to the user per step 412.
If yes, then the user is given a warning tone and then allowed to
proceed after a brief delay for reconsideration. If not, then it is
determined per step 416, if VoIP is an acceptable option. If not,
then an abort is returned resulting in the call being given
treatment.
[0079] If it is determined at step 404 or 416 that VoIP is to be
used to establish the call between gateways, in a preferred
embodiment of the present invention the caller's privileges are
evaluated to determine if SIP bandwidth reservation is to be
employed. Bandwidth reservation guarantees the Quality of Service
(QoS) at the expense of the number of calls that can be carried in
a given transport facility. Thus, its use is a privilege. There is
also a possibility that sufficient bandwidth might not be
available. If not, the Routing Decision Tree returns a treatment
code. Alternatively, the caller might be given a special tone
indicating failure to reserve the required bandwidth, allowing the
caller the option of either continuing with a reduced QoS or
hanging up and trying again. Because the person locator
functionality does not ring the called telephone, the preferred
embodiment allows the reservation step to cancel the call without
causing the unacceptable QoS situation of ringing followed by a
busy re-order, or no trunks available signal.
[0080] In the case of a multimedia call, when insufficient IP
bandwidth is available to support all user specified media, a
determination needs to be made if the lifeline voice path should be
established. In the preferred embodiment, the user is given either
a special tone, or a voice message with words to the effect: "There
is insufficient bandwidth for the video portions of this call;
please try again later, or stay on the line to continue with a
voice only call." After a delay of a customer settable number of
seconds, call flow is returned to step 402 of the Routing Decision
Tree for a voice only call. If the logic tree is successfully
negotiated, the originating call agent sends an IP message to the
terminating gateway revising the aforementioned service specifier
for the call in progress.
[0081] It has been customary for large private networks to lease
fixed numbers of virtual PSTN trunks in key cross sections. When
this level has been exceeded, per-call charges apply for excessive
usage. The gateway must keep track of simultaneous calls in
progress for tracking against the contracted allotment of virtual
trunks. When the latter number is at risk of being exceeded, the
routing strategy becomes more complex. This might involve
maximizing utilization of both the PSTN allotment and the full
capacity of the managed IP network, followed either by giving the
calling user treatment or an "expensive route warning tone". In the
latter instance, the user can terminate the call by hanging up and
try the call again; otherwise, the call proceeds to be routed with
excessive usage charges.
[0082] Address Translation Decision Tree The user profile impacts
matching and routing decisions, as discussed herein before. Because
the logic trees for these functions have to consider transient
data, these decisions in a preferred embodiment are best handled at
the level of the call agent. However, there is a group of CMS
features that affect the translation decision but are not dependent
on per-call transient data; in a preferred embodiment, these are
best handled by the Directory Server, without delegation.
[0083] In a preferred embodiment, screening tables are an example
of CMS features that affect the translation decision, such as those
used to deny long distance or overseas calls from certain users. In
this case, the NA of a network termination point located in a
public place can be assigned a CA belonging to the sub-class of
user profiles used for public phones. Such a sub-class can be set
up with extremely limited privileges as well as screening table
entries to restrict where the user can call. Such screening can
also be done through an entry in the profiles of selected users, or
through a blanket setting based on the business unit identity and a
user's privilege code.
[0084] The personalized "speed-calling" list is another example of
a Directory Server based CMS feature. In a preferred embodiment,
the business unit profile allows users to have up to eight, for
example, speed-call numbers. Users enter these numbers themselves
and they are retained in the user's profile, located in the
Directory Server.
[0085] As described herein before, the Directory Server performs a
dual translation on all internal calls. It translates the dialed CA
to an NA, and the NA of the endpoint to a CA. In a preferred
embodiment, the NA to CA translation is performed first. The CA
locates the calling user's profile and makes screening tables and
speed-call lists available to the translation process on the dialed
number. If the dialed number is a speed-call number, the entry in
the speed-call list is substituted and this becomes the new dialed
number. If there are screening numbers present, these are compared
for a match with the new dialed number. If a match occurs, the call
attempt is given appropriate treatment. Otherwise, the new dialed
number is routed as described herein before.
[0086] FIG. 9 is a flowchart illustrating a method 450 for an
Address Translation Decision Tree according to a preferred
embodiment of the present invention. The Directory Server receives
the query at step 452 along with the caller's NA and the dialed
number. The Directory Server gets the currently assigned CA from
the NA at step 454. At step 456, the caller's profile is accessed.
At step 458, it is determined if the dialed number has a speed call
access code. If yes, then it is determined if the user has speed
call and if the number is valid at step 460. If it is valid, then a
lookup is performed on the user's speed call numbers and the one
corresponding to the dialed code is substituted for the dialed
number accessed. If not valid, then the caller gets a response
indicating a treatment at step 462.
[0087] If at step 458, it has been determined that the dialed
number does not have a speed call access code then call flow
proceeds directly to step 466. Otherwise the speed call code is
translated into a typical dialed number, as described herein
before, then directed to step 466. At step 466 it is determined if
the dialed number has been screened. If yes, then the caller gets a
response indicating a treatment at step 468. If not, then, as
required, the caller's CA is retrieved from step 454 and the dialed
number is translated at step 470 for incorporation into the
response to the query.
Service Portability
[0088] To illustrate the roaming functionality, assume that user
"A" is going to roam from NA 313-555-2001 on gateway "X" to a phone
in the office of an associate on gateway "Z". User "A" has a CA of
2001, which is assigned to the 313-555-2001 NA. The associate is
identified as user "D" with an NA of 212-555-7951 and a CA of
7951.
[0089] In a preferred embodiment, user "A" begins a session by
initiating a conversation with the "Portability Server". This is
accomplished by dialing a service code. The call is routed to a
Portability Server endpoint within the residential gateway in the
usual way, except that the Directory Server recognizes the service
code and declines to translate the NA of the calling station. Once
this has been done, the caller is prompted for the assigned CA and
a password. When the Portability Server has obtained and verified
the information, it advises the local Directory Server that a
roaming user has just logged on and provides the NA of 212-555-7951
and CA of 2001. The Directory Server gets the User Profile for 2001
and changes the current NA from 313-555-2001 to 212-555-7951. Then
it sets a flag in the profile to show that this is not the assigned
NA. The profile also contains a record of the user's assigned NA
and this is not changed. The Directory Server then gets the NA for
the endpoint and changes the current CA from 7951 to 2001, and it
sets a flag in the NA to indicate the presence of a guest user. The
Directory Server in gateway "Z" also issues a message with the
relevant data to update all other Directory Servers in the private
network. User "A" is now established at the new location with
access to all CMS functions.
[0090] User "B" in gateway "X" dials 2001 to reach user "A". The
Directory Server accesses the profile for 2001 and performs the
translation to the 212-555-7951 NA. Since the profile for 2001
indicates the user has roamed, and the NA for 222-555-7951 confirms
the presence of a guest user, the Directory Server requests the
call agents to process a normal call from user "B" to user "A". On
the next call, user "B" dials 7951 to reach user "D". The profile
for 7951 also points to 222-555-7951. Since the profile for 7951
has no indication of roaming and there is a guest user at the
associated NA, the terminating call agent is requested to give
default Call Forward All treatment to the incoming call. This
ensures that calls for the station's assigned user are never
presented to the guest user, and in fact receive appropriate "away
from the office" treatment.
[0091] In a preferred embodiment, a call from the PSTN to user "A",
who has roamed away, presents a special problem since the called CA
is not present on the call and is not directly available. In this
case, the Directory Server finds the called NA and notes that the
roaming flag has been set. This causes a lookup on the assigned CA,
which appears as an attribute within the NA record. Thus, the
dialed NA (313-555-2001) is translated to 2001 and presented for
translation again, yielding the new NA of 212-555-7951. This allows
the call to be completed properly through the private network. A
call from the PSTN to user "D" causes the Directory Server to note
the guest user flag. This results, in the call being given Call
Forward All treatment. As before, this additional provision ensures
that calls for the station's assigned user are handled properly in
his absence.
[0092] In a particular embodiment, users who log on through the
Portability Server are required to log off, or in an alternate
embodiment, they are logged off automatically if there has been no
activity for a pre-determined interval of time. Log off triggers
the Directory Servers to revert the data in the NA and user
profile, such that the current NA and CA are set equal to the
assigned values.
[0093] FIGS. 10A-10C are flowcharts illustrating a method for
implementing service portability in accordance with a preferred
embodiment of the present invention. The portability functionality
introduces additional steps to several flowcharts, in particular
FIGS. 4A and 4B, described herein before. These steps were omitted
initially in the interest of simplicity. The guest user initiates a
log-on procedure at step 502. The residential gateway passes the
request to a local call agent at step 504. The call agent in step
506 generates a NA for the physical endpoint being used by the
guest user. A query is then sent by the call agent to the Directory
Server at step 508. The Directory Server determines in step 510 if
the call is internal to the private network or not. If there is an
escape code, the call is for an external destination and the call
flow proceeds to FIG. 6D. Otherwise the flow proceeds to step 514.
If at step 514 the dialed number is recognized as being an
administration number assigned to the Portability Server, then the
calling NA is not translated. The NA_Not_Translated (NNT) flag is
set and the call flow proceeds to step 518. The calling NA is
essential data that must be forwarded intact to the Portability
Server. It is not appropriate to ask the guest user to supply the
NA because it may not be evident, especially if the endpoint being
used is in a conference room. This also eliminates the possibility
of the user identifying the wrong NA, which could cause another
user's incoming calls to be given treatment. If the dialed number
is not recognized at step 514, this is an ordinary internal call:
in this case the calling NA is translated in step 516 and the call
flow proceeds from step 172 in FIG. 4A. Step 520 is a decision that
is encountered by responses from the Directory Server to screen out
failed call attempts that require treatment. In this case, for a
call being directed to the Portability Server, the outcome is ok
and the call flow proceeds to step 524. The method 500 then
proceeds to the Matching Decision Tree in step 526 to evaluate the
privileges of the called and calling party. In the method 500, the
NA Not Translated (NNT) flag set by the Directory Server,
transported in the response to the call agent, and forwarded to the
Matching Decision Tree causes the calling NA to be substituted for
the anticipated CA. Since the Matching Decision Tree is always
encountered at this point in the call flow, it must be set by the
system administrator to correctly handle calls to the Portability
Server., In a particular embodiment where there is a restriction on
calls from certain physical endpoints, and an appropriate voice
announcement treatment is given when all the access ports to the
Portability Server are in use. Once the outcome of the decision
tree is checked at step 528 the call agent then sends a query to
the Domain Name Server at step 530. The Domain Name Server
translates the dialed NA to the local IP address of the Portability
Server at step 532. At step 534, the call agent sets up a voice
association with the Portability Server via the residential
gateway. A voice path is needed so that the Portability Server can
send voice prompts to the user and receive in-band tone signaling
pulses in return. A coordinated signaling association is also set
up between this server and the call agent to convey the
call-related data, as identified herein. The Portability Server
obtains a CA and password from the user in response to a prompt at
step 536 and, given that this is not a foreign user as determined
per step 537, sends a query to the Directory Server at step 538.
Procedures for logging on foreign users are described herein after,
in the sub section entitled, "Interworking in Native Mode". The
Directory Server, at step 540, obtains the user's profile,.
extracts the password and provides it to the Portability Server. At
step 542, the Portability Server compares the password obtained
from the guest user with the password received from the Directory
Server. If there is a failure to match, after a pre-determined
number of attempts on the user's part to enter a valid password,
the flow proceeds to step 544 with a response indicating the call
should be aborted. If a match is obtained at step 542, the
Portability Server sends a successful response to the call agent
with the guest user's CA and current NA. Once the call agent
verifies the response at step 546, it ends a message to the
Directory Server at step 550 containing the guest user's CA and
current NA, and requesting an update of the profile and NA to
reflect the fact that the user has roamed to a new location. At
step 552, the Directory Server updates the profile and NA and
broadcasts the update at step 554. Assuming the update was
determined to have been successful at step 556, the guest user is
given a confirmation signal at step 560.
[0094] FIG. 11 is a flowchart illustrating a method 600 for
implementing service portability for an outgoing call in accordance
with a preferred embodiment of the present invention. At step 602
the Directory Server gets a query from the call agent. The
Directory Server translates the NA to obtain the current CA at step
604. The caller's profile is then obtained at step 606. The Address
Translation Decision Tree, is then used at step 608 by the
Directory Server. The Address Translation Decision Tree uses the
information from the user's profile to apply a speed call code
conversion, and to handle any number screening information
contained therein, such as restrictions on long distance and
overseas calling. This ensures that the speed call list and calling
restrictions move with the caller to the new physical location. At
step 614, the Directory Server translates the caller's NA and
dialed number. At step 616 the Directory Server responds to the
query. The call flow then proceeds from the Directory Server to
step 172 in FIG. 4A.
[0095] FIG. 12 is a flowchart illustrating a method 650 for
implementing service portability for an incoming call from a PSTN
station using a Directory Server process in accordance with a
preferred embodiment of the present invention. The Directory Server
receives a query from the call agent at step 652. It determines if
the call is an external call at step 654. If it is not, the call
flow proceeds to step 454 on FIG. 9. The Directory server further
determines if the called party has roamed in step 658. If the
called party has not roamed, the call flow proceeds directly to
step 670, as being successful, with no translation of the CA and
NA, as would be expected from an ordinary outside call. The
Directory Server gets the assigned CA in step 662 from a stored
attribute in the network address object. It further gets the user
profile at step 664 and the current NA at step 666. The Directory
Server then substitutes the current NA for the dialed NA at step
668, and completes a response to the call agent query in step
670.
Quality of Service
[0096] Quality of Service (QoS) is an important issue for customers
of business services such as multi-location Centrex or its private
network equivalent. They are generally wary of using VoIP as their
primary method of voice communication. The system and method of the
present invention treats the issue as one of paramount importance
and offers four strategies to deal with it: continuous performance
monitoring of the managed IP network as input to per-call routing
decisions; optimization of facility selection between a managed IP
network and the PSTN, such that traffic is shared and the balance
adjusted to compensate for IP network loading; a fall-back scenario
which allows the Centrex voice network to survive, even in the face
of a total loss of the managed IP network; and reservation of IP
network bandwidth for callers with sufficient privileges.
[0097] The distributed Directory Server architecture gives each
node in the network full access to the status of all NAs and CAs.
This presents the opportunity for a default routing scheme in that
an inter-gateway call has two opportunities for number translation.
If the originating gateway opportunity fails, causing the DS flag
to remain false (or the token to be null), the terminating gateway
will request an address translation from its Directory Server.
Thus, a complete failure of the managed IP network can be
accommodated with minimal short-term impact on the private
network's voice services users. The following example, based on
user "A" calling user "C", illustrates inter-gateway call setup in
a situation where there has been a total failure of the managed IP
network.
[0098] User "A" on IP gateway "X" dials 3001 to reach user "C" on
gateway "Y". The originating call agent launches a query to the
local Directory Server, which converts the CA (3001) to
709-555-3001. Upon receipt of the response, the originating call
agent recognizes that the called party is within the private
network, but at another gateway, gateway "Y". Accordingly, it
composes a SIP person locator query for a call agent in gateway
"Y". However, because the managed IP network has failed, there is
no immediate response from the distant gateway and a timer in the
originating call agent expires. The originating call agent abandons
the person locator step and proceeds directly to the Routing
Decision Tree. The failed status of the IP network may affect the
outcome of the routing decision, particularly if user "A" has
insufficient privileges to complete an internal Centex network call
in an emergency situation. It is assumed that a decision is made to
proceed with the call via the PSTN.
[0099] The originating call agent directs trunk gateway "X" to set
up a PSTN call to the provided NA, which is equivalent to the
Directory Number (DN) of the target endpoint. This is populated
into the Called Party Number parameter of the SS7 Initial Address
Message (IAM). Given the failure situation, there is no valid token
for population into the Generic Name parameter, as would normally
be done on inter-gateway calls within the private network. Instead,
a null value is inserted.
[0100] FIGS. 13A and 13B are flowcharts illustrating a method 700
for implementing default routing on an inter-gateway call in the
case of IP network failure in accordance with a preferred
embodiment of the present invention. The earlier steps of the
flowcharts are the same as illustrated in FIG. 4A. User "A" on
gateway "X" dials 3001 to reach user "C" on gateway "Y". The
originating call agent launches a query to the local Directory
Server, which converts the CA (3001) to 709-555-3001. Upon receipt
of the response, the originating call agent recognizes that the
called party is within the private network, but at another gateway,
gateway "Y". Accordingly, in steps 702 and 704 it composes a SIP
person locator query for a call agent in gateway "Y". However,
because the managed IP network has failed, the query does not reach
gateway "Y" in step 706 and there is no response. As is customary
in all calls to an external agent, the originating call agent sets
a timer upon launching the query and this is periodically tested
for expiry in step 710. Eventually the timer expires and the
originating call agent abandons the person locator step and
proceeds directly to the Routing Decision Tree in step 712. The
failed status of the IP network may affect the outcome of the
routing decision, particularly if user "A" has insufficient
privileges to complete an internal VPN or, in particular, a Centrex
network call, in an emergency situation. It is assumed that a
decision is made to proceed with the call via the PSTN.
[0101] In step 718 the originating call agent directs trunk gateway
"X" to set up a PSTN call to the provided NA, which is equivalent
to the Directory Number (DN) of the target endpoint. This is
populated into the Called Party Number parameter of the SS7 Initial
Address Message (IAM) and user "A's" NA is populated into the
Calling Party Number parameter. Given the failure situation, there
is no valid token for population into the Generic Name parameter,
as would normally be done on inter-gateway calls within the private
network. Instead, a null value is inserted.
[0102] The PSTN sets up the call between gateways in step 720. When
the call is received at gateway "Y", it is not anticipated by the
call agent associated with the DN, as would normally be the case
for an internal call. This is because the person locator function
was not performed. Accordingly, the call flow proceeds through
steps 724 to 728, or through steps 724 and 726 to step 728. The
flow having reached step 728 without encountering a matching
record, the terminating call agent treats this as a new call and
launches a query to its co-located Directory Server. By matching
the caller's identity with an existing NA record in step 730, the
Directory Server recognizes this as a call from within the private
network. The null token confirms that a failure occurred and that a
default routing translation needs to be made. Based on attributes
within the NA record found in step 730, the Directory Server
translates the caller's identity to a CA in step 732. The CA is
used to access user "A's" profile in order to extract business unit
identity and privileges, which otherwise would have been available
in a matching call-in-progress record at step 726. The
Default_Routing flag is set by the Directory Server and the
response is sent back to the terminating call agent at step
736.
[0103] Assuming an acceptable outcome at step 736, the
Default_Routing flag tells the call agent to negotiate the Matching
Decision Tree at step 740. Normally, the terminating leg of an
inter-gateway internal call would not need to negotiate the
Matching Decision Tree, as this would already have been done during
the person locator stage of the call flow. Assuming an acceptable
outcome from the Matching Decision Tree, the call completes in the
usual manner through steps 746, 748, 750, and 752.
[0104] The following degradations from the normal Quality of
Service occur in the failure mode: roaming users cannot be logged
off and on with an acceptable level of service portability; calls
cannot be redirected at the source, if required which results in
less efficient routing on forwarded calls; if the managed IP
network is being used for VoIP, call handling capacity is reduced,
more calls are given "no trunks available" treatment by the Routing
Decision Tree; data transport is lost between gateways and
multimedia calls are collapsed to become voice calls only; and
advanced end-to-end features which rely on the power of IP
signaling do not work. These degradations are considered tolerable
from the viewpoint of basic voice services.
Interworking in Native Mode
[0105] A preferred embodiment of the present invention includes a
method for handling calls between customer networks being served by
the deployment of the system of this invention. This method permits
a base level of person locator functionality such that a user can
physically move from the home network to a plurality of others and
have calls forwarded to those networks, without knowing the
physical destination NA in advance.
[0106] In a preferred embodiment of the present invention, the
"foreign" user, identified as John Smith calling from 416-555-5001,
logs on at the Portability Server in one of the other networks in
the following manner. At step 536 in FIG. 10B the Portability
Server does not recognize this user's name. Assuming the network
has been configured by the system administrator to allow foreign
users to log on, the Portability Server enters into a conversation
with the user to confirm his name and his intent to be registered
on the network as a foreign user. At step 537, it is recognized by
the Portability Server that a foreign user is being logged on. It
sets a Foreign-User flag and causes the call flow to jump to step
544. The response back to the call agent contains the
aforementioned flag and the user's name. The call agent then relays
a message to the Directory Server in step 550, adding the foreign
user's current NA. Recognizing the Foreign-User flag, the Directory
Server creates a temporary user profile object for the foreign user
with generic profile capabilities established by the system
administrator for this type of user. The user name field contains
"johnsmith" and the current network address contains 2125557951.
This temporary record is purged automatically by the Directory
Server after a user-settable interval. These temporary records for
foreign users are differentiated from internal user profile objects
so that searches on the user name key are kept in context. This
prevents conflicts with internal user names. The system
administrator may require that a naming convention be followed to
prevent conflicts amongst foreign users.
[0107] Referring to FIG. 4C, and assuming the call flow has
progressed to the point where the Matching Decision Tree in the
originating network has provided an IP address, SIP person locator
queries are launched towards the potential destination networks in
step 196. As identified herein before the search key for the target
user is identified as <sip.johnsmith@othercorp.com>. The
destination networks' Directory Servers do the search, one of them
finds the temporary record created earlier, and returns a PSTN
Directory Number, which is 212-555-7951. The originating call agent
then requests the trunk gateway to set up a PSTN call to the
indicated phone number.
Unassigned Network Addresses
[0108] In a particular embodiment, an NA may have no assigned CA,
for example, in an office move where the original CA has been
reassigned elsewhere. In this preferred embodiment of the present
invention, when the assigned user permanently moves to another
location, and this transaction is authenticated by the system
administrator, the system of the present invention automatically
assigns a special user class to the NA. Based on a datafillable
customer option, this class can route all call attempts to the
system administrator, using a call setup method identical to that
used to reach the Portability Server. The system administrator can
then extract the necessary information from the user to set up a
new CA to NA association. This can be used to eliminate
administrative overhead and delay when a new user moves into an
existing office equipped with a phone jack, simply by having a
prior authorization of the CA in an electronic file within the
system.
[0109] It should be understood that the programs, processes,
methods and systems described herein are not related or limited to
any particular type of computer or network system (hardware or
software), unless indicated otherwise. Various types of general
purpose or specialized computer systems may be used with or perform
operations in accordance with the teachings described herein.
[0110] In view of the wide variety of embodiments to which the
principles of the present invention can be applied, it should be
understood that the illustrated embodiments are exemplary only, and
should not be taken as limiting the scope of the present invention.
For example, the steps of the flow diagrams may be taken in
sequences other than those described, and more or fewer elements
may be used in the block diagrams. While various elements of the
preferred embodiments have been described as being implemented in
software, in other embodiments hardware or firmware implementations
may alternatively be used, and vice-versa.
[0111] It will be apparent to those of ordinary skill in the art
that methods involved in the system and method for providing call
management services in a Virtual Private Network using Voice or
Video over Internet Protocol may be embodied in a computer program
product that includes a computer usable medium. For example, such a
computer usable medium can include a readable memory device, such
as, a hard drive device, a CD-ROM, a DVD-ROM, or a computer
diskette, having computer readable program code segments stored
thereon. The computer readable medium can also include a
communications or transmission medium, such as, a bus or a
communications link, either optical, wired, or wireless having
program code segments carried thereon as digital or analog data
signals.
[0112] The claims should not be read as limited to the described
order or elements unless stated to that effect. Therefore, all
embodiments that come within the scope and spirit of the following
claims and equivalents thereto are claimed as the invention.
* * * * *
References