CALL CONTROL

Abstract

A method of operating a user terminal in a telecommunications network. A telephony call is established between a first user, associated with the user terminal, and a remote user. Data communications is conducted between the user terminal and a communications server, such that the user terminal has a first connection to a communications session associated with a communications server. The telephony call is manipulated such that the telephony call forms a second connection to the communications session. Both the first connection and the second connection are maintained, for conducting communications between the first user and the remote user. The second connection may be terminated after assessment is made that the first connection is likely to provide better quality of service.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to GB Application No. 1905589.6, filed Apr. 18, 2019, and GB Application No. GB1911237.4, filed Aug. 6, 2019, under 35 U.S.C. § 119(a). Each of the above-referenced patent applications is incorporated by reference in its entirety.

BACKGROUND OF THE INVENTION

Field of the Invention

The present disclosure relates to improved methods of, apparatus for and computer software for call control in telephony-capable communication networks.

Description of the Related Technology

Traditional telephony, based on circuit-switched networks such as PSTN (Public Switched Telephony Networks) and GSM (Global System for Mobile communication), is moving towards packet-based telephony using technologies such as Long Term Evolution (LTE) and Next Generation Network (NGN), also referred to as Fifth Generation (5G) technologies. This move to packet-based technologies allows for the convergence of voice and data as well as the provision of further non-voice communication services such as instant messaging, video conferencing, desktop sharing etc. One of the issues associated with these developments is that the user experience can be overly complex, especially when a user attempts to transition from one service to another.

For example, there are known ways to convert a two-way circuit-switched call into a three-way circuit-switched call. However, these techniques are not familiar nor easy to achieve and may requires that specific call control actions are taken in the correct order and the process is not simple or user friendly.

Alternatively, third party meeting apps such as Skype™ may be used. However the quality of service (QoS) for a third party meeting app voice call may be lower than that available for voice calls made via a telephony-capable network such as known cellular networks.

Another alternative approach would be for the network to provide QoS for an entire meeting data stream (voice, screen-sharing etc.). However, third party apps such as meeting apps installed on a user terminal may not be able to access QoS-enabled network services. And although some additional services may defined in a telecommunications network (e.g. video calling) which can benefit from additional QoS, these do not offer the range of collaboration features available via the more richly-featured meeting services.

SUMMARY

According to a first aspect of the present disclosure, there is provided a method of operating a user terminal in a telecommunications network, the method comprising the steps of:

• • establishing a telephony call between a first user, associated with the user terminal, and a remote user;
  • conducting data communications between the user terminal and a communications server, such that the user terminal has a first connection to a communications session associated with the communications server;
  • initiating a manipulation of the telephony call such that the telephony call forms a second connection to the communications session;
  • maintaining both the first connection and the second connection to the communications session, for conducting communications between the first user and the remote user.

According to a second aspect of the present disclosure, there is provided a method of controlling communications in a telecommunications network, the method comprising the steps of:

• • conducting data communications between a communications server and a first user terminal, associated with a first user, such that the first user terminal has a first connection to a communications session associated with the communications server, wherein, prior to the data communications between the communications server and the first user terminal, an in-progress telephony call exists between the first user and a second user, associated with a second user terminal;
  • participating in a manipulation of the telephony call such that the telephony call forms a second connection to the communications session;
  • conducting data communications between the communications server and the second user terminal, such that the second user terminal has a third connection to the communications session; and
  • maintaining both the first connection and the second connection to the communications session, and the third connection to the communications session, for conducting communications between the first user and the second user.

According to a third aspect of the present disclosure, there is provided a method of operating a user terminal in a telecommunications network, the method comprising the steps of:

• • conducting data communications between the user terminal and a communications server, such that the user terminal has a first connection to a communications session associated with the communications server;
  • conducting a telephony call between the user terminal and the communications server, such that the user terminal has a second connection to the communications session;
  • transmitting and/or receiving non-voice meeting service data between a user of the user terminal and a remote user, via the first connection; and
  • selecting between the first connection and the second connection, for transmitting and/or receiving voice data between the user of the user terminal and the remote user.

According to a fourth aspect of the present disclosure, there is provided a method of controlling communications in a telecommunications network, the method comprising the steps of:

• • conducting data communications between a communications server and a user terminal, such that the user terminal has a first connection to a communications session associated with the communications server;
  • conducting a telephony call between the communications server and the user terminal, such that the user terminal has a second connection to the communications session;
  • transmitting and/or receiving non-voice meeting service data between a user of the user terminal and a remote user, via the first connection; and
  • selecting between the first connection and the second connection, for transmitting and/or receiving voice data between the user of the user terminal and the remote user.

An advantage of some aspects is that an in-progress voice call may be uplifted at the communications server whilst maintaining the voice call, thereby improving voice call continuity. The voice call may be native to a voice-optimized communication network, and therefore may be of a higher quality than available by communicating voice data with a communications server directly. There is no need for a call party to take specific call control actions to switch or merge the call, other than to uplift the call to the communications server.

Further features and advantages of the disclosure will become apparent from the following description of preferred embodiments of the disclosure, given by way of example only, which is made with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a schematic depiction of a communication network, according to a first example of the present disclosure, when a voice call is in progress;

FIG. 2 shows a schematic depiction of the network of FIG. 1 when the voice call is to be uplifted by a first user whilst keeping the first user terminal on the voice call;

FIG. 3 shows a schematic depiction of the network of FIG. 1 when the voice call has been uplifted by the first user whilst keeping the first user terminal on the voice call;

FIG. 4 shows a schematic depiction of the network of FIG. 1 when a three-way call has been set up whilst keeping the first user terminal on the voice call;

FIG. 5 shows a schematic depiction of the network of FIG. 1 when the voice call is to be uplifted by a second user whilst keeping the second user terminal on a voice call;

FIG. 6 shows a schematic depiction of the network of FIG. 1 when the voice call is being uplifted by the second user whilst keeping the first and second user terminals on the voice call;

FIG. 7 shows a schematic depiction of the network of FIG. 1 when the voice call has been uplifted by the first and second users whilst keeping the first and second user terminals on respective ends of the voice call;

FIG. 8 shows a schematic depiction of the network of FIG. 1 when the voice call is to be uplifted in respect of a second user without keeping the second user terminal on the voice call; and

FIG. 9 shows a schematic depiction of the network of FIG. 1 when the voice call has been uplifted in respect of a second user without keeping the second user terminal on the voice call.

FIG. 10 shows a schematic depiction of elements of a communication network according to examples of the present disclosure;

FIG. 11 shows a schematic depiction of a communication network, according to a further example of the present disclosure, when a voice call is in progress;

FIG. 12 shows a schematic depiction of the network of FIG. 11 when the voice call is to be uplifted by a first user whilst keeping the first user terminal on the voice call;

FIGS. 13 to 17 show schematic depictions of steps carried out in the network of FIG. 11 when the voice call is being uplifted by the first user; and

FIGS. 18 to 21 show schematic depictions of alternative steps carried out in the network of FIG. 11 when the voice call is being uplifted by the first user.

DETAILED DESCRIPTION OF CERTAIN INVENTIVE EMBODIMENTS

FIG. 1 shows a schematic depiction of a communication network according to a first embodiment of the present disclosure when a voice call is in progress. The communication network may include a plurality of interconnected communication networks including a first cellular radio network, a public switched telephony network (PSTN) 102, a packet data network (PDN) 104 such as the Internet, and a second cellular radio network 106. A communications server 108, referred to herein as a “meeting server”, may be connected each of to the cellular radio networks 100, 106 via both the PSTN 102 and the PDN 104. Whilst the communications server 108 is referred to herein as a “meeting server”, it should be understood that the meeting server generally provides one or more communication services, which may or may not include one or more meeting services.

FIG. 1 also shows a first user terminal 110A and a second user terminal 110B. These are cellular radio terminals, such as smartphones, which are adapted to conduct voice telephony. The user terminals 110A, 110B may be Long Term Evolution (LTE) user terminals and/a Next Generation Network (NGN) user terminals, also referred to as Fifth Generation (5G) user terminals.

