EP2845369A1

EP2845369A1 - Method for controlling media transmission

Info

Publication number: EP2845369A1
Application number: EP12718650.0A
Authority: EP
Inventors: Daniel Rodriguez
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2012-05-02
Filing date: 2012-05-02
Publication date: 2015-03-11
Also published as: WO2013164017A1

Abstract

A method (100) for controlling media transmission in a communications network according to a traffic rule, comprises: monitoring (101) messages from a server for detecting a response message of a pre-defined media type, the response message being directed to a client; upon detection (102) of a response message of the pre-defined media type, the response message being directed to a client, intercepting the response message of the pre-defined media type and determining a destination identifier from the response message of the predefined media type; forwarding (103) the response message of the pre-defined media type to the client; monitoring (104) messages from a client for detecting a request message pointing to the determined destination identifier; upon detection (105) of a request message pointing to the determined destination identifier, intercepting the request message pointing to the determined destination identifier and modifying the request message pointing to the determined destination identifier according to the traffic rule; and forwarding (106) the modified request message pointing to the determined destination identifier.

Description

DESCRIPTION

Method for controlling media transmission TECHNICAL FIELD

The present invention relates to a method for controlling media transmission and an intermediate network device implementing the method. BACKGROUND OF THE INVENTION

Major players in communication networks have made proposals for protocols to replace HTTP Progressive Download. In HTTP Progressive Download a single request is made for the retrieval of a media file/stream. These protocols have been developed in the last 2 years and find themselves still in RFC if sent to the IETF or in a similar phase, although they are already commercially used by some media streaming companies. The new protocols proposed are generically named "Adaptive Bit Rate" or "Adaptive Streaming" because a control protocol to do the encoding selection has been implemented. This protocol allows to dynamically change the quality and therefore always retrieve the highest possible quality allowed by the network conditions. This can have the side effect of increasing the load of networks and decrease the available bandwidth for other users.

SUMMARY OF THE INVENTION It is the object of the invention to provide a bandwidth-efficient control protocol for media transmission in a communications network.

This object is achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

By means of HTTP proxying technology, an interception and processing engine is implemented that monitors the communication between client and server, learning about the existing encodings and monitoring, and if so decided, editing the requests made by clients to servers. Thus, the control protocol communicates the different encodings also known as bitrate or quality levels available at the beginning and/or during the transmission. According to a network rule or a traffic contract the accessing of bandwidth to individual users is controlled in a highly efficient manner.

In order to describe the invention in detail, the following terms, abbreviations and notations will be used:

HTTP: Hypertext,

RNC: Radio Network Controller,

Node-B: Base transceiver station,

SGSN: Serving GPRS support node, MME: Mobile Management Entity,

GGSN: Gateway GPRS support node,

Serial-Parallel Gateway,

RADIUS: Remote Authentication Dial-ln User Service,

HLR: Home Location Register, HSS: Home Subscriber Server,

LDAP: Lightweight Directory Access Protocol,

PCRF: Policy and Charging Rules Function,

PCEF: Policy Control Enforcement Function,

BAS: Broadband Access Server, BRAS: Broadband Access Radio Server, CMTS: Cable Modem Termination System,

HTTP: Hypertext Transfer Protocol, XML: Extended Markup Language,

URL: Uniform Resource Locator,

URI: Uniform Resource Identifier,

URN: Uniform Resource Name,

QoE: Quality of Experience, MIP: Manifest Interception Protocol,

MS-SSTR: Smooth Streaming Protocol Specification

MSDN: Microsoft® Developer Network.

According to a first aspect, the invention relates to a method for controlling media transmission in a communications network according to a traffic rule, comprising:

monitoring messages from a server for detecting a response message of a pre-defined media type, the response message being directed to a client; upon detection of a response message of the pre-defined media type, the response message being directed to a client, intercepting the response message of the pre-defined media type and determining a destination identifier from the response message of the pre-defined media type; forwarding the response message of the pre-defined media type to the client; monitoring messages from a client for detecting a request message pointing to the determined destination identifier; upon detection of a request message pointing to the determined destination identifier, intercepting the request message pointing to the determined destination identifier and modifying the request message pointing to the determined destination identifier according to the traffic rule; and forwarding the modified request message pointing to the determined destination identifier. In an implementation form of the method according to the first aspect, Intercepting (only the response at the beginning of the process and only the requests thereafter) and forwarding (unmodified response, but modified requests) is needed to be able to

