O que é SIP?

Sistemas telefônicos de diferentes fabricantes precisam de uma forma comum de concordar sobre uma chamada.

SIP não transporta mídia, e esse limite explica por que uma chamada conectada pode não ter áudio.

O que SIP realmente faz?

Faz duas partes concordarem que uma sessão deve acontecer e em quais termos.

A RFC 3261, a especificação de junho de 2002 que o define, descreve SIP como "an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants". As cinco tarefas são localizar a outra ponta, decidir se ela vai aceitar a chamada, negociar a mídia, tocar e, depois, desligar ou transferir. A especificação as lista como:

User location: determination of the end system to be used for
     communication;

User availability: determination of the willingness of the called
     party to engage in communications;

User capabilities: determination of the media and media parameters
     to be used;

Session setup: "ringing", establishment of session parameters at
     both called and calling party;

Session management: including transfer and termination of
     sessions, modifying session parameters, and invoking
     services.

Nenhuma das cinco é transportar o áudio. Esse é todo o escopo.

Por que minha chamada conectou sem áudio?

Porque o áudio nunca foi responsabilidade de SIP, e os dois caminhos podem falhar de forma independente.

A especificação é explícita sobre seu próprio escopo:

SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture.

A mídia trafega por RTP, negociado durante o estabelecimento e depois fluindo por conta própria, frequentemente entre endpoints que a sinalização nunca tocou. A sinalização pode ser concluída e ambos os lados podem concordar que uma sessão está ativa. Mesmo assim, o áudio pode não chegar porque um firewall, um tradutor de endereços de rede ou uma regra de roteamento entre os endpoints de mídia o descartou, sem afetar a sinalização.

É por isso que áudio unidirecional e ausência de áudio são uma categoria diagnóstica própria, e não uma variação de falha de chamada. O log de chamadas mostrará uma chamada conectada, porque uma chamada conectada é exatamente o que a sinalização alcançou. Solução de problemas de voz percorre os sintomas. A ferramenta de chamada de teste do Bird exibe um resumo de pico de áudio para cada direção, em que um zero em um dos lados é o sintoma de áudio unidirecional expresso como número.

Essa mesma separação é o que permite que outros recursos se encaixem naturalmente. A RFC 3261 coloca da seguinte forma: "SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services." Correio de voz, grupos de busca, gravação de chamadas e um agente de IA são todos construídos sobre os primitivos, e não definidos pelo protocolo.

Preciso registrar um cliente antes que ele possa chamar?

Não. Trunks Bird autenticam chamadas sem registro de cliente.

SIP define uma função de registro, que é como um user agent informa à rede onde pode ser encontrado no momento. É o que torna um telefone de mesa localizável quando alguém disca um ramal. Mas registrar e fazer uma chamada são atos separados, e um sistema que apenas origina chamadas nunca precisa ser localizável.

Um SIP INVITE é o método que solicita uma chamada. Bird autentica cada um contra a lista de IPs permitidos do trunk ou por meio de um desafio de senha. Os clientes não se registram no trunk. Configure Bird como trunk, e não como conta registrada: sem seção type=registration no Asterisk, register=false em um gateway FreeSWITCH, registration definido como none no FreePBX ou 3CX. Quando um softphone não oferece como desativar o registro, a tentativa de registro que falha é cosmética e a discagem continua funcionando, porque a plataforma age com base no convite, não no registro. Configuração de cliente SIP contém as configurações detalhadas.

O corolário é onde vão as credenciais. Seu cliente envia duas identidades diferentes. O caller ID vai no cabeçalho From e precisa ser um número que você verificou. O nome de usuário do digest é bird em todos os trunks. Colocar o caller ID no campo de autenticação causa um erro de autenticação, e não um erro que mencione caller ID.

Por que as respostas se parecem com HTTP?

Porque o protocolo foi projetado assim, até nas faixas numéricas.

SIP é um protocolo de solicitação e resposta baseado em texto, com métodos e cabeçalhos. Suas respostas vêm nas mesmas seis classes com os mesmos números familiares: um 404 para um destino que não existe e um 486 para um sistema final ocupado. A estrutura compartilhada permite ler um trace SIP quase como você leria um trace HTTP.

Há duas exceções. Uma sexta classe, 6xx, não tem equivalente em HTTP e significa que nenhum servidor em lugar algum consegue atender à solicitação, não apenas este. Um código comum também carrega um significado em Bird que o padrão não descreve. O que significam os códigos de resposta SIP cobre ambos, incluindo por que um 503 de Bird geralmente é uma recusa que ele não explica na rede, e não uma sobrecarga.

Onde encontro SIP no Bird?

No trunk, que é o endereço para o qual seu equipamento envia.

Cada trunk tem um domínio SIP fixo e aceita UDP ou TCP na porta 5060, ou TLS na porta 5061 quando você quer a sinalização criptografada em trânsito. O que pode enviar para ele é decisão sua, e um trunk novo não aceita nada até que você o autorize. O que é um trunk SIP cobre essa decisão e os três mecanismos por trás dela. O que é um API de voz cobre como a metade SIP e a metade HTTP dividem o trabalho.