The first cellular radio network 100 may be a Long Term Evolution (LTE) network or a Next Generation Network (NGN) network, also referred to as a Fifth Generation (5G) network. The cellular radio network 100 includes a plurality of radio base stations, of which only one is shown for the sake of clarity, forming part of a radio access network (RAN) associated with the cellular radio network 100.

The first cellular radio network 100 may include a plurality of call control nodes, including one or more telephony application servers (TASs), of which only one TAS 112 is shown for the sake of clarity, forming part of a core network of the cellular network 100. The TAS 112, sometimes known in a telephony context only as an application server (AS), is used in the core network to provide call control for telephony applications and may provide additional multimedia functions. The core network may have an NGN or IP Multimedia Subsystem (IMS) architecture. The TAS 112 may include components providing call control and/or media transformation, such as a softswitch and/or media gateway.

The cellular radio network 100 may employ the session initial protocol (SIP) for voice calls. The network's call control nodes for voice calls, such as TAS 112, may have SIP signalling capabilities and may be directly involved in a voice call's signalling flow. A call control for voice calls, such as TAS 112, may be a SIP back-to-back user agent (B2BUA). A call control node for voice calls, such as TAS 112, may act as a redirect server, proxy server, originating user agent and/or terminating user agent.

A call control node for voice calls, such as TAS 112, may include functionality adapted to emulate the calling features provided by the PSTN, referred to as PSTN Emulation Subsystem (PES), and can include calling features like call forwarding, voicemail and conference bridges. A call control node for voice calls, such as TAS 112, may additionally provide advanced features like unified messaging and video calling.

A call control node for voice calls, such as TAS 112, may be a purpose-built hardware appliance, may be specialized software running on a general-purpose hardware appliance, may be one or more virtualized network functions (VNFs) running in a cloud environment as part of a network function virtualization (NFV) deployment, or may be one or more distributed applications running in a containerization deployment.

The second cellular radio network 106 may have the characteristics described above in relation to the first cellular radio network 100, and may include a plurality of call control nodes, including one or more TASs, of which only one TAS 114 is shown for the sake of clarity, forming part of a core network of the cellular radio network 106.

Voice calls may be initiated or answered by use of a built-in telephony client on a user terminal 110A, 110B. The built-in telephony client is adapted to interwork with core network functions of the cellular radio networks 100, 106, to conduct telephony interworking with specific telephony functionality in the core network. Such a telephony client may be referred to as a “native” telephony client and a voice call made via a native telephony client may be referred to as a cellular-network-native voice call, being native to the cellular radio networks 100, 106. Such cellular-network-native voice calls are referred to herein as “native” voice calls for the sake of brevity. A native voice call is handled by call control nodes such as TASs 112, 114 in the core of the cellular radio network 100. Native voice telephony communication may be provided in a circuit-switched calling arrangement, such as available in 2G and 3G networks, and/or packet-switched calling arrangement, such as available in 4G, 5G and other future networks. Current packet-switched calling arrangements include Voice Over LTE (VoLTE) as defined in GSMA Permanent Reference Document (PRD) IR.92 “IMS Profile for Voice and SMS”, and various future variations are envisaged in 5G and other future networks. A native voice call may have a higher quality of service (QoS) than the standard, best-effort packet-switched data.

Another type of data exchange, which may be referred to as over-the-top (OTT) data exchange, which relies on best-effort packet-switched data, may be conducted by a pre-installed or downloadable software application installed on a user terminal 110A, 110B, referred to herein as a “meeting app”. The meeting app is adapted to interwork with the meeting server 108. Note that, whilst the communication application is referred to herein as a “meeting app”, it should be understood that the meeting app generally provides access to one or more communication services, which may or may not include one or more meeting service.

The meeting server 108 and the meeting apps on user terminals 110A, 110B make use of packet data links, for example Hypertext Transfer Protocol (HTTP) connections, which may be set up through the cellular radio networks 100, 106 but do not pass through a cellular network's call control nodes. The packet data links may carry both session control data and session media data, which two elements are referred to herein generally as session data. The session data is used to establish and control the communications session, and may carry non-voice communications data such as multimedia data to be exchanged between users during the communications session. Such multimedia data may include video image data, still image data, textual data such as instant messaging data, data files, screen sharing data and/or hyperlink data.

A user terminal 110A, 110B may simultaneously conduct a native voice call via the native telephony client and OTT data exchanges via the meeting app.

Voice calls may be established via the meeting server 108. Such a voice call may be a two-party voice call, or may be a multi-party voice call (i.e. three-or-more-party voice call). A voice call established via the meeting server 108 may also referred to as a conference call, and may consist of two or more individual voice calls established between the respective users' user terminals 110A, 110B and the meeting server 108, bridged together at the meeting server 108. The individual voice calls may be PSTN voice calls, native voice calls and/or may be OTT data exchange voice calls. A user may access a conference call by dialling into a predetermined service number and entering a conference ID after the call is answered by an Interactive Voice Response (IVR) component at the meeting server 108. Alternatively, or in addition, a user may access a conference call by clicking on a hyperlink in a Hypertext Markup Language (HTML) formatted communication such as an email. Further alternatively, or in addition, a user may access a conference call by receiving an out-dial voice call from the meeting server 108 after having been invited by one of the other participants using a meeting app on their user terminal 110A, 110B.

A communications session established via the meeting server 108 may involve a voice call component and/or a multimedia data exchange component.

The meeting server 108 may be a purpose-built hardware appliance, may be specialized software running on a general-purpose hardware appliance, may be one or more virtualized network functions (VNFs) running in a cloud environment as part of a network function virtualization (NFV) deployment, or may be one or more distributed applications running in a containerization deployment.

FIG. 1 illustrates a communication state, in which first and second users are conducting a native voice call, which has been established via each of the first and second TAS 112, 114 and via the PSTN 102, on their cellular user terminals 110A, 110B. The voice call has for example been initiated by use of a native telephone dialler on one of the user terminals 110A, 110B and has been answered by use of a native telephone answering function on the other user terminal 110A, 110B. The voice call includes a first call leg 116, established between the first user terminal 110A and the first TAS 112, a second, middle, call leg 118, established between the first TAS 112 and the second TAS 114, and a third call leg 120, established between the second TAS 114 and the second user terminal 110B. The middle call leg 118 may be established via the PSTN 102, as shown. In an alternative (not shown), where the two user terminals 110A, 110B are operating in the same cellular network, the middle call leg may be established across two different TASs within the cellular network. Where the two user terminals are currently being serviced by the same TAS, the middle call leg 118 may not exist at the physical level but may be controlled as a logical connection within a single TAS. The meeting server 108 may also be co-located with a, or the, TAS.

FIG. 2 illustrates a communication state, in which the first user has initiated an uplift in communication whilst keeping the first user terminal 110A on the native voice call. The meeting app is adapted to interwork not only with the meeting server 108 but also with the first TAS 112. The first user may for example initiate an uplift in communication by opening the meeting app during the call, and pressing a single button, or a combination of buttons, on the user interface provided by the meeting app to request uplift of an in-progress native voice call. In response to the initiation, the meeting app may query the operating system of the first user terminal 110A for call-characterising data indicating one or more characteristics of the currently in-progress call. The call-characterising data may include, for example, a telephony party identifier of the second user, which is associated with the second user terminal, and which may be either the calling party ID or the called party ID for the call, depending on which party initiated the call.

The meeting app may cause the first user terminal 110A to transmit a call control instruction message 122 to the first TAS 112. The call control instruction message 122 is for associating a to-be-established new call leg, between the TAS 112 and the meeting server 108, with the currently in-progress native voice call. The call control instruction message 122, and/or subsequent call control data sent from the first user terminal 110A and the meeting server 108, includes one or more elements of call control data.

The call control instruction message 122, and/or subsequent call control data sent from the first user terminal 110A to the TAS 112, may include call control data requesting communication uplift processing to be initiated by the TAS 112. The TAS 112 processes the call control instruction message 122, and in response, sets a call feature, referred to herein as “call-based uplift”, relating to receiving an incoming call from the meeting server 108. The call feature may be set on the TAS 112 in relation to the telephony party identifier of the first user.