1. Identify that a SmoothStreaming exchange is about to happen (response interception and unmodified forwarding)

2. Force the server to comply with the desired network bandwidth policies or quality of service requirements (request interception and modified forwarding).

In a first possible implementation form of the method according to the first aspect, the response message of the pre-defined media type is a HTTP response message.

Intercepting (only the response at the beginning of the process and only the requests thereafter) and forwarding (unmodified response, but modified requests) is needed to be able to identify that a SmoothStreaming exchange is about to happen (response interception and unmodified forwarding).

In a second possible implementation form of the method according to the first aspect as such or according to the first implementation form of the first aspect, the pre-defined media type corresponds to a Manifest type, in particular to a Smooth Streaming Manifest type.

In a third possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the response message of the pre-defined media type comprises an XML file. In a fourth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the destination identifier comprises a Uniform Resource Locator.

In a fifth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the response message comprises available encoding levels, in particular available audio and/or video encoding levels.

In a sixth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the request message pointing to the determined destination identifier is a HTTP request message. Intercepting (only the response at the beginning of the process and only the requests thereafter) and forwarding (unmodified response, but modified requests) is needed to be able to force the server to comply with the desired network bandwidth policies or quality of service requirements (request interception and modified forwarding).

In a seventh possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, a media type of the request message pointing to the determined destination identifier corresponds to a Fragment type, in particular to a video Fragment type or an audio Fragment type.

In an eighth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the request message pointing to the determined destination identifier comprises a requested encoding level and the modified request message pointing to the determined destination identifier comprises a modified encoding level, modified according to the traffic rule.

In a ninth possible implementation form of the method according to the eighth

implementation form of the first aspect, the requested encoding level comprises a requested bitrate and the modified encoding level comprises a modified bitrate.

In a tenth possible implementation form of the method according to the ninth implementation form of the first aspect, the modified bitrate is reduced with respect to the requested bitrate according to the traffic rule.

In an eleventh possible implementation form of the method according to the ninth implementation form of the first aspect, the modified bitrate is matched to a maximum possible bitrate according to the traffic rule. In a twelfth possible implementation form of the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect, the traffic rule is configured for managing quality of experience and/or bandwidth limitation in the communications network.

Methods according to the first aspect as such or according to implementation forms of the first aspect provide the following advantages: • Limitation of maximum encoding receivable by clients depending on the tariff subscribed with operator,

• Limitation of maximum encoding that may be sent by providers depending on framework contract with operator, and

• Usage of network aware information to perform fast encoding switching to ensure the highest potential quality playback with no stalling.

According to a second aspect, the invention relates to an intermediate network device for controlling media transmission in a communications network according to a traffic rule, the intermediate network device processing messages according to the method according to the first aspect as such or according to any of the preceding implementation forms of the first aspect. In a first possible implementation form of the intermediate network device according to the second aspect, the intermediate network device is configured as one of the following network elements: a radio network controller and/or enhanced Node-B or element serving the function of managing the radio transmission, a serving GPRS support node and/or Mobile Management Entity or an element serving the management of user mobility, a gateway GPRS support node and/or S/P-gateway or element managing the routing and forwarding of data packets, a RADIUS server and/or HLR/HSS or element managing user subscription data, an LDAP server, a PCRF network, an element serving the PCEF (Policy Control Enforcement Function) in the network, a Broadband Access Server or a Broadband Radio Access Server, a Cable Modem Termination System or a CMTS, a generic router placed in the network with packet/session proxying capabilities, and a generic server placed in the network with packet/session proxying capabilities.

An intermediate network device according to the second aspect or according to the first implementation form of the second aspect provides a dynamic adaptive live streaming management device and implements an interception and processing engine by means of HTTP proxying technology. The intermediate network device monitors the communication between client and server, learns about the existing encodings and monitoring, and if so decided, edits the requests made by clients to servers, thereby providing a highly efficient bandwidth control and improved quality of experience to the user. The methods described herein may be implemented as software in a Digital Signal

Processor (DSP), in a micro-controller or in any other side-processor or as hardware circuit within an application specific integrated circuit (ASIC). The invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

Further embodiments of the invention will be described with respect to the following figures, in which:

Fig. 1 shows a simple schematic diagram of a method for controlling media transmission in a communications network according to a traffic rule according to an implementation form;

Fig. 2 shows a listing of a request message of a "Manifest Request" media type according to an implementation form; Fig. 3 shows a listing of a response message of a "Manifest Response" media type according to an implementation form;

