KR20070019669A - Method for remote service forwardingrsf between dissimilar systems with operator, service and location portability - Google Patents

Abstract

The remote service forwarding (RSF) system allows a telephone service user to access subscribed services without loss of service via different access devices. The system allows a user to access different systems or to use different telephone devices or different service providers by porting services over an IP connection. A user may access subscribed services, such as Centrex or PBX services, via a mobile IP connection.

RSF, telephone service user, subscribed service, different access device, exporting service provider, importing service provider, IP connection, porting, call

Description

METHOD FOR REMOTE SERVICE FORWARDING (RSF) BETWEEN DISSIMILAR SYSTEMS WITH OPERATOR, SERVICE AND LOCATION PORTABILITY}

This application claims priority to US Provisional Patent Application No. 60 / 527,361, filed December 5, 2003, which is incorporated herein by reference.

The present invention relates to a digital telephone. More specifically, the present invention relates to mobile switching centers (MSCs), IP telephony, hosted PBXs, and enterprise PHS networks.

In one known solution of remote call forwarding (RCF), a customer calls a phone number forwarded to a new location, unknown to the caller. The originating local exchange of the customer parks the call while it initiates a signaling message to the apparent terminating local exchange. When the signaling message reaches the original destination local switching center via the CCS7 network, the switch polls the customer line to determine the state of the customer line (eg, whether the customer line is available, busy, or Is delivered). If the circuit is forwarded, the lookup table is looked up to determine the new location of the number, and a new signaling path is established. In order to establish a new signaling path, another signaling message is sent to the new clear destination local exchange and the process is repeated until the correct destination customer line is identified. If the line is available, the switch returns a message to the originating switching station indicating that everything for call completion is ready. The call is then recovered by the originating exchange and routed along the same path previously passed on the signaling network.

Problems with this on-switch solution of RCF include service limitations to a single system. In addition, the call path (or at least signaling path) must be completed before the ported number is recognized. This results in inefficient call routing where the majority of ported numbers may become unacceptable.

In other solutions known as off-switches, the previously associated switches are allowed to access information about the numbers ported earlier in the call setup phase. In this solution, the customer calls a phone number that may or may not have been ported to the new location. The originating local exchange of the customer (known as the Service Switching Point (SSP) in the IN architecture) parks the call while it initiates a CCS7 signaling message from the Service Control Point (SCP) to the IN database. When the signaling message reaches the SCP, the database is queried to determine the network address or routing number associated with the dialed telephone number. SCP returns routing information to SSP. The SSP then sends a signaling message to the destination exchange to determine whether a called party is available. The call is recovered by the SSP, and the call path is established through an optimal path to the destination local exchange.

In such off-switch solutions, there is no equivalent to an incoming database solution for non-geographic services. Furthermore, they do not provide a method for linking services of a user subscribed to multiple service providers to one device, application, or location.

Further, conventional solutions also have the disadvantage of having to assume quality circuit connections that do not exist in ad hoc Internet connections. Instead, quality of service is assumed for the endpoint.

Various IP telephony solutions are known in the art. For example, US Pat. No. 6,069,809 to White et al. Teaches telephone-type services over the Internet. U. S. Patent No. 6,021, 126 to White et al. Teaches the use of the Internet for phone number portability. White and Ferris, US Pat. No. 6,014,379, teach telecommunications custom calling services over the Internet. US Pat. No. 6,324,279 to Kalmanek et al teaches signaling for linking two different systems for IP telephony. All of these disclosures are incorporated herein by reference. However, these solutions do not provide a method for linking the services of a user subscribed to multiple service providers to one device.

Due to a remote service forwarding (RSF) system, a telephone service user may lose or change service through different access devices, even if the user accesses different systems or uses different telephone devices or different service providers. Without access to subscribed services.

In operation of the RSF system, a first exporting service provider receives a call to a telephone number. The system determines whether the call should be forwarded, and if so, identifies the internet protocol (IP) address associated with that phone number and forwards the call to that IP address.

