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 
	}