Resumo

  • A RFC 3136 organizou os atores necessários para levar um evento originado na rede telefônica até um usuário da Internet e devolver sua escolha de tratamento à rede de chamadas.
  • O clique não era a execução. Gateway e SPIRITS Client ainda transportavam a disposição, a SCF a convertia em ação telefônica e o switch retomava o processamento antes de existir um resultado para quem ligou.

A chamada ficou em espera; a decisão atravessou duas redes

Na Internet discada, uma única linha doméstica tinha dois usos concorrentes. Enquanto o modem sustentava a sessão de dados, uma chamada de voz podia chegar ao mesmo número. Internet Call Waiting queria fazer mais do que emitir um sinal de ocupado: pretendia avisar a pessoa conectada e permitir que ela escolhesse um tratamento.

Na tela apareciam número ou nome, quando disponíveis, e opções como aceitar a chamada depois de encerrar a sessão, encaminhar, mandar para caixa postal, tocar uma mensagem ou rejeitar. O software sabia que um botão fora pressionado. Era uma evidência forte da intenção naquele host.

Mas a chamada não morava no host. Estava em um estado da rede telefônica, possivelmente suspensa enquanto o serviço aguardava resposta. Para transformar preferência em efeito, a arquitetura precisava levar a decisão ao domínio que controlava o call processing.

Publicada em junho de 2001 como Informational, a RFC 3136 não especificou um protocolo completo. Descreveu componentes e interfaces para serviços SPIRITS—serviços que começavam no PSTN e necessitavam da Internet. Esse estatuto limita a conclusão: o desenho define responsabilidades, não comprova uma implantação nem uma taxa de sucesso.

O evento nasceu no lado telefônico

A Service Switching Function, normalmente dentro do comutador, reconhecia triggers de Intelligent Network e interagia com a Service Control Function. A SCF executava a lógica do serviço e instruía os switches sobre como completar a chamada.

Há vários recibos antes da tela: a chamada atingiu um ponto de detecção; o SSF reconheceu o trigger; o SCF recebeu informação suficiente; o controle resolveu publicar um evento. A ausência de qualquer um deles muda a falha. Um pop-up que não apareceu não diz, sozinho, se faltou o trigger ou se a Internet perdeu a notificação.

O SPIRITS Client representava a borda de controle telefônico. Recebia solicitações da SCF e enviava respostas. Podia ser co-localizado com a SCF ou conversar com ela pela interface D. As caixas eram funções lógicas, não uma promessa de equipamentos fisicamente separados.

O SPIRITS Gateway mediava a passagem para o domínio IP e podia compartilhar localização com elementos PINT. O SPIRITS Server cuidava da interação com o assinante, terminando solicitações do PSTN, entregando notificações e retransmitindo o tratamento escolhido. Nenhum nome de componente condensava toda a autoridade.

Cada interface respondia a uma pergunta

A interface A levava solicitações PINT do host ao PINT Server. No arranjo SPIRITS, sua função principal era registrar a sessão e ativar o serviço durante um período; podia também ser usada para assinatura. Registro ativo não significava trigger armado nem host alcançável no minuto seguinte.

B ficava entre SPIRITS Server e Gateway. Em um sentido, levava a notificação de chamada e os dados disponíveis do chamador. No outro, levava a disposição escolhida naquele momento. A entrega da notificação não confirmava o caminho de volta. A chegada ao Gateway ainda não confirmava o domínio telefônico.

C ligava Gateway e SPIRITS Client. O Gateway podia falar com o Server ou funcionar como servidor virtual, terminando a solicitação. Por isso, “terminada no Gateway” podia ser o resultado arquitetural esperado, não um erro; só a implementação dizia qual leitura era correta.

D ligava Client e SCF. Parâmetros do trigger saíam da SCF; a disposição do assinante voltava. A RFC 3136 dizia que a SCF transformava a disposição em ações apropriadas, como tocar um anúncio, e retomava no SSP o processamento que estava suspenso.

E entregava solicitações PINT à SCF para execução. PINT começava com uma solicitação na Internet; SPIRITS começava com um evento no PSTN. O reúso de blocos não tornava registro, evento, escolha e ação o mesmo objeto.

Um rótulo precisava virar sequência telefônica

“Rejeitar” é uma palavra de interface. A chamada exige operações. O host pode registrar o clique; o Server pode serializar; o Gateway pode autenticar; o Client pode entregar à SCF. Até aí há uma intenção legítima que chegou a um ponto de decisão.

A SCF ainda interpreta a opção à luz do estado da chamada, do plano contratado e da política da operadora. Pode precisar ordenar um anúncio e depois liberar. O SSP precisa executar dentro do prazo. Se a resposta chegar depois de o switch sair do estado suspenso, o conteúdo pode ser correto e já não ter poder sobre aquela chamada.

