IMS Application Server: onde a lógica de serviço reside no core IMS

Um core IMS pode registrar um assinante, autenticá-lo e rotear uma sessão até seu destino sem jamais entregar um único recurso. Encaminhamento de chamada, chamada em espera, conferência multiponto, SMS sobre IP, o handover que mantém uma chamada móvel ativa quando ela sai da cobertura LTE: nada disso reside na camada de roteamento. Reside no Application Server. O S-CSCF sabe como alcançar o Application Server correto e quando invocá-lo, mas a lógica de serviço propriamente dita fica um plano acima, em software construído exatamente para essa função.

Este artigo foca especificamente no Application Server (AS): o que ele é, a interface ISC que o conecta ao core IMS, como o S-CSCF decide entregar uma sessão a ele, os modos em que ele pode operar e os Application Servers comuns que um engenheiro de voz realmente encontra em produção. Se você quer primeiro a arquitetura IMS completa, nosso guia sobre o que é IMS cobre o plano de controle e os gateways. Aqui vamos mais fundo no único elemento onde os recursos nascem. A TelcoBridges tem mais de vinte anos de experiência na fronteira onde esse tráfego encontra o resto do mundo.

O que é um IMS Application Server

O IMS é geralmente representado como três planos horizontais: um plano de acesso onde o dispositivo se conecta, um plano de controle que registra usuários e roteia sessões, e um plano de aplicação onde a lógica de serviço é executada. O Application Server reside nesse plano superior. Enquanto os elementos do plano de controle se preocupam em alcançar o assinante correto, o AS se preocupa com o que acontece quando a sessão está em andamento: se deve encaminhá-la, bifurcá-la para vários destinos, reproduzir um anúncio, colocá-la em espera ou gerar uma mensagem própria.

Um AS é uma entidade SIP especializada. Ele fala o mesmo Session Initiation Protocol que o restante do core, definido na RFC 3261, e do ponto de vista do S-CSCF é apenas mais um destino SIP para o qual sessões podem ser roteadas. Fabricantes vendem produtos de Application Server, e cada um mapeia o comportamento padronizado em seu próprio software, mas a arquitetura de referência e a interface com o core permanecem consistentes. Isso permite que uma operadora compre um Application Server de telefonia de um fornecedor e um Application Server de mensagens de outro, ambos operando atrás do mesmo S-CSCF. Se a camada de protocolo não é familiar, nosso guia sobre fundamentos de sinalização SIP cobre os métodos e respostas sobre os quais tudo aqui é construído.

A arquitetura é definida pelo 3GPP, principalmente no TS 23.228 para o IMS geral e no TS 23.218 para como o AS e o core interagem. O ponto fundamental a reter é a separação de responsabilidades: o core roteia, o AS entrega recursos, e uma única interface SIP une os dois.

A interface ISC: como o core alcança o AS

A ligação entre o S-CSCF e um Application Server é a interface ISC, abreviação de IP Multimedia Service Control. Não é um protocolo novo. ISC é SIP, usado como ponto de referência com comportamento definido, razão pela qual um AS pode ser tratado como um servidor SIP comum pelo restante do core.

Quando o S-CSCF decide que uma sessão precisa de lógica de serviço, ele roteia a requisição ao AS pela ISC, o AS realiza seu trabalho e, na maioria dos casos, envia a sessão de volta ao S-CSCF para continuar em direção ao destino. A sessão sai da camada de roteamento, passa pela camada de recursos e retorna. Essa viagem de ida e volta é o que torna os recursos componíveis: o S-CSCF pode enviar uma única sessão por vários Application Servers em sequência, cada um adicionando seu próprio comportamento, sem que nenhum deles precise conhecer os outros.

Como a ISC é SIP, o AS vê a mesma linha de requisição, cabeçalhos e corpo SDP que trafegam em qualquer tronco. Se você quer uma visão campo a campo do que essas mensagens contêm, nossa referência sobre o fluxo de chamada SIP passo a passo percorre cada uma delas. A diferença no IMS não são as mensagens em si, mas a orquestração ao redor delas, e essa orquestração é conduzida pela próxima peça.

Como o S-CSCF decide invocar um AS