The call control instruction message 122, and/or subsequent call control data sent from the first user terminal 110A to the TAS 112, may include call control data in the form of call-identifying data indicative of the first user's telephony party identifier, namely that associated with the first user terminal 110A, and/or the call-characterising data. The TAS 112 may use the call-identifying data to identify call state associated with the currently in-progress native voice call, and to set a call-based uplift feature only for the currently in-progress call. Alternatively, or in addition, a call-based uplift feature may be set according to different parameters, such as an identity of the meeting server 108. Call control data is stored on the TAS 112 to indicate that the feature has been set.

The call control instruction message 122, and/or subsequent call control data sent from the first user terminal 110A to the TAS 112, may include call control data in the form of incoming-uplift-call identifying data. The incoming-uplift-call identifying data may include one or more of a telephony party identifier of the meeting server 108 used as a calling party identifier, a special service number used as called party identifier, or predetermined indicator to be included in signalling, associated with an incoming call from the meeting server 108.

The meeting app may cause the first user terminal 110A to transmit a session request message 124 to the meeting server 108, requesting the establishment of a communications session. In addition, the session request message may cause the meeting server 108 to establish a new call leg with the TAS 112, in order to make the meeting server 108 a party to the voice call via the new call leg, and to associate the new call leg with the communications session, in order to associate the communications session with the in-progress native voice call.

The session request message 124, and/or subsequent session data sent from the first user terminal 110A to the meeting server 108, includes one or more elements of session control data.

The session request message 124, and/or subsequent session data sent from the first user terminal 110A to the meeting server 108, may include session control data in the form of an identifier associated with the first user terminal, for example a telephony party identifier of the first user.

The session request message 124, and/or subsequent session data sent from the first user terminal 110A to the meeting server 108, may include session control data indicating that the first user wishes to uplift an existing native voice call into the data communications session.

The session request message 124, and/or subsequent session data sent from the first user terminal 110A to the meeting server 108, may include session control data in the form an identity associated with the TAS 112 to enable the meeting server to send uplift control data directly to the TAS 112. Such information may not be available to the user terminal 110A, or may not be necessary in order to perform uplift, and may not be included.

The session request message 124, and/or subsequent session data sent from the first user terminal 110A to the meeting server 108, may include session control data in the form of identity associated with the user terminal of the other call party, for example the telephony party identifier of the second users. Such information may not be necessary in order to perform uplift, and may not be included.

In response to receiving the session request message 124, the meeting server 108 may initiate a new call leg by sending a call establishment request from the meeting server 108 to the first user. The call establishment request may include an uplift party identifier. In an example, the uplift party identifier may be the telephony party identifier of the first user, which may be included in the call establishment request as the called party identifier for the new call leg. Alternatively, another form of identifier, for example a random string or number, may be used as the uplift party identifier. An uplift party identifier may be agreed between the first user terminal 110A and the meeting server 108, which may in turn each pass that identifier on to the TAS 112 for correlation. The uplift party identifier may be originally generated in the first user terminal 110A and passed onto the meeting server 108, or vice versa.

In response to receiving the call establishment request from the meeting server 108, the TAS 112 may correlate the uplift party identifier with the call control data set for the call-based uplift feature, and connect the new call leg 128 to the voice call on the basis of the correlating. The TAS 112 connects the new call leg 128 to the in-progress native voice call on the basis of the call control instruction message received earlier, to make the meeting server 108 a party to the voice call. The TAS 112 may merge the new call leg 128 with the existing call legs 116, 118.

FIG. 3 illustrates a communication state, in which the native voice call has been uplifted by the first user whilst keeping the first user terminal 110A on the native voice call.

The meeting server 108 may respond to the session request message 124 to establish a new communications session, for example a conference call, and to establish a communication link in the form of a data exchange connection 126, between first user terminal 110A and the meeting server 108, associated with the new communications session.

FIG. 4 illustrates a communication state, in which a three-way call has been set up whilst keeping the first user terminal 110A on the native voice call.

The first user terminal 110A, having uplifted communication as described in relation to FIGS. 1 and 3, may make use of various in-session services provided by the meeting server 108. Meeting content may be streamed, with a meeting data stream being sent in each direction via the data exchange connection 126. The meeting data streams may include various elements of meeting data content such as screen sharing data, video data, instant messaging data, etc.

In addition, or in the alternative, the meeting data stream may include control data for controlling the session at the meeting server. For example, the call may be converted into a multi-party conference call. To convert the call into a multi-party conference call, the first user may interact with the meeting app on the first user terminal 110A, in response to which the meeting app may transmit an add-participant request message to the meeting server 108 via the data exchange connection 126.

In response to receiving the add-participant request message, the meeting server 108 may cause an additional call with a further participant to be added, with the calls bridged together at the meeting server 108. The additional calls may be a PSTN voice call, a native voice call, an OTT data exchange voice calls. Alternatively, the additional call may be conducted from a computer terminal 130 via the PDN 104 via a further communication link 132. The additional user may access the conference call by dialling into a predetermined service number and entering a conference ID associated with the communications session set up by the first user, after the call is answered by an Interactive Voice Response (IVR) component at the meeting server 108. Alternatively, or in addition, the additional user may access the conference call by clicking on a hyperlink in a Hypertext Markup Language (HTML) formatted communication such as an email or text message sent by the first user from the first user terminal 110A, on the basis of session-identifying information received from the meeting server 108 over the session data link 126. Further alternatively, or in addition, the additional user may access the conference call by receiving an out-dial voice call from the meeting server 108 after having been invited by the first user using the meeting app on their user terminal 110A.

FIG. 5 illustrates a communication state, in which the native voice call is also to be uplifted by a second user whilst keeping the second user terminal 110B on the native voice call. In this state, the native voice call has already been uplifted by the first user as described in relation to FIGS. 1 to 3.

The second user terminal 110B transmits a call control instruction message 134, similar to the call control instruction message described above, to the second TAS 114. The second user terminal 110B also transmits a session request message 136, similar to the session request message 136 described above, to the meeting server 108.

The session request message 136 may cause the meeting server 108 to join the second user terminal 110B into the existing communications session, of which it is already a part for voice data exchange by virtue of the native voice call having been merged with the new call leg 128. After the meeting server 108 joins the second user terminal 110B into the existing communications session the second user may additionally conduct session control, and multimedia data exchange, via the meeting app on the second user terminal 110B.

FIG. 6 illustrates a communication state, when the native voice call is being uplifted by the second user whilst keeping the first and second user terminals 110A, 110B on the native voice call. The session request message 136 may cause the meeting server 108 to initiate a establish a further call leg 140, shown in FIG. 6, in a manner similar to the way in which the new call leg 128 has been established. The further call leg 140 may be merged with the other call legs 118, 120 at the second TAS 114, thus associating the further call leg 140 with the communications session.

FIG. 7 illustrates a communication state, when the native voice call has been uplifted by the first and second users whilst keeping the first and second user terminals 110A, 110B on respective ends of the native voice call. The middle call leg 118 may be torn down by the second TAS 114 once the further call leg 140 has been merged with the other call legs 118, 120 at the second TAS 114. An instruction to tear down the middle call leg 118 after establishment of the further call leg may accompany either the call establishment request for establishing the further call leg 114, or the call control instruction message call control instruction message 134.

In the example described above in FIGS. 6 to 8, the first and second TAS conduct call uplift processing by merging in new call legs. In an alternative, a TAS may cut over to a new call leg rather than merging in the new call leg. In this example, rather than merging in the new call leg 128 with the original middle call leg 118 as shown in FIG. 5, the first TAS 112 may cut over from the middle call leg 118 to the new call leg 128. And, rather than merging in the new call leg 140 with the original middle call leg 118 as shown in FIG. 6, the second TAS 114 may cut over from the middle call leg 118 to the new call leg 140, with a resulting communication state as shown in FIG. 7. In this example, the two ends of the call may co-ordinate triggers which cause the cut-overs to the new call legs, so that there is no glitch in the voice call uplift procedure. The co-ordination may be done by conducted by any of the control nodes involved in the uplift procedure, namely the first and second user terminals 110A, 110B, the first and second TAS 112, 114 and the meeting server 108, either alone or in combination.