Fig. 4 shows two listings of a request message of a "Fragment Request" media type, a first with unmodified message parameters and a second one with modified message parameters according to an implementation form;

Fig. 5 shows two listings of a response message of a "Fragment Response" media type, a first one upon an unmodified request message of the "Fragment Request" media type and a second one upon a modified request message of the "Fragment Request" media type according to an implementation form;

Fig. 6 shows a message sequence diagram of an intermediate network device intercepting a communication between a user and a server in a "Manifest Registering" phase according to an implementation form; Fig. 7 shows a message sequence diagram of an intermediate network device modifying a communication between a user and a server in a "Fragment Request Modifying" phase according to an implementation form; Fig. 8 shows a simple diagram illustrating QoE improvement in a network implementing a method according to an implementation form; and

Fig. 9 shows a simple diagram illustrating bandwidth limitation in a network implementing a method according to an implementation form.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Fig. 1 shows a schematic diagram of a method 100 for controlling media transmission in a communications network according to a traffic rule according to an implementation form. The method 100 comprises monitoring 101 messages from servers for detecting a response message of a pre-defined media type, the response message being directed to a client; upon detection 102 of a response message of the pre-defined media type, the response message being directed to a client, intercepting the response message of the pre-defined media type and determining a destination identifier from the response message of the pre-defined media type; forwarding 103 the response message of the pre-defined media type to the client; monitoring 104 messages from clients for detecting a request message pointing to the determined destination identifier; upon detection 105 of a request message pointing to the determined destination identifier, intercepting the request message pointing to the determined destination identifier and modifying the request message pointing to the determined destination identifier according to the traffic rule; and forwarding 106 the modified request message pointing to the determined destination identifier.

In an implementation form, the response message of the pre-defined media type is a HTTP response message. The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems as defined in RFC 2616. In an implementation form, the HTTP response message is according to the RFC 2616 protocol.

In an implementation form, the pre-defined media type corresponds to a "Manifest" type, in particular to a "Smooth Streaming Manifest" type. In an implementation form, the "Manifest" type is according to the [MS-SSTR] Smooth Streaming Protocol Specification, which and can be found in the Microsoft® Developer Network (MSDN).

In an implementation form, the response message of the pre-defined media type comprises an XML file. In an implementation form, the XML file is according to the Extensible Markup Language as defined in the XML 1.0 Specification or in later versions thereof.

In an implementation form, the destination identifier comprises a Uniform Resource Locator (URL). In an implementation form, the Uniform Resource Locator URL is a compact string representation for a resource available via the internet as defined in the RFC 1738 protocol or later versions thereof.

In an implementation form, the response message comprises available encoding levels, in particular available audio and/or video encoding levels. In an implementation form, the request message pointing to the determined destination identifier is a HTTP request message. In an implementation form, a media type of the request message pointing to the determined destination identifier corresponds to a Fragment type, in particular to a video Fragment type or an audio Fragment type. In an implementation form, the request message pointing to the determined destination identifier comprises a requested encoding level and the modified request message pointing to the determined destination identifier comprises a modified encoding level, modified according to the traffic rule. In an implementation form, the requested encoding level comprises a requested bitrate and the modified encoding level comprises a modified bitrate. In an implementation form, the modified bitrate is reduced with respect to the requested bitrate according to the traffic rule. In an implementation form, the modified bitrate is matched to a maximum possible bitrate according to the traffic rule. In an implementation form, the traffic rule is configured for managing quality of experience (QoE) and/or bandwidth limitation in the communications network.

In an implementation form, the method illustrated in Fig. 1 addresses specifically the Microsoft Smooth Streaming Protocol and does the following: • It monitors HTTP Responses from servers looking for XML files and media type that corresponds to the Microsoft Smooth Streaming Manifest type

• If a Manifest is detected, the HTTP Response is intercepted.

• The manifest is saved and analyzed to learn about the different media encodings available (audio and video) and the destination URL that will be used to retrieve the media

• The HTTP Response is forwarded to the client as if it had been sent by the server

• The engine then monitors HTTP Requests that point to the URL recorded above.

• Upon detection of the URL the HTTP Request will be intercepted

· Business logic/network rules available to the engine will dictate if the HTTP Request has to be modified (the bandwidth parameter part of the URL request)

• The processed URL will then be forwarded to the destination server as if it had been sent by the client The consequence is that the server will send back to the client the media encoding that matches the business/network rules set by the operator and not the media encoding requested by the client.

