GB2577942A - System and method for control of business telephone calls over cellular networks - Google Patents

Abstract

A system for the controlled use of personally owned mobile phones in a business environment is disclosed which is applicable to companies / enterprises with a multi-national presence using existing infrastructure for handling fixed line calls made by/to employees. Routing at least those calls that should or must be recorded / stored via a "Mobile Access Point" MAP 24, preferably in the country/region the phone is currently being used within. Only a local leg of a call traverses a mobile network with the call being recorded as required and routed to its endpoint within/via an existing corporate network / infrastructure / private branch exchange PBX and a least cost routing plan LCR. Additional features include: initiating concurrent voice and/or video connections, or more than one audio/video path, monitoring the states / health of other MAPs, presenting calling party information identifying an alternative number to an originating mobile phone, including a plurality of options which results in a different set of actions being taken with regard to how long a call rings and what is done afterwards (via Interactive Voice Response, IVR), and monitoring the state and/or performance of multiple networks to determine which should be used for a call.

Description

System and Method for Control of Business Telephone Calls over Cellular Networks This invention relates to a means of controlling and, optionally, recording telephone calls made to or from business mobile phone numbers.

Background

Many businesses do (or would like to) allow employees to select, purchase and use their own mobile phone with which to conduct business calls as well as personal calls. Such "Bring Your Own Device" or "BYOD" policies are now common across many industries.

However, some sectors -such as financial services -must comply with regulations such as the European Union's Markets in Financial Instruments Directive ("MiFID II"), Frank-Dodd in the U.S.A. amongst others. These can require that, for at least a subset of the calls, details about the call and, in some cases, the content of the call are recorded, archived and easily accessible to regulators.

Conversely, increasingly complex privacy regulations, such as the European Union's General Data Protection Regulations ("GDPR") mean that blanket recording of all details and voice -including private calls made on the same device -is not permitted.

There is therefore a requirement in at least some businesses for visibility, control and access to the content of the business calls made on the device. A number of approaches are already well established but all have significant disadvantages when end users are in many countries where the business already has a fixed telephony presence.

Let us call our hypothetical, multi-national, at least partially regulated company wanting to implement a global BYOD smartphone policy "GLOBALCO".

Some phones allow two SIMs to be inserted -giving them two phone numbers, one business and one personal. More recently, the eSIM specification allows this without the need for a physical SIM. This provides separation of business and personal calls, each using a separate phone number -often over different Mobile Network Operators (MN0s).

Some MNOs provide recording services "in the network" allowing calls over the business number to be recorded there. However, this may be sub-optimal when the user travels overseas as it either requires a similar recording capability in the MNO which the user is roaming on, or the call has to be routed to or a fork taken to the recording service in the user's home network.

As there are no truly global MN05, GLOBALCO cannot do a single deal with one provider for such a service. As operators come and go, signing up to vaguely similar services from several MNOs is not attractive. One or other will be bought, leave a territory, cease trading or change this offering soon.

GLOBALCO typically will already have at least one recording system and would rather the call details and content were delivered into that than to a separate, MNO-specific system. Some regulations require that all communications associated with a given transaction are presented together -quickly and easily on demand. This drives GLOBALCO to seek solutions that feed its existing recording systems instead.

Alternative solutions -say from hypothetical company "SMALLCO" -use an application on the phone to route business calls via one or more switching hubs (owned or at least operated by SMALLCO) before they are connected on to the far end i.e. the destination phone number. In this way, the audio can be recorded at said hub and/or forwarded to a separate recording service. However, existing such solutions then route the call from said hub either directly to the number dialled or do so via an overlay network of such switching hubs. The latter approach can avoid international phone call charges by routing the call via the Internet (typically using SIPS) to the country in which the destination phone number is present. The final leg of the call is then placed over that destination country's telephone network.

This approach requires that GLOBALCO pays SMALLCO for the calls its hubs place over the various fixed and mobile networks that SMALLCO has chosen. GLOBALCO is likely to already have deals in place with telecom operators worldwide and a sophisticated least cost routing system to exploit these optimally. GLOBALCO may not believe that SMALLCO can obtain rates as competitive as GLOBALCO already has in place for its fixed infrastructure. Nor will GLOBALCO like being entirely reliant on SMALLCO for the ongoing provision of all its staffs mobile calls worldwide.

An alternative approach has been adopted by at least one company -referred to hereafter as "MultiMVNO". Such a company operates as a Mobile Virtual Network Operator ("MVNO") in many countries. This means it does not need to have its own network in any country -just an agreement with a local MNO in each -though achieving that is non-trivial. A single business SIM can therefore be used in all of these countries without incurring roaming charges and with calls still visible to and under the control of MultiMVNO.

However, GLOBALCO will already have contracts for mobile service with its preferred MNO in each territory it operates in. It will also be unwilling to risk all of its staff's mobile service being dependent on the ongoing operation of MultiMVNO -a company that is typically much smaller, and less stable than any one MNO it already deals with.

A further approach is more popular in the United States -where (unlike in Europe) it is impossible to tell whether a given phone number is a fixed or mobile number. There, employees typically have a single number on their business card. This is typically terminated in a data centre but is often then forwarded to or otherwise linked to their cellular phone -which is actually itself a completely different number. However, this ensures that they can be reached with that one number whether they are at their desk or on the road.

This approach is offered by at least one of the major business telephony system providers and does exploit the least cost routing, resilience and recording systems already present for fixed telephony lines within GLOBALCO. However, it does not work well for GLOBALCO's employees in countries such as the UK and much of Europe where business cards show fixed and mobile numbers -and people choose which to dial.

None of the existing solutions satisfactorily exploits the considerable investment and infrastructure GLOBALCO will already have in place for its fixed line telephony and data traffic. As more and more interaction is done over the data network, GLOBALCO is likely to have spare capacity in their telephony network -which is typically highly reliable and fault tolerant and has to be maintained for fixed office phone and call centres.

Many of the solutions above introduce an additional, global overlay of MNO agreements and infrastructure controlled and managed by SMALLCO. This would rapidly fall apart in the event of SMALLCO failing and would take a huge effort and considerable time to replace. They also require SMALLCO to pass through the (considerable) call charges. These are likely to be less favourable than GLOBALCO's existing tariff agreements, are out of its control and usually subject to a mark-up.

None of the present solutions outshines the others -as evidenced by the lack of a dominant approach and/or vendors in this market. There is therefore scope for an alternative and novel system architecture that overcomes all of the objections described above.

All of the current solutions are more complex than they need be. A simpler approach that is cheaper, more reliable and does not require massive investment should be possible. This is particularly important when one realises that the phone network is a decreasing part of our real-time communications. It is now an anachronistic hangover that needs to be accommodated but gracefully phased out rather than driving yet another fragile, mission-critical global headache.

Statement of Invention

The present invention consists of a novel telecommunications system architecture and method for the integration of mobile phone calls into the existing infrastructure that supports the fixed line telephone and/or data networks of a multi-national business.

This consists of a plurality of access points, ideally at least one per country, through which are routed at least a subset of business mobile calls made by or to employees currently present in that country. These "Mobile Access Points" ("MAP"s) route said calls via said existing infrastructure and/or the internet so as to leverage the existing infrastructure, fault tolerance, least cost routing, archiving and transmission capacity available therein.

Introduction to the Drawings

Figure 1 shows the top level telecommunications architecture that a typical multi-national company ("GLOBALCO") will have servicing their operations in a given country. Note that many of the elements may be hosted or "in the cloud", or running as virtual machines on a shared physical host. The physical arrangement and location of the components is largely irrelevant to this invention. What is important is that, with the exception of the MAPs (24), this is existing infrastructure that the company already uses and manages for fixed line, VolP and existing business mobile numbers.

Figure 2 shows a multi-national system in three countries. Note that large countries such as the U.S. may be divided into smaller "regions" -each acting as a separate country -if required to localise traffic. For example, this may help to avoid time-zone issues, congestion, slow long distance setup or satellite hops and associated delays.

