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].

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.Evénement | Méthode |
---|---|
SipSessionListener | getSession() |
SipApplicationSessionListener | getApplicationSession() |