In an implementation form, the method illustrated in Fig. 1 can be partitioned into two implementation steps, a manifest identification implementation step and a bandwidth control implementation step. The manifest identification implementation step is performed by the monitoring for detecting 101 , the intercepting and determining 102 and the forwarding 103 steps of the method 100 illustrated in Fig. 1. The bandwidth control implementation step is performed by the monitoring for detecting 104, the intercepting and modifying 105 and the forwarding 106 steps of the method 100 illustrated in Fig. 1.

According to this partitioning, the monitoring for detecting 101 of the manifest identification implementation step can be described in an implementation form as follows: ♦ 1. HTTP Get Requests are monitored by a Proxy

♦ The request will usually contain "Manifest" and/or the name of the media with an ".ism" extension.

♦ This may not be the case and therefore also HTTP responses have to be monitored

♦ If "Manifest" and the ".ism" extensions are seen in the Get query, it may be assumed that a Smooth Stream media has been requested. ♦ In any case the monitorization of the response is the key.

The intercepting and determining 102 of the manifest identification implementation step can be described in an implementation form as follows:

♦ 2. HTTP Get Responses are monitored by a Proxy

♦ A Manifest will be of type: "text/xml"

♦ Although Microsoft servers will contain a HTTP header of the type: "Pragma:

I ISMS/4.0, 1 IS Media Services by Microsoft" this is not expected to be true by non-Microsoft implementations

♦ The root node of XML content has to be named "SmoothStreamingMedia".

This is the key to identify the Manifest file

The forwarding 103 of the manifest identification implementation step can be described in an implementation form as follows:

♦ 3. Manifest has been identified

♦ The Manifest will be saved and analyzed according to the Smooth Streaming Standard

♦ Encodings for media will be recorded

♦ The "get" query string for media fragments will be recorded for identification

According to this partitioning, the monitoring for detecting 104 of the bandwidth control implementation step can be described in an implementation form as follows:

♦ 1. HTTP Get Requests are monitored by a Proxy

♦ The request query will be matched against the "get query pattern" identified in the manifest

♦ Because the media is broken into fragments, each "get" has to be monitored

The intercepting and modifying 105 of the bandwidth control implementation step can be described in an implementation form as follows:

♦ 2. "Get Query Pattern" is identified

♦ The client will make an initial query for the maximum quality which will help the client to identify the network conditions for subsequent requests ♦ The pattern may be modified (from the 1 request and any subsequent request) to conform to the following policies:

♦ Maximum bandwidth on a per user basis (individual tariff) that may include location, time, handset information, already used data quota and other factors

♦ Maximum bandwidth on a network-condition-basis. Network condition will be identified by other elements and this information will be available The forwarding 106 of the bandwidth control implementation step can be described in an implementation form as follows:

♦ 3. Each "Get Query" may be subject to modification following the previous criteria

Fig. 2 shows a listing of a request message 200 of a "Manifest Request" media type according to an implementation form. The request message 200 of the "Manifest Request" media type is detected by a get request identification 201 which is ".ism/Manifest". When the get request identification 201 is detected, the communication between user and server is "ready", i.e. available for interception.

Fig. 3 shows a listing of a response message 300 of a "Manifest Response" media type according to an implementation form. The response message 300 may comprise a HTTP header 301 which is only expected in MS (Microsoft) implementations. In an implementation form, there is no HTTP header 301. The response message 300 comprises an XML content type 303, e.g. of type "text/xml" and an XML root node identification 305, e.g. as

"SmoothStreamingMedia" identifier. The response message 300 further comprises a get query pattern 307 and encoding levels available for media 309, e.g. the two encoding levels "QualityLevelBitrate=2750000" and "QualityLevelBitrate=2040000".

Fig. 4 shows two listings of a request message of a "Fragment Request" media type, a first request message 400 with unmodified message parameters and a second request message 402 with modified message parameters according to an implementation form. The first request message 400 comprises a get query pattern 405 as identified in the manifest with bitrate 1520 kbps. The second request message 402 comprises a get query pattern 407 with the requested bitrate reduced to 640 kbps. This get query pattern 407 is only seen by the receiving server and not by the issuing client.

Fig. 5 shows two listings of a response message of a "Fragment Response" media type, a first response message 500 upon an unmodified request message of the "Fragment Request" media type and a second response message 502 upon a modified request message of the "Fragment Request" media type according to an implementation form. There is no difference in the answers. The server issues different bandwidths (honoring the requests) but does not notify which one is sending. The bandwidth is in the data delivered after the headers (not shown due to its binary nature). The client will play the video content using the information embedded in the binary data and is not using the textual information exchanged with the server.

