Conteneur SIP

Le conteneur SIP ne parvient pas à traiter une requête d'annulation lorsqu'il a renvoyé une réponse 100 (Problème 712)

Description

Le conteneur SIP ne peut pas traiter une requête d'annulation lorsqu'une réponse 100 a été envoyée.

Solution

L'application doit envoyer une réponse provisoire (telle que 1xx), de manière à ce que la partie distante puisse annuler la requête d'invitation.

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 
	}

La session SIP se poursuit après le rappel du conteneur pour sessionExpired (Problème 1265)

Description

Il s'agit d'un problème intermittent. Le conteneur SIP répond par intermittence avec un message d'erreur interne 500 Serveur au lieu d'une erreur 481 Appel/Transaction inexistant lorsqu'il y a une condition de compétitivité entre l'erreur 200 de notification indiquant que la session a été supprimée et la requête d'inscription envoyée par le client lorsqu'il reçoit cette notification.

Solution

Le client doit actualiser la requête d'inscription avant que l'abonnement expire.

Communications Server agit d'abord comme un UAS, puis en tant que proxy, puis génère un NOP (Problème 1432)

Description

Lorsqu'il reçoit une requête d'invitation, Communications Server agit d'abord comme un UAS, répond à cette requête avec 1XX, puis transmet cette demande d'invitation à une autre instance, qui envoie une réponse 200 OK. Le 1xx crée une branche virtuelle interne tandis que le message 200 crée une branche réelle. Une fois le message 200 OK de B reçu, la branche virtuelle interne doit être annulée.

Solution

Cette trace d'exception n'affecte pas la fonctionnalité de la branche de proxy virtuelle.

La méthode getLastAccessedTime ne permet pas de fournir des résultats précis (Problème 1351)

Description

La méthode getLastAccessedTime d'une session SIP ne permet pas de fournir des résultats précis.

Solution

Les applications nécessitant de conserver une trace précise de lastAccessedTime doivent être stockées dans SipApplicationSession.

synchronized (sas) {
	Long last = (Long) sas.getAttribute("myLastAccessedTime");
	if (last == null) {last = 0};
	// do something with the last one
	// and...
	// set the new one.
	sas.setAttribute("myLastAccessedTime", System.currentTimeMillis());
}

Le listener SIP reste actif un certain temps après sa suppression (Problème 1294)

Description

Après la suppression d'un listener SIP configuré pour des requêtes TCP et UDP, il reste actif pendant quelques instants. Les requêtes UDP envoyées au listener peuvent recevoir une réponse du listener.

Solution

Aucune solution connue. Le listener SIP arrête l'écoute des requêtes UDP après un certain temps. Ce problème n'a aucun impact sur les requêtes TCP.

Communications Server génère une exception lors de la réception d'un en-tête Contact sans « <> » (Problème 1489)

Description

Communications Server génère une exception lors de la réception d'un en-tête Contact sans « <> ». Conformément à la spécification SIP RFC 3261, il n'est pas obligatoire d'indiquer « <> » dans l'adresse. Cela peut entraîner des problèmes d'interopérabilité avec d'autres périphériques non compatibles SIP.

Solution

Utilisez « <> » dans l'en-tête Contact.

Communications Server génère une exception sur une valeur UUID incorrecte (Problème 1494)

Description

Communications Server génère une exception sur une valeur UUID incorrecte au lieu de renvoyer une erreur 400, Requête erronée. La valeur UUID réside dans la valeur sip.instance de l'en-tête du contact SIP.

Solution

Aucune solution connue.

Windows : parfois Communications Server ne reçoit pas les messages UDP (pas d'ID)

Description

Ce problème n'est rencontré que par intermittence et sous Windows. Communications Server ne reçoit pas les messages UDP.

Solution

Définissez l'option JVM suivante comme suit et redémarrez Communications Server.

org.jvnet.glassfish.comms.disableUDPSourcePort=true