Patent ID: 12255932

REFERENCE NUMERALS USED IN THE DRAWINGS INCLUDE

1Session Recording Client1, SRC12Session Recording Client2, SRC23Session Recording Client3, SRC34Session Recording Client4, SRC45Session Recording Client5, SRC5BCF-I ingress Border Control FunctionBCF-E-1egress Border Control Function1BCF-E-2egress Border Control Function2Ingress SBC ingress Session Border ControllerESRP Emergency Service Routing ProxyPSAP Public Safety Answering PointECRF Emergency Call Routing FunctionSIP INVITE Session Initiation Protocol INVITE messageSIP200OK Session Initiation Protocol200OK messageSIP ACK Session Initiation Protocol acknowledgement, ACK, messageSIP PRACK Session Initiation Protocol pre-acknowledgement, PRACK messageSIP180Ringing Session Initiation Protocol180Ringing messagesrc_count first SRC parametersrc_contact second SRC parameterSRS Session Recording ServerUA User Agent(s)CTI Computer Telephony IntegrationSIPREC Session Recording ProtocolDNS Domain Name Systemrec recording

DETAILED DESCRIPTION

FIG.1schematically shows an overview of a recording solution according to the state of the art. In this example, the concrete context to which the recording solution is applied is a Next Generation 1-1-2 (or Next Generation 9-1-1) telephony sub-system. In the context of NG9-1-1/NG1-1-2 systems recordings are mandated to use the SIPREC (IETF RFC8766) recording protocol. The SIPREC recording protocol is based on a Client/Server architecture where the client corresponds to the device or element that is normally present in the recorded call's media path and is responsible for controlling the SIPREC session. The server typically corresponds to a SIPREC-capable recording server that receives the recorded call's media through the established SIPREC session from the client. Typically, one or more SBCs/BCFs in the domain in which the recording is needed is/are statically configured to handle all the call recordings. The latter implies that the chosen SBCs/BCFs is/are constantly taking up the complete call recording load, on top of the actual call media anchoring load, while the remaining SRC-capable components in the call path, never take up any of the call recording load and have only to deal with the call media anchoring load. This potentially decreases the call handling capacity of the recording SBCs/BCFs which constantly need to reserve CPU and memory resources to services the recordings causing an overall decrease in their call handling capacity and making them subject to overload issues. The situation is depicted inFIG.1where there is a total of four potential recording tap points (Ingress SBC, BCF-I, BCF-E-1, BCF-E-2) but only one (BCF-E-1) takes the complete recording load.FIG.1shows that the signaling from outside the emergency network to the user agent (UA) is relatively simple to understand, while the actual payload of the data is more complex.

The payload can be the part of transmitted data that is the actual intended message. Headers and metadata are sent only to enable payload delivery. Incoming multimedia calls to be recorded are received from service providers and are first aggregated and a geographic routing is performed. However, it is common that incoming multimedia calls to be recorded are first received at aggregation points. The aggregation points or centers act as interconnection or in other words traffic hand-off points between service providers and the NG9-1-1 or NG1-1-2 provider. Based on the system topology, geospatial call routing may or may not occur at those centers. It is common to provide routing redundancy to accommodate for NGCS data center failures at those aggregation points/centers. It is also common that the service provider itself already selects the aggregation center based on the caller's location. For example, an emergency call from an emergency caller at the Northern region of a state or country would typically reach an aggregation center that serves the Northern region of the state or country. The call is then routed via an Ingress SBC to the Data Center 2 determined by the geographical routing. Within the Data Center 2, the call is routed to the core services via the Ingress BCF-I. The call exits the Core Services via the egress BCF-E-1. In this example, the BCF-E-1takes over the session recording. The call exits the Data Center 2 via another BCF-E-2and is passed on to the user agents. In terms of the invention, egress means data traffic that leaves part or all of a network and ingress refers to data traffic that crosses the boundary of a network from the outside.