The TAS 112 may for example connect the new call leg 128 to the in-progress native voice call on the basis of the call control instruction message received earlier, to make the meeting server 108 a party to the voice call, in response to receiving a trigger message from the user terminal 110A which causes the cut-over to the new call leg 128. Similarly the TAS 114 may for example connect the new call leg 140 to the in-progress native voice call on the basis of the call control instruction message received earlier, to make the meeting server 108 a party to the voice call, in response to receiving a trigger message from the user terminal 110B which causes the cut-over to the new call leg 140. The two user terminals, in particular the messaging apps on the user terminals, may co-ordinate the sending of each respective trigger message to each respective TAS 112, 114, by automatic communication between the messaging apps which confirm that each side is ready to perform uplift. Uplift, and the cut-overs performed by the TAS 112, 114 can then be performed at exactly the same time, or at least effectively the same time to avoid glitches. Prior to the trigger messages being sent to the TAS 112, 114 by the respective user terminal 110A, 110B, the user terminals may be informed by each respective TAS that it is ready for uplift, having received a call establishment request from the meeting server 108.

In some examples, as TAS, in this case the second TAS 114, cannot conduct call-based uplift or other forms of call uplift processing. The TAS may, for example, be a legacy TAS. FIG. 8 illustrates a communication state, when the native voice call is to be uplifted in respect of a second user without keeping the second user terminal 110B on the native voice call.

As before, the meeting app on the second user terminal 110B may send a session request message 142 whilst the call is in progress. However in this case the meeting app on the second user terminal 110B does not send a call control instruction message to the second TAS 114. In response to the session request message 142, the meeting server may make the second user terminal a party to the communications session via a newly established data exchange link 144, as illustrated in FIG. 9, when the native voice call has been uplifted in respect of the second user without keeping the second user terminal 110B on the native voice call. In this case, the meeting app on the second user terminal 110B, or the second user themselves, may terminate the native voice call. The meeting app on the second user terminal 110B may connect the user to a new OTT voice call established via the meeting server 108. In this example, the meeting server 108 communicates voice call data for the conference call between the meeting server 108 and the first user terminal 110A via the new call leg 128 and communicates the voice call data between the meeting server 108 and the second user terminal via the newly established data exchange link 144.

As well as participating in the conference call managed by meeting server 108, the second user may now also conduct multimedia data exchange with the first user, using the meeting app on the second user terminal 110B, via the newly established data exchange link 144.

The first user terminal 110A, having uplifted communication as described in relation to any of FIGS. 1 to 9, has a first connection to the communications session at the meeting server 108, and having initiated a manipulation of the telephony call such that the telephony call forms a second connection to the communications session at the meeting server 108, can now maintain both the first connection and the second connection to the meeting server 108, for conducting communications between the first user and the second user, via the meeting server 108. The meeting server meanwhile maintains at least a third connection to the second user terminal 110A, as described. Both the first user and the second user may make use of the various in-session services provided by the meeting server 108, as described above. For example, the call may be converted into a multi-party conference call. When the first user decides to end interaction with the second user via the meeting server 108, the first user may end both the first connection and the second connection to the meeting server 108 substantially simultaneously, for example using a single button on the meeting app.

Whilst in the example shown in FIG. 8, the call legs 118, 128 are merged by the first TAS 112, the first TAS 112 may cut over from the old call leg 118 to the new call leg 108. The cut-over may be controlled by co-ordination between the messaging apps on the two user terminals, as described above.

In the example shown in FIGS. 8 and 9, the data exchange link 144 between the meeting server 108 and the second user terminal 110B is established by the meeting app sending from the second user terminal 110B a session request message 142. In the alternative, the meeting server 108 may initiate the establishment of the data exchange link 144 by transmitting a session invite message, for example as a push notification message, to the second user terminal in response to receiving the session control data from the first user terminal 110A.

In the above-described examples, a call control instruction is included in a call control instruction message 124 sent from the first user terminal 110A, or a similar message 134 sent from the second user terminal 110B, to a respective TAS 112, 114. Thus the call control state is changed under the control of the user's terminal. In an alternative, the message server 108 may be treated as a trusted party by a TAS 112, 114 and call control instructions may be included in signalling associated with a call establishment request sent by the meeting server 108 to set up the new call leg 128 and further call leg 140 respectively. The call control instructions may be based upon information included in session requests 124, 136 sent to the meeting server 108 by the first and second user terminals 110A, 110B respectively.

In the above-described examples, the new call leg 128 and further call leg 140 are established by a call establishment request originating at the meeting server 108. In alternative examples, a call establishment request may be originated at a respective TAS 112, 114 in order to set up the new call leg 128 and further call leg 140, in response to the call control instructions received from each respective user terminal 110A, 110B. Thus a TAS 112, 114 may transmit a call establishment request to the meeting server 108 in response to the call control instruction. The call establishment request may comprise a calling party identifier associated with the first user. The meeting server may transmit an answer message to the call establishment request to accept the call. The TAS 112, 114 may establish the new call leg 128, and further call leg 140, in response to the answer, and proceed to merge it with the in-progress native voice call as described above.

Where a call establishment request is originated at a TAS 112 in order to set up the new call leg 128, the TAS may include a session establishment request in signalling associated with the call establishment request, the session establishment request identifying a characteristic of the communications session, for example the telephony party identifiers.

In the above-described examples, the second user terminal 110B is at least initially connected to the native voice call via a second TAS 114. In an alternative, the second user terminal 110B may be at least initially connected to the native voice call via the same TAS 112 that the first user terminal 11A is connected to. Thus, a single TAS may conduct uplift for both the and second user terminals 110A, 110B respectively, and/or either endpoint separately.

An enhanced telephony function, such as that described herein, may assist users in uplifting a native voice call whilst keeping the user terminal on the native voice call, thereby providing an enhanced user experience and an opportunity for additional services and functionality to be made available to the user, via a separate data exchange link, whilst maintaining call quality.

A native voice call may for example be initiated by a user entering a telephony identifier, for example a telephone dialling number, into a native telephony client of a user terminal. The telephony identifier may be entered by the user dialling digits into the native telephony client or by the user selecting a remote party with whom they wish to conduct telephony from an address book (or ‘contacts’) function of a user terminal. Native voice telephony can be initiated in other ways, for example by speaking the name of the entity with whom they wish to conduct telephony in association with a dial-by-voice function of a user terminal.

Referring now to FIG. 10, there is shown an example of telephony equipment used in some examples of the disclosure. Access network arrangements, including a cellular access network which is used by at least the first user terminal 110A to access telephony services, are not shown here but should be understood to be included.

The first user terminal 110A may support native voice telephony communication, along with other types of communication such as packet-based data communication, short messaging service (SMS) communication, multimedia messaging service (MMS) communication and/or other types of telephony. Native voice telephony communication may be provided in a circuit-switched calling arrangement, such as available in 2G and 3G networks, and/or packet-switched calling arrangement, such as available in 4G, 5G and other future networks.

In this example, the telephony equipment comprises a first user terminal 110A, network-based telephony equipment 150 and a second user terminal 110B. The user terminals 110A, 110B may be a mobile user terminal or a non-mobile user terminal. Examples of user terminals include, but are not limited to, smartphones, tablet computing devices, laptop computing devices, desktop computing devices, smart televisions, computer games consoles, wearable computing devices and personal digital assistants.

The telephony network equipment 150 may comprise one or more servers. In some examples, the telephony network equipment 150 comprises a telephony application server 112. An example of a telephony application server is a SIP application server. The telephony network equipment 150 may also comprise a meeting server 108. The telephony network equipment 150 may comprise one or more physical resources and/or one or more virtualised resources. Where the telephony network equipment comprises multiple resources, the resources may be co-located or may be located remotely from each other.

