Affinité de session SIP et reprise en ligne
Dans WebSphere, le protocole SIP propose l'affinité de session et la reprise en ligne.
- Affinité de session SIP
Un seul conteneur SIP dans un cluster peut gérer tous les messages associés à un même dialogue. Si un conteneur tombe en panne au milieu d'un dialogue, un seul serveur du cluster assume la responsabilité du dialogue. Le proxy SIP est chargé de gérer l'affinité de session en fonction de l'identificateur de sessions (qui contient le nom de serveur logique)). Les informations relatives au serveur logique sont publiées par le conteneur SIP et utilisées par le proxy SIP via le système WLM (Workload Management).
- Routage des messages SIP en fonction de l'ID de session
L'identificateur ibmsid est incorporé dans différents messages SIP et permet d'acheminer des sessions spécifiques qui s'exécutent sur le serveur d'applications SIP. De façon générale, les en-têtes VIA sont toujours utilisés pour acheminer des réponses. Le conteneur incorpore toujours un identificateur ibmsid dans l'en-tête VIA associé au serveur d'applications SIP. Exemple d'en-tête VIA :
Via: SIP/2.0/UDP 9.51.252.69:5063;ibmsid=sipcontainer1.1153242645968.4_2_2;branch=z9hG4bK920196437955379
Dans les applications proxy, l'identificateur ibmsid (ou l'ID de session) est inséré dans la requête initiale reçue de l'agent de client utilisateur dans l'enregistrement/routage. L'agent de serveur utilisateur renvoie le même enregistrement/routage avec l'ID de session dans la réponse. L'agent de client utilisateur renvoie l'en-tête de routage avec l'ID de session dans la requête suivante dans le dialogue. Exemple :
Dans cet exemple l'agent de serveur utilisateur renvoie le même enregistrement/routage avec l'ID de session dans la réponse, et l'agent de client utilisateur renvoie l'en-tête de routage avec l'ID de session dans la requête suivante dans le dialogue.Record-Route: <sip:protocol2.databeam.com:5060;transport=udp;ibmsid=sipcontainer1a.1138119214953.4_2_2;lr>
Pour les applications d'agent de client utilisateur et d'agent de serveur utilisateur, le conteneur tenant lieu de ces agents insère l'ID de session dans la balise A (agent de client utilisateur) ou De (agent de serveur utilisateur) (c.-à-d. la balise A local.1132518053302_2_2). La même balise A ou De est incluse dans la requête suivante.
Les URI encodés contiendront également un identificateur ibmappid (très similaire à un identificateur ibmsid), qui peut alors être envoyé dans la requête HTTP suivante. Un point important ici repose dans le fait que l'infrastructure SIP IBM ne prend pas en charge la reprise en ligne de niveau transaction. Elle ne prend en charge que la reprise en ligne des dialogues pour les appels stables.
Voici les règles générales sur la façon dont l'infrastructure SIP IBM décide des adresses à utiliser pour les en-têtes de contact qu'elle incorpore dans les messages SIP sortants :- Un serveur d'applications SIP autonome utilise sa propre adresse dans les en-têtes de contact qu'il doit insérer dans les messages SIP.
- Un serveur d'applications SIP présenté par un proxy SIP sans état utilise l'adresse du proxy SIP dans des en-têtes de contact qu'il doit insérer dans des messages SIP. Le serveur d'applications SIP découvre cette adresse via WLM.
- Un serveur d'applications SIP présenté par un proxy SIP sans état qui est alors présenté par un diffuseur d'informations utilisera l'adresse du diffuseur d'informations dans les en-têtes de contact qu'il doit insérer dans des messages SIP. L'adresse du diffuseur d'informations doit être configurée sur le proxy SIP par le biais de la console d'administration et cette adresse est "publiée" sur le serveur d'applications SIP via UCF.
- Reprise en ligne au milieu d'un appel
En cas d'incident sur un serveur, les sessions associées au serveur en panne sont activées sur les conteneurs restant dans le domaine de réplication. Lorsqu'ils sont activés, les conteneurs gérant les sessions défaillantes publient l'emplacement des sessions vers les serveurs proxy présentant le cluster via WLM. Lorsqu'un message associé à l'un des dialogues ayant échoué arrive sur le proxy, ce dernier extrait l'ID de session du message SIP et l'utilise pour rechercher le nouveau conteneur. Lors du redémarrage du serveur défaillant, ce dernier réintègre le cluster. Il ne gère alors plus que les nouveaux dialogues.
Figure 1. Reprise en ligne du conteneur SIP dans un cluster (Avant)Figure 2. Reprise en ligne du conteneur SIP dans un cluster (Après)- Applications convergentes et reprise en ligne
Tous les messages associés à une session HTTP/SIP convergente sont acheminés par le proxy vers le même conteneur dorsal à l'aide d'URI encodés et une affinité de session SIP. Les protocoles HTTP et SIP utilisent la même topologie de réplication (ils partagent les mêmes paramètres de réplication). En cas de panne, les requêtes HTTP et SIP associées à un dialogue défaillant sont acheminées vers le même serveur dorsal. Les cookies Jsession sont prioritaires sur les cookies URI encodés dans le proxy lorsque les cibles d'affinité sont déterminées.
Figure 3. Exemple d'applications convergentes