Scénario
Signalisation pour la QoS de bout en bout dans les réseaux NGN

La figure 4 montre un exemple d'utilisateur mobile voulant voir une vidéo d'un serveur qui se trouve dans le réseau cœur de son fournisseur de service. Le fournisseur du service utilise les preconditions pour ce type de service afin d'éviter une défaillance et vérifier que tant l'utilisateur que le serveur ont les conditions nécessaires pour ce service. Et il va donner aux deux parties l'information de la composition du flux avant qu'ils décident de l'accepter.

La figure montre l'établissement de l'appel avec les preconditions. Le contrôleur du fournisseur enverra au début de la signalisation un INVITE (1) avec une description en SDP du média, ainsi la session sera établie plus tard avec un UPDATE et le téléphone ne sonnera que lorsque les ressources ont été réservées. Le contrôleur génère un 100 Trying (2) comme réponse sans aucune description pour ne pas alerter l'utilisateur. Comme le serveur d'applications veut utiliser les preconditions et il génère une offre 183 Session Progress (3) qui a les attributs SDP nécessaires pour les conditions. Le contrôleur du fournisseur envoie cette offre à l'utilisateur avec un UPDATE parce que l'appel n'a pas encore été accepté. En même temps, le contrôleur demande les ressources (4) avec le protocole DIAMETER pour vérifier l'autorisation et les règles d'admission (policies) de l'utilisateur. L'utilisateur génère une réponse 200 OK à l'UPDATE. Ensuite le contrôleur passe cette réponse sur un PRACK (5) comme une réponse provisoire. Le Serveur envoie un 200 OK (6) pour acquitter le PRACK. Maintenant les deux côtés font la réservation de ressources (7). Le protocole COPS est utilisé pour réserver la bande passante nécessaire pour la vidéo.

L'utilisateur le fait le premier et envoie une mise à jour de la description de sa session avec un UPDATE (8). Le serveur répond avec un 200 OK (9). Le serveur aussi envoie une mise à jour, après...