The user terminals 110A, 110B each comprise a respective telephony client 152A, 152B and a respective meeting app 154A, 154B. The telephony clients 152A, 152B and the respective meeting apps 154A, 154B may be logically separate components of the user terminals 110A, 110B.

In this example, the telephony clients 152A, 152B of the user terminals 110A, 110B are each native to the user terminal. The telephony client 152A, 152B is native in that it is a default telephony function, which may (or may not) have been pre-installed when the user terminal 110A, 110B and may (or may not be) part of an operating system of the user terminal 110A, 110B. A native function may, in some cases, be referred to as a ‘built-in’, ‘out-of-the-box’ or ‘default’ function. The telephony client 152A, 152B is operable to conduct voice telephony via the telephony module 156. The telephony client 152A, 152B may be operable to conduct voice telephony via a circuit-switched link. The circuit-switched part of the telephony network may comprise a public land mobile network (PLMN) and/or a public switched telephone network (PSTN). The telephony client 152A, 152B may also, or in the alternative, be operable to conduct voice telephony via a packet-switched link. For example, the telephony client 152A, 152B may be operable to conduct Voice over Internet Protocol (VoIP) communication via a packet-switched link.

The meeting app 154A, 154B may be configured to communicate with the meeting server 108 via a packet-switched link, which may at least in part be the same as that used by telephony client 152A, 152B. The packet-switched link may comprise a public network, for example the Internet, and/or a private network. The meeting app 154A, 154B may be configured to communicate with the telephony network equipment 150 using a client-server connection. The meeting app 154A, 154B may be configured to communicate with meeting server 108 using HTTP or HTTPS, for example.

In some examples, the telephony client 152A, 152B and the meeting app 154A, 154B are comprised in a common software application on the user terminal 110A, 110B.

In other examples, the telephony client 152A, 152B and the meeting app 154A, 154B are comprised in separate software applications on the user terminal 110A, 210B. In such other examples, the meeting app 154A, 154B may be configured to use one or more APIs of the native telephony client 152A, 152B to communicate with the telephony client 152A, 152B. As such, as an alternative or in addition to providing suggestion functionality within the native telephony client 152A, 152B, applications or functions installed alongside the native telephony client 152A, 152B may use APIs made available by the native telephony client 152A, 152B and/or APIs made available by the user terminal 110A, 210B itself to provide the suggestion functionality described herein.

The meeting app 154A, 154B may be configured to transmit telephony control data associated with telephony conducted by the telephony client 152A, 152B. The meeting app 154A may be configured to transmit such data to the network-based telephony network equipment 150, for example to the meeting uplift module 158.

The meeting app 154A, 154B may be configured to transmit the telephony control data during a native voice call being conducted by the telephony client 152A, 152B. For example, the meeting app 154A, 154B may be configured to transmit the telephony control data in response to a trigger event. The trigger event may comprise the receipt of user input via the meeting app 154A, 154B, for example the user pressing an “uplift call” button and/or a communication event associated with the meeting app 154A, 154B, for example an incoming session establishment notification. The communication event may comprise the meeting app 154A, 154B receiving data from the meeting server 108. and/or from the other meeting app 154B, 154A, associated with a request to conduct a communications session.

The meeting app 154A, 154B may be operable to cause the voice telephony conducted with the telephony client 152A, 154A of the user terminal 110A, 110B on which the meeting app is installed to be uplifted. Alternatively or additionally, the meeting app 154A, 154B may be operable to cause the voice telephony conducted with the telephony client 152B, 152A of the remote user terminal 110B, 110A to be uplifted. The meeting app 154A, 154B may be able to cause an uplift initiation message to be transmitted to cause the voice telephony to be uplifted.

FIGS. 11 to 21 illustrate examples of the present disclosure. Where the same reference numerals have been used as in previous examples, the above description of the corresponding elements should be understood to apply to these examples.

FIG. 11 illustrates a communication state, in which first and second users are conducting a native voice call, which has been established via a TAS 112, on their user terminals 110A, 210B. Each of the user terminals 110A, 210B may have an installed meeting app 154A, 154B and at least one separate telephony client 152A, 152B as previously described. Here, the first user terminal 110A is connected to the TAS 112 via a cellular radio network 100, which may be referred to as the cellular access network. The TAS 112 is shown as being located outside of the cellular access network but may be located inside or outside of the cellular radio network 100. One or more additional call control nodes, for example a Session Border Controller (SBC) or Call Session Control Function (CSCF), may be connected in the call leg 116 between the first user terminal 110A and the TAS 112. In this example, the second user terminal 210B is a general purpose computing device, such as a laptop or desktop computer, connected to the TAS 112 via a call leg 204 across packet data network (PDN) 202. The packet data network (PDN) 202 may be an IP network. Alternatively, the second user terminal 210B could be another cellular user terminal, connected via the same or a different a cellular access network, similar to the first user terminal 110A.

FIG. 12 illustrates a communication state, in which the first user has initiated an uplift in communication whilst keeping the first user terminal 110A on the native voice call. The meeting app 154A on the first user terminal 110A is adapted to interwork not only with the meeting server 108 but also with the TAS 112. The first user may for example initiate an uplift in communication by opening the meeting app 154A during the call, and pressing a single button, or a combination of buttons, on the user interface provided by the meeting app 154A to request uplift of an in-progress native voice call. In response to the initiation, the meeting app 154A may query the operating system of the first user terminal 110A for call-characterising data indicating one or more characteristics of the currently in-progress call. The call-characterising data may include, for example, a call party identifier of the first user, which is associated with the first user terminal 110A, and which may be either the calling party ID or the called party ID for the call, depending on which party initiated the call. The call-characterising data may include, for example, a call party identifier of the second user, which is associated with the second user terminal 210B, and which may be either the calling party ID or the called party ID for the call, depending on which party initiated the call.

The meeting app 154A may cause the first user terminal 110A to transmit a session request message 124 to the meeting server 108, requesting the establishment of a communications session. This will result in the connection of the meeting app 154A with the meeting server 108, via a client-server connection using a secure protocol such as HTTPS.

The session request message 124, and/or subsequent session data sent from the first user terminal 110A to the meeting server 108, includes one or more elements of session control data.

The session request message 124, and/or subsequent session data sent from the first user terminal 110A to the meeting server 108, may include session control data indicating that the first user wishes to uplift an existing native voice call into the data communications session.

The session request message 124, and/or subsequent session data sent from the first user terminal 110A to the meeting server 108, may include session control data in the form of an identifier associated with the first user terminal, for example the call party identifier of the first user.

The session request message 124, and/or subsequent session data sent from the first user terminal 110A to the meeting server 108, may include session control data in the form of an identifier associated with the second user terminal, for example the call party identifier of the second user. Such information may not be necessary in order to perform uplift, and may not be included.

Depending on how the second user terminal 210B is to be informed of the uplift, for example if the second user terminal is informed by means of a message directly from the first user terminal 110A, such information may not be necessary in order to perform uplift in respect of the first user, and may not be included. However if the meeting server 108 is to initiate communication with the second user terminal 210B, an identifiers associated with both the first user terminal 110A and the second user terminal 210B are preferably sent by the first user terminal 110A to the meeting server 108.

Referring to FIG. 13, the meeting server 108 may respond to the session request message 124 to establish a new communications session, for example a video conference, and to establish a communication link in the form of a data exchange connection 126, between first user terminal 110A and the meeting server 108, associated with the new communications session.

The meeting app 154A is then connected with the meeting server 108, via a client-server data exchange link 126 using a secure protocol such as HTTPS. The meeting server uses this data exchange link 126 to send an identifier for the newly established communications session to the meeting app 154A on the first user terminal 110A. The communications session identifier may for example be a globally-unique voice telephony identifier such as a SIP address, identifying the meeting server with the hostname, and a locally-unique reference for the session as the username, e.g. meetingID@meetingserver.example.com.

The meeting app 154A may cause the first user terminal 110A to transmit a call control instruction message 206 to the TAS 112. The call control instruction message 206 is addressed to the TAS 112. The address of the TAS currently handling the in-progress voice call may be derived by the meeting app 154A for example by lookup in a service database using a reference to the in-progress voice call, for example by means of a call identifier and/or by means of the two call party identifiers of the first and second users. The call control instruction message 206 is handled by the meeting uplift module 158 in the TAS 112.

