EP3278532A1 - Procédé de priorisation de flux médias dans un réseau de communications - Google Patents

Procédé de priorisation de flux médias dans un réseau de communications

Info

Publication number
EP3278532A1
EP3278532A1 EP16714490.6A EP16714490A EP3278532A1 EP 3278532 A1 EP3278532 A1 EP 3278532A1 EP 16714490 A EP16714490 A EP 16714490A EP 3278532 A1 EP3278532 A1 EP 3278532A1
Authority
EP
European Patent Office
Prior art keywords
session
entity
control message
media
control
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP16714490.6A
Other languages
German (de)
English (en)
Inventor
Jean-Claude Le Rouzic
José DOREE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP3278532A1 publication Critical patent/EP3278532A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS

Definitions

  • the invention lies in the field of media flow management during a communication session, and more particularly relates to a method of prioritizing media streams associated with a multimedia communication session between two entities.
  • IETF RFC 3264 titled “An Offer / Answer Model with the Session Description Protocol” also describes a mechanism that allows two entities to use the SDP to negotiate settings for desired media streams for a session to be established or modified.
  • a first entity submits an offer, called "SDP offer”, in the form of a session description to establish or modify a session, to a second entity.
  • This offer includes a list of media flow descriptions specifying in particular for each stream a type of media (e.g. audio, video, text), a destination port number, a transport protocol, or encoding information.
  • the entity submitting the offer can thus indicate to the entity receiving the offer, the different media and characteristics (e.g. type of encoding) associated that it is able to support.
  • the entity receiving the offer accepts the offer by issuing a response, called "SDP response", indicating to the issuing entity of the offers the media feeds it is able to process.
  • the entity receiving the offer may also issue a new offer to the first entity, including for example other media it wishes to add to the session.
  • the two entities are thus likely to play indifferently the role of the issuer of an offer and that of the recipient of an offer.
  • This offer / answer mechanism is also applicable for communication sessions involving more than two participants (eg videoconferencing with more than two participants).
  • RFC 4412 "Communications Resource Priority for the Session Initiation Protocol (SIP)" defines a "Resource-Priority" SIP header field to identify a SIP request as requiring priority access to certain network resources. (eg network gateways, routers, SIP proxy).
  • the SIP header field "Resource-Priority” is populated by one or more domain names.
  • ETSI Specification Document TS 129 214 v7.4.0 (for "European Telecommunications Standards Institute"), entitled “Universal Mobile Telecommunications System (UMTS); Rx reference point "also describes a mechanism for prioritizing an IP flow within an application session between an application application entity (AF) and a PCRF entity (for” Policy and Charging "). Rules Function ”) via a" Reservation-Priority "attribute inserted into a Diameter message. This attribute makes it possible to indicate in a flow descriptor a relative priority for this flow within a session with which the latter is associated.
  • the state of the art does not provide a mechanism for the application entity to determine or be aware of the existence of flow priority within the session relative to other possible flows of the session.
  • the priority of a flow within a session is unknown to the control entities of the network, which does not allow the latter to take into account the importance of a flow relative to the other flows of the same session. network congestion, for example, or to transmit such information to other network entities. End-to-end processing of the priority of a stream is thus impossible to date.
  • One of the aims of the invention is to remedy the shortcomings / disadvantages of the state of the art and / or to make improvements thereto.
  • the invention relates to a method for prioritizing a media stream belonging to a plurality of media streams associated with a communication session, comprising:
  • the prioritization method thus enables the control entity to obtain priority information relating to a media stream associated with a session from a session control message.
  • This message is for example related to a session between a calling entity and a called entity, and received from the calling entity, the called entity or from an intermediary entity of the network located on a network path between the calling entity and the called entity.
  • the method advantageously makes it possible to transmit the priority information from such an entity to the control entity.
  • the message can also be directly generated by the control entity. This is particularly the case when this control entity is a user terminal. An end-to-end processing of this information from the sending entity of the session control message, or from the control entity if applicable, to the receiving media entity of the resource control message sent by the entity control is thus offered.
  • the method makes it possible, for example, in the event of network congestion, to preempt a particular media stream in favor of other flows associated with the session.
  • the method also makes it possible to favor the sending of a particular stream according to its type.
  • the method makes it possible, for example, to process a video surveillance video marked with a high priority in the session control message, in priority with respect to other streams (eg video and audio streams of a videoconference) of the session marked with a lower priority.
  • the method makes it possible, for example, to take into account a low priority associated with an audio stream of a videoconference held in sign language between hearing impaired participants by the control entity of the network.
  • the method further comprises a modification of the priority information prior to its insertion in the resource control message.
  • the method thus enables the controlling entity to directly intervene on the respective priorities assigned to the flows of the session.
  • These priorities are, for example, redefined or deleted by the control entity according to flow information (e.g. flow content, flow user, feed source) or network information.
  • a zero priority can advantageously be associated with the audio stream by the control entity of the network.
  • a media entity of the network receiving the resource control message containing the priority information thus modified can thus decide not to transmit this stream. This can also result in a release of resources from the network.
  • the modification of the priority information by the control entity also makes it possible to protect the network from the effects (eg saturation of the network) of a prioritization of one or more streams received from an unrecognized trusted entity issuing the session control message.
  • the method notably makes it possible to prohibit or redefine the priorities of certain streams before transmission of the priority information to other entities of the network via the resource control message.
  • the priority information is an attribute of a flow description included in an SDP offer or response associated with the session control message.
  • an SDP message can easily be encapsulated in a control message of a higher layer protocol using the SDP protocol. It is not necessary to provide extensions to such a protocol to implement the method.
  • MGCF Media Gateway Control Function
  • IMS-MGW IP Multimedia Subsystem - Media Gateway
  • the stream belongs to a plurality of media streams respectively associated with a flow description for the communication session.
  • These flow descriptions are ordered in an SDP offer or response associated with the session control message, and the priority information is an ordered list of values, included in a header of the session control message, whose order corresponds to the order of flow descriptions in the SDP offer or response.
  • the values then indicate a relative priority for each of the streams within the session in the order of the list.
  • Obtaining the priority information from a header of the session control message makes it possible to group all the priorities relating to the flows of a session in one and the same place. In particular, it is possible to predetermine the priorities of the flows described in an SDP offer or response without prior analysis of this SDP offer or response.
  • the session control message is a message
  • the invention relates to a control entity, called a "primary control entity", in a communication network, arranged to prioritize a media stream belonging to a plurality of media streams associated with a communication session.
  • the controlling entity includes:
  • a obtaining module and / or a generation module arranged to obtain from a session control message, or to generate, priority information indicating a relative priority of the flow within the session with respect to the others; flow of the plurality of media streams; and
  • an insertion module arranged to insert the priority information into a resource control message intended for a media entity.
  • control entity further comprises a modification module, arranged to modify the priority information prior to its insertion into the resource control message by the insertion module.
  • the obtaining module is arranged to obtain the priority information from an SDP offer or response included in the session control message.
  • the priority information is then an attribute of a flow description included in the SDP offer or response.
  • the control entity comprises a reception module, arranged to receive a session control message comprising an offer or an SDP response, said SDP offer or response comprising an ordered list of descriptions of the streams. associated with the session, and the obtaining module is arranged to obtain the priority information from a header of the session control message, this priority information being an ordered list of values included in the header, ordered in the same order as the flow descriptions associated with the session.
  • the control entity further comprises a determination module, arranged to determine, from the ordered list of values, and from the ordered list of flow descriptions associated with the session, a relative priority for each of the flows within the session according to the order of the lists.
  • the invention relates to a control entity, called a "secondary control entity", in a communication network, implementing session control signals, comprising:
  • a generation module arranged to extract and modify from a session control message, or to generate, priority information indicating a relative priority of a flow within a communication session, with respect to other streams of a plurality of media streams associated with the session;
  • the invention relates to a media entity, in a communication network, capable of retrieving, from an H.248 resource control message received from a control entity according to any of the characteristics of the second aspect, priority information indicating a relative priority of a stream within a communication session, relative to other streams of a plurality of media streams associated with the session.
  • the invention also relates to a program for a control entity, comprising program code instructions for controlling the execution of the steps of the prioritization method described above, when the program is executed by the control entity.
  • control and a computer-readable recording medium on which is recorded a computer program comprising program code instructions for performing the steps of the prioritization method described above.
  • FIG. 1 shows two IMS communication networks (for "IP Multimedia Subsystem") according to a particular embodiment
  • FIG. 2 represents steps of a prioritization method of a media stream, implemented by entities of an IMS communication network according to a particular embodiment
  • FIG. 3 shows a control entity, called "secondary control entity", according to a particular embodiment
  • FIG. 4 shows a control entity, called "primary control entity", according to a second particular embodiment.
  • FIG. 1 represents two IMS communication networks 100 and 200 in which control entities according to the invention implement a method for prioritizing one or more media streams associated with a session between a calling user terminal 10 and a user terminal. called 20.
  • An IMS network architecture as defined by the 3GPP standardization group (for 3rd "Generation Partnership Project") allows the establishment and control of multimedia sessions between user terminals, as well as the reservation of resources for flows Multimedia at the level of a data transport network. With this architecture, network operators can conveniently control the quality of service offered.
  • the IMS architecture offers services such as telephony, video telephony, presence, instant messaging, or television, and also manages the interaction of these services. It typically implements the Session Initiation Protocol (SIP) as defined by the Internet Engineering Task Force (IETF) in RFC 3261 as the session management protocol, which allows the establishment, modification and termination of multimedia sessions in a network using the IP protocol.
  • SIP Session Initiation Protocol
  • IETF Internet Engineering Task Force
  • the communication network 100 more particularly comprises control entities 30-33, and a both media and control entity 15.
  • the communication network 200 comprises control entities 52, 53, and a media entity 40.
  • the control entities and media entities are respectively entities capable of processing signaling messages relating to a communication session, and entities able to process the transport of data relating to a communication session.
  • the control entities are said to belong to a control plane, while the media entities are said to belong to a media plan.
  • control entity 30 is an application server AS (for example,
  • control entity 31 is a PCRF (Policy Control and Charging Rules Function) control entity
  • control entities 32 and 52 are P-CSCF proxy servers (for "Proxy - Call Server Control Function ")
  • control entities 33 and 53 are entities grouping I-CSCF interrogation functions (for” Interrogating - Call Server Control Function ") and S-CSCF registration functions (for" Serving - Call Server Control Function ")
  • the both media and control entity 15 is a PDN-GW gateway (for" Packet Data Network - Gateway ")
  • media entity 40 is an IMS-AGW gateway (for "IMS-Access Gateway”).
  • the entities of the network are implemented to manage the communication session between the calling user terminals 10 and 20 called.
  • the calling user terminal 10 is subscribed to the communication network 100 to which it accesses via the PDN-GW gateway 15
  • the called user terminal 20 is subscribed to the communication network 200.
  • control entity 32 serves as a connection entity between the heart of the communication network 100 and the access network used by the calling user terminal 10, and is able to retransmit all the messages of signaling between the calling user terminal 10 and the control entity 33.
  • the control entity 33 notably makes it possible to interrogate a subscriber server (not shown) in order to manage the registration procedure of the calling user terminal 10. It also makes it possible to request the control entity 30 for one or more services. associated with the communication session.
  • the control entity 31 is responsible for adapting and controlling the use of the network resources of the communication network 100 by providing control rules for the session as a function, for example, of the services required by the calling user terminal 10 or its subscriber profile.
  • the control entity 52 has a role equivalent to that of the control entity 32 in the communication network 200. It serves as a connection entity between the heart of the communication network 200 and the access network used by the user terminal called 20, and is able to retransmit all the signaling messages between the called user terminal 20 and the control entity 53.
  • the control entity 52 also communicates with the media entity 40.
  • the control entity 53 has a role equivalent to that of the control entity 33 in the communication network 200. It notably makes it possible to interrogate a subscriber server (not shown) in order to manage the registration procedure of the called user terminal 20.
  • Diameter 1 signaling messages such as as defined in IETF RFC 4740.
  • the exchanges between the control entity 52 and the media entity 40 are in turn supported by signaling messages 2 conforming to the H.248 protocol defined by the ITU-T ITU Working Group (for "Union Internationale of Telecommunications ").
  • control entities 30 and 52 which will be respectively called “primary control entity” and “secondary control entity” respectively. This will be detailed later in connection with FIG.
  • FIG. 1 is a simplified representation of the communication networks 100 and 200. No limitation is attached to the number of control entities and media entities belonging to the communication networks 100 and 200.
  • control entities may be further grouped within the same entity.
  • certain functions provided by the same entity may be separated and implemented by separate entities. This is for example the case of the I-CSCF interrogation and S-CSCF registration functions of the control entities 33 and 53.
  • FIG. 2 represents steps of a prioritization method of a media stream, implemented by entities of an IMS communication network according to a particular embodiment. Subsequently, one places oneself in a network configuration such as that described with reference to FIG.
  • the calling user terminal 10 sends a SIP session control message "INVITE" comprising an SDP offer to the communication network 200 to which the called user terminal 20 subscribes.
  • This message is intended to establish a communication session between the calling user terminal 10 and the called user terminal 20.
  • the SIP session control message "INVITE" sent for example has the following content: INVITE sip: userl@operatorl.com SIP / 2.0
  • a header of the SIP session control message "INVITE" more particularly indicates that the communication session that the calling user terminal 10 wishes to establish is a videoconferencing session with subtitling. This is indicated by the "Contact" header of the SIP session control message "INVITE" which includes the value "VisioConferenceAvecSousTitration".
  • the SDP offer contained in the SIP session control message "INVITE" further comprises three media flow descriptions each identified by the letter "m".
  • the first description describes an audio stream, the second a video stream, and the third a stream of instant messaging.
  • the SIP session control message "INVITE" does not contain any information relating to a priority of the flows associated with the communication session.
  • the control entity 32 (a proxy server P-CSCF) receives the session control message "INVITE" transmitted by the calling user terminal 10.
  • the control entity 32 then issues a request for reservation of media flows, for the three media streams of the SDP offer, with the control entity 31 (control entity PCRF rules).
  • the media stream reservation request is more precisely a Diameter Resource Check message "AAR" (for "AA-Request”) as defined in RFC 4005.
  • the control entity 31 sends an acknowledgment message of the stream reservation request to the control entity 32.
  • This acknowledgment message is a Diameter resource control message "AAA” (for "AA-Answer") as defined in RFC 4005.
  • the control entity 32 relays the SIP session control message "INVITE" to the control entity 33 (entity supporting I-CSCF interrogation and S-CSCF registration functions) .
  • the control entity 33 receives the SIP session control message "INVITE", and determines from the header "Contact” including the value "VisioConferenceAvecSousTitrage", that a video conference service with subtitling is to be implemented.
  • This service is provided by the primary control entity 30 (application server AS), and consists, for example, in real-time captioning in an instant messaging stream the words of a called user of the called user terminal 20 the language of a calling user of the calling user terminal 10.
  • the language of the calling user is for example determined from his subscriber profile obtained from a subscriber server HSS (for "Home Subscriber Server") .
  • the control entity 33 transmits the SIP session control message "INVITE" to the primary control entity 30.
  • the primary control entity 30 receives the SIP session control message "INVITE" and identifies the three media streams contained in the SDP offer.
  • a local flow prioritization policy at the primary control entity 30 provides that for this videoconferencing service with closed captioning, a video stream has a lower priority than an audio stream, the latter stream being itself of lower priority than an instant messaging stream associated with real-time subtitling.
  • the primary control entity 30 applies the prioritization policy to the media streams contained in the SDP offer. For this, the primary control entity 30 generates priority information indicating a relative priority of each of the media streams within the session compared to other flows associated with the session.
  • the value "0" corresponding to the minimum priority for a stream .
  • the priority information thus indicates that the video stream has the lowest priority, that the audio stream is of higher priority than that of the video stream, and that the instant messaging stream has a higher priority than the other two streams of video. the session.
  • the SIP session control message "INVITE" then contains a new SDP offer.
  • the resulting "INVITE" SIP session control message has, for example, the following content:
  • INVITE sip userl@operatorl.com SIP / 2.0
  • the primary control entity 30 stores it pending an SDP response, and returns the SIP session control message. "INVITE" to the controlling entity 33.
  • control entity 33 conveys the session control message
  • control entity 53 then routes the SIP signaling control message "INVITE" to the secondary control entity 52 (proxy server of the communication network 200).
  • the secondary control entity 52 inserts the priority information in an H.248 resource control message "Add Request", and sends it to the entity media 40 (IMS-AGW gateway of the communication network 200).
  • the H.248 resource control message "Add Request” is for example a reservation request for three separate streams ("stream" in the H.248 resource control message) for each of the media streams of the SDP offer.
  • the description of each of the media streams of the SDP offer containing the priority information is more precisely inserted in the H.248 resource check message "Add Request”.
  • the H.248 resource check message "Add Request" has the following form:
  • the media entity 40 receives the resource control message H.248 "Add Request”, and determines from the priority information contained in the message, the respective priorities of the media streams within of the communication session.
  • the priority information is then known to the media entity 40, which can advantageously exploit it by implementing, for example, different queues to process the flows of the session with differentiated priorities.
  • the media entity 40 after processing the H.248 resource control message "Add Request”, responds to the secondary control entity 52 with an H.248 "Add Reply" resource control message.
  • the secondary control entity 52 transmits the SIP session control message "INVITE" to the called user terminal 20.
  • the called user terminal 20 receives the SDP offer containing the priority information. It is thus informed of the priority of each stream associated with the session relative to the other streams.
  • the called user terminal 20 applies one or more flow prioritization policies configured at the terminal.
  • the called user terminal 20 generates, for example, a SIP session control message "200 OK" comprising an SDP response with valued attributes identical to those of the received SDP offer.
  • the called user terminal 20 sends this SDP response to the secondary control entity 52.
  • the content of the SIP session control message "200 OK" is for example the following: SIP / 2.0 200 OK
  • the secondary control entity 52 receives the SDP response sent by the called user terminal 20 and sends an H.248 resource control message "Modify Request" to the media entity 40.
  • the message H.248 resource control system "Modify Request” is used to inform the media entity 40 of the priorities associated with the flows of the session described in the SDP response.
  • the H.248 resource control message "Modify Request” has the following content:
  • a prio: 2
  • the media entity 40 acknowledges the resource control message received in step E13 by sending a resource control message "Modify Reply" to the secondary control entity 52.
  • step E15 the secondary control entity 52 relays the SIP session control message "200 OK" to the control entity 53, which itself relays it during a step E16 to the entity control 33 of the communication network 100.
  • control entity 33 transmits the SIP session control message "200 OK" to the primary control entity 30.
  • the latter then has the SDP offer stored in step E6 and the corresponding SDP response obtained from the SIP session control message "200 OK".
  • the primary control entity 30 can then update, if necessary, the priority information contained in the SDP response. This is for example the case when the primary control entity 30 determines, from an element inserted by the called user terminal 20 in the session control message containing the SDP response in step E12, that the called user of the called user terminal 20 uses a language that turns out to be identical to that used by the calling user. Since the latter stream no longer has the same importance for the calling user (with few exceptions), the primary control entity 30 modifies the priority information so that the priority of the instant messaging stream is less than that of the stream. audio.
  • the priority associated with the instant messaging flow for real-time video-conference captioning is decreased by decrementing its value by one unit, and the priority associated with the audio stream is increased by incrementing its value by one unit.
  • the primary control entity 30 then returns a SIP session control message "200 OK" with an SDP response with the new priority information.
  • control entity 33 transmits the SIP session control message "200 OK" to the control entity 32.
  • a step E20 the control entity 32 receives the session control message "200 OK".
  • the control entity 32 then issues a new media flow reservation request, for the three media streams of the SDP response, to the control entity 31.
  • the reservation request for media streams, as well as to the step E2, is a Diameter Resource Control message "AAR”.
  • the Diameter Resource Check message "AAR” further includes for each media stream of the session, a "Reservation-Priority" attribute valued with the new priority values associated with those streams in the SDP response.
  • the Diameter "AAR" Resource Check message sent is for example: Diameter Protocol
  • AVP Length ..
  • AVP Vendor Id 3GPP (10415)
  • step E21 the control entity 31 sends an acknowledgment message of the flow reservation request to the control entity 32.
  • this acknowledgment message is a Diameter Resource Check message "AAA”.
  • the control entity 32 transmits the SIP session control message "200 OK" to the calling user terminal 10.
  • This message includes the relative priorities associated with each stream of the session as configured by the user.
  • primary control entity 30 in step E18.
  • the calling user terminal may optionally locally reuse the priority information contained in the SDP response, in order to implement priority processing of one or more streams relative to the other streams of the session.
  • the priority information is directly inserted into a header of a SIP session control message, for example a "Flow-Priority" header, rather than in an SDP offer or response contained in this message.
  • the priority information then corresponds to an ordered list of values whose order corresponds to the order of the flow descriptions associated with the session in the SDP offer or response contained in the SIP session control message.
  • the values in the list then indicate a relative priority for each of the streams within the session in the order of the list. More precisely, at an nth flow description of an SDP offer or response corresponds the n-th priority value of the list of values associated with the "Flow-Priority" header.
  • a SIP session control message "INVITE" has the following form: INVITE sip: userl@operatorl.com SIP / 2.0
  • the called user terminal indicates in its SDP response valuated attributes different from those included in the SDP offer it has received.
  • the called user terminal can thus propose a prioritization of the flows of the session different from that proposed or retained by a control entity or, where appropriate, by a media entity or a user terminal of one of the networks 100 or 200.
  • a policy of prioritizing the media streams associated with the session is implemented by the calling user terminal 10 which indicates the priority information in the SDP offer sent to the step E1.
  • step E6 the primary control entity 30, according to a predefined parameter setting, can then modify the prioritization of the media streams described in the SDP offer or still retain the priority information as indicated by the calling user terminal 10.
  • the primary control entity 30 obtains the priority information indicating a relative priority of said flow within the session with respect to the other flows associated with the session, directly from the SIP session control message "INVITE " received.
  • the primary control entity and the secondary control entity are the same entity.
  • the controlling entity obtaining from a session control message, or generating, the priority information, also inserts this priority information into a resource control message.
  • the secondary control entity 52 implements an optional step of modifying the priority information before inserting the latter into a resource control message in step E9.
  • Priority information is, for example, modified according to an operator policy aimed at giving a lower priority to the most important flows. bandwidth consumers in case of network congestion.
  • Identical processing can also be implemented by the control entity 32 in the communication network 100.
  • the method has been described with implementation in two communication networks 100 and 200. There is however no limitation as to the number of communication networks in which the method is implemented. The method can for example easily be implemented in the same network for a communication session between subscriber terminals of this network.
  • control entity there is also no limitation as to the control entities likely to implement the described method.
  • a control entity belongs for example to the following group of control entities: entity P-CSCF (for "Proxy - Call Server Control Function"), entity I-CSCF (for "Interrogating - Call Server Control Function"), entity S-CSCF ("Serving - Call Server Control Function"), AS entity (for "Application Server”), MGCF entity (for "Media Gateway Controller Function"), IBCF entity (for "Interconnection Border Control Function”), user terminal .
  • Such a media entity belongs, for example, to the following group of media entities: AGW entity (for "Access Gateway”), C-BGF entity (for "Core - Border Gateway Function"), P-GW entity (for "PDN Gateway”) ), MRFP entity (for "Multimedia Resource Function Processor”), TrGW entity (for "Transition Gateway”), user terminal.
  • AGW entity for "Access Gateway”
  • C-BGF entity for "Core - Border Gateway Function
  • P-GW entity for "PDN Gateway”
  • MRFP entity for "Multimedia Resource Function Processor”
  • TrGW entity for "Transition Gateway”
  • FIG. 3 represents a secondary control entity 52 arranged to prioritize a media stream belonging to a plurality of media streams associated with a communication session.
  • the secondary control entity 52 comprises:
  • a obtaining module 310 and / or a generation module 320 arranged to obtain from a session control message, or to generate, priority information indicating a relative priority of a flow within the session; relative to the other streams of the plurality of media streams; an insertion module 330, arranged to insert said priority information in a resource control message intended for a media entity.
  • the control entity also comprises a modification module 340, arranged to modify the priority information prior to its insertion into the resource control message by the insertion module 330.
  • the obtaining module 310 is arranged to obtain the priority information from an SDP offer or response included in the session control message, the priority information being an attribute of a flow description included in the SDP offer or response.
  • control entity 52 comprises a reception module 350 arranged to receive a session control message comprising an offer or an SDP response.
  • This SDP offer or response includes an ordered list of flow descriptions associated with the session.
  • the obtaining module is also arranged to obtain the priority information from a header of the session control message. This header includes the priority information in the form of an ordered list of values. The values are ordered in the same order as the flow descriptions associated with the session.
  • the control entity further comprises a determination module 360, arranged to determine, from the ordered list of values, and from the ordered list of descriptions of the flows associated with the session, a relative priority for each of the flows within of the session according to the order of the lists.
  • FIG. 4 represents a primary control entity 30, in a communication network. This entity implements session control signals.
  • the control entity 30 comprises:
  • a generation module 410 arranged to extract and modify from a session control message, or to generate, priority information indicating a relative priority of a flow within a communication session, with respect to other streams of a plurality of media streams associated with the session;
  • an insertion module 420 arranged to insert the information in a session control message to a secondary control entity.
  • module may correspond in this document to both a software component, a hardware component or a set of hardware and / or software components, capable of implementing a function or a set of functions, as described above for the module concerned.
  • a software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software.
  • Such a software component is stored in memory and then loaded and executed by a data processor of a physical entity and is capable of accessing hardware resources of this physical entity (memories, recording media, communication bus, input / output electronic boards, user interfaces, etc.).
  • a material component corresponds to any element of a material set (or hardware). It may be a programmable hardware component or not, with or without an integrated processor for running software. This is for example an integrated circuit, a smart card, an electronic card for executing a firmware, etc.
  • the modules 310, 320, 330, 340, 350 and 360 are arranged to implement the prioritization method described above.
  • These are preferably software modules comprising software instructions for executing those of the steps of the prioritization method described above, implemented by a secondary control entity.
  • the invention therefore also relates to:
  • a program for a secondary control entity comprising program code instructions intended to control the execution of the steps of the previously described prioritization method, when said program is executed by said secondary control entity;
  • a recording medium readable by a secondary control entity on which the program is recorded for a secondary control entity.
  • modules 410 and 420 are arranged to implement the prioritization method described above.
  • These are preferably software modules comprising software instructions for executing those of the steps of the prioritization method described above, implemented by a primary control entity.
  • the invention therefore also relates to:
  • a program for a primary control entity comprising program code instructions for controlling the execution of the steps of the previously described prioritization method, when said program is executed by said primary control entity;
  • a recording medium readable by a primary control entity on which the program is recorded for a primary control entity.
  • the software modules can be stored in or transmitted by a data carrier.
  • a data carrier This may be a hardware storage medium, for example a CD-ROM, a magnetic diskette or a hard disk, or a transmission medium such as an electrical signal, optical or radio, or a telecommunications network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé de priorisation d'un flux média appartenant à une pluralité de flux médias associée à une session de communication, comprenant une obtention (E8, E19), à partir d'un message de contrôle de session, ou une génération (E6), par une première entité de contrôle (30, 32, 52), d'une information de priorité indiquant une priorité relative dudit flux au sein de la session par rapport aux autres flux de ladite pluralité de flux médias; et une insertion (E9, E20), par une deuxième entité de contrôle (32, 52), de ladite information de priorité, dans un message de contrôle de ressources à destination d'une entité média (10, 40).

Description

Procédé de priorisation de flux médias dans un réseau de communications
L'invention se situe dans le domaine de la gestion de flux médias lors d'une session de communication, et concerne plus particulièrement un procédé de priorisation de flux médias associés à une session de communication multimédia entre deux entités.
Plusieurs méthodes de gestion de flux sont connues de l'état de la technique. Dans les réseaux de type IP (pour « Internet Protocol »), il est notamment connu de combiner le protocole SDP (pour « Session Description Protocol ») tel que défini dans le document RFC 4566 de l'IETF (pour « Internet Engineering Task Force »), avec le protocole SIP (pour « Session Initiation Protocol ») tel que décrit dans le document RFC 3261 également de l'IETF, afin d'établir, modifier ou encore terminer une session de communication multimédia entre deux entités. Le protocole SDP permet en particulier de décrire un ensemble de flux médias associés à une telle session de communication multimédia.
Le document RFC 3264 de l'IETF, intitulé « An Offer/Answer Model with the Session Description Protocol », décrit par ailleurs un mécanisme permettant à deux entités d'utiliser le protocole SDP afin de négocier des paramètres relatifs à des flux médias souhaités pour une session à établir ou à modifier. Selon ce modèle, une première entité soumet une offre, dite « offre SDP », sous la forme d'une description de session afin d'établir ou modifier une session, à une deuxième entité. Cette offre comprend une liste de descriptions de flux médias précisant notamment pour chaque flux un type de média (e.g. audio, vidéo, texte), un numéro de port de destination, un protocole de transport, ou encore des informations d'encodage. L'entité qui soumet l'offre peut ainsi indiquer à l'entité destinataire de l'offre, les différents médias et caractéristiques (e.g. type d'encodage) associées qu'elle est en mesure de prendre en charge. L'entité destinataire de l'offre, en fonction par exemple des médias et encodages qu'elle-même prend en charge, accepte l'offre en émettant une réponse, dite « réponse SDP », indiquant à l'entité émettrice de l'offre les flux médias qu'elle est en mesure de traiter. L'entité destinataire de l'offre peut également émettre une nouvelle offre à destination de la première entité, comprenant par exemple d'autres médias qu'elle souhaite ajouter à la session. Les deux entités sont ainsi susceptibles de jouer indifféremment le rôle de l'émetteur d'une offre et celui du destinataire d'une offre. Ce mécanisme d'offre/réponse est en outre également applicable pour des sessions de communications impliquant plus de deux participants (e.g. visioconférence comprenant plus de deux participants).
Lorsque le réseau est saturé, les flux médias ainsi négociés lors d'un établissement ou de la modification d'une session de communication multimédia sont susceptibles d'être traités prioritairement par une entité du réseau. Pour cela, le document RFC 4412, intitulé « Communications Resource Priority for the Session Initiation Protocol (SIP) » définit un champ d' entête SIP « Resource-Priority » permettant d'identifier une requête SIP comme requérant un accès prioritaire à certaines ressources réseaux (e.g. passerelles réseaux, routeurs, proxy SIP). Le champ d'entête SIP « Resource-Priority » est renseigné par un ou plusieurs noms de domaine. Lorsqu'une entité d'un plan de contrôle du réseau reçoit un message SIP comprenant le champ d'entête SIP « Resource-Priority », elle vérifie que le message est valide, et identifie les services associés aux noms de domaine du champ d'entête SIP « Resource-Priority ». Lorsque les ressources sont saturées, l'entité peut préempter les autres sessions de communication en cours non associées à un nom de domaine identifié, ou insérer la requête SIP comportant le champ d'entête « Resource-Priority » dans une file d' attente de requêtes à traiter prioritairement. Le mécanisme décrit dans le document RFC 4412 permet ainsi de traiter prioritairement une session de communication, et indirectement l'ensemble des flux médias associés à cette session. Cette priorité est cependant identique pour l'ensemble des flux médias associés à la session. Le mécanisme décrit ne permet notamment pas d'indiquer une priorité relative entre flux d'une même session.
Le document de spécification TS 129 214 v7.4.0 de l'ETSI (pour « European Télécommunications Standards Institute »), intitulé « Universal Mobile Télécommunications System (UMTS) ; Policy and charging control over Rx référence point », décrit en outre un mécanisme permettant de prioriser un flux IP au sein d'une session applicative entre une entité applicative AF (pour « Application Function ») et une entité PCRF (pour « Policy and Charging Rules Function ») via un attribut « Reservation-Priority » inséré dans un message Diameter. Cet attribut permet d'indiquer dans un descripteur de flux, une priorité relative pour ce flux au sein d'une session à laquelle ce dernier est associé. L'état de la technique ne prévoit cependant pas de mécanisme permettant à l'entité applicative de déterminer ou d'être informée de l'existence d'une priorité du flux au sein de la session relativement aux autres flux éventuels de la session. La priorité d'un flux au sein d'une session est inconnue des entités de contrôle du réseau, ce qui ne permet pas à ces dernières de prendre en compte l'importance d'un flux relativement aux autres flux d'une même session en cas par exemple de congestion réseau, ni de transmettre une telle information à destination d'autres entités du réseau. Un traitement bout-à-bout de la priorité d'un flux est ainsi impossible à ce jour.
Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations.
Selon un premier aspect, l'invention concerne un procédé de priorisation d'un flux média appartenant à une pluralité de flux médias associée à une session de communication, comprenant :
- une obtention à partir d'un message de contrôle de session, ou une génération, par une première entité de contrôle, d'une information de priorité indiquant une priorité relative de ce flux au sein de la session par rapport aux autres flux de la pluralité de flux médias ; et
- une insertion, par une deuxième entité de contrôle, de l'information de priorité, dans un message de contrôle de ressources à destination d'une entité média. Le procédé de priorisation permet ainsi à l'entité de contrôle d'obtenir une information de priorité relative à un flux média associé à une session à partir d'un message de contrôle de session. Ce message est par exemple relatif à une session entre une entité appelante et une entité appelée, et reçu depuis l'entité appelante, l'entité appelée ou encore depuis une entité intermédiaire du réseau située sur un chemin réseau entre l'entité appelante et l'entité appelée. Le procédé permet avantageusement de transmettre l'information de priorité depuis une telle entité à l'entité de contrôle. Le message peut également être directement généré par l'entité de contrôle. C'est notamment le cas lorsque cette entité de contrôle est un terminal utilisateur. Un traitement bout en bout de cette information depuis l'entité émettrice du message de contrôle de session, ou depuis l'entité de contrôle le cas échéant, jusqu'à l'entité média réceptrice du message de contrôle de ressources envoyé par l'entité de contrôle est ainsi offert.
Grâce au procédé, il est ainsi possible à une entité émettrice du message de contrôle de session, ou à une entité générant un tel message, de proposer une priorité pour des flux médias associés à la session. De nombreuses politiques de priorisation des flux médias associés à la session peuvent ainsi être mises en œuvre à leur réception ou envoi par l'entité de contrôle.
Le procédé permet, par exemple, en cas de congestion réseau, de préempter un flux média particulier au profit d'autres flux associés à la session. Le procédé permet également de privilégier l'envoi d'un flux particulier selon son type. Le procédé permet par exemple de traiter un flux vidéo de télésurveillance marqué d'une priorité élevée dans le message de contrôle de session, prioritairement par rapport à d'autres flux (e.g. flux vidéo et audio d'une visioconférence) de la session marqués d'une priorité inférieure. De même, le procédé permet par exemple une prise en compte d'une priorité faible associée à un flux audio d'une visioconférence tenue en langage des signes entre des participants malentendants par l'entité de contrôle du réseau.
Selon une caractéristique particulière, le procédé comprend en outre une modification de l'information de priorité préalablement à son insertion dans le message de contrôle de ressources.
Le procédé permet ainsi à l'entité de contrôle d'intervenir directement sur les priorités respectives affectées aux flux de la session. Ces priorités sont par exemple redéfinies ou supprimées par l'entité de contrôle en fonction d'informations relatives aux flux (e.g. contenu des flux, utilisateur des flux, source des flux) ou encore d'informations relatives au réseau.
Dans l'exemple précédemment cité d'un flux audio d'une visioconférence tenue en langage des signes entre des participants malentendants, une priorité nulle peut avantageusement être associée au flux audio par l'entité de contrôle du réseau. Une entité média du réseau réceptrice du message de contrôle de ressources contenant l'information de priorité ainsi modifiée peut ainsi décider de ne pas transmettre ce flux. Ceci peut par ailleurs avoir pour conséquence une libération de ressources du réseau.
La modification de l'information de priorité par l'entité de contrôle permet en outre de prémunir le réseau des effets (e.g. saturation du réseau) d'une priorisation d'un ou de plusieurs flux reçus d'une entité non réputée de confiance émettrice du message de contrôle de session. Le procédé permet notamment d'interdire ou de redéfinir les priorités de certains flux avant transmission de l'information de priorité vers d'autres entités du réseau par l'intermédiaire du message de contrôle de ressources.
Selon une caractéristique particulière, l'information de priorité est un attribut d'une description du flux comprise dans une offre ou une réponse SDP associée au message de contrôle de session.
L'obtention de l'information de priorité à partir d'une offre ou d'une réponse SDP, permet une mise en œuvre aisée du procédé. Un message SDP peut en particulier facilement être encapsulé dans un message de contrôle d'un protocole de couche supérieure utilisant le protocole SDP. Il n'est pas nécessaire de prévoir des extensions à un tel protocole pour mettre en œuvre le procédé. Pour une entité de contrôle de type MGCF (pour « Media Gateway Control Function ») communiquant avec une entité média de type IMS-MGW (pour « IP Multimedia Subsystem - Media Gateway ») par l'intermédiaire du protocole H.248, il est par exemple possible d'intégrer l'offre ou la réponse SDP contenant l'information de priorité directement dans un message de contrôle de ressources H.248, alors que dans l'état de l'art, seul le protocole Diameter permettait d'indiquer la priorité relative d'un flux au sein d'une session par rapport à d'autres flux d'une pluralité de flux associée à la session. Ceci assure une compatibilité du procédé avec de nombreux protocoles.
En outre, l'utilisation d'un attribut pour indiquer la priorité associée à un flux directement dans la description de ce flux contenue dans l'offre ou la réponse SDP, offre une lisibilité facilitée de cette information.
Selon une caractéristique particulière, le flux appartient à une pluralité de flux médias respectivement associé à une description de flux pour la session de communication. Ces descriptions de flux sont ordonnées dans une offre ou une réponse SDP associée au message de contrôle de session, et l'information de priorité est une liste ordonnée de valeurs, comprise dans un entête du message de contrôle de session, dont l'ordre correspond à l'ordre des descriptions de flux dans l'offre ou la réponse SDP. Les valeurs indiquent alors une priorité relative pour chacun des flux au sein de la session selon l'ordre de la liste.
L'obtention de l'information de priorité à partir d'un entête du message de contrôle de session permet de regrouper l'ensemble des priorités relatives aux flux d'une session en un même endroit. Il est en particulier possible de prédéterminer les priorités des flux décrits dans une offre ou une réponse SDP sans analyse préalable de cette offre ou réponse SDP.
En outre, il n'est pas nécessaire de prévoir un attribut spécifique dans l'offre ou la réponse SDP pour indiquer une priorité relative à un flux. Le procédé peut ainsi être mis en œuvre avec des entités générant des messages SDP selon des techniques connues. Selon une caractéristique particulière, le message de contrôle de session est un message
SIP.
Selon un deuxième aspect, l'invention concerne une entité de contrôle, dite « entité primaire de contrôle », dans un réseau de communication, agencée pour prioriser un flux média appartenant à une pluralité de flux médias associée à une session de communication. L'entité de contrôle comprend :
- un module d'obtention et/ou un module de génération, agencés pour obtenir à partir d'un message de contrôle de session, ou générer, une information de priorité indiquant une priorité relative du flux au sein de la session par rapport aux autres flux de la pluralité de flux médias ; et
- un module d'insertion, agencé pour insérer l'information de priorité dans un message de contrôle de ressources à destination d'une entité média.
Selon une caractéristique particulière, l'entité de contrôle selon le deuxième aspect comprend en outre un module de modification, agencé pour modifier l'information de priorité préalablement à son insertion dans le message de contrôle de ressources par le module d'insertion.
Selon une caractéristique particulière, le module d'obtention est agencé pour obtenir l'information de priorité à partir d'une offre ou d'une réponse SDP comprise dans le message de contrôle de session. L'information de priorité est alors un attribut d'une description du flux comprise dans l'offre ou la réponse SDP.
Selon une caractéristique particulière, l'entité de contrôle selon le deuxième aspect comprend un module de réception, agencé pour recevoir un message de contrôle de session comprenant une offre ou une réponse SDP, ladite offre ou réponse SDP comprenant une liste ordonnée de descriptions des flux associés à la session, et le module d'obtention est agencé pour obtenir l'information de priorité à partir d'un entête du message de contrôle de session, cette information de priorité étant une liste ordonnée de valeurs comprise dans l'entête, ordonnées selon un même ordre que les descriptions de flux associées à la session. L'entité de contrôle comprend en outre un module de détermination, agencé pour déterminer, à partir de la liste ordonnée de valeurs, et de la liste ordonnée de descriptions des flux associés à la session, une priorité relative pour chacun des flux au sein de la session selon l'ordre des listes.
Selon un troisième aspect, l'invention concerne une entité de contrôle, dite « entité secondaire de contrôle », dans un réseau de communication, mettant en œuvre des signaux de contrôle de session, comprenant :
- un module de génération, agencé pour extraire et modifier à partir d'un message de contrôle de session, ou générer, une information de priorité indiquant une priorité relative d'un flux au sein d'une session de communication, par rapport à d'autres flux d'une pluralité de flux médias associée à la session ; et
- un module d'insertion, agencé pour insérer l'information dans un message de contrôle de session à destination d'une autre entité de contrôle, dite « entité primaire de contrôle ». Selon un quatrième aspect, l'invention concerne une entité média, dans un réseau de communication, apte à extraire, depuis un message de contrôle de ressources H.248 reçu depuis une entité de contrôle selon l'une quelconque des caractéristiques du deuxième aspect, une information de priorité indiquant une priorité relative d'un flux au sein d'une session de communication, par rapport à d'autres flux d'une pluralité de flux médias associée à la session.
Les avantages énoncés pour le procédé de priorisation selon le premier aspect sont directement transposables aux entités de contrôle selon le deuxième aspect et le troisième aspect, ainsi qu'à l'entité média selon le quatrième aspect.
Selon un cinquième aspect, l'invention concerne également un programme pour une entité de contrôle, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de priorisation précédemment décrit, lorsque le programme est exécuté par l'entité de contrôle, et un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé de priorisation précédemment décrit.
L'invention sera mieux comprise à l'aide de la description suivante de modes de réalisation particuliers, en référence aux dessins annexés sur lesquels :
- la figure 1 représente deux réseaux de communication IMS (pour « IP Multimedia Subsystem ») selon un mode particulier de réalisation ;
- la figure 2 représente des étapes d'un procédé de priorisation d'un flux média, mis en œuvre par des entités d'un réseau de communication IMS selon un mode particulier de réalisation ;
- le figure 3 représente une entité de contrôle, dite « entité secondaire de contrôle », selon un mode particulier de réalisation ;
- la figure 4 représente une entité de contrôle, dite « entité primaire de contrôle », selon un deuxième mode particulier de réalisation.
La figure 1 représente deux réseaux de communication IMS 100 et 200 dans lesquels des entités de contrôle selon l'invention mettent en œuvre un procédé de priorisation d'un ou plusieurs flux médias associés à une session entre un terminal utilisateur appelant 10 et un terminal utilisateur appelé 20. Une architecture de réseau IMS telle que définie par le groupe de normalisation 3GPP (pour 3rd « Génération Partnership Project ») permet l'établissement et le contrôle de sessions multimédias entre des terminaux utilisateur, ainsi que la réservation de ressources pour les flux multimédias au niveau d'un réseau de transport de données. Grâce à cette architecture, les opérateurs de réseaux peuvent commodément contrôler la qualité de service offerte. L'architecture IMS permet d'offrir des services de type téléphonie, visiophonie, présence, messagerie instantanée, ou télévision, et gère également l'interaction de ces services. Elle met généralement en œuvre le protocole SIP (pour « Session Initiation Protocol »), tel que défini par l'IETF (pour « Internet Engineering Task Force ») dans le document RFC 3261 en tant que protocole de gestion de sessions, lequel permet l'établissement, la modification et la terminaison de sessions multimédias dans un réseau utilisant le protocole IP.
Le réseau de communication 100 comprend plus particulièrement des entités de contrôle 30-33, et une entité à la fois média et de contrôle 15. De même, le réseau de communication 200 comprend des entités de contrôle 52, 53, et une entité média 40. Les entités de contrôle et entités médias sont respectivement des entités aptes à traiter des messages de signalisation relatifs à une session de communication, et des entités aptes à traiter le transport de données relatives à une session de communication. Les entités de contrôles sont dîtes appartenir à un plan de contrôle, tandis que les entités médias sont dîtes appartenir à un plan média.
A titre d'exemple, l'entité de contrôle 30 est un serveur d'application AS (pour
« Application Server »), l'entité de contrôle 31 est une entité de contrôle de règles PCRF (pour « Policy Control and Charging Rules Function »), les entités de contrôle 32 et 52 sont des serveurs mandataires P-CSCF (pour « Proxy - Call Server Control Function »), les entités de contrôle 33 et 53 sont des entités regroupant des fonctions d'interrogation I-CSCF (pour « Interrogating - Call Server Control Function ») et des fonctions d'enregistrement S-CSCF (pour « Serving - Call Server Control Function »), l'entité à la fois média et de contrôle 15 est une passerelle PDN-GW (pour « Packet Data Network - Gateway), et l'entité média 40 est une passerelle IMS-AGW (pour « IMS- Access Gateway »).
Les entités du réseau sont mises en œuvre pour gérer la session de communication entre les terminaux utilisateur appelant 10 et appelé 20. Le terminal utilisateur appelant 10 est abonné au réseau de communication 100 auquel il accède par l'intermédiaire de la passerelle PDN-GW 15. Le terminal utilisateur appelé 20 est abonné au réseau de communication 200.
Dans le mode de réalisation décrit, l'entité de contrôle 32 sert d'entité de raccordement entre le cœur du réseau de communication 100 et le réseau d'accès utilisé par le terminal utilisateur appelant 10, et est apte à retransmettre tous les messages de signalisation entre le terminal utilisateur appelant 10 et l'entité de contrôle 33.
L'entité de contrôle 33 permet notamment d'interroger un serveur d'abonnés (non représenté) afin de gérer la procédure d'enregistrement du terminal utilisateur appelant 10. Elle permet également de solliciter l'entité de contrôle 30 pour un ou plusieurs services associés à la session de communication.
L'entité de contrôle 31 est chargée d'adapter et de contrôler l'usage des ressources réseaux du réseau de communication 100 en fournissant des règles de contrôle de la session en fonction par exemple des services requis par le terminal utilisateur appelant 10 ou de son profil d'abonné.
L'entité de contrôle 52 a un rôle équivalent à celui de l'entité de contrôle 32 dans le réseau de communication 200. Elle sert d'entité de raccordement entre le cœur du réseau de communication 200 et le réseau d'accès utilisé par le terminal utilisateur appelé 20, et est apte à retransmettre tous les messages de signalisation entre le terminal utilisateur appelé 20 et l'entité de contrôle 53. L'entité de contrôle 52 communique par ailleurs avec l'entité média 40.
L'entité de contrôle 53 a un rôle équivalent à celui de l'entité de contrôle 33 dans le réseau de communication 200. Elle permet notamment d'interroger un serveur d'abonnés (non représenté) afin de gérer la procédure d'enregistrement du terminal utilisateur appelé 20.
Les échanges entre respectivement, le terminal utilisateur appelant 10 et la passerelle PDN- GW 15, la passerelle PDN-GW 15 et l'entité de contrôle 32, l'entité de contrôle 32 et l'entité de contrôle 33, l'entité de contrôle 33 et l'entité de contrôle 30, l'entité de contrôle 33 et l'entité de contrôle 53, l'entité de contrôle 53 et l'entité de contrôle 52, et l'entité de contrôle 52 et le terminal utilisateur appelé 20, sont des messages de signalisation SIP 3.
Les échanges entre d'une part l'entité de contrôle 31 et l'entité de contrôle 32, et d'autre part entre la passerelle PDN-GW 15 et l'entité de contrôle 31 sont réalisés par des messages de signalisation Diameter 1 tels que défini dans le document de l'IETF RFC 4740.
Les échanges entre l'entité de contrôle 52 et l'entité média 40 sont quant à eux supportés par des messages de signalisation 2 conformes au protocole H.248 défini par le groupe de travail UIT-T de l'UIT (pour « Union Internationale des Télécommunications »).
Le procédé de priorisation est plus particulièrement mis en œuvre par les entités de contrôle 30 et 52, qui par la suite seront respectivement dite « entité primaire de contrôle » et « entité secondaire de contrôle ». Ceci sera détaillé par la suite en relation avec la figure 2.
II est par ailleurs à noter que la figure 1 est une représentation simplifiée des réseaux de communication 100 et 200. Aucune limitation n'est attachée au nombre d'entités de contrôle et d'entités médias appartenant aux réseaux de communication 100 et 200.
Dans une autre configuration réseau, certaines entités de contrôle peuvent en outre être regroupées au sein d'une même entité. De même, certaines fonctions assurées par une même entité peuvent être dissociées et mises en œuvre par des entités distinctes. C'est par exemple le cas des fonctions d'interrogation I-CSCF et d'enregistrement S-CSCF des entités de contrôle 33 et 53.
La figure 2 représente des étapes d'un procédé de priorisation d'un flux média, mis en œuvre par des entités d'un réseau de communication IMS selon un mode particulier de réalisation. Par la suite, on se place dans une configuration réseau telle que celle décrite en relation avec la figure 1.
Lors d'une étape El, le terminal utilisateur appelant 10 envoie un message de contrôle de session SIP « INVITE » comprenant une offre SDP à destination du réseau de communication 200 auquel est abonné le terminal utilisateur appelé 20. Ce message a pour but d'établir une session de communication entre le terminal utilisateur appelant 10 et le terminal utilisateur appelé 20. Le message de contrôle de session SIP « INVITE » envoyé a par exemple le contenu suivant : INVITE sip: userl@operatorl.com SIP/2.0
To: <sip:userl@operatorl.com>
From: <sip: user2@operator2. com> tag=786
Call-ID: 3413an89KU
Contact : <sip :...> ; +VisioCon erenceAvecSousTitrage
Content-Type : application/sdp c=IN IP4 hostuser2.operator2.com
t=0 0
m=audio 49170 RTP/AVP 8
a=rtpmap:8 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=message 51789 TCP/MSRP *
a=accept-types : text/plain
a=path : msrp: //host . operator2. com : 7394/2s93i9ek2a tcp
Un entête du message de contrôle de session SIP « INVITE » indique plus particulièrement que la session de communication que souhaite établir le terminal utilisateur appelant 10 est une session de visioconférence avec sous-titrage. Ceci est indiqué par l'entête « Contact » du message de contrôle de session SIP « INVITE » qui comprend la valeur « VisioConferenceAvecSousTitrage ».
L'offre SDP contenue dans le message de contrôle de session SIP « INVITE » comprend en outre trois descriptions de flux média chacune identifiée par la lettre « m ». La première description décrit un flux audio, la deuxième un flux vidéo, et la troisième un flux de messagerie instantanée.
On notera qu'à ce stade, le message de contrôle de session SIP « INVITE » ne contient aucune information relative à une priorité des flux associés à la session de communication.
Lors d'une étape E2, l'entité de contrôle 32 (un serveur mandataire P-CSCF) reçoit le message de contrôle de session « INVITE » émis par le terminal utilisateur appelant 10. L'entité de contrôle 32 émet alors une demande de réservation de flux médias, pour les trois flux médias de l'offre SDP, auprès de l'entité de contrôle 31 (entité de contrôle de règles PCRF). La demande de réservation de flux médias est plus précisément un message de contrôle de ressources Diameter « AAR » (pour « AA-Request ») tel que défini dans le document RFC 4005.
Lors d'une étape E3, l'entité de contrôle 31 envoie un message d'acquittement de la demande de réservation de flux à l'entité de contrôle 32. Ce message d'acquittement est un message de contrôle de ressources Diameter « AAA » (pour « AA-Answer ») tel que défini dans le document RFC 4005. Lors d'une étape E4, l'entité de contrôle 32 relaye le message de contrôle de session SIP « INVITE » vers l'entité de contrôle 33 (entité supportant des fonctions d'interrogation I-CSCF et d'enregistrement S-CSCF).
Lors d'une étape E5, l'entité de contrôle 33 reçoit le message de contrôle de session SIP « INVITE », et détermine à partir de l'entête « Contact » comprenant la valeur « VisioConferenceAvecSousTitrage », qu'un service de visioconférence avec sous-titrage est à mettre en œuvre. Ce service est fourni par l'entité primaire de contrôle 30 (serveur d'application AS), et consiste par exemple à sous-titrer en temps réel dans un flux de messagerie instantanée les propos d'un utilisateur appelé du terminal utilisateur appelé 20 dans la langue d'un utilisateur appelant du terminal utilisateur appelant 10. La langue de l'utilisateur appelant est par exemple déterminée à partir de son profil d'abonné obtenue auprès d'un serveur d'abonné HSS (pour « Home Subscriber Server »). L'entité de contrôle 33 transmet alors le message de contrôle de session SIP « INVITE » à l'entité primaire de contrôle 30.
Lors d'une étape E6, l'entité primaire de contrôle 30 reçoit le message de contrôle de session SIP « INVITE » et identifie les trois flux médias contenus dans l'offre SDP. Une politique de priorisation de flux locale à l'entité primaire de contrôle 30 prévoit que pour ce service de visioconférence avec sous-titrage, un flux vidéo est moins prioritaire qu'un flux audio, ce dernier flux étant lui-même de priorité inférieure à un flux de messagerie instantanée associé à un sous- titrage temps réel. L'entité primaire de contrôle 30 applique la politique de priorisation aux flux médias contenus dans l'offre SDP. Pour cela, l'entité primaire de contrôle 30 génère une information de priorité indiquant une priorité relative de chacun des flux médias au sein de la session par rapport aux autres flux associés à la session. L'entité primaire de contrôle 30 insère plus précisément un attribut a=p dans les descriptions des flux audio, vidéo et de messagerie instantanée, respectivement valorisés à 1, 0 et 2. La valeur « 0 » correspondant à la priorité minimale pour un flux. L'information de priorité indique ainsi que le flux vidéo a la priorité la plus faible, que le flux audio est de priorité supérieure à celle du flux vidéo, et que le flux de messagerie instantanée bénéficie d'une priorité supérieure aux deux autres flux de la session. Le message de contrôle de session SIP « INVITE » contient alors une nouvelle offre SDP. Le message de contrôle de session SIP « INVITE » résultant a, par exemple, le contenu suivant :
INVITE sip: userl@operatorl.com SIP/2.0
To: <sip:userl@operatorl.com>
From: <sip: user2@operator2. com> tag=786
Call-ID: 3413an89KU
Content-Type: application/sdp m=audio 24567 RTP/AVP 8
a=prio : 1
a=rtpmap:8 PCMU/8000 m=video 26547 RTP/AVP 31
a=prio : 0
a=rtpmap:31 H261/90000
m=message 27564 TCP/MSRP *
a=prio : 2
a=accept-types : text/plain
a=path : msrp: //gwl .operator2. com: 7394/2s93i9ek2a tcp
Une fois l'information de priorité générée et insérée dans le message de contrôle de session SIP « INVITE », l'entité primaire de contrôle 30 la mémorise dans l'attente d'une réponse SDP, et retourne le message de contrôle de session SIP « INVITE » à l'entité de contrôle 33.
Lors d'une étape E7, l'entité de contrôle 33 achemine le message de contrôle de session
SIP « INVITE » à destination du terminal utilisateur appelé 20 par l'intermédiaire de l'entité de contrôle 53 (entité du réseau de communication 200 supportant des fonctions d'interrogation I- CSCF et d'enregistrement S-CSCF).
Lors d'une étape E8, l'entité de contrôle 53 achemine ensuite le message de contrôle de signalisation SIP « INVITE » vers l'entité secondaire de contrôle 52 (serveur mandataire du réseau de communication 200).
Lors d'une étape E9, l'entité secondaire de contrôle 52, à titre d'exemple, insère l'information de priorité dans un message de contrôle de ressources H.248 « Add Request», et l'envoie à l'entité média 40 (passerelle IMS-AGW du réseau de communication 200). Le message de contrôle de ressources H.248 « Add Request » est par exemple une demande de réservation de trois flux distincts (« stream » dans le message de contrôle de ressources H.248) pour chacun des flux médias de l'offre SDP. La description de chacun des flux média de l'offre SDP contenant l'information de priorité est plus précisément insérée dans le message de contrôle de ressources H.248 « Add Request ». A titre d'exemple le message de contrôle de ressources H.248 « Add Request » a la forme suivante :
MEGACO/2 [172.20.214.26]:2953
Transaction 14289 {
Context=63967{
Add=Terml {
Media}
Stream=l {Local}
m=audio ...
a=prio :1
}}
Stream=2{Local{
m=video ..
a=prio :0 Stream=3 {Local}
m=message ...
a=prio :2
Lors d'une étape E10, l'entité média 40 reçoit le message de contrôle de ressources H.248 « Add Request », et détermine à partir de l'information de priorité contenue dans le message, les priorités respectives des flux médias au sein de la session de communication. L'information de priorité est alors connue de l'entité média 40, qui peut avantageusement l'exploiter en mettant par exemple en œuvre des files d'attentes différentes pour traiter les flux de la session avec des priorités différenciées. L'entité média 40, après avoir traité le message de contrôle de ressources H.248 « Add Request », répond à l'entité secondaire de contrôle 52 par un message de contrôle de ressources H.248 « Add Reply ».
Lors d'une étape El 1, l'entité secondaire de contrôle 52 transmet le message de contrôle de session SIP « INVITE » vers le terminal utilisateur appelé 20.
Lors d'une étape E12, le terminal utilisateur appelé 20 reçoit l'offre SDP contenant l'information de priorité. Il est ainsi informé de la priorité de chaque flux associé à la session relativement aux autres flux. Le terminal utilisateur appelé 20 applique une ou plusieurs politiques de priorisation de flux configurées au niveau du terminal. Le terminal utilisateur appelé 20 génère par exemple un message de contrôle de session SIP « 200 OK » comprenant une réponse SDP avec des attributs valorisés identiques à ceux de l'offre SDP reçue. Le terminal utilisateur appelé 20 envoie cette réponse SDP à l'entité secondaire de contrôle 52. Le contenu du message de contrôle de session SIP « 200 OK » est à titre d'exemple le suivant : SIP/2.0 200 OK
To: sip: userl@operatorl.com; tag=345
From: <sip: user2@operator2. com> tag=786
Call-ID: 3413an89KU
Content-Type: application/sdp c=IN IP4 hostuserl.operatorl.com
t=0 0
m=audio 14744 RTP /AVP 8
a=prio : 1
a=rtpmap:0 PCMU/8000
m=video 18955 RTP /AVP 31
a=prio : 0
a=rtpmap:31 H261/90000
m=message 45646 TCP /MSRP *
a=prio : 2
a=accept-types : text/plain Lors d'une étape El 3, l'entité secondaire de contrôle 52 reçoit la réponse SDP envoyée par le terminal utilisateur appelé 20 et envoie un message de contrôle de ressources H.248 « Modify Request» à l'entité média 40. Le message de contrôle de ressources H.248 « Modify Request» permet d'informer l'entité média 40 des priorités associées aux flux de la session décrit dans la réponse SDP. Le message de contrôle de ressources H.248 « Modify Request» a par exemple le contenu ci-dessous :
MEGACO/2 [172.20.214.26]:2953
Transaction 14289 {
Context=63967{
Modify=Terml {
Media}
Stream=l {Local}
m=audio ...
a=prio :1
}
Remote{
m=audio ...
a=prio :1
}}
}
Stream=2{Local{
m=video ...
a=prio :0
}
Remote {
m=audio ...
a=prio :0
} }
}
Stream=3 {Local}
m=message ...
a=prio :2
} Remote {
m=audio ..
a=prio :2 Lors d'une étape E14, l'entité média 40 acquitte le message de contrôle de ressources reçu à l'étape E13 par l'envoi d'un message de contrôle de ressources « Modify Reply » a l' entité secondaire de contrôle 52.
Lors d'une étape E15, l'entité secondaire de contrôle 52 relaye le message de contrôle de session SIP « 200 OK » à l'entité de contrôle 53, qui elle-même le relaye lors d'une étape E16 à l'entité de contrôle 33 du réseau de communication 100.
Lors d'une étape E17, l'entité de contrôle 33 transmet le message de contrôle de session SIP « 200 OK » à l'entité primaire de contrôle 30. Cette dernière dispose alors de l'offre SDP mémorisée lors de l'étape E6 et de la réponse SDP correspondante obtenue à partir du message de contrôle de session SIP « 200 OK ».
Lors d'une étape El 8, l'entité primaire de contrôle 30 peut alors mettre à jour si nécessaire l'information de priorité contenue dans la réponse SDP. C'est par exemple le cas lorsque l'entité primaire de contrôle 30 détermine, à partir d'un élément inséré par le terminal utilisateur appelé 20 dans le message de contrôle de session contenant la réponse SDP à l'étape E12, que l'utilisateur appelé du terminal utilisateur appelé 20 utilise une langue qui s'avère être identique à celle utilisée par l'utilisateur appelant. Ce dernier flux ne revêtant plus la même importance pour l'utilisateur appelant (à quelques exceptions près), l'entité primaire de contrôle 30 modifie l'information de priorité de sorte que la priorité du flux de messagerie instantanée soit inférieure à celle du flux audio. Pour cela, la priorité associée au flux de messagerie instantanée pour le sous-titrage temps réel de la visioconférence est diminuée en décrémentant sa valeur d'une unité, et la priorité associée au flux audio est augmentée en incrémentant sa valeur d'une unité. L'entité primaire de contrôle 30 renvoie ensuite un message de contrôle de session SIP « 200 OK » avec une réponse SDP comportant la nouvelle information de priorité.
Lors d'une étape E19, l'entité de contrôle 33 transmet le message de contrôle de session SIP « 200 OK » à l'entité de contrôle 32.
Lors d'une étape E20, l'entité de contrôle 32 reçoit le message de contrôle de session « 200 OK ». L'entité de contrôle 32 émet alors une nouvelle demande de réservation de flux médias, pour les trois flux médias de la réponse SDP, auprès de l'entité de contrôle 31. La demande de réservation de flux médias, de même qu' à l'étape E2, est un message de contrôle de ressources Diameter « AAR ». Le message de contrôle de ressources Diameter « AAR » comprend en outre pour chaque flux média de la session, un attribut « Reservation-Priority » valorisé avec les nouvelles valeurs de priorité associées à ces flux dans la réponse SDP. Le message de contrôle de ressources Diameter « AAR » envoyé est par exemple : Diameter Protocol
Version: 0x01
Length: ..
Flags: ...
Command Code: 265 AA Applicationld: 3GPP Rx (16777236)
Hop-by-Hop Identifier:
End-to-End Identifier:
AVP: Session-Id(263) 1=.. f=-...
AVP: Auth-Application-Id(258) 1=.. f=- ..- val=3GPP Rx (16777236)
AVP: Origin-Host(264) 1=.. f=-..- val=..
AVP: Origin-Realm(296) 1=.. f=-..- val=
AVP: Destination-Host(293) 1=.. f=- .. val=
AVP: Destination-Realm(283) 1=.. f=- .. val=...
AVP: Media-Component-Description(517) 1=.. f=..- vnd=TGPP
AVP Code: 517 Media-Component-Description
AVP Flags: ..
AVP Length: ..
AVP Vendor Id: 3GPP (10415)
Media-Component-Description: ...
AVP: Media-Component-Number(518) 1=.. f=..- vnd=TGPP val=l
AVP: Media-Type(520) 1=.. f=..- vnd=TGPP val=AUDIO
AVP Reservation-Priority(458) 1=.. vnd=TGPP val= PRIORITY-TWO(2).
AVP: Media-Component-Number(518) 1=.. f=..- vnd=TGPP val=2
AVP: Media-Type(520) 1=.. f=..- vnd=TGPP val= VIDEO
AVP Reservation-Priority(458) 1=.. vnd=TGPP val=DEFAULT(0)
AVP: Media-Component-Number(518) 1=.. f=..- vnd=TGPP val=3
AVP: Media-Type(520) 1=.. f=..- vnd=TGPP val=MESSAGE
AVP Reservation-Priority(458) 1=.. vnd=TGPP val=PRIORITY-ONE(l).
Lors d'une étape E21, l'entité de contrôle 31 envoie un message d'acquittement de la demande de réservation de flux à l'entité de contrôle 32. De même qu'à l'étape E3, ce message d' acquittement est un message de contrôle de ressources Diameter « AAA ».
Enfin lors d'une étape E22, l'entité de contrôle 32 transmet le message de contrôle de session SIP « 200 OK » au terminal utilisateur appelant 10. Ce message comprend les priorités relatives associées à chaque flux de la session telles que configurées par l'entité primaire de contrôle 30 lors de l'étape E18. Le terminal utilisateur appelant peut optionnellement réutiliser localement l'information de priorité contenue dans la réponse SDP, afin de mettre en œuvre un traitement prioritaire d'un ou plusieurs flux relativement aux autres flux de la session.
Dans un autre mode de réalisation, l'information de priorité est directement insérée dans un entête d'un message de contrôle de session SIP, par exemple un entête « Flow-Priority », plutôt que dans une offre ou une réponse SDP contenue dans ce message. L'information de priorité correspond alors à une liste ordonnée de valeurs dont l'ordre correspond à l'ordre des descriptions de flux associés à la session dans l'offre ou la réponse SDP contenue dans le message de contrôle de session SIP. Les valeurs de la liste indiquent alors une priorité relative pour chacun des flux au sein de la session selon l'ordre de la liste. Plus précisément, à une n-ième description de flux d'une offre ou réponse SDP correspond la n-ième valeur de priorité de la liste de valeurs associées à l'entête « Flow-Priority ». A titre d'exemple, un message de contrôle de session SIP « INVITE » selon ce mode de réalisation a la forme suivante : INVITE sip: userl@operatorl.com SIP/2.0
To: <sip:userl@operatorl.com>
From: <sip: user2@operator2. com> tag=786
Call-ID: 3413an89KU
Contact : <sip :...> ; +VisioCon erenceAvecSousTitrage
Flow-Priority : 1, Q, 2
Content-Type : application/sdp c=IN IP4 hostuser2.operator2.com
t=0 0
m=audio 49170 RTP/AVP 8
a=rtpmap:8 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=message 51789 TCP/MSRP *
a=accept-types : text/plain
a=path : msrp: //host . operator2. com : 7394/2s93i9ek2a tcp Dans un autre mode de réalisation, à l'étape E12, le terminal utilisateur appelé indique dans sa réponse SDP des attributs valorisés différents de ceux compris dans l'offre SDP qu'il a reçu. Le terminal utilisateur appelé peut ainsi proposer une priorisation des flux de la session différente de celle proposée ou retenue par une entité de contrôle ou le cas échéant par une entité média ou un terminal utilisateur de l'un des réseaux 100 ou 200.
Dans un autre mode de réalisation, une politique de priorisation des flux médias associés à la session est mise en œuvre par le terminal utilisateur appelant 10 qui indique l'information de priorité dans l'offre SDP envoyée à l'étape El. A l'étape E6, l'entité primaire de contrôle 30, selon un paramétrage prédéfini, peut alors modifier la priorisation des flux médias décrits dans l'offre SDP ou encore conserver l'information de priorité telle qu'indiquée par le terminal utilisateur appelant 10. Dans ce dernier cas, l'entité primaire de contrôle 30 obtient l'information de priorité indiquant une priorité relative dudit flux au sein de la session par rapport aux autres flux associés à la session, directement à partir du message de contrôle de session SIP « INVITE » reçu.
Dans un autre mode de réalisation, l'entité primaire de contrôle et l'entité secondaire de contrôle sont une même entité. L'entité de contrôle obtenant à partir d'un message de contrôle de session, ou générant, l'information de priorité, insère également cette information de priorité dans un message de contrôle de ressources.
Dans un autre mode de réalisation, l'entité secondaire de contrôle 52 met en œuvre une étape optionnelle de modification de l'information de priorité avant insertion de cette dernière dans un message de contrôle de ressources à l'étape E9. L'information de priorité est par exemple modifiée selon une politique opérateur visant à donner une priorité moins élevée aux flux les plus consommateurs de bande passante en cas de congestion réseau. Un traitement identique peut également être mis en œuvre par l'entité de contrôle 32 dans le réseau de communication 100.
Le procédé a été décrit pour une mise en œuvre d'un service de visioconférence avec sous- titrage, il n'existe cependant aucune limitation au type de service requérant, initiant ou bénéficiant de la priorisation des flux médias.
De même, le procédé a été décrit avec une mise en œuvre dans deux réseaux de communication 100 et 200. Il n'existe cependant pas de limitation quant au nombre de réseaux de communication dans lesquels le procédé est mis en œuvre. Le procédé peut par exemple aisément être mis en œuvre dans un même réseau pour une session de communication entre terminaux abonnés de ce réseau.
Il n'existe par ailleurs aucune limitation quant aux entités de contrôle susceptibles de mettre en œuvre le procédé décrit. Une telle entité de contrôle appartient par exemple au groupe d'entités de contrôle suivant : entité P-CSCF (pour « Proxy - Call Server Control Function »), entité I-CSCF (pour « Interrogating - Call Server Control Function »), entité S-CSCF (« Serving - Call Server Control Function »), entité AS (pour « Application Server »), entité MGCF (pour « Media Gateway Controller Function »), entité IBCF (pour « Interconnection Border Control Function »), terminal utilisateur.
De même, il n'existe aucune limitation quant aux entités médias susceptibles de mettre en œuvre le procédé décrit. Une telle entité média appartient par exemple au groupe d'entités médias suivant : entité AGW (pour « Access Gateway »), entité C-BGF (pour « Core - Border Gateway Function »), entité P-GW (pour « PDN Gateway »), entité MRFP (pour « Multimedia Resource Function Processor »), entité TrGW (pour « Transition Gateway »), terminal utilisateur.
Les précédents modes de réalisation ont été décrits pour le traitement d'un message de contrôle de session SIP « INVITE » et d'un message de réponse correspondant SIP « 200 OK ». Il n'existe cependant pas de limitations quant aux types de requêtes de service traitées. Le procédé de traitement mis en œuvre par exemple pour une requête SIP « UPDATE » est équivalent à celui mis en œuvre pour traiter une requête SIP « INVITE ».
La figure 3 représente une entité secondaire de contrôle 52 agencée pour prioriser un flux média appartenant à une pluralité de flux médias associée à une session de communication. L'entité secondaire de contrôle 52 comprend :
- un module d'obtention 310 et/ou un module de génération 320, agencés pour obtenir à partir d'un message de contrôle de session, ou générer, une information de priorité indiquant une priorité relative d'un flux au sein de la session par rapport aux autres flux de la pluralité de flux médias ; - un module d'insertion 330, agencé pour insérer ladite information de priorité dans un message de contrôle de ressources à destination d'une entité média. Dans un mode de réalisation particulier, l'entité de contrôle comprend également un module de modification 340, agencé pour modifier l'information de priorité préalablement à son insertion dans le message de contrôle de ressources par le module d'insertion 330.
Dans un autre mode de réalisation particulier, le module d'obtention 310 est agencé pour obtenir l'information de priorité à partir d'une offre ou d'une réponse SDP comprise dans le message de contrôle de session, l'information de priorité étant un attribut d'une description du flux comprise dans l'offre ou la réponse SDP.
Dans un autre mode de réalisation particulier, l'entité de contrôle 52 comprend un module de réception 350 agencé pour recevoir un message de contrôle de session comprenant une offre ou une réponse SDP. Cette offre ou réponse SDP comprend une liste ordonnée de descriptions des flux associés à la session. Le module d'obtention est par ailleurs agencé pour obtenir l'information de priorité à partir d'un entête du message de contrôle de session. Cet entête comprend l'information de priorité sous la forme d'une liste ordonnée de valeurs. Les valeurs sont ordonnées selon un même ordre que les descriptions de flux associées à la session. L'entité de contrôle comprend en outre un module de détermination 360, agencé pour déterminer, à partir de la liste ordonnée de valeurs, et de la liste ordonnée de descriptions des flux associés à la session, une priorité relative pour chacun des flux au sein de la session selon l'ordre des listes.
La figure 4 représente une entité primaire de contrôle 30, dans un réseau de communication. Cette entité met en œuvre des signaux de contrôle de session. L'entité de contrôle 30 comprend :
- un module de génération 410, agencé pour extraire et modifier à partir d'un message de contrôle de session, ou générer, une information de priorité indiquant une priorité relative d'un flux au sein d'une session de communication, par rapport à d'autres flux d'une pluralité de flux médias associée à la session ;
- un module d'insertion 420, agencé pour insérer l'information dans un message de contrôle de session à destination d'une entité secondaire de contrôle.
L'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et/ou logiciels, apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit précédemment pour le module concerné.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel. Un tel composant logiciel est stocké en mémoire puis chargé et exécuté par un processeur de données d'une entité physique et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc).
De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware). Il peut s'agir d'un composant matériel programmable ou non, avec ou sans processeur intégré pour l'exécution de logiciel. Il s'agit par exemple d'un circuit intégré, d'une carte à puce, d'une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.
Dans un mode de réalisation particulier, les modules 310, 320, 330, 340, 350 et 360 sont agencés pour mettre en œuvre le procédé de priorisation précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter celles des étapes du procédé de priorisation précédemment décrit, mises en œuvre par une entité secondaire de contrôle. L'invention concerne donc aussi :
- un programme pour une entité secondaire de contrôle, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de priorisation précédemment décrit, lorsque ledit programme est exécuté par ladite entité secondaire de contrôle ;
- un support d'enregistrement lisible par une entité secondaire de contrôle sur laquelle est enregistré le programme pour une entité secondaire de contrôle.
De même, les modules 410 et 420 sont agencés pour mettre en œuvre le procédé de priorisation précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter celles des étapes du procédé de priorisation précédemment décrit, mises en œuvre par une entité primaire de contrôle. L'invention concerne donc aussi :
- un programme pour une entité primaire de contrôle, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de priorisation précédemment décrit, lorsque ledit programme est exécuté par ladite entité primaire de contrôle;
- un support d'enregistrement lisible par une entité primaire de contrôle sur laquelle est enregistré le programme pour une entité primaire de contrôle.
Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal électrique, optique ou radio, ou un réseau de télécommunication.

