Patent Description:
Rich Communication Suite (RCS) is a communication protocol between mobile telephone carriers and between phone and carrier. The global system for mobile communications (GSM) association (GSMA) controls the development of RCS and a desired goal of RCS is the replacement of short message service (SMS) messages with a text message system that is richer, a system that provides phonebook polling (for service discovery) as well as transmission of in-call multimedia such as audio, images and video sequences.

RCS messaging was launched in <NUM>, but full adoption has since then stalled and has yet to take off, but since Google has decided to adopt RCS as an alternative to the iMessage® service provided by Apple®, it promises to upgrade today's business about messaging and to rapidly grow. The main RCS services are message session relay protocol (MSRP) <NUM>-<NUM> chat, group chat and file transfer.

For RCS, the base network element is the Internet protocol multimedia subsystem (IMS) core system which enables peer-to-peer communication between RCS clients and uses session initiation protocol (SIP) and MSRP as protocols for signalling and media, respectively.

There are some SIP communications that do not require a session establishment (e. g, SMS over IMS), but most of the IMS/SIP based communication (e.g. voice over long term evolution (VoLTE), video, file transfer etc.) are taking place in sessions. For RCS the GSMA, has defined (in the official document RCC. <NUM> - "Rich Communication Suite <NUM> Advanced Communications Services and Client Specification") two modes for delivering messages:.

Depending on the mode used in a service, specific SIP messages can be used (e.g. SIP INVITE is used in session mode messaging and the MESSAGE in pager mode messaging).

Instant messaging (IM) sessions (i.e. chat) require the "session-mode messaging" and the contents of the messages are carried using MSRP (see request for comments (RFC) <NUM>). To achieve this, a SIP session is established between the interested parties (sender and all receivers) with MSRP as the media component. All data communications during IM sessions should be transmitted using MSRP, regardless of the size of individual messages, but most communication terminals use the "early media" mode (as defined in RFC3960) to include the message content within the SIP signalling (e.g. SIP INVITE) before the MSRP session is established (see RFC <NUM>).

From an LI perspective, at present, there is no specific LI standard for the interception of RCS services and then this service is intercepted as a generic application within the IMS domain. The main referenced standards for LI interception in IMS domain are the technical specification <NUM> by the third generation partnership project (3GPP), the <NUM>-<NUM> specification by the European telecommunications standards institute (ETSI) and the alliance for telecommunications industry solutions (ATIS) specification <NUM>.

The current LI standards used to intercept in the IMS domain do not take in consideration the current implementations of the RCS in the network and of communication terminals using the "early media" mode (RFC3960); in fact at present they require the delivering of intercepted signalling over the HI2 interface and intercepted traffic over the HI3 interface. The delivery of call content (CC) over HI2 is foreseen only in some special cases, e.g. SMS over IMS where the message content is carried inside the SIP signalling.

During test deployment of RCS it has been experienced that the "early media mode" is often used (e.g. in IM communications) and due to that the content of chats (usually exclusively handled as CC) is spread on both HI2 and HI3. In fact, it has been found that some message content intercepted within one and the same session is retrieved from the SIP messages (e.g. INVITE) and delivered to the law enforcement agency (LEA) via the HI2 interface, while some other message content is intercepted over the MSRP traffic and delivered to the LEA via the HI3 interface. In particular, a SIP message may carry the encapsulated message content of a chat (e.g. text, audio, emoji) in the final section of Message/CPIM body (see RFC <NUM>).

Example: Alice is inviting Bob to an IM session (session mode messaging) and the early media mode is used. The first SIP INVITE carries the text "hello Bob" inside the body of the message/common profile for instant messaging (CPIM) part. An example of how LI functionality reports the SIP INVITE to the LEA may be illustrated in the following table:.

That is, as exemplified in the table, all the SIP messages (including the SIP INVITE message containing text "hello Bob") exchanged between endpoints during the IM channel negotiation are delivered over the HI2 interface and the contents of the MSRP session established after the SIP session is up is delivered over the HI3 interface.

This behaviour produces a big processing effort for the LEA because the LEA has to correlate and assemble the whole call content by getting part of it via the HI2 and the other part via the HI3 despite the fact that the contents received via the HI2 and the HI3 interfaces belong to the same session. Consequently, service providers will complain about the great complexity of the work needed in order to provide evidence of what has been delivered to the LEA, also because statistics reporting associated with distinct counters for HI2 (that should carry IRI only) and HI3 (that should carry CC only) are no longer valid since part of CC is delivered over HI2. <CIT> discloses the use of lawful interception in for instance IMS when packets contain a mix of signaling and content. It does however not disclose the use of MF2/DF2 to determine that intercepted messages comprise early media content associated with RSC traffic.