The call control instruction message 206 is for initiating the transfer of the call leg 116, from the TAS 112 to the meeting server 108, with the currently in-progress native voice call being maintained at least with respect to the first user terminal 110A.

The call control instruction message 206, and/or subsequent call control data sent from the first user terminal 110A to the TAS 112, includes one or more elements of call control data. The call control data may include the communications session identifier previously sent by the meeting server 108 to the meeting app 154A on the first user terminal 110A. The call control data may also reference the in-progress voice call, for example by means of a call identifier such as the SIP dialog identifier for the call, and/or by means of the two call party identifiers of the first and second users.

In response to receiving the session request message 124, and/or subsequent session data sent from the first user terminal 110A to the meeting server 108, the meeting server 108 may also initiate the establishment of a new OTT data link with the second user terminal 210B. The meeting server 108 may initiate the establishment of the new OTT data link by sending a session invite message 208 to the second user terminal 210B. The session invite message may include the call party identifier of the first user as information to be presented to the second user when receiving the session invite (e.g. “You are currently in call with [call party identifier], please click to accept uplift to video conference”). The session invite message 208 may for example be a push notification message. It may include a URL including data identifying or corresponding to the session ID, for example www.meetingserver.example.com/meetingID. The session invite message may be presented by the meeting app 154B on the second user terminal 210B to the second user, or may be presented by a notification function on the second user terminal 210B associated with the push notification.

Referring to FIG. 14, if the second user accepts the session invite message 208, for example by pressing a single button, or a combination of buttons, on the user interface provided by the meeting app 154B or the notification function, the second user terminal 210B sends in response a session join message 212. The session join message 212 includes the URL including data identifying or corresponding to the session ID, for example www.meetingserver.example.com/meetingID, which was sent in the session invite message, and the meeting server then establishes a connection to the meeting app.

The meeting app 154B on the second user terminal 210B is then connected with the meeting server 108, via a client-server data exchange link 218, as shown in FIG. 15, using a secure protocol such as HTTPS. The meeting server 108 joins the second user into the appropriate communications session using the session ID received in the session join message 212. The second user, via the meeting app 154B on the second user terminal 210B, is then thereby joined into the same communications session in which the first user, via the meeting app 154A on the first user terminal 110A, is already a participant. The communications session may include a voice call bridge such that the second user terminal 210B may now continue the voice call via the client-server data exchange link 218, and the user or the meeting app 154B may terminate the original voice call leg 204, as shown in FIG. 16.

The second user, via the meeting app 154B on the second user terminal 210B, may also participate in additional data communication using any enhanced call-related services provided by the meeting server (for example video conferencing) with respect to the first user. Both the first user and second users, via the meeting apps 154A, 154B on the first and second user terminals 110A, 210B, are now participants in the same communications session, and may conduct for example video conferencing with each other via the meeting server 108.

Referring back to FIG. 14, on receipt of the call control instruction message 206, the meeting uplift module 158 in the TAS 112 parses the message contents and in response to the call control instruction, instructs the telephony module 156 in the TAS 112, which is handling the call control for the currently in-progress call between the two user terminals 110A, 210B, to transfer the call leg 116 from the TAS 112 to the meeting server 108. The meeting uplift module 158 identifies the in-progress call and also passes the communications session identifier to the telephony module for processing.

The transfer at this point may be conducted using network-based call control functionality available in the native telephony protocol used in the cellular radio network 100, in this example SIP. The telephony module may for example use the Basic Transfer Call Flow mechanism described in IETF RFC 5589—“Session Initiation Protocol (SIP) Call Control—Transfer”, the contents of which are incorporated herein by reference. The transferor may be the TAS 112, the transferee may be the user terminal 110A and the transfer target may be the meeting server 108, more particularly the specially-established communications session at the meeting server 108.

The telephony module 156 in the TAS 112 may put the call leg 116 on hold and transmit a REFER message 214 to the native telephone client 152A in the user terminal 110A, which is handling the in-progress native voice call leg 116. The Refer-To header may include details of the communications session which has been established at meeting server 108 for the call uplift (e.g. it contains the SIP address of the communications session, for example meetingID@meetingserver.example.com).

Referring to FIG. 15, on receipt of the REFER message 214 the native telephone client 152A in the user terminal 110A may send an INVITE message 216 which is addressed to the SIP address of the communications session at the meeting server 108. The INVITE message 216 may be transmitted to the meeting server 108 directly, via a call control node other than the TAS 112, and/or via the TAS 112.

Referring to FIG. 16, receipt of a 200 OK message (not shown) from the message server 108 in response to the INVITE message 216 results in the setting up of a cellular-native call path 220 between the first user terminal 110A and the meeting server 108. In this way the telephone client 152A is connected to the appropriate communications session which provides, amongst other services, a voice call bridge for conducting voice calls with respect to the second user terminal 210B and other parties that may be invited to attend.

On receipt of the 200 OK message from the meeting server 108, the telephone client 152A may then release the call leg 116 by sending a BYE message to the TAS 112.

As shown in FIG. 17, the first user terminal 110A is now connected, via the specially-established communications session at the meeting server 108, to the second user terminal 210B. The first user terminal may be connected to the session both via a cellular-native voice call leg 220, which is a maintained voice call as regards the first user terminal, and a newly-established OTT data link 126, which has been set up as a result of the uplift initiated by the first user. As a result of the uplift, the maintained cellular-native voice call has been manipulated by network-based call control to re-route the voice call to the meeting server 108.

Also as shown in FIG. 17, the second user terminal 210B is now connected, via the specially-established communications session at the meeting server 108, to the first user terminal 110A. The second user terminal 210B may be connected to the session via only a newly-established OTT data link 218, which has been set up as a result of the uplift initiated by the first user. The telephony module may for example use the Transfer with Dialog Reuse mechanism described in IETF RFC 5589—“Session Initiation Protocol (SIP) Call Control—Transfer”, the contents of which are incorporated herein by reference, where the REFER message 214 is sent within the existing SIP dialog context of call 116.

Note that, whilst in the example described above in relation to FIGS. 11 to 17 the transferee in the call manipulation is the first user terminal 110A, the transferee may alternatively be an intermediate call control node, for example a Session Border Controller (SBC) or Call Session Control Function (CSCF), acting as a SIP back-to-back user agent (B2BUA) in the call leg 116.

Note that, whilst in the example described in FIGS. 11 to 17 the re-routing of the call leg 116 to call leg 220—on the one hand—and the setting up of the OTT data link 218 and the tearing down of the second call leg—on the other hand—are not synchronized other than via their initial triggering in call uplift. However one or more additional synchronization steps may be performed during the progress of call uplift. For example the INVITE message 216 received by message server 208 may be used to trigger the session invite message 208 being sent to the second user terminal 210A. Alternatively, a NOTIFY message, informing the first user terminal 110A of the successful setting up of the call path 220, may be used to trigger the sending of a session invite message directly from the first user terminal 110A to the second user terminal 210B.

FIGS. 18 to 21 illustrate an alternative call flow to that illustrated in FIGS. 11 to 17. In this alternative, the call flow may proceed as described in relation to FIGS. 11 to 13 above. Referring now to FIG. 18, on receipt of the call control instruction message 206, the meeting uplift module 158 in the TAS 112 parses the message contents and in response to the call control instruction, instructs the telephony module 156 in the TAS 112, which is handling the call control for the currently in-progress call between the two user terminals 110A, 210B, to transfer the call leg 116 from the TAS 112 to the meeting server 108. The meeting uplift module 158 identifies the in-progress call, for example using the SIP dialog identifier for the call, and also passes the communications session identifier to the telephony module for processing.