Claims

REVENDICATIONS
1. Procédé de priorisation d'un flux média appartenant à une pluralité de flux médias associée à une session de communication, comprenant :
- une obtention (E8, E19), à partir d'un message de contrôle de session, ou une génération (E6), par une première entité de contrôle (30, 32, 52), d'une information de priorité indiquant une priorité relative dudit flux au sein de la session par rapport aux autres flux de ladite pluralité de flux médias ; et
- une insertion (E9, E20), par une deuxième entité de contrôle (32, 52), de ladite information de priorité, dans un message de contrôle de ressources à destination d'une entité média (10, 40).
2. Procédé selon la revendication 1, comprenant en outre une modification de l'information de priorité préalablement à son insertion dans ledit message de contrôle de ressources.
3. Procédé selon la revendication 1, dans lequel ladite information de priorité est un attribut d'une description dudit flux comprise dans une offre ou une réponse SDP associée au message de contrôle de session.
4. Procédé selon la revendication 1 , dans lequel ledit flux appartenant à une pluralité de flux médias respectivement associé à une description de flux pour ladite session de communication, lesdites descriptions de flux étant ordonnées dans une offre ou une réponse SDP associé au message de contrôle de session, ladite information de priorité est une liste ordonnée de valeurs, comprise dans un entête dudit message de contrôle de session, dont l'ordre correspond à l'ordre desdites descriptions de flux dans ladite offre ou réponse SDP, lesdites valeurs indiquant une priorité relative pour chacun des flux au sein de ladite session selon l'ordre de ladite liste.
5. Procédé selon la revendication 1, dans lequel ledit message de contrôle de session est un message SIP.
6. Entité de contrôle (52), dite « entité secondaire de contrôle », dans un réseau de communication, agencée pour prioriser un flux média appartenant à une pluralité de flux médias associée à une session de communication, comprenant :
- un module d'obtention (310) et/ou un module de génération (320), agencés pour obtenir à partir d'un message de contrôle de session, ou générer, une information de priorité indiquant une priorité relative dudit flux au sein de la session par rapport aux autres flux de ladite pluralité de flux médias ; et - un module d'insertion (330), agencé pour insérer ladite information de priorité dans un message de contrôle de ressources à destination d'une entité média (10, 40).
7. Entité de contrôle selon la revendication 6, comprenant en outre un module de modification (340), agencé pour modifier l'information de priorité préalablement à son insertion dans ledit message de contrôle de ressources par le module d'insertion (330).
8. Entité de contrôle selon la revendication 6, dans laquelle ledit module d'obtention (310) est agencé pour obtenir ladite information de priorité à partir d'une offre ou d'une réponse SDP comprise dans le message de contrôle de session, ladite information de priorité étant un attribut d'une description dudit flux comprise dans ladite offre ou réponse SDP.
9. Entité de contrôle selon la revendication 6, dans laquelle :
- un module de réception (350) est agencé pour recevoir un message de contrôle de session comprenant une offre ou une réponse SDP, ladite offre ou réponse SDP comprenant une liste ordonnée de descriptions des flux associés à ladite session ;
- ledit module d'obtention (310) est agencé pour obtenir ladite information de priorité à partir d'un entête du message de contrôle de session, ladite information de priorité étant une liste ordonnée de valeurs comprise dans ledit entête, ordonnées selon un même ordre que lesdites descriptions de flux associées à ladite session ;
et comprenant en outre un module de détermination (360), agencé pour déterminer, à partir de la liste ordonnée de valeurs, et de la liste ordonnée de descriptions des flux associés à ladite session, une priorité relative pour chacun des flux au sein de ladite session selon l'ordre desdites listes.
10. Entité de contrôle (30), dite « entité primaire de contrôle », dans un réseau de communication, mettant en œuvre des signaux de contrôle de session, comprenant :
- un module de génération (410), agencé pour extraire et modifier à partir d'un message de contrôle de session, ou générer, une information de priorité indiquant une priorité relative d'un flux au sein d'une session de communication, par rapport à d'autres flux d'une pluralité de flux médias associée à ladite session ; et
- un module d'insertion (420), agencé pour insérer ladite information dans un message de contrôle de session à destination d'une autre entité de contrôle (52), dite « entité secondaire de contrôle ».
11. Entité média (40), dans un réseau de communication, apte à extraire, depuis un message de contrôle de ressources H.248 reçu depuis une entité de contrôle selon l'une des revendications 6 à 9, une information de priorité indiquant une priorité relative d'un flux au sein d'une session de communication, par rapport à d'autres flux d'une pluralité de flux médias associée à ladite session.
12. Programme pour une entité de contrôle, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 5, lorsque ledit programme est exécuté par ladite entité de contrôle.
13. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 5.
EP16714490.6A 2015-03-31 2016-03-16 Procédé de priorisation de flux médias dans un réseau de communications Ceased EP3278532A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1552771A FR3034608A1 (fr) 2015-03-31 2015-03-31 Procede de priorisation de flux medias dans un reseau de communications
PCT/FR2016/050584 WO2016156694A1 (fr) 2015-03-31 2016-03-16 Procédé de priorisation de flux médias dans un réseau de communications