In view of the above, an object of the present disclosure is to overcome drawbacks related to lawful interception in an RCS context.

This object is achieved in a first aspect by a method performed by a LI mediation system in a communication system, the mediation system comprising a mediation and delivery function for intercept related information (MF2/DF2) and a mediation and delivery function for call content (MF3/DF3). The method comprises receiving, by the MF2/DF2 from an intercept access point (IAP) in an RCS network element (NE), an intercepted message. The MF2/DF2 determines that the intercepted message comprises SIP early media content associated with RCS traffic, and as a consequence:.

That is, such a method identifies the early media content in RCS traffic and provides the whole CC on the HI3 interface to the LEA. This is advantageous at least in that it enables the LEA to use fewer resources for collating the intercepted content of an RCS session. This advantage is further accentuated when considering various embodiments that involve identifying the "early media mode" in an RCS service, extracting the message content from the intercepted SIP messages carrying it and building an "artificial" MSRP packet and send it to the LEA over the HI3 interface. The artificial MSRP packet may be identifiable by a new flag put in the HI3 header and named, e.g.,.

ContentExtractedFromSipMessage. The original SIP message carrying the content of communication is still sent to the LEA but it may be marked with a new flag, e.g., ContentDuplicated-onHI3, to inform the LEA that a copy of it has been also delivered over HI3. In this way the LEA receives all the CC over the HI3 interface and the LEA is informed that there may be an "artificial" HI3 packet by checking the new "optional" flags introduced over HI2 and HI3. In this way the LEA may discard the message content received over HI2 and instead obtaining the whole content of the RCS session via the HI3 interface only. The optionality of these flags will allow the LEA to interwork with LI mediation systems that do not implement the method as disclosed herein and thereby assuring backward compatibility. In other words, various embodiments may be summarized as follows:
The determination by the MF2/DF2 that the intercepted message comprises SIP early media content associated with RCS traffic may comprise determining that the intercepted message is a SIP INVITE message, determining that the SIP INVITE message comprises session description protocol (SDP) data, determining that the SDP data comprises a MSRP media description and determining that a content type of the SIP INVITE message is CPIM.

Some embodiments comprises storing, by the MF2/DF2, as a consequence of the determination that the intercepted message comprises SIP early media content associated with RCS traffic, the SIP early media content having the CPIM content type and at least part of the SDP data.

In some embodiments, the transmission of the intercepted SIP INVITE message by the MF2/DF2 via the HI2 interface to the LEA may comprise transmission of information that specifies that content of the intercepted message is provided to the LEA also via the HI3 interface from the MF3/DF3.

In various embodiments, the MF3/DF3 performs:.

In various embodiments, the creation of the MSRP packet may comprise inclusion of early media content obtained from stored CPIM content. In such embodiments the creation of the MSRP packet may comprise inclusion of any of the SDP media descriptions m, c and a, as well as inclusion of a session identity.

In various embodiments, the HI3 packet may comprise information that specifies that the SIP early media content originates in a SIP message, and in various embodiments the HI3 packet may comprise information that specifies that the MSRP packet is created by the MF3/DF3.

In a further aspect there is provided a computer system of a communication system. The computer system is configured to communicate with a LEA and an IAP and comprises an MF2/DF2 and an MF3/DF3. The computer system comprises a plurality of server blades, each server blade comprising a processor and a memory. The memory contains instructions executable by the processor whereby the computer system is operative to perform a method according to the first aspect.

In yet a further aspect there are provided a computer program comprising instructions which, when executed on at least one processor in a server blade in a computer system of a communication system, wherein the computer system is configured to communicate with a LEA and an IAP and comprises an MF2/DF2 and an MF3/DF3, cause the computer system to carry out a method according to the first aspect. In yet a further aspect there is provided a carrier comprising such a computer program, wherein the carrier is one of an electronic signal, an optical signal, a radio signal and a computer readable storage medium.

These further aspects and embodiments of these further aspects provide the same effects and advantages as summarized above in connection with the method of the first aspect.