The detail of Figure 1 has been condensed into simplified functional blocks that the MAPs (24) interact with -regardless of the detail within them or the vendor/MNO/Telco providing them. In many cases, the voice network is arranged hierarchically, with a hub and spoke topology and will include disaster recovery (DR) capability. However the architecture is organised, there is existing capability for at least a subset of employees in a plurality of countries to each have a personally assigned public telephone number and/or a personally assigned mobile phone number. These can be used to place and receive calls from anywhere in the world using the numbers advertised on the employee's business cards; corporate directories; email signatures, blogs, websites and so forth.

Figure 3 shows the key internal objects within a MAP. These interact with the existing telecommunications elements shown in Figures land 2.

Figure 4 shows a flow chart of how an outbound business call from a mobile phone is handled in the case of an employee using a single business number for all business calls.

Figure 5 shows a flow chart of how an inbound business call to a mobile phone is routed.

Figure 6 shows a flow chart of the "PathSelector" process running on the mobile phone. This determines how a voice call should be established.

Figure 7 shows a flow chart of a "PathEvaluator" process running on the mobile phone. This analyses the characteristics of a potentially available speech path.

Figure 8 shows a flow chart of the "PathFindern process running on the mobile phone. This attempts to find alternative speech paths that may be available nearby.

Figure 9 shows a flow chart of the "PathManager" process running on the mobile phone. This establishes and manages the most appropriate call paths from those currently available.

Detail of the Invention Consider a large, established company "GLOBALCO" with presence in many, perhaps most countries around the world. It will have built up a complex network of telephony equipment servicing its offices around the world. More recently, it will probably have tried to rationalise this, reducing the number of independent switches and moving traditional Time Division Multiplexed (TDM) telephony circuits to Voice over IP (VolP), typically using Session Initiation Protocol (SIP) for vendor independence. Traditional telephone calls are slowly being usurped by other real-time interaction services.

However, there is usually still some significant "traditional" telephony infrastructure in place. This may be from a single, strategic vendor or, more likely, a mixture of multiple vendors' equipment as a result of company acquisitions, changes in strategy and/or vendors falling out of favour or going out of business.

Figure 1 shows the relevant major components of an exemplary telecommunications infrastructure that GLOBALCO will typically have already have in a particular country -plus the additional one or more Mobile Access Points "MAPs" (24) provided as part of this invention.

Mobile phones (1) owned or leased by employees will be using at least one and often all of the mobile networks (2, 3) available in the country. Historically, and often still today, the company would have provided mobile phones (4) with numbers that it owns and are connected via a preferred MNO (5) with whom GLOBALCO has negotiated an overall contract.

A Private Branch Exchange (PBX) typically manages telephony within the business. This typically contains a controller (6); zero or more TDM gateways (7) that connect to the PSTN (11) and/or private TOM circuits; zero or more IP gateways such as Session Border Controller (SBC) (8) that connect to SIP trunks or other IP routes (12) over which Voice over IP (VolP) calls may be made. Typically, a Computer Telephony Integration (CTI) server or service (9) is available to allow other devices to observe what calls are occurring within the PBX and/or to control them.

Connections to each of the above external data and/or voice "pipes" may be via a wide variety of interface standards -each of which is terminated on the appropriate equipment. These may include but are not limited to: satellite, micro-wave, radio, fibre-optic, co-axial and copper cables.

When employees need to speak to someone outside the business (13), using that counterparty's public phone number, the call must normally route via the PSTN of the country in which that number is located. This call could be routed via a MNO if that phone number is a mobile or it could be routed via the internet (14) if they are on a VolP capable device.

The corporate network (10) is typically connected to the internet (14) via router(s) and firewall(s) (15)-allowing direct (and often cheaper and faster) connectivity to any customer that can be reached via VolP rather than having to use their PSTN number.

A company operating in a country typically has a physical presence in one or more buildings (16) and these are normally provided with a wired and/or wireless Local Area Network (LAN) (17) over which data and (commonly now) voice traffic flows to any IP telephone sets (19), mobile devices such as laptops or tablets (20) and desktop computers (21). Note that any of these latter two (20, 21) may be running a "softphone" application providing similar telephony services as would be provided by having a physical phone (19). Also note that the mobile devices (20) can usually operate across multiple buildings and "on the road" via internet and/or MNO connections.

The corporate network (10) within the country will normally be connected to the global, corporate Wide Area Network (22) via router(s) and (often) firewall (23). This allows data -and often voice -traffic to flow between national corporate network(s) (10). Sometimes voice is carried over a parallel network to the data.

Note that this is only an example. There are many variations on the exact mechanisms by which the elements are connected. For example, Router and firewall (23) could be a VPN connection over the internet.

This invention adds into this existing infrastructure one or more "Media Access Points" (MAPs) (24). This is a software process that may run on a physical server or virtual "slice" on a server or on a "cloud server" so long as it has an IP path to and from the corporate network (10).

Also note that many of the components may be logically and/or physically remote from the country. For example, several countries (or the whole world) may share a single PBX controller though TDM Gateways (7) tend to be distributed in-country.

These details do not impact the architecture of this invention -merely the configuration of the MAP (24). For example, it may have to connect to a CTI feed (9) at corporate headquarters to observe the calls happening in the country it serves.

Figure 2 shows a higher level, logical view of the relevant parts of the global corporate communications infrastructure. Two countries are shown but there are often many. In each country there may be employees with their own smartphones (1) connected over a variety of MNOs. The company's PBX system -including control (6), gateways (7), SBCs (8) and CTI (9) of Figure 1-connects the business to the PSTN (11) and often at least one MNO directly. Typically each country will have some form of local processing (203) allowing calls to be made even if isolated from the rest of the world.

Phones (or softphones) (201) within the corporate infrastructure in a given country (202) running on analogue, digital and/or IP phone sets (19), mobile (20) or workstations (21) within the business typically have an internal number that is their unique address within the corporate network. Some also have a publicly available number that can be dialled from the public network using Direct Dial In (DDI) (also known as Direct Inward Dial or DiD). This is often, but not necessarily, the internal number prefixed with a fixed set of digits representing a contiguous block of national PSTN numbers owned/rented by the company.

Note that by using the existing PBX capability provided (though not necessarily physically present) in country (203) the MAP (24) serving (though not necessarily located in) that country can make and take phone calls anywhere in the world via that country's PBX (203). This typically includes sophisticated security and cost optimisation algorithms to prevent fraud and to minimise call costs respectively. The MAP (24) also has access to the corporate network (10) and hence the corporate WAN (22) and internet (14) -allowing it to make and place VolP calls worldwide direct to end users who have VolP capability or via other MAPs (24) to "break out" via the PBX (203) in another country in the case of an international phone number being dialled. This is a common technique used to avoid international call charges. In many cases, the PBX controller (6) will already be configured to do this, avoiding the need for the MAP (24) to be concerned how the call should be routed.

In (or accessible to) each country is one or more MAP processes (24). Each handles a certain load and typically at least one more MAP (24) is provided than is required to handle the overall load in that country. This provides fault tolerance in each territory.

The MAPs (24) are typically administered by an IT manager in each territory but this is largely done via a user interface onto a central controller "MAPCON" (205) located in the corporate data centre (204). Configuration data is stored in a fault tolerant database (206) and the appropriate subset passed to each MAP (24) when it is changed and cached there -so the MAP can operate on the most recent configuration it knows even if isolated from the MAPCON (205) and/or database (206).

Typically, a disaster recovery site (209) mirrors the configuration of the data centre (204) allowing it (209) to take over in the event of major failures of the latter (204).

Note that there is no real-time central control of the MAPs (24) and hence no single point of failure or bottleneck. Each can operate independently.