O S-CSCF não entrega cada sessão a cada Application Server. Ele consulta um conjunto de regras chamado Initial Filter Criteria, o iFC, que reside no perfil de serviço do assinante. Esse perfil é armazenado no Home Subscriber Server (HSS) e baixado para o S-CSCF quando o usuário se registra, de modo que quando qualquer sessão chega o core já conhece os direitos de recursos do assinante.

Cada entrada no iFC associa um gatilho a um destino. O gatilho é construído a partir de um ou mais Service Point Triggers, os SPTs, cada um testando algo sobre a requisição: o método SIP, a direção da sessão, a presença ou valor de um cabeçalho, ou uma linha no SDP. Quando uma requisição corresponde, o S-CSCF a roteia pela ISC ao Application Server nomeado naquela entrada. As entradas possuem uma prioridade, então o S-CSCF as avalia em ordem e pode encadear vários Application Servers em uma única sessão, cada um invocado quando seu próprio gatilho dispara.

Um Application Server frequentemente precisa de mais informações sobre o assinante do que uma única requisição SIP carrega. Para isso, ele se comunica diretamente com o HSS pela interface Sh, um ponto de referência Diameter que usa para ler e gravar os dados de serviço dos quais um recurso depende, como um número de encaminhamento ou uma lista de presença. A divisão permanece limpa: o iFC decide se invoca o AS, a ISC transporta a sessão até ele, e a Sh fornece os dados de assinante sobre os quais o serviço opera.

Os modos em que um Application Server pode operar

O 3GPP TS 23.218 define como um Application Server se comporta como entidade SIP, e o comportamento não é um papel único e fixo. Dependendo do recurso que está entregando, um AS atua em um de vários modos na interface ISC.

Como agente de usuário de terminação, o AS é o ponto final da sessão. Um servidor de correio de voz que atende uma chamada que o assinante não atendeu está atuando dessa forma, encerrando a sessão em vez de repassá-la. Como agente de usuário de originação, o AS cria uma sessão própria, que é como um servidor gera uma chamada de notificação ou envia uma mensagem que nenhum assinante iniciou. Como proxy SIP, o AS observa e encaminha a requisição com alterações mínimas, adequado para registro, triagem ou decisões leves de roteamento onde a sessão não está sendo reformulada.

O modo mais capaz é o Agente de Usuário Back-to-Back (B2BUA), onde o AS termina o trecho de entrada e origina um novo, dando-lhe controle total da sessão. O controle de chamada de terceiros depende desse modo: recursos como transferência de chamada, conferência e encaminhamento complexo exigem que o AS manipule ambos os lados de uma chamada, o que um proxy não consegue fazer. A distinção entre um proxy de encaminhamento e um B2BUA completo é a mesma que separa um roteador leve de um verdadeiro controlador de sessão, e nosso artigo sobre o que é um proxy SIP versus um B2BUA cobre exatamente por que a diferença importa. Um AS também pode atuar como servidor de redirecionamento SIP, informando ao core para onde enviar a sessão em vez de transportá-la.

Application Servers comuns e o que fazem

Os padrões deixam o AS deliberadamente genérico para que qualquer serviço possa ser construído sobre ele, mas um punhado de Application Servers aparece em quase toda rede de operadora, cada um responsável por uma função reconhecível.

O MMTel AS, para telefonia multimídia, é o que a maioria das sessões toca. Ele entrega os serviços suplementares que os assinantes esperam de uma linha telefônica: chamada em espera e retomada, encaminhamento de chamada em suas várias modalidades, bloqueio de chamada, conferência multiponto e os serviços de identidade que apresentam ou restringem o número do chamador. Quando um assinante VoLTE encaminha uma chamada ou entra em uma conferência, o MMTel AS é o elemento que torna isso possível.

O SCC AS, para centralização e continuidade de serviço, existe para manter sessões ativas através de fronteiras. Sua função mais conhecida é o SRVCC, single radio voice call continuity, que transfere uma chamada VoLTE em andamento para uma rede comutada por circuito quando o assinante sai da cobertura LTE. Para fazer isso, o SCC AS ancora a sessão de modo que haja um ponto fixo de controle para transferir, o que só é possível porque ele está no caminho como B2BUA.