The transfer at this point may be conducted using network-based call control functionality available in the native telephony protocol used in the cellular radio network 100, in this example SIP. The telephony module may for example use the Transfer Protecting Transfer Target mechanism described in IETF RFC 5589—“Session Initiation Protocol (SIP) Call Control—Transfer”, the contents of which are incorporated herein by reference. Again, the transferor may be the TAS 112, the transferee may be the user terminal 110A and the transfer target may be the meeting server 108, more particularly the specially-established communications session at the meeting server 108.

The telephony module 156 in the TAS 112 may put the call leg 116 on hold and transmit a REFER message 222 to the meeting server 108. The REFER message 222 may include details of the communications session which has been established at meeting server 108 for the call uplift (e.g. it contains the SIP address of the communications session, for example meetingID@meetingserver.example.com). The REFER message 222 may also identify the in-progress call, for example using the SIP dialog identifier for the call. Alternatively, the information may be transmitted separately to the meeting server 108, either from the meeting uplift module 158 in the TAS 112 or from the user terminal 110A.

Referring to FIG. 19, in response to receipt of the REFER message 222, the meeting server 108 may send an “INVITE with Replaces” message 224, containing the identifier for the in-progress call, to the user terminal 110A. This establishes a new SIP call leg 226 between the meeting server 108 and the user terminal 110A, whilst indicating to the user terminal 110A that the new call leg 226 replaces the first call leg 116 instead of presenting it to the user as new incoming call. In response to receipt of the “INVITE with Replaces” message, the telephone client 152A may then identify and release the call leg 116 by sending a BYE message to the TAS 112.

As shown in FIG. 21, the first user terminal 110A is now connected, via the specially-established communications session at the meeting server 108, to the second user terminal 210B. The first user terminal may be connected to the session both via a cellular-native voice call leg 226, which is a maintained voice call as regards the first user terminal, and a newly-established OTT data link 126, which has been set up as a result of the uplift initiated by the first user. As a result of the uplift, the maintained cellular-native voice call has been manipulated by network-based call control to re-route the voice call to the meeting server 108.

The first user terminal 110A, having uplifted communication as described in relation to any of FIGS. 11 to 17 and 18 to 21, has a first connection to the communications session at the meeting server 108, and having initiated a manipulation of the telephony call such that the telephony call forms a second connection to the communications session at the meeting server 108, can now maintain both the first connection and the second connection to the meeting server 108, for conducting communications between the first user and the second user, via the meeting server 108. The meeting server meanwhile maintains at least a third connection to the second user terminal 110A, as described. Both the first user and the second user may make use of the various in-session services provided by the meeting server 108, as described above. For example, the call may be converted into a multi-party conference call. When the first user decides to end interaction with the second user via the meeting server 108, the first user may end both the first connection and the second connection to the meeting server 108 substantially simultaneously, for example using a single button on the meeting app 154A.

Whilst in the above examples, the call control node is a telephony application server in the core network, the call control node may take other forms. For example, the call control node may reside at least in part in a user terminal. A user terminal may for example include a SIP user agent capable of merging calls in the manner described.

In the above examples, the session data, such as the non-voice communications data, which are transmitted between the meeting server 108 and the meeting apps 154A, 154B on user terminals 110A, 110B make use of OTT packet data links, for example Hypertext Transfer Protocol (HTTP) connections, which are set up through the cellular networks 100, 106 but do not pass through a cellular network's call control nodes. In the alternative, or in addition, such session data may be transmitted via a separate network link, such as an Internet or other packet data network link accessed via a Wi-Fi™ access point. The native voice call may also go via Wi-Fi™, in the case that a user terminal 110A, 110B supports voice over Wi-Fi™ calling (VoWi-fi, as defined in GSMA Permanent Reference Document (PRD) IR.51 “IMS over Wi-Fi”; various future variations are envisaged in 5G and other future networks.)

In relation to the examples described above, a native voice call may generally provide a better experience to the end user than transmitting and/or receiving voice over an OTT connection to a meeting session. However, transmitting and/or receiving voice over an OTT connection may provide a better user experience in some circumstances, some of which are described below.

