Resumo

  • A phone-string de RFC 3601 combina DTMF, pausa, tonewait e separadores visuais. A forma local pode incluir saída de PBX, acesso a operadora, senha de serviço e comandos posteriores à conexão.
  • Fonte, classificação, contexto, autorização, ações do dispositivo, sinalização, conexão e resultado precisam de recibos independentes; o sucesso de uma etapa não comprova a seguinte.

O incidente não começa necessariamente no discador. Pode começar quando uma plataforma de observability indexa uma coluna chamada telefone. A string parece rotineira e é copiada inteira. Só depois alguém percebe que os dígitos finais eram um identificador de caixa postal e um PIN, separados do destino por comandos de pausa.

RFC 3601 foi publicado em setembro de 2003 como Standards Track para criar uma notação textual comum de sequências de discagem e endereços GSTN/E.164 discáveis. A definição central não é “número”. Dial Sequence é uma série de elementos DTMF e ações humanas ou de dispositivo. Sua phone-string admite dígitos, #, *, A-D, p para pausa, w para espera de tom, hífen e ponto como separadores escritos.

Cada grupo tem autoridade diferente. Hífen e ponto servem apenas à leitura e não podem causar ação; implementações conformes podem inseri-los ou removê-los. Pausa e tonewait alteram o fluxo. Uma rotina que remove separadores pode preservar sentido. Uma rotina que conserva apenas dígitos pode eliminar controle e produzir outro programa.

Nem o controle tem semântica temporal única. O RFC recomenda uma pausa de um segundo por p e recomenda que w espere tom de discagem ou outra indicação de que mais caracteres podem ser processados. Uma indicação de off-hook também pode valer. Ainda assim, o significado exato fica a cargo do dispositivo. Duas plataformas podem aceitar os mesmos bytes e executar calendários diferentes.

Por isso o parser não é testemunha da execução. Ele comprova gramática, não DTMF emitido, duração de pausa ou áudio que liberou a espera. Um log de tonewait satisfeito comprova a decisão do detector local. Não comprova identidade remota, conexão, resposta nem recepção dos dígitos posteriores.

Há também uma fronteira entre sequência e endereço. gstn-phone pode ser global ou local. O global-phone começa com + e representa endereços numéricos E.164 discáveis. Mas RFC 3601 diz que o endereço E.164 abstrato completo tem elementos que não podem ser discados e não cabe integralmente nessa notação. O sinal de mais reserva um namespace; não transforma toda informação abstrata em comando.

O local-phone expõe o contexto. Pode ter exit-code e dial-number. O exit-code pode incluir a tecla para linha externa, acesso a operadora de longa distância, senha para um serviço e outros elementos. Mover a string sem PBX, local, plano numérico, política de operadora e versão de configuração preserva o texto enquanto altera seu comportamento.

RFC 3966 reforçou a divisão ao tratar a URI tel como identificador, não como passos de discagem. Ela não implica semântica de execução nem alcance universal. Dial strings, pausas e post-dial ficaram fora de seu escopo. Um número local requer phone-context, mas esse contexto delimita validade; não é prefixo que possa ser concatenado para gerar E.164 de forma garantida.

RFC 4967 criou depois user=dialstring em SIP/SIPS. Uma dial string sempre existe num contexto e deve ser distinguível de um user part com os mesmos caracteres. RFC 6116 mantém + no E.164 plenamente qualificado usado por ENUM e proíbe tratar dígitos discados localmente como se já fossem esse identificador. Várias sequências locais podem apontar para o mesmo número global.

Uma migração precisa classificar antes de converter. Identificador, global-phone, local-phone, Dial Sequence, subendereço e post-dial não são intercambiáveis. Se o destino não representa ações, removê-las é uma decisão de produto; escondê-las num identificador é um erro de tipo com consequência operacional.

O post-dial tem uma precondição. RFC 3601 o define para uma sequência usada após estabelecer conexão com o dispositivo de destino, como um menu automatizado. A presença do campo não prova que a conexão existiu. O registro deve ligar primeiro resposta ou estabelecimento, depois os DTMF enviados e, quando disponível, a confirmação do serviço.

A seção de segurança do próprio RFC descreve o risco de códigos privados em strings transmitidas sem proteção. O exemplo de correio de voz combina user ID e PIN. Portanto, classificar o campo como PII comum não basta; ele pode conter uma credencial operacional, além de uma possível identidade.

Esse erro amplia o raio da exposição. CRM, data lake, busca, log, gravação de atendimento e screenshot de suporte replicam tudo. Mas mascarar cegamente todos os dígitos destrói a capacidade de correlacionar um evento. A arquitetura melhor separa endereço público, plano de ações e referência protegida ao segredo. Logs guardam hash, forma e eventos, nunca o código em claro.

A cadeia de evidências começa pela origem: fornecedor, tipo do campo, hash bruto e tempo. Depois vem classificação e versão do parser. O recibo de contexto preserva site, PBX, plano, operadora e configuração. A normalização registra cada alteração. A execução exige autorização. Em seguida, cada DTMF, pausa e liberação de espera produz evento. Rota, conexão, post-dial e resultado de negócio recebem identificadores próprios.

Assim, palavras convenientes deixam de ocultar lacunas. Importado não é classificado. Válido não é autorizado. Discado não é conectado. Atendido não identifica necessariamente o destino pretendido. Dígitos enviados não provam aceitação pelo menu. Um status único não reduz a complexidade; apenas apaga causalidade.