O IP-SM-GW, o IP Short Message Gateway, transporta SMS pela rede IMS. Ele interconecta mensagens curtas entre o domínio IP e a infraestrutura de SMS legada, para que uma mensagem enviada de um terminal VoLTE alcance um assinante em uma rede mais antiga e vice-versa. Mensagens e serviços mais ricos seguem o mesmo padrão: um servidor de presença rastreia quem está disponível, e um Application Server RCS entrega os serviços de comunicação enriquecida que estendem a mensageria simples. Se você está avaliando o lado de mensagens do IMS, nossa comparação entre RCS e SMS cobre onde cada um se encaixa.

Além desses, operadoras executam Application Servers para tudo, de tons de ringback a gravação regulatória. A forma é sempre a mesma: uma entidade SIP que o S-CSCF invoca por iFC, comunicando-se com o HSS pela Sh para quaisquer dados de assinante que o recurso precise.

Registro de terceiros: como um AS sabe que você está online

Um recurso como encaminhamento de chamada ou presença só é útil se o Application Server souber se o assinante está registrado. O AS não vê o REGISTER original, porque ele trafega entre o dispositivo e o S-CSCF, então o IMS usa um mecanismo chamado third-party registration para fechar essa lacuna.

Quando um assinante se registra e o S-CSCF carrega seu perfil de serviço, o iFC pode incluir um gatilho que dispara no próprio REGISTER. Quando isso ocorre, o S-CSCF envia um REGISTER separado ao Application Server nomeado, em nome do assinante. Esse REGISTER de terceiros informa ao AS que o usuário agora está online e qual S-CSCF o está servindo, para que o AS possa se inscrever em eventos de registro, preparar seu estado e estar pronto no momento em que uma sessão chegar. É o handshake silencioso que permite que um servidor de recursos permaneça sincronizado com um assinante com quem nunca fala diretamente durante o registro.

Onde o SBC se encaixa em relação ao Application Server

Para quem compra, implanta ou opera Controladores de Borda de Sessão (SBC), a pergunta útil é como o AS e o SBC se relacionam. Eles são complementares, não concorrentes. O Application Server fica no plano de aplicação e controla a lógica de serviço. O SBC fica nas bordas da rede e controla o perímetro, na borda de acesso voltada para dispositivos e na interface rede-a-rede voltada para outras operadoras. Um SBC não hospeda recursos, e um AS não protege um perímetro.

Os dois ainda interagem, porque o tráfego moldado por um Application Server precisa cruzar as mesmas bordas que todo o resto. Quando um AS ancora mídia, por exemplo um anúncio ou uma ponte de conferência proveniente da media resource function, essa mídia ainda sai e entra na rede pelo SBC. Quando sessões que um AS tocou são entregues a outra operadora, o SBC na interface rede-a-rede realiza ocultação de topologia para que os endereços internos do core e de seus Application Servers nunca sejam expostos ao lado remoto. E como diferentes operadoras executam Application Servers de diferentes fornecedores, o SBC normaliza SIP entre os dialetos que cada lado fala, para que uma sessão que saiu do AS de uma rede seja entendida pela próxima. Essa normalização é o mesmo trabalho de interoperabilidade multi-fornecedor que um SBC faz em qualquer interconexão, aqui aplicado ao tráfego originado no IMS.

Há um modo que vale nomear explicitamente. Tanto um AS rico em recursos quanto um SBC de classe operadora operam como Agentes de Usuário Back-to-Back (B2BUA), mas para fins diferentes. O AS é um B2BUA no core para poder controlar ambos os trechos de uma chamada e entregar um serviço. O SBC é um B2BUA na borda para poder terminar e re-originar completamente a sinalização e a mídia, que é o que torna possível a ocultação de topologia, manipulação de cabeçalhos e segurança de mídia. Mesma arquitetura, lugar diferente na rede, função diferente.

Perguntas frequentes

Conclusão

O Application Server é onde o IMS para de rotear e começa a entregar. O S-CSCF o alcança pela interface ISC baseada em SIP, decide quando invocá-lo a partir dos Initial Filter Criteria no perfil do assinante, e pode encadear vários Application Servers em uma única sessão. O MMTel AS cobre recursos de telefonia, o SCC AS mantém chamadas ativas durante handovers, o IP-SM-GW transporta mensagens, e o registro de terceiros mantém cada um sincronizado com o assinante. Para um engenheiro de voz na borda, a conclusão principal é a fronteira: a lógica de serviço pertence ao Application Server no core, enquanto a borda controlada e segura que esse tráfego cruza pertence ao SBC.