“Encaminhar” abre uma cadeia adicional. O número pode ser válido, o switch pode aceitar a rota e o destino pode estar ocupado, fora de serviço ou não atender. “Caixa postal” pode alcançar a plataforma sem preservar mensagem útil. “Aceitar” pode exigir derrubar o modem antes de devolver voz à linha. A RFC citava aceitação por voz sobre IP, mas declarava que sua arquitetura proposta não refletia essa função.

Uma auditoria precisa separar registro da sessão, reconhecimento do trigger, emissão e entrega da notificação, escolha manual ou de perfil, recepção por Server/Gateway/Client, transformação da SCF, ação do switch, resultado no destino e leitura independente. A confirmação anterior não herda a semântica da etapa seguinte.

A regra automática continuava sujeita ao mesmo caminho

O assinante podia definir uma regra geral ou tratamentos específicos por número de origem. A chamada seria processada sem uma janela ao vivo, e depois um log mostraria hora, número, nome e disposição.

O log era evidência de uma observação local. A palavra “forwarded” poderia significar que a regra venceu, que a instrução foi enviada ou que o sistema classificou algum retorno como sucesso. Sem declarar observador e condição de conclusão, não provava que o destino tocou nem que uma pessoa respondeu.

A RFC 2995 havia pesquisado quatro implementações anteriores ao padrão. Todas ofereciam Internet Call Waiting, a maioria usava SIP e todas adotavam soluções IN no lado PSTN. O próprio documento, porém, dizia que nem todas interoperavam e que as baseadas em SIP não necessariamente suportavam a mesma versão.

“SPIRITS server” também variava de significado entre implementações. O código em execução demonstrava possibilidades reais, mas não autorizava projetar um único caminho universal sobre todos os sistemas nem transformar contador ou log em observação humana.

Saber da chamada não conferia controle sobre ela

A RFC 3298 exigiu depois que o protocolo mínimo pudesse oferecer notificação básica sem depender de PINT nem de interação persistente com o PSTN. Assim, informar um evento era uma capacidade completa por si; modificar a chamada era outra.

Para o caso com disposição, o documento desenhou registro, notificação, escolha, Service Control e SSP. Descreveu a reação à notificação como o elemento restante necessário ao serviço. Aceitar, rejeitar e redirecionar compunham o vocabulário básico; aceitar por VoIP permaneceu fora do escopo.

Um produto honesto pode mostrar “evento recebido”, “escolha enviada”, “política aceita”, “switch executou” e “destino respondeu”. Mesclar todos em “concluído” apaga o limite de autoridade.

Em 2004, a RFC 3910 especificou pacotes de evento SPIRITS com SIP SUBSCRIBE/NOTIFY e XML. Passou a chamar o lado Internet de subscriber de eventos e o lado PSTN de notifier. A nomenclatura seguia quem pedia observação e quem emitia o fato.

Também separou detection points Request e Notification. Um Request suspendia o processamento no SSP até uma resposta da SCP. Um Notification permitia seguir após avisar. Receber um NOTIFY não provava que a central aguardava uma decisão da Internet.

Até a assinatura tinha fases. Uma resposta 202 podia ser seguida por NOTIFY dizendo que a solicitação havia sido aceita e estava sendo processada, e outro somente quando os detection points estivessem inicializados. Depois, o trigger real produziria nova notificação. Aceito, pronto e ocorrido eram estados diferentes.

O ponto de transformação ficou sob política local

A RFC 3910 concentrou-se em B e C e declarou D matéria de política local da operadora PSTN. D poderia ser interface funcional ou troca de mensagens. O protocolo comum parava antes de universalizar a integração que realmente convertia a intenção em lógica de chamada.

Esse limite preservava decisão local. XML e SIP podiam tornar eventos e parâmetros interoperáveis. A operadora ainda verificava associação com a linha, validade da assinatura, ação disponível e estado atual. Mensagem bem formada não era mandato universal.

Uma especificação inicial pequena permitia que implementações evoluíssem sem fingir que toda consequência já estava decidida. O contrato compartilhado dizia como falar; o sistema local dizia se e como agir.

Segurança acompanhava a disposição

A RFC 3136 via B, em geral sobre a Internet pública, como interface vulnerável a roubo e negação de serviço. C podia ficar na intranet do provedor, mas o Gateway conectado à Internet abria uma fronteira; firewall isolado podia ser insuficiente.

Registro fraudulento poderia desviar caller ID. Alteração poderia trocar caixa postal por encaminhamento. Replay poderia aplicar uma opção antiga à chamada nova. Identidade autêntica poderia já não estar associada à linha.

Autenticação, integridade, frescor, vínculo linha-usuário, autorização da disposição, decisão da SCF, execução do switch e resultado no destino são verificações distintas. O clique prova intenção, não substitui as demais.

O modem passou; a distância de controle ficou

Painéis modernos repetem o padrão ao oferecer failover, revogação, migração ou cancelamento. O botão produz intenção. Gateway autentica. Política decide. Controlador traduz. Dispositivo executa. Outro observador confirma.

A honestidade da RFC 3136 foi manter esses verbos separados. O assinante podia escolher. A rede ainda precisava transformar sua escolha em realidade.