STIR/SHAKEN Starter AS-OOB SaaS Anual — Plano Light

Descrição

STIR/SHAKEN Starter AS-OOB SaaS Anual — Plano Light

Este pacote entrega a solução SaaS AS-OOB da ZICTEC para autenticação de chamadas STIR/SHAKEN com ISBC em nuvem. No modelo, o ISBC/ZICTEC funciona como elemento SIP fora de banda: recebe a tentativa de validação, consome a API ZICTEC/Neustar para executar o STI-AS (Authentication Service) e pode também executar VS (Verification Service) quando contratado.

Diferente de integrações que exigem suporte nativo profundo no SBC/softswitch de origem, o modelo SIP OOB trabalha principalmente com comportamento SIP padrão: a origem encaminha a chamada para uma rota de validação e recebe uma resposta SIP 4xx, 5xx ou 6xx para decidir se deve tentar a próxima rota, permitir continuidade por política própria ou bloquear a chamada. Por isso, é um modelo extremamente eficiente e compatível com praticamente qualquer plataforma SIP — open-source ou proprietária — desde que exista suporte a failover de rota por resposta SIP.

Como o fluxo funciona

• A origem envia a chamada para o ISBC/ZICTEC como rota SIP de validação fora de banda.
• O ISBC consulta a API ZICTEC/Neustar e executa a lógica STI-AS; VS pode ser habilitado quando aplicável.
• Se a política indicar continuidade por outra rota, o ISBC retorna código SIP apropriado para a origem acionar o failover configurado.
• Se a política indicar bloqueio/falha, o ISBC pode retornar resposta 4xx/5xx/6xx adequada ao tratamento operacional da origem.
• Opcionalmente, em topologias compatíveis, o ISBC retorna 302 Redirect com dados para a próxima rota e token Identity para que a origem encaminhe a chamada já autenticada.

Modo opcional com 302 Redirect e header Identity

Quando a plataforma de origem suporta interoperabilidade adequada, o ISBC também pode ser configurado para retornar SIP 302 Redirect. Nesse modo, a origem pode encaminhar a chamada para a próxima rota carregando o token de autenticação no header Identity. Esse modo é tecnicamente poderoso, mas depende mais da interoperabilidade do ambiente de origem do que o modo por 4xx/5xx/6xx.

O que está incluso

• Ambiente SaaS ZICTEC com ISBC em nuvem para fluxo SIP AS-OOB — Authentication Service Out-of-Band.
• Consulta do ISBC à API ZICTEC/Neustar para autenticação STI-AS; VS opcional conforme escopo contratado e topologia.
• Retorno SIP 4xx, 5xx ou 6xx para que a origem aplique política de failover, reencaminhamento, continuidade ou bloqueio da chamada.
• Modo opcional com SIP 302 Redirect, permitindo que a origem encaminhe a chamada para a próxima rota com token de autenticação no header Identity, quando a plataforma suportar esse comportamento.
• Compatibilidade ampla com plataformas SIP open-source e proprietárias que tenham suporte a failover/roteamento por resposta SIP.
• Headers SIP de diagnóstico e informações operacionais para troubleshooting e auditoria do fluxo de autenticação.
• Interface ZICTEC/STFC-Tools, auditoria transacional, relatórios e ferramenta de diagnóstico.
• Suporte operacional de implantação, homologação e entrada em produção conforme premissas do Plano Light.

Diferenciais ZICTEC

• Comportamento análogo ao modelo de redirect server usado em arquiteturas de referência STIR/SHAKEN, em que o elemento externo decide autenticação/roteamento por respostas SIP.
• A ZICTEC cumpre o papel de plataforma de decisão/API/diagnóstico no lugar de provedores de referência como ClearIP, porém com integração à API ZICTEC/Neustar, headers de diagnóstico e possibilidade de customizações conforme projeto.
• O modelo evita depender de integração profunda no core SIP do cliente: quando há suporte a failover de rota, a adoção tende a ser simples e eficiente.

Limites e premissas do Plano Light

• Plano Light: até 10 CAPS, até 10 milhões de bilhetes/mês e até 2 IPs de origem.
• A eficiência do modelo depende de a origem tratar corretamente respostas SIP e failover de rota.
• Códigos SIP, headers de diagnóstico, políticas de bloqueio/failover e uso de 302 Redirect devem ser homologados antes da produção.
• A ZICTEC pode adaptar regras e diagnósticos conforme projeto, desde que o escopo seja validado comercial e tecnicamente.

O que não está incluso

• Instalação de cliente/script local em ProSBC — esse escopo é outro produto/licença.
• Licenças ProSBC, SBCs, softswitches, hardware, conectividade, certificados, números/cadastros regulatórios ou serviços de terceiros.
• Garantia universal de 302 Redirect com Identity em qualquer plataforma: esse modo depende de suporte, roteamento, headers aceitos e interoperabilidade do ambiente de origem.
• Customizações avançadas, integrações fora do padrão, alta disponibilidade dedicada, operação assistida recorrente ou suporte 24×7 sem proposta específica.
• Campanhas/Branded Call/Origem Verificada visual para o usuário final, salvo contratação separada.

Referência técnica

O modelo é conceitualmente comparável ao uso de um redirect server STIR/SHAKEN em arquiteturas como ProSBC + ClearIP, em que o ProSBC consulta um elemento externo para lógica SHAKEN AS/VS e interpreta respostas como 404/603/3xx para roteamento, bloqueio ou encaminhamento com Identity. Na oferta ZICTEC, o ISBC/ZICTEC cumpre esse papel integrado à API ZICTEC/Neustar, com diagnósticos e customizações adicionais.

Validação antes da compra

Consulte sempre o Comercial ZICTEC antes de realizar a compra. A equipe deve confirmar topologia, plataforma de origem, suporte a failover, comportamento esperado dos códigos SIP, necessidade de VS, uso ou não de 302 Redirect, limites do Plano Light e eventuais customizações.