<FIG> schematically illustrates a first functional representation of a communication system <NUM> comprising an IMS <NUM> and entities involved in lawful interception as summarized above. In some more detail, the IMS <NUM> is connected to two access networks: a radio access network (RAN) <NUM>, e.g. any 3GPP RAN, and a local area network (LAN) that may include a wireless LAN <NUM> that operates according to, e.g. an institute of electrical and electronics engineers (IEEE) <NUM> standard. The access networks <NUM>, <NUM> are connected to the IMS <NUM> via interface functionality <NUM>, <NUM> in appropriate gateway nodes that are not illustrated in <FIG>. A first communication unit <NUM> is connected via an air interface <NUM> to the RAN <NUM> and a second communication unit <NUM> is connected to the LAN <NUM> via an appropriate connection interface <NUM>.

An LI mediation system <NUM>, connected to the IMS <NUM>, comprises lawful interception mediation functionality in the form of an MF2/DF2 for intercept related information and an MF3/DF3 for call content that communicate with a LEA <NUM> for performing lawful interception of RCS traffic (as well as, e.g., telephone calls and other types of media sessions) involving, e.g., the communication units <NUM> and <NUM>. The IMS <NUM> comprises at least one RCS network element (NE) <NUM> that provides appropriate RCS functionality to the communication units <NUM>, <NUM>. In order to enable lawful interception of RCS (and other) traffic, the RCS NE <NUM> comprises an intercept access point (IAP) <NUM> that is configured to communicate with the LI mediation system <NUM>. An LI administrative function (ADMF) <NUM> is configured to communicate with the LEA <NUM> and the IAP <NUM>.

Signalling between the entities in the IMS <NUM> and the connected entities takes place by means of SIP signalling and associated SDP data. The IAP <NUM> in the RCS NE <NUM> in the IMS <NUM> interfaces with the mediation system <NUM> via an X2 interface and via an X3 interface, and the mediation function <NUM> interfaces with the LEA <NUM> via an HI2 interface and via an HI3 interface. The ADMF <NUM> interfaces with the IAP <NUM> via an X1 interface and interfaces with the LEA <NUM> via an HI1 interface.

As the skilled person realizes, the IMS <NUM> typically comprises a plurality of functional entities such as a proxy call/session control functions (P-CSCF) <NUM> and a serving call/session control function (S-CSCF) <NUM> etc. that may interact within the IMS <NUM> as well as interact with the mediation function <NUM>, the RAN <NUM> and the LAN <NUM>. Detailed description of how these functional entities <NUM>, <NUM> operate, and interface functionality indicated by reference numerals <NUM> and <NUM> are outside the scope of the present disclosure.

Typical implementations of an IMS and the connected functional entities, including the mediation system <NUM>, may in various embodiments realize the entities in a larger and more general processing system, e.g. in the form of one or more computer servers (e.g. a so-called cloud implementation) having functional blocks that operate to realize functionality of the IMS <NUM> as well as the mediation system <NUM>. <FIG> schematically illustrates such a cloud implemented functional representation of the communication system <NUM>. In this functional representation, the communication system <NUM> is realized at least in part by virtualized functions that are executed on virtual nodes <NUM> that utilize a hardware server platform <NUM>.

The P-CSCF <NUM>, the S-CSCF <NUM>, the RCS NE <NUM> with the included IAP <NUM>, the ADMF <NUM>, the MF2/DF2 <NUM> and the MF3/DF3 <NUM> are realized in a functional layer <NUM> of virtualized network functions (VNF) that execute in the virtual nodes <NUM> via a virtualization layer <NUM>. The communication units <NUM>, <NUM> are connected to the hardware platform <NUM> via the RAN <NUM> and the LAN <NUM>, respectively. The LEA <NUM> is connected to the hardware platform <NUM>, the details of which are outside the scope of the present disclosure.

The RCS NE <NUM> with the included IAP <NUM>, the ADMF <NUM>, the MF2/DF2 <NUM> and the MF3/DF3 <NUM>, as well as the LEA <NUM> all comprise processing and storage resources that are configured to realize and handle LI in a RCS context as will be exemplified in detail below. That is, communication units in the communication system <NUM> such as the communication units <NUM> and <NUM> may be a target of lawful interception when operating in an RCS context, as requested by the LEA <NUM>. In such cases, the ADMF <NUM>, having received the request for LI from the LEA <NUM>, sends an interception order for the requested target to the IAP <NUM> in the RCS NE <NUM>, whereupon LI of RCS traffic takes place as will be discussed further below.

