Aller au contenu principal

3. Fonctionnement du protocole (Protocol Operation)

Cette section décrit les détails opérationnels du protocole PPTP, y compris les états de connexion de contrôle, les états d'appel et les flux de traitement pour divers scénarios opérationnels.

3.1. États de connexion de contrôle (Control Connection States)​

La connexion de contrôle est une connexion TCP établie entre le PAC et le PNS pour échanger des messages de contrôle PPTP. L'établissement de la connexion de contrôle peut être initié par le PAC ou le PNS.

Transitions d'état de base​

La connexion de contrôle passe par les états de base suivants :

  1. Idle (Inactif) - Aucune connexion de contrôle n'existe
  2. Wait-Connect (Attente de connexion) - Demande de connexion envoyée, en attente de réponse
  3. Established (Établi) - Connexion de contrôle établie avec succès
  4. Wait-Disconnect (Attente de déconnexion) - Demande de déconnexion envoyée, en attente de confirmation

3.1.1. Initiateur de connexion de contrôle (Control Connection Originator)​

L'initiateur de la connexion de contrôle (PAC ou PNS) effectue les opérations suivantes :

État : Idle (Inactif)

  • Action : Établir une connexion TCP vers le pair
  • Envoyer : Start-Control-Connection-Request
  • Transition vers : État Wait-Reply

État : Wait-Reply (Attente de réponse)

  • Recevoir : Start-Control-Connection-Reply (Result = succès)
    • Transition vers : État Established
  • Recevoir : Start-Control-Connection-Reply (Result = erreur)
    • Fermer la connexion TCP
    • Transition vers : État Idle
  • Timeout :
    • Fermer la connexion TCP
    • Transition vers : État Idle

État : Established (Établi)

  • Peut envoyer et recevoir : tous les messages de contrôle PPTP
  • Envoyer : Echo-Request (maintien en vie périodique)
  • Recevoir : Echo-Reply (réponse au maintien en vie)
  • Envoyer : Stop-Control-Connection-Request (fermeture active)
    • Transition vers : État Wait-Stop-Reply

