Le mécanisme de redondance du serveur SIP garantit la fiabilité et la continuité du service SIP. Le déploiement d’un serveur principal et d’un serveur de secours est l’un des modes de redondance courants. Les serveurs principal et de secours partagent les comptes utilisateurs, les informations de Dialog selon la mise en œuvre de la solution de redondance, les informations de Registration et d’autres données de service. En fonctionnement normal, toutes les requêtes et réponses SIP sont traitées par le serveur principal. Lorsque le serveur principal tombe en panne, est en maintenance ou devient inaccessible, le terminal SIP bascule automatiquement vers le serveur de secours pour demander le service, afin de préserver la continuité d’utilisation. Lorsque le serveur principal est rétabli, le terminal SIP peut revenir automatiquement vers le serveur principal pour demander le service.
Figure 1 Serveur SIP principal et de secours
Failover : mécanisme par lequel le serveur de secours prend en charge tous les services lorsque le serveur principal est indisponible, sans affecter l’utilisation par le client.
Failback : mécanisme par lequel l’équipement vérifie si le serveur principal est rétabli lorsque le serveur de secours fonctionne, afin de revenir rapidement au serveur principal.
Server Unavailable : le client demande l’enregistrement et le Server répond 500/503, ou UDP reçoit un ICMP de destination inaccessible, ou la connexion TCP expire.
Register Failback : lorsque le serveur principal est indisponible et que le téléphone est enregistré sur le serveur de secours, le téléphone crée un nouveau Register Dialog pour vérifier si le serveur principal est rétabli. Cette fonction dispose d’un cycle de détection indépendant et configurable.
Ce document s’adresse au personnel interne de R&D ou de test qui souhaite comprendre comment la fonction Dial plan est améliorée.
Configurez deux informations Server pour la ligne SIP du téléphone. SIP Server1 est le serveur principal et SIP Server2 est le serveur de secours.
Le téléphone prend en charge le Failover pour les signalisations Register, Invite et Bye. Les autres signalisations ne sont pas encore prises en charge.
2.2.1 Register Failover
Conditions de déclenchement : enregistrement manuel / expiration de l’enregistrement / expiration de la requête Option ou Cancel
1) Le téléphone envoie une signalisation Register au serveur principal.
2) Le téléphone tente d’envoyer Register au serveur principal un nombre de fois défini pour les produits V3, ou pendant une durée spécifique pour les produits V2.
3) Lorsque le serveur principal est Unavailable, le téléphone envoie la signalisation Register au serveur de secours.
4) Le serveur de secours répond 200 OK et le téléphone est enregistré avec succès.
2.2.2 Invite Failover
Condition de déclenchement : l’utilisateur passe un appel
1) Le téléphone A appelle le téléphone B.
2) Le téléphone A envoie une requête Invite au serveur principal.
3) Le téléphone A tente d’envoyer Invite au serveur principal un nombre de fois défini pour les produits V3, ou pendant une durée spécifique pour les produits V2.
4) Lorsque le serveur principal est Unavailable, le téléphone envoie Register au serveur de secours.
5) Le serveur de secours répond 200 OK au téléphone et le téléphone s’enregistre avec succès sur le serveur de secours.
6) Le téléphone envoie une requête Invite au serveur de secours.
7) Le serveur de secours répond 200 OK et les téléphones A et B établissent l’appel.
2.2.3 Bye Failover
Condition de déclenchement : après qu’un appel a été établi via le serveur principal, le téléphone raccroche
1) Le téléphone A établit un appel avec le téléphone B via le serveur principal.
2) Le téléphone A raccroche.
3) Le téléphone A envoie une requête Bye au serveur principal.
4) Le téléphone A tente d’envoyer Bye au serveur principal un nombre de fois défini pour les produits V3, ou pendant une durée spécifique pour les produits V2.
5) Lorsque le serveur principal est Unavailable, le téléphone envoie Register au serveur de secours.
6) Le serveur de secours répond 200 OK au téléphone et le téléphone s’enregistre avec succès sur le serveur de secours.
7) Le téléphone envoie un message Bye au serveur de secours.
8) Le serveur de secours répond 200 OK et l’appel du téléphone B se termine.
2.2.4 Échec du Failover
Lorsque tous les serveurs sont indisponibles, le téléphone essaie chaque serveur dans l’ordre de priorité des serveurs principal et de secours, selon le nombre de tentatives défini pour les produits V3 ou pendant une durée spécifique pour les produits V2. Le dernier serveur fait exception. Selon RFC3261, SIP tente pendant 64*T1, soit 32 secondes. La requête de signalisation SIP actuelle échoue alors et le résultat est indiqué à l’utilisateur.
Le téléphone prend en charge un Register Failback indépendant. Une fois l’enregistrement réussi sur le serveur de secours, le téléphone envoie périodiquement un Register indépendant au serveur principal afin de vérifier si le serveur principal est rétabli.
Condition de déclenchement : expiration du minuteur Register Failback.
1) Le téléphone s’enregistre avec succès sur le serveur de secours.
2) À l’expiration du Register Failback, le téléphone envoie un Register indépendant au serveur principal.
3) Le serveur principal répond 200 OK et le téléphone bascule vers le serveur principal.
Lorsque le serveur principal reste indisponible, le Register envoyé par le téléphone est retransmis selon RFC3261 jusqu’à l’expiration de 64*T1, soit 32 secondes. Après expiration, le minuteur redémarre pour détecter périodiquement le serveur principal.
| Nom de l’élément de configuration | Description | Valeur | |
| SIPN | Register Addr: | Adresse du serveur principal. | IP/nom de domaine Valeur par défaut : vide |
| SIPN | Register Port: | Port de service du serveur principal. | Numérique Valeur par défaut : 5060 |
| SIPN | Register TTL: | Cycle d’enregistrement du serveur principal. | Numérique Valeur par défaut : 3600 Unité : secondes |
| SIPN | Transport: | Protocole de transport du serveur principal : UDP, TCP ou TLS. | 0 : UDP 1 : TCP 3 : TLS Valeur par défaut : 0 |
| SIPN | Backup Addr: | Adresse du serveur de secours. | IP/nom de domaine Valeur par défaut : vide |
| SIPN | Backup Port: | Port de service du serveur de secours. | Numérique Valeur par défaut : 5060 |
| SIPN | Backup TTL: | Cycle d’enregistrement du serveur de secours. | Numérique Valeur par défaut : 3600 Unité : secondes |
| SIPN | Backup Transport: | Protocole de transport du serveur de secours : UDP, TCP ou TLS. | 0 : UDP 1 : TCP 3 : TLS Valeur par défaut : 0 |
| SIPN | Enable Failback: | Contrôle si la ligne active la fonction Register Failback. | 0/1 Valeur par défaut : 1 |
| SIPN Failback Interval: | Intervalle de détection permettant de vérifier si le serveur principal ou Proxy est rétabli après l’enregistrement sur le serveur de secours ou Proxy. | Numérique Valeur par défaut : 1800 Unité : secondes | |
| SIPN Signal Retry Counts: | Nombre de retransmissions de SIP Request lorsque le serveur ou Proxy est indisponible, à l’exception du dernier serveur ou Proxy, qui utilise un délai d’expiration de 32 secondes. | Numérique Valeur par défaut : 3 | |
L’utilisateur peut se connecter au serveur Web du téléphone afin de configurer les serveurs principal et de secours.
1) Cliquez sur l’onglet « Ligne » et sélectionnez le sous-onglet SIP, qui est la page par défaut.
2) Sélectionnez la ligne à configurer dans la liste déroulante « Ligne » à l’intérieur de la page.
3) Configurez les informations d’enregistrement de la ligne.
4) Configurez les informations du SIP Server1, serveur principal, et du SIP Server2, serveur de secours, comme indiqué à la Figure 2.
5) Cliquez sur « Paramètres de base » sur la page actuelle pour définir les éléments liés au Failback principal et de secours, comme indiqué à la Figure 3.
6) Cliquez sur le bouton « Soumettre » en bas de la page afin d’appliquer la configuration.
Figure 2 Configuration du serveur SIP principal et de secours
Figure 3 Configuration du Failback SIP principal et de secours