Resumo

  • Em fork paralelo, vários UAS podem autoatender e devolver 200 antes que o primeiro diálogo seja mantido e os demais recebam BYE. Uma ramificação descartada ainda pode ter reproduzido mídia.
  • Answer-Mode: Auto e Priv-Answer-Mode: Auto são pedidos submetidos à política local. require define rejeição ou suporte da extensão, não autoridade remota sobre o aparelho.
  • O terminal não pode passar de mídia apenas recebida para mídia enviada ou bidirecional sem aceitação explícita do usuário, mesmo que a sessão tenha começado por autoatendimento válido.

O resumo de um diálogo escondia várias ações

Um endereço SIP pode resolver para telefone de mesa, aplicativo móvel e outro contato. Com atendimento manual, usuários diferentes raramente apertam aceitar ao mesmo tempo. Com Auto, cada UAS pode responder imediatamente. A mecânica padrão conserva o primeiro diálogo e envia BYE aos demais.

O estado final parece limpo: um diálogo ativo. O caminho até ele pode ter aberto dois alto-falantes. O BYE posterior não desfaz áudio já tocado, custo já incorrido ou informação já exposta. Por isso RFC 5373 não recomenda auto-answer em ambientes com fork paralelo.

O registro precisa manter todas as branches, não apenas a vencedora: contact escolhido, 200 de cada UAS, início de mídia, duração até BYE e política aplicada em cada dispositivo. Anunciar answermode no REGISTER ajuda a encontrar contatos compatíveis, mas não prova unicidade nem autorização para uma chamada concreta.

Auto não era um comando enviado pelo chamador

O campo comum pede que o UAS aceite sem esperar interação. O UAS ainda pode impor preferências locais, usar atendimento manual ou rejeitar. Uma identidade autenticada é entrada para a política; não é a decisão completa.

Com Auto;require, o UAS não pode substituir manual. Se a política não permite Auto, rejeita. A palavra preserva a diferença entre resultado aceitável e fallback, sem deslocar a autoridade para o UAC.

Require: answermode trata de compreensão da extensão. Um terminal compatível pode perfeitamente recusar o comportamento solicitado. Accept-Contact filtra ou prioriza destinos que declararam suporte; capacidade não equivale a execução.

Priv pedia uma autorização mais rara

Priv-Answer-Mode é comparado pela RFC a sudo. O chamador pede que a regra privilegiada seja consultada, mas o texto não carrega o privilégio. A política deveria ser mais rigorosa e negar por padrão quando o solicitante não estiver autenticado e especificamente autorizado.

A mesma pessoa pode preferir uma chamada comum agora e uma interrupção urgente depois. Elevar todo tráfego por identidade elimina essa escolha. Se ambos os campos aparecem, o UAS testa primeiro o privilegiado e, se ele falhar, processa o comum. O caminho efetivo deve ficar no recibo.

As referências de identidade de 2008 são contexto histórico. RFC 4474 foi substituída por RFC 8224; a obrigação permanente é usar identidade adequada e autorização explícita, não presumir uma implantação atual.

O alto-falante e o microfone não compartilhavam autorização

Mídia de entrada pode incomodar, enganar, cobrar dados ou gastar bateria. Mídia de saída pode transformar o aparelho em ponto de escuta. A política mínima separa essas direções.

Sem aceitação explícita do usuário, o UAS não deve originar mídia de saída ou bidirecional. O loopback de diagnóstico é exceção porque devolve o sinal de teste, não o ambiente. Para entrada, desconhecidos ou identidades sem permissão não deveriam obter reprodução automática.

Uma sessão pode começar em recepção e depois receber re-INVITE ou UPDATE para sendrecv. Os campos de answering mode não valem no meio do diálogo, mas o controle deve acompanhar o estado e bloquear a transição até nova aceitação.

O 200 podia omitir como a resposta ocorreu

O UAS pode dizer no 200 se respondeu Manual ou Auto. Essa informação ajuda quem fala em push-to-talk, mas Manual pode revelar presença humana. A recomendação é configurar a divulgação e omiti-la por padrão.

Ausência significa não divulgado. Não deve ser preenchida como Auto, Manual ou sem suporte. E presença do campo continua limitada: Auto é ausência da interação definida, não ausência de pessoa; Manual é uma interação, não prova de identidade, audição ou compreensão.

Um proxy só alterava sob acordo

Proxies intermediários normalmente ignoram os campos. Um proxy de serviço pode inserir, remover ou mudar Answer-Mode apenas quando existe acordo externo explícito com o usuário atendido. Essa delegação precisa aparecer na proveniência.

Guardar somente o INVITE final confunde intenção do chamador com política intermediária. O conjunto deve unir original, transformações, proxy, acordo, versão de regra e bytes avaliados no destino.

Limite de evidência

O dossiê liga identidade, autenticação, pedido comum ou privilegiado, ambos os require, seleção e forks, decisão de política, resposta e divulgação, direção SDP em cada versão, aceitação humana e pacotes efetivamente enviados. Ouvir, entender e agir continuam fora do 200.

Assim a organização sabe quais aparelhos atuaram antes de o primeiro diálogo vencer. A topologia deixa de ser apagada pelo estado final.