EP2606623A1 - Etablissement d'un flux de paquets possédant une qualité de service symétrique par négociation de l'indicateur de qualité - Google Patents

Etablissement d'un flux de paquets possédant une qualité de service symétrique par négociation de l'indicateur de qualité

Info

Publication number
EP2606623A1
EP2606623A1 EP11743092.6A EP11743092A EP2606623A1 EP 2606623 A1 EP2606623 A1 EP 2606623A1 EP 11743092 A EP11743092 A EP 11743092A EP 2606623 A1 EP2606623 A1 EP 2606623A1
Authority
EP
European Patent Office
Prior art keywords
value
equipment
field
transmitted
received
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.)
Withdrawn
Application number
EP11743092.6A
Other languages
German (de)
English (en)
Inventor
Christian Cayeux
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.)
Alcatel Lucent SAS
Original Assignee
Alcatel Lucent SAS
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 Alcatel Lucent SAS filed Critical Alcatel Lucent SAS
Publication of EP2606623A1 publication Critical patent/EP2606623A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2408—Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H04L47/2433—Allocation of priorities to traffic types
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441—Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]
    • 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 present invention is reluctive to reseve multimedia communication.
  • These networks can transmit traffic of different sizes (voice, video, data ...) corresponding to voried applications: telephony, videophony, internet noviggtion, file downloading, real-time textual discussion ("instant messaging” or "instant messaging”). chat ”) ...
  • This traffic is conventionally transmitted in the form of packet streams, in particular IP packet (for" Internet Protocol ").
  • IP packet for" Internet Protocol ".
  • the same application message can be transmitted in several IP packets and it must be reconstructed on receipt before delivery to the application.
  • These applications and these types of traffic are associated with different quality of service criteria and, since the transmission capacity of the networks is limited, there appears to be a need to give greater priority to certain applications / traffic pairs than to others. For example, in the case of a voice call, the delay taken by some packets may cause a loss of voice quality. In the worst case, the audio message may be inaudible or incomprehensible.
  • DiffServ mechanism as defined in particular in RFC 2474 of the I ETF, "Definition of the Differentiated Field Services (DS Field) in the IPv A and IPv6 Headers".
  • This DiffServ mechanism is to insert into the packets of a stream a field, DS Field, the value of which determines a class of service (or code-point).
  • Network devices located on the path of the packet stream must read the DS Field and process retransmission of packets based on this value, with the highest class of service packets being the highest. priority.
  • Each device inserting a class of service into a packet stream determines the value according to its own mechanisms and according to the different flows that it may have to manage. These mechanisms may depend on the supplier of the equipment.
  • bidirectional communication it can often result in each of the two terminals (or associated access equipment) using different policies to determine the class of service.
  • the flows of each direction belong to different classes of service and, therefore, the behavior of the communication network with respect to them is different and generate different perceived qualities of service for the two directions.
  • an equipment flow connected to an echo-sensitive network could require a decrease in the delay. If this is not applied, users may suffer from echo problems (the delay parameter amplifies the echo perception).
  • the object of the invention is to overcome this problem by providing a mechanism that guarantees the same perceived quality of service for all the directions of a communication session.
  • the invention relates to a network equipment comprising means for establishing a packet flow with another equipment through a communication network, means for determining a first value of a priority indicator in depending on the type of this data flow and means for exchanging with this other equipment signaling messages to allow the establishment of the data flow.
  • the equipment of the invention furthermore has means for inserting this first value in the first of the signaling messages and means for, on receipt of a signaling message (si, s2) comprising a value received from the indicator of priority, determining a value issued from the received value and inserting this value transmitted in the packets of the packet stream.
  • the invention also relates to a method for establishing a packet flow with another equipment through a communication network, comprising a step of determining a first value of a priority indicator based on the type of data flow and a step of exchange, with this other equipment, signaling messages to allow the establishment of data flow.
  • the first value is inserted into the first of these signaling messages.
  • AT receiving a signaling message having a value received from this priority indicator a value transmitted is determined from this received value, and inserted into the packets of the packet stream.
  • the value emitted is the maximum value between the value received and the value determined by the equipment as a function of the type of packet flow.
  • the priority indicator may be in accordance with the DiffServ mechanism and the equipment may then be adapted to insert the third value in the "DS Field" field of the packet stream.
  • the value sent can be inserted into an SDP compliant attribute in the signaling messages.
  • the value sent can be inserted into a "DS Field" field of packets of the packet stream.
  • the implementation of a session on a communication network generally comprises two phases: a phase of establishment, during which the parties to the session exchange signaling messages, and a phase of communication proper during which the parties exchange the data: voice, video, text ...
  • two pieces of equipment A and B are connected via a communication network N.
  • the invention is quite capable of being applied with more parts, and so in the case of "conferences" audios or videos.
  • Both devices can be communication terminals: fixed or mobile phones, computers, PDAs (Personal Digital Assistants PDAs) and so on.
  • the communication may be a communication between a content server and a communication terminal allowing the user of the latter to access audio, video content ... It may also be virtual equipment.
  • the equipment A initiates the creation of the communication session. It sends equipment B a first signaling message, SI.
  • This message may typically be a SIP compliant invitation message as defined in IETF RFC 3261, Session invitation Protocol.
  • This "Invite” message may be relayed by various devices, such as "SIP Proxy", within the communication network N. These are not shown in FIG. 1 and will not be described any more insofar as they do not influence the invention itself.
  • the equipment A has means for determining a value of a priority indicator p as a function of the type of the data stream that must compose the communication session.
  • the type of data to be transmitted is called “type” here: video, audio, audio-video, text, real-time text of the "messaging” or “chat” type, etc.
  • the type may furthermore be more accurate and it may be possible to decline a grosgrain type as "video" into several types.
  • the supplier of the equipment A generally sets a correspondence table between these types of data streams and a value of the priority indicator.
  • This priority indicator is preferably in accordance with the DiffServ mechanism as specified by RFC 2474, "Definition of the Differentiated Field Service (DS Field) in the IPv4 and IPv6 Headers".
  • the equipment A can be provided to directly have a correspondence table between type of data flow and "codepoint".
  • the equipment has means for inserting this value, v1, into the first signaling message S I, that is to say the invitation message.
  • This value can be inserted into an appropriate SDP (Session Description Protocol) attribute as defined by RFC 4566 of the IET.
  • This attribute can be 8-bit encoded. For example, it can be called "Traffic-class”.
  • this attribute can be of the form:
  • the value that can be taken by this attribute is an integer between 0 and 255.
  • the equipment B On receipt of the signaling message SI, the equipment B must read this received value vl of the priority indicator p.
  • I l refers to the transmitting equipment Has a signaling message S2 which, conventionally, is a message SI P "200 Ok". It also has means for inserting in this signaling message S2 an "emitted" value of the priority indicator p. This value sent is determined from the value received v1. According to one embodiment of the invention, this transmitted value (v3) is equal to the received value.
  • this value emitted is equal to the maximum between the received value v1 and a value determined by the type of data flow.
  • the equipment A has means for determining a value v2 for the priority indicator p associated with the type of data flow. It can determine the type of data flow through other fields and attributes of the SI signaling message.
  • the attribute "m" of the description of the medium, SDP can be used to determine this value v2.
  • the equipment A may return a signaling message according to S3. This may be a SIP "ACK" message.
  • the devices A and B also have means for establishing the packet flow F through the communication network N, according to the modalities and parameters negotiated during the signaling messages (CODEC etc.).
  • this value may be in accordance with DiffServ specifications.
  • it may be 8-bit coded with a 6-bit DSCP field (Differeniiaied Services CodePoinf) as specified in paragraph 3 of RFC 2474 of the I ETF.
  • the value of the priority indicator can be directly inserted into the field "DS Field" of the outgoing packets.
  • the insertion into the DS field of the packets is carried out in a manner known per se.
  • the way in which the inserted value is determined is, on the other hand, novel: according to the invention, an equipment according to the invention must therefore choose as the DiffServ indicator to use for a packet flow the value received in the last signaling message received concerning this value. flux.
  • the packet stream has the same DiffServ value in both directions.
  • the transmission of the packets is therefore symmetrical and the quality of service perceived by the two equipments A and B is identical.
  • the embodiments described above use the DiffServ mechanism, the invention is not limited to this mechanism but can instead be applied to any protocol that makes it possible to define a priority or a quality of service indicator at a specific location. packet of data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