Publications (1)

Publication Number Publication Date
EP3278532A1 true EP3278532A1 (fr) 2018-02-07

Family

ID=54260835

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16714490.6A Ceased EP3278532A1 (fr) 2015-03-31 2016-03-16 Procédé de priorisation de flux médias dans un réseau de communications

Country Status (4)

Country Link
US (1) US11223658B2 (fr)
EP (1) EP3278532A1 (fr)
FR (1) FR3034608A1 (fr)
WO (1) WO2016156694A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10972525B2 (en) * 2016-08-15 2021-04-06 Comcast Cable Communications, Llc Targeted buffer priority management
US10938810B2 (en) * 2016-08-22 2021-03-02 Viasat, Inc. Methods and systems for efficient content delivery
US11075973B2 (en) * 2019-10-23 2021-07-27 Verizon Patent And Licensing Inc. Systems and methods for prioritized sip services using UE-specified sip register messages
US11662975B2 (en) * 2020-10-06 2023-05-30 Tencent America LLC Method and apparatus for teleconference
JP2022182019A (ja) * 2021-05-27 2022-12-08 シャープ株式会社 会議システム、会議方法、及び会議プログラム
US20230087807A1 (en) * 2021-09-23 2023-03-23 Apple Inc. Techniques for activity based wireless device coexistence

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050237931A1 (en) * 2004-03-19 2005-10-27 Marconi Communications, Inc. Method and apparatus for conferencing with stream selectivity

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2813744C (fr) * 2000-03-03 2017-05-09 Qualcomm Incorporated Procede et appareil pour participer a des services de communications de groupe dans un systeme de communication existant
US6477150B1 (en) 2000-03-03 2002-11-05 Qualcomm, Inc. System and method for providing group communication services in an existing communication system
US7161939B2 (en) * 2001-06-29 2007-01-09 Ip Unity Method and system for switching among independent packetized audio streams
EP1331785B1 (fr) * 2002-01-23 2005-04-20 Sony International (Europe) GmbH Procédé de transmission de qualité de service de bout en bout en utilisant un protocole de nègociation de bout en bout (E2ENP)
DE102005050588B4 (de) * 2005-10-21 2010-07-08 Siemens Ag Signalisierung bezüglich des Aufbaus von H.324 Videotelefonie zwischen einer Mediagateway und einem Controller
US7587031B1 (en) * 2005-12-22 2009-09-08 Nortel Networks Limited Forced hold call handling in a VoP environment
US7660321B2 (en) * 2006-03-01 2010-02-09 Alcatel-Lucent Usa Inc. System and method for prioritizing session initiation protocol messages
US7801129B2 (en) * 2006-04-27 2010-09-21 Alcatel-Lucent Usa Inc. Method and apparatus for SIP message prioritization
US8077626B2 (en) * 2006-07-14 2011-12-13 Qualcomm Incorporated Quality of service (QoS) aware establishment of communication sessions
US20080089324A1 (en) * 2006-10-13 2008-04-17 Cisco Technology, Inc Indicating or remarking of a dscp for rtp of a flow (call) to and from a server
CN101257433B (zh) * 2007-03-01 2011-09-14 华为技术有限公司 实现网络地址转换穿越的方法和系统
CN101459664B (zh) * 2007-10-22 2010-10-20 华为技术有限公司 一种获取iptv业务媒体描述信息的方法及装置
JP5823866B2 (ja) * 2008-11-05 2015-11-25 テレフオンアクチーボラゲット エル エム エリクソン（パブル） コマンドの条件実行
CN101741821A (zh) * 2008-11-07 2010-06-16 华为技术有限公司 一种实现包过滤的方法、媒体网关及系统
CA2742609A1 (fr) * 2008-11-26 2010-06-03 Telefonaktiebolaget L M Ericsson (Publ) Mecanismes de file d'attente pour acces lte et reseaux sae permettant un  service de priorite base sur un systeme ims de bout en bout
KR20130010910A (ko) * 2008-12-05 2013-01-29 소우셜 커뮤니케이션즈 컴퍼니 실시간 커널
KR101489432B1 (ko) * 2008-12-16 2015-02-03 삼성전자주식회사 접속 설정 프로토콜 기반의 브이오 아이피 네트워크에서 미디어 코덱 결정 방법 및 장치
EP2499757B1 (fr) * 2009-11-09 2019-07-03 Samsung Electronics Co., Ltd. Procédé et système de support de continuité d'appel radio vidéo unique pendant un transfert
US9294526B2 (en) * 2009-12-28 2016-03-22 Microsoft Technology Licensing, Llc Managing multiple dynamic media streams
FR2965690A1 (fr) * 2010-09-30 2012-04-06 France Telecom Procede de gestion de la priorite de flux media preliminaires
WO2012095165A1 (fr) * 2011-01-10 2012-07-19 Telefonaktiebolaget Lm Ericsson (Publ) Mise en cache d'annonces en bordure d'un réseau de télécommunication à commutation de paquets
US8966095B2 (en) * 2011-07-08 2015-02-24 Avaya Inc. Negotiate multi-stream continuous presence
WO2013019261A1 (fr) * 2011-08-01 2013-02-07 Intel Corporation Authentification unique (sso) multi-saut pour un serveur mandataire/itinérance de fournisseur d'identité (idp)
EP2761881A4 (fr) * 2011-09-30 2015-06-17 Intel Corp Améliorations de qualité d'expérience sur des réseaux sans fil
US8755342B2 (en) * 2011-10-05 2014-06-17 Cisco Technology, Inc. System and method for dynamic bearer selection for immersive video collaboration in mobile wireless networks
EP2856727B1 (fr) * 2012-06-04 2018-06-06 Telefonaktiebolaget LM Ericsson (publ) Procédés et appareil pour la transmission de médias dans des réseaux de télécommunication
WO2013187873A1 (fr) * 2012-06-11 2013-12-19 Intel Corporation Distribution de flux multimédias disposés en couches, au moyen d'une pluralité de liaisons radios
US9148306B2 (en) * 2012-09-28 2015-09-29 Avaya Inc. System and method for classification of media in VoIP sessions with RTP source profiling/tagging
US20140112130A1 (en) * 2012-10-23 2014-04-24 Electronics And Telecommunications Research Institute Method for setting packet forwarding rule and control apparatus using the method
US8867731B2 (en) * 2012-11-05 2014-10-21 Genesys Telecommunications Laboratories, Inc. System and method for web-based real time communication with optimized transcoding
US20140244798A1 (en) * 2013-02-27 2014-08-28 Cisco Technology, Inc. TCP-Based Weighted Fair Video Delivery
US10027586B2 (en) * 2013-03-15 2018-07-17 Star2Star Communications, LLC Network address family translation method and system
US20160261517A1 (en) * 2013-11-11 2016-09-08 Nec Corporation Device, session processing quality stabilization system, priority processing method, transmission method, relay method, and program
EP2924945B1 (fr) * 2014-03-26 2017-02-22 Alcatel Lucent Serveur d'appel pour l'optimisation de ressources de passerelle
US9571552B2 (en) * 2014-09-10 2017-02-14 Genband Us Llc Systems, methods, and computer program products for selecting codecs to optimize resource utilization
US9699237B2 (en) * 2015-03-30 2017-07-04 Oracle International Corporation Managed media relay selection for real-time communications

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050237931A1 (en) * 2004-03-19 2005-10-27 Marconi Communications, Inc. Method and apparatus for conferencing with stream selectivity

