METHOD AND TELECOMMUNICATIONS ARRANGEMENT FOR TRANSFERRING MEDIA DATA HAVING DIFFERING MEDIA TYPES VIA A NETWORK SENSITIVE TO QUALITY OF SERVICE

Abstract

The invention concerns a telecommunication system (10) and a computer-implemented method for transferring media data from a first RTC client (30) over a QoS-sensitive network (N1) using the real-time protocol (RTP) to a second RTC client (40), wherein the quality of service is based on different traffic classes and the media data contain a first media type with a first traffic class (QoS1) and a second media type with a second traffic class (QoS2), comprising the following steps: media data, which contain a first media type with a first traffic class (QoS1) and a second media type with a second traffic class (QoS2), are bundled by the first RTC client (30) into second packets (P2), in each second packet (P2), the traffic class (QoS1, QoS2) for each media type is marked in layer 4 and/or layer 5 of the real-time protocol (RTP), the second packets (P2) are transmitted in the direction of the second RTC client (40), either before or during the transfer to the network (N1), the second packets (P2) are unbundled using the markings in layer 4 and/or layer 5 of the real-time protocol (RTP) and then bundled into first packets (P1), each of which has only one of the traffic classes (QoS1, QoS2), and the first packets (P1) are transmitted over the network (N1) to the second RTC client (40).

Claims

1-10. (canceled)

11. A computer-implemented method for transferring media data, the method comprising: marking, in second data packets, different traffic classes in a header of a real-time protocol (RTP) element to generate marked second packets; unbundling the marked second packets using the different traffic classes to generate unbundled second packets; bundling the unbundled second packets into first data packets; and transmitting the first data packets.

12. The computer-implemented method of claim 11, wherein marking comprises extending the header of the RTP element of the second data packets.

13. The computer-implemented method of claim 12, wherein extending the header further comprises including a list of markings of the different traffic classes.

14. The computer-implemented method of claim 11, wherein marking comprises changing the different traffic classes from a layer 2 or a layer 3 of the RTP to a layer 4 or layer 5 of the RTP.

15. The computer-implemented method of claim 11, wherein marking comprises marking the second data packets with a worst Differentiated Services Code Point (DSCP) value.

16. The computer-implemented method of claim 11, wherein marking comprises marking the second data packets with an Assured Forwarding Codepoint.

17. The computer-implemented method of claim 11, further comprising: negotiating a port multiplexing or a service multiplexing.

18. A non-transitory, computer-readable medium, storing instructions that, when executed by a processor, cause: marking, in second data packets, different traffic classes in a header of a real-time protocol (RTP) element to generate marked second packets; unbundling the marked second packets using the different traffic classes to generate unbundled second packets; bundling the unbundled second packets into first data packets; and transmitting the first data packets.

19. The non-transitory, computer-readable medium of claim 18, wherein marking comprises extending headers of RTP protocol elements of the second data packets.

20. The non-transitory, computer-readable medium of claim 19, wherein extending the headers further comprises including a list of markings of the different traffic classes.

21. The non-transitory, computer-readable medium of claim 18, wherein marking comprises changing the different traffic classes from a layer 2 or a layer 3 of the RTP to a layer 4 or layer 5 of the RTP.

22. The non-transitory, computer-readable medium of claim 18, wherein marking comprises marking the second data packets with a worst Differentiated Services Code Point (DSCP) value.

23. The non-transitory, computer-readable medium of claim 18, wherein marking comprises marking the second data packets with an Assured Forwarding Codepoint.

24. The non-transitory, computer-readable medium of claim 18, storing further instructions that, when executed by the processor, further cause: negotiating a port multiplexing or a service multiplexing.

25. A multimedia system, comprising: a processor; a memory operatively connected to the processor and storing instructions that, when executed by the processor, cause: marking, in second data packets, different traffic classes in a header of a real-time protocol (RTP) element to generate marked second packets; unbundling the marked second packets using the different traffic classes to generate unbundled second packets; bundling the unbundled second packets into first data packets; and transmitting the first data packets.

26. The multimedia system of claim 25, wherein marking comprises extending headers of RTP protocol elements of the second data packets.

