Resumo

  • A RFC 3351 propôs que texto, voz, vídeo, retransmissão e preferências pessoais fizessem parte de uma sessão SIP capaz de mudar sem derrubar a chamada.
  • Era um documento informativo de requisitos, não uma extensão SIP padronizada nem prova de que aparelhos e provedores ofereciam aqueles serviços.

A ideia mais concreta da RFC 3351 é também a mais estrutural: qualquer agente de usuário na conversa, inclusive um serviço de transcodificação, deveria conseguir incluir ou remover um fluxo de mídia sem encerrar e restabelecer a chamada. Uma ligação de voz poderia ganhar texto; uma retransmissão poderia entrar, converter uma mídia e sair. Mudar a forma de conversar não deveria obrigar todo mundo a começar de novo.

Publicada em agosto de 2002, a RFC tratou acessibilidade menos como uma categoria de aparelho e mais como uma questão de como a sessão responde às preferências. Ela descreve o perfil do usuário como capacidades e preferências que o SIP poderia comunicar para orientar o tratamento da sessão. Texto, áudio e vídeo poderiam ser combinados em uma ou duas direções. Um fluxo poderia passar por um serviço de conversão, e um gateway conectaria um agente SIP a um telefone de texto antigo. A sessão era o ponto comum entre escolhas diferentes.

Mas o status da RFC precisa permanecer no primeiro plano. A 3351 é Informational e declara que não define um padrão da Internet. Os termos “MUST” e “SHOULD” registram os requisitos desejados pelos autores; não transformam o texto em uma extensão SIP padronizada. O documento tampouco certifica uma implementação ou mede quantos serviços se tornaram acessíveis. Os diálogos apresentados são cenários de projeto, não um levantamento de implantação.

O perfil também pode ajudar e expor ao mesmo tempo. Preferências podem encaminhar a chamada pela mídia certa, mas revelar informações sobre a pessoa. Por isso, a RFC imaginou que o destinatário não precisasse saber que o interlocutor é surdo apenas porque uma retransmissão participa da conversa. Pediu que os intermediários publicassem suas políticas de confidencialidade e sugeriu permitir que capacidades e preferências não fossem divulgadas em cada transação. A pergunta não é só se o serviço transmite texto, mas o que ele aprende, guarda e revela no caminho.

Preço e escolha aparecem de forma surpreendentemente concreta. O agente de usuário deveria identificar o conteúdo do fluxo, comparar serviços de transcodificação por capacidade e política e encontrar alternativas. A RFC sugere mostrar o preço por minuto e a cobrança mínima antes do início da sessão. Em um exemplo, uma rádio não oferece texto, enquanto o prestador de transcodificação recusa converter o áudio para não esgotar seus recursos. A cadeia tem um limite operacional; a sinalização não garante que o serviço aceite a solicitação.

Os cenários vão além de legendas. Um mantém a conversa por voz enquanto uma retransmissão transforma a fala em texto e lê as respostas digitadas. Outro encadeia fala-para-texto, texto-para-língua de sinais e língua de sinais-para-texto em uma conferência com participantes de preferências diferentes. Um menu telefônico por voz também pode ganhar uma alternativa textual através de um intermediário. São propostas ambiciosas, mas cada conversão acrescenta um fornecedor, uma política, uma possível tarifa e outro ponto por onde passam dados pessoais.

O que veio depois mostra uma sequência de especificações, não um sucesso universal. A RFC 4103 definiu um formato RTP para texto T.140 em tempo real e recomendou redundância para recuperar alguns caracteres perdidos. A RFC 5194 desenvolveu um marco SIP/IP mais detalhado para texto, transcodificação, apresentação e interoperação; ela cita a RFC 3351 sobre a invocação de retransmissões. A RFC 4504 recomendou que telefones SIP atendessem aos requisitos de acessibilidade da 3351. Mais tarde, a RFC 8865 especificou T.140 em canais de dados WebRTC confiáveis e ordenados; a RFC 9071 tratou da mistura de texto RTP em conferências e atualizou a 4103.

Cada texto deixa uma parte do caminho mais precisa, mas nenhum prova que todos os terminais, provedores ou serviços de emergência o ofereçam.

Esse é o legado mais sóbrio. Uma sessão pode ser extensível no papel enquanto o serviço continua indisponível, incompatível, caro ou sujeito à recusa de um fornecedor. Um perfil útil pode divulgar dados sensíveis. Uma retransmissão pode conectar mídias e impor condições. A RFC 3351 trouxe controle, custo e privacidade para o debate sobre como a chamada é projetada: trocar de mídia não deveria exigir uma nova chamada, e a pessoa deveria participar da decisão. Ela não declarou que esse equilíbrio já existia no mundo real.

Fontes: RFC 3351 · Registro da RFC 3351 · Ficha Datatracker da RFC 3351 · RFC 2119 · RFC 8174 · SIP: Session Initiation Protocol, RFC 3261 · Modelo oferta/resposta SDP, RFC 3264 · Texto conversacional em RTP, RFC 4103 · Estrutura para texto em tempo real sobre SIP, RFC 5194 · Requisitos para telefones SIP, RFC 4504 · Texto T.140 em canais WebRTC, RFC 8865 · Mistura RTP de texto em tempo real para conferências, RFC 9071 · Especificação inicial mínima, decisão futura localizada e adoção voluntária · Primazia do código em execução