The present invention relates to a method and device for tapping the payload data of multimedia connections in a packet network.
Modem communication architectures that utilize packet-based or cell-based methods such as Voice over IP (VoIP) or Voice over ATM (VoATM), for example, provide for separation of the connection control and the bearer channel control. The communication between one/a plurality of subscribers such as ISDN/PSTN subscribers, for example, routed via traditional circuit-switched telecommunication networks up to now, is then routed via IP networks. To continue to allow communication with traditional circuit-switched telecommunication networks such as PSTNs (Public Switched Telephone Networks), a “translation” between the two different transport technologies is required, which is performed in crosspoints. At such a crosspoint, the first transport technology for the payload information is converted into the second transport technology by using specific facilities designated as a Media Gateway (MG).
The Media Gateways themselves are controlled by central entities, the Media Gateway Controllers (MGC). The signaling information transmitted between two Media Gateway Controllers is transported, for example, by using a BICC protocol (Bearer Independent Call Control Protocol) or SIP/SIP-T protocol. The Media Gateway Controllers are essentially used for the coordination of the Media Gateways and monitor/control connections (bearer connections) between the Media Gateways. The control of the Media Gateways is effected, for example, with the aid of the MGCP (Media Gateway Controller Protocol) or the H.248 protocol.
In the case of packet-based connections, particularly in the case of connections routed via the IP network, the payload data stream is therefore routed direct between the subscribers or gateways involved outside the switching office. The legally prescribed possibility of tapping the payload data (Lawful Interception, LI), designated as LI for short in the following, is usually effected via a conventional interface outside the packet network, implemented in TDM technology. An outgoing call via the packet network with a pure audio connection from an A subscriber who has to be monitored is then tapped in a TDM loop. This means that a conversion to TDM must be performed first. There, the payload data is tapped, forwarded to the parties tasked in this respect (LEAs, Law Enforcement Agencies), designated as LEAs for short in the following, then converted back into the IP protocol and fed to the called subscriber (B subscriber).
The corresponding relationships are shown in
However, the double conversion of the payload data stream brings with it serious disadvantages in terms of the end-to-end quality of the payload data transmitted. This would also apply particularly to video information which would have to be tapped in the case of video telephony. Moreover, this broadband payload data (>64 kbit/s, e.g. video) does not lend itself to problem-free transfer into the narrow-band TDM network. This is another reason why TDM Gateways are not equipped with video interfaces.
In the case of video telephony, mixed audio/video payload data is produced. As soon as a mixed audio and video connection is set up in the packet network, however, the video portion/stream would have to be suppressed in the case of tapping via TDM conversion. This has a strong adverse effect on the subscriber connection (no video image), however, and the monitoring function would be detectible to the monitored subscriber. There is, therefore, de facto no longer any possibility of tapping for a potential video connection, either for audio or for video. Only statistical data and signaling data (Interception Related Information, IRI) for the call can be secured.
In practice, this means that subscribers can only be monitored while they are making telephone calls in the TDM network. Since video telephony now occupies a permanent place in the service offerings of the fixed network operators, a problem arises here for the feature LI, since the associated video payload data stream is taken away from access by the LEAs (Law Enforcement Agencies) in the packet network. In the absence of corresponding standards, the LEAs currently have no IP-based interfaces. The intended rapid and broad-based introduction of video telephony accentuates the demand position for LI in this regard.
An object underlying the invention is to disclose a way in which the feature LI can be deployed efficiently for multimedia connections.
An advantageous aspect of the invention is that the subscriber who has to be monitored does not notice the tapping of payload data, e.g. due to delays in the transmission of the payload data (lack of lip synchronization). Furthermore, the interventions in the packet-based switching system are minimal.
Thus, the logic or the switching technology of the packet-based switching system is not affected. Because of the processing of the payload data signal, existing interfaces of the LEAs can be used. The adaptations are effected in an LEA-specific manner, while the tapping and adaptation to LEA format can be effected in two stages in different facilities. This scheme also covers the serving of LEAs with new interfaces for classical TDM connections.
CallP features can also be covered with this scheme. Thus, monitoring in the case of activation of the features Call Forwarding or Call Transfer is just as possible as the monitoring of conferences
Mixed audio+video streams (e.g. coded in MPEGx) can be split, adapted to the needs of the LEAs. The audio and video signals can be transmitted in the form of two independent calls to the LEAs with conventional interfaces.
Finally, a step-by-step introduction of LEA access to the payload data of a multimedia connection is possible by adaptation of the type of payload data signal (none/audio only/video+audio, video+audio+data). The adaptation of the bandwidth of the video portion or of the overall audio+video stream is similarly possible (full bandwidth without changes, buffer storage and succeeding transmission with low bandwidth, processing and particularly compression to 64 kbit/s).
Advantageous developments of the invention are specified in the dependent claims.
In the following, the invention is explained in detail on the basis of an exemplary embodiment represented in the form of diagrams. The diagrams show:
According to the invention, a controller LICA (LI Connection Agent) and a packet multiplexer PMUX realized as a tapping device for tapping the multimedia stream are then provided. The (additional) packet multiplexer PMUX is looped into the packet data stream (payload data stream). The activation of said packet multiplexer PMUX leaves the switching software of the softswitch MGC unaffected by this. The controller LICA is realized as a pure software function unit, which is incorporated in the exchange of the IP endpoint data IP-EPD. It is located in one of the switching offices involved; but an arrangement outside the switching offices involved would be just as possible.
On the one hand, the controller LICA is in effective connection with a device LIC, which represents the LI Control. On the other hand, the packet multiplexer PMUX is activated by the controller LICA via a standard IP protocol such as H.248, for example. Furthermore, the knowledge that the feature LI is activated for at least one of the terminals is established in the controller LICA or alternatively the device LIC. The controller LICA receives this information following directory number analysis by the front-end function unit LIC or by its own activity (directory number trigger). In the latter case, the functionality of the LI Control LIC is reduced to the unconditional looping-in of a suitable LI Connection Agent LICA while taking account of the availability of LICA and packet multiplexer resources.
The controller LICA controls the data tapping transparently for the Call Agents CA. The IP endpoint data IP-EPD of the respective partner end is replaced by the IP endpoint data IP-EPD of the packet multiplexer PMUX. The payload data is therefore always routed via the packet multiplexer in the case of LI and tapped there, controlled by the controller LICA. The replacement does not affect the functionality of the Call Agents CA.
The controller LICA controls the connection of the packet multiplexer to the LEAs, which is preferably routed via an IP protocol IP-P (e.g. H.323 or SIP). If the tapping is to be effected in the TDM world (TDM LEA), the information that has to be tapped is fed via an IP protocol IP-P to a Gateway GW and from there, e.g. via a DSS1 protocol, to the LEAs.
The intervention of the controller LICA also supports switching functions (subscriber features) such as Call Forwarding or Call Transfer. All these features are handled in the usual way by the Call Agents CA. The algorithm of the IP endpoint data exchange always stays the same. This also applies to conferences, which can be monitored with the same method. In this respect, the conference point is situated in the terminal or a further facility, e.g. a central Media Server. In the case of conference functionality in the packet multiplexer, the conference point can also be situated there.
The payload data tapped in the packet multiplexer PMUX contains the audio stream and, depending on the capabilities of the LEAs, the video stream also. If only the audio portion should be required from a single data steam containing audio and video data (e.g. MPEG2 with audio+video) or if the video portion is needed separately for other technical reasons, the packet multiplexer splits the stream in the direction of the LEA (MPEG splitter). The payload data stream between the subscribers remains unaffected by this. According to the stipulations of the LEAs, the tapping is effected in such a way that the payload data stream coming from the A-end and the payload data stream coming from the B-end are forwarded separately in the direction of the LEA.
The packet multiplexer PMUX can deliver the tapped payload data in various ways depending on the requirement of the LEA:
1. Just the audio data is transmitted on two LI connections and sent to the LEA via an IP/TDM Gateway. The video data is not forwarded to the LEAs.
2. The audio data is sent to the LEA direct via a Gateway as in 1., the video data is placed in buffer storage and transmitted as TDM data to the LEA over and above the call (if the bandwidth makes this necessary) or even after the call.
3. The audio and video data is transferred to highly compressing codecs and transmitted to the LEAs direct and simultaneously as a TDM data stream or in the form of separate TDM data streams. (An example of this comprises the use of H.324M in the direction of the LEA.)
4. The audio and video data is transmitted unchanged via an IP protocol to an IP-LEA, that is to say an LEA with IP-based interfaces (SIP, H.323).
5. The adaptations to the interfaces of a plurality of LEAs can preferably be effected in a further subordinate facility for the purposes of payload data distribution. (2-stage method with tapping in a first facility and individual LEA adaptation and distribution in a second facility.) The latter possesses TDM interfaces for LEAs with conventional interfaces, or there is a further subordinate signaling and/or payload data converter (Gateway) on the route to the LEAs.
6. The adaptation to the LEA IFs is effected in an LEA-specific manner in each case, i.e. a plurality of LEAs with different interface requirements for the same call can be served in parallel.
7. A bandwidth adaptation is performed, where relevant with buffer storage.
In the present exemplary embodiment, the tapping of payload data has been shown using the example of video telephony. In this respect, just two different types of connection are involved, specifically a voice connection and a video or picture connection. Further connections, such as data connections, for example, can also be monitored with the method and the device according to the invention.
Number | Date | Country | Kind |
---|---|---|---|
10 2004 040 479.8 | Aug 2004 | DE | national |
This application is the US National Stage of International Application No. PCT/EP2005/053888, filed Aug. 8, 2005 and claims the benefit thereof. The International Application claims the benefits of German application No. 102004040479.8 DE filed Aug. 20, 2004, both of the applications are incorporated by reference herein in their entirety.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/EP2005/053888 | 8/8/2005 | WO | 00 | 7/7/2008 |