27. The multimedia system of claim 26, wherein extending the headers further comprises including a list of markings of the different traffic classes.

28. The multimedia system of claim 25, wherein marking comprises changing the different traffic classes from a layer 2 or a layer 3 of the RTP to a layer 4 of the RTP.

29. The multimedia system of claim 25, wherein marking comprises marking the second data packets with a worst Differentiated Services Code Point (DSCP) value.

30. The multimedia system of claim 25, wherein marking comprises marking the second data packets with an Assured Forwarding Codepoint.

Description

[0032] Additional advantages, features, and characteristics of the present invention are presented in the following description of advantageous embodiments with reference to the drawing. The figures show:

[0033] FIG. 1, schematically, an invented telecommunication system according to the present invention, which is suitable for executing the invented method and in relation to which the invented method is described below; and

[0034] FIG. 2, the structure of a MAC frame with IP and UDP packets as well as RTP protocol elements.

[0035] FIG. 2 shows a MAC frame 50 (e.g. Ethernet) with IP packet 51 and UDP packet 52 embedded in it. The MAC frame 50 contains the L2-QoS marking in its MAC header. The IP packet 51 contains the L3-QoS marking in its IP header. The UDP data payloads 53 contain, by means of service multiplexing, the RTP protocol elements 54 and 55 (as illustrated, for example, by the “video” 54 and “audio” 55 services). According to the invention, the header for each of the RTP protocol elements carries the L4/L5-QoS marking, which will be explained in detail later.

[0036] FIG. 1 schematically shows an invented telecommunication system according to the present invention, which is suitable for executing the invented method and in relation to which the invented method is described below.

[0037] The schematically illustrated invented telecommunication system 10 includes in a general sense, but is not limited to, three networks. In a first network N1, a WebRTC server 25 and two routers 23 are illustrated here as an example, which are in contact with each other through QoS sensitive connections (based on different traffic classes). In this case the entire network N1 is a QoS-sensitive network. In addition, there is a network N2 that includes an access router 32, a “normal” router 33, a switch 34, a WebRTC server 35, a notebook computer with a WebRTC browser 36 running on it, and a notepad with a WebRTC browser 30 running on it. The WebRTC browser 30 here should be considered as an example of a WebRTC client that wishes to send media data with different traffic classes QoS1 and QoS2. The WebRTC client 30 is connected through WLAN to the router 33, which in turn is connected to the access router 32. In this example, all of these connections should be considered as non-QoS-sensitive. A marking unit QMP, whose function will be described later, is assigned to the access router 32.

[0038] In this example, the invented telecommunication system 10 also includes a third network N3 that includes: an access router 42 (serving as a network gateway device), a router 43, a switch 44, a WebRTC server 45, a notebook computer with a WebRTC browser 46 running on it, and a notepad with a WebRTC browser 40 running on it. The WebRTC browser 40 here should be considered as an example of a second WebRTC client. Unlike the network N2, in the network N3 a marking unit QMP is assigned to the router 43. While the connections between the router 43 and the access router 42 and to the WebRTC server 45 are “standard” QoS-sensitive connections, the other connections have port/service multiplexing (like the connections in the network N2).

[0039] It should be assumed here that the first WebRTC client 30 wants to send speech data with a QoS value QoS1, as well as video data with a QoS value QoS2 to the second WebRTC client 40 and wishes to use the services of the QoS-sensitive network N1 to do so. To do this, the first WebRTC client 30 packs the different data as appropriate into multiple second packets P2, which can also be designated as bundling or multiplexing. For each traffic class used (which can also include more than the two aforementioned traffic classes), the first WebRTC client 30 places a corresponding marking in layer 4 and/or layer 5 of the real-time protocol. These packets P2 are sent to the router 33 and forwarded by it to the access router 32. The access router 32, which can be assumed to be capable of interpreting the information in the packet heading and/or the markings in the extension of an IPv6 packet or the extensions to the layer 4/layer 5 markings in the header of the RTP protocol elements, has a marking unit QMP assigned to it, which unbundles or demultiplexes the mixed data packets P2 and creates new first packets P1 that are “type-pure,” i.e., have RTP protocol elements for only one QoS traffic class. First packets P1 of this type can then be transferred by the network N1, as soon as they are sent to it by the access router 32 and forwarded to the router 23, for example. For the respective connections between individual devices, there is an indication of which type of packets—packets P1 or packets P2—are being transported. The packets P1 are then sent to the access router 42 in the network N3 and forwarded by the access router 42 to the router 43. The router 43 also has a marking unit QMP assigned to it, which unbundles the data packets P1 and reconstructs the originally existing data packets 2, wherein it waits for a certain number of packets P1 to arrive and from them combines or rebundles the corresponding media data with different media types into a new second data packet P2. These new data packets P2 are then sent to the second WebRTC client 40.