Also Published As

Publication number Publication date
US11223658B2 (en) 2022-01-11
FR3034608A1 (fr) 2016-10-07
WO2016156694A1 (fr) 2016-10-06
US20180176265A1 (en) 2018-06-21

Similar Documents

Publication Publication Date Title
EP3278532A1 (fr) Procédé de priorisation de flux médias dans un réseau de communications
EP3085065A1 (fr) Procédé de mise a jour dynamique d&#39;informations obtenues de la part d&#39;un serveur dns
EP2366238A1 (fr) Procede et systeme de regulation du trafic de redemarrage dans un reseau de telecommunications
EP2920942B1 (fr) Selection de periodes de rafraichissement dans un reseau ip
EP2816778A1 (fr) Etablissement de communication entre une application Web et un terminal
EP2396950B1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
EP3298749B1 (fr) Procédé de contrôle d&#39;une session relative a un service
EP3560168B1 (fr) Classification et aiguillage de messages de contrôle d&#39;une infrastructure de communications
WO2020128258A1 (fr) Procédé de basculement d&#39;une communication de tcp sur udp
WO2007144545A1 (fr) Unite et procede de definition d&#39;une regle de session dans un reseau
WO2019102117A1 (fr) Procédé de propagation d&#39;informations concernant la bande passante allouée à un usager d&#39;un réseau ip
WO2015197937A1 (fr) Procédé de sélection dynamique par un appelant parmi une pluralité de terminaux d&#39;un appelé
WO2015181505A1 (fr) Procédé pour informer une entité d&#39;un réseau ip du type de réseau d&#39;accès utilisé par un terminal
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
EP3646578B1 (fr) Procédé de synchronisation d&#39;état média
EP2801178B1 (fr) Procédé dynamique de détermination d&#39;une liste de services dans un réseau sip
EP3583757B1 (fr) Procédé de changement de réseau mobile
WO2015044566A1 (fr) Conversion de protocole enrichie dans un réseau de télécommunications pour la fourniture de services à qualité de service améliorée
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
WO2012049404A1 (fr) Procede de traitement des flux de presence dans un reseau sip

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20171026

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20190611

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20210701