The system can forward calls from multiple different systems to a single user device. As a result, the system may receive a second call to a different phone number at a different exporting service provider. Nevertheless, the system may identify the same IP address for delivery to the same user of the call.

The system allows forwarding calls to the user's IP devices from the exporting service provider to the importing service provider. The system also allows the user to access services provided by the exporting service provider, including services such as outgoing telephone calls and voice mail.

1 is a schematic block diagram illustrating connections between service providers and user devices.

2 is a schematic flow diagram illustrating service setup in an RSF system.

3 is a schematic flow diagram illustrating incoming call handling in an RSF system.

4 is a schematic flow diagram illustrating outgoing call handling in an RSF system.

I. Overview of the REMOTE SERVICE FORWARDING System

Due to a remote service forwarding (RSF) system, a telephone service user may lose or change service through different access devices, even if the user accesses different systems or uses different telephone devices or different service providers. Without access to subscribed services.

One example is the extension of PBX or Centrex services. The user can use his commercial hardware phone at his desk, or use a Wi-Fi (or PHS) enabled wireless IP phone if he is moving around the workplace, or if he is out of the workplace (GSM, CDMD or Ordinary mobile phones (such as PHS phones) can be used. Due to the RSF system, services provided to a PBX user can be delivered to these different devices even if the user is using these different devices.

In another example, even if the user is away from the area of the home service provider, he can still manage to access the services as an IP device. The IP device may be, for example, an application running on a personal computer (PC) having an IP connection. The application includes a graphical user interface that mimics the interface of the telephone apparatus by telephone buttons. The application registers the user with a home service provider (such as Verizon) via an access service provider (such as Comcast), requesting that the regular wireless service be delivered to the application until the registration is canceled.

The system centralizes services from office phones and mobile phones of operators that do not have a common element into a single, centralized representation (such as a centralized mailbox) in an IP application or IP device. In addition, the system may use a drop-back to a mobile or fixed in-house wired call to be used when a concentrated IP application fails to connect as described herein. Such dropbacks are implemented in such a way that lifeline services are met or enhanced enough to be effectively bypassed.

The system provides means for wireless operators and private enterprise communications to port phone numbers and convert certain subscriber calls to voice over IP (VoIP) such that calls are forwarded to and from user-specified URLs. do. The URL may be associated with a speakerphone application on a PC or other IP device for the user. The apparatus may act as an alternative endpoint for originating or terminating calls and services temporarily and seamlessly, instead of the endpoint of originating.

This service can be created in a VoIP telephony network using remote call forwarding where call-paths to ported numbers are established by a switch of a non-geographic exporting service provider. The exporting service provider uses its service database to identify the importing service provider by IP address or URL, and then the call is converted to IP and forwarded to that service provider's softswitch. Alternatively, the call is not translated and is not forwarded to the associated media gateway. In the case of drop-back where the signaling path to the ported numbers is established by the switch of the non-geographic exporting service provider, the call-path may be established from both in the originating operator's network and in the forwarded network for redundancy.

For example, prior to a call, a broadband service provider (BSP), such as Comcast, registers a user IP address or URL associated with the mobile user's phone number. Mobile service providers, such as Verizon, provide BSPs with IP access to subscriber voicemail. Upon stimulus provided by the MSP subscriber, a database entry is recorded that causes remote call forward (RCF) or forking calls to the media gateway. The incoming call to the MSP triggers a database query to the MSP database to determine whether the number has been ported. The RCF triggers delivery to a media gateway and URL that is geographically associated with the MSP or BSP. The MSP or BSP sends a call to the user's IP device. A fork triggers a call flow involving both the drop-back connection through the RCF and mobile switching center (MSC) described above.

In the case of branching, rules may be established regarding how drop-back is regulated. The rules may be based, for example, on whether a port is available or whether the user responds to a ringtone at either telephone device.

In an outgoing call from an IP device on a BSP ported from an MSP, a user stimulus (such as a button press), as indicated in the BSP subscriber database, sets up a simple call where only the handshake (accounting) information is shared between the SPs. It may be initiated. Alternatively, the user stimulus may initiate complex queries to the MSP database for other transactions suitable for the MSP service package to be converted into packets for voice mail or IP.

Similarly, a BSP may register a CCP user, or, conversely, an MSP may register a BSP or CCP user as a lifeline replacement.

In the following, some of the entity relationships that can be discovered and maintained in the RSF system are illustrated. 1 illustrates data relationships used to supply and manage an RSF system. The subscriber provides phone number portability information that should be mapped to one or more service profiles, products, and profile families. These profiles include not only information about certain endpoint penalties, but also their associated specifications and policies used to operatively supply the quality or lifeline attributes of service for the session. These may now be mapped to an application manager (eg, SIP specification server) database and / or policy management system.

Upon activation, the subscriber communicates the location information and identifies the service provider and profile to be called via the incoming call. This information is mapped to an operational sequence and client databases for issuing service and accounting information, and also optionally invokes the behavior of service policy interfaces and / or session protocols of some quality between the application manager and the RSF endpoint.

Network service and network topology discovery is used to address issues such as VPIM interfaces for integrated mail services and access router type for quality of service purposes.

Seed devices, such as telephones or web browsers, can accommodate elements as described below.

Using the auto-ready model, customers can also access login-protected sites via end devices in the remote service area. The contact server may execute the seed device program via browser CGI, Java, or other techniques (such as downloadable client or embedded client routines). This discovery consists of discovering local LAN information and discovering a local site network topology.

In order to discover local site LAN information, gathering and sending subnet discovery mechanisms are provided, such as ping, ARP-a, Windows registry local machine queries, and the like.

To find the local site network topology, trace routed mechanism reports (eg, trace routed) from the customer premises to the RSF policy management element to discover the IP addresses of the first few routing network elements on the outbound packet path. RSF server) is created. These reports are collected and sent. Reverse DNS lookup may be performed on selected IP addresses of candidate access routers (such as the first 1-3 elements found) and candidate based routers that may have selective control by policy server (s). . Routing and collecting devices, their functions and access types (eg, CMTS cable router, DSL, DSLAM, Dial) in the control or service agreement sphere of the policy management element associated with the RSF function. A database of domains may be found to find out RAS, unknown / best effort.

