SIP e Voz para Equipas de Mensagens

SIP — Session Initiation Protocol, RFC 3261 — é o protocolo de sinalização da camada de aplicação que cria, modifica e encerra sessões multimédia em tempo real sobre IP , mais comumente voz e vídeo. Fundamentalmente, SIP não transporta o conteúdo multimédia em si: ele negocia e controla a sessão, e o áudio ou vídeo então flui separadamente sobre RTP .

O seu design é deliberadamente semelhante HTTP — mensagens de texto legíveis por humanos, métodos de requisição, códigos de resposta de três dígitos e endereçamento URI (sip:alice@example.com) — o que o torna acessível para equipas já familiarizadas com protocolos da web. É por isso que a voz se encaixa naturalmente ao lado de mensagens numa CPaaS: é outro canal orientado API com um formato familiar de requisição/resposta subjacente.

Os principais atores são os Agentes de Utilizador (um UAC que envia solicitações e um UAS que responde), além da infraestrutura: os registadores armazenam informações sobre onde um utilizador está acessível e os proxies encaminham as solicitações para eles. Para uma equipa de mensagens, a voz geralmente é o canal de fallback OTP e o canal de alerta urgente — portanto, entender SIP significa entender como esse canal realmente se conecta.

SIP define um pequeno conjunto de métodos de requisição. INVITE inicia ou modifica uma sessão, ACK confirma uma resposta final a um INVITE e BYE encerra uma chamada estabelecida. REGISTER informa a um servidor de registo onde um utilizador pode ser contactado, CANCEL cancela uma requisição pendente e OPTIONS consulta as capacidades do servidor. RFCs posteriores adicionaram métodos como INFO, MESSAGE, SUBSCRIBE/NOTIFY e UPDATE.

As respostas espelham o esquema de três dígitos do HTTP em seis classes. 1xx são provisórias (100 Tentando, 180 Ligando); 2xx são bem-sucedidas (200 OK); 3xx são redirecionamentos; 4xx são erros do cliente (404 Não encontrado, 486 Ocupado, 407 Autenticação de proxy necessária); 5xx são erros do servidor; e 6xx são falhas globais (603 Recusado). Ler primeiro a classe e depois o código é a maneira de identificar rapidamente o problema numa chamada com falha.

A peculiaridade clássica a ser internalizada é o handshake de três vias para o estabelecimento da chamada: INVITE , seguido de um 200 OK e, em seguida, um ACK separado — diferentemente da maioria dos protocolos de solicitação/resposta, o ACK para um INVITE é uma transação própria. A gestão incorreta desse ACK é uma das causas mais comuns de chamadas que tocam, mas nunca são completadas.

Como SIP utiliza apenas sinais, os parâmetros reais do conteúdo multimédia são descritos pelo SDP (Session Description Protocol, RFC 4566), presente nos corpos das mensagens SIP . É no SDP que cada lado anuncia os codecs que suporta, o endereço IP e a porta em que receberá o conteúdo multimédia, além de outros atributos do conteúdo multimédia.

SIP utiliza um modelo de oferta/resposta (RFC 3264): o convite INVITE do chamador contém uma oferta SDP listando as suas capacidades, e a resposta do destinatário contém uma resposta SDP selecionando o subconjunto comum. Essa negociação é o que permite que dois pontos de extremidade concordem com um codec e um caminho multimédia antes que qualquer fluxo de áudio seja estabelecido.

O conteúdo multimédia negociado então trafega pelo RTP (Real-time Transport Protocol), que transporta os pacotes de áudio/vídeo com números de sequência e carimbos de data/hora, juntamente com o RTCP para feedback de qualidade. Quando o conteúdo multimédia precisa ser confidencial, SRTP (Secure RTP ) encripta e autentica esses pacotes. O modelo mental a ser lembrado é o seguinte: SIP + SDP estabelecem a chamada, RTP / SRTP a transportam — dois caminhos separados que podem até mesmo seguir rotas diferentes pela rede.

Imagine uma chamada simples. O UAC do chamador envia INVITE (com uma oferta SDP ) para o destinatário, possivelmente através de um ou mais proxies. O lado do destinatário responde com 100 Trying, depois 180 Ringing enquanto o telefone emite um alerta e, finalmente, 200 OK, transmitindo a resposta SDP assim que o destinatário aceita a chamada.

O chamador responde com um ACK e, nesse momento, a sessão é estabelecida: o fluxo multimédia RTP ocorre diretamente entre os pontos de extremidade de acordo com o SDP negociado, independentemente dos proxies que estabeleceram a chamada. Alterações durante a chamada — como colocar uma chamada em espera, adicionar vídeo ou trocar codecs — utilizam um re- INVITE ou UPDATE com um novo SDP .

Qualquer uma das partes encerra a chamada enviando BYE , respondido com 200 OK, o que finaliza a sessão e interrompe a transmissão multimédia. Falhas interrompem o fluxo: um erro 486 Busy Here ou 408 Request Timeout em vez de 200 OK significa que a chamada nunca chega ao estágio ACK. A visualização de toda essa sequência é o que torna os logs SIP legíveis quando uma chamada apresenta comportamento inadequado.

Um tronco SIP é uma conexão baseada em SIP entre um sistema telefónico privado (PBX) ou uma aplicação e uma operadora, substituindo os troncos físicos legados e transportando chamadas de e para a rede pública via IP . É assim que a voz programática chega à PSTN em grande escala.

Na fronteira da rede encontra-se o Session Border Controller ( SBC ) — o elemento que protege e controla SIP na borda da rede. Ele realiza ocultação de topologia, transposição de NAT, interoperabilidade e normalização de protocolos entre diferentes dialetos SIP , controlo de admissão e limitação de taxa, e frequentemente ancoragem e transcodificação multimédia. O SBC é para o SIP aproximadamente o que o firewall de sinalização é para o SS7 / Diameter : o ponto de verificação controlado no limite de confiança.

VoLTE (Voice over LTE ) é a transmissão de voz como um serviço IMS sobre a rede de dados LTE , e o seu controlo de chamadas é feito por meio SIP executado dentro IMS — o mesmo protocolo que você acabou de aprender, enquadrado pelas interfaces Cx / HSS e de políticas do núcleo da rede móvel. Portanto, o SIP que uma equipa de mensagens usa para voz programável e o SIP que controla uma chamada VoLTE são o mesmo protocolo, diferindo na rede circundante, e não na sinalização em si.