Procédé pour l'établissement d'un flux de paquets avec un autre équipement au travers d'un réseau de communication, comportant une étape de détermination d'une première valeur d'un indicateur de priorité en fonction du type du flux de données et une étape d'échange, avec cet autre équipement, de messages de signalisation pour permettre l'établissement du flux de données. La première valeur est insérée dans le premier de ces messages de signalisation. A réception d'un message de signalisation comportant une valeur reçue de cet indicateur de priorité, une valeur émise est déterminée à partir de cette valeur reçue, et insérée dans les paquets du flux de paquets.

Description

Établissement d'un flux de paquets possédant une qualité de service symétrique par négociation de l'indicateur de qualité
La présente invention est relotive gux résegux de communicotion multimédio. Ces résegux peuvent transmettre du trafic de différentes ngtures (voix, vidéo, données...) correspondont à des gpplicgtions voriées : téléphonie, vidéophonie, noviggtion sur internet, téléchargement de fichiers, discussion textuelle en temps-réel (« instant messaging » ou « chat »)... Ces trafic sont transmis classiquement sous la forme de flux de paquets, notamment de paquet IP (pour « Internet Protocol »). Un même message applicatif peut être transmis en plusieurs paquet IP et il doit être reconstruit à réception avant délivrance à l'application. Ces applications et ces types de trafic sont associés à des critères de qualité de service différents et, dans la mesure où la capacité de transmission des réseaux est limité, il apparaît un besoin de donner une priorité plus important à certains couples applications/trafic qu'à d'autre. Par exemple, dans le cas d'une communication voix, le retard prit par certains paquets peut engendrer une perte de qualité de la voix. Dans le pire cas, le message audio pourra être inaudible ou incompréhensible.
Dans le cas d'une navigation sur internet, un retard pris par certains paquets peut éventuellement engendrer la sensation d'un système plus lent, mais la plupart du temps l'effet est imperceptible.
Il apparaît donc naturel de donner une importance plus forte au trafic de voix en comparaison du trafic de données. I l existe des solutions techniques permettant une affectation de priorités aux différents flux de données transmis par un réseau. Une de ces solutions est le mécanisme DiffServ, tel que notamment défini dans le RFC 2474 de l'I ETF, « Définition of the Differentiated Services Field (DS Field) in the IPv A and IPv6 Headers ».
Le principe de ce mécanisme DiffServ est d'insérer dans les paquets d'un flux un champ, DS Field, dont la valeur détermine une classe de service (ou code-point). Les équipements de réseau (routeurs, passerelles...) situés sur le chemin du flux de paquets doivent lire le champ DS Field et traiter la retransmission des paquets en fonction de cette valeur, les paquets de classe de service la plus élevée étant les plus prioritaires.
De cette façon, les flux requérant une qualité de service élevée peuvent être privilégiés par le réseau de communication par rapport aux flux n'en exigeant pas.
Toutefois, aucun mécanisme ne vient préciser comment la classe de service doit être déterminée. Chaque équipement insérant une classe de service dans un flux de paquets détermine la valeur selon des mécanismes propres et en fonction des différents flux qu'il peut avoir à gérer. Ces mécanismes peuvent dépendre du fournisseur de l'équipement.
Dans le cadre d'une communication bidirectionnelle, il peut souvent en résulter que chacun des deux terminaux (ou les équipements d'accès associés) utilise des politiques différentes pour déterminer la classe de service. Du coup, les flux de chaque direction appartiennent à des classes de service différentes et, donc, le comportement du réseau de communication à leur égard est différent et engendrer des qualités de service perçues différentes pour les deux directions. Par exemple, dans le cas d'une communication voix bidirectionnelle, un flux équipement connecté à un réseau sensible à l'écho pourrait requérir une diminution du délai. Si cela n'est pas appliqué les utilisateurs pourraient souffrir de problèmes d'écho (le paramètre délai amplifie la perception d'écho).
Le but de l'invention est de palier ce problème en offrant un mécanisme garantissant la même qualité de service perçue pour l'ensemble des directions d'une session de communication.
Pour ce faire, l'invention a pour objet un équipement de réseau comportant des moyens pour établir un flux de paquets avec un autre équipement au travers d'un réseau de communication, des moyens pour déterminer une première valeur d'un indicateur de priorité en fonction du type de ce flux de données et des moyens pour échanger avec cet autre équipement des messages de signalisation pour permettre l'établissement du flux de données. L'équipement de l'invention dispose en outre de moyens pour insérer cette première valeur dans le premier des messages de signalisation et des moyens pour, à réception d'un message de signalisation (si , s2) comportant une valeur reçue de l'indicateur de priorité, déterminer une valeur émise à partir de la valeur reçue et insérer cette valeur émise dans les paquets du flux de paquets.
L'invention a également pour objet un procédé pour l'établissement d'un flux de paquets avec un autre équipement au travers d'un réseau de communication, comportant une étape de détermination d'une première valeur d'un indicateur de priorité en fonction du type du flux de données et une étape d'échange, avec cet autre équipement, de messages de signalisation pour permettre l'établissement du flux de données. La première valeur est insérée dans le premier de ces messages de signalisation. A réception d'un message de signalisation comportant une valeur reçue de cet indicateur de priorité, une valeur émise est déterminée à partir de cette valeur reçue, et insérée dans les paquets du flux de paquets.
Selon un mode de réalisation de l'invention, la valeur émise est la valeur maximale entre la valeur reçue et la valeur déterminée par l'équipement en fonction du type de flux de paquets.
L'indicateur de priorité peut être conforme au mécanisme DiffServ et l'équipement peut alors être adapté pour insérer la troisième valeur dans le champ « DS Field » du flux de paquets.
La valeur émise peut être insérée dans un attribut conforme au protocole SDP dans les messages de signalisation.
La valeur émise peut être insérée dans un champ « DS Field » des paquets du flux de paquets.
L'invention apparaîtra de façon plus claire dans la description qui va suivre en liaison avec la figure annexée. Cette figure schématise les messages échangés entre deux équipements reliés par un réseau de communication et mettant en oeuvre l'invention.
La mise en oeuvre d'une session sur un réseau de communication, notamment sur un réseau de données de type « internet », comporte d'une façon générale deux phases : une phase d'établissement, durant laquelle les parties à la session échangent des messages de signalisation, et une phase de communication proprement dite durant laquelle les parties échangent les données: voix, vidéos, texte...
Dans la mise en oeuvre représentée sur la figure 1 , deux équipements A et B sont connectés via un réseau de communication N. L'invention est toutefois tout à fait susceptible de s'appliquer avec d'avantage de parties, et donc au cas des « conférences » audios ou vidéos. Les deux équipements peuvent être des terminaux de communication : téléphones fixes ou mobiles, ordinateurs, assistants numériques personnels (ou PDA pour Personal Digital Assistants) etc.
II peut aussi s'agir d'équipements hébergés chez un fournisseur de service, tel des serveurs. Par exemple, la communication peut être une communication entre un serveur de contenu et un terminal de communication permettant à l'utilisateur de ce dernier d'accéder à des contenus audio, vidéo... Il peut également s'agir d'équipements virtuels.
Dans l'exemple de la figure 1 , on suppose que l'équipement A initie la création de la session de communication. Il adresse à l'équipement B un premier message de signalisation, SI . Ce message peut typiquement être un message d'invitation conforme au protocole SIP tel que défini dans le RFC 3261 de l'IETF, « Session Invitation Protocol ».
Ce message « Invite » peut être relayé par différents dispositifs, tels des « SIP Proxy », au sein du réseau de communication N. Ceux-ci ne sont pas représentés sur la figure 1 et ne seront pas plus décrits dans la mesure où ils n'influencent pas l'invention proprement dite.
L'équipement A possède des moyens pour déterminer une valeur d'un indicateur de priorité p en fonction du type du flux de données qui doit composer la session de communication. On appelle « type » ici la nature des données à transmettre : vidéo, audio, audio-vidéo, texte, texte en temps-réel de type « messaging » ou « chat », etc. Le type peut en outre être plus précis et il peut être possible de décliner un type gros-grain comme « vidéo » en plusieurs types.
Le fournisseur de l'équipement A paramètre généralement une table de correspondance entre ces types de flux de données et une valeur de l'indicateur de priorité. Cet indicateur de priorité est préférentiellement conforme au mécanisme DiffServ tel que spécifié par le RFC 2474, « Définition of the Differentiated Serviecs Field (DS Field) in the IPv4 and IPv6 Headers ». L'équipement A peut être prévu pour disposer directement d'une table de correspondance entre type de flux de données et « codepoint ».
Selon l'invention, l'équipement possède des moyens pour insérer cette valeur, vl , dans le premier message de signalisation S I , c'est-à-dire celui d'invitation. Cette valeur peut être insérée dans un attribut approprié du protocole SDP (Session Description Protocole) tel que défini par le RFC 4566 de l'I ETF.
Cet attribut peut être codé sur 8 bits. I l peut être par exemple nommé « Traffic-class ».
Selon la grammaire ABN F (Augmented Backus-Naur Form), cet attribut peut être de la forme:
Traffic-class = « a =traffic-class: » Traffic-class-value
Traffic-class-value = *DIGIT
La valeur qui peut être prise par cet attribut est un entier compris entre 0 et 255.
Dans l'exemple de la figure, on peut trouver un attribut SDP dans le message SI P « I nvite » SI de type: a =traffic-class:vl A la réception du message de signalisation S I , l'équipement B doit lire cette valeur reçue vl de l'indicateur de priorité p.
I l renvoie à l'équipement émetteur A un message de signalisation S2 qui, classiquement, est un message SI P « 200 Ok ». Il dispose également des moyens pour insérer dans ce message de signalisation S2 une valeur « émise » de l'indicateur de priorité p. Cette valeur émise est déterminée à partir de la valeur reçue vl . Selon un mode de réalisation de l'invention, cette valeur émise (v3) est égale à la valeur reçue.
Selon un autre mode de réalisation de l'invention, cette valeur émise est égale au maximum entre la valeur reçue vl et une valeur déterminée par en fonction du type de flux de données. En effet, tout comme l'équipement A, il possède des moyens pour déterminer une valeur v2 pour l'indicateur de priorité p associée au type de flux de données. Il peut déterminer le type de flux de données grâce à d'autres champs et attributs du message de signalisation SI . Notamment, l'attribut « m » de la description du média, SDP, peut être utilisé pour déterminer cette valeur v2.
La valeur insérée dans le message S2 est donc une valeur v3 = max(vl ,v2).
Et le message S2 comporte un attribut a=traffic-class:v3 A la réception de ce message S2, l'équipement A peut lire cet attribut et prendre connaissance de cette valeur v3.
Dans certaines situations, l'équipement A peut renvoyer un message de signalisation suivant S3. Il peut s'agir d'un message SIP « ACK ».
Il n'est pas nécessaire d'y insérer un indicateur de priorité puisqu'à ce moment-là les deux équipements se sont déjà. Toutefois, l'invention s'applique évidemment au cas où cet indicateur est inséré dans les éventuels autres messages de signalisation S3. Les équipements A et B possèdent en outre des moyens pour établir le flux F de paquets au travers du réseau de communication N, selon les modalités et paramètres négociés durant les messages de signalisation (CODEC etc.)
I ls peuvent insérer au sein de ces paquets la valeur de l'indicateur de priorité déterminée précédemment, c'est-à-dire cette valeur v3.
Comme évoqué précédemment, cette valeur peut être conforme aux spécifications de DiffServ. Elle peut notamment être codée sur 8 bits, avec un champ DSCP (Differeniiaied Services CodePoinf) de 6 bits, tels que spécifiés au paragraphe 3 du RFC 2474 de l'I ETF.
Ainsi, la valeur de l'indicateur de priorité peut être directement insérée dans le champ « DS Field » des paquets sortants. L'insertion dans le champ DS Field des paquets est effectuée de façon connue en soi. La façon dont est déterminée la valeur insérée est par contre novatrice : selon l'invention, un équipement conforme à l'invention doit donc choisir comme indicateur DiffServ à utiliser pour un flux de paquets la valeur reçue dans le dernier message de signalisation reçu concernant ce flux.
De cette façon, le flux de paquets possède la même valeur DiffServ dans les deux sens. La transmission des paquets est donc symétrique et la qualité de service perçue par les deux équipements A et B est identique. Bien que les modes de réalisations décrits ci-dessus utilisent le mécanisme DiffServ, l'invention n'est pas limité à ce mécanisme mais peut au contraire s'appliquer à tout protocole permettant de définir une priorité ou un indicateur de qualité de service à un paquet de données.

Claims

Revendications
1 ) Équipement de réseau (A, B) comportant des moyens pour établir un flux (F) de paquets avec un autre équipement au travers d'un réseau de communication (N), des moyens pour déterminer une première valeur (vl ) d'un indicateur de priorité (p) en fonction du type dudit flux de données et des moyens pour échanger avec ledit autre équipement des messages de signalisation (s i , s2, s3) pour permettre l'établissement dudit flux de données, disposant en outre des moyens pour insérer ladite première valeur dans le premier (s i ) desdits messages de signalisation et des moyens pour, à réception d'un message de signalisation (s i , s2) comportant une valeur reçue dudit indicateur de priorité, déterminer une valeur émise à partir de ladite valeur reçue et insérer ladite valeur émise dans les paquets dudit flux de paquets.
2) Equipement de réseau selon la revendication 1 , dans lequel ladite valeur émise est la valeur maximale entre ladite valeur reçue et la valeur déterminée par ledit équipement en fonction dudit type de flux de paquets.
3) Equipement de réseau selon l'une des revendications 1 ou 2 dans lequel ledit indicateur de priorité est conforme au mécanisme DiffServ, et adapté pour insérer ladite troisième valeur dans le champ « DS Field » dudit flux de paquets.
4) Equipement de réseau selon l'une des revendications précédentes, adapté pour insérer ladite valeur émise dans un attribut conforme au protocole SDP dans lesdits messages de signalisation. 5) Équipement de réseau selon l'une des revendications précédentes, adapté pour insérer ladite valeur émise dans un champ « DS Field » des paquets dudit flux de paquets. 6) Procédé pour l'établissement d'un flux (F) de paquets avec un autre équipement au travers d'un réseau de communication (N), comportant une étape de détermination d'une première valeur (vl ) d'un indicateur de priorité (p) en fonction du type dudit flux de données et une étape d'échange avec ledit autre équipement de messages de signalisation (si , s2, s3) pour permettre l'établissement dudit flux de données, dans lequel ladite première valeur est insérée dans le premier (si ) desdits messages de signalisation, et dans lequel, à réception d'un message de signalisation (si , s2) comportant une valeur reçue dudit indicateur de priorité, une valeur émise est déterminée à partir de ladite valeur reçue et insérée dans les paquets dudit flux de paquets.
7) Procédé selon la revendication précédente, dans lequel ladite valeur émise est la valeur maximale entre ladite valeur reçue et la valeur déterminée par ledit équipement en fonction dudit type de flux de paquets.
8) Procédé selon l'une des revendications 6 ou 7 dans lequel ledit indicateur de priorité est conforme au mécanisme DiffServ, et adapté pour insérer ladite troisième valeur dans le champ « DS Field » dudit flux de paquets.
9) Procédé selon l'une des revendications 5 à 8, dans lequel ladite valeur émise est insérée dans un attribut conforme au protocole SDP dans lesdits messages de signalisation. 10) Procédé selon l'une des revendications 5 à 9, dans lequel ladite valeur émise est insérée dans un champ « DS Field » des paquets dudit flux de paquets.
EP11743092.6A 2010-08-20 2011-07-05 Etablissement d'un flux de paquets possédant une qualité de service symétrique par négociation de l'indicateur de qualité Withdrawn EP2606623A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1056685A FR2964001B1 (fr) 2010-08-20 2010-08-20 Etablissement d'un flux de paquets possedant une qualite de service symetrique par negociation de l'indicateur de qualite
PCT/FR2011/051589 WO2012022867A1 (fr) 2010-08-20 2011-07-05 Etablissement d'un flux de paquets possédant une qualité de service symétrique par négociation de l'indicateur de qualité