État : Wait-Stop-Reply (Attente de réponse d'arrêt)

  • Recevoir : Stop-Control-Connection-Reply
    • Fermer la connexion TCP
    • Transition vers : État Idle
  • Timeout :
    • Fermer la connexion TCP
    • Transition vers : État Idle

3.1.2. Récepteur de connexion de contrôle (Control Connection Receiver)​

Le récepteur de la connexion de contrôle (PAC ou PNS) effectue les opérations suivantes :

État : Idle (Inactif)

  • Écouter : Port TCP 1723
  • Recevoir : Demande de connexion TCP
    • Accepter la connexion TCP
    • Transition vers : État Wait-Request

État : Wait-Request (Attente de demande)

  • Recevoir : Start-Control-Connection-Request
    • Valider : Version du protocole, paramètres
    • Si accepté :
      • Envoyer : Start-Control-Connection-Reply (Result = succès)
      • Transition vers : État Established
    • Si rejeté :
      • Envoyer : Start-Control-Connection-Reply (Result = erreur)
      • Fermer la connexion TCP
      • Transition vers : État Idle

État : Established (Établi)

  • Peut envoyer et recevoir : tous les messages de contrôle PPTP
  • Recevoir : Echo-Request
    • Envoyer : Echo-Reply
  • Recevoir : Stop-Control-Connection-Request
    • Envoyer : Stop-Control-Connection-Reply
    • Fermer la connexion TCP
    • Transition vers : État Idle

3.1.3. Collision de demande d'initiation Start Control Connection (Initiation Request Collision)​

Lorsque le PAC et le PNS tentent simultanément d'établir une connexion de contrôle, une collision peut se produire. La gestion est la suivante :

  1. Détection de collision : Quand une partie reçoit un Start-Control-Connection-Request en état Wait-Reply
  2. Résolution de collision :
    • Comparer les adresses IP (valeur numérique)
    • Partie avec l'adresse IP inférieure : fermer sa connexion initiée, accepter celle du pair
    • Partie avec l'adresse IP supérieure : continuer sa connexion initiée, rejeter celle du pair
  3. Résultat final : Une seule connexion de contrôle est établie

3.1.4. Maintien en vie et temporisateurs (Keep Alives and Timers)​

Pour maintenir l'état actif de la connexion de contrôle, les mécanismes suivants sont implémentés :

Mécanisme Echo-Request/Reply

  • Fréquence d'envoi : Recommandé d'envoyer un Echo-Request toutes les 60 secondes
  • Gestion du timeout : Si aucun Echo-Reply n'est reçu dans les 60 secondes, la connexion est considérée comme défaillante
  • Stratégie de réessai : Peut réessayer jusqu'à 3 fois, avec un intervalle de 60 secondes entre chaque essai
  • Échec de connexion : Après plusieurs timeouts consécutifs, fermer la connexion de contrôle

Maintien en vie TCP

  • Le mécanisme de maintien en vie de la couche TCP peut être utilisé en complément
  • Le mécanisme Echo de la couche PPTP est requis (MUST)

Paramètres de temporisation

  • Timeout d'établissement de connexion de contrôle : 60 secondes
  • Intervalle de maintien en vie : 60 secondes
  • Timeout d'Echo-Reply : 60 secondes
  • Timeout de fermeture de connexion de contrôle : 60 secondes

Ces valeurs de temporisation sont des recommandations. Les implémentations peuvent les ajuster selon les besoins, mais doivent s'assurer que :

  • L'intervalle de maintien en vie est suffisamment court pour détecter rapidement les échecs de connexion
  • Les valeurs de timeout sont suffisamment longues pour éviter les faux positifs dus à la latence réseau

3.2. États d'appel (Call States)​

3.2.1. Considérations de temporisation (Timing Considerations)​

En raison de la nature temps réel de la signalisation téléphonique, le PNS et le PAC doivent tous deux être implémentés avec des architectures multi-thread de sorte que les messages relatifs à plusieurs appels ne soient pas sérialisés et bloqués. Le délai de transit entre le PAC et le PNS ne doit pas dépasser 1 seconde (SHOULD NOT). Les diagrammes d'état d'appel et de connexion ne spécifient pas explicitement les exceptions causées par les temporisateurs. L'hypothèse implicite est que puisque la connexion de contrôle basée sur TCP est vérifiée avec des messages de maintien en vie, il y a moins besoin de maintenir des temporisateurs stricts pour les messages de contrôle d'appel.

L'établissement d'appels sortants internationaux, y compris les séquences d'entraînement et de négociation de modem, peut prendre plus d'1 minute, donc l'utilisation de temporisateurs courts est déconseillée.

Si une transition d'état ne se produit pas dans 1 minute (sauf pour les connexions en état inactif ou établi), l'intégrité du traitement du protocole entre les pairs est suspecte et l'ENSEMBLE DE LA CONNEXION DE CONTRÔLE (ENTIRE CONTROL CONNECTION) doit être fermée et redémarrée. Tous les ID d'appel sont logiquement libérés chaque fois qu'une connexion de contrôle est démarrée. Cela aide également à empêcher que les appels payants soient "perdus" et jamais effacés.

3.2.2. Valeurs d'ID d'appel (Call ID Values)​

Chaque pair attribue une valeur d'ID d'appel à chaque session utilisateur qu'il demande ou accepte. Cette valeur d'ID d'appel doit (MUST) être unique pour le tunnel entre le PNS et le PAC auquel elle appartient. Les tunnels vers d'autres pairs peuvent utiliser le même numéro d'ID d'appel, donc le récepteur d'un paquet sur un tunnel doit associer une session utilisateur à un tunnel particulier et un ID d'appel. Il est suggéré que le nombre de valeurs d'ID d'appel potentielles pour chaque tunnel soit au moins deux fois plus grand que le nombre maximum d'appels attendus sur un tunnel donné.

Une session est définie par le triplet (PAC, PNS, Call ID).

3.2.3. Appels entrants (Incoming Calls)​

Un message Incoming-Call-Request est généré par le PAC lorsqu'une ligne téléphonique associée sonne. Le PAC sélectionne un ID d'appel et un numéro de série et indique le type de support d'appel. Les modems doivent toujours indiquer le type d'appel analogique (SHOULD). Les appels ISDN doivent indiquer numérique lorsque le service numérique sans restriction ou l'adaptation de débit est utilisé et analogique si des modems numériques sont impliqués (SHOULD). Le numéro appelant, le numéro appelé et la sous-adresse peuvent être inclus dans le message s'ils sont disponibles depuis le réseau téléphonique.

Une fois que le PAC envoie l'Incoming-Call-Request, il attend une réponse du PNS mais ne répond pas à l'appel du réseau téléphonique. Le PNS peut choisir de ne pas accepter l'appel si :

  • Aucune ressource n'est disponible pour gérer plus de sessions
  • Les champs de numéro appelé, appelant ou sous-adresse n'indiquent pas un utilisateur autorisé
  • Le service de support n'est pas autorisé ou n'est pas pris en charge

Si le PNS choisit d'accepter l'appel, il répond avec un Incoming-Call-Reply qui indique également les tailles de fenêtre (voir section 4.2). Lorsque le PAC reçoit l'Outgoing-Call-Reply, il tente de connecter l'appel, en supposant que la partie appelante n'a pas raccroché. Un message final de connexion d'appel du PAC au PNS indique que les états d'appel pour le PAC et le PNS doivent entrer dans l'état établi.

Lorsque le client entrant raccroche, l'appel est effacé normalement et le PAC envoie un message Call-Disconnect-Notify. Si le PNS souhaite effacer un appel, il envoie un message Call-Clear-Request puis attend un Call-Disconnect-Notify.

3.2.3.1. États d'appel entrant PAC (PAC Incoming Call States)​

Les états associés au PAC pour les appels entrants sont :

idle (inactif)

  • Le PAC détecte un appel entrant sur l'une de ses interfaces téléphoniques. Typiquement, cela signifie qu'une ligne analogique sonne ou qu'un TE ISDN a détecté un message SETUP Q.931 entrant. Le PAC envoie un message Incoming-Call-Request et passe à l'état wait_reply.

wait_reply (attente de réponse)

  • Le PAC reçoit un message Incoming-Call-Reply indiquant une non-volonté d'accepter l'appel (erreur générale ou refus) et retourne à l'état inactif. Si le message de réponse indique que l'appel est accepté, le PAC envoie un message Incoming-Call-Connected et entre dans l'état établi.

established (établi)

  • Les données sont échangées sur le tunnel. L'appel peut être effacé suite à :
    • Un événement sur la connexion téléphonique. Le PAC envoie un message Call-Disconnect-Notify
    • Réception d'un Call-Clear-Request. Le PAC envoie un message Call-Disconnect-Notify
    • Une raison locale. Le PAC envoie un message Call-Disconnect-Notify

3.2.3.2. États d'appel entrant PNS (PNS Incoming Call States)​

Les états associés au PNS pour les appels entrants sont :

idle (inactif)

  • Un message Incoming-Call-Request est reçu. Si la demande n'est pas acceptable, un Incoming-Call-Reply est renvoyé au PAC et le PNS reste dans l'état inactif. Si le message Incoming-Call-Request est acceptable, un Incoming-Call-Reply est envoyé indiquant accepter dans le code de résultat. La session passe à l'état wait_connect.

wait_connect (attente de connexion)

  • Si la session est connectée sur le PAC, le PAC envoie un message de connexion d'appel entrant au PNS qui passe alors à l'état établi. Le PAC peut envoyer un Call-Disconnect-Notify pour indiquer que l'appelant entrant n'a pas pu être connecté. Cela pourrait se produire, par exemple, si un utilisateur téléphonique passe accidentellement un appel vocal standard à un PAC, entraînant une défaillance de négociation sur le modem appelé.

established (établi)

  • La session est terminée soit par réception d'un message Call-Disconnect-Notify du PAC, soit par envoi d'un Call-Clear-Request. Une fois qu'un Call-Clear-Request a été envoyé, la session entre dans l'état wait_disconnect.

wait_disconnect (attente de déconnexion)

  • Une fois qu'un Call-Disconnect-Notify est reçu, la session retourne à l'état inactif.

3.2.4. Appels sortants (Outgoing Calls)​

Les messages sortants sont initiés par un PNS et ordonnent à un PAC de passer un appel sur une interface téléphonique. Il n'y a que deux messages pour les appels sortants : Outgoing-Call-Request et Outgoing-Call-Reply. Le PNS envoie un Outgoing-Call-Request spécifiant le numéro de téléphone de la partie appelée et la sous-adresse ainsi que les paramètres de vitesse et de fenêtre. Le PAC doit (MUST) répondre au message Outgoing-Call-Request avec un message Outgoing-Call-Reply une fois que le PAC détermine que :

  • L'appel a été connecté avec succès
  • Une défaillance d'appel s'est produite pour des raisons telles que : aucune interface n'est disponible pour composer, la partie appelée est occupée ou ne répond pas, ou aucune tonalité de composition n'est détectée sur l'interface choisie pour composer

3.2.4.1. États d'appel sortant PAC (PAC Outgoing Call States)​

Les états associés au PAC pour les appels sortants sont :

idle (inactif)

  • Outgoing-Call-Request reçu. Si ceci est reçu en erreur, répondre avec un Outgoing-Call-Reply avec condition d'erreur définie. Sinon, allouer un canal physique pour composer. Passer l'appel sortant, attendre une connexion et passer à l'état wait_cs_ans.

wait_cs_ans (attente de réponse de commutation de circuit)

  • Si l'appel est incomplet, envoyer un Outgoing-Call-Reply avec un code d'erreur non nul. Si un temporisateur expire sur un appel sortant, renvoyer un Outgoing-Call-Reply avec un code d'erreur non nul. Si une connexion de commutation de circuit est établie, envoyer un Outgoing-Call-Reply indiquant le succès.

established (établi)

  • Si un Call-Clear-Request est reçu, l'appel téléphonique devrait être libéré (SHOULD) via des mécanismes appropriés et un message Call-Disconnect-Notify devrait être envoyé (SHOULD) au PNS. Si l'appel est déconnecté par le client ou par l'interface téléphonique, un message Call-Disconnect-Notify devrait être envoyé (SHOULD) au PNS.

3.2.4.2. États d'appel sortant PNS (PNS Outgoing Call States)​

Les états associés au PNS pour les appels sortants sont :

idle (inactif)

  • L'indication d'ouverture de l'application de couche supérieure entraîne l'envoi d'un Outgoing-Call-Request et le passage à l'état wait_reply.

wait_reply (attente de réponse)

  • Si un Outgoing-Call-Reply avec erreur est reçu, retourner à l'état inactif. Si un Outgoing-Call-Reply réussi est reçu, passer à l'état établi. Si un abandon se produit en attendant l'Outgoing-Call-Reply, envoyer un Call-Clear-Request et passer à l'état wait_disconnect.

established (établi)

  • Si un Call-Disconnect-Notify est reçu, passer à l'état inactif. Si une terminaison locale se produit, envoyer un Call-Clear-Request et passer à l'état wait_disconnect.

wait_disconnect (attente de déconnexion)

  • Si un Call-Disconnect-Notify est reçu, passer à l'état inactif.
Dernière mise à jour le