Typically the corporation will also have an existing communications recording/archiving infrastructure in place. This may be a consolidated system or separate silos but can include elements for recording of voice (208), text messages (210) and call details (207). This latter data (207) is used for billing and cost allocation but is also the metadata that makes the former stores (208, 210) easily searchable. As with the other elements, these may be in country, centralised, hub and spoke or "in the cloud". The important point is that any logical recording service(s) already present are accessible directly to the MAP (24) and/or via the PBX (203). For example, if the MAP (24) places a call via PBX (203), that call may well be recorded automatically without the MAP (24) having to do anything itself.

Figure 3 shows the key logical components within each MAP (24). Standard elements common to any server application -such as logging, audit trail, login security, alarming -are present but not relevant to the detail of this invention hence are omitted for clarity.

Note that "process" below may be replaced by "thread" in many cases -the entire MAP service typically runs as a single multi-threaded process but could be distributed if required.

A persistent store holds a local copy of the configuration (301) of this MAP (24). Config tracker (310) is advised by or polls the MAPCON (205) or central database (206) directly for changes. This (301) is a cached snapshot of the subset of the overall configuration (206) that relates to the employees, mobile phones and business numbers in the country this MAP (24) serves. In addition to the definitions of these, it also includes addresses and credentials of the CTI feed(s) (9) that it needs to observe and utilise the PBX (203) facilities in country. It also contains details of the other MAPs (24) that this one shares the load in that country with.

Note that each MAP (24) may interact with more than one PBX (203) -which may be in other countries -but for simplicity, a single one is shown here.

Each MAP instantiates one or more pools of softphones (302, 303, 304), each member of which appears to the PBX (203) as an internal phone -that can make and/or take phone calls and access its advanced features in the same way that a physical phone set (19) would. This normally includes the ability to place on call on hold while making a second (or third) then conferencing or transferring them.

This is typically done via a first party call control or softphone interface (304) such as Telephony Application Programming Interface (TAPI), H.323, SIP,SIPS or a proprietary protocol. The interface and audio paths subsequently established with each endpoint (not shown) are preferably encrypted -typically using SRTP. This is under the control of the PBX (203).

Three separate pools of internal endpoints are shown: * Business Number Endpoints (302): Each of these has its own internal number which may be assigned an external DDI number hence can be reached directly from the public network thanks to the DDI routing within the PBX.

* Shadow Endpoints (303): Only available on some PBXs, these softphones operate in "shared control" or "dependent" mode. Each has a corresponding physical or softphone with the same internal number as itself. That "controlling" softphone is used by someone in the business as their "business phone". These endpoints (303) allow the MAP (24) to track that user's actions on their phone (19) and/or softphone (20. 21).

* Worker Endpoints (304): Each have an internal address but these numbers are not made public outside the MAP system. They are used to place calls which are, typically, then transferred to other numbers when ready.

Optionally, a further pool of telephony endpoints (306) may be instantiated. These do not appear as internal numbers within the PBX (203). Instead, they are standard SIPS endpoints capable of placing and taking VolP calls directly. They therefore act as a fall-back calling route should the PBX (203) be overloaded, too slow, too expensive or dead.

In many cases it is also necessary to learn more about phone calls than can be observed from the events provided to the internal endpoints. Most PBXs (203) support one or more 3rd Party CTI feeds (307)-such as Telephony Services Application Programming Interface (TSAPI) or similar. Via this feed, the Call Tracker (308) process or thread observes at least a subset of the calls passing through the PBX (203). It builds an in-memory model of the state of calls currently in progress (309).

In many cases, this same CTI feed (307) allows control of calls occurring on endpoints -whether those are locally instantiated (302, 303, 304) or not.

Where systems already exist to store voice, messages and/or call details (207, 208, 210), a process or thread manages the interactions with each of these (311, 312, 313 respectively).

One or more App Interface (314) processes/threads interacts with a plurality of "Corporate Dialler" applications running on the employees' mobile phones. This typically presents a RESTful interface over HTTPS and is accessible from the internet. Commands from and messages to the employees using their mobile phones (1) for business calls pass through this process (314). However, to alert the employee to an incoming call, this process (314) also interfaces to the push notifications services of the operating systems supported on the smart phones.

At the heart of, and interacting with all of these components is the Call Controller (315) process/thread. Each of the other processes tells this controller (315) about relevant events and actions. It (315) then instructs the relevant component(s) to act. It (315) is also in direct contact with the Call Controllers (315) in other MAPs (24) within the same country/region and around the world. Heart-beating and sanity checks between Call Controllers (315) allows each to track the health and current loading of the others to facilitate load balancing and fault tolerant failover procedures letting a pool of MAPs (24) act as an N+n fault tolerant, load balancing pool.

However, there is a danger that although a given pair of MAPs (24) may be able to communicate and neither sees a problem, it is possible that the telephony system they are connected to is not functioning as a single system. Such "split brain" modes can be detected by observing the state changes of one or more unique endpoints (302, 304) allocated to each of the other MAP(s) (24).

If MAP (24) "A" sees telephony activity -even just an "off hook" event -via CTI feed (307) on an endpoint that it knows has been dedicated to MAP "B" it can deduce that MAP B is able to control it and that they are part of the same telephony system. Each MAP (24) therefore performs at least a basic telephony operation on a dedicated port (302 or 304) at least once every N seconds. Failure to see such an event within 3 x N seconds is a clear indication to other MAPs (24) that there is a problem with that MAP (24) and/or the PBX (203) serving it.

Turning to the use cases next. There are four major variants on how employers want to use employees' own mobile phones: two regional differences and whether or not the mobile phone being used supports only a single SIM or multiple (dual and/or eSIM).

Within the set of employees there will be those for whom no call recording or routing is needed -but least cost routing may be required; those for whom call recording is optional or sometimes desirable and other for whom recording is mandatory and calls must not be completed without recording.

In the United States, mobile phone numbers are indistinguishable from landlines. The "area code" making up the first 3 digits of a 10 digit national number normally relate to a specific geographic region but number portability -including between landline and mobile networks -has broken this strict mapping. It is common for employees in the U.S.A. to have a single business phone number. This needs to reach them when they are in the office or on the road. Those contacting them are unaware of whether the employee will answer on an office phone or a cellular phone -the external party always rings the same number (as do colleagues around the world).

Case 1: Single Business Number, Single-SIM Smartphone The employee has a personal service contract with one MNO -associating their "personal" number (EMP1) with their own phone (1). Calls ordinarily made from this phone (1) normally display their personal number (EMP1) to the called party and to call the phone someone must know this personal number (EMP1). Calls to and from the phone are not recorded -at least not by GLOBALCO.

It is important that the phone user (employee) uses his personal number (EMP1) for personal calls -without the business seeing details or content of those calls -but appears to be using his allotted business number (BUSPUB1) and is able to take calls via this business number when working.

To achieve these goals, a "corporate dialler" application is installed on the employee's phone (1)-typically under the control of a Mobile Device Management (MDM) suite that separates business and personal data and applications within the phone (1)-allowing remote control, auditing and wiping of business data if needed.

The employee either selects from personal or business lines -or the appropriate line is selected for them according to who they are dialling or messaging.

Consider outbound calling first. Employee John Doe, normally resident in country "CO", is currently in country "Cl" (may or may not be the same as CO). He wants to make a business call to a customer at a specific phone number -which we will refer to as "EXT1".

The flowchart of Figure 4 shows the process.

The user opens the corporate dialler app (401) and selects the business contact with (or enters) phone number EXT1 (402). Instead of dialling EXT1, the dialler, calls (403) one of a set of pre-configured phone numbers known to route to the MAPs (24) in country Cl -we will call this "BUSPPRIV1".

BUSPRIV1 is configured in the public network to route (404) to a corporate PBX (203) in country Cl. Therefore an inbound, national call arrives at the appropriate PBX (203)-either directly from the mobile network or via an interlink to the PSTN.