Publications (1)

Publication Number Publication Date
EP2606623A1 true EP2606623A1 (fr) 2013-06-26

Family

ID=43736145

Family Applications (1)

Application Number Title Priority Date Filing Date
EP11743092.6A Withdrawn EP2606623A1 (fr) 2010-08-20 2011-07-05 Etablissement d'un flux de paquets possédant une qualité de service symétrique par négociation de l'indicateur de qualité

Country Status (7)

Country Link
US (1) US9306859B2 (fr)
EP (1) EP2606623A1 (fr)
JP (1) JP5941914B2 (fr)
KR (1) KR101502250B1 (fr)
CN (1) CN103069773A (fr)
FR (1) FR2964001B1 (fr)
WO (1) WO2012022867A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9591108B2 (en) * 2013-08-20 2017-03-07 Avaya Inc. Management of network impairment by communication endpoints
CN109005126B (zh) * 2017-06-06 2020-06-02 华为技术有限公司 数据流的处理方法、设备和计算机可读存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020165966A1 (en) * 2001-01-10 2002-11-07 Widegren Ina B. Method and apparatus for coordinating end-to-end quality of service requirements for media flows in a multimedia session
US7050396B1 (en) * 2000-11-30 2006-05-23 Cisco Technology, Inc. Method and apparatus for automatically establishing bi-directional differentiated services treatment of flows in a network

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6382142A (ja) * 1986-09-26 1988-04-12 Nec Corp 蓄積交換網における優先交換処理方式
JP2001308925A (ja) * 2000-02-14 2001-11-02 Fujitsu Ltd ネットワークシステムの優先制御方法
US7352770B1 (en) * 2000-08-04 2008-04-01 Intellon Corporation Media access control protocol with priority and contention-free intervals
US6980523B1 (en) * 2001-01-23 2005-12-27 Sprint Spectrum L.P. Method and system for facilitating end-to-end quality of service in a wireless packet data system
US7379461B2 (en) * 2004-04-26 2008-05-27 Alcatel Lucent System and method for indicating network quality of service capability as a presence attribute of an end-user
CN1882107B (zh) * 2005-06-17 2010-12-08 华为技术有限公司 一种在下一代网络中实现信令网关双归属的方法
CN100563202C (zh) * 2005-09-01 2009-11-25 华为技术有限公司 提供差分服务的方法
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
US7760643B2 (en) * 2007-04-09 2010-07-20 Telcordia Technologies, Inc. Automatic policy change management scheme for DiffServ-enabled MPLS networks

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7050396B1 (en) * 2000-11-30 2006-05-23 Cisco Technology, Inc. Method and apparatus for automatically establishing bi-directional differentiated services treatment of flows in a network
US20020165966A1 (en) * 2001-01-10 2002-11-07 Widegren Ina B. Method and apparatus for coordinating end-to-end quality of service requirements for media flows in a multimedia session

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2012022867A1 *

