Les sessions SIP et les sessions HTTP n'appliquent pas le même modèle de délai d'expiration de session (Problème 1180)

Description

Le modèle d'expiration de session des sessions SIP est différent de la logique de délai d'expiration HTTP. Dans le modèle HTTP, la session est automatiquement étendue, hors contrôle de l'application, chaque fois qu'une nouvelle requête HTTP est reçue dans cette session HTTP.

Avec les sessions SIP, l'application contrôle la durée de la session SipApplicationSession (SAS), sujette à l'approbation du conteneur SIP. Les applications peuvent utiliser la méthode setExpires pour indiquer que cette SAS devrait expirer. setExpires définit un délai d'expiration par rapport au moment où la méthode setExpires est appelée. Le conteneur peut modifier, rejeter ou accepter la durée indiquée dans setExpires. Si la session n'est pas invalidée, alors le rappel sessionExpired est réalisé au moment défini par setExpires. Dans ce rappel, l'application peut tenter d'étendre la durée de la SAS en appelant un nouveau setExpires, également sujet à modification, rejet ou acceptation par le conteneur.

Pour cette raison, les applications convergentes qui commencent avec la même heure d'expiration que la session SipApplicationSession (SAS) et la session HTTP noteront que la session SAS expire avant la session HTTP si de nouvelles requêtes ont été reçues sur la session HTTP.

Solution

La meilleure manière de gérer les différents délais d'expiration des sessions SIP et HTTP est de commencer avec un délai d'expiration SAS suffisamment long, qui représente la durée totale prévue de la session d'application (avec plusieurs requêtes HTTP). La durée de vie d'une session SAS pourrait même être réglée sur l'infini, en particulier si la sémantique invalidateWhenReady est utilisée, auquel cas la session SipApplicationSession est invalidée lorsque la dernière session enfant du protocole est invalidée. Le premier délai d'expiration pour le SAS peut être configuré dans le descripteur de déploiement.

Si la durée totale maximale peut être estimée à l'avance, aucun autre code est nécessaire, puisqu'il convient donc d'invalider la session SIP et la session HTTP lorsque le SAS expire. Si la durée maximale ne peut être estimée à l'avance, la session SipApplicationSession peut être étendue lorsqu'elle arrive à expiration, comme illustré dans le fragment de code ci-dessous.

Dans l'implémentation SipApplicationSessionListener, vous pouvez effectuer une action, comme suit :

public void sessionExpired(SipApplicationSessionEvent sasEvent) {
                // check if the SAS needs to be extended first, if so:
		int granted = sasEvent.getApplicationSession().setExpires(2);
		if (granted <= 0) {
			System.out.println("extension rejected");
		} else if (granted < 2) {
			System.out.println("extension granted with lower value " + granted);
		} // else allowed 
	}