Turning now to <FIG>-c, and with continued reference to <FIG> and <FIG>, embodiments of methods related to LI in a RCS context will be described in detail. The embodiments comprise a number of actions performed by the LI mediation system <NUM> comprising the MF2/DF2 <NUM> and the MF3/DF3 <NUM> introduced and described above in connection with <FIG> and <FIG>:.

The MF2/DF2 <NUM> receives, from the IAP <NUM> in the RCS NE <NUM>, an intercepted message.

As will be schematically illustrated below, the IAP <NUM> has been ordered by the ADMF <NUM> to perform LI of RCS traffic and provides the intercepted messages to the MF2/DF2, the details of which is outside the scope of the present disclosure.

The MF2/DF2 <NUM> determines that the intercepted message comprises SIP early media content associated with RCS traffic, and as a consequence performs the following actions:.

The MF2/DF2 <NUM> transmits, via the HI2 interface to the LEA <NUM>, the intercepted message.

The transmission of the intercepted message by the MF2/DF2 <NUM> via the HI2 interface to the LEA <NUM> may comprise transmission of information that specifies that content of the intercepted message is provided to the LEA <NUM> also via the HI3 interface from the MF3/DF3 <NUM>.

The MF2/DF2 <NUM> transmits the SIP early media content to the MF3/DF3 <NUM>.

The MF3/DF3 <NUM> transmits, via the HI3 interface to the LEA <NUM>, the SIP early media content.

The determination in action <NUM> by the MF2/DF2 <NUM> that the intercepted message comprises SIP early media content associated with RCS traffic may comprise:.

Determining that the intercepted message is a SIP INVITE message.

Determining that the SIP INVITE message comprises SDP data.

Determining that the SDP data comprises an MSRP media description.

Determining that a content type of the SIP INVITE message is CPIM.

As indicated in <FIG>, if any of the determinations <NUM>, <NUM>, <NUM> is negative, then the MF2/DF2 continues with normal operations. For example, formatting and delivering the received message to the LEA <NUM> according to the LI standard, the details of which is outside the scope of the present disclosure.

As a consequence of the determination that the intercepted SIP INVITE message comprises SIP early media content associated with RCS traffic, the MF2/DF2 <NUM> may in various embodiments perform:.

Preparing an object that comprises the intercepted SIP INVITE message. The object may comprise information that specifies that content of the intercepted SIP INVITE message is provided to the LEA <NUM> also via the HI3 interface from the MF3/DF3 <NUM>. For example, a parameter "ContentDuplicated-onHI3=true" may be included.

The object that was prepared as described in connection with action <NUM> is then transmitted to the LEA <NUM> via the HI2 interface.

Storing the SIP early media content having the CPIM content type and at least part of the SDP data. Any of the SDP media descriptions m, c and a of the SIP INVITE message as well as a session identity may be stored.

It is to be noted that it is assumed that the session identity is available and that any mechanism for calculating or obtaining the session identity are outside the scope of the present disclosure.

Having received and processed an SIP INVITE message as described above, further SIP messages may then be received and processed as follows:.

The MF2/DF2 <NUM> receives, from the IAP <NUM>, an intercepted SIP <NUM> OK message.

Having determined, in action <NUM> that the message is not a SIP INVITE message, the MF2/DF2 <NUM> determines that a session identity of the intercepted SIP <NUM> OK message is equal to a session identity of the intercepted SIP INVITE message, and as a consequence performs the following actions:.

The MF2/DF2 <NUM> transmits the intercepted SIP <NUM> OK message via the HI2 interface to the LEA <NUM>.

The MF2/DF2 <NUM> obtains the SIP early media content having the CPIM content type and said at least part of the SDP data that was stored by the MF2/DF2 <NUM> in action <NUM>. Any of the SDP media descriptions m, c and a of the SIP INVITE message as well as a session identity may be obtained.

The MF2/DF2 <NUM> transmits the SIP early media content to the MF3/DF3 <NUM>, said transmission including said at least part of the SDP data.

For example, the transmission may be in the form of an object that comprises the information obtained as described in connection with action <NUM>.

As indicated in <FIG>, if the determination <NUM> is negative, then the MF2/DF2 continues with normal operations. For example, formatting and delivering the received message to the LEA <NUM> according to the LI standard, the details of which is outside the scope of the present disclosure.