FIGS.2to7illustrate exemplary embodiments in the context of a Next Generation 9-1-1/1-1-2 telephony sub-system. In the context of NG9-1-1/NG 1-1-2 systems, recordings are mandated to use the SIPREC (IETF RFC8766) recording protocol. However, although the context of NG9-1-1/NG1-1-2 telephony sub-systems are used to describe the mechanics of these embodiments, the invention is not limited to only such use cases but can also be applied to general VoIP telecommunications systems that can be configured to use the SIPREC recording protocol. Furthermore, embodiments can be configured so that they can be applicable to other contexts different than call recordings.

FIG.2shows a flow chart of the invention in context of the SIPREC recording protocol. In this and the followingFIGS.2to7, the caller icon and the call taker icon stand for the beginning and the end of a telecommunications session that is to be recorded. The section of this session that is concerned with the recording scheme of the session is shown in a rectangular box that comprises the SRCs available for the scheme. Here, SIPREC SRCs initiate call recordings with the final200OK responses. It is noted that even though a description of the mechanism in terms of initial INVITE,200OK and ACK messages is provided, the scheme can be modified to use other call signalling messages. This means that an extension to this method is possible, for example, to accommodate the recordings of calls with early media (in this case different messages will be used). In essence, a form of a distributed voting scheme is used (as opposed to a centralized controller solution) that utilizes the existing SIP call signalling flow to balance the recordings among SRCs that span a call path within a domain or even across domains. The scheme can be thought of comprising of three phases. In the first phase which occurs with the initial call setup signalling (INVITE message), the SRCs implicitly state their wish to participate in the voting scheme. In this phase an already overwhelmed SRC can choose not to participate in the scheme.

During call initiation (SIP INVITE), the first SRC (1) that participates in the scheme and is capable of recording the call attaches in the signalling an src-count parameter with value 1. All downstream SRCs (2,3,4,5) that are capable of recording the call increment this src-count parameter subsequently. In the second phase, the selection of the SRC client is performed and the recording session is initiated. Each SRC will decide probabilistically to record the call and if it decides to record then will indicate this through signalling. During call answer (SIP200OK), each SRC (1,2,3,4,5) beginning from the last one (5) will decide probabilistically (e.g. with probability of 1/src-count) if it will record the call. The SRC that decides to record the call will attach in the signalling an src-contact parameter with value src=SRC contact identifier>>. All upstream SRCs that see the src-contact parameter will know that the call is being recorded by a downstream element so they will not record the call. InFIG.2the SRC2sets the <SRC contact identifier>>.

Additionally, all SRCs in the path will decrement the src-count parameter when sending downstream the SIP200OK signalling message. Consequently, when the first (recording capable) SRC handles the200OK, and if no other SRC has decided to record the call, then this SRC will record the call since the probability for doing so will be 1. The third phase ensures that all the SRCs in the call path receive the acknowledgement that a recording for the call has started. During call acknowledgement (SIP ACK), the SRC that will record the call (in this case SRC2) will insert in the SIP Signalling the same src-contact parameter with the same value src=<SRC contact identifier>>. This way all downstream elements will also be informed that an SRC will record the call. The parameters used in INVITE,200OK and/or ACK messages can be carried within an X header field or as parameters in existing header fields or the SDP, subject to implementation details. An assumption for this specific case here is that recordings are started with the200OK (e.g. no early media recordings required) but can be extended if needed. Further, it is assumed that all elements in the signalling path will proxy the messages and so the SIP ACK messages will go end to end.