Also Published As

Publication number Publication date
FR2964001A1 (fr) 2012-02-24
WO2012022867A1 (fr) 2012-02-23
US9306859B2 (en) 2016-04-05
JP2013537766A (ja) 2013-10-03
US20130163423A1 (en) 2013-06-27
CN103069773A (zh) 2013-04-24
KR20130032400A (ko) 2013-04-01
JP5941914B2 (ja) 2016-06-29
KR101502250B1 (ko) 2015-04-02
FR2964001B1 (fr) 2013-02-08

Similar Documents

Publication Publication Date Title
TWI239172B (en) Method and system for group communications
JP2006525693A (ja) マルチメディア・ストリーミングにおけるクライアント速度機能のシグナリング方法
CA2442676C (fr) Procede de gestion de l'alternat pour une communication en mode semi-duplex a travers un reseau de transport a commutation de paquets
EP3053303B1 (fr) Procede d'abonnement a des flux en provenance de clients multicast
MX2007013843A (es) Senalizacion de parametros de calidad de servicio para sesion multimedia.
JP5746112B2 (ja) 最大パケットサイズ属性を規定する、回線交換マルチメディアサービスとパケット交換マルチメディアサービスとの間の効率的なインターワーキング
US9591108B2 (en) Management of network impairment by communication endpoints
EP2606623A1 (fr) Etablissement d'un flux de paquets possédant une qualité de service symétrique par négociation de l'indicateur de qualité
FR2931024A1 (fr) Conversion voix vers texte en temps reel pour services de telecommunication
Hannu Signaling compression (SigComp) requirements & assumptions
WO2019081836A1 (fr) Procédé et entité de gestion d'une session multimédia entre un terminal appelant et au moins un terminal appelé, terminal et programme d'ordinateur correspondants
EP1267531B1 (fr) Routeur de signalisation pour l'établissement de sessions multimédias multiparties
EP2681912B1 (fr) Codage de données sans perte pour communication bidirectionnelle dans une session collaborative d'échange de contenu multimédia
FR2907621A1 (fr) Enrichissement de la signalisation dans une session de communication de type "push to talk" par insertion d'une carte de visite
Mutanen A System for Real-time High-quality Audio Streaming
Hannu RFC3322: Signaling Compression (SigComp) Requirements & Assumptions
Singh et al. A study on methodology on VoIP-based communication investigation through network packet analysis
Fang RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)
Ilie Multimedia protocol decoding
FR2930699A1 (fr) Negociation optimisee de ressources de codage entre clients de communication
Verma et al. Voice over Internet Protocol
Fang RFC 6884: RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)
Lee et al. Abnormal traffic detection system of VoIP based on SIP
Osuagwu Improving multimedia transmission through enhanced multimedia devices
Khokhar Shashank Khanvilkar, Faisal Bashir, Dan Schonfeld, and

Legal Events

Date Code Title Description
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

17P Request for examination filed

Effective date: 20130320

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

111Z Information provided on other rights and legal means of execution

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

Effective date: 20130430

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ALCATEL LUCENT

D11X Information provided on other rights and legal means of execution (deleted)
17Q First examination report despatched

Effective date: 20180122

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

Owner name: ALCATEL LUCENT

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180802

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 29/06 20060101AFI20120306BHEP

Ipc: H04L 12/56 20181130ALI20120306BHEP

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 29/06 20060101AFI20120306BHEP

Ipc: H04L 12/56 20060101ALI20120306BHEP