FR 2909822 A1 20080613 FR 0610629 A 20061206 Procédé et système de contrôle de l'établissement de canaux de communication pour permettre une transmission d'informations multimédia DOMAINE TECHNIQUE DE L'INVENTION La présente invention concerne les télécommunications utilisant les protocoles de téléphonie sur IP (Internet Protocol) ou d'établissement de session multimédia, et plus particulièrement, dans le but de contrôler l'établissement de canaux de communication dans un réseau géré par un opérateur, un procédé et un système de gestion de sessions multimédia. io ARRIERE-PLAN TECHNOLOGIQUE DE L'INVENTION Un réseau de données bien connu est Internet. Dans un domaine IP (Internet Protocol), le réseau de données est ouvert, ce qui signifie que n'importe quels terminaux peuvent communiquer deux à deux, par exemple en utilisant un même protocole de signalisation. Des sessions de type 15 multimédia peuvent être ainsi créées via le réseau Internet entre deux terminaux de communication. La convergence entre les réseaux de voix et les réseaux de données est permise par utilisation de protocoles de signalisation adaptés. La technologie voix sur IP ou VoIP et plus généralement les 20 technologies permettant l'établissement de sessions multimédia utilisent le plus fréquemment le protocole SIP (Session Initiation protocol), qui est un standard ouvert interopérable. D'autres protocoles de signalisation, par exemple H323, MGCP (Media Gateway Control Protocol) et Megaco (ce dernier protocole ayant été choisi dans la norme UMTS par le 3GPP pour le 25 contrôle des passerelles Media Gateways) peuvent aussi être utilisés pour les sessions multimédia. Le protocole SIP est normalisé par l'IETF (Internet Engineering Task Force) et décrit en particulier par le RFC 3261. Le protocole SIP, comme les protocoles H323 et MGCP, a été conçu pour établir, modifier et terminer des 2909822 2 sessions multimédia. Il se charge de l'authentification et la localisation des multiples participants. Il se charge également de la négociation sur les types de média utilisables par les différents participants en encapsulant des messages SDP (Session Description Protocol). Le protocole SIP ne 5 transporte pas les données échangées durant la session comme la voix ou la vidéo. Ce protocole étant indépendant de la transmission des données, tout type de données et de protocoles peut être utilisé pour cet échange : c'est le protocole RTP (Real-time Transport Protocol) qui assure le plus souvent les sessions audio et vidéo. Un intérêt du protocole SIP est qu'il io n'est pas seulement destiné à la voix sur IP mais également à de nombreuses autres applications telles que la visiophonie, la messagerie instantanée, la réalité virtuelle ou même les jeux vidéo. Comme tout protocole de signalisation, SIP incorpore une phase de déclaration auprès du réseau de rattachement, puis des phases de 15 demande d'établissement de session multimédia, de négociation de caractéristiques du service demandé et enfin une phase de clôture de la session multimédia. Le protocole d'initiation de protocole SIP (Session Initiation Protocol) permet à partir de la version v2.0 des échanges d'informations entre les entités en communication avant ou pendant la 20 session multimédia. De manière connue en soi, ces échanges peuvent être réalisés au travers des méthodes suivantes : INFO: permet d'échanger de l'information n'affectant pas l'état de l'appel (décrit dans RFC 2976). Dans certains cas ce champ est utilisé pour transférer des tonalités DTMF. 25 NOTIFY : permet d'envoyer des notifications d'événement (RFC 3265). SUBSCRIBE : permet de s'abonner à une notification d'événements (décrit dans RFC 3265). UPDATE : est utilisée pour mettre à jour les paramètres 30 média (cf. RFC 3311) ; 2909822 3 - MESSAGE : cette méthode définie dans la RFC 3428 SIP extension for Instant Messaging permet d'échanger des messages instantanés entre deux terminaux. Dans un réseau de radiotéléphonie par exemple, l'utilisation de tels 5 protocoles (SIP / H323 / MGCP) pour des sessions multimédia peut permettre des échanges d'informations à travers des canaux de données parallèles aux canaux de voix. Mais l'inconvénient de ces méthodes d'échange d'information est qu'elles ne sont pas toujours supportées par les réseaux sous-jacents et/ou les terminaux simples. DESCRIPTION GENERALE DE L'INVENTION La présente invention a donc pour objet de supprimer un ou plusieurs des inconvénients de l'art antérieur en définissant un procédé permettant des nouvelles utilisations du protocole de signalisation en profitant au maximum des potentialités de l'infrastructure réseau supportant ce type de protocole. Un enseignement selon l'invention montre pour cela une manière d'utiliser les méthodes élémentaires, nécessaires à l'établissement d'une session multimédia, et une façon de les acheminer par l'ensemble des réseaux. Au travers d'un nouvel usage, en conformité avec les normes, ces méthodes simples sont par exemple capables de résoudre le problème de renégociation en temps réel de la qualité négociée pour la session multimédia déjà établie. A cet effet, l'invention concerne un procédé de contrôle de l'établissement de canaux d'échanges pour permettre une transmission d'informations multimédia entre au moins deux terminaux de communication connectés entre eux par un réseau de télécommunications, comprenant une étape d'établissement d'une communication entre un premier terminal de communication et un second terminal de communication par utilisation d'applications respectives gérant un protocole de signalisation déterminé permettant d'initier des sessions, le premier terminal effectuant une étape de 2909822 4 sélection d'au moins un canal d'échange de données entre les deux terminaux, caractérisé en ce que l'étape de sélection s'effectue à un niveau applicatif et l'étape d'établissement d'une communication comprend les étapes suivantes : 5 - une étape d'émission d'au moins une requête par le premier terminal, à destination du second terminal, en ouvrant une session selon le protocole de signalisation déterminé ; et une étape d'envoi par le second terminal d'une réponse représentative d'une indisponibilité pour clôturer la session selon le lo protocole de signalisation déterminé ; le procédé comprenant lors des étapes d'émission et d'envoi une étape de transmission d'informations additionnelles en sus dudit protocole de signalisation, par utilisation dudit canal d'échange de données sélectionné, ce canal d'échange de données étant accessible via un is champ purement descriptif/explicatif de caractéristiques d'une session, lesdites informations additionnelles correspondant à des informations applicatives non nécessaires à la gestion de sessions multimédia. L'invention permet ainsi de contrôler l'émergence de solutions à un niveau application permettant des usages innovants/inhabituels des 20 infrastructures (SIP ou IMS notamment) d'un opérateur de réseau. Le fonctionnement intrinsèque du protocole de signalisation (par exemple SIP) reste inchangé de façon à pouvoir bénéficier d'une infrastructure réseau élémentaire au niveau mondial. On comprend que le procédé peut permettre d'élargir avantageusement l'usage des méthodes du protocole de 25 signalisation afin par exemple d'échanger des informations de signalisation en rapport au service et/ou à sa qualité et à sa délivrance autrement que par le canal data alloué (RTP) entre les entités communicantes. L'échange par cette voie inédite (via des champs contextuels) d'informations applicatives permet d'assurer un service en temps réel. 30 Selon une autre particularité, le procédé comprend une étape d'identification par le premier terminal d'au moins un canal d'échange de 2909822 5 données susceptible d'être utilisé pour l'étape de transmission d'informations additionnelles, l'identification résultant d'une étape de recherche de canaux d'échanges, dans laquelle le premier terminal analyse au moins une réponse du second terminal à une requête dans laquelle un des champs purement 5 descriptifs a été renseigné avec des informations additionnelles en sus dudit protocole de signalisation. Selon une autre particularité, l'étape de recherche de canaux d'échanges comprend une étape d'envoi par le second terminal d'un ensemble de messages de réponse à des requêtes du premier terminal. io Selon une autre particularité, le canal d'échange de données sélectionné est utilisé pour diffuser de bout en bout des informations multimédia. Selon une autre particularité, l'étape de sélection comprend une sélection de plusieurs canaux d'échange de données pour utiliser plusieurs 15 méthodes de transmission d'informations additionnelles en parallèle. Selon une autre particularité, le procédé comprend une étape de négociation de moyens de communication en temps réel entre un client du premier terminal et un serveur au travers d'une infrastructure de communication ayant une capacité d'acheminer au travers d'informations et 20 de messages de signalisation de bout en bout des données applicatives. Selon une autre particularité, au moins un des champs suivants est utilisé pour l'étape de transmission d'informations additionnelles en sus du protocole SIP : -En-tête des paquets SIP où sont mentionnées des caractéristiques 25 de session ; - Descriptif du code de réponse ; - Call ID ; Branch ; - TAG. 2909822 6 Selon une autre particularité, au moins un champ associé à la méthode MESSAGE du protocole SIP est utilisé pour l'étape de transmission d'informations additionnelles en sus du protocole SIP. Selon une autre particularité, au moins un champ associé à 5 l'information SDP de charge utile de SIP est utilisé pour l'étape de transmission d'informations additionnelles en sus du protocole SIP, ce champ SDP dans la charge utile de SIP étant défini comme optionnel par le protocole SIP ou ayant une structure et une syntaxe qui ne sont pas fixées par le protocole SIP. ~o Selon une autre particularité, un champ Call_ID du protocole SIP est utilisé pour l'étape de transmission d'informations additionnelles en sus du protocole SIP. Selon une autre particularité, des conditions de consommation/usage du contenu multimédia transmis lors de ladite étape de transmission sont 15 modifiées par une application multimédia consommatrice du contenu multimédia sur la réception et la prise en compte des informations additionnelles véhiculées au travers du protocole SIP. Selon une autre particularité, des conditions de consommation/usage d'un flux de transmission établi entre les deux terminaux de communication 20 sont modifiées par des applications multimédia consommatrices et émettrices du contenu multimédia de chaque terminal sur l'émission, la réception et la prise en compte des informations additionnelles véhiculées au travers du protocole SIP. Cette prise en compte peut être planifiée suivant un protocole partagé 25 au préalable par les deux applications multimédia. Selon une autre particularité, le procédé comprend une étape d'évaluation d'une bande passante disponible pour au moins un des canaux d'échanges hors session identifiés. Selon une autre particularité, le procédé comprend une étape de 30 renégociation en temps réel de la délivrance d'un service multimédia quand les conditions d'usage sont modifiées au travers de l'émission d'information additionnelle via le réseau SIP sous-jacent, l'étape de renégociation 2909822 7 comprenant une détection par le second terminal de cette modification des conditions d'usage, en fonction - de l'évolution de l'environnement de réseaux de transport disponibles pour le second terminal (par exemple détection d'un 5 réseau Wifi ou de réseaux de connectivité local et/ou pervasif) ; des conditions de localisation géographique du second terminal (à base d'information de type géolocalisation GPS ou cellule de rattachement d'un réseau mobile ou réseau de rattachement (roaming/itinérance)) ; to - des conditions de fonctionnement du second terminal lui-même, par exemple suite à la modification de l'environnement radio, de l'énergie disponible (batterie), de la disponibilité des processeurs internes du second terminal (notamment lorsque ce dernier est un terminal mobile) en fonction du nombre de tâches en cours 15 d'exécution au sein dudit terminal ; - des conditions d'usage et de consommation du service, par exemple paiement par tranche de durée, selon l'horaire de connexion, paiement en fonction de la résolution affichée et du rendu des couleurs, service dégradé suivant la position 20 géographique, service nécessitant un chiffrement supplémentaire ou une authentification supplémentaire car le second terminal vient d'être localisé dans une zone non sûre. Selon une autre particularité, l'étape de renégociation est réalisée pour modifier les conditions de délivrance du service multimédia suite à une 25 action spécifique de l'utilisateur. Il est ainsi permis pour l'utilisateur de diminuer temporairement une consommation de bande passante, en iconifiant un flux streaming de TVNideo. Autrement dit, quand des conditions d'usage sont modifiées par exemple au niveau du second 2909822 8 terminal, l'étape de renégociation permet de modifier la taille d'une fenêtre vidéo visible à l'écran. Selon une autre particularité, le procédé comprend une étape de mémorisation dans une mémoire de chacun des deux terminaux d'une liste 5 des canaux d'échange identifiés et pouvant être utilisés hors session pour transmettre des informations multimédia. Selon une autre particularité, le protocole de signalisation est le protocole SIP et l'étape de transmission d'informations additionnelles en sus dudit protocole comprend : 10 - une étape d'écriture par le premier terminal d'une requête dans un format texte ; une étape d'encodage de la requête ; - une étape d'envoi d'un message INVITE en passant la requête encodée dans le champ Call-ID. 15 Selon une autre particularité, l'étape de transmission d'informations additionnelles en sus dudit protocole comprend en outre : une étape d'envoi d'un message de réponse contenant une indication d'indisponibilité temporaire et dans lequel une réponse à la requête est positionnée par le second terminal dans un champ 20 purement descriptif ou explicatif ; - une étape de confirmation de fermeture d'une session SIP, dans laquelle le premier terminal envoie au second terminal un message d'acquittement ACK avec le même champ Call-ID pour indiquer une bonne réception de la réponse (définitive) à la requête. 25 Selon une autre particularité, ledit champ purement descriptif ou explicatif est le champ Reason (servant habituellement pour le motif du refus ou de l'acceptation d'une requête). Un objectif supplémentaire est de proposer dans un terminal de communication en réseau une application permettant de nouvelles 2909822 9 utilisations du protocole de signalisation en profitant au maximum des potentialités de l'infrastructure réseau supportant ce type de protocole. A cet effet, l'invention concerne un programme d'un module de traitement directement chargeable dans la mémoire d'un terminal de 5 communication avec un réseau pour commander des étapes du procédé selon l'invention lorsque ledit programme est exécuté sur le terminal. L'invention, avec ses caractéristiques et avantages, ressortira plus clairement à la lecture de la description faite en référence aux dessins annexés donnés à titre d'exemples non limitatifs dans lesquels : io la figure 1 représente un logigramme des étapes du procédé dans un mode de réalisation de l'invention ; la figure 2 montre un exemple d'établissement d'échanges de signalisation propres à des applications des terminaux, sans interférence avec les réseaux SIP sous-jacents ; is - la figure 3 illustre un premier scénario d'appel qui peut être détecté par utilisation d'un indicateur d'un système selon l'invention ; - la figure 4 illustre un second scénario d'appel qui peut être détecté par utilisation d'un indicateur d'un système selon l'invention ; la figure 5 représente schématiquement un contexte IP Multimedia 20 Subsystem (IMS), dans lequel un réseau d'opérateur de radiotéléphonie est doté d'un système de surveillance et gestion des requêtes SIP selon un mode de réalisation de l'invention. DESCRIPTION DES MODES DE REALISATION PREFERES DE L'INVENTION 25 Le procédé selon l'invention vise à proposer des méthodes d'échange de signalisation à un niveau application en utilisant les spécificités du protocole SIP ou autre protocole de signalisation, mais sans jamais porter atteinte au fonctionnement intrinsèque du protocole de signalisation de façon à pouvoir bénéficier d'une infrastructure réseau au niveau mondial. Dans 30 l'exemple de la figure 2, des échanges de signalisation propres aux 20 2909822 10 applications utilisées doivent être établies entre les applications (Al, A2, A4) des terminaux (T1, T2, T4). Des informations de signalisation peuvent être échangées entre ces applications (Al, A2, A4) sans interférer avec les réseaux SIP sous-jacents. Le procédé prévoit d'identifier une pluralité de 5 possibilités d'échange d'information dans un scénario simple de communication et à titre d'exemple non limitatif : l'usage de INVITE, réponse et ACK et BYE. Une méthode INVITE indique que l'application (ou utilisateur) correspondant à l'adresse URL SIP spécifiée est invité à participer à une 10 session (le corps du message décrivant cette session, par exemple : média supporté par l'appelant) ; en cas de réponse favorable, l'invité doit spécifier les médias qu'il supporte. Il existe également la méthode RE-INVITE. Le format des messages SIP reste inchangé. On rappelle ici qu'un message SIP peut être à la fois une requête d'un client (terminal appelant) 15 vers un serveur (terminal appelé) ou bien une réponse d'un serveur vers un client. A titre d'exemple, une requête SIP d'un client vers un serveur peut se représenter comme suit : 25 Une requête SIP d'un serveur vers un client peut se représenter comme suit : En-tête général, ou de requête, ou d'entité Ligne de requête (Méthode, Requête URI, version SIP) CRLF (permet de spécifier la fin du champ d'en- têtes, et le début du corps de message) Corps du message 2909822 5 Dans le cas des requêtes, un corps (du message) est ajouté ou non selon la méthode utilisée. S'il s'agit par exemple d'une méthode INVITE, le corps du message de la requête INVITE contient des informations indiquant la progression de la requête. Dans le cas des réponses, le corps du io message est obligatoire. Ainsi, la réponse à une requête INVITE contient dans le corps du message une description de la session. L'abonné qui utilise via son terminal (Ti) une infrastructure SIP est normalement connecté à celle-ci. II a passé les phases d'authentification et s'est enregistré auprès de son serveur (3) proxy SIP. L'abonné voulant 15 établir un service utilisant les principes du procédé selon l'invention, va lancer une application (Al) appelée client de son terminal (Ti) qui va dans une première phase 'scanner' les potentialités de l'infrastructure SIP utilisée. Pour ce faire, le client embarqué de l'abonné va émettre un ensemble de requêtes vers le serveur (3) de délivrance du service ou un autre abonné 20 (terminal T2) si le service requis et de type poste à poste Peer to Peer (P2P). Le protocole SIP repose sur l'envoi de requêtes au format texte. Une requête utilise une méthode définie dans la RFC du protocole telle que INVITE, OPTIONS, ACK, BYE, REGISTER, CANCEL, ou MESSAGE (défini 25 dans l'extension de la RFC). Chaque requête contient des en-têtes (généralement une dizaine mais le nombre est extensible) et éventuellement un corps de message. L'annexe 1 fournit un exemple de requêtes SIP établissant un appel téléphonique. Le processus décrit dans l'annexe 1 se rapporte à la succession d'étapes illustrées à la figure 3. lI faut remarquer Ligne d'état (version SIP, code d'état, Reason phrases) En-tête général, ou de réponse, ou d'entité CRLF (permet de spécifier la fin du champ d'en-têtes, et le début du corps de message) Corps du message 2909822 12 que dans cet exemple, un appel est établi : il y a donc un effet sur le comportement de l'infrastructure SIP. Les champs Call-ID, branch et tag sont choisis par le terminal émetteur (Ti) et acheminés par l'infrastructure SIP jusqu'au terminal 5 destinataire (T2). Ces champs n'ont que très peu d'exigence de format et peuvent donc être facilement utilisés pour envoyer de l'information additionnelle du terminal émetteur (Ti) vers le terminal destinataire (T2). Dans un mode de réalisation de l'invention, il est prévu pour la mise en oeuvre du procédé des moyens d'utiliser cette facilité prévue par la norme. ~o Pour cela, le terminal (Ti) émetteur comprend un agent de traitement disposant de scripts qui permettent d'utiliser ces champs. On comprend également que le second terminal (T2) destinataire peut utiliser le champ contextuel du compte rendu pour émettre une information en sus du protocole vers le premier terminal (Ti). La réception du message 15 de statut avec le champ Cali _ID renseigné avec la valeur émise par le premier terminal (Ti), fournit un renseignement sur le fait que la donnée véhiculée dans le champ Call-ID a bien été prise en compte par le second terminal (T2). De façon parallèle, le premier terminal (Ti) peut renvoyer un acquittement ACK vers le second terminal (T2) pour lui signifier 20 au travers du TAG associé au champ from que sa réponse a bien été prise en compte. En référence à la figure 2, le réseau (N) SIP inclut un premier domaine (15) de protocole IP (Internet Protocol) permettant d'utiliser une topologie d'options de routage (traits en pointillés) et un deuxième domaine 25 correspondant à un réseau de radiotéléphonie (16). Un domaine de type RTC (Réseau Téléphonique Commuté) peut également faire partie du réseau (N) SIP. Dans un mode de réalisation préféré, le réseau (N) SIP illustré à la figure 2 utilise une architecture de service avec un sous-système IMS (IP 30 Multimédia Subsystem), qui permet de déployer une technologie voix sur IP. Bien que le réseau (N) SIP soit représenté comme incluant un réseau de radiotéléphonie (16) doté de stations et une partie avec connexion filaire, on 2909822 13 comprend que n'importe quelle connexion sans fil peut être utilisée dans le réseau (N), ce dernier pouvant même utiliser uniquement des connexions sans fil (radio, WiFi, Wimax, Bluetooth , etc.). Dans l'exemple de la figure 2, le domaine IP (15) dispose d'une 5 pluralité d'éléments de réseau, notamment une passerelle (2) média (media gateway), un serveur (3) proxy ainsi que des premier et second terminaux d'utilisateur (Ti, T2). Chaque terminal (Ti, T2) peut utiliser une portion de la topologie des options de routage lors de l'établissement d'une communication avec un terminal de radiocommunication (4), par exemple 10 cellulaire, connecté via le réseau de radiotéléphonie (16). Dans ce cas, le serveur (3) proxy et la passerelle (2) sont utilisées. Les premier et second terminaux peuvent aussi communiquer entre eux par utilisation du serveur (3) proxy SIP, sans utilisation de la passerelle (2) dans ce cas. En référence à la figure 1, le procédé prévoit d'utiliser un canal 15 d'échange de données, accessible via le protocole de signalisation, pour diffuser de bout en bout des informations autres que celles nécessaires à la gestion de sessions multimédia. Le procédé contrôle l'établissement de canaux d'échanges pour permettre la transmission d'informations multimédia entre des terminaux de communication (Ti, T2, 4) connectés entre eux par 20 le réseau (N) de télécommunications. En référence aux figures 1 et 2, une étape (51) d'établissement d'une communication entre un premier terminal de communication (Ti) et un second terminal de communication (T2) est réalisée par utilisation d'applications respectives (Al, A2) gérant le protocole de signalisation. Le 25 premier terminal (Ti) effectue une étape (500) de recherche de canaux d'échanges entre les deux terminaux (Ti, T2). Cette étape (500) de recherche de canaux d'échanges peut ainsi permettre de répertorier les possibilités d'échanger des informations applicatives, le canal d'échange pouvant être choisi lors d'une étape ultérieure (52) de sélection. Une étape 30 (50) d'identification par le premier terminal (Ti) d'au moins un canal d'échange peut être réalisée par le premier terminal (Ti), par exemple après 2909822 14 chaque réception d'un message de réponse à une des requêtes émises lors de l'étape (500) de recherche. Lors de la communication, le procédé peut comporter : - une étape (53) d'émission d'une ou plusieurs requêtes par le 5 premier terminal (Ti), à destination du second terminal (T2), en ouvrant une session selon le protocole de signalisation déterminé ; et une étape (54) d'envoi par le second terminal (T2) d'une réponse représentative d'une indisponibilité pour clôturer la session selon le 10 protocole de signalisation déterminé. Dans un mode de réalisation de l'invention, le procédé comprend une étape (55) de transmission d'informations multimédia par utilisation dudit canal d'échange sélectionné. On comprend que l'utilisation de ce canal d'échange ne correspond absolument pas à la voie utilisée lors d'une 15 session classique, dans lequel l'initiation du transfert d'une information multimédia est effectuée en utilisant le corps du message de la requête SIP. Avantageusement, l'étape (55) de transmission d'informations additionnelles via ce canal s'effectue lors desdites étapes (53, 54) d'émission et d'envoi, en sus dudit protocole de signalisation. 20 Cette étape (55) de transmission est réalisée par exemple après l'étape (52) de sélection du canal d'échange. Ces deux étapes (52, 55) sont par exemple chacune déclenchées à un niveau applicatif. L'étape (500) de recherche de canaux d'échanges peut comprendre une étape (510) d'envoi par le second terminal (T2) d'un ensemble de messages de réponse aux 25 requêtes du premier terminal (Ti). Ceci permet d'identifier et répertorier, au niveau de chacune des applications (Al, A2), les canaux parallèles disponibles. Plusieurs méthodes sous-jacentes au principe d'utilisation détournée de canaux de communication vont à présent être décrites. Bien que les 30 exemples décrits se focalisent sur le protocole SIP, il doit être compris que 2909822 15 cela peut être étendu à d'autres protocoles de signalisation (SIP, H323, MGCP, Megaco). Méthode des champs non définis : La technique proposée repose sur le fait d'échanger des données de 5 niveau applicatif au-dessus de la signalisation en utilisant astucieusement les facilités d'encodage proposées par le protocole SIP. On se focalise sur quatre méthodes utilisables simplement pour les échanges en les combinant plus ou moins : on peut généraliser tous les cas d'usage. Il doit être compris que le procédé de contrôle n'est pas restrictif de ces quatre méthodes to puisque la présente solution porte plus généralement sur le fait d'utiliser le transport de signalisation toujours présent, quelle que soit la consommation de flux de streaming en cours (cf. le descriptif des échanges entre Bob et Alice dans les annexes 1 et 2). Les quatre méthodes suivantes peuvent être citées : 15 En-têtes des paquets SIP (caractéristiques des sessions) ; Descriptif du code de réponse (req 200 OK) ; - Cali ID ( ); - TAG (ou BRANCH). Ainsi, une multitude d'en-têtes proposés dans un protocole (SIP ou 20 autre) et pouvant être inclus aux messages pour préciser un peu plus les caractéristiques de la session sont susceptibles de faire transiter de l'information dans la signalisation. De la même façon, une réponse à une requête dans un protocole donné, constituée d'un code et d'une description du code (par exemple pour SIP : 200 OK, 301 Moved Permanent/y, 404 Not 25Found...) permet de faire transiter de l'information dans la signalisation : réponse 200 Bonjour par exemple. 2909822 16 Méthode incluse au sein des méthodes MESSAGE L'application (Al) du terminal (Ti) construit une requête transportée dans la méthode MESSAGE du protocole SIP, dont le format est préalablement établi avec le serveur/destinataire auquel/avec lequel il 5 souhaite accéder/communiquer. L'agent embarqué teste alors s'il est possible de communiquer avec le serveur (3) des informations descriptives. Si le réseau (N) SIP achemine les méthodes MESSAGE, alors c'est le moyen le plus simple de transporter et d'établir une échange de données entres applications (Al, A2) entre deux utilisateurs (Bob et Alice). Le seul lo inconvénient des méthodes MESSAGE est la facturation possible de celle-ci, dans le cas où le réseau sous-jacent met en oeuvre des services de messagerie instantanée ; or dans notre problématique, la renégociation des conditions de qualité de la délivrance d'un contenu multimédia ne doit pas être facturable pour un acte de signalisation. 15 Dans un mode de réalisation de l'invention, le procédé de contrôle de l'établissement de canaux de communication permet d'échanger des informations de signalisation pour modifier en temps réel la nature des informations échangées, donc de la signalisation : il peut être dommageable de devoir utiliser un canal soumis à facturation pour établir et échanger de la 20 signalisation relative à un service en cours de délivrance. Méthode s'appuyant sur l'usage du payload (charge utile de SIP) SDP du protocole SIP Le protocole SDP (Session Description Protocol) est décrit dans le RFC 2327 [2.] et est utilisé pour décrire des sessions multicast dans les 25 annonces ou les invitations de sessions. Ces description ne figent pas forcément la structure et la syntaxe de tous les champs et en particulier des champs optionnels. Parmi ces champs facultatifs, certains ne sont pas syntaxiquement décrits et donc utilisables suivant le bon vouloir des services développés. Ce fait est astucieusement décrit dans l'annexe 4. A titre 2909822 17 d'exemple non limitatif, la charge utile de SIP ou payload SDP contenue dans les messages INVITE et certains 200 et ACK peut être utilisée pour transférer des données, même si aucune session n'est établie. Le champ s= de la payload SDP est par exemple un nom descriptif de la session et peut 5 être utilisé pour transmettre des données de façon parallèle. Application à la Méthode Cali ID dans le message INVITE L'absence de format sur ces champs permet à l'agent/le client (Al) de générer ses propres données et de leur adjoindre une donnée unique permettant la garantie de l'unicité du champ dans sa globalité. II est alors lo facile d'imaginer, au sein du champ CALL-ID, la mise en oeuvre d'une structure de type : Cet identifiant id-unique peut être composé d'une information d'identification de l'abonné ou agent et d'une variable de valeur unique 15 toto MSISDNesfr.fr-donnée unique(temps), comme par exemple : toto_03360313130202@sfr.fr-197.118.0.10_12h3047GMT Un exemple intéressant est le suivant : lors de la diffusion d'un contenu en streaming (préalablement établi), le client (A2) du terminal (T2) recevant le flux de streaming souhaite informer le serveur (3) ou l'émetteur 20 (Ti) de la nécessité de baisser temporairement la qualité du flux pour des raisons de disponibilité de l'unité de traitement CPU au niveau du client (A2). La requête : modification de la qualité vidéo à la valeur 7 pour 5 minutes peut être codée entre AA pour le champ descriptif de l'action et PP pour le champ descriptif des paramètres AAvideoAAPP7_5PP. 25 Pour transférer des informations vers le serveur (3) ou le client (A2) de l'abonné distant, on peut prévoir que le champ call ID va s'écrire toto_ 03360313130202@sfr.fr-197.118.0.10_12h3047GMT_AAvideoAAPP7_5PP. L'annexe 2 illustre alors le format de la requête émise par l'application (Al) 2909822 18 du premier terminal (Ti). Le correspondant peut alors renvoyer ses réponses ou paramètres au travers du champ Descriptif du code de réponse tout en recopiant le CALL-ID. Le message requete video 7 5 en traitement peut donc être reçu par le premier terminal (Ti). Cet exemple peut être 5 complexifié en y intégrant des notions de délais horaires ou programmation de délais en terme de trame RTP ou séquences d'images. Le protocole est réalisé sous la forme question / réponse ou commande / réponse. La structure suivante permet d'offrir à 10 n'importe quelle couche applicative un support (bearer) de transport. Il est ainsi très simple de reconstruire un module de transfert de fichier fonctionnant par un usage des canaux CALL-ID et descriptif du code de réponse au travers des messages INVITE. Il faut aussi remarquer que si le compte-rendu d'INVITE est négatif, aucune session ne sera établie ni 15 construite au niveau du serveur (3) SIP. Le module de transfert de fichier peut donc émettre un message d'INVITE avec au niveau du CALL-ID la requête suivante : , c'est-à-dire modifier la qualité vidéo en sélectionnant le niveau 7, pour une durée de 5 minutes. Un exemple de réponse du serveur est 20 illustré à la fin de l'annexe 2. Le serveur (3) peut aussi spontanément demander à un utilisateur d'activer des moyens de sécurité plus élevés si le client se retrouve dans un environnement peu sûr au moyen d'une requête INVITE dans le présent exemple. 25 On remarque que le champ FROM peut aussi être utilisé pour dialoguer directement avec un serveur de service, puisqu'il est disponible pour n'importe quelle valeur d'alias. Ce champ n'étant pas contraint dans son contenu, il peut être renseigné avec n'importe qu'elle structure convenu auparavant respectant les obligations de structure de la norme. Un autre 30 intérêt du champ FROM est que, de façon générale, le contenu de ce champ sera affiché à la réception par le terminal ; il est ainsi permis de construire des offres de services (avec interactivité) demandant des actions de 2909822 19 l'utilisateur au moment de la réception de la demande de traitement émise, que cette demande soit relative ou non à la renégociation de la qualité de service du contenu multimédia en cours de diffusion. En référence avec l'annexe 3, deux autres champs sont aussi 5 intéressants dans le cadre d'une utilisation parallèle de la signalisation SIP selon l'invention des champs du protocole de signalisation : warning champ et reason champ . La lecture du descriptif de la RFC permet de voir que ces champs sont de type texte et sont obligatoires lors des échecs ou des alertes, événement particulièrement recherché pour ne pas établir de to session d'échange de données entre les interlocuteurs RTP (Real Time Protocol). Un des moyens les plus astucieux est d'établir une convention de format au niveau applicatif pour l'ensemble des champs de la norme laissés libres pour fournir une explication textuelle (humainement lisible : "the reason 15 phrase should be human readable"). L'information est ainsi véhiculée de bout en bout par l'infrastructure SIP sans aucune modification au niveau des serveurs, gateway et proxy (2, 3) traversés. Cette information se retrouve dans les réponses SIP et les méthodes. Il faut aussi souligner qu'il peut être évité d'émettre des requêtes 20 aboutissant en échec pour ne pas déclencher l'établissement d'un canal data : un nouveau canal de données peut en effet être avantageusement établi et utilisé entre deux terminaux (Ti, T2) ou même plus de deux terminaux (Ti, T2, 4). La forme de réalisation de la figure 5 montre l'infrastructure de deux 25 opérateurs de radiotéléphonie différents avec une communication entre ces réseaux via des serveurs (31, 32) CSCF (Cali Session Control Function) dotés par exemple de base de données HSS (Home Subscriber Server) pour récupérer les données d'abonnés. Des passerelles (21, 21') et des commutateurs (22, 22') prévus dans chacun de ces réseaux de 30 radiotéléphonie (16, 16') permettent d'acheminer les messages jusqu'à des terminaux mobiles de radiocommunication (T1, T2). Un protocole GTP (GPRS Tunnel Protocol) permet de communiquer entre une passerelle (21, 2909822 20 21') de type GGSN (Gateway GPRS Support Node) à un commutateur (22, 22') de type SGSN (Serving GPRS Support Node). Un pare feu (FW) peut être placé à l'interface entre au moins un des réseaux (16) de radiotéléphonie et le domaine (15) de type Internet. s L'architecture IMS telle qu'illustrée à la figure 5 permet d'accéder à des services multimédia depuis des terminaux mobiles ou fixes, en utilisant le protocole SIP sur IP. Le sous-système IMS est organisé en trois couches, qui sont : - la couche de transport qui désigne le moyen d'accès à l'IMS : ~o GGSN pour les téléphones mobiles, DSLAM pour l'ADSL, etc. ; le contrôleur de session (Call/Session Control Function ou CSCF) ; cette couche comprend notamment les serveurs suivants : o le Proxy-CSCF qui joue le rôle de proxy SIP : tous les messages de signalisation passent par lui ; il établit un tunnel 15 IPSec entre le GGSN et lui ; o le Serving-CSCF qui permet d'administrer le domaine : il joue le rôle de Registrar SIP et permet d'établir une politique de signalisation ; il assure aussi les fonctions de routages (tous les messages passent aussi par lui) ; 20 o le Interrogating-CSCF est le point d'entrée d'un domaine : c'est par lui que passent les paquets SIP provenant d'un autre domaine ; son adresse est publiée dans le système DNS (Domain Name System) ; - les serveurs d'application qui exécutent les services. 25 La figure 3 permet de rappeler le déroulement conventionnel d'un scénario d'appel avec un protocole de signalisation. Les scénarios simples de communication utilisent des requêtes SIP telles que : INVITE, ACK, BYE. Un terminal client SIP (Ti) appelle un autre terminal (T2) en utilisant le 2909822 21 message INVITE. Le message envoyé contient des informations permettant d'établir les flux media vers le terminal client (Ti) appelant. L'exemple ci-après illustre un message d'invitation selon le protocole SIP : INVITE sip christian@domaine.fr SIP/2.0 5 Via: SIP/2.0/UDP {mon adresse privée : port };branch={branch} Max_forwards: 70 From: {"Christian"} ; To: {Paul} Call-ID: {2966324558-edc-6548-fg8g9} 10 CSeq: {1} INVITE Expires: 1800 Content-Length: {187} Un serveur SIP, par exemple le serveur (3) proxy du domaine domaine.fr , répond à une requête SIP au moyen d'une ou plusieurs 15 réponses. La majorité des réponses, dont les codes sont de la forme 2xx, 3xx, 4xx, 5xx, et 6xx sont des réponses finales et terminent la transaction courante. Les réponses de la forme 1xx sont des réponses provisoires. Un exemple de réponse est fourni ci-après : SIP/2.0 100 Trying 20 Via: SIP/2.0/UDP {mon adresse privée : port };branch={branch} From: {"Christian"} ; To: {Paul} Call-ID: {2966324558-edc-6548-fg8g9} CSeq: {1} INVITE 25 Dans l'exemple de la figure 3 : le code de réponse 100 signifie Trying en cours de traitement ; le code de réponse 180 signifie Ringing sonnerie en cours ; et 30 le code de réponse 200 signifie OK . 2909822 22 Pour comprendre la notion de transactions et de retransmission de messages, il faut ici rappeler qu'un dialogue SIP est identifié par la combinaison des champs From , To , Call-ID et du numéro de séquence Cseq . Lorsque le dialogue est établi, toutes les requêtes et les 5 réponses doivent inclure ces champs d'en-tête. Chaque transaction est identifiée par la valeur commune de l'en-tête Cseq (le nom de la méthode et le numéro de séquence doivent être identiques). Le système selon l'invention peut permettre d'analyser dans chaque transaction le type de requêtes émises avec les réponses associées et de comparer les io transactions entre elles. En référence à la figure 4, des requêtes génériques comme SUBSCRIBE et NOTIFY peuvent être aussi contrôlées et utilisées lors de l'étape (55) de transmission d'informations multimédia. Le fait d'utiliser les requêtes SUBSCRIBE et NOTIFY permet de diffuser de bout en bout des 1s informations autres que celles nécessaires à la gestion de sessions multimédia. Ces deux requêtes génériques peuvent être routées par les serveurs (3) proxy à l'aide des en-têtes From et To et sont acquittées par des réponses. La requête SUBSCRIBE est envoyée par le terminal client (Ti) qui souhaite recevoir certains événements vers un serveur (3) qui 20 génère les événements (par exemple : une demande d'informations de présence à une application de type liste d'amis buddy Iist ). La requête SUBSCRIBE contient dans l'en-tête Expires qui indique la durée de la souscription. La requête NOTIFY sert à envoyer des notifications d'événements. Ces requêtes SUBSCRIBE et NOTIFY peuvent créer un 25 dialogue SIP, elles n'ont pas besoin de requête INVITE et elles peuvent être envoyées de manière asynchrone à n'importe quel moment. Il est ainsi très simple de réaliser au-dessus d'une infrastructure SIP un système de communication sur la base question/réponse. Avec l'exemple du champ call-ID, si un premier terminal (Ti) veut par exemple émettre vers 30 un second terminal (T2) une requête élémentaire pour interroger une base de données, alors : 2909822 23 - le premier terminal (Ti) écrit sa requête élémentaire au format texte ; il encode ensuite sa requête en base-64 ; puis il envoie un message INVITE au second terminal (T2) en passant 5 la requête encodée dans le CALL-ID. Le second terminal (T2) répond avec le code 480 (temporarily unavailable) et positionne dans le champ reason-code la réponse de la requête à une base de données. Le premier terminal (T1) renvoie alors un acquittement ACK avec le même Call-ID pour confirmer la fermeture de la ~o session SIP et la bonne réception du résultat à la requête. L'infrastructure SIP va considérer que l'appel n'a jamais abouti et que la session est terminée, mais une requête aura été traitée au travers de l'infrastructure SIP. On comprend qu'il est aisé de complexifier le protocole pour embarquer au niveau des champs tels que CALL-ID une succession de 15 requêtes. L'homme de l'art appréciera qu'il suffit d'établir une convention pour identifier le premier paquet, identifier le paquet d'ordre N et le dernier paquet (voir SIP INVITE definition : RFC 2543 et RFC 3261). L'exemple de la figure 3 permet de montrer la relative simplicité du scénario de communication, par usage de INVITE / ACK et BYE. 20 Dans un mode de réalisation de l'invention, le procédé prévoit de scruter/scanner les canaux ouverts. La plupart des exemples précédemment cités utilisent simplement le champ Call-ID pour véhiculer les requêtes, et cela de façon bidirectionnelle grâce à la puissance du protocole SIP. Mais certaines infrastructures SIP n'acheminent pas l'information de Call-ID de 25 bout en bout, en particulier si un serveur (3) proxy SIP réécrit ces données. Cela est possible au niveau du protocole SIP puisque la seule contrainte est que l'information constituée de TO, FROM et CALL ID doit identifier une connexion peer to peer unique. L'usage du champ from comme activateur d'échange peut alors 30 être nécessaire. Dans le cas où les champs from se retrouveraient aussi 2909822 24 bridés par le serveur (3) proxy SIP du fait des limitations de ses capacités, des schémas s'appuyant sur l'usage du champ TO peuvent être envisagés. Dans le cadre de l'usage du champ FROM, la requête est encodée dans celui-ci et le schéma montré avec le call-ID reste identique (cf. annexes 5 1-2). Dans le cadre du champ TO, le terminal récepteur (T2) utilisé par Bob fait une requête vers le terminal (Ti) d'Alice mais en ciblant un alias (pseudo) spécifique d'Alice lui demandant de rappeler pour permettre de passer la requête. Alice rappelle donc et en retour le terminal (T2) de Bob transporte sa requête dans un des champs contextuels offerts : la réponse to reviendra au niveau de l'acquittement ACK ou si cette méthode n'est pas disponible dans le réseau il peut être convenu au niveau du rejet de la requête que, moyennant un identifiant de requête, bob rappelle Alice afin de lui transmettre son identifiant de requête et que celle-ci lui réponde au moment du rejet. 15 Plusieurs méthodes sont donc possible pour tirer astucieusement parti de la puissance du protocole SIP, mais il est nécessaire de convenir laquelle de ces méthodes on souhaite utiliser et en particulier de détecter laquelle peut être utilisée sur un réseau (N) SIP et cela de façon automatique. Le principe de fonctionnement du scan (scrutation) repose sur une utilisation 20 d'un ensemble de méthodes, de façon séquentielle, jusqu'à ce que l'on détecte une méthode opérationnelle sur cette infrastructure. Lors de la phase de découverte des canaux parallèles disponibles, l'agent/le client embarqué émet une requête INVITE vers le destinataire en renseignant les champs disponibles successivement et peut ainsi établir une 25 cartographie des moyens de communication parallèle disponible pour atteindre le correspondant. Par extension, l'agent peut établir une cartographie des moyens de communications parallèles disponibles pour atteindre N correspondants ou serveurs, par extension des notions de groupes de destinataires peuvent aussi être gérés toujours par rapport aux 30 moyens de communication parallèles cartographiés. La description des tests nécessaires à la découverte des moyens de communications parallèles peut être précodée séquentiellement. Une 2909822 25 grammaire peut décrire la liste des champs du protocole de signalisation que l'application (Al, A2) ou agent pourrait utiliser et évaluer. Une fois la cartographie réalisée, il est envisageable d'évaluer la bande passante disponible pour chacun des canaux parallèles par une succession de tests 5 récurrents de disponibilité des canaux parallèles cartographiés. Plusieurs options sont possibles, le client (Al, A2) se maintient à la première méthode opérationnelle. II teste toutes les méthodes connues et choisit celle de son choix sur des critères aléatoires, ordinaux, ou dépendant de la nature des informations qu'il souhaite échanger avec son interlocuteur. 10 Le client (Al, A2) utilise plusieurs méthodes en parallèle, si l'infrastructure SIP autorise plusieurs de ces méthodes et peut dédier/particulariser chaque méthode à des sous-types de services bien précis. Il est bien entendu que les clients (Al, A2) dans le cadre de service en peer to peer entre 2 ou N usagers, ou le serveur (3) et le client (Al, A2) 15 dans le premier cas ont convenu préalablement d'une convention protocolaire et de structure des informations qui sont échangés de façon à rester intelligibles. L'avantage résultant est d'utiliser l'infrastructure SIP de manière optimale pour établir un échange de données multimédia via RTP. On ne cesse pas d'utiliser l'infrastructure SIP et on parvient en outre à 20 modifier la nature ou la qualité ou même le service échangé via la liaison de donnée RTP déjà établie, sans chercher à rompre celle-ci pour en rétablir une autre. II est ainsi possible de forcer une réduction de qualité dans la délivrance du contenu si le client et le serveurs ou les clients des usagers en peer to peer détecte une altération de la bande passante disponible au 25 niveau de leur contrôle (monitoring) des transferts/échanges. Ce type de modification est aujourd'hui très difficile à mettre en oeuvre et nécessite la plupart du temps de rompre la session établie pour en reconstruire une autre. Afin de diminuer la consommation de bande passante, le terminal (T2) 30 récepteur peut par exemple iconifier, ou réduire la taille d'affichage de la vidéo en réduisant d'autant la bande passante nécessaire (donc réduction du flux streaming de TV/Video). Dans l'exemple de la figure 5, une fenêtre 2909822 26 réduite (I) est ainsi utilisée pour la visualisation du contenu multimédia (images/vidéo) reçu. Cette fenêtre (I) a un format bien inférieur à celui de l'écran (E) du terminal (T2) récepteur et le contenu peut être visualisé avec une moindre définition, ce qui permet d'économiser la bande passante. A 5 titre d'exemple, la consommation de bande passante peut être volontairement réduite pendant certaines phases de la diffusion d'une bande annonce, au moment du générique par exemple. Les conditions d'utilisation en réception du contenu multimédia peuvent être prises en compte pour ajuster automatiquement la consommation de bande passante. lo Un des avantages de l'invention est de permettre une maîtrise de nouveaux protocoles utilisés notamment dans la gestion des services multimédia tels que la visiophonie, la voix sur IP, échange de fichiers, la messagerie, etc. En particulier, le procédé selon l'invention peut permettre de contrôler l'usage des canaux parallèles dans les protocoles de voix sur IP 15 et de mettre en place des canaux de communication en temps réel offrant la possibilité aux usagers de modifier la qualité du service consommé, le niveau du service et le type du service par une la mise en place d'une signalisation souple, indépendante du support (bearer) d'accès. En outre, une couche applicative de service peut être avantageusement prévue pour 20 offrir aux applications des moyens de communications avec les centres serveurs indépendamment des politiques de filtrage et des capacités fonctionnelles des serveurs de signalisation sous-jacents. Le procédé selon l'invention est applicable à de nombreux services, comme par exemple les services de push de messagerie, les services 25 d'interactivité dans la consommation des nouveaux média (par exemple, la télévision interactive, ou les échanges de type Peer to Peer au sein des communautés), les services de négociation en temps réel de la qualité de service. Il doit être évident pour les personnes versées dans l'art que la 30 présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de 2909822 27 réalisation doivent être considérés à titre d'illustration, mais peuvent être modifiés dans le domaine défini par la portée des revendications jointes et l'invention ne doit pas être limitée aux détails donnés ci-dessus. 2909822 28 ANNEXE1 INVITE sip:bob@fr.sfr. com SIP/2.0 Via: SIP/2.0/UDP 197.118.0.10:5060;branch=z9hG4bK894348304 From: ;tag=EX4EvRd7LY 5 To: CSeq: 1 INVITE Call-ID: uutng5001 gwJiG@ 1 97.118.0.10 Max-Forwards: 70 user-agent: X-lite io Content-Type: application/sdp Content-Length: 370 SIP/2.0 180 Ringing From: ;tag=EX4EvRd7LY 15 To: CSeq: 1 INVITE Call-ID: uutng5001 gwJiG@ 1 97.118.0.10 Max-Forwards: 70 user-agent: X-lite 20 Content-Type: application/sdp Content-Length: 370 SIP/2.0 200 0K From: ;tag=EX4EvRd7LY 25 To: CSeq: 1 INVITE Call-ID: uutng5001gwJiG@197.118.0.10 Max-Forwards: 70 user-agent: X-lite 30 Content-Type: application/sdp Content-Length: 370 ACK sip:bob@fr.sfr.com SIP/2.0 Via: SIP/2.0/UDP 197.118.0.10:5060;branch=z9hG4bK894348304 35 From: ;tag=EX4EvRd7LY To: ;tag=XFXF445Rd7 CSeq: 1 INVITE Call-ID: uutng5001 gwJiG@197.118.0.10 Max-Forwards: 70 40 user-agent: X-lite Content-Type: application/sdp Content-Length: 370 2909822 29 ANNEXE 2 Pour transférer des informations vers le serveur ou l'agent de l'abonné distant Le call ID : 5 toto_03360313130202@sfr.fr- 197.118.0.10 12h3047GMT AAvideoAAPP7 5PP INVITE sip:bob@fr.sfr.com SIP/2.0 Via: SIP/2.0/UDP 197.118.0.10:5060;branch=z9hG4bK894348304 From: ;tag=EX4EvRd7LY lo To: CSeq: 1 INVITE Call-ID: toto_ 03360313130202@sfr.fr- 197.118.0.10 12h3047GMT AAvideoAAPP7 5PP Max-Forwards: 70 15 user-agent: X-lite Content-Type: application/sdp Content-Length: 370 20 Pour renvoyer des réponses ou paramètres au travers du champ Descriptif du code de réponse, tout en recopiant le CALL-ID SIP/2.0 180 requete video 7 5 en traitement From: ;tag=EX4EvRd7LY 25 To: CSeq: 1 INVITE Call-ID: toto_ 03360313130202@sfr.fr- 197.118.0.10 12h3047GMT AAvideoAAPP7 5PP Max-Forwards: 70 30 user-agent: X-lite Content-Type: application/sdp Content-Length: 370 Réponse du serveur CALL ID : 400 KO SIP/2.0 400 requete video 7 5 prise en compte From: ;tag=EX4EvRd7LY 40 To: CSeq: 1 INVITE Call-ID: toto 03360313130202@sfr.fr- 197.118.0.10 12h3047GMT AAvideoAAPP7 5PP Max-Forwards: 70 2909822 30 user-agent: X-lite Content-Type: application/sdp Content-Length: 370 ANNEXE 3 Etablissement d'un nouveau canal de données (cf. champs de la norme laissés libres) Waning method ~o Warning: 307 isi.edu "Session parameter 'foo' not understood" Warning: 301 isi.edu "Incompatible network address type 'E.164" Reason method The Reason header field MAY appear in any request within a dialog, in 15 any CANCEL request and in any response whose status code explicitly allows the presence of this header field. The syntax of the header field follows the standard SIP parameter syntax. Reason = "Reason" HCOLON reason-value `(COMMA reason-value) 20 reason-value = protocol *(SEMI reason-params) protocol = "SIP" / "Q.850" / token reason-params = protocol-cause / reason-text / reason-extension protocol-cause = cause EQUAL cause 25 cause = 1*DIGIT reason-text = "text" EQUAL quoted-string reason-extension = generic-param Reason: SIP ;cause=580 ;text="Precondition Failure" 5 2909822 31 ANNEXE 4 Description d'une session avec SDP 5 v= (protocol version) o= (owner/creator and session identifier) username session id version network type address type address s= (session name) i=* (session information) 10 u=* (URI of description : link to more information) e=* (email address of the person responsible of the session -> e=mjh@isi.edu (Mark Handley) or e=Mark Handley mjh@isi.edu) p=* (phone number-> p=+44-171-380-7777 orp=+1 617 253 6011) c=* (connection information - not required if included in ail media) c=network 15 type address type connection address/TTL b=* (bandwidth information) b=modifier:bandwidth-value One or more time descriptions (voir plus bas) z=* (time zone adjustments) z=adjustment time offset adjustment time offset eg z=2882844526 -1h 2898848070 0 20 k=* (encryption key) k=method[:encryption key] a=* (zero or more session attribute fines) a=attribute[:valueJ Zero or more media descriptions (voir plus bas) Time description 25 t= (time the session is active) t=start time stop time valeurs données selon le format du protocole NTP r=* (zero or more repeat times) r-repeat interval active duration list of offsets from start-time Media description 30 m= (media name and transport address) m=media port[/number of ports] transport fmt list (les ports sont succesifs) i=* (media title) c=* (connection information - optional if included at session-level) b=* (bandwidth information) 35 k=* (encryption key) Les attributs notés en italique sont facultatifs. Les informations décrites par SDP seront différentes selon le type de trame SAP (service advertising protocol). Parmi ces champs facultatifs, certains ne sont pas syntaxiquement décrits et donc utilisables suivant le bon vouloir des services développés. REVENDICATIONS 1. Procédé de contrôle de l'établissement de canaux d'échanges pour permettre une transmission d'informations multimédia entre au moins deux terminaux de communication (Ti, T2, 4) connectés entre eux par un réseau (N) de télécommunications, comprenant une étape (51) d'établissement d'une communication entre un premier terminal de communication (T1) et un second terminal de communication (T2) par utilisation d'applications respectives gérant un protocole de signalisation déterminé permettant d'initier des sessions, le premier terminal (Ti) effectuant une étape (52) de lo sélection d'au moins un canal d'échange de données entre les deux terminaux (Ti, T2), caractérisé en ce que l'étape (52) de sélection s'effectue à un niveau applicatif et l'étape (51) d'établissement d'une communication comprend les étapes suivantes : - une étape (53) d'émission d'au moins une requête par le premier 15 terminal (Ti), à destination du second terminal (T2), en ouvrant une session selon le protocole de signalisation déterminé ; et - une étape (54) d'envoi par le second terminal (T2) d'une réponse représentative d'une indisponibilité pour clôturer la session selon le protocole de signalisation déterminé ; 20 le procédé comprenant lors des étapes (53, 54) d'émission et d'envoi une étape (55) de transmission d'informations additionnelles en sus dudit protocole de signalisation, par utilisation dudit canal d'échange de données sélectionné, ce canal d'échange de données étant accessible via un champ purement descriptif/explicatif de caractéristiques d'une session, lesdites 25 informations additionnelles correspondant à des informations applicatives non nécessaires à la gestion de sessions multimédia. 2. Procédé selon la revendication 1, comprenant une étape (50) d'identification par le premier terminal (Ti) d'au moins un canal d'échange de données susceptible d'être utilisé pour l'étape (55) de transmission 2909822 33 d'informations additionnelles, l'identification résultant d'une étape (500) de recherche de canaux d'échanges, dans laquelle le premier terminal (Ti) analyse au moins une réponse du second terminal (T2) à une requête dans laquelle un des champs purement descriptifs a été renseigné avec des 5 informations additionnelles en sus dudit protocole de signalisation. 3. Procédé selon la revendication 2, dans lequel l'étape (500) de recherche de canaux d'échanges comprend une étape (510) d'envoi par le second terminal (T2) d'un ensemble de messages de réponse à des requêtes du premier terminal (Ti). l0 4. Procédé selon une des revendications 1 à 3, dans lequel le canal d'échange de données sélectionné est utilisé pour diffuser de bout en bout des informations multimédia. 5. Procédé selon une des revendications 1 à 4, dans lequel l'étape (52) de sélection comprend une sélection de plusieurs canaux d'échange de 15 données pour utiliser plusieurs méthodes de transmission d'informations additionnelles en parallèle. 6. Procédé selon une des revendications 1 à 5, comprenant une étape de négociation de moyens de communication en temps réel entre un client (Al) du premier terminal (Ti) et un serveur (3) au travers d'une 20 infrastructure de communication ayant une capacité d'acheminer au travers d'informations et de messages de signalisation de bout en bout des données applicatives. 7. Procédé selon une des revendications 1 à 6, dans lequel au moins un des champs suivants est utilisé pour l'étape (55) de transmission 25 d'informations additionnelles en sus du protocole SIP : En-tête des paquets SIP où sont mentionnées des caractéristiques de session ; Descriptif du code de réponse ; Call ID ; 2909822 Branch ; TAG. 8. Procédé selon une des revendications 1 à 7, dans lequel au moins un champ associé à la méthode MESSAGE du protocole SIP est utilisé pour 5 l'étape (55) de transmission d'informations additionnelles en sus du protocole SIP. 9. Procédé selon une des revendications 1 à 8, dans lequel au moins un champ associé à l'information SDP de charge utile de SIP est utilisé pour l'étape (55) de transmission d'informations additionnelles en sus du Io protocole SIP, ce champ SDP dans la charge utile de SIP étant défini comme optionnel par le protocole SIP ou ayant une structure et une syntaxe qui ne sont pas fixées par le protocole SIP. 10. Procédé selon une des revendications 1 à 9, dans lequel un champ Call_ID du protocole SIP est utilisé pour l'étape (55) de transmission 15 d'informations additionnelles en sus du protocole SIP. 11. Procédé selon une des revendications 1 à 10, dans lequel des conditions de consommation/usage du contenu multimédia transmis lors de ladite étape (55) de transmission sont modifiées par une application multimédia consommatrice du contenu multimédia sur la réception et la prise 20 en compte des informations additionnelles véhiculées au travers du protocole SIP. 12. Procédé selon une des revendications 1 à 11, dans lequel lesdites conditions de consommation/usage du contenu multimédia transmis lors de ladite étape (55) de transmission sont modifiées selon l'évolution de 25 l'environnement de réseaux de transport disponibles pour le second terminal (T2). 13. Procédé selon une des revendications 1 à 12, dans lequel lesdites conditions de consommation/usage du contenu multimédia transmis lors de 34 2909822 35 ladite étape (55) de transmission sont modifiées selon l'évolution des conditions de localisation géographique du second terminal (T2). 14. Procédé selon une des revendications 1 à 13, dans lequel lesdites conditions de consommation/usage du contenu multimédia transmis lors de 5 ladite étape (55) de transmission sont modifiées selon l'évolution des conditions de fonctionnement intrinsèque du second terminal (T2). 15. Procédé selon une des revendications 1 à 14, dans lequel lesdites conditions de consommation/usage du contenu multimédia transmis lors de ladite étape (55) de transmission sont modifiées selon l'évolution des conditions de délivrance d'un service reçu par le second terminal (T2). 16. Procédé selon une des revendications 1 à 15, dans lequel des conditions de consommation/usage d'un flux de transmission établi entre les deux terminaux de communication (1, 2) sont modifiées par des applications multimédia consommatrices et émettrices du contenu multimédia de chaque terminal sur l'émission, la réception et la prise en compte des informations additionnelles véhiculées au travers du protocole SIP. 17.Procédé selon une des revendications 1 à 16, comprenant une étape d'évaluation d'une bande passante disponible pour au moins un des canaux d'échanges hors session identifiés. 18. Procédé selon une des revendications 1 à 17, comprenant une étape de renégociation en temps réel d'un service quand des conditions d'usage sont modifiées au niveau du second terminal (T2), l'étape de renégociation étant réalisée pour diminuer une consommation de bande passante, en modifiant la taille d'une fenêtre vidéo visible à l'écran. 19. Procédé selon une des revendications 1 à 18, comprenant une étape de mémorisation dans une mémoire de chacun des deux terminaux (Ti, T2) d'une liste des canaux d'échange identifiés et pouvant être utilisés hors session pour transmettre des informations multimédia. 2909822 36 20. Procédé selon une des revendications 1 à 19, dans lequel le protocole de signalisation est le protocole SIP et l'étape (55) de transmission d'informations additionnelles en sus dudit protocole comprend : une étape d'écriture par le premier terminal (Ti) d'une requête 5 dans un format texte ; une étape d'encodage de la requête ; - une étape d'envoi d'un message INVITE en passant la requête encodée dans le champ Call-ID. 21. Procédé selon la revendication 20, dans lequel l'étape (55) de 10 transmission d'informations additionnelles en sus dudit protocole comprend en outre : - une étape d'envoi d'un message de réponse contenant une indication d'indisponibilité temporaire et dans lequel une réponse à la requête est positionnée par le second terminal (T2) dans un 15 champ purement descriptif ou explicatif ; - une étape de confirmation de fermeture d'une session SIP, dans laquelle le premier terminal (Ti) envoie au second terminal (T2) un message d'acquittement ACK avec le même champ Call-ID pour indiquer une bonne réception de la réponse à la requête. 20 22. Procédé selon la revendication 21, dans lequel ledit champ purement descriptif ou explicatif est le champ Reason . 23. Programme d'un module de traitement directement chargeable dans la mémoire d'un terminal (Ti, T2, 4) de communication avec un réseau (N) pour commander les étapes de la revendication 1, 2, 3, 4 ou 5 lorsque 25 ledit programme est exécuté sur le terminal (Ti, T2, 4).