Fig. 6 shows a message sequence diagram of an intermediate network device 603, also called "Platform" intercepting a communication between a user 601 and a server 605 in a "Manifest Registering" phase according to an implementation form. The "Manifest

Registering" phase corresponds to the manifest identification implementation step as described with respect to Fig. 1. The "Manifest Registering" phase comprises the monitoring for detecting 101 , the intercepting and determining 102 and the forwarding 103 steps of the method 100 illustrated in Fig. 1.

A "GET Manifest" message 610 is sent by the user 601 to the server 605 and intercepted by the platform 603 which forwards this message 610 unmodified as "GET Manifest" message 612 to the server 605. The server 605 answers with a "Manifest" message 614 which is intercepted by the platform 603 where the "Manifest" message is registered 616 and forwarded unmodified as "Manifest" message 618 to the user 601. During the "Manifest Registering" phase the platform 603 registers the "Manifest" message and knows that the user 601 is waiting for further messages from the server 605. In the Manifest/Playlist registration process the Manifest is registered during the response phase from the server and quality encodings, fragment information and URL request information are recorded.

Fig. 7 shows a message sequence diagram of an intermediate network device 703, also called "Platform" modifying a communication between a user 701 and a server 705 in a

"Fragment Request Modifying" phase according to an implementation form. The "Fragment Request Modifying" phase corresponds to the bandwidth control implementation step as described with respect to Fig. 1. The "Fragment Request Modifying" phase comprises the monitoring for detecting 104, the intercepting and modifying 105 and the forwarding 106 steps of the method 100 illustrated in Fig. 1.

A "Fragment QMax" message 710 is sent by the user 701 to the server 705 and intercepted by the platform 703. QMax indicates a desired bandwidth which the user 701 requests. According to a bandwidth policy or a network rule, the platform 703 modifies the desired bandwidth QMax into an available bandwidth QMed which may be smaller than the desired bandwidth QMax the client is requesting. The platform 703 forwards the received fragment message 710 with a modified bandwidth parameter QMed instead of QMax as "Fragment QMed" message 714 to the server 705. The server 705 answers with a "Fragment QMed" message 716 which is intercepted by the platform 703 where the "Fragment QMed" message is forwarded unmodified as "Fragment QMed" message 718 to the user 701.

During the "Fragment Request Modifying" phase the platform 703 modifies the requested bandwidth according to a network rule or a bandwidth policy which may consider the whole network, i.e. the demands of all users of the network for a high quality of experience or according to their traffic contract.

In the Fragment modification process the Fragment request is modified to match the decision made using network information and user information.

In an implementation form, the platform 703 depicted in Fig. 7 and/or the platform 603 as depicted in Fig. 6 is configured as one of the following network elements: a radio network controller and/or enhanced Node-B or element serving the function of managing the radio transmission, a serving GPRS support node and/or Mobile Management Entity or an element serving the management of user mobility, a gateway GPRS support node and/or S/P-GW or element managing the routing and forwarding of data packets, a RADIUS server and/or HLR/HSS or element managing user subscription data, an LDAP server, and a PCRF network node, an element serving the PCEF (Policy Control Enforcement Function) in the network, a Broadband Access Server (or BRAS), a Cable Modem Termination System (or CMTS), a generic router placed in the network with packet/session proxying capabilities and a generic server placed in the network with packet/session proxying capabilities. In an implementation form, the platform 703 is an element belonging to a mobile network. In an implementation form, the platform 703 is an element belonging to a fixed network like ADSL or Cable. Fig. 8 shows a diagram illustrating QoE improvement in a network implementing a method according to an implementation form. The first graph 801 depicts the normal protocol not implementing the method according to implementation forms of the invention. The normal client is slow to react to changing TCP/IP conditions, stalling happens. The second graph 802 depicts a MIP (Manifest identification protocol) protocol implementing the method according to implementation forms of the invention. The Manifest identification protocol 802 according to implementation forms of the invention reacts faster and thus selects the appropriate quality level faster. The maximum quality level Q_Max is illustrated by the third graph 803. In response to better network conditions, this faster reaction ensures that the client always receives the best possible encoding. In an implementation form, RAN information (radio network aware information) is exploited for improving the reaction times. Reaction with Radio/Network Aware Information to changing network conditions and adaptation of the protocol improves the overall performance of the protocol. The protocol adaptability is improved, less stalling happens, the playback is smoother and the QoE is improved.