Typically a range of numbers around BUSPRIV1 are configured and the DDI/DID/DNIS number presented to the PBX in the DNIS field is used by the PBX (203) to route the call to a specific internal endpoint -"BNE1C1". This will be one of the Business Number Endpoints (302) on a MAP (24) in country Cl.

This endpoint alerts (407) as the incoming call is presented-raising an event within the Business Number Endpoint thread (302) and prompting it to go "off-hook", answering the call (409) and completing a bi-directional audio path between itself and the employee's smartphone (1) via the PBX (203).

This action typically also triggers at least one event (408) that is reported by CTI feed (307), acted on by the Call Tracker (308) and hence the Real-time Call Model (309) updated with at least the Calling Line Identifier (CLI) -also known as Automatic Number Identification (ANI) -and the DDI number dialled. Note this latter number may not map to a single specific endpoint if hunt groups are used to pool multiple such endpoints. A further event (not shown) typically reports the call has been established between EMP1 and BNE1C1.

Thus the Call Controller (315) becomes aware of the call, which (personal) mobile (1) number (EMP1) the call is coming from and that the corporate dialler application dialled BUSPUB1.

In parallel with this call setup via the MNO/PSTN, the corporate dialler application initiates a data interaction (405) via, for example, a RESTful interface to App Interface 314. This can occur over Wi-fi or the MNO (if it supports data).

One challenge with all systems such as this it that call setup is, on average, slower than calling the end customer directly -as the call goes via the corporate server (24) in between. To mitigate this, the data request may be sent over both MNO and Wi-fi IP paths if available. Whichever reaches the App Interface (314) first can trigger other actions -even if the cellular call has not yet reached the PBX (203). The small amount of data wasted is normally immaterial.

Further milliseconds can be shaved off call connect time by acting on the first, incoming call event (408) rather than waiting for the audio path to be established (409).

As soon as it becomes aware of the number required (EXT1), the Call Controller (315) allocates (406) a Worker Endpoint (WE1C1) and instructs that endpoint or (often quicker), tells the PBX via 3rd Party CTI feed (307) to dial (410) public number EXT1. This typically requires that it prefixes EXT1 with an access code indicating that the following digits are a public rather than internal number.

If this MAP (24) is not in the same country (Cl) as the originating mobile phone (1) (e.g. is supporting several small countries from one regional hub or acting as fall-back or overflow for another MAP), the country code for Cl would be added if the EXT1 is a national rather than international number. Alternatively, an endpoint in the destination country may be used if that results in quicker connection that relying on the PBX's (203) call setup.

As soon as the Worker Endpoint WE1C1 has been instructed to call EXT1, that outbound call can be conferenced (411) into the call that has just been answered by the Business Number Endpoint BNE1C1. Again, this can be achieved by first party commands issued via WE1C1 but is often more quickly achieved with 3rd party control via the CTI feed (307).

The outbound leg of the call proceeds and, hopefully, rings EXT1 (412) who then answers (413) and the call is connected.

During this period, the Business Number Endpoint can be sending tones and/or announcements to the employee advising them of the progress of the call; whether or not this will be recorded and so forth.

Also in parallel with call setup, Call Controller (315) determines if the call is to be recorded (414) (as determined by the configuration database (301)). If so, the Call Recording Interface provides end point details (415) so that by the time the call is answered, a copy of the data streams to and from the business endpoint BNE1C1 may be forked (416) and directed to either file storage or to ports on the recording system (208).

The call thus established continues until either party hangs up (417), at which point the call is torn down (418) and the recording terminated. Ports are freed for subsequent calls.

Alternative approaches to connecting the original MNO call, the external party and (optionally) the recorder port(s) are possible -depending on the capabilities of the PBX and the need for separate streams of audio for each party. For example: * Multiple line appearances on the Business Number Endpoint (302) can be used to set up the outbound call rather than a separate worker endpoint (304).

* "Single-step" or "fast" Conferencing and/or transfer features of the CTI link (307) may allow the additional external party to be added without a second call being created.

* Conference bridging can occur within the MAP (24) itself rather than using a bridge within the PBX. This approach, keeping what the PBX sees as two independent calls active (one on the Business Number Endpoint and one on a Worker Endpoint) gives greater control over what each party hears -for example, prior to the far end ringing. For example, should the far end not answer for 15s, the MAP could play an announcement to the employee offering them some options ("Do you wish to continue waiting; record a message to be played when they answer or let me try again later and call you back?"). Should the external party answer during that period, the MAP could play to them "One second please, John Doe is just coming" whilst interrupting the announcement to John Doe with "They just answered. I'll connect you." Voice control is also easier in this approach. For example, if John Doe says "let them know I tried" while EXT1 is still alerting, MAP could respond to John Doe (only) "OK, I'll let them know" -and hang up on John Doe. Should EXT1 then answer, MAP may say "John Doe was trying to reach you". Such interactions are already well handled by various Interactive Voice Response ("IVR") systems that could be conferenced into the call to perform these functions.

In this scenario, the call routing is handled by the PBX (203). It also typically provides the ability to present the calling party as a specific business number -so EXT1 see the call as coming from John Doe's business number rather than his personal number-which is never disclosed outside John Doe's employer (where it is needed to match incoming call to employee).

Where this ANI cannot be programmatically set, the call has to actually come from John Doe's assigned business phone in order to show his number to the far end. If John Doe never actually uses a phone or softphone on the PBX (always works via his mobile) then a Worker Endpoint (304) can be registered with John Does' internal business number and all calls transferred to or conferenced into it.

Some PBXs offer a "dependent mode" softphone registration. This allows a "Shadow Endpoint" (303) to be registered for such a purpose without stopping John Doe from using the physical phone (19) and/or softphone(s) (20,21) with that number should he need to do SO.

During the call, the user interface shown on John Doe's phone (1) is that of the corporate dialler. This will show the EXT1 number as the far end rather than BUSPUB1 (which means nothing to and does not need to be known by John Doe). Further interaction with the MAP (24) via App Interface (314) can provide call status, duration, recording status and so forth which can be presented to John Doe via the Corporate Dialler app on his phone (1).

Optionally, a speech recognition engine may be connected to the data streams, providing transcription of calls in near real-time. This and all call details can be sent to the archiving mechanism via Call Detail Archive Interface (313).

Optionally, the Call Controller (315) may monitor the success/failure, responsiveness and call setup times of the PBX (203) and PSTN. Call Tracker (308) can also gauge how busy the system is from the rate of events being received for CTI (307). These metrics may be used to change the call routing to use External Endpoints (306) instead of or even in parallel with the internal endpoints (302, 304).

When roaming overseas, the dialler app uses the phone's (1) current location and/or MNO identity to determine which country it is in. The number it dials is selected to be that of the MAP(s) (24) in that country. Hence call charges on the MNO are minimized.

Consider now an incoming call from external PSTN number EXT2 (in country C2) to John Doe's (sole) business number (BUSPUB1) which is a public number in country CO (regardless of where John Doe currently is).

Figure 5 shows the process -beginning with the external party dialling John Doe's business number (501). The PSTN routes his call to country CO (if not already there) and thence (502) to the PBX (203) with which it is currently associated -regardless of where in the world John Doe currently is.

As above, this business number, BUSPUB1 is associated internally with either a dedicated Worker Endpoint (302) (if not used by a real phone or softphone) or a Shadow Endpoint (303) otherwise, in a MAP in country CO. For this example, we will use a Shadow Endpoint, "SEP1C0". The PBX (204) thus routes the call to SEP1C0 (503), alerts SEP1C0 (504) and raises a CTI event to this effect (505). SEP1C0 goes off-hook to answer the call (506).

Alternatively, or additionally, the MAP (24) may express an interest in the employee's phone number (the internal number for which BUSPUB1 is the public, external number) and hence receive events via CTI feed (307).

Via at least one of these means, the Call Controller (315) in a MAP (24) becomes aware (505) of an incoming call to John Doe's (internal) business number. It allocates (506) an available Worker Endpoint (304) WE1C0 or, as above, in the case of overload, fall-back etc. an External Endpoint(306) to call (507) John Doe's personal mobile number (EMP1) (SEP1C0).