FIG.3shows a flowchart of the SRCs' logic regarding the recording of a session of the flow shown inFIG.2. During call initiation (INVITE), an SRC can decide whether it should participate in or be considered for recording the session. Any SRC already under stress not wishing to participate or SRCs that do not understand signaling just pass it through. In such a case, the method according to the invention is terminated (done) for this SRC. In the event, the first SRC that participates in the scheme and can record the call attaches in the signaling an src-count parameter with value 1. All downstream SRCs that can record the call increment this src-count parameter subsequently (depicted with the “src_count++” inFIG.3). Then the SRCs awaiting the SIP200OK message. During call answer (200OK), the SRC who decides first to record the call will mark this in the signalling with an src-contact parameter. All upstream SRCs that see the src-contact parameter will know that the call is being recorded by a downstream element so they will not record the call and will wait for the ACK message. Additionally, all SRCs in the path will decrement the src_count parameter when sending downstream the SIP200OK signalling message (see “src_count-” inFIG.3.). However, if an SRC wants to draw from uniform, it first checks, if its probability to record the call is less or equal to 1/src_count. If the probability of the SRC to record the call or session is less or equal to 1/src_count is true, this SRC is obliged to record the session since there is no other SRC upstream which could do the recording. Consequently, when the first (recording capable) SRC handles the200OK, and if no other SRC has decided to record the call, then this SRC will record the call since the probability for doing so will be 1. The SRC that has decided to record the call specifies its Fully Qualified Domain Name, FQDN (see src_contact=myfqdn inFIG.3), and starts recording. However, the invention is not limited to FQDN. Other embodiments may utilize another feature as a substitute for FQDN for providing another type of identifier that identifies the specific SRC within the solution or network environment it operates in. For example, in NG9-1-1 it could also be the so-called Function Element Identifier. Also in this case, the SRC decreases the src_count parameter and then waits for the ACK message. During call acknowledgement (ACK), the SRC that is recording the call inserts in the SIP Signalling its specific src-contactparameter. This way all downstream elements will also be informed that an SRC will record the call. However, if a downstream SRC sees no contact-src parameter in ACK, it takes over to record the session.

FIG.4shows in another flowchart an example where parameters are exchanged before a dialog is established using the PRACK SIP method. The scheme can also be thought of comprising of three phases. In the first phase which occurs with the initial call setup signaling (INVITE message), the SRCs implicitly state their wish to participate in the voting scheme. In this phase, an already overwhelmed SRC can choose not to participate in the scheme. During call initiation (SIP INVITE), the first SRC (1) that participates in the scheme and is capable of recording the call attaches in the signaling an src-count parameter with the value 1. All downstream SRCs (2,3,4,5) that are capable of recording the call increment this src-count parameter subsequently. In the second phase, the selection of the SRC is performed. Each SRC will decide probabilistically to record the call and, if it decides to record, then will indicate this through signaling. During SIP180Ringing, each SRC (1,2,3,4,5) beginning from the last one (5) will decide probabilistically (e.g. with probability of 1/src-count), if they will record the call. The SRC that decides to record the call will attach in the signaling an src-contact parameter with value src=<<SRC contact identifier>>. All upstream SRCs that see the src-contact parameter will know that the call will be recorded by a downstream element so they will not record the call. InFIG.4, the SRC (2) sets the <<SRC contact identifier>>. Additionally, all SRC in the path will decrement the src-count parameter when sending downstream the180Ringing message. Consequently, when the first (recording capable) SRC handles the180Ringing message, and if no other SRC has decided to record the call, then this SRC will record the call since the probability for doing so will be 1. The third phase ensures that all the SRCs in the call path receive the pre-acknowledgement PRACK that a recording for the call has started. During call pre-acknowledgement (SIP PRACK), the SRC that will record the call (in this case SRC2) will insert in the SIP Signaling the same src-contact parameter with the same value src=<<SRC contact identifier>>. This way, all downstream elements will also be informed that an SRC will record the call. The parameters used in INVITE,180Ringing and/or PRACK messages can be carried within an X header field or as parameters in existing header fields or the SDP, subject to implementation details. Assumptions for this specific case here are that recordings are started with the provisional response (180Ringing,183Progress, etc.), SDP information is included in the message and that the PRACK method is supported. However, the method described herein is applicable to any valid signaling messages prior to the media stream initiation between the call parties. For environments where only proxies are used, the only requirement is that the information included in the signaling is carried throughout the domain of interest. For environments where B2BUAs are included, additional messages, e.g. SIP UPDATE/200OK, can be used.