[0040] The target router 43, configured according to the invention, therefore expects the sorted UDP/IP packets P1 corresponding to a predefined sliding window that corresponds to an IP packet counter, because the different PHBs used in the network N1 to transfer the packets P1 can certainly lead to packets bypassing each other. UDP/IP packets received inside the window are reconstructed as originally received according to the RTP segment counter, and the standard DSCP code point (or the one valid for the network N3) for service-bundled RTP/UDP/IP packets is assigned before the packets are forwarded to the WebRTC client 40.

[0041] In a current or currently known QoS-sensitive network, according to the invention the following steps must take place before routing in the network: This typically occurs in connection with a router that is connected to the distribution layer of an entire network. On the other hand, if only the network N1 is QoS-sensitive, this would occur in connection with a corresponding access router. In this way, the invented marking function for layers 4 and/or 5 can be applied to one of the two sides of the network gateway.

[0042] RTP protocol elements according to RFC3550 allow the use of an RTP header extension. This possibility is shown in the RTP header. The RTP header extension includes a profile identification that must be specified according to the invention. The length specification should display as at least one for the presence of a DSCP code point (8 bits) for the respective media type and of an optional combined IP packet/RTP protocol element counter in the following 32-bit word. In the remaining 24 bits, the IP packet counter and RTP protocol element counter can be coded (with overrun), allowing for optional restoration of the original second packets before delivery to the second WebRTC client. A marking unit according to the invention (assigned to a router or proxy server, for example), that terminates the original distribution network segment and has identified an RTP/UDP/IP data flow with service multiplexing, now segments the individual RTP segments, counts and overwrites the existing IP packet number and the position of the RTP protocol element within the UPD/IP packet in the RTP header extension. Advantageously, the router gathers the RTP protocol elements with the same DSCP code point into a recombined RTP/UDP/IP packet and overwrites the DSCP code point of the UDP/IP header corresponding to the RTP header extension, before the packet is forwarded.

[0043] In the previous description of an exemplary embodiment of the invention, it was stated that only one QoS-sensitive network N1 is available to transmit the media data from the first WebRTC client (of a non-QoS-sensitive network N2) to the second WebRTC client (of a QoS-sensitive network N3). This corresponds to a schematic network configuration chosen for the description. The network N3 in the configuration shown in FIG. 1 is also suitable for executing the invented method.

[0044] It should be noted that the features of the invention described by referencing the presented embodiments, for example the type and configuration of individual devices or components as well as individual method steps and their sequences, can also be present in other embodiments, unless stated otherwise or prohibited for technical reasons.

LIST OF REFERENCE INDICATORS

[0045] 10=Telecommunication system [0046] 23=Router [0047] 25=WebRTC server [0048] 30=First WebRTC client [0049] 32=Access router/Network gateway device [0050] 33=Router [0051] 34=Switch [0052] 35=WebRTC server [0053] 36=WebRTC browser [0054] 40=Second WebRTC client [0055] 42=Access router/Network gateway device [0056] 43=Router [0057] 44=Switch [0058] 45=WebRTC server [0059] 46=WebRTC browser [0060] 50=MAC frame [0061] 51=IP packet [0062] 52=UDP packet [0063] 53=Data payload [0064] 54=Video data [0065] 55=Audio data [0066] 90=Data carrier [0067] 92=Computer program product [0068] N1=QoS-sensitive network for transmission [0069] N2=Second network [0070] N3—Third network [0071] QMP=Marking unit [0072] QoS=Traffic class (Quality of Service)