Using the same mechanism(s) described previously, where possible the ANI is set to that of the calling party so that the incoming call shows the original calling party.

As with outbound calls, the Call Controller (315) causes the inbound and outbound legs to merge into a single call (508)-via PBX (203) conference bridge or internal bridging as for outbound calls.

As with outbound calls, additional rules within the Call Controller (315) can, for example, announce to the calling party that "John Doe is not available, would you like to leave a message; have him call you back or shall I try his other number for you?" As with outbound, in parallel with call setup, the Call Controller (315) determines whether or not recording is needed (510) and, if so, determines appropriate end-point(s) (511) such that when EMP1 answers (512) the call is forked (513) to said end-point(s).

When either party hangs up (514) the call is torn down and recording terminated (515).

As with outbound, the MAP (24) has no need for international least cost routing algorithms -as it uses the PBX (203) to make the outbound call to John Doe's mobile (1). If John is known to be in a different country (as reported to a MAP (24) in that country by his Corporate Dialler app), the call can be routed via that MAP and break out there rather than incur MNO international forwarding charges.

However, even a national call outbound from landline to mobile can be expensive in itself. Where this is the case, a push notification from App Interface (314) to John Doe's Smartphone can be sent (516) before or at the same time as the outbound PSTN call (507) to his smartphone is attempted. If the corporate dialler app on the phone is alerted and responds before the outbound PSTN call reaches the phone, it can initiate a call (517) to the PBX (203) using a number (BUSPRIVO) passed in the push notification (516).

The PBX (203) and hence allocated Worker Endpoint (WE1C0) will thus receive "busy" for the outbound call but an inbound call appears almost (518, 519) immediately. The business endpoint mapped to BUSPRIVO in the PBX answers the call (520) and this inbound call, rather than the (failed) outbound one (via WE1C0) is conferenced into the original call. Thus the call comes out of John Doe's contracted minutes (often unlimited) rather than a charged landline to mobile (1) call from the PBX (203).

The above parallel calling approach results in increased traffic on the PBX (203) so, where speed is not as important as loading, the outbound PABX call (506) may be delayed by a predetermined time and cancelled before it happens if the expected inbound call appears (519) during that period.

When roaming overseas, the dialler app regularly reports its current country to the App Interface of a MAP in that country -which alerts the other MAPs so that it can decide whether any inbound calls to John Doe should be routed via the corporate PBX to the country they are in and handled by the MAP there if this is cheaper than using the MAP where the inbound call originated.

Case 2: Single Business Number, Dual or eSIM Smartphone This case has the same business requirements as case 1 above but the employee's smartphone (1) is able to operate with at least two MNO numbers at the same time. This gives the opportunity to further separate business and personal calls. In case 1, business calls were, necessarily, being made over the employee's personal mobile service contract (EMP1) and thus eating into his available minutes. Typically, a business would pay for an unlimited minutes contract -or at least refund the difference between that and the contract they would need without the business calls.

In Case 2, however, many businesses simply provide the 2 contract/SIM on the phone and that's sufficient. The requirement here, though, includes recording of at least some business calls and/or use of GLOBALCO's least cost routing to minimise call charges. For the employees to whom that applies, this system overcomes the limitations of other systems as discussed under "Background" above.

Consider employee Jane Doe who has a phone (1) with eSIM capability but must have many of her business calls recorded. As before, the detail of the user interface on the phone that encourages/enforces use of the business or personal SIM is outside the scope of this patent but the requirement is to ensure that all calls to or from Jane Doe's business number go via the MAP and hence can be logged and recorded if needed.

As with Case 1, there will be a Corporate Dialler application installed and running on the phone (1).