Call flow scripts for the session / policy are created. Moderate quality of service policy messages and interfaces for this particular client type in this particular access type (e.g., CMTS DQoS policies, DSLAM ATM Virtual Circuit Supply, IntServe / DiffServ MPLS, RSVP Proxy Target Routines / Settings) And the like). Scripting of access methods with the required policy interfaces is provided as required for the discovered RSF media.

In one example, PacketCable Multimedia Architecture represents methods of invoking various policy elements for distributed QoS proxies from a policy manager at the request of an application manager. This is one embodiment of the policies found by the methods defined above for the RSF system.

In the following, an application management interface (exemplary SIP header) is shown as an embodiment for the option of performing application (SIP) endpoint specification programming of the end device using previously defined methods for remote service delivery.

The protocol between the SIP proxy and the RSF endpoint may use a new SIP header, for example X-multimedia-service-enabled. This header can be added to messages from the SIP proxy (network core device) to the SIP phone (end device). This header indicates what multimedia service should be provided and how. This information can be sent to the endpoint at registration or call setup.

Example 1

200 OK

. . .

CSeq: 1 REGISTER

. . .

X-multimedia-service-enabled: CW = yes, CCW = yes, CND = no,

DVC = WD6035, SP = SPT

Example 1 sends from a SIP proxy (operating as a registrar) to indicate that this account is subscribed only to call waiting (CW) and cancel call waiting (CCW) services and not to service of caller number delivery (CND). Message. The device to be emulated is a Kyocera 6035 phone (DVC = WD6035), and services must follow the Sprint usage (SP = SPT). After receiving this header of "200 OK" as a REGISTER message, the SIP telephone must stop presenting the calling number to the user through the entire registration lifetime, even if the telephone is equipped with such capability. do. The client device will use a Sprint Kyocera 6035 device with buttons mapped for use by these phone personalities for sprint features.

