CA2313852A1 - Mobile agent-based service architecture for internet telephony and method of controlling service mobility - Google Patents
Mobile agent-based service architecture for internet telephony and method of controlling service mobility Download PDFInfo
- Publication number
- CA2313852A1 CA2313852A1 CA 2313852 CA2313852A CA2313852A1 CA 2313852 A1 CA2313852 A1 CA 2313852A1 CA 2313852 CA2313852 CA 2313852 CA 2313852 A CA2313852 A CA 2313852A CA 2313852 A1 CA2313852 A1 CA 2313852A1
- Authority
- CA
- Canada
- Prior art keywords
- service
- terminal
- services
- domain
- agent
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Abstract
A service architecture for Internet telephony that utilizes mobile agents and the Session Initiation Protocol (SIP). The architecture includes a mobile agent that includes service scripts for a plurality of related services such as all originating services or all terminating services. A service interaction manager in the mobile agent controls interactions between the related services. The mobile agent may include Intelligent Network (IN) service logic as well as scripts written in a SIP-compatible language such as Call Processing Language (CPL} or SIP Common Gateway Interface (CGI). A terminal equipped with an agency retrieves and executes the services.
Adapters for each script language enable the agency to retrieve the service scripts from the mobile agent. Additionally, a general adapter controls general and service-paradigm-independent interaction between the mobile agent and basic call processing functions in the terminal. A Service Implementation Repository (SIR) contains executable code for all services to which end users can subscribe, and a Service Management Unit (SMU) creates and updates mobile agents according to the end user's subscription by downloading relevant elements from the SIR. The architecture supports intra-domain and inter-domain service mobility, and immediate and on-demand service provision.
Adapters for each script language enable the agency to retrieve the service scripts from the mobile agent. Additionally, a general adapter controls general and service-paradigm-independent interaction between the mobile agent and basic call processing functions in the terminal. A Service Implementation Repository (SIR) contains executable code for all services to which end users can subscribe, and a Service Management Unit (SMU) creates and updates mobile agents according to the end user's subscription by downloading relevant elements from the SIR. The architecture supports intra-domain and inter-domain service mobility, and immediate and on-demand service provision.
Description
MOBILE AGENT-BASED SERVICE ARCHITECTURE
FOR INTERNET TELEPHONY AND METHOD OF
CONTROLLING SERVICE MOBILITY
PRIORITY STATEMENT UNDER 35 U.S.C. ~ 119(e) & 37 C.F.R. ~ 1.78 This nonprovisional application claims priority based upon the prior U.S.
provisional patent application entitled, "Mobile Agents for Value Added Services in Session Initiation Protocol (S1P)", application number 60/144,983, filed July 22,1999, in the names of Roch Glitho and Huan A. Wang.
BACKGROUND OF THE INVENTION
Technical Field of the Invention This invention relates to telecommunication systems and, more particularly, to a service architecture for Internet telephony that utilizes mobile agents and an Internet protocol such as the Session Initiation Protocol (SIP).
Description of Related Art In addition to high-quality voice calls, circuit-switched telephony offers a host of advanced services. Examples are free phone, call diversion, and virtual private networks (VPNs). From the perspective of an end user, Internet telephony offers fewer services, but its pricing scheme offers a major advantage. However, this advantage will probably not East forever. In order to survive and thrive, Internet telephony needs to offer not only the same high quality for voice calls, but also advanced services that are at least at par with what is offered in circuit-switched networks. Sound and comprehensive service architectures are needed to provide high-quality voice calls and advanced services..
The architectural model of Internet telephony differs from that of the traditional telephone network because all signaling and media flow are carried over an Internet Protocol (IP)-based network, either the public Internet or various intranets, instead of a circuit-switched network. In the traditional telephone architecture, nodes can generally only communicate with those other nodes to which they are directly connected. IP-ba.sed networks on the other hand, present the appearance at the network level that any machine can communicate directly with any other.
Intelligent Network (IN) is the currently implemented architecture for classical telephony. The ma j or difference between classical telephony and IP telephony is that, in the latter, call and connection controls do not have to be performed by the network nodes. They can b~e performed by the end systems located at the edges of the network.
Therefore, IP telephony services can be provided purely from end to end, without any intervention from network entities.
Two sets of standards are emerging for Tnternet telephony: H.323 from the International Telecommunications Union - Telecommunication Standardization Sector (ITU-T), and Session Initiation Protocol (SIP) from the Internet Engineering Task Force (IETF). The; associated service architectures are still in their infancy and have many shortcomings. The H.323 service architecture draws heavily on the Integrated Services Digital Network (ISDN) service architecture and focuses on supplementary services. It follows a service-by-service approach with a rather generic part in recommendation H.450.1 and rather heavy service-specific parts in separate recommendations. To date, service-specific parts have been specified for two services:
call diversion and call transfer. Several other services are currently being specified.
The architecture defines on a per-service basis, control entities and the messages they exchange. Examples of control entities defined for call diversion are the diverting entity and the re-routing entity. The diverting entity is the end point where diversion is invoked while the re-routing entity is the entity that establishes the call to the end point to which the call should be re-routed.
Unlike circuit-switched telephony where the same switch invokes diversion and performs the actual re-routing, diverting and re-routing entities need not be the same in Internet telephony. For example, a gatekeeper could invoke call diversion, but request the calling party terminal to do the re-routing instead of doing it itself. This request is an exarr~ple of the messages exchanged by control entities, and which are referred to herein as "service-execution related signaling messages". The called party terminal could also invoke the call diversion, and request either the gatekeeper or the calling party terminal to do the re-routing, using the same service-execution related signaling message.
Session Initiation Protocol (SIP) is a simple signaling protocol proposed by the IETF for .IP tele;phony. SIP can realize IP telephony services through the implementation of'service logic and data at end systems: SIP proxy servers, redirect servers, or user agents. Although SIP can provide more value-added services, it is still immature, and in its present form does not provide enough flexibility and efficiency for those services. For example, the SIP service architecture does not support service mobility.
The SIP in.frastruct:ure transforms the locations at which many services are performed. In general, the SIP implementation assumes that end systems are much more intelligent that in the traditional telephone model. Thus, many services that traditionally had to reside within the network can be moved out to the user agents without requiring any explicit support for them within the network. Other services can be performed by widely separated specialized servers which can proxy or redirect the calls on behalf of t:he subscribers.
The SIP service architecture focuses on service-execution related signaling and service creation. LJnlike H.323, SIP service-execution related signaling messages are not defined on a :per-service basis. They are built using two tools: SIP
request methods and SIP header fields. The tools are used either separately or in combination.
They allow the specification of service-execution related signaling messages for a wide range of services. Two principal tools are offered for service creation:
Call Processing Language (CPL) and SIP Common Gateway Interface (CGI). CPL targets end users while SIP CGI targets more experienced service developers.
By using SIP header fields to create services, callers are allowed to express preference about h.ow their calls are to be handled. Examples of services which may be created this way are services that allow end users to restrict or prioritize locations to which calls should be forwarded. It should be noted that the range of services that can be created in this manner is rather limited.
Mobile A ents in :Existing Networks All switchf;s are equipped with what is referred to as agencies or mobile agent platforms. Agencies are execution environments for mobile agents. However a key underlying assumption in existing networks is that an IN service paradigm is used. IN
is network-centric:, and it follows that the agents are more likely to roam within the network, although the possibility exists of having them roam at the edges. The key features ofthe mobile agent-based service architecture for IN services are summarized below.
The IN service creation environment (SCE) is enhanced in order to allow the creation of IN services as mobile agents. A mobile agent can be defined as an autonomous computer program that can migrate between physical locations within the network on behalf of a person or organization. Mobile agents are capable of suspending their execution, transporting themselves to another network node, and resuming execution from the point at which they were suspended. The use of mobile agents has several main advantages: reduction of network traffic, asynchronous interaction, robustness, and flexibility in service provision. There is an agent for each service for which the user has a subscription, and each agent includes both service logic and service data. Upon subscription, the agent moves to the agency of the switch to which the user phone is attached. Thus far, the use of mobile agents in Internet telephony has been confined to services utilizing IN service logic. An adapter unit makes the bridge between the IN interface offered by the switch and the mobile IN
services residing on the switch agency.
Thus, each switch is equipped with a mobile agent platform (agency) for executing mobile agents. A Service Management Unit (SMU) through which the user requests services is also provided. Through a web page, for example, the user can ask to subscribe to a service such as call forwarding. The service, implemented as a mobile agent, moves to a mobile agent platform associated with the switch.
During execution, when the service is triggered, the switch contacts the agent, and the service is executed. The <;ontrol is then given back to the switch.
Many advantages are associated with the mobile agent-based service architecture. For example, mobile service agents can be installed for a limited time duration; network traffic can be reduced; services can be provisioned on demand; and service creation and management can be integrated. Furthermore, new classes of -$-services which take advantage of the mobility aspects of the agent can be created.
There are ;>everal disadvantages to the existing service architecture utilizing mobile agents. First, there is a multiplicity of mobile agents. For each service, there is a mobile agent. Thus, if a user subscribes to 20 services, 20 mobile agents must be implemented. Second, all of the services are implemented using IN procedures.
Therefore, the service logic interacts with the switch exactly like it does in the IN
context. Thus, the architecture is much like part of a Service Control Point (SCP) that has been moved to the mobile agent platform (agency). In 1P telephony, there are other service creation tools like CPL or SIP CGI that may be used more effectively.
However, the basic SIP protocol does not interact with the service in the same way as IN does, so basic changes are needed in the service architecture to support the use of these tools.
In order to overcome the disadvantage of existing solutions, it would be advantageous to h<ive a service architecture for Internet telephony that utilizes mobile agents and an Internet protocol such as the Session Initiation Protocol (SIP).
The architecture would group related services in a single agent, and would provide for the use of tools other than IN that are more efficient for use with SIP. The present invention provides such an architecture.
SUMMARY OF 'THE INVENTION
In one aspect, the present invention is a service architecture for Internet telephony that utilizes mobile agents. The description herein is related to the Session Initiation Protocol (SIP), but can be applied to H..323 by those skilled in the art. The architecture comprises a mobile agent that includes service scripts for a plurality of related services such as all originating services, and a terminal equipped with an agency for retrieving and executing the services. The mobile agent may include Intelligent Network (IN) service logic as well as scripts written in a SIP-compatible language such as C,'all Processing Language (CPL;) or SIP Common Gateway Interface (CGI). The architecture includes adapters for each script language that enable the agency to retrieve the service scripts from the mobile agent. Additionally, a general adapter controls general and service-paradigm-independent interaction between the mobile agent and basic call processing functions in the terminal. The mobile agent includes a service interaction manager that controls interactions between the related services. A Service Management Unit (SMU) creates and updates mobile agents according to the e:nd user's subscription. This may be done by downloading relevant S elements from a Service Implementation Repository (SIR) that contains executable code for all services to which end users can subscribe.
In another aspect, the present invention is a method for use with the architecture of the present invention of controlling infra-domain service mobility when a user migrates from a first terminal to a second terminal within a single Internet domain. The method begins by sending a first registration request message from the first terminal to a. local domain proxy server when the user begins using the first terminal. The fimt registration request message includes an address for the first terminal. The local domain proxy server then sends a mobile agent that includes a plurality of originating services (originating services agent) to the first terminal, and 1 S retains a mobile agent that includes a plurality of terminating services (terminating services agent) at the local domain proxy server. When the user begins using the second terminal, a second registration request message is sent to the local domain proxy server. The; second message is sent from the second terminal and includes an address for the second terminal. The local domain proxy server then sends the address for the second terminal to the originating services agent at the first terminal. Finally, the originating services agent is sent from the first terminal to the second terminal.
In another aspect, the present invention is a method for use with the architecture ofthe present invention of controlling inter-domain service mobility when a user migrates from a first terminal in a home Internet domain to a second terminal in a second Internet domain, the home domain having a home domain proxy server, and the second domain having a second domain proxy server. The method begins by sending an originating services agent from the home domain proxy server to the first terminal when the user begins using the first terminal and registers with the first domain proxy server. A terminating services agent is retained at the home domain proxy server. When the user begins using the second terminal, the second terminal sends a second registration request message to the home domain proxy server and _7_ includes a domain address for the second terminal. A third registration request message is also sent from the second terminal to the second domain proxy server, and includes the address for the second terminal. This is followed by sending the terminating services agent from the home domain proxy server to the second domain proxy server, sending the domain address for the second terminal from the home domain proxy server to the originating services agent at the first terminal, and sending the originating services agent from the first terminal to the second domain proxy server. Finally, th.e originating services agent is sent from the second domain proxy server to the second terminal.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention will be better understood and its numerous objects and advantages will become more apparent to those skilled in the art by reference to the following drawings, in conjunction with the accampanying specification, in which:
FIG. 1 is an illustrative drawing illustrating a mobile agent residing on a terminal equipped with an agency;
FIG. 2 is a simplified block diagram of the Mobile Agent SIP service architecture of the present invention illustrating the creation and publication of services;
FIG. 3 is a simplified block diagram of the Mobile Agent SIP service architecture of the: present invention when spanning multiple domains;
FIG. 4 is a flow diagram illustrating the process followed by the present invention during intra-domain service mobility when a user migrates within the same domain; and FIG. 5 is a flow diagram illustrating the process followed by the present invention during inter-domain service mobility when a user migrates from one domain to another domain..
DETAILED DESCRIPTION OF EMBODIMENTS
The present invention provides a novel service architecture for Internet telephony that utilizes mobile agents and, preferably, the Session Initiation Protocol _g_ (SIP), although the architecture can be applied to H.323 by those skilled in the art.
The architecture h~~s been designed to support Internet telephony services using the SIP
protocol while exhibiting the following characteristics:
1. Support for a wide range of services.
2. Rapid service creation and deplo5~rnent.
3. Customization of services for users and groups of users.
4. Independence of the service architecture and the network architecture.
S. Open service creation with support for the mufti-player environment.
6. Ea:>e of service management.
7. Support for universal access to services independent of user terminals and location.
8. Capability to interwork with other service architectures including service architectures from the circuit-switched environment, for ex~unple, IN.
SIP Service Architecture Utilizing Mobile Age, nts FIG. 1 is an illustrative drawing illustrating a mobile agent 1 entitled Originating Services Agent residing on a terminal 2 equipped with an agency.
The mobile agent includes a coordinator 3, a User Prof le 4 containing grouped originating services, a Service Interaction Manager 5, Service S 1 (6) and Service S2 (7) which are implemented in IrJ service logic, and Service S3 (8) which is implemented in CPL
script. The Interaction between the terminal and the agent is facilitated by a general adapter 9, an IN adapter 10, and a CPL adapter 11. It is assumed that the user subscribes to Services S 1 and S2 which are IN service logic, and that the user has developed the CP1L Service S3 himself.
Because of the advantages offered by mobile agents, mobile agents are suitable for providing an advanced service architecture for SIP-based IP telephony.
From the Internet telephony standpoint, the main weakness of past approaches is the key underlying assumption of the use of IN as the sole service paradigm. There are other service paradigms in use in Internet telephony, such as CPL and SIP CGI. Going beyond the IN paradigm means departing from the network-centric view, and allowing BRIEF DESCRIPTION OF T
agents to roam at 'the edges of the network when appropriate.
FIG. 2 is a simplified block diagram of the Mobile Agent SIP service architecture of the present invention illustrating the creation and publication of services. There are four basic components of the mobile agent-based SIP
service S architecture. They are the First Level Service Creator 1 S, the Second Level Service Provider 16, the Service Management Unit (SMLf) 17, and the end user 18. The First Level Service Creator is an entity that creates and advertises services for second level service providers. It consists of a Service Component Creator (SCC) 19, a Service Component Repository (SCR) 20, and a Lookup Service (LUS) 21. The First Level Service Creator brings opportunities for second level service providers to compete in the service market.
The Second Level Service Provider 16 is an entity that creates, advertises, and provides value-added services directly to end users. It consists of an Enterprise Service Creator (IESC) 22, a Service Implementation Repository (SIR) 23, and an 1 S Enterprise LUS 24. The SMU 17 is an agent provider that provides and updates mobile service agents according to the end user's subscription. Through an Internet link 25, the SMU <;an discover the LUS 21, and help end users to subscribe and update their desired serviices. After end users subscribe to the desired services, the SMU
creates mobile agents that contain the subscriber services.
The end user 18 is the person who actually uses the services. The end user may or may not be the; same as the service subscriber. For example, a company may subscribe to the VPN service, but the employees in that company are the service end users. On the other hand, an individual may serve as both service subscriber and end user when he subscribes to both originating and terminating services.
Originating services are designated as AIN services and terminating services are designated as BIN
services in the description herein.
FIG. 3 is a simplified block diagram of the mobile agent-based SIP service architecture 30 of the present invention. The architecture has been shown to extend through Domain A 31 and Domain B 32. A single SMU 17 provides mobile service agents to end users in different domains throughout the network. A mobile agent platform, SMU agency 34, is provided to this agent provider. To simplify the architecture of the present invention and scenarios for SIP IP telephony, it is assumed that the SMU has already discovered all service components in a desired SIR, and the SMU can fetch those components directly from the SIR to create mobile service agents.
S The AIN and BIN services are individual services, so the person who subscribes to the service is the end user. The architecture of the present invention provides an end user agency to every terminal in the network so that each end user can subscribe to services from any terminal, and the end user can also utilize the services from any terminal. This is shown in FIG. 3 as Terminal A 35 having End User Agency 36 and Terminal B 37 having End User Agency 38.
Each end user can migrate to and register at different domains over the Internet.
It is assumed that l:here is only one proxy server in every domain, and that the agency connected to the proxy server service agency can be named. This is shown in FIG. 3 as Proxy Server A 39 having Service Agency 41 and Proxy Server B 42 having Service Agency 43.
The preser,~t invention provides a service architecture that does not rely on IN
as the sole service paradigm. It can accommodate any service paradigm including IN.
From the practical. point of view, this description focuses on IN, CPL, and SIP CGI
service paradigms. although others may be utilized. Referring again to FIG. 1, it is shown that in addition to the IN-adapter 10 as known in previous architectures, a CPL-adapter unit 11 (or a SIP CGI-adapter unit), and a general-adapter unit 12 are introduced. The general-adapter unit is used for general and service-paradigm-independent interaction between the agents and basic call processing in the terminal 2. It should be noted that these different adapter units are needed because IN, CPL, and SIP CGI differ significantly in the way they interact with basic call processing.
When basic call processing invokes a CPL script, the script takes control and handles the rest of the call. On the other hand, there is usually a dialogue between basic call processing and IN service logic or SIP CGI service logic after service invocation.
Grouped Services Services invoked in a similar manner are grouped together in a single folder in the architecture of the present invention. FICr. 1 illustrates an example in which originating services are grouped together in the mobile agent's User Profile 4 which includes a list of services in the set along with the data required for the execution of each service. The grouping is done on a per-subscriber basis. From the invocation point of view, services that are invoked when a user initiates a call can be distinguished from services that are invoked when the user receives a call.
Thus, originating services such as outgoing call screening, abbreviated dialing, etc. are distinguished from terminating services such as incoming call screening, call forwarding, etc. In addition to their type of invocation, the services also share other characteristics. In the context of Internet telephony, most services related to the initiation of a call are optimally executed on the end terminal while most of the services related to~ the reception of a call are optimally executed on a server in the network because the end terminal might be turned off. Furthermore, services in the same group are more likely to interact with each other. The present invention provides the Service Interaction Manager 5 in the folder in order to control the interactions between related services.
Mobile Agents There are two kinds of mobile agent functionality: remote execution and migration. Remote execution refers to the fact that a mobile agent can be transferred to a remote system. for local activation and execution. Migration refers to the fact that during its execution, a mobile agent may move from node to node in order to progressively accomplish its task. In other words, agents are capable of suspending their execution, transporting themselves to another node in the network, and resuming execution from the point at which they were suspended. In addition, agents may launch new agents during their journey in order to distribute the tasks more efficiently.
The migration of software processes can be regarded as an extension to the concept of remote execution, Apart from its code and data, the migration agent also has an explicit execution state allowing it to suspend execution at a specific state at one node, and resume execution from that state after migrating to another node.
The use of mobile agents provides two main advantages: reduction of network traffic and asynchronous interaction. Compared to the client server approach, which can generate a high level of network traffic and can be susceptible to congestion delay, the use of mobile agents brings the requesting client closer to the source and hence reduces the network traffic. This also achieves a more robust architecture since a reduction in the dependence on network availability is achieved by moving the required logic and. data closer to the source.
Two mobiile agents defined on a per-subscriber basis are the heart of the architecture: the Originating Services Agent and the Terminating Services Agent.
The Originating Services Agent is created when. the user subscribes for the first time to an originating service while the Terminating Services Agent is created when the user subscribes for the first time to a terminating service. For the set of services to which the user subscribes, each agent contains a coordinator, a user profile, a service interaction manager, and executable code (or a proxy to the code) for each service belonging to the set.
As noted .above, the Originating Services Agent is created when the user subscribes for the first time to an originating service while the Terminating Services Agent is created when the user subscribes for the first time to a tenminating service. The first agent is updated each time the user subscribes to a new originating service: while the second agent is updated each time the user subscribes to a new terminating; service. Updates are performed by the coordinator and consist of upgrading the service interaction manager, the user profile, and adding the service logic (or script) or its proxy to the set.
Refernng .again to FIGS. 2 and 3, it is seen that from the implementation point of view, there are ~,wo key entities: the SMU 17 and the SIR 23. These entities belong to the service provider. The SIR contains the executable code of all services to which end users can subscribe. The services are created by the service provider or by third parties using appropriate IN or CPL or SIP CGI service creation environments.
The SIR also contains the code for the agent coordinator and code for a generic service interaction manager.
When the user subscribes to the first originating service (or the first terminating service), the SMU creates the Originating_Services Agent (or the Terminating Services Agent) by downloading the relevant elements from the SIR.
The SMU then dispatches the agent to the user terminal or to the appropriate network node, SIP proxy server, or H.323 gatekeeper. The SMU and the SIR communicate using HTTP. For subsequent subscriptions, the SMU dispatches the executable code to the agent, and the coordinator updates the user profile and service interaction manager.
The capabi lities of the new architecture can be demonstrated by showing how it can solve the universal access problem in SIP. In SIP, when a user is in a domain, he registers with tile domain proxy server from his terminal when he logs on.
When the domain is not his home domain, he also remotely registers with his home domain proxy server in order to indicate his current location. In the case of infra-domain roaming, when the: home domain proxy server is alerted that the user has logged onto a new terminal, tree home domain proxy server alerts the SMU, and the SMU asks either the Originating Services Agent (or a clone) to move to the new terminal. In the case of inter-domain roaming, the SMU is alerted by the same proxy server, and the Originating_Sc;rvices Agent and the Terminating Services Agent (or clones) are asked to move to the new terminal and to the proxy server of the foreign home domain, respectively. Infra-domain and inter-domain roaming are described in more detail in FIGS. 4 and 5.
User Service Agents (LTSAs) are deployed to the end users, thereby providing an open, distributed, and flexible service architecture. When using H.323 IP-based telephony, USAs and Call Agents (CAs) are used to provide supplementary services.
In the SIP-based architecture, service logic and data are implemented internally in the mobile service agents, so the USA can provide value added services directly to end users, and CAs are not required. This approach has the advantage of providing immediate and on-demand service provision. In the architecture of the present invention, service logic and data are contained internally in the mobile service agent, and the mobile service agent is already at the proxy server agent before the incoming call arnves. This is an optimum architecture for immediate and on-demand service provision since no time is required for USA migration and CA creation.
The mobile agent-based service architecture, instead of using one USA to provide all types of services, uses two types of mobile service agents.
Originating services are designated as AIN services and terminating services are designated as BIN
services. Accordingly, an AIN Service Agent (ASA) is used to provide originating services and a BIN Service Agent (BSA) is used to provide terminating services.
Because originating and terminating services are provided at different places in the network, splitting the USA into two mobile service agents facilitates service mobility.
Service mobilitv Service mobility means that the same kind of services are provided to different domains or even different networks. Although SIP can provide value-added services at end systems in different domains, it is not flexible and efficient to support service mobility. For example, a SIP user agent can provide originating services at end systems, but every end system in the network is required to support service logic for all subscribers because end users may migrate to and log on at different end systems in different domains from time to time. This requires intelligent end systems to have very large memory capacity in order to store all user profiles, which is not feasible.
The Internet is geographically divided into areas called domains. In SIP; each domain may have one or more proxy servers or redirect servers responsible for call handling. In the architecture of the present invention, it is assumed that there is only one proxy server in each domain.
When an end user enters a new domain, he registers with that domain's proxy server from a local terminal. If the domain he enters is not his home domain, the user also registers remotely with his home domain proxy server.
In IP telephony, an end user can migrate to and log on at different terminals all over the Internet. A user may register with his home domain proxy server from different terminals in his home domain, and may migrate to another domain and register both with this home domain proxy server and the other domain proxy server.
All moving users are assumed to have a permanent "home proxy" that never changes.
They also have a permanent home address that can be used to determine their home locations. The proxy or redirect server is responsible for forwarding or redirecting incoming calls made to a user's home address to wherever the user may migrate in the network.
The present invention recognizes and supports two kinds of service mobility:
intra-domain service mobility within a single domain and inter-domain service mobility between <iomains. FIG. 4 is a flow diagram illustrating the process followed S by the present invention during intra-domain service mobility when a user migrates within the same domain. A Local Domain Proxy Server S 1 serves an end user utilizing Terminal A 52 who later moves to Terminal B 53. In this case, the is retained at the Local Domain Proxy Server, but the ASA follows the user and migrates to the terminal where the user is currently located.
When the user first begins using Terminal A 52, he sends a REGISTER
Request message 'i5 to the Local Domain Proxy Server 51 and includes the Terminal A address in the Contact header. At 56, the ASA migrates to Terminal A. When the user moves from Terminal A to Terminal B within the same domain at step 57, he first sends a REGISTER Request message 58 to the Local Domain Proxy Server indicating his new address in the Contact header. At step 59, the Local Domain Proxy Server checks this user's register file in its database, and at step 60 appends a new record of the user's current address at the end of the file. At step 61, the Local Domain Proxy Server finds the old address of the user in the register file (where the ASA
is currently located), and at st<;p 62 sends the user's current address to the ASA. At step 63, the ASA migrates to Terminal B, the end system where the user is currently located, according to the new address it received.
FIG. 5 is .a flow diagram illustrating the process followed by the present invention during inter-domain service mobility when a user migrates from one domain (Domain A) to another domain (Domain B). A Domain A Proxy Server 71 serves an end user utilizing Terminal A 72. A Domain B Proxy Server 73 serves Terminal B
74.
If the user moves to another domain, in order to provide service on demand, both ASA
and BSA follow the user and migrate to the domain where the user is currently located.
This migration procedure may be realized by copying the service agent from the user's home domain and sending the newly copied agent to the current domain.
Normally, the service agent v~rill follow the user from the previous domain to the current domain after the home proxy server gets the registration information from the user in the current domain.
When the user first begins using Terminal A 72, he sends a REGISTER
Request message 75 to the Domain A Proxy Server 71 and includes the Terminal A
address in the Contact header. At 76, the ASA migrates to Terminal A. When the user moves from Terminal A in Domain A to Terminal B in Domain B at step 77, he first sends a REGISTER Request message 78 to his home domain proxy server indicating his new address in the Contact header. If it is assumed that Domain A is the end user's home domain, the; message is sent to the Domain A Proxy Server. He also sends a REGISTER Request message 79 to the Domain B Proxy Server 73 indicating the Terminal B address in the Contact header. At step 80, the Domain A Proxy Server checks this user's register file in its database, and at step 81 appends a new record of the user's current address at the end of the file. At step 82, the Domain A
Proxy Server finds the old address of the user in the register file (where the ASA is currently located). The BSA is always located in the proxy server in the domain where the end user is currently operating. Therefore, if Domain A is the end user's home domain, the BSA will be in the Domain A Proxy Server. If Domain A is not the end user's home domain, the. home domain proxy server finds the address for the BSA
(i.e., the Domain A Proxy Server) in the register file.
The user's new domain address is then sent to the ASA (and the BSA if not in the home domain proxy server) at step 83. The BSA and the ASA then migrate at steps 84 and 85, respectively, to the Domain B Proxy Server 73 where the user is currently located according to the new address received. After migration to the Domain B Proxy Server, the BSA stays at this domain proxy server, and at step 86, the ASA migrates to 'Terminal B 74 where the user is currently located.
It is thus believed that the operation and construction of the present invention will be apparent from the foregoing description. While the system architecture and method described has been characterized as being preferred, it will be readily apparent that various changes and modifications could be made therein without departing from the scope of the invention as defined in the following claims.
FOR INTERNET TELEPHONY AND METHOD OF
CONTROLLING SERVICE MOBILITY
PRIORITY STATEMENT UNDER 35 U.S.C. ~ 119(e) & 37 C.F.R. ~ 1.78 This nonprovisional application claims priority based upon the prior U.S.
provisional patent application entitled, "Mobile Agents for Value Added Services in Session Initiation Protocol (S1P)", application number 60/144,983, filed July 22,1999, in the names of Roch Glitho and Huan A. Wang.
BACKGROUND OF THE INVENTION
Technical Field of the Invention This invention relates to telecommunication systems and, more particularly, to a service architecture for Internet telephony that utilizes mobile agents and an Internet protocol such as the Session Initiation Protocol (SIP).
Description of Related Art In addition to high-quality voice calls, circuit-switched telephony offers a host of advanced services. Examples are free phone, call diversion, and virtual private networks (VPNs). From the perspective of an end user, Internet telephony offers fewer services, but its pricing scheme offers a major advantage. However, this advantage will probably not East forever. In order to survive and thrive, Internet telephony needs to offer not only the same high quality for voice calls, but also advanced services that are at least at par with what is offered in circuit-switched networks. Sound and comprehensive service architectures are needed to provide high-quality voice calls and advanced services..
The architectural model of Internet telephony differs from that of the traditional telephone network because all signaling and media flow are carried over an Internet Protocol (IP)-based network, either the public Internet or various intranets, instead of a circuit-switched network. In the traditional telephone architecture, nodes can generally only communicate with those other nodes to which they are directly connected. IP-ba.sed networks on the other hand, present the appearance at the network level that any machine can communicate directly with any other.
Intelligent Network (IN) is the currently implemented architecture for classical telephony. The ma j or difference between classical telephony and IP telephony is that, in the latter, call and connection controls do not have to be performed by the network nodes. They can b~e performed by the end systems located at the edges of the network.
Therefore, IP telephony services can be provided purely from end to end, without any intervention from network entities.
Two sets of standards are emerging for Tnternet telephony: H.323 from the International Telecommunications Union - Telecommunication Standardization Sector (ITU-T), and Session Initiation Protocol (SIP) from the Internet Engineering Task Force (IETF). The; associated service architectures are still in their infancy and have many shortcomings. The H.323 service architecture draws heavily on the Integrated Services Digital Network (ISDN) service architecture and focuses on supplementary services. It follows a service-by-service approach with a rather generic part in recommendation H.450.1 and rather heavy service-specific parts in separate recommendations. To date, service-specific parts have been specified for two services:
call diversion and call transfer. Several other services are currently being specified.
The architecture defines on a per-service basis, control entities and the messages they exchange. Examples of control entities defined for call diversion are the diverting entity and the re-routing entity. The diverting entity is the end point where diversion is invoked while the re-routing entity is the entity that establishes the call to the end point to which the call should be re-routed.
Unlike circuit-switched telephony where the same switch invokes diversion and performs the actual re-routing, diverting and re-routing entities need not be the same in Internet telephony. For example, a gatekeeper could invoke call diversion, but request the calling party terminal to do the re-routing instead of doing it itself. This request is an exarr~ple of the messages exchanged by control entities, and which are referred to herein as "service-execution related signaling messages". The called party terminal could also invoke the call diversion, and request either the gatekeeper or the calling party terminal to do the re-routing, using the same service-execution related signaling message.
Session Initiation Protocol (SIP) is a simple signaling protocol proposed by the IETF for .IP tele;phony. SIP can realize IP telephony services through the implementation of'service logic and data at end systems: SIP proxy servers, redirect servers, or user agents. Although SIP can provide more value-added services, it is still immature, and in its present form does not provide enough flexibility and efficiency for those services. For example, the SIP service architecture does not support service mobility.
The SIP in.frastruct:ure transforms the locations at which many services are performed. In general, the SIP implementation assumes that end systems are much more intelligent that in the traditional telephone model. Thus, many services that traditionally had to reside within the network can be moved out to the user agents without requiring any explicit support for them within the network. Other services can be performed by widely separated specialized servers which can proxy or redirect the calls on behalf of t:he subscribers.
The SIP service architecture focuses on service-execution related signaling and service creation. LJnlike H.323, SIP service-execution related signaling messages are not defined on a :per-service basis. They are built using two tools: SIP
request methods and SIP header fields. The tools are used either separately or in combination.
They allow the specification of service-execution related signaling messages for a wide range of services. Two principal tools are offered for service creation:
Call Processing Language (CPL) and SIP Common Gateway Interface (CGI). CPL targets end users while SIP CGI targets more experienced service developers.
By using SIP header fields to create services, callers are allowed to express preference about h.ow their calls are to be handled. Examples of services which may be created this way are services that allow end users to restrict or prioritize locations to which calls should be forwarded. It should be noted that the range of services that can be created in this manner is rather limited.
Mobile A ents in :Existing Networks All switchf;s are equipped with what is referred to as agencies or mobile agent platforms. Agencies are execution environments for mobile agents. However a key underlying assumption in existing networks is that an IN service paradigm is used. IN
is network-centric:, and it follows that the agents are more likely to roam within the network, although the possibility exists of having them roam at the edges. The key features ofthe mobile agent-based service architecture for IN services are summarized below.
The IN service creation environment (SCE) is enhanced in order to allow the creation of IN services as mobile agents. A mobile agent can be defined as an autonomous computer program that can migrate between physical locations within the network on behalf of a person or organization. Mobile agents are capable of suspending their execution, transporting themselves to another network node, and resuming execution from the point at which they were suspended. The use of mobile agents has several main advantages: reduction of network traffic, asynchronous interaction, robustness, and flexibility in service provision. There is an agent for each service for which the user has a subscription, and each agent includes both service logic and service data. Upon subscription, the agent moves to the agency of the switch to which the user phone is attached. Thus far, the use of mobile agents in Internet telephony has been confined to services utilizing IN service logic. An adapter unit makes the bridge between the IN interface offered by the switch and the mobile IN
services residing on the switch agency.
Thus, each switch is equipped with a mobile agent platform (agency) for executing mobile agents. A Service Management Unit (SMU) through which the user requests services is also provided. Through a web page, for example, the user can ask to subscribe to a service such as call forwarding. The service, implemented as a mobile agent, moves to a mobile agent platform associated with the switch.
During execution, when the service is triggered, the switch contacts the agent, and the service is executed. The <;ontrol is then given back to the switch.
Many advantages are associated with the mobile agent-based service architecture. For example, mobile service agents can be installed for a limited time duration; network traffic can be reduced; services can be provisioned on demand; and service creation and management can be integrated. Furthermore, new classes of -$-services which take advantage of the mobility aspects of the agent can be created.
There are ;>everal disadvantages to the existing service architecture utilizing mobile agents. First, there is a multiplicity of mobile agents. For each service, there is a mobile agent. Thus, if a user subscribes to 20 services, 20 mobile agents must be implemented. Second, all of the services are implemented using IN procedures.
Therefore, the service logic interacts with the switch exactly like it does in the IN
context. Thus, the architecture is much like part of a Service Control Point (SCP) that has been moved to the mobile agent platform (agency). In 1P telephony, there are other service creation tools like CPL or SIP CGI that may be used more effectively.
However, the basic SIP protocol does not interact with the service in the same way as IN does, so basic changes are needed in the service architecture to support the use of these tools.
In order to overcome the disadvantage of existing solutions, it would be advantageous to h<ive a service architecture for Internet telephony that utilizes mobile agents and an Internet protocol such as the Session Initiation Protocol (SIP).
The architecture would group related services in a single agent, and would provide for the use of tools other than IN that are more efficient for use with SIP. The present invention provides such an architecture.
SUMMARY OF 'THE INVENTION
In one aspect, the present invention is a service architecture for Internet telephony that utilizes mobile agents. The description herein is related to the Session Initiation Protocol (SIP), but can be applied to H..323 by those skilled in the art. The architecture comprises a mobile agent that includes service scripts for a plurality of related services such as all originating services, and a terminal equipped with an agency for retrieving and executing the services. The mobile agent may include Intelligent Network (IN) service logic as well as scripts written in a SIP-compatible language such as C,'all Processing Language (CPL;) or SIP Common Gateway Interface (CGI). The architecture includes adapters for each script language that enable the agency to retrieve the service scripts from the mobile agent. Additionally, a general adapter controls general and service-paradigm-independent interaction between the mobile agent and basic call processing functions in the terminal. The mobile agent includes a service interaction manager that controls interactions between the related services. A Service Management Unit (SMU) creates and updates mobile agents according to the e:nd user's subscription. This may be done by downloading relevant S elements from a Service Implementation Repository (SIR) that contains executable code for all services to which end users can subscribe.
In another aspect, the present invention is a method for use with the architecture of the present invention of controlling infra-domain service mobility when a user migrates from a first terminal to a second terminal within a single Internet domain. The method begins by sending a first registration request message from the first terminal to a. local domain proxy server when the user begins using the first terminal. The fimt registration request message includes an address for the first terminal. The local domain proxy server then sends a mobile agent that includes a plurality of originating services (originating services agent) to the first terminal, and 1 S retains a mobile agent that includes a plurality of terminating services (terminating services agent) at the local domain proxy server. When the user begins using the second terminal, a second registration request message is sent to the local domain proxy server. The; second message is sent from the second terminal and includes an address for the second terminal. The local domain proxy server then sends the address for the second terminal to the originating services agent at the first terminal. Finally, the originating services agent is sent from the first terminal to the second terminal.
In another aspect, the present invention is a method for use with the architecture ofthe present invention of controlling inter-domain service mobility when a user migrates from a first terminal in a home Internet domain to a second terminal in a second Internet domain, the home domain having a home domain proxy server, and the second domain having a second domain proxy server. The method begins by sending an originating services agent from the home domain proxy server to the first terminal when the user begins using the first terminal and registers with the first domain proxy server. A terminating services agent is retained at the home domain proxy server. When the user begins using the second terminal, the second terminal sends a second registration request message to the home domain proxy server and _7_ includes a domain address for the second terminal. A third registration request message is also sent from the second terminal to the second domain proxy server, and includes the address for the second terminal. This is followed by sending the terminating services agent from the home domain proxy server to the second domain proxy server, sending the domain address for the second terminal from the home domain proxy server to the originating services agent at the first terminal, and sending the originating services agent from the first terminal to the second domain proxy server. Finally, th.e originating services agent is sent from the second domain proxy server to the second terminal.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention will be better understood and its numerous objects and advantages will become more apparent to those skilled in the art by reference to the following drawings, in conjunction with the accampanying specification, in which:
FIG. 1 is an illustrative drawing illustrating a mobile agent residing on a terminal equipped with an agency;
FIG. 2 is a simplified block diagram of the Mobile Agent SIP service architecture of the present invention illustrating the creation and publication of services;
FIG. 3 is a simplified block diagram of the Mobile Agent SIP service architecture of the: present invention when spanning multiple domains;
FIG. 4 is a flow diagram illustrating the process followed by the present invention during intra-domain service mobility when a user migrates within the same domain; and FIG. 5 is a flow diagram illustrating the process followed by the present invention during inter-domain service mobility when a user migrates from one domain to another domain..
DETAILED DESCRIPTION OF EMBODIMENTS
The present invention provides a novel service architecture for Internet telephony that utilizes mobile agents and, preferably, the Session Initiation Protocol _g_ (SIP), although the architecture can be applied to H.323 by those skilled in the art.
The architecture h~~s been designed to support Internet telephony services using the SIP
protocol while exhibiting the following characteristics:
1. Support for a wide range of services.
2. Rapid service creation and deplo5~rnent.
3. Customization of services for users and groups of users.
4. Independence of the service architecture and the network architecture.
S. Open service creation with support for the mufti-player environment.
6. Ea:>e of service management.
7. Support for universal access to services independent of user terminals and location.
8. Capability to interwork with other service architectures including service architectures from the circuit-switched environment, for ex~unple, IN.
SIP Service Architecture Utilizing Mobile Age, nts FIG. 1 is an illustrative drawing illustrating a mobile agent 1 entitled Originating Services Agent residing on a terminal 2 equipped with an agency.
The mobile agent includes a coordinator 3, a User Prof le 4 containing grouped originating services, a Service Interaction Manager 5, Service S 1 (6) and Service S2 (7) which are implemented in IrJ service logic, and Service S3 (8) which is implemented in CPL
script. The Interaction between the terminal and the agent is facilitated by a general adapter 9, an IN adapter 10, and a CPL adapter 11. It is assumed that the user subscribes to Services S 1 and S2 which are IN service logic, and that the user has developed the CP1L Service S3 himself.
Because of the advantages offered by mobile agents, mobile agents are suitable for providing an advanced service architecture for SIP-based IP telephony.
From the Internet telephony standpoint, the main weakness of past approaches is the key underlying assumption of the use of IN as the sole service paradigm. There are other service paradigms in use in Internet telephony, such as CPL and SIP CGI. Going beyond the IN paradigm means departing from the network-centric view, and allowing BRIEF DESCRIPTION OF T
agents to roam at 'the edges of the network when appropriate.
FIG. 2 is a simplified block diagram of the Mobile Agent SIP service architecture of the present invention illustrating the creation and publication of services. There are four basic components of the mobile agent-based SIP
service S architecture. They are the First Level Service Creator 1 S, the Second Level Service Provider 16, the Service Management Unit (SMLf) 17, and the end user 18. The First Level Service Creator is an entity that creates and advertises services for second level service providers. It consists of a Service Component Creator (SCC) 19, a Service Component Repository (SCR) 20, and a Lookup Service (LUS) 21. The First Level Service Creator brings opportunities for second level service providers to compete in the service market.
The Second Level Service Provider 16 is an entity that creates, advertises, and provides value-added services directly to end users. It consists of an Enterprise Service Creator (IESC) 22, a Service Implementation Repository (SIR) 23, and an 1 S Enterprise LUS 24. The SMU 17 is an agent provider that provides and updates mobile service agents according to the end user's subscription. Through an Internet link 25, the SMU <;an discover the LUS 21, and help end users to subscribe and update their desired serviices. After end users subscribe to the desired services, the SMU
creates mobile agents that contain the subscriber services.
The end user 18 is the person who actually uses the services. The end user may or may not be the; same as the service subscriber. For example, a company may subscribe to the VPN service, but the employees in that company are the service end users. On the other hand, an individual may serve as both service subscriber and end user when he subscribes to both originating and terminating services.
Originating services are designated as AIN services and terminating services are designated as BIN
services in the description herein.
FIG. 3 is a simplified block diagram of the mobile agent-based SIP service architecture 30 of the present invention. The architecture has been shown to extend through Domain A 31 and Domain B 32. A single SMU 17 provides mobile service agents to end users in different domains throughout the network. A mobile agent platform, SMU agency 34, is provided to this agent provider. To simplify the architecture of the present invention and scenarios for SIP IP telephony, it is assumed that the SMU has already discovered all service components in a desired SIR, and the SMU can fetch those components directly from the SIR to create mobile service agents.
S The AIN and BIN services are individual services, so the person who subscribes to the service is the end user. The architecture of the present invention provides an end user agency to every terminal in the network so that each end user can subscribe to services from any terminal, and the end user can also utilize the services from any terminal. This is shown in FIG. 3 as Terminal A 35 having End User Agency 36 and Terminal B 37 having End User Agency 38.
Each end user can migrate to and register at different domains over the Internet.
It is assumed that l:here is only one proxy server in every domain, and that the agency connected to the proxy server service agency can be named. This is shown in FIG. 3 as Proxy Server A 39 having Service Agency 41 and Proxy Server B 42 having Service Agency 43.
The preser,~t invention provides a service architecture that does not rely on IN
as the sole service paradigm. It can accommodate any service paradigm including IN.
From the practical. point of view, this description focuses on IN, CPL, and SIP CGI
service paradigms. although others may be utilized. Referring again to FIG. 1, it is shown that in addition to the IN-adapter 10 as known in previous architectures, a CPL-adapter unit 11 (or a SIP CGI-adapter unit), and a general-adapter unit 12 are introduced. The general-adapter unit is used for general and service-paradigm-independent interaction between the agents and basic call processing in the terminal 2. It should be noted that these different adapter units are needed because IN, CPL, and SIP CGI differ significantly in the way they interact with basic call processing.
When basic call processing invokes a CPL script, the script takes control and handles the rest of the call. On the other hand, there is usually a dialogue between basic call processing and IN service logic or SIP CGI service logic after service invocation.
Grouped Services Services invoked in a similar manner are grouped together in a single folder in the architecture of the present invention. FICr. 1 illustrates an example in which originating services are grouped together in the mobile agent's User Profile 4 which includes a list of services in the set along with the data required for the execution of each service. The grouping is done on a per-subscriber basis. From the invocation point of view, services that are invoked when a user initiates a call can be distinguished from services that are invoked when the user receives a call.
Thus, originating services such as outgoing call screening, abbreviated dialing, etc. are distinguished from terminating services such as incoming call screening, call forwarding, etc. In addition to their type of invocation, the services also share other characteristics. In the context of Internet telephony, most services related to the initiation of a call are optimally executed on the end terminal while most of the services related to~ the reception of a call are optimally executed on a server in the network because the end terminal might be turned off. Furthermore, services in the same group are more likely to interact with each other. The present invention provides the Service Interaction Manager 5 in the folder in order to control the interactions between related services.
Mobile Agents There are two kinds of mobile agent functionality: remote execution and migration. Remote execution refers to the fact that a mobile agent can be transferred to a remote system. for local activation and execution. Migration refers to the fact that during its execution, a mobile agent may move from node to node in order to progressively accomplish its task. In other words, agents are capable of suspending their execution, transporting themselves to another node in the network, and resuming execution from the point at which they were suspended. In addition, agents may launch new agents during their journey in order to distribute the tasks more efficiently.
The migration of software processes can be regarded as an extension to the concept of remote execution, Apart from its code and data, the migration agent also has an explicit execution state allowing it to suspend execution at a specific state at one node, and resume execution from that state after migrating to another node.
The use of mobile agents provides two main advantages: reduction of network traffic and asynchronous interaction. Compared to the client server approach, which can generate a high level of network traffic and can be susceptible to congestion delay, the use of mobile agents brings the requesting client closer to the source and hence reduces the network traffic. This also achieves a more robust architecture since a reduction in the dependence on network availability is achieved by moving the required logic and. data closer to the source.
Two mobiile agents defined on a per-subscriber basis are the heart of the architecture: the Originating Services Agent and the Terminating Services Agent.
The Originating Services Agent is created when. the user subscribes for the first time to an originating service while the Terminating Services Agent is created when the user subscribes for the first time to a terminating service. For the set of services to which the user subscribes, each agent contains a coordinator, a user profile, a service interaction manager, and executable code (or a proxy to the code) for each service belonging to the set.
As noted .above, the Originating Services Agent is created when the user subscribes for the first time to an originating service while the Terminating Services Agent is created when the user subscribes for the first time to a tenminating service. The first agent is updated each time the user subscribes to a new originating service: while the second agent is updated each time the user subscribes to a new terminating; service. Updates are performed by the coordinator and consist of upgrading the service interaction manager, the user profile, and adding the service logic (or script) or its proxy to the set.
Refernng .again to FIGS. 2 and 3, it is seen that from the implementation point of view, there are ~,wo key entities: the SMU 17 and the SIR 23. These entities belong to the service provider. The SIR contains the executable code of all services to which end users can subscribe. The services are created by the service provider or by third parties using appropriate IN or CPL or SIP CGI service creation environments.
The SIR also contains the code for the agent coordinator and code for a generic service interaction manager.
When the user subscribes to the first originating service (or the first terminating service), the SMU creates the Originating_Services Agent (or the Terminating Services Agent) by downloading the relevant elements from the SIR.
The SMU then dispatches the agent to the user terminal or to the appropriate network node, SIP proxy server, or H.323 gatekeeper. The SMU and the SIR communicate using HTTP. For subsequent subscriptions, the SMU dispatches the executable code to the agent, and the coordinator updates the user profile and service interaction manager.
The capabi lities of the new architecture can be demonstrated by showing how it can solve the universal access problem in SIP. In SIP, when a user is in a domain, he registers with tile domain proxy server from his terminal when he logs on.
When the domain is not his home domain, he also remotely registers with his home domain proxy server in order to indicate his current location. In the case of infra-domain roaming, when the: home domain proxy server is alerted that the user has logged onto a new terminal, tree home domain proxy server alerts the SMU, and the SMU asks either the Originating Services Agent (or a clone) to move to the new terminal. In the case of inter-domain roaming, the SMU is alerted by the same proxy server, and the Originating_Sc;rvices Agent and the Terminating Services Agent (or clones) are asked to move to the new terminal and to the proxy server of the foreign home domain, respectively. Infra-domain and inter-domain roaming are described in more detail in FIGS. 4 and 5.
User Service Agents (LTSAs) are deployed to the end users, thereby providing an open, distributed, and flexible service architecture. When using H.323 IP-based telephony, USAs and Call Agents (CAs) are used to provide supplementary services.
In the SIP-based architecture, service logic and data are implemented internally in the mobile service agents, so the USA can provide value added services directly to end users, and CAs are not required. This approach has the advantage of providing immediate and on-demand service provision. In the architecture of the present invention, service logic and data are contained internally in the mobile service agent, and the mobile service agent is already at the proxy server agent before the incoming call arnves. This is an optimum architecture for immediate and on-demand service provision since no time is required for USA migration and CA creation.
The mobile agent-based service architecture, instead of using one USA to provide all types of services, uses two types of mobile service agents.
Originating services are designated as AIN services and terminating services are designated as BIN
services. Accordingly, an AIN Service Agent (ASA) is used to provide originating services and a BIN Service Agent (BSA) is used to provide terminating services.
Because originating and terminating services are provided at different places in the network, splitting the USA into two mobile service agents facilitates service mobility.
Service mobilitv Service mobility means that the same kind of services are provided to different domains or even different networks. Although SIP can provide value-added services at end systems in different domains, it is not flexible and efficient to support service mobility. For example, a SIP user agent can provide originating services at end systems, but every end system in the network is required to support service logic for all subscribers because end users may migrate to and log on at different end systems in different domains from time to time. This requires intelligent end systems to have very large memory capacity in order to store all user profiles, which is not feasible.
The Internet is geographically divided into areas called domains. In SIP; each domain may have one or more proxy servers or redirect servers responsible for call handling. In the architecture of the present invention, it is assumed that there is only one proxy server in each domain.
When an end user enters a new domain, he registers with that domain's proxy server from a local terminal. If the domain he enters is not his home domain, the user also registers remotely with his home domain proxy server.
In IP telephony, an end user can migrate to and log on at different terminals all over the Internet. A user may register with his home domain proxy server from different terminals in his home domain, and may migrate to another domain and register both with this home domain proxy server and the other domain proxy server.
All moving users are assumed to have a permanent "home proxy" that never changes.
They also have a permanent home address that can be used to determine their home locations. The proxy or redirect server is responsible for forwarding or redirecting incoming calls made to a user's home address to wherever the user may migrate in the network.
The present invention recognizes and supports two kinds of service mobility:
intra-domain service mobility within a single domain and inter-domain service mobility between <iomains. FIG. 4 is a flow diagram illustrating the process followed S by the present invention during intra-domain service mobility when a user migrates within the same domain. A Local Domain Proxy Server S 1 serves an end user utilizing Terminal A 52 who later moves to Terminal B 53. In this case, the is retained at the Local Domain Proxy Server, but the ASA follows the user and migrates to the terminal where the user is currently located.
When the user first begins using Terminal A 52, he sends a REGISTER
Request message 'i5 to the Local Domain Proxy Server 51 and includes the Terminal A address in the Contact header. At 56, the ASA migrates to Terminal A. When the user moves from Terminal A to Terminal B within the same domain at step 57, he first sends a REGISTER Request message 58 to the Local Domain Proxy Server indicating his new address in the Contact header. At step 59, the Local Domain Proxy Server checks this user's register file in its database, and at step 60 appends a new record of the user's current address at the end of the file. At step 61, the Local Domain Proxy Server finds the old address of the user in the register file (where the ASA
is currently located), and at st<;p 62 sends the user's current address to the ASA. At step 63, the ASA migrates to Terminal B, the end system where the user is currently located, according to the new address it received.
FIG. 5 is .a flow diagram illustrating the process followed by the present invention during inter-domain service mobility when a user migrates from one domain (Domain A) to another domain (Domain B). A Domain A Proxy Server 71 serves an end user utilizing Terminal A 72. A Domain B Proxy Server 73 serves Terminal B
74.
If the user moves to another domain, in order to provide service on demand, both ASA
and BSA follow the user and migrate to the domain where the user is currently located.
This migration procedure may be realized by copying the service agent from the user's home domain and sending the newly copied agent to the current domain.
Normally, the service agent v~rill follow the user from the previous domain to the current domain after the home proxy server gets the registration information from the user in the current domain.
When the user first begins using Terminal A 72, he sends a REGISTER
Request message 75 to the Domain A Proxy Server 71 and includes the Terminal A
address in the Contact header. At 76, the ASA migrates to Terminal A. When the user moves from Terminal A in Domain A to Terminal B in Domain B at step 77, he first sends a REGISTER Request message 78 to his home domain proxy server indicating his new address in the Contact header. If it is assumed that Domain A is the end user's home domain, the; message is sent to the Domain A Proxy Server. He also sends a REGISTER Request message 79 to the Domain B Proxy Server 73 indicating the Terminal B address in the Contact header. At step 80, the Domain A Proxy Server checks this user's register file in its database, and at step 81 appends a new record of the user's current address at the end of the file. At step 82, the Domain A
Proxy Server finds the old address of the user in the register file (where the ASA is currently located). The BSA is always located in the proxy server in the domain where the end user is currently operating. Therefore, if Domain A is the end user's home domain, the BSA will be in the Domain A Proxy Server. If Domain A is not the end user's home domain, the. home domain proxy server finds the address for the BSA
(i.e., the Domain A Proxy Server) in the register file.
The user's new domain address is then sent to the ASA (and the BSA if not in the home domain proxy server) at step 83. The BSA and the ASA then migrate at steps 84 and 85, respectively, to the Domain B Proxy Server 73 where the user is currently located according to the new address received. After migration to the Domain B Proxy Server, the BSA stays at this domain proxy server, and at step 86, the ASA migrates to 'Terminal B 74 where the user is currently located.
It is thus believed that the operation and construction of the present invention will be apparent from the foregoing description. While the system architecture and method described has been characterized as being preferred, it will be readily apparent that various changes and modifications could be made therein without departing from the scope of the invention as defined in the following claims.
Claims (16)
1. A service architecture for Internet telephony that utilizes mobile agents and the Session Initiation Protocol (SIP), said architecture comprising:
a first mobile agent that includes service scripts for a plurality of related services; and a terminal equipped with an agency for retrieving and executing the services.
a first mobile agent that includes service scripts for a plurality of related services; and a terminal equipped with an agency for retrieving and executing the services.
2. The service architecture of claim 1 wherein the first mobile agent includes Call Processing Language (CPL) scripts, and the architecture further comprises:
a general adapter for controlling general and service-paradigm-independent interaction between the first mobile agent and basic call processing functions in the terminal; and a CPL adapter that enables the agency to retrieve the CPL scripts from the first mobile agent.
a general adapter for controlling general and service-paradigm-independent interaction between the first mobile agent and basic call processing functions in the terminal; and a CPL adapter that enables the agency to retrieve the CPL scripts from the first mobile agent.
3. The service architecture of claim 1 wherein the first mobile agent includes SIP Common Gateway Interface (CGI) scripts, and the architecture further comprises:
a general adapter for controlling general and service-paradigm-independent interaction between the first mobile agent and basic call processing functions in the terminal; and a SIP CGI adapter that enables the agency to retrieve the SIP CGI scripts from the first mobile agent.
a general adapter for controlling general and service-paradigm-independent interaction between the first mobile agent and basic call processing functions in the terminal; and a SIP CGI adapter that enables the agency to retrieve the SIP CGI scripts from the first mobile agent.
4. The service architecture of claim 1 wherein the first mobile agent includes service scripts for a plurality of originating services.
5. The service architecture of claim 1 wherein the first mobile agent includes service scripts for a plurality of terminating services.
6. The service architecture of claim 1 wherein the first mobile agent includes service scripts for a plurality of originating services, and the architecture further comprises a second mobile agent that includes service scripts for a plurality of terminating services.
7. The service architecture of claim 1 wherein the first mobile agent includes a service interaction manager that controls interactions between the related services.
8. The service architecture of claim 7 wherein the first mobile agent includes a coordinator that updates the service interaction manager and the plurality of related services when a new service is added.
9. The service architecture of claim 7 further comprising a Service Management Unit (SMU) that creates and updates mobile agents according to an end user's subscription.
10. The service architecture of claim 9 further comprising a Service Implementation Repository (SIR) that contains executable code for all services to which end users can subscribe, and the SMU includes means for creating the mobile agents by downloading relevant elements from the SIR.
11. A service architecture for Internet telephony that utilizes mobile agents and the Session Initiation Protocol (SIP), said architecture comprising:
a first mobile agent that includes:
Call Processing Language (CPL) service scripts for a plurality of related services; and Intelligent Network (IN) service logic for the plurality of related services;
a terminal equipped with an agency for retrieving and executing the services;
a CPL adapter that enables the agency to retrieve the CPL scripts from the first mobile agent;
an IN adapter that enables the agency to retrieve the IN service logic from the first mobile agent; and a general adapter for controlling general and service-paradigm-independent interaction between the first mobile agent and basic call processing functions in the terminal.
a first mobile agent that includes:
Call Processing Language (CPL) service scripts for a plurality of related services; and Intelligent Network (IN) service logic for the plurality of related services;
a terminal equipped with an agency for retrieving and executing the services;
a CPL adapter that enables the agency to retrieve the CPL scripts from the first mobile agent;
an IN adapter that enables the agency to retrieve the IN service logic from the first mobile agent; and a general adapter for controlling general and service-paradigm-independent interaction between the first mobile agent and basic call processing functions in the terminal.
12. The service architecture of claim 11 wherein the first mobile agent also includes a service interaction manager that controls interactions between the related services.
13. The service architecture of claim 12 wherein the first mobile agent includes a coordinator that updates the service interaction manager and the plurality of related services when a new service is added.
14. The service architecture of claim 13 further comprising a Service Management Unit (SMU) that creates and updates mobile agents according to an end user's subscription.
15. In a service architecture for Internet telephony that utilizes mobile agents and the Session Initiation Protocol (SIP), a method of controlling intra-domain service mobility when a user migrates from a first terminal to a second terminal within a single Internet domain, said method comprising the steps of:
sending a first registration request message from the first terminal to a local domain proxy server when the user begins using the first terminal, said first registration request message including an address for the first terminal;
sending a mobile agent that includes a plurality of originating services (originating services agent) from the local domain proxy server to the first terminal;
retaining a mobile agent that includes a plurality of terminating services (terminating services agent) at the local domain proxy server;
sending a s second registration request message to the local domain proxy server when the user begins using the second terminal, said second message being sent from the second terminal and including an address for the second terminal;
sending the; address for the second terminal from the local domain proxy server to the originating services agent at the first terminal; and sending the originating services agent from the first terminal to the second terminal.
sending a first registration request message from the first terminal to a local domain proxy server when the user begins using the first terminal, said first registration request message including an address for the first terminal;
sending a mobile agent that includes a plurality of originating services (originating services agent) from the local domain proxy server to the first terminal;
retaining a mobile agent that includes a plurality of terminating services (terminating services agent) at the local domain proxy server;
sending a s second registration request message to the local domain proxy server when the user begins using the second terminal, said second message being sent from the second terminal and including an address for the second terminal;
sending the; address for the second terminal from the local domain proxy server to the originating services agent at the first terminal; and sending the originating services agent from the first terminal to the second terminal.
16. In a service architecture for Internet telephony that utilizes mobile agents and the Session Initiation Protocol (SIP), a method of controlling inter-domain service mobility when a user migrates from a first terminal in a home Internet domain to a second terminal in a second Internet domain, the home domain having a home domain proxy server and the second domain having a second domain proxy server, said method comprising the steps of:
sending a mobile agent that includes a plurality of originating services (originating services agent) from the home domain proxy server to the first terminal when the user begins using the first terminal and registers with the first domain proxy server;
retaining a. mobile agent that includes a plurality of terminating services (terminating services agent) at the home domain proxy server;
sending a second registration request message to the home domain proxy server when the user begins using the second terminal, said second message being sent from the second terminal and including a new domain address for the second terminal;
sending a third registration request message to the second domain proxy server when the user begins using the second terminal, said third message being sent from the second terminal and including the address for the second terminal;
sending the terminating services agent from the home domain proxy server to the second domain proxy server;
sending the domain address for the second terminal from the home domain proxy server to the originating services agent at the first terminal;
sending the originating services agent from the first terminal to the second domain proxy server; and sending the originating services agent from the second domain proxy server to the second terminal.
sending a mobile agent that includes a plurality of originating services (originating services agent) from the home domain proxy server to the first terminal when the user begins using the first terminal and registers with the first domain proxy server;
retaining a. mobile agent that includes a plurality of terminating services (terminating services agent) at the home domain proxy server;
sending a second registration request message to the home domain proxy server when the user begins using the second terminal, said second message being sent from the second terminal and including a new domain address for the second terminal;
sending a third registration request message to the second domain proxy server when the user begins using the second terminal, said third message being sent from the second terminal and including the address for the second terminal;
sending the terminating services agent from the home domain proxy server to the second domain proxy server;
sending the domain address for the second terminal from the home domain proxy server to the originating services agent at the first terminal;
sending the originating services agent from the first terminal to the second domain proxy server; and sending the originating services agent from the second domain proxy server to the second terminal.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US14498399P | 1999-07-22 | 1999-07-22 | |
| US60/144,983 | 1999-07-22 | ||
| US53796600A | 2000-03-28 | 2000-03-28 | |
| US09/537,966 | 2000-03-28 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2313852A1 true CA2313852A1 (en) | 2001-01-22 |
Family
ID=26842550
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2313852 Abandoned CA2313852A1 (en) | 1999-07-22 | 2000-07-11 | Mobile agent-based service architecture for internet telephony and method of controlling service mobility |
Country Status (3)
| Country | Link |
|---|---|
| BR (1) | BR0002729A (en) |
| CA (1) | CA2313852A1 (en) |
| MY (1) | MY133241A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1919163A1 (en) * | 2006-11-06 | 2008-05-07 | Vodafone Group PLC | Method, network and device for the location, communication and migration of mobile agents |
| US7953799B2 (en) * | 2001-02-23 | 2011-05-31 | Nokia Siemens Networks Oy | Service control device and method |
| CN113055398A (en) * | 2021-03-31 | 2021-06-29 | 杭州恒生数字设备科技有限公司 | SIP architecture-based multi-level cross-domain equipment certificate management system |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111314099B (en) * | 2018-12-11 | 2023-04-28 | ***通信集团重庆有限公司 | Network resource monitoring method, device, equipment and medium |
-
2000
- 2000-07-11 MY MYPI20003174 patent/MY133241A/en unknown
- 2000-07-11 CA CA 2313852 patent/CA2313852A1/en not_active Abandoned
- 2000-07-12 BR BR0002729-4A patent/BR0002729A/en not_active IP Right Cessation
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7953799B2 (en) * | 2001-02-23 | 2011-05-31 | Nokia Siemens Networks Oy | Service control device and method |
| EP1919163A1 (en) * | 2006-11-06 | 2008-05-07 | Vodafone Group PLC | Method, network and device for the location, communication and migration of mobile agents |
| CN113055398A (en) * | 2021-03-31 | 2021-06-29 | 杭州恒生数字设备科技有限公司 | SIP architecture-based multi-level cross-domain equipment certificate management system |
| CN113055398B (en) * | 2021-03-31 | 2022-04-22 | 杭州恒生数字设备科技有限公司 | SIP architecture-based multi-level cross-domain equipment certificate management system |
Also Published As
| Publication number | Publication date |
|---|---|
| BR0002729A (en) | 2001-12-04 |
| MY133241A (en) | 2007-10-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6940847B1 (en) | System and method for providing access to service nodes from entities disposed in an integrated telecommunications network | |
| US6735621B1 (en) | Method and apparatus for messaging between disparate networks | |
| US8098802B2 (en) | DSL integrated call waiting | |
| EP1096808B1 (en) | Communications switching system | |
| US7366291B2 (en) | Call transfer service using service control point and service node | |
| US8532089B2 (en) | Call intercept for voice over internet protocol (VoIP) | |
| US7277444B2 (en) | Method and system for distributing and executing service logic | |
| US7616623B1 (en) | Technique for providing intelligent features for calls in a communications network independent of network architecture | |
| US7424106B2 (en) | Routing traffic between carriers | |
| JP2002528932A (en) | Method and apparatus for providing real-time call processing services in intelligent networks | |
| KR20010022744A (en) | Management of calling name delivery in telephone networks providing for telephone number portability | |
| JP3708052B2 (en) | System and method for creating subscriber services in a communication system based on the Internet protocol | |
| US6327358B1 (en) | System and method for rerouting data calls to internet service provider via lowest access point in a telephone network | |
| US7212621B1 (en) | Feature interactions | |
| GB2243517A (en) | Call processing | |
| US6707901B1 (en) | Subscriber profile extension (SPEX) | |
| WO2002073911B1 (en) | Sharing remote terminals | |
| FI109396B (en) | Implementation of services in an IP telephone network | |
| US7881286B2 (en) | Method for distributing and executing service logic | |
| CA2313852A1 (en) | Mobile agent-based service architecture for internet telephony and method of controlling service mobility | |
| US7221739B1 (en) | Callback function for messaging platform in public telephone system | |
| JP2000165453A (en) | Gateway between data network and service network | |
| EP1352508B1 (en) | Improvements in service oriented networks | |
| Parr et al. | RIDE replacement—a hybrid PSTN/VoIP application solution | |
| Wang | Building value-added services using mobile agents in SIP based internet telephony |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Dead |