Considerações do Tempo de Execução para Desenvolvedores de Aplicativos SIP
Considere os comportamentos do tempo de execução de determinado produto ao gravar aplicativos SIP (Session Initiation Protocol).
O contêiner pode aceitar esquemas URI não SIP
O contêiner de SIP não rejeitará uma mensagem caso não reconheça o esquema no Uniform Resource Indicator (URI) do pedido porque o contêiner não poderá saber quais esquemas URI são suportados pelos aplicativos. Os elementos SIP podem suportar um URI de pedido com um esquema diferente de sip ou sips, por exemplo, o esquema pres: tem um significado especial para servidores de presença, mas o contêiner não o reconhece. Ele está preparado para determinar se aceitar ou rejeitar um esquema específico. Os elementos SIP pode converter URIs não SIP utilizando algum mecanismo disponível, resultando em URIs SIP, URIs SIPS e outros esquemas, como o esquema URI tel do RFC 2806 [9].

Direcionando pedidos num ambiente de vários contêineres
Num ambiente de vários contêineres (proxy SIP mais contêineres SIP), quando o aplicativo envia um pedido que se destina inicialmente a ser enviado externamente, mas recebido posteriormente, ele deve utilizar o host e portas do elemento mais a frente no balanceamento de cargas (ou um sprayer de IPs para vários proxies IP SIP, ou o proxy SIP se apenas um existir). Se o aplicativo utilizar o nome do host de um contêiner em vez do elemento mais a frente, o pedido pode ser perdido no caso de uma falha.
Por exemplo, um aplicativo envia um pedido INVITE para ele mesmo, mas o pedido deve passar por um sistema de contabilidade externo por meio de um cabeçalho de Rota pressionada. O aplicativo deve configurar o URI do pedido INVITE para o host e porta do elemento mais a frente para garantir a ocorrência do failover. Os pedidos serão roteados para o sistema de contabilidade por meio de uma Rota pressionada, e enviar de volta ao elemento de balanceamento de carga frontal para processamento.
Chamando Eventos do Listener de Sessão
Os eventos SipSessionListener e SipApplicationSessionListener são chamados apenas se um aplicativo pedir o objeto de sessão correspondente. Isso é feito utilizando no seu aplicativo o método mostrado em Tabela 1.As classes de eventos | Método |
---|---|
SipSessionListener | getSession() |
SipApplicationSessionListener | getApplicationSession() |