Example 2

INVITE customer@x.com SIP / 2.0

. . .

X-multimedia-service-enabled: CW = no, DVC = SEI202, SP = VRZN

Example 2 illustrates a header that may be sent to an endpoint on a call-by-call basis when the header appears in the state of responses to an INVITE message or an INVITE message. The message is sent from the SIP proxy to the callee end device. The header indicates that for the incoming call, the call-waiting service should not be provided, even if the user subscribes to the service. This is useful if the caller does not want his call to be queued. After receiving this header in the state of an incoming INVITE message, the SIP telephone must treat the incoming call as if the victim did not have call-waiting capability. In addition, the end device mapping must be a mapping of the Siemens SNO202 SIP phone indicated by the user's profile that it exists at the victim's site, and the services should be mapped to the same task as the Verizon specifications.

II. Example REMOTE SERVICE FORWARDING System

As shown in FIG. 1, a user accesses the specifications of an RSF system via an IP (Internet Protocol) device 10. IP device 10 may be, for example, a Wi-Fi (or PHS) enabled wireless IP phone or a personal computer (PC) with an IP connection. IP device 10 includes interface software 12. The interface software may be, for example, a graphical user interface application of the user's PC. In this case, the interface software preferably has a graphical interface with telephone buttons that mimics the interface of the telephone apparatus, which may, for example, mimic the appearance of a PBX or Centrex telephone equipment in a user's office. In this way, the user does not need to relearn the operation of the telephone for use in different devices.

As shown in FIG. 1, the user may be a subscriber of multiple service providers (“exporting service providers”; 16 and 18), but in the case of RSF, the user may be such a service provider through a single importing service provider 14. May access the services provided by them.

For example, if the user has configured an RSF from the second exporting service provider 18, telephone calls from the originating phone 20 may be delivered to the user by the importing service provider 14 as follows. . The calling telephone dials the telephone number corresponding to the user telephone number of the second exporting service provider 18. For example, if the second exporting service provider 18 is a mobile service provider, the user's phone number on that service provider's side is its mobile phone number. The call may originate from there via a public switched telephone network (PSTN).

Upon receiving a call from the calling telephone, the second exporting service provider 18 queries the service database 24 for information associated with the called telephone number. The service database 24 associates telephone numbers with IP addresses and / or URLs. If the results of the query indicate that calls to the called telephone number are being forwarded to another service provider, the second exporting service provider 18 retrieves the IP address associated with the called telephone number. The IP address may be geographically associated with an exporting or importing service provider. The forwarded call is sent to the importing service provider 14. For example, the importing service provider 14, which may be a broadband service provider, sends a call to the user's IP device 10.

The first exporting service provider 16 operates similarly to the second exporting service provider 18. Similar to service provider 18, service provider 16 includes its own service database 26 that associates a user's telephone numbers with IP addresses and / or URLs. The first exporting service provider 16 may be, for example, a PBX or Centrex system implemented in the user's office.

The telephone number of a single user is different for different service providers. For example, the user's office number (on the first service provider side) is different from the user's mobile phone number (on the second service provider side). Nevertheless, according to the system described herein, calls to a user through different service providers may be directed to the same IP device 10. IP device 10 may distinguish calls arriving through different service providers, for example, by using unique ring tones for callers over different networks. Similarly, interface software 12 may emulate a different telephone for calls arriving through different service providers.

In addition to being able to receive telephone calls delivered from different service providers, the user of the system may form outgoing calls and / or access services provided through different networks. To do so, the user initiates an outgoing call on the IP device 10 side by dialing a telephone number or entering a "*" command. The IP device 10 contacts the importing service provider 14 with the information entered by the user, and the importing service provider 14 is responsible for identifying the information necessary to establish communication with one of the exporting service providers. Query the service database 28 of. The user of the IP device 10 may then make outgoing calls through one of the exporting service providers, or other services of those providers, such as checking or handling voice mail messages stored by such service providers. You can also use them.

III. Example REMOTE SERVICE FORWARDING Method