The eSIM (preferably, 2" physical SIM otherwise) will NOT be for the business phone number that Jane Doe uses for all business calls (BUSPUB2). It will, instead be from a block of unpublished numbers -though still owned by the business -say BUSPRIV1.

Preferably the Corporate Dialer on the smartphone prevents her from dialling any number manually and will, itself only dial one of GLOBALCOs own numbers in the country she is presently in -all of which route to a MAP (24) in that country.

Thus Jane Doe cannot phone anyone directly and have her published business number presented as the calling party. Nor can anyone reach her mobile by calling the number she publishes as here work number.

Outbound calls work identically to case 1 but are all made over the business SIM -avoiding any impact on Jane Doe's personal contract. They therefore present the unpublished number BUSPRIV1 to the PBX (203) instead of Jane Doe's personal number -removing the need for the business to even know her personal number for calls outbound from the mobile phone (1).

Inbound calls similarly, are very like Case 1 but, again, are all made over the business SIM -avoiding any impact on Jane Doe's personal contract (inbound calls do attract charges on some mobile networks). Hence the number dialled to ring Jane Doe's phone when routing an inbound call through to her is BUSPRIV1 -removing the need to know her private number at all.

Case 3: Separate "Office" and "Mobile" Business Numbers, single SIM Smartphone This case is the norm in the UK and much of Europe. Phone numbers are inherently either mobile (in the UK starting "07") or not. Both are published on business cards and email signatures and people consciously choose which to ring.

John Smith has a smartphone on his personal contract that uses his personal number (EMP3). His business card shows his "Office" number (BUSPUB3) and his "Mobile" number (BUSMOB3).

He has a phone on his desk -reachable via the PSTN by dialling BUSPUB3 or internally using (normally) a trailing subset of the digits of BUSPUB3 (BUSINT3).

He may also have a softphone app on his laptop that lets him appear to be using this same office phone (BUSPUB3 externally, BUSINT3 internally) wherever he's connected to Wi-fi.

Consider outbound calls first.

Those made from the "real" office phone -or a softphone of that number -obviously appear to come from that number and can be recorded by the existing infrastructure designed to record the PBX.

Calls made from his personal mobile (1) direct to a customer (EXT3), however, won't show his business mobile number (BUSMOB3) -and can't be intercepted even if recording is mandatory. Nor will calls to BUSMOB3 ring his mobile phone (1) as that is EMP3.

So the business deploys a Corporate Dialler app to John Smiths' smartphone -just as in Cases 1 and 2. As previously, John Smith is encouraged/cajoled/forced/instructed to make all his business calls via the Corporate Dialler app.

As with John Doe in Case 1, this Corporate Dialler app does not call the person John Smith wishes to speak to on EXT3 directly but, rather, calls the in country MAP (24) via a non-published but public network number BUSPRIV3.

This scenario is the same as outbound for Case 1 with the exception of the ANI presented to the far end. John Smith would expect this to be his business mobile number BUSMOB3 rather than his office number BUSPUB3.

If the PBX (203) allows this to be set programmatically to the required mobile number (BUSMOB3) that can be done. Otherwise, that has to be achieved by the business having a block of mobile numbers (including John Smith's business mobile number BUSMOB3) and a contract with an MNO that allows them to make calls over that number. As there is not actually a phone with a SIM in assigned to that number, it needs to be diverted to a (normally) SIP endpoint (306) in the MAP (24) -which can then be used to place national calls using that number (BUSMOB3).

However, if (as will be shown below) incoming calls to either John Smith's office number (BUSPUB3) or his business mobile number (BUSMOB3) both reach him when he's on his personal mobile (EMP3), does it matter whether the ANI shown on outbound calls is that of his mobile number (BUSMOB3)? Could it not be that of his office number (BUSPUB3) -which the PBX definitely can present! This can avoid the need to make any outbound calls over this mobile number (BUSMOB3) -opening up the option of using a "Pay as You Go" SIM for it with zero monthly charges instead of a monthly contract.

Now consider inbound calls -first to John Smith's "office" number (BUSPUB3). These calls ring, as they have always done, on his desk phone (19) in his office and any softphone (20, 21) he has running on a laptop -or even his Wi-ti connected smartphone (1).

With a MAP (24), as was in Case 1 with John Doe, a Shadow Endpoint (303) and/or CTI (307) observer can monitor the internal office phone number BUSINT3 for incoming calls and choose (optionally -potentially on schedule or personal preferences) whether or not his (personal) mobile phone (EMP3) should also ring.

The outbound leg to his smartphone (1) is established exactly as in Case 1.

Now consider inbound calls to John Smith's "mobile" business number (BUSMOB3). Assume that this is a real mobile number and is therefore associated with a service contract from an MNO. As this number is not present on John's (or anyone else's) phone, he cannot undo a simple "divert" placed on it -which can be to a MAP's External Endpoint (302) in the country John's (personal) phone (1) EMP3 is currently in. Alternatively, it can be diverted to an unpublicised public network number BUSPRIV3 that routes via PBX (203) to an Endpoint (302) with number BUSINT3A on the MAP (24) in that country. In either case the call initially alerts and can be answered by an Endpoint (302, 306) in a MAP (24) in the country John Smith is currently using his phone in.

Inbound calls to John Smith's mobile business number BUSMOB3 are therefore visible to the MAP (24) in the country he is currently in. As with Case 1, the MAP can place an outbound call (and/or try to beat it with a notification to the corporate dialler app to make an inbound call to it).

As with Case 1, business calls to and from John Smith's mobile phone (1) necessarily go via his personal mobile contract (EMP3). The incremental cost of this needs to be borne by the business.

Case 4: Separate "Office" and "Mobile" Business Numbers, Dual/eSIM Smartphone Jane Smith has a smartphone (1) with a personal number (EMP4) and contract on it. The business pays for a separate contract and places a second number on the eSIM (or physical SIM). As with Case 2, if no record of Jane's business calls or their content are needed, Jane uses the phone number of this contract as her "Mobile" business number (BUSMOB4) and calls route directly to and from her phone.

If details of her business calls (over and above what is obtained from the MNO's billing records) is required, then the Corporate Dialler app can be deployed to log call details but there is no need to change the routing of calls.

Similarly, the corporate dialler app may be used selectively to reduce call charges. For example, it may allow national calls (within the MNO contract) but divert international calls via the MAP (24) and hence use the corporate least cost routing plan to break out in the destination country or wherever is most cost effective.

If, however, Jane's calls can only be allowed to complete if they are being recorded, then the same approach as in Case 2 can be used. The eSIM contract on Jane's (personal) phone does NOT correspond to her mobile business number BUSMOB4 -but, rather, is a private business number BUSPRIV4.

Her public mobile business number BUSMOB4 is on a separate contract, diverted to and thus terminating on a MAP in the country she is currently in (C4) as in Case 3.

Operation is as for Case 3 but, as with Case 2, Jane Smith's private mobile number (EMP4) need not be visible at all to the business and neither inbound nor outbound business calls impact her personal mobile contract.

Intermediate cases include those where recording of some calls or some parts of calls is required but there is no need to force all calls via the corporate infrastructure. In this case only calls that need recording or least cost routing will be routed via the MAP (24).

Note that, in all four cases, once the initial call has been established, advanced features such as hold, transfer, conference and so forth may be offered by the dialler app.

The above discussion has assumed that all voice calls are carried over the PSTN or MNO networks at the employee's mobile (1) end. That is no longer optimal in many cases. As Wi-fi and, (at least some) 4G networks support Voice over IP connections, so this alternative path for the voice channel becomes attractive. Where these networks are available, of sufficient speed and not overloaded, such calls can be established more quickly; they can use higher quality voice codecs and are typically cheaper (often free) than the PSTN/MNO route. There is therefore a great incentive to use them when available.

However, unlike traditional telephone calls, such packet voice paths are more susceptible to quality problems as their bandwidth is not guaranteed for the duration of the call. Dropped packets, out of order packets, duplicated packets, shorter range and lack of hand-off and variable delivery time all cause issues if present to excess.

Wi-fi connections tend to be unmetered and hence effectively zero cost to the mobile phone user. Data usage over an MNO's (for example) 4G network, is normally restricted and can be expensive -so should not be wasted.

In cases where there is no, or very poor cellular network capability, it makes sense to try connection over Wi-fi as it cannot be worse. This "Wi-fi calling" capability is already present in mobile phone settings -though not supported by all carriers and is optional on others.

Whenever a cellular and Wi-fi connection are both available, there is at least an opportunity to try and speed up connection, improve voice quality and/or reduce costs -but a danger of providing a worse user experience if the call is routed over a poorly performing network.

Figure 6 shows how the invention tracks the available voice and data networks to gain the optimum call experience -based on configuration data that may include but is not limited to settings that indicate the relative importance of factors such as: 1. That the connection is established and remains established.

2. That the audio quality is as high as possible.

3. That the audio quality is as consistent as possible.

4. That the cost of the call is minimized as far as possible.

5. That the speed of connection is maximized (delays minimized).

6. That the call holds up while the phone (1) moves.

A further setting or algorithm indicates whether the call need not be recorded, should be recorded or must be recorded. In the latter case, the call cannot be allowed to proceed unless it is definitely being recorded.

Where a dual or eSIM phone is used, further settings indicate which are personal or business connections and whether a personal call can ever, never, or under specific circumstances (e.g. only the other network is available) be carried across the business line and/or vice versa.

This algorithm is started (601) whenever a call is needed now, may be needed very shortly or if the phone (1) must always be ready to make the best choice of voice path. The sooner the process is started, the better the decisions it can make. Thus, it is ideally started at boot time. Failing that, as soon as the user of the mobile phone accesses the corporate dialler (or any other app exploiting this algorithm) -or, failing that "brings the app to the foreground" in mobile operating systems terms. The intent is that this process is already as informed as possible by the time the specific number or contact has been selected. Obviously a short-code button with a pre-defined counterparty will not give an early warning like opening the Corporate Dialler does. Nor will an incoming call -especially if that is being routed via a MAP (24). Where connection speed is critical, this process may be running continuously as a background task (at the expense of battery and bandwidth on the phone).

However the process (or thread) is started (601), the state of the network interfaces is checked (602), looking for any that may allow a voice path to be established. The process also declares an interest in any network connectivity changes so as to receive a call-back event on change of connectivity where the operating system supports this.

Acceptable networks could include: * MNO voice connectivity -on any of the available SIM/eSIM contracts * MNO Voice over the data channel (VolP) -for example a high-speed data network (such as a 46 connection) * Wi-fi connection(s) * Any other network interface appearing to provide IP connectivity Thus a set of potential voice paths is determined (602). Any parameters visible to the process that could indicate likely quality are harvested. These will include but are not limited to: signal strength; BSSID; error rates; data and/or packet volumes transmitted and/or received.

If not already running, a separate PathFinder process/thread (603)may be spawned to try and identify alternative paths.

Preferably the parameters driving the choice of network paths are based on previous experience of said networks. This may be collected on this phone using the outcomes of the calls set up by the network selection process. Advantageously these include the phone's location, time of day and day of week -allowing it to gradually learn which networks work best, where and when thus improving the accuracy of its decisions over time.

Furthermore, as staff from a given company typically frequent many of the same locations, pooling such data gathered across all or a subset of the company's phones provides a much better basis on which to decide the likely outcome of using a particular network. Preferably such data is anonymized so as not to provide a privacy leak. To reduce the chances of it being linked back to the originator, time data should be blurred (e.g. hour of day, day of week and month but not which day of the month for example).

Advantageously, a shared service may be provided over the data network. This collects path evaluation and actual call outcome data from these mobiles. It makes aggregated, anonymised summaries available to those from other companies and/or the public. Thus a mobile phone can report its current location and its assessment of the networks around it. The central service then responds with information about the likely connection and voice quality of those networks and the locations and identities of alternatives nearby that the user may wish to switch to and/or physically move to should they have problems.

If any of the possible voice paths does not already have an associated PathEvaluator task running, one is started (604).

The set of voice paths is counted (605). If only a single voice path is available, the decision is easy. The sole available path is selected (606) and will be used for the next voice call.

However, phones move, signals change. Should a network connectivity status change occur, or a pre-determined, repeating "recheck timer" expire (607) the process again considers the available paths so as to provide an updated decision. Note that a PathEvaluator may trigger such a network availability call-back should a sudden change occur, forcing a re-evaluation of the paths immediately.

The evaluation results from the PathEvaluators for all potential VolP paths are gathered (608) -including an initial (hence rough and ready) one from those just started (607). These evaluations may include but are not limited to: data rate, signal strength, network type, hops to specific destination (s), round trip delay to specific destination(s), packet loss rates, jitter, historical experience. Each element may be more than a single figure -for example, it may contain a range, error bars, standard deviations, confidence levels, outliers and/or data covering specific time intervals.

From the available information about each possible speech path and the configuration data the optimal set of paths is determined for each of a plurality of call categories -such as "personal", "business", "confidential", "MiFID II regulated". This may be a set or rules or a machine learning algorithm trained on the outcome of previous calls and parameters from PathEvaluators and/or shared historical data from other sources.

The process then sleeps for a predetermined period or until a network availability event occurs (607).

A PathEvaluator process or thread is shown in Figure 7. One of these is started (701) for each potential voice path -whether that is identified by the PathSelector process of Figure 6 or the PathFinder process of Figure 8.

The current characteristics of the network are noted (702). If the path supports a data channel, one or more exploratory "probing" data transmissions are initiated (703). These may include but are not limited to: * Simple ping messages to check connectivity and round trip delay to specific IP addresses (corporate and/or third party). Other protocols that elicit a response from systems that are not deliberately assisting can be used too. For example, ICMP.

* "Path Reporting" packets to one or more "PathFinder" services. These packets optionally report the current network characteristics and, preferably, the phone's location. The presence or absence of, and time taken for responses to appear are noted as indicators of the speed and reliability of the network path used. The response may contain information regarding previous experience with this path from this and/or other locations nearby and/or alternative paths.

* Path probing packets or, preferably, bursts of packets at known intervals. For example, a burst of UDP packets may be sent to one or more pre-configured endpoints. These may be at pre-determined IP addresses or a DNS lookup of hostname (the latter being slower).

These are representative of a burst of RTP carrying voice but the payload provides data regarding the mobile phone (1) and its path evaluation and selection status. A process at the destination end (such as MAP (24)'s App Interface (314)) echoes these back to the sender (1)-but with the payload now containing data regarding how well the stream was received. Typically the MAP (24) is capable of more accurate and consistent measurement of jitter than the PathEvaluator process which is at the mercy of the mobile operating system's task scheduler.

* Path reliability probes. These can include the establishment of persistent connections that require repeated activity to maintain them. For example a TCP/IP socket with each end sending a message or burst of messages once every N milliseconds. Should the socket tear down; a message cannot be sent or none is received for, say, 2 x N milliseconds, that can be used as an indication of inability to maintain the connection. Preferably a SIP/TCP connection is initiated as this can then be also be used to establish a media path.

Each of these exploratory exercises (703) is typically performed on its own thread and results in a call-back when a response is received -or a timeout firing after a predetermined interval deemed unacceptable for a voice path. In parallel with this, however, a timer is used to update the results prior to that. This ensures that a path which responds in a usable time (say 250ms) is marked after (say) 100ms as NOT being a sub-100ms candidate.

As responses are received or time out, the time they took, jitter between them (in the case of bursts) and the data within them (where proactively populated by the far end) are analysed and the performance characteristics recorded (704).

As long as the path remains of interest (705) the process repeats (706) after a specified interval or on a change in network connectivity state or change in call requirements. Note that the intervals for the different exploratory methods may vary -resulting in separate threads with different repeat times for each.

The data gathered by a PathEvaluator is accessible to the PathSelector and other processes at any time. They can also initiate a call-back (706) forcing an immediate re-evaluation and hence fresh exploratory exercises.

The PathFinder process is shown in Figure 8. This process may be started (801) when the mobile phone boots, when the phone enters a geo-fenced location, on a schedule, on opening the corporate dialler application (as the PathSelector starts) or on command from an external application (e.g. via an appropriate "intent" being issued by another process).

Two independent threads are started. One examines the Wi-fi networks that are visible (802) and what can be learned about their security, data rates, SSID and BSSID addresses, signal strength etc. The exact information available varies between operating systems but is that shown in many Wi-fi network locating apps that are readily available to help you find and access Wi-fi networks.

This process keeps an up to date view of the Wi-fi environment around it -and stores the historical data -allowing PathSelector to use said data as part of its decision criteria regarding the likely suitability of any of these networks as a voice path.

By comparing the currently available networks against pre-existing configuration and/or learned data (e.g. from noting which networks this user has used before) it may decide to wake the PathSelector (803) so that it can reassess the available paths and, potentially, suggest to the user that they may wish to switch to a specific network that is more likely to give them the quality of voice call they need.

This process typically repeats its checks on any significant network availability event; a background timer and/or movement of more than a few metres (804).

A second process or thread attempts to exchange information (805) with one or more shared PathFinder services over the network. Preferably this utilises the same data packets sent as probes by the PathEvaluator. These may be corporate or shared services that gather data about voice path attempts and actual experiences and accept this mobile's current view of its paths -adding that to their database -and respond with information regarding prior experience of those paths -ideally from that location at that time of day/day of week and/or predicted performance based on that prior knowledge.

The PathFinder analyses the response(s) (806), applying any corporate rules or policies to thin out the potential candidates (or the initial request may have included a corporate identifier if the business has an agreement with the service provider -in which case the results may be pre-processed accordingly by the service provider and only approved ones returned).

This process too, may choose to alert the PathSelector to alternative networks (807) and/or concerns regarding the networks currently available that may justify a reassessment of which to use. Again, this repeats (808) on a schedule, on moving or on another process requesting that it refresh immediately.

When a voice path is actually required the PathManager process controls which path or paths are established -as shown in Figure 9. Note that, advantageously, a SIP or SIPS connection will, preferably, already have been established as part of a PathEvaluator's role and is also used here.

A PathManager is created (901) when a path is (or is likely to be) needed. Configuration criteria determine whether the potential costs (money, battery, data...) of establishing path(s) before they are definitely needed and/or maintaining more paths than are needed outweigh the benefit of having at least part of the voice path to the end user already established and/or a backup path available.

In the case of a MAP (24) being "in circuit" this allows the path to it to be prepared in advance -reducing the impact of the extra call leg required. In this case, the voice path required is not to the eventual phone number (EXT1 in the previous examples) but to one of the business numbers (such as BUSPRIV1) which is known before the user selects who they wish to talk to (e.g. EXT1). This process therefore is typically initiated as soon as the user accesses the Corporate Dialler.

At some point, the endpoint (EXT1) becomes known (and any potential alternative numbers that may be used, for example, to reach the individual over an alternative route such as SkypeTM WhatsAppTm or similar).

The PathManager first determines (902) the set of potential voice paths that are available now -from the PathSelector. From the current state of these and the configuration data that specify the balance between speed, reliability, cost and bandwidth, a subset of some or all of these are selected for path establishment (903).

Connection(s) is/are then initiated (904) over each of these selected voice paths. Note that this set may include both a circuit-switched voice call over an mobile network and a VolP connection over the same network (e.g. 4G). Furthermore, it may include more than one possible connection over a single path. For example, a direct connection to the end user may be attempted over SIP and/or any of the alternative addresses known to the application -all via the same Wi-fi connection.

Typically, each connection is handled on a separate thread and/or using asynchronous callbacks that allow each to proceed independently. Each connection attempt results in subsequent connection progress events and/or timeouts (905) should the expected progress fail to occur. Each of these updates an in-memory view of the currently available connections and outstanding attempts.

As connection states change and/or on a refresh timeout the process evaluates (906) the performance and state of each connection and hence the desirability of maintaining it. If this has changed the optimum desired connection state then (907) the connection is started/stopped/demoted/promoted/has media started/has media stopped as appropriate.

Connections deemed appropriate for the voice call to use are made available to the other processes that are collecting the user's speech and extracting audio from the received data to be played.

Note that more than one such connection may be active and transmitting and/or receiving data at the same time.

For example, if speed and reliability of connection are paramount -and cost is less of a concern, then if the first connection to become established is an MNO voice channel and that network is "showing 4 bars" (i.e. good signal) the call is likely to be reliable -so alternative channels may be dropped.

As with the PathSelector, these decisions are typically based on simple rules initially, then more complex rules and ultimately on machine learning figuring out the best answer once sufficient training data has been accumulated and a model trained.

Although the PathManager can measure incoming packet quality metrics, it cannot determine how well the outbound path is performing. Information on this can be measured by the MAP (24) end and transmitted back to the PathManager via RTCP and/or proprietary protocols.

The process may therefore decide to modify the state of a connection (907) and/or to switch which is being used for transmission and/or reception. This modification can be more than simply dropping a connection. For example, a SIP connection can be established but the media stream(s) not flowing. In the case of extreme reliability being required, a call started as a normal voice call over a mobile network may have a second (or more) channel(s) established over VolP.

If data usage and/or cost are deemed more important than a completely uninterrupted call then the SIP channel may be kept open but no media flows until problems are experienced with the voice channel. In this case, that may not be possible for the application to determine -but the corporate dialler app may present the user with a button such as "Switch to Wi-fi" that he can press if the cellular signal falters and he is unhappy with the call quality.

Advantageously, even if a VolP channel is not being used for the actual voice, short exploratory or "probing" bursts of data may be exchanged over it so as to have ongoing and growing confidence in the application's understanding of the quality of the channel. This can then be reflected in whether or not the "Switch to Wi-fl" button is presented and/or an indication of the expected quality of that as an alternative channel is shown.

In cases where reliability is important, more than one voice channel may be maintained at the same time. At the MAP (24) these multiple connections-typically one via the mobile network, PSTN and PBX and another via direct SIP connection -are known to be from the same mobile phone (1). They are therefore treated as such within the conference bridging process. Audio from only the currently selected "better" channel is added into the conference audio. The other channel(s) is/are treated as "listen only" participants. This ensures the same data is sent to the mobile over all such channels and it can play the audio from whichever it is receiving better (which may not be the same channel that the MAP has determined has "best" incoming audio).

In other configurations, the MAP (24) may preferentially use the voice data received over VolP as this may be of higher quality than that received over the mobile network's voice circuit. Even though the jitter and/or packet loss rate may make that a worse channel from the point of view of injecting audio into the call at the MAP (24), it may still be a better option to feed analysis tools such as speech recognition engines.

As long as the path is still of interest (908) the process regularly refreshes its connections -or does so immediately it is notified of a change of state (909).

Note that in the case of the MAP (24) being used, it is advantageous to maintain a SIP or SIPS connection even between calls -and at least burst test its media capabilities if not keeping it open as a full voice channel (or use a codec with silence suppression and let that drop the data rate down until needed). So long as the Corporate Dialler app is in foreground or there is a call in progress, a SIPS connection to the MAP is beneficial and should be maintained.

It will be appreciated that the voice path selection and switching processes of Figures 6-9 have applicability outside of the multinational corporate environment that is the primary focus of this patent application. Small businesses and individuals can also benefit from the ability to find and use the most appropriate voice path that is available to them. This may be as simple as choosing between two SIMs and VolP on the basis of "best" versus "cheapest" option.

Little mention has been made of SMS messaging above. This short text messaging service to and from mobile phone numbers can be accommodated within the MAP (24) architecture described. Intra-company messages can be routed via a central service and their details and content logged to the appropriate archival system. Messages to and from the public are received at or sent from the same endpoint that voice to or from that mobile number uses. This MAP Endpoint can then send a copy of the data to the archiving service if required before forwarding the message on via the same redirection algorithms it uses to reach the mobile phone for voice calls.

Although the description has concentrated on "voice calls", the same approaches and techniques apply if the call includes other real-time streams such as one or more video stream(s).

Claims (23)

1. CLAIMS1. A system consisting of a plurality of mobile access points, each of which may be contacted via a telephone call over the public telephone network using one or more public network telephone numbers and over the internet by one or more addresses wherein calls made by mobile phones configured with said telephone numbers and addresses are routed to and from a desired end address via at least one of said access points.
2. 2. A system of claim 1 further characterised in that said public network telephone numbers are routed from the public switched telephone network to a private branch exchange in communication with said mobile access point over a company's internal network.
3. 3. A system of claim 1 in which voice and/or video connections from said mobile phone to said mobile access point are initiated concurrently via said public telephone number and said internet address.
4. 4. A system of claim1 in which said routing is via the corporate network of the company deploying said mobile access points.
5. 5. A system of claim 4 in which said routing utilises the same least cost routing plan as used by said company for calls between its internal telephones and external parties.
6. 6. A system of claim 1 in which a plurality of said mobile access points monitor each other's state by means of network connections between them.
7. 7. A system of claim 1 in which a plurality of said mobile access points monitor the integrity of the internal telephony system to which they and another mobile access point are connected by observing state changes occurring on at least one address assigned to said other mobile access point.
8. 8. A system of claim 1 in which one or more copies of the audio and/or video flowing to and from said mobile phone are transmitted to a recording and/or file storage or archival system.
9. 9. A system of claim 1 in which only calls made via a subset of the mobile network connections available on said mobile phone are routed via said mobile access points.
10. 10. A system of claim 1 in which calls originating from said mobile phone present calling party information identifying an alternative number.
11. 11. A system of claim 1 in which said end address is communicated to said mobile access point via a data network in parallel with the establishment of the telephone call to said mobile access device and that said mobile device initiates a telephone call to said end address on receipt of said data message.
12. 12. A system of claim 1 in which, prior to said end address answering the telephone call made to them the originating user is presented with a plurality of options each of which results in a different set of actions being taken with regard to how long the call rings and what is done afterwards.
13. 13. A system of claim 1 in which more than one audio or video path is established for at least part of said call.
14. 14. A system of claim 13 in which the measured quality of said call determines which of said multiple paths is used for the transmission and/or reception of data.
15. 15. A system of claim 13 in which a different audio stream is used for automated analysis than that which is used for transmission to and/or receipt of data from the participants in the call.
16. 16. A system of claim 1 in which the state and/or performance of multiple networks is monitored before and/or during said calls to determine which one or more of said networks should be used for said call.
17. 17. A system of claim 1 in which said mobile phone is instructed via a data path to initiate a telephone call to a specified number thus establishing a call to a point to which the audio from an inbound call has also been routed and hence audio can be exchanged between said inbound call and said mobile phone without having to place a call to said mobile phone.
18. 18. A system of claim 16 in which said network state and/or performance and location of said mobile phone is transmitted to a shared repository from which aggregated such data previously submitted by others and/or recommendations derived therefrom are retrieved.
19. 19. A system of claim 16 in which said performance is determined at least partially by the transmission of known bursts of packets.
20. 20. A system of claim 17 in which said bursts are triggered by starting media flowing over an RTP or SRTP channel previously established via SIP or SIPS.
21. 21. A system of claim 17 in which said bursts mimic or are the result of using a codec supporting a silence suppression during short periods of sound interspersed with sustained periods of silence.
22. 22. A system of claim 16 in which the connection used to transmit and/or receive voice or audio is changed during the call in response to user input and/or quality metrics taken of the data reception locally and/or data transmission quality as reported back by the recipient.
23. 23. A system of claim 1 in which voice and/or video streams are transmitted and/or received over more than one path at the same time.