As illustrated in <FIG>, the MF3/DF3 <NUM> may perform a number of actions:.

The MF3/DF3 <NUM> receives, from the MF2/DF2 <NUM>, an object that comprises the SIP early media content. The received object may comprise further data as will be exemplified below.

The MF3/DF3 <NUM> creates an MSRP packet comprising the received SIP early media content. The MSRP packet may comprise further data such as SDP data obtained from the at least part of the SDP data that has been stored as described in connection with action <NUM>. For example, the creation of the MSRP packet may comprise inclusion of any of the SDP media descriptions m, c and a and inclusion of a session identity.

The MF3/DF3 <NUM> creates an HI3 packet comprising the created MSRP packet. The transmission in action <NUM> of the SIP early media content by the MF3/DF3 <NUM> to the LEA <NUM> then comprises transmission of the created HI3 packet.

Various embodiments include those where the HI3 packet created as described in connection with action <NUM> comprises information that specifies that the SIP early media content originates in a SIP INVITE message. For example, a parameter "ContentExtractedFromSipMessage=true" may be included.

Various embodiments include those where the HI3 packet created as described in connection with action <NUM> comprises information that specifies that the MSRP packet is created by the MF3/DF3. In other words, such information conveys the fact that the HI3 packet is an "artificial" HI3 packet.

As <FIG> illustrates, in order to create the MSRP packet as described in connection with action <NUM>, the MF3/DF3 <NUM> may perform the following actions <NUM>-<NUM>:.

The MF3/DF3 <NUM> extracts data from the object received from the MF2/DF2 <NUM>. The extracted data may comprise SDP media descriptions m, c and a of the intercepted SIP INVITE and the <NUM> OK messages as well as a session identity.

The MF3/DF3 <NUM> then builds a to-path using the uniform resource identifier (URI) of the a line, if available, or a c and m line of the intercepted SIP <NUM> OK message received as described in connection with action <NUM>. The to-path may then be included in the MSRP packet that is created as described in action <NUM>.

The MF3/DF3 <NUM> then builds a from-path using the MSRP URI of the a line, if available, or a c and m line of the intercepted SIP INVITE message received as described in connection with actions <NUM> and <NUM>. The from-path may then be included in the MSRP packet that is created as described in action <NUM>.

Turning now to <FIG>, and with continued reference to <FIG> and <FIG>, a LI scenario in a RCS context is illustrated in the form of a signalling diagram where a sequence (time increasing downwards) of message transmissions are illustrated as arrows.

The LI scenario commences by a transmission <NUM> from the LEA <NUM> to the ADMF <NUM>. The transmission <NUM> comprises a warrant for LI of a specified target, for example the any of the communication units <NUM> and <NUM>.

The ADMF <NUM> then communicates with the IAP <NUM> in the RCS NE107 by generating a transmission <NUM> comprising a target activation request and subsequently receiving from the IAP <NUM> a target activation response transmission <NUM> that comprises a confirmation that LI is activated for the specified target.

At some point in time, the specified target, e.g. the first communication unit <NUM>, initiates a RCS chat with, e.g., the second communication unit <NUM>. In order to initiate the RCS chat an MSRP session setup sequence <NUM> takes place during which SIP signalling takes place between the involved entities. Details regarding such signalling are outside the scope of the present disclosure.

Due to the fact that LI has been activated, the SIP messages that are transmitted during the MSRP session setup sequence <NUM> are intercepted by the IAP <NUM> and conveyed to the LEA <NUM> as illustrated. That is, an intercepted SIP INVITE message (comprising early media content as discussed above) is provided by the IAP <NUM> to the MF2/DF2 <NUM> in a transmission <NUM> (corresponding to action <NUM> as described above), whereupon the MF2/DF2 <NUM> conveys the SIP INVITE message to the LEA <NUM>, including the parameter "ContentDuplicated-onHI3=true", in a transmission <NUM> (corresponding to action <NUM> as described above).

Subsequent intercepted SIP messages during the MSRP session setup sequence <NUM> include messages such as "<NUM> trying", "<NUM> Ringing" and "<NUM> OK" (corresponding to action <NUM> as described above). These SIP messages are conveyed via the MF2/DF2 <NUM> to the LEA <NUM> in the form of a plurality of transmissions <NUM> and <NUM>, respectively, among which transmission of a "<NUM> OK" message is denoted <NUM> and <NUM>.

