Aspects d'exécution pour les développeurs d'applications

Vous devez prendre en compte les comportements d'exécution de certains produits quand vous écrivez des applications SIP (Session Initiation Protocol).

Le conteneur peut accepter des plans URI non-SIP.

Le conteneur SIP ne rejette pas un message s'il ne reconnaît pas le schéma dans l'identificateur URI (Uniform Resource Indicator), car le conteneur ne peut pas connaître les schémas URI pris en charge par les applications. Les éléments SIP peuvent prendre en charge un URI de requête ayant un plan autre que sip ou sips, par exemple, le plan pres: a une signification particulière pour les serveurs de présence, mais le conteneur ne le reconnaît pas. C'est à l'application de déterminer si elle accepte ou refuse un plan spécifique. Les éléments SIP peuvent convertir des URI non-SIP à l'aide de tout mécanisme disponible ; cela donnerait lieu à des URI SIP, URI SIPS ou autres plans, tels que le plan URI tel de RFC 2806 [9].

Pour les utilisateurs en transition Pour les utilisateurs en transition: Quand une application SIP envoie une requête à une URI SIP via TLS (Transport Layer Security) dans la version 6.1, le schéma d'URI de la requête "sip" devient "sips." Dans la version actuelle, le schéma ne change pas. Vous pouvez rétablir l'ancien mode opératoire en modifiant le code de l'application. Avec un URI "sips", le mode opératoire reste identique après la mise à niveau de la version 6.1 vers la version 7.0 ou ultérieure. Pour plus d'informations, reportez-vous à la rubrique du Centre de documentation relative aux remarques sur la prémigration.trns

Orientation des requêtes dans un environnement à conteneurs multiples

Dans un environnement à conteneurs multiples (Proxy SIP et conteneurs SIP), lorsque votre application formule une requête initialement prévue pour être envoyée en externe mais reçue plus tard, elle doit utiliser l'hôte et les ports de l'élément d'équilibrage de charge le plus avancé (un pulvérisateur IP pour des proxys SIP multiples ou bien le proxy SIP s'il n'en existe qu'un seul). Si l'application utilise le nom d'hôte d'un conteneur au lieu de l'élément le plus avancé, la requête peut être perdue en cas d'incident.

Par exemple, si une application envoie une requête INVITE à elle-même, la requête doit transiter par un système de comptabilisation externe à l'aide d'un en-tête d'itinéraire intégré. L'application doit diriger l'URI de la requête INVITE vers l'hôte et le port de l'élément le plus avancé pour garantir la reprise en ligne. La requête sera acheminée jusqu'au système de comptabilisation via l'itinéraire intégré, puis sera renvoyée vers l'élément avancé d'équilibrage de charge pour être traitée.

Appel des événements d'écoute de session

Les événements SipSessionListener et SipApplicationSessionListener sont appelés uniquement si une application demande l'objet de session correspondant. Pour y parvenir, utilisez dans votre application la méthode présentée dans Tableau 1.
Tableau 1. Méthodes d'appel des événements d'écoute de session.

Ce tableau répertorie les méthodes qui appellent des événements d'écoute de sessions.

Evénement Méthode
SipSessionListener getSession()
SipApplicationSessionListener getApplicationSession()

Activation et passivation de session

En fonctionnement normal, ce produit ne déplace jamais de session d'un serveur à un autre. Seule une erreur de serveur peut provoquer une migration de session. Le rappel de passivation de la méthode SipSessionActivationListener n'est donc jamais appelé. Cependant, le rappel d'activation est appelé lorsqu'une erreur oblige la reprise d'une session vers un différent serveur.

Ressources externes

Si une application SIP effectue des opérations d'E-S ou d'accès intensives à une base de données externe, elle peut être bloquée pendant plusieurs millisecondes. Si possible, utilisez des API asynchrones pour ces ressources. En cas de surcharge, une application SIP bloquée peut déclencher un délai d'expiration de la requête ou une retransmission.

Attributs d'application SIP

Evitez de bloquer des objets LOB ou BLOB, tels que des attributs de session SIP (via l'API SIPSession.setAttribute). Ceci peut endommager les performances globales lorsque la haute disponibilité est utilisée. Les mêmes recommandations sont valables pour SIPApplicationSession.setAttribute. Dans la plupart des cas, l'objet LOB peut être remplacé par plusieurs chaînes simples ou complexes.

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rsip_refwrite
Nom du fichier : rsip_refwrite.html