Further, it must be noted that it is assumed that all elements in the signaling path will proxy the messages and so the SIP PRACK messages will go end to end. Further, a SIP200OK response would follow the SIP PRACK, however, no special handling is required.

FIG.5aandFIG.5bshow the error handling capabilities that can be utilized in upstream and downstream directions.FIG.5aandFIG.5bare based on the sequences shown inFIG.2andFIG.3, which is why the description of these figures can be referred to.FIG.5ashows an example scenario of error handling in the upstream direction, where failure handling is indistinguishable from the normal voting scheme in the upstream direction. In this example scenario, SRC3wants to take over the recording during the SIP200OK message but fails. Therefore, no src-contact parameter is passed to the upstream SRCs. Since SRC1cannot find an src-contact parameter in the ACK message, it will try to take over the recording. If SRC1can start the recording successfully, the downstream SRCs will be informed in the ACK message using the src-contact=src-1parameter. If SRC1cannot start the recording for some reason, the second SRC in the row (downstream) will not receive an src-contact parameter with the ACK message (seeFIG.5b). This causes SRC2to try to take over the recording and, if this is successful, the other SRCs downstream are informed via the ACK message which should now have the src-contact=src-2parameter. If this also fails, the third SRC3in the chain will try to take over the recording and so on. At the implementation level the mechanism uses two signalling parameters. The first signalling parameter is a counter incremented by SRCs participating in the scheme that are in the call path. This counter is also used for calculating the probability of an SRC recording a call. The second signalling parameter acts as an acknowledgement and is signalled when a recorder decides to record the call. This type of configuration can provide an advantage in that it can be guaranteed that a recording will happen as long as there is at least one functional SRC client in the call path and the communication link between it and the underlying SRS (Session Recording Server) is up. The scheme can be robust to errors and, at a minimum, does not do worse than existing schemes where, in the case of a recording initiation failure (for example, because of a temporary network connectivity issue), the call is not recorded at all. If the signalling path of a call fails, then there may potentially be more severe problems with the call itself, let aside the recording. The chance of a call failing can be reduced by utilization of one or more redundant nodes so that in the case of the primary node failure, the secondary (or backup node) takes over. Embodiments can be configured to sustain such an architecture.

In the previous examples, it was assumed that all elements in the signalling path will proxy the messages and so the SIP ACK or PRACK messages will go end to end.FIG.6considers a different scenario where a back-to-back user agent (B2BUA) is used in the path and SIP ACK or PRACK messages do not go from end to end but are initiated by the B2BUA element. However, in this case an additional SIP message like a SIP UPDATE or a SIP INFO can be used to notify all downstream participants. A B2BUA is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behaviour.

It should be appreciated that different devices of the exemplary embodiments are machines that include a processor connected to a non-transitory memory. Examples of such machines include SBCs, SRCs, proxy servers, PSAPs, ESRPs, caller devices and call taker devices.

It should be noted that the term “comprising” does not exclude other elements or steps and the “a” or “an” does not exclude a plurality. Further, elements described in association with different embodiments may be combined.

It should also be noted that reference signs in the claims shall not be construed as limiting the scope of the claims.

It should be appreciated that different embodiments of the method, communication system, and communication apparatus can be developed to meet different sets of design criteria. For example, the particular type of network connection, server configuration or client configuration for a device for use in embodiments of the method can be adapted to account for different sets of design criteria. As yet another example, it is contemplated that a particular feature described, either individually or as part of an embodiment, can be combined with other individually described features, or parts of other embodiments. The elements and acts of the various embodiments described herein can therefore be combined to provide further embodiments. Thus, while certain exemplary embodiments of a telecommunication apparatus, telecommunication device, terminal device, a network, a server, a communication system, and methods of making and using the same have been shown and described above, it is to be distinctly understood that the invention is not limited thereto but may be otherwise variously embodied and practiced within the scope of the following claims.