A native cellular voice service may use a narrowband codec (e.g. an Adaptive Multi-Rate (AMR) codec). The meeting server 108 and/or the meeting app 154A, 154B may use a high-definition codecs designed for lossy Internet networks (e.g. a codec operating according to the Opus standard (as described in IETF RFC 6716, the contents of which are incorporated herein by reference). When the cellular data connection is good (or the user is in good quality Wi-Fi™ range), then OTT voice can potentially outperform voice quality offered by the native cellular network.

Even if cellular network supports a higher definition codec (e.g. an AMR-WB codec, an Enhanced Voice Services (EVS) codec), the media may get transcoded to another codec type before it reaches the meeting server 108 (e.g. due to intermediate equipment not supporting the cellular codec). Indeed, multiple such transcodings can result in the audio being severely degraded.

A native voice call may adopt a VoWi-Fi connection as a way for improving in-building coverage and/or offload traffic from congested cellular networks, in this case the native voice call may not actually receive any additional QOS from the cellular network.

The meeting server 108 and/or the meeting app 154A, 154B may offer an OTT video stream, which is transmitted as part of the non-voice meeting service data. When the voice goes through a different network path (e.g. the native voice path), then there is a greater risk that differences in end-to-end latency can cause lip-sync issues, etc.

In further examples of the present disclosure, one or more assessments of OTT voice quality and/or a native voice quality may be made to inform a decision as to which voice connection to use. The selected voice connection may then be used for the transmission of voice data by one of or both of the meeting app 154A, 154B and the meeting server. The one or more assessments may be made at the meeting server 108 and/or at the meeting app 154A, 154B. Examples of assessment are described below and may be used alone or in any combination. The one or more assessments may be made at the start of a call and/or data communications session, once during a call and/or data communications session or repeatedly during a call and/or data communications session. The decision may be made at the meeting server 108 and/or at the meeting app 154A, 154B. The decision may be made at the start of a call and/or data communications session, once during a call and/or data communications session or repeatedly during a call and/or data communications session.

The meeting server 108 and/or the meeting app 154A, 154B may perform an assessment by measuring an observed quality or qualities of the one or more data packets sent over an OTT data connection (e.g. latency, packet loss etc.)

In some examples, an assessment may be performed by the meeting server 108 and/or the meeting app 154A, 154B sending dedicated test packets over an OTT data connection and measuring an observed quality or qualities.

In some examples, an assessment may be performed by the meeting server 108 and/or the meeting app 154A, 154B measuring an observed quality or qualities of one or more packets in a meeting service data stream (e.g. a screen-sharing data stream being delivered via an OTT data connection).

In some examples, an assessment may be performed by the meeting server 108 and/or the meeting app 154A, 154B detecting which data network(s) the user terminal is connected or connectable to. For example, preferentially selecting the OTT data connection whenever the user terminal is connected or connectable to a known good Wi-Fi™ network; preferentially selecting the native voice connection when the user terminal only has access to an EDGE cellular data connection etc.

In some examples, an assessment may be performed by the meeting app 154A, 154B detecting on the user terminal the availability of one or more data networks (using information provided by the terminal's operating system to the meeting app 154A, 154B) and determining an OTT voice call quality based on the available data network(s).

In some examples, an assessment may be performed by the meeting server 108 observing an IP address of the user terminal on an OTT connection in order to determine which data network the user terminal is currently connected to and determining an OTT voice call quality based on the determined data network.

In some examples, an assessment may be performed by the meeting server 108 and/or the meeting app 154A, 154B analysing a signal received via the native voice connection and determining a native voice call quality based on the analysis. The assessment may be performed by analysing the voice signal. As well as analysing the voice signal, the assessment of the native voice connection could alternatively or additionally be performed by analysing the underlying packet stream which is used to carry the voice signal, e.g. by measuring Real-time Transport Protocol (RTP) jitter, inspecting Real-time Transport Control Protocol (RTCP) Extended Report (XR) packets (as described in IETF RFC 3611, the contents of which are incorporated herein by reference), etc.

In some examples, an assessment may be performed by the meeting server 108 and/or the meeting app 154A, 154B analysing a received voice signal by means of frequency analysis techniques, to determine whether the cellular voice connection is using a standard definition or high definition codec.

In some examples, an assessment may be performed by the meeting server 108 and/or the meeting app 154A, 154B analysing a received voice signal by comparing a voice sample in a received signal with a voice sample in a transmitted signal and detecting signal distortion (which may suggest that the native voice connection includes multiple transcoding procedures). The compared voice samples may be the same voice sample. The meeting server 108 and/or the meeting app 154A, 154B may for example make a copy of a voice sample transmitted via the native voice connection and transmit the copy to the other end via the OTT data connection, preferably without lossy compression being applied. On receipt of both samples, these may be stored and compared to determine an native voice call quality based on the comparison. Since the sample sent via the OTT data connection does not need to be played in real time to the user, it can be transported using a reliable non-real time protocol (e.g. TCP).

Having determined that an OTT voice stream provides a better experience than the cellular voice stream, the meeting server 108 and/or the meeting app 154A, 154B may release the native voice connection and then use the OTT voice part of the communications session connection.

If the communications session connection, according to subsequent assessment using one of the methods described above, later deteriorates, the cellular voice can be re-established (e.g. the meeting app 154A, 154B may trigger the establishment of a native voice call from the user terminal to the meeting server 108; the meeting server 108 triggers the establishment of a native voice call to the user terminal). Note that, in the case of re-establishment of the voice call, the user terminal may alert the user when it receives the incoming native voice call, or prompt the user if an outgoing native voice call to be made to the meeting server 108. This is to be contrasted with the manipulation of the in-progress voice call when uplift first occurs, however may be an acceptable intrusion to the user in order to improve voice quality.

In some examples of the present disclosure, both the native voice connection and the OTT voice connection may be maintained, and the meeting server 108 and/or the meeting app 154A, 154B may dynamically select which stream is transmitted from and/or played to the user (e.g. by dynamically muting the signal in/out of the meeting server 108 and/or the meeting app 154A, 154B). Although maintaining duplicate voice connections may seem to be an inefficient use of bandwidth, the impact can be mitigated by for example by using a codec featuring silence suppression or by renegotiating a media stream (e.g. by marking a RTP stream as “a=inactive” as described by IETF RFC 3264—“An Offer/Answer Model with the Session Description Protocol (SDP)”, the contents of which are incorporated herein by reference).

Whilst some of the voice calls of the present disclosure provide native voice calls between the user terminals comprising circuit-switched network connections, and/or OTT voice calls comprising OTT Voice-over IP (VoIP) connections, it should be understood that the nature of the connection between the communications server and the respective user terminals is not critical to the present disclosure. Other network connections may be used, and the limitations of one or more of the user terminals may mean that a mix of fixed networks, mobile networks and different transport technologies or applications are used to provide the respective connections between the user terminals and between the user terminals and the communications server. Furthermore, whilst a user terminal terminates both a native voice call and acts as an endpoint the communications session, the two functions could be performed on separate devices at the user end. For example, a user may use a fixed line telephone with no data capabilities, to terminate the native voice call, and a desktop computer, to act as an endpoint the communications session, in order to perform call uplift as described.

As mentioned above, a TAS may additionally provide advanced features like video telephony. In the above examples, the telephony call is a voice call. In the alternative, or additionally, the telephony call may be a video call, which may be handled natively in the cellular networks.

In the above examples, the original voice call is a two-party voice call. Alternatively, the original voice call may be a multi-party voice call.

Functionality of the present disclosure, in particular the meeting app on a user terminal, the meeting server 108, and the first and second TAS 112, 114, can be implemented on computer software by a conventional computing apparatus. Such computer software may be transmitted and installed via remote configuration, or may be accessed via download, for example via the Internet, or on some physical media, for example flash memory, etc. for which the computing apparatus has an appropriate media reader.

It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the disclosure, which is defined in the accompanying claims.

Claims

1. A method of operating a user terminal in a telecommunications network, the method comprising the steps of: establishing a telephony call between a first user, associated with the user terminal, and a remote user;conducting data communications between the user terminal and a communications server, such that the user terminal has a first connection to a communications session associated with the communications server;initiating a manipulation of the telephony call such that the telephony call forms a second connection to the communications session;maintaining both the first connection and the second connection to the communications session, for conducting communications between the first user and the remote user.

2. The method of claim 1, wherein the manipulation of the telephony call such that the telephony call forms a second connection to the communications session, comprises re-routing a call leg in the telephony call from a call control node to the communications server.

3. The method of claim 2, wherein the call leg is re-routed using a call transfer procedure under the control of the call control node in the telecommunications network.

4. The method of claim 2, wherein: the telephony call includes an initial call leg between the call control node and a remote call control node associated with the second user, and wherein, whilst the second connection is maintained, the second connection to the communications session is not connected to the initial call leg; orthe telephony call includes an initial call leg between the call control node and a remote call control node associated with the second user, and wherein, whilst the second connection is maintained, the second connection to the communications session is merged with the initial call leg.

5. The method of claim 1, wherein the manipulation of the telephony call such that the telephony call forms a second connection to the communications session, comprises establishing a new call leg in the telephony call between a call control node and the communications server.

6. The method of claim 5, wherein: the telephony call includes an initial call leg between the call control node and a remote call control node associated with the second user, and wherein, whilst the second connection is maintained, the second connection to the communications session is not connected to the initial call leg; orthe telephony call includes an initial call leg between the call control node and a remote call control node associated with the second user, and wherein, whilst the second connection is maintained, the second connection to the communications session is merged with the initial call leg.

7. The method of claim 1, comprising: initiating the transmission of an invitation message to a user terminal associated with the remote user, the invitation message inviting the second user to participate in the communications session; and/orinitiating the transmission of an invitation message to a user terminal associated with a third user, the invitation message inviting the third user to participate in the communications session.

8. A user terminal configured to perform the method of claim 1.

9. A method of controlling communications in a telecommunications network, the method comprising the steps of: conducting data communications between a communications server and a first user terminal, associated with a first user, such that the first user terminal has a first connection to a communications session associated with the communications server, wherein, prior to the data communications between the communications server and the first user terminal, an in-progress telephony call exists between the first user and a second user, associated with a second user terminal;participating in a manipulation of the telephony call such that the telephony call forms a second connection to the communications session;conducting data communications between the communications server and the second user terminal, such that the second user terminal has a third connection to the communications session; andmaintaining both the first connection and the second connection to the communications session, and the third connection to the communications session, for conducting communications between the first user and the second user.

10. The method of claim 9, comprising setting up the communications session in response to a session establishment request from the first user terminal, the session establishment request being received via a data communications link separate from the telephony call.

11. The method of claim 10, comprising receiving session control data from the first user terminal, and setting up the communications session in accordance with the first session control data.

12. The method of claim 9, comprising transmitting an invite message to the second user terminal, the invite message inviting the second user terminal to join the communications session via the third connection.

13. The method of claim 12, comprising receiving a session request from the second user terminal to initiate the establishment of the third connection, and establishing the third connection in response to the session request.

14. The method of claim 9, wherein the method comprises: establishing a further call leg with a call control node associated with the second user, in order to make the communications server a party to the telephony call via the further call leg; andassociating the further call leg with the communications session.

15. The method of claim 9, comprising: establishing a telephony communication connection with a third user terminal associated with a third user; andassociating the telephony communication connection with the communications session to establish a multi-party telephony call.

16. The method of claim 9, wherein the method comprises transmitting via the first and third connections at least one of: still image data;video image data;textual data;a data file;screen sharing data; and/orhyperlink data.

17. The method of claim 9, wherein the method comprises transmitting via the second and third connections at least voice telephony data.

18. A method comprising the steps of: conducting data communications between a communications server and a user terminal, such that the user terminal has a first connection to a communications session associated with the communications server;conducting a telephony call between the communications server and the user terminal, such that the user terminal has a second connection to the communications session;transmitting and/or receiving non-voice meeting service data between a user of the user terminal and a remote user, via the first connection; andselecting between the first connection and the second connection, for transmitting and/or receiving voice data between the user of the user terminal and the remote user.

19. A user terminal or a communications server configured to perform the method of claim 18.