Fig. 9 shows a diagram illustrating bandwidth limitation in a network implementing a method according to an implementation form.

The first graph 901 depicts the normal protocol not implementing the method according to implementation forms of the invention. The normal client always requests the maximum quality level QMax 903 if possible. The requested quality depends on TCP/IP conditions. The second graph 902 illustrates the Manifest identification protocol implementing the method according to implementation forms of the invention. The Manifest identification protocol 902 according to implementation forms of the invention limits the quality the client may receive to a limited quality Q_Limit 904. In an implementation form, the quality the client may receive is a network bandwidth which is available for him according to a network rule or a traffic contract. Thus, the Manifest identification protocol 902 according to implementation forms of the invention is Network/User information based and provides faster playback startup times, smoother playback due to reduced stalling probability, an overall QoE increase, fair use policies and therefore allows more users being served with existing bandwidth.

Claims

CLAIMS:

1. A method (100) for controlling media transmission in a communication network according to a traffic rule, comprising: - monitoring (101 ) messages from a server for detecting a response message of a predefined media type, the response message being directed to a client;

- upon detection (102) of a response message of the pre-defined media type, the response message being directed to a client, intercepting the response message of the pre-defined media type and determining a destination identifier from the response message of the pre- defined media type;

- forwarding (103) the response message of the pre-defined media type to the client;

- monitoring (104) messages from a client for detecting a request message pointing to the determined destination identifier;

- upon detection (105) of a request message pointing to the determined destination identifier, intercepting the request message pointing to the determined destination identifier and modifying the request message pointing to the determined destination identifier according to the traffic rule; and

- forwarding (106) the modified request message pointing to the determined destination identifier.

2. The method (100) according to claim 1 , wherein the response message of the predefined media type is a HTTP response message (300).

3. The method (100) according to claim 1 or claim 2, wherein the pre-defined media type corresponds to a Manifest type (201 ), in particular to a Smooth Streaming Manifest type.

4. The method (100) according to one of the preceding claims, wherein the response message of the pre-defined media type comprises an XML file.

5. The method (100) according to one of the preceding claims, wherein the destination identifier comprises a Uniform Resource Locator.

6. The method (100) according to one of the preceding claims, wherein the response message comprises available encoding levels (309), in particular available audio and/or video encoding levels.

7. The method (100) according to one of the preceding claims, wherein the request message pointing to the determined destination identifier is a HTTP request message.

8. The method (100) according to one of the preceding claims, wherein a media type of the request message pointing to the determined destination identifier corresponds to a Fragment type, in particular to a video Fragment type or an audio Fragment type.

9. The method (100) according to one of the preceding claims, wherein the request message pointing to the determined destination identifier comprises a requested encoding level (405) and the modified request message pointing to the determined destination identifier comprises a modified encoding level (407), modified according to the traffic rule.

10. The method (100) according to claim 9, wherein the requested encoding level (405) comprises a requested bitrate and the modified encoding level (407) comprises a modified bitrate.

1 1. The method (100) according to claim 10, wherein the modified bitrate is reduced with respect to the requested bitrate according to the traffic rule.

12. The method (100) according to claim 10, wherein the modified bitrate is matched to a maximum possible bitrate (803) according to the traffic rule.

13. The method (100) according to one of the preceding claims, wherein the traffic rule is configured for managing quality of experience and/or bandwidth limitation in the

communications network.

14. Intermediate network device (603, 703) for controlling media transmission in a communications network according to a traffic rule, the intermediate network device (603, 703) processing messages according to the method (100) of one of the claims 1 to 13.

15. The intermediate network device (603, 703) of claim 14, being configured as one of the following network elements: a radio network controller and/or enhanced Node-B or element serving the function of managing the radio transmission, a serving GPRS support node and/or Mobile Management Entity or an element serving the management of user mobility, a gateway GPRS support node and/or S/P-gateway or element managing the routing and forwarding of data packets, a RADIUS server and/or HLR/HSS or element managing user subscription data, an LDAP server, a PCRF network, an element serving the PCEF (Policy Control Enforcement Function) in the network, a Broadband Access Server or a Broadband Radio Access Server, a Cable Modem Termination System or a CMTS, a generic router placed in the network with packet/session proxying capabilities, and a generic server placed in the network with packet/session proxying capabilities.