As discussed above, once the MSRP session is setup, as confirmed by the "<NUM> OK" message (as determined in actions <NUM> and <NUM> as described above), the MSRP session (i.e. the RCS chat) <NUM> commences.

The obtained (in action <NUM> as described above) SIP early media content having the CPIM content type and said at least part of the SDP data is provided by the MF2/DF2 <NUM> to the MF3/DF3 <NUM> in a transmission <NUM> (corresponding to action <NUM> as described above).

The object received by the MF3/DF3 <NUM> from the MF2/DF2 <NUM> in transmission <NUM> is then processed, e.g. as described above in connection with actions <NUM>-<NUM>. The HI3 packet resulting from this processing by the MF3/DF3 <NUM>, comprising the early media content and further data such as the parameter "ContentExtractedFromSipMessage=true" , is then provided by the MF3/DF3 <NUM> to the LEA <NUM> in a transmission <NUM> (corresponding to action <NUM> as described above).

The MSRP session <NUM> then continues and RCS traffic in the form of, e.g., media content intercepted by the IAP <NUM> is conveyed via the MF3/DF3 <NUM> to the LEA <NUM> as exemplified by transmissions <NUM> and <NUM>.

Turning now to <FIG>, and with continued reference to <FIG>, a computer system <NUM> will be described in some more detail. The computer system <NUM>, which may correspond to at least part of the communication system <NUM>, comprises a plurality of server blades <NUM> that comprise a processor <NUM> and a memory <NUM>. The memory <NUM> contains instructions executable by the processor <NUM> whereby the computer system <NUM> is operative, as an MF2DF2 and an MF3/DF3, to:.

The instructions that are executable by the processor <NUM> may be software in the form of a computer program <NUM>. The computer program <NUM> may be contained in or by a carrier <NUM>, which may provide the computer program <NUM> to the memory <NUM> and processor <NUM>. The carrier <NUM> may be in any suitable form including an electronic signal, an optical signal, a radio signal or a computer readable storage medium.

In some embodiments, the computer system <NUM> is operative to:.

In some embodiments, the computer system <NUM> is operative such that the transmission of the intercepted SIP INVITE message by the MF2/DF2 via the HI2 interface to the LEA comprises transmission of information that specifies that content of the intercepted message is provided to the LEA also via the HI3 interface from the MF3/DF3.

In some embodiments, the computer system <NUM> is operative such that the creation of the MSRP packet comprises inclusion of early media content obtained from the stored (<NUM>) CPIM content.

In some embodiments, the computer system <NUM> is operative such that the creation of the MSRP packet comprises inclusion of any of the SDP media descriptions m, c and a and inclusion of a session identity.

In some embodiments, the computer system <NUM> is operative such that the HI3 packet comprises information that specifies that the SIP early media content originates in a SIP message.

In some embodiments, the computer system <NUM> is operative such that the HI3 packet comprises information that specifies that the MSRP packet is created by the MF3/DF3.

Turning now to <FIG>, and with continued reference to <FIG>, a computer system <NUM> will be described in some more detail. The computer system <NUM> comprises:.

Claim 1:
A method performed by a lawful interception, LI, mediation system (<NUM>) comprising a mediation and delivery function for intercept related information, MF2/DF2 (<NUM>) and a mediation and delivery function for call content, MF3/DF3 (<NUM>), in a communication system (<NUM>), the method comprising:
- receiving (<NUM>, <NUM>), by the MF2/DF2 (<NUM>) from an intercept access point, IAP, (<NUM>) in a rich communication suite, RCS, network element, NE, (<NUM>), an intercepted message,
- determining (<NUM>), by the MF2/DF2 (<NUM>), that the intercepted message comprises session initiation protocol, SIP, early media content associated with RCS traffic, and as a consequence:
- transmitting (<NUM>, <NUM>), by the MF2/DF2 (<NUM>) via an HI2 interface to a law enforcement agency, LEA (<NUM>), the intercepted message,
- transmitting (<NUM>, <NUM>), by the MF2/DF2 (<NUM>) to the MF3/DF3 (<NUM>), the SIP early media content, and
- transmitting (<NUM>, <NUM>), by the MF3/DF3 (<NUM>) via an HI3 interface to the LEA (<NUM>), the SIP early media content.