A method of operating a remote delivery system is illustrated in FIGS. 2 illustrates the steps involved in setting up service delivery. In particular, in response to the user request in step 30, the system stores the porting information in databases associated with both the importing service provider (in step 32) and the exporting service provider (in step 34). In this way, calls to the exporting service provider may not only be delivered to the user of the importing service provider, but the user at the importing service provider may also access the services provided by the exporting service provider. If there is more than one exporting service provider, the porting information at the importing service provider may identify different exporting service providers.

3 shows a process for forwarding an incoming call. In step 36, a call is received at an exporting service provider. The exporting service provider then checks in step 38 to determine if the call should be forwarded. If not, the call is handled regularly, and in other cases, the exporting service provider finds the IP address and / or URL to which the call is to be forwarded at step 40 and the call is forwarded to that IP address at step 42.

4 illustrates a process for accessing a service at an exporting service provider using an IP device at the importing service provider. In step 50, the user initiates the call, and the call initiation is received by the importing service provider. In step 52, the service provider retrieves user information, which may include information identifying various exporting service providers subscribed by the user. In step 54, the importing service provider identifies the exporting service provider to be used for the call in the near future. For example, if a user has prepared a number of exporting service providers, the system may determine which service provider is used for outgoing voice calls or which system responds to "*" commands. Once the system has retrieved the required data and identified the exporting service provider, the importing service provider, in step 56, exchanges handshake information with the exporting service provider. This information may include accounting information. If the importing service provider needs any additional information to access services, such as voice mail, provided by the exporting service provider, the information may be exchanged, at step 58. After the system has received the necessary information, the importing service provider portes the service to the user over the IP network, in step 60. For example, if the importing service provider is a broadband service provider and the exporting service provider is a mobile phone service provider, the user may access his mobile phone voicemail via an IP network, for example from a PC.

Although this specification describes specific examples and embodiments to describe different implementations of the invention, it should not be understood that they limit the invention, and the practice of the invention may not be construed as a variation of the systems and methods described herein. Include. Rather, the scope of the invention is defined by the following claims.

Claims (15)

As a method for providing remote service forwarding (RSF), Receiving, at a first exporting service provider, a first call to a first telephone number; Identifying a first internet protocol address associated with the first telephone number; And Forwarding the first call to the first internet protocol address How to include. The method of claim 1, At a second exporting service provider, receiving a second call to a second telephone number; Identifying a second internet protocol address associated with the second telephone number; And Forwarding the second call to the second internet protocol address. The method of claim 2, The first telephone number and the second telephone number are different. The method of claim 3, The first internet protocol address and the second internet protocol address are the same. As a method for providing remote service forwarding (RSF), Receiving a first porting request for porting calls from an exporting service provider to an importing service provider; Storing an IP address associated with a subscriber of the importing service provider in a first database associated with the exporting service provider; And Storing service information associated with a service provided by the exporting service provider in a second database associated with the importing service provider; How to include. The method of claim 5, The exporting service provider is a mobile service provider. The method of claim 6, The importing service provider is a broadband service provider. The method of claim 7, wherein The service provided by the exporting service provider is voice mail. As a method for providing remote service forwarding (RSF), Receiving, at an exporting service provider, a call directed to the first telephone number; Determining an internet protocol address associated with the first telephone number; Determining a second telephone number associated with the first telephone number; And Forking the call by requesting that the call be forwarded to the Internet Protocol address and the second telephone number. How to include. As a method for providing remote service forwarding (RSF), Receiving a forwarding message from the user; Receiving an incoming call directed to a hardware telephone associated with the user; And Forwarding the call to a mobile telephone associated with the user How to include. The method of claim 10, The forwarding message identifies a URL to which calls will be forwarded. The method of claim 10, The forwarding message identifies the IP address to which calls will be forwarded. The method of claim 10, The hardware telephone is a private branch exchange (PBX) telephone. The method of claim 10, The mobile telephone is a wireless internet protocol telephone. The method of claim 10, The mobile telephone and the hardware telephone are operated by different service providers.

Images