SIP - Guia Rápido

Session Initiation Protocol (SIP) é um dos protocolos mais comuns usados na tecnologia VoIP. É um protocolo de camada de aplicativo que funciona em conjunto com outros protocolos de camada de aplicativo para controlar as sessões de comunicação multimídia pela Internet.

Tecnologia VoIP

Antes de prosseguir, vamos primeiro entender alguns pontos sobre VoIP.

VOIP é uma tecnologia que permite fornecer conteúdo de voz e multimídia (vídeos, fotos) pela Internet. É uma das formas mais econômicas de se comunicar a qualquer hora e em qualquer lugar com a disponibilidade da Internet.
Algumas vantagens do VOIP incluem -
- Baixo custo
- Portability
- Sem cabos extras
- Flexibility
- Vídeo conferência
Para uma chamada VOIP, tudo o que você precisa é um computador / laptop / celular com conexão à Internet. A figura a seguir descreve como ocorre uma chamada VoIP.

Com tudo isso fundamental, vamos voltar ao SIP.

SIP - Visão geral

Abaixo estão alguns pontos a serem observados sobre o SIP -

SIP é um protocolo de sinalização usado para criar, modificar e encerrar uma sessão multimídia no protocolo da Internet. Uma sessão nada mais é do que uma simples chamada entre dois terminais. Um endpoint pode ser um smartphone, um laptop ou qualquer dispositivo que possa receber e enviar conteúdo multimídia pela Internet.
SIP é um protocolo de camada de aplicação definido pelo padrão IETF (Internet Engineering Task Force). É definido emRFC 3261.
SIP incorpora arquitetura cliente-servidor e o uso de URL e URI de HTTP e um esquema de codificação de texto e um estilo de cabeçalho de SMTP.
O SIP tem a ajuda do SDP (Session Description Protocol), que descreve uma sessão e do RTP (Real Time Transport Protocol) usado para fornecer voz e vídeo pela rede IP.
O SIP pode ser usado para sessões de duas partes (unicast) ou multipartidárias (multicast).
Outros aplicativos SIP incluem transferência de arquivos, mensagens instantâneas, videoconferência, jogos online e distribuição de multimídia veloz.

Onde o SIP se encaixa?

Basicamente, o SIP é um protocolo da camada de aplicativo. É um protocolo de sinalização de rede simples para criar e encerrar sessões com um ou mais participantes. O protocolo SIP é projetado para ser independente do protocolo de transporte subjacente, de modo que os aplicativos SIP podem ser executados em TCP, UDP ou outros protocolos de rede de camada inferior.

A ilustração a seguir mostra onde o SIP se encaixa no esquema geral das coisas -

Normalmente, o protocolo SIP é usado para telefonia pela Internet e distribuição de multimídia entre dois ou mais terminais. Por exemplo, uma pessoa pode iniciar uma chamada telefônica para outra usando SIP ou alguém pode criar uma chamada em conferência com vários participantes.

O protocolo SIP foi projetado para ser muito simples, com um conjunto limitado de comandos. Também é baseado em texto, de modo que qualquer pessoa pode ler uma mensagem SIP passada entre os terminais em uma sessão SIP.

Existem algumas entidades que ajudam o SIP na criação de sua rede. No SIP, cada elemento de rede é identificado por umSIP URI(Uniform Resource Identifier), que é como um endereço. A seguir estão os elementos de rede -

Agente de usuário
Servidor proxy
Servidor de registro
Servidor de redirecionamento
Servidor de localização

Agente de usuário

É o terminal e um dos elementos de rede mais importantes de uma rede SIP. Um terminal pode iniciar, modificar ou encerrar uma sessão. Os agentes do usuário são o dispositivo ou elemento de rede mais inteligente de uma rede SIP. Pode ser um softphone, um celular ou um laptop.

Os agentes de usuário são logicamente divididos em duas partes -

User Agent Client (UAC) - A entidade que envia uma solicitação e recebe uma resposta.
User Agent Server (UAS) - A entidade que recebe uma solicitação e envia uma resposta.

O SIP é baseado na arquitetura cliente-servidor em que o telefone do chamador atua como um cliente que inicia uma chamada e o telefone do receptor atua como um servidor que responde à chamada.

Servidor proxy

É o elemento de rede que recebe uma solicitação de um agente do usuário e a encaminha para outro usuário.

Basicamente, a função de um servidor proxy é muito parecida com a de um roteador.
Ele tem alguma inteligência para entender uma solicitação SIP e enviá-la adiante com a ajuda do URI.
Um servidor proxy fica entre dois agentes de usuário.
Pode haver no máximo 70 servidores proxy entre uma origem e um destino.

Existem dois tipos de servidores proxy -

Stateless Proxy Server- Simplesmente encaminha a mensagem recebida. Este tipo de servidor não armazena nenhuma informação de uma chamada ou transação.
Stateful Proxy Server- Este tipo de servidor proxy rastreia todas as solicitações e respostas recebidas e pode usá-lo no futuro, se necessário. Ele pode retransmitir a solicitação, se não houver resposta do outro lado a tempo.

Servidor de registro

O servidor de registro aceita solicitações de registro de agentes de usuário. Ajuda os usuários a se autenticarem na rede. Ele armazena o URI e a localização dos usuários em um banco de dados para ajudar outros servidores SIP dentro do mesmo domínio.

Dê uma olhada no exemplo a seguir que mostra o processo de um registro SIP.

Aqui, o chamador deseja registrar-se no domínio TMC. Então, ele envia uma solicitação REGISTER para o servidor Registrar do TMC e o servidor retorna uma resposta 200 OK ao autorizar o cliente.

Servidor de redirecionamento

O servidor de redirecionamento recebe solicitações e procura o destinatário pretendido da solicitação no banco de dados de localização criado pelo registrador.

O servidor de redirecionamento usa o banco de dados para obter informações de localização e responde com 3xx (resposta de redirecionamento) ao usuário. Discutiremos os códigos de resposta posteriormente neste tutorial.

Servidor de localização

O servidor de localização fornece informações sobre as localizações possíveis de um chamador para os servidores de redirecionamento e proxy.

Apenas um servidor proxy ou servidor de redirecionamento pode contatar um servidor de localização.

A figura a seguir descreve as funções desempenhadas por cada um dos elementos da rede no estabelecimento de uma sessão.

SIP - Arquitetura do Sistema

O SIP é estruturado como um protocolo em camadas, o que significa que seu comportamento é descrito em termos de um conjunto de estágios de processamento bastante independentes, com apenas um acoplamento fraco entre cada estágio.

A camada mais baixa do SIP é o seu syntax and encoding. Sua codificação é especificada usando um aumentoBackus-Naur Form grammar (BNF).
No segundo nível está o transport layer. Ele define como um cliente envia solicitações e recebe respostas e como um servidor recebe solicitações e envia respostas pela rede. Todos os elementos SIP contêm uma camada de transporte.
Em seguida vem o transaction layer. Uma transação é uma solicitação enviada por uma transação do Cliente (usando a camada de transporte) para uma transação do Servidor, junto com todas as respostas a essa solicitação enviada da transação do servidor de volta ao cliente. Qualquer tarefa que um cliente do agente do usuário (UAC) realiza ocorre usando uma série de transações.Stateless proxies não contém uma camada de transação.
A camada acima do transaction layeré chamado de usuário de transação. Cada uma das entidades SIP, exceto oStateless proxies, é um usuário de transação.

A imagem a seguir mostra o fluxo básico de chamadas de uma sessão SIP.

Dada a seguir é uma explicação passo a passo do fluxo de chamada acima -

Uma solicitação INVITE enviada a um servidor proxy é responsável por iniciar uma sessão.
O servidor proxy sendsa 100 Trying responder imediatamente ao chamador (Alice) para interromper as retransmissões da solicitação INVITE.
O servidor proxy procura o endereço de Bob no servidor de localização. Após obter o endereço, ele encaminha a solicitação INVITE posteriormente.
Depois disso, 180 Ringing (Respostas provisórias) gerado por Bob é devolvido a Alice.
UMA 200 OK a resposta é gerada logo após Bob atender o telefone.
Bob recebe um ACK da Alice, assim que conseguir 200 OK.
Ao mesmo tempo, a sessão é estabelecida e os pacotes RTP (conversas) começam a fluir de ambas as extremidades.
Após a conversa, qualquer participante (Alice ou Bob) pode enviar um BYE pedido para encerrar a sessão.
BYE alcança diretamente de Alice para Bob, ignorando o servidor proxy.
Finalmente, Bob envia um 200 OK resposta para confirmar o BYE e a sessão é encerrada.
No fluxo básico de chamadas acima, três transactions estão (marcados como 1, 2, 3) disponíveis.

A chamada completa (de INVITE a 200 OK) é conhecida como Dialog.

Trapézio SIP

Como um proxy ajuda a conectar um usuário a outro? Vamos descobrir com a ajuda do diagrama a seguir.

A topologia mostrada no diagrama é conhecida como trapézio SIP. O processo ocorre da seguinte forma -

Quando um chamador inicia uma chamada, uma mensagem INVITE é enviada ao servidor proxy. Ao receber o CONVIDADO, o servidor proxy tenta resolver o endereço do receptor com a ajuda do servidor DNS.
Após obter a próxima rota, o servidor proxy do chamador (Proxy 1, também conhecido como servidor proxy de saída) encaminha a solicitação INVITE para o servidor proxy do receptor, que atua como um servidor proxy de entrada (Proxy 2) para o receptor.
O servidor proxy de entrada contata o servidor de localização para obter informações sobre o endereço do receptor onde o usuário se registrou.
Após obter as informações do servidor de localização, ele encaminha a chamada ao seu destino.
Uma vez que os agentes do usuário conheçam seu endereço, eles podem ignorar a chamada, ou seja, as conversas passam diretamente.

As mensagens SIP são de dois tipos - requests e responses.

A linha de abertura de uma solicitação contém um método que define a solicitação e um Request-URI que define para onde a solicitação deve ser enviada.
Da mesma forma, a linha de abertura de uma resposta contém um código de resposta.

Métodos de Solicitação

SIP requestssão os códigos usados para estabelecer uma comunicação. Para complementá-los, existemSIP responses que geralmente indicam se uma solicitação foi bem-sucedida ou falhou.

Essas solicitações SIP, conhecidas como MÉTODOS, tornam a mensagem SIP viável.

MÉTODOS podem ser considerados como solicitações SIP, uma vez que solicitam uma ação específica a ser realizada por outro agente de usuário ou servidor.
MÉTODOS são distinguidos em dois tipos -
- Métodos Básicos
- Métodos de Extensão

Métodos Básicos

Existem seis métodos principais, conforme discutido abaixo.

CONVITE

INVITE é usado para iniciar uma sessão com um agente do usuário. Em outras palavras, um método INVITE é usado para estabelecer uma sessão de mídia entre os agentes do usuário.

INVITE pode conter as informações de mídia do chamador no corpo da mensagem.
Uma sessão é considerada estabelecida se um INVITE recebeu uma resposta de sucesso (2xx) ou um ACK foi enviado.

Uma solicitação INVITE bem-sucedida estabelece um dialog entre os dois agentes do usuário, que continua até que um BYE seja enviado para encerrar a sessão.
Um CONVITE enviado em um diálogo estabelecido é conhecido como um re-INVITE.
Re-CONVIDAR é usado para alterar as características da sessão ou atualizar o estado de um diálogo.

INVITE Exemplo

O código a seguir mostra como INVITE é usado.

INVITE sips:[email protected] SIP/2.0 
   Via: SIP/2.0/TLS client.ANC.com:5061;branch = z9hG4bK74bf9 
   Max-Forwards: 70 
   From: Alice<sips:[email protected]>;tag = 1234567 
   To: Bob<sips:[email protected]>
   Call-ID: [email protected]  
   CSeq: 1 INVITE 
   Contact: <sips:[email protected]> 
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
   Supported: replaces 
   Content-Type: application/sdp 
   Content-Length: ...  

   v = 0 
   o = Alice 2890844526 2890844526 IN IP4 client.ANC.com 
   s = Session SDP 
   c = IN IP4 client.ANC.com 
   t = 3034423619 0 
   m = audio 49170 RTP/AVP 0 
   a = rtpmap:0 PCMU/8000

TCHAU

BYE é o método usado para encerrar uma sessão estabelecida. Esta é uma solicitação SIP que pode ser enviada pelo chamador ou pelo receptor para encerrar uma sessão.

Não pode ser enviado por um servidor proxy.
A solicitação BYE normalmente roteia de ponta a ponta, ignorando o servidor proxy.
BYE não pode ser enviado para um INVITE pendente ou uma sessão não estabelecida.

REGISTRO

A solicitação REGISTER realiza o registro de um agente do usuário. Essa solicitação é enviada por um agente do usuário a um servidor de registro.

O pedido de REGISTER pode ser encaminhado ou procurado até chegar a um registrador autorizado do domínio especificado.
Carrega o AOR (Endereço de Registro) no To cabeçalho do usuário que está sendo registrado.
A solicitação REGISTER contém o período de tempo (3600seg).
Um agente de usuário pode enviar uma solicitação REGISTER em nome de outro agente de usuário. Isso é conhecido comothird-party registration. Aqui oFrom tag contém o URI da parte que envia o registro em nome da parte identificada no To cabeçalho.

CANCELAR

CANCELAR é usado para encerrar uma sessão que não foi estabelecida. Os agentes do usuário usam essa solicitação para cancelar uma tentativa de chamada pendente iniciada anteriormente.

Ele pode ser enviado por um agente de usuário ou um servidor proxy.
CANCELAR é um hop by hop solicitação, ou seja, ela passa pelos elementos entre o agente do usuário e recebe a resposta gerada pelo próximo elemento com estado.

ACK

ACK é usado para reconhecer as respostas finais a um método INVITE. Um ACK sempre vai na direção de INVITE.ACK pode conter um corpo SDP (características de mídia), se não estiver disponível em INVITE.

ACK não pode ser usado para modificar a descrição da mídia que já foi enviada no INVITE inicial.

Um proxy com estado que recebe um ACK deve determinar se o ACK deve ou não ser encaminhado para outro proxy ou agente de usuário.
Para respostas 2xx, ACK é de ponta a ponta, mas para todas as outras respostas finais, ele funciona salto a salto quando proxies com estado estão envolvidos.

OPÇÕES

O método OPTIONS é usado para consultar um agente de usuário ou um servidor proxy sobre seus recursos e descobrir sua disponibilidade atual. A resposta a uma solicitação lista os recursos do agente do usuário ou servidor. Um proxy nunca gera uma solicitação OPTIONS.

Métodos de Extensão

Se inscrever

SUBSCRIBE é usado por agentes do usuário para estabelecer uma assinatura com o objetivo de obter notificação sobre um determinado evento.

Contém um Expires campo de cabeçalho que indica a duração de uma assinatura.
Depois que o período de tempo passar, a assinatura será encerrada automaticamente.
A assinatura estabelece um diálogo entre os agentes do usuário.
Você pode se inscrever novamente enviando outro ASSINAR dentro da caixa de diálogo antes do tempo de expiração.
Um 200 OK será recebido para uma assinatura do usuário.
Os usuários podem cancelar a assinatura enviando outro método SUBSCRIBE com valor de expiração 0 (zero).

NOTIFICAR

NOTIFY é usado por agentes de usuário para obter a ocorrência de um evento específico. Normalmente, um NOTIFY será acionado em uma caixa de diálogo quando houver uma assinatura entre o assinante e o notificador.

Cada NOTIFY obterá uma resposta 200 OK se for recebida pelo notificador.
NOTIFY contém um Event campo de cabeçalho indicando o evento e um subscriptionstate campo de cabeçalho indicando o estado atual da assinatura.
Uma NOTIFICAÇÃO é sempre enviada no início e no término de uma assinatura.

PUBLICAR

PUBLISH é usado por um agente de usuário para enviar informações de estado do evento a um servidor.

PUBLICAR é útil principalmente quando há várias fontes de informações de eventos.
Uma solicitação PUBLISH é semelhante a uma NOTIFY, exceto que ela não é enviada em um diálogo.
Uma solicitação PUBLICAR deve conter um Expires campo de cabeçalho e um Min-Expires campo de cabeçalho.

REFERIR

REFER é usado por um agente de usuário para referir outro agente de usuário para acessar um URI para o diálogo.

REFER deve conter um Refer-Tocabeçalho. Este é um cabeçalho obrigatório para REFER.
REFER pode ser enviado dentro ou fora de um diálogo.
UMA 202 Accepted irá acionar uma solicitação REFER que indica que outro agente do usuário aceitou a referência.

INFO

INFO é usado por um agente de usuário para enviar informações de sinalização de chamada a outro agente de usuário com o qual ele estabeleceu uma sessão de mídia.

Esta é uma solicitação ponta a ponta.
Um proxy sempre encaminhará uma solicitação de INFO.

ATUALIZAR

UPDATE é usado para modificar o estado de uma sessão se uma sessão não for estabelecida. O usuário pode alterar o codec com UPDATE.

SE uma sessão for estabelecida, um novo convite é usado para alterar / atualizar a sessão.

PRACK

PRACK é usado para acusar o recebimento de uma transferência confiável de resposta provisória (1XX).

Geralmente PRACK é gerado por um cliente quando recebe uma resposta provisória contendo um RSeq número de sequência confiável e um supported:100rel cabeçalho.
PRACK contém valor (RSeq + CSeq) no rack cabeçalho.
O método PRACK se aplica a todas as respostas provisórias, exceto a resposta 100 Trying, que nunca é transportada de forma confiável.
Um PRACK pode conter um corpo de mensagem; pode ser usado para troca de oferta / resposta.

MENSAGEM

Ele é usado para enviar uma mensagem instantânea usando SIP. Uma MI geralmente consiste em mensagens curtas trocadas em tempo real por participantes em conversas de texto.

A MENSAGEM pode ser enviada dentro de um diálogo ou fora de um diálogo.
O conteúdo de uma MENSAGEM é transportado no corpo da mensagem como um MIME anexo.
UMA 200 OK a resposta é normalmente recebida para indicar que a mensagem foi entregue em seu destino.

Uma resposta SIP é uma mensagem gerada por um servidor de agente de usuário (UAS) ou servidor SIP para responder a uma solicitação gerada por um cliente. Pode ser uma confirmação formal para evitar a retransmissão de solicitações por um UAC.

Uma resposta pode conter alguns campos de cabeçalho adicionais de informações necessárias para um UAC.
O SIP tem seis respostas.
1xx a 5xx foi emprestado do HTTP e 6xx foi introduzido no SIP.
1xx é considerado um provisional resposta e o resto são final respostas.

S.No.	Descrição da função
1	1xx: Respostas provisórias / informativas Respostas informativas são usadas para indicar call progress. Normalmente as respostas são de ponta a ponta (exceto 100 tentativas).
2	2xx: Respostas de sucesso Esta classe de respostas serve para indicar que uma solicitação foi aceita.
3	3xx: Redirecionar respostas Geralmente, essas respostas de classe são enviadas por servidores de redirecionamento em resposta a INVITE. Eles também são conhecidos como respostas de classe de redirecionamento.
4	4xx: Respostas de falha do cliente As respostas de erro do cliente indicam que a solicitação não pode ser atendida, pois alguns erros são identificados do lado do UAC.
5	5xx: Resposta de falha do servidor Esta resposta de classe é usada para indicar que a solicitação não pode ser processada devido a um erro com o servidor.
6	6xx: Resposta de falha global Essa classe de resposta indica que o servidor sabe que a solicitação falhará sempre que for tentada. Como resultado, a solicitação não deve ser enviada para outros locais.

Um cabeçalho é um componente de uma mensagem SIP que transmite informações sobre a mensagem. Está estruturado como uma sequência de campos de cabeçalho.

Na maioria dos casos, os campos de cabeçalho SIP seguem as mesmas regras dos campos de cabeçalho HTTP. Os campos de cabeçalho são definidos comoHeader: field, em que Cabeçalho é usado para representar o nome do campo do cabeçalho e campo é o conjunto de tokens que contém as informações. Cada campo consiste em um nome de campo seguido por dois pontos (":") e o valor do campo (ou seja,field-name: field-value)

Cabeçalhos SIP - Formulário Compacto

Muitos campos de cabeçalho SIP comuns têm um formato compacto em que o nome do campo de cabeçalho é indicado por um único caractere minúsculo. Alguns exemplos são fornecidos abaixo -

Cabeçalho	Forma Compacta
Para	T
Através da	V
Call-ID	Eu
Contato	M
De	F
Sujeito	S
Comprimento do conteúdo	Eu

Formato de cabeçalho SIP

A imagem a seguir mostra a estrutura de um cabeçalho SIP típico.

Os cabeçalhos são categorizados da seguinte forma, dependendo de seu uso no SIP -

Solicitação e Resposta
Solicitar apenas
Apenas Resposta
Corpo da mensagem

SDP significa Protocolo de Descrição de Sessão. É usado para descrever sessões de multimídia em um formato compreendido pelos participantes em uma rede. Dependendo desta descrição, uma parte decide se deseja ingressar em uma conferência ou quando ou como ingressar em uma conferência.

O proprietário de uma conferência a anuncia na rede enviando mensagens multicast que contêm a descrição da sessão, por exemplo, o nome do proprietário, o nome da sessão, a codificação, o tempo etc. Dependendo dessas informações, os destinatários do anúncio tomar uma decisão sobre a participação na sessão.
O SDP geralmente está contido na parte do corpo do Protocolo de Iniciação de Sessão, popularmente chamado de SIP.
O SDP é definido no RFC 2327. Uma mensagem SDP é composta de uma série de linhas, chamadas campos, cujos nomes são abreviados por uma única letra minúscula e estão em uma ordem necessária para simplificar a análise.

Objetivo do SDP

O objetivo do SDP é transmitir informações sobre fluxos de mídia em sessões multimídia para ajudar os participantes a ingressar ou coletar informações de uma sessão específica.

SDP é uma breve descrição textual estruturada.
Ele transmite o nome e a finalidade da sessão, a mídia, os protocolos, os formatos de codec, o tempo e as informações de transporte.
Um participante provisório verifica essas informações e decide se deseja entrar em uma sessão e como e quando entrar em uma sessão, se decidir fazê-lo.
O formato tem entradas na forma de <tipo> = <valor>, onde o <tipo> define um parâmetro de sessão exclusivo e o <valor> fornece um valor específico para esse parâmetro.
A forma geral de uma mensagem SDP é -

x = parameter1 parameter2 ... parameterN
A linha começa com uma única letra minúscula, por exemplo, x. Nunca há espaços entre a letra e =, e há exatamente um espaço entre cada parâmetro. Cada campo possui um número definido de parâmetros.

Parâmetros de descrição da sessão

Descrição da sessão (* denota opcional)

v = (versão do protocolo)
o = (proprietário / criador e identificador de sessão)
s = (nome da sessão)
i = * (informações da sessão)
u = * (URI da descrição)
e = * (endereço de email)
p = * (número de telefone)
c = * (informações de conexão - não necessárias se incluídas em todas as mídias)
b = * (informações de largura de banda)
z = * (ajustes de fuso horário)
k = * (chave de criptografia)
a = * (zero ou mais linhas de atributo de sessão)

Versão do protocolo

O campo v = contém o número da versão SDP. Como a versão atual do SDP é 0, uma mensagem SDP válida sempre começará com v = 0.

Origem

O campo o = contém informações sobre o originador da sessão e identificadores de sessão. Este campo é usado para identificar exclusivamente a sessão.

O campo contém -

o = <nome de usuário> <id da sessão> <versão> <tipo de rede> <tipo de endereço>
o username parâmetro contém o login ou host do originador.
o session-id parâmetro é um registro de data e hora do Network Time Protocol (NTP) ou um número aleatório usado para garantir a exclusividade.
o version é um campo numérico que é aumentado para cada alteração na sessão, também recomendado como um carimbo de data / hora NTP.
o network-typeestá sempre IN para Internet. O parâmetro de tipo de endereço é IP4 ou IP6 para endereços IPv4 ou IPv6 em formato decimal pontuado ou um nome de host totalmente qualificado.

Nome da sessão e informações

O campo s = contém um nome para a sessão. Ele pode conter qualquer número diferente de zero de caracteres. O campo opcional i = contém informações sobre a sessão. Ele pode conter qualquer número de caracteres.

URI

O campo opcional u = contém um indicador uniforme de recursos (URI) com mais informações sobre a sessão

Endereço de e-mail e número de telefone

O campo opcional e = contém um endereço de e-mail do host da sessão. O campo opcional p = contém um número de telefone.

Dados de conexão

O campo c = contém informações sobre a conexão de mídia.

O campo contém -

c = <network-type> <address-type> <connection-address>
o network-type parâmetro é definido como IN para a Internet.
o address-type é definido como IP4 para endereços IPv4 e IP6 para endereços IPv6.
o connection-address é o endereço IP ou host que enviará os pacotes de mídia, que podem ser multicast ou unicast.
Se multicast, o campo de endereço de conexão contém -

endereço de conexão = endereço de multicast de base / ttl / número de endereços

Onde ttl é o valor de tempo de vida e o número de endereços indica quantos endereços multicast contíguos estão incluídos, começando com o endereço multicast base.

Largura de banda

O campo opcional b = contém informações sobre a largura de banda necessária. É da forma -

b = modificador: largura de banda - valor

Tempo, tempos de repetição e fusos horários

O campo t = contém a hora de início e a hora de término da sessão.

t = tempo de início e tempo de parada

O campo opcional r = contém informações sobre os tempos de repetição que podem ser especificados em NTP ou em dias ( d ), horas ( h ) ou minutos ( m ).

O campo opcional z = contém informações sobre os deslocamentos de fuso horário. Este campo é usado se a sessão estiver ocorrendo durante uma mudança do horário de verão para o horário padrão ou vice-versa.

Anúncios para a mídia

O campo opcional m = contém informações sobre o tipo de sessão de mídia. O campo contém -

m = lista de formatos de transporte de porta de mídia

O parâmetro de mídia é áudio, vídeo, texto, aplicativo, mensagem, imagem ou controle. O parâmetro port contém o número da porta.
O parâmetro de transporte contém o protocolo de transporte ou o perfil RTP usado.
A lista de formatos contém mais informações sobre a mídia. Normalmente, ele contém tipos de carga de mídia definidos em perfis de áudio e vídeo RTP.

Example:
m = audio 49430 RTP/AVP 0 6 8 99

Um desses três codecs pode ser usado para a sessão de mídia de áudio. Se a intenção for estabelecer três canais de áudio, serão usados três campos de mídia separados.

Atributos

O campo opcional a = contém atributos da sessão de mídia anterior. Este campo pode ser usado paraextend SDP to provide more information about the media. Se não for totalmente compreendido por um usuário SDP, o campo de atributo pode ser ignorado. Pode haver um ou mais campos de atributo para cada tipo de carga útil de mídia listado no campo de mídia.

Os atributos no SDP podem ser

nível de sessão, ou
nível de mídia.

O nível da sessão significa que o atributo é listado antes da primeira linha de mídia no SDP. Se for esse o caso, o atributo se aplica a todas as linhas de mídia abaixo dele.

Nível de mídia significa que ela está listada após uma linha de mídia. Nesse caso, o atributo se aplica apenas a este fluxo de mídia específico.

O SDP pode incluir atributos de nível de sessão e nível de mídia. Se o mesmo atributo aparecer como ambos, o atributo de nível de mídia substitui o atributo de nível de sessão para esse fluxo de mídia específico. Observe que o campo de dados de conexão também pode ser no nível da sessão ou no nível da mídia.

Um Exemplo SDP

A seguir está um exemplo de descrição de sessão, retirado do RFC 2327 -

v = 0
o = mhandley2890844526 2890842807 IN IP4 126.16.64.4
s = SDP Seminar
i = A Seminar on the session description protocol
u = http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e = [email protected](Mark Handley)
c = IN IP4 224.2.17.12/127
t = 2873397496 2873404696
a = recvonly
m = audio 49170 RTP/AVP 0
m = video 51372 RTP/AVP 31
m = application 32416udp wb
a = orient:portrait

O uso de SDP com SIP é fornecido na resposta de oferta SDP RFC 3264. O tipo de corpo de mensagem padrão no SIP é application/sdp.

A parte chamadora lista os recursos de mídia que deseja receber no SDP, geralmente em um INVITE ou em um ACK.
A parte chamada lista seus recursos de mídia na resposta 200 OK ao CONVITE.

Um uso SIP típico de SDP inclui os seguintes campos: versão, origem, assunto, hora, conexão e uma ou mais mídias e atributos.

Os campos de assunto e hora não são usados pelo SIP, mas são incluídos para compatibilidade.
No padrão SDP, o campo assunto é um campo obrigatório e deve conter pelo menos um caractere, sugerido como s = - se não houver assunto.
O campo de hora geralmente é definido como t = 00. SIP usa os campos de conexão, mídia e atributo para configurar sessões entre UAs.
O campo de origem tem uso limitado com SIP.
O id de sessão geralmente é mantido constante durante uma sessão SIP.
A versão é incrementada cada vez que o SDP é alterado. Se o SDP enviado não for alterado em relação ao enviado anteriormente, a versão será mantida a mesma.
Como o tipo de sessão de mídia e codec a ser usado fazem parte da negociação de conexão, o SIP pode usar o SDP para especificar vários tipos de mídia alternativos e aceitar ou recusar seletivamente esses tipos de mídia.

A especificação de oferta / resposta, RFC 3264, recomenda que um atributo contendo um = rtpmap: seja usado para cada campo de mídia. Um fluxo de mídia é recusado definindo o número da porta como zero para o campo de mídia correspondente na resposta SDP.

Exemplo

No exemplo a seguir, o chamador Tesla deseja configurar uma chamada de áudio e vídeo com dois codecs de áudio possíveis e um codec de vídeo no SDP transportado no CONVITE inicial -

v = 0 
o = John 0844526 2890844526 IN IP4 172.22.1.102  
s = - 
c = IN IP4 172.22.1.102 
t = 0 0 
m = audio 6000 RTP/AVP 97 98 
a = rtpmap:97 AMR/16000/1 
a = rtpmap:98 AMR-WB/8000/1 
m = video 49172 RTP/AVP 32 
a = rtpmap:32 MPV/90000

Os codecs são referenciados pelos números de perfil RTP / AVP 97, 98.

A parte chamada Marry atende a chamada, escolhe o segundo codec para o primeiro campo de mídia e recusa o segundo campo de mídia, querendo apenas a sessão AMR.

v = 0 
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110 
s = - 
c = IN IP4 200.201.202.203 
t = 0 0 
m = audio 60000 RTP/AVP 8 
a = rtpmap:97 AMR/16000 
m = video 0 RTP/AVP 32

Se esta chamada apenas de áudio não for aceitável, Tom enviará um ACK e, em seguida, um BYE para cancelar a chamada. Caso contrário, a sessão de áudio seria estabelecida e os pacotes RTP trocados.

Como este exemplo ilustra, a menos que o número e a ordem dos campos de mídia sejam mantidos, a parte chamadora não saberá com certeza quais sessões de mídia estão sendo aceitas e recusadas pela parte chamada.

As regras de oferta / resposta são resumidas nas seções a seguir.

Regras para gerar uma oferta

Uma oferta SDP deve incluir todos os campos SDP obrigatórios (isso inclui v =, o =, s =, c = e t =). Esses são campos obrigatórios no SDP.

Geralmente inclui um campo de mídia ( m = ), mas não é obrigatório. As linhas de mídia contêm todos os codecs listados em ordem de preferência. A única exceção a isso é se o terminal suportar um grande número de codecs, os mais prováveis de serem aceitos ou os mais preferidos devem ser listados. Diferentes tipos de mídia incluem áudio, vídeo, texto, MSRP, BFCP e assim por diante.

Regras para gerar uma resposta

Uma resposta SDP a uma oferta deve ser construída de acordo com as seguintes regras -

A resposta deve ter o mesmo número de m = linhas na mesma ordem da resposta.
Fluxos de mídia individuais podem ser recusados definindo o número da porta como 0.
Os fluxos são aceitos enviando um número de porta diferente de zero.
As cargas úteis listadas para cada tipo de mídia devem ser um subconjunto das cargas úteis listadas na oferta.
Para cargas dinâmicas, o mesmo número de carga dinâmica não precisa ser usado em cada direção. Normalmente, apenas uma única carga útil é selecionada.

Regras para modificar uma sessão

Qualquer uma das partes pode iniciar outra troca de oferta / resposta para modificar uma sessão. Quando uma sessão é modificada, as seguintes regras devem ser seguidas -

O número da versão da linha de origem ( o = ) deve ser igual ao último enviado, o que indica que este SDP é idêntico à troca anterior, ou pode ser incrementado em um, o que indica um novo SDP que deve ser analisado.
A oferta deve incluir todas as linhas de mídia existentes e devem ser enviadas no mesmo pedido.
Fluxos de mídia adicionais podem ser adicionados ao final da lista m = line.
Um fluxo de mídia existente pode ser excluído configurando o número da porta como 0. Esta linha de mídia deve permanecer no SDP e em todas as trocas de ofertas / respostas futuras para esta sessão.

Chamada em espera

Uma pessoa em uma chamada pode colocar a outra temporariamente em espera. Isso é feito enviando um CONVITE com um SDP idêntico ao do CONVITE original, mas coma = sendonly atributo presente.

A chamada é reativada enviando outro CONVITE com o a = sendrecvatributo presente. A ilustração a seguir mostra o fluxo de uma chamada em espera.

Personal mobilityé a capacidade de ter um identificador constante em vários dispositivos. O SIP oferece suporte à mobilidade pessoal básica usando o método REGISTER, que permite que um dispositivo móvel mude seu endereço IP e ponto de conexão com a Internet e ainda seja capaz de receber chamadas.

SIP também pode suportar service mobility - a capacidade de um usuário de manter os mesmos serviços quando móvel

Mobilidade SIP durante a transferência (pré-chamada)

Um dispositivo vincula seu URI de contato com o endereço de registro por um simples registro sip. De acordo com o endereço IP do dispositivo, o registro autoriza a atualização automática dessa informação na rede sip.

Durante a transferência, o agente do Utilizador faz o percurso entre diferentes operadores, onde tem de se registar novamente com um contacto como AOR de outro prestador de serviços.

Por exemplo, vamos dar o exemplo do seguinte fluxo de chamada. UA que recebeu temporariamente um novo URI SIP com um novo provedor de serviços. O UA então realiza um registro duplo -

O primeiro registro é com o novo operador de serviço, que vincula o URI de contato do dispositivo com o URI de AOR do novo provedor de serviço.
A segunda solicitação de REGISTRO é roteada de volta para o provedor de serviço original e fornece o AOR do novo provedor de serviço como o URI de contato.

Conforme mostrado posteriormente no fluxo da chamada, quando uma solicitação chega à rede do provedor de serviço original, o CONVITE é redirecionado para o novo provedor de serviço que então encaminha a chamada para o usuário.

Para o primeiro registro, a mensagem contendo o URI do dispositivo seria -

REGISTER sip:visited.registrar1.com SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK97a7ea349ce0fca 
Max-Forwards: 70 
To: Tom <sip:[email protected]> 
From: Tom <sip:[email protected]>;tag = 72d65a24 
Call-ID: [email protected] 
CSeq: 1 REGISTER 
Contact: <sip:[email protected]:5060> 
Expires: 600000 
Content-Length: 0

A segunda mensagem de registro com o URI de roaming seria -

REGISTER sip:home.registrar2.in SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bKah4vn2u 
Max-Forwards: 70 
To: Tom <sip:[email protected]> 
From: Tom <sip:[email protected]>;tag = 45375 
Call-ID:[email protected] 
CSeq: 6421 REGISTER 
Contact: <sip:[email protected]> 
Content-Length: 0

O primeiro CONVITE que é representado na figura acima seria enviado para sip: registrar2.in; o segundo CONVITE seria enviado para sip: sip: [email protected], que seria encaminhado parasip:[email protected]. Alcança Tom e permite que a sessão seja estabelecida. Periodicamente, ambos os registros precisariam ser atualizados.

Mobilidade durante uma chamada (novo convite)

O Agente do Usuário pode alterar seu endereço IP durante a sessão conforme ele muda de uma rede para outra. O SIP básico oferece suporte a esse cenário, pois um novo CONVITE em uma caixa de diálogo pode ser usado para atualizar o URI do contato e alterar as informações de mídia no SDP.

Dê uma olhada no fluxo de chamadas mencionado na figura abaixo.

Aqui, Tom detecta uma nova rede,
Usa DHCP para adquirir um novo endereço IP e
Executa um novo CONVITE para permitir a sinalização e o fluxo de mídia para o novo endereço IP.

Se o UA puder receber mídia de ambas as redes, a interrupção será insignificante. Se não for esse o caso, alguns pacotes de mídia podem ser perdidos, resultando em uma ligeira interrupção da chamada.

O re-CONVIDAR aparecerá da seguinte maneira -

INVITE sip:[email protected] SIP/2.0  
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a 
Max-Forwards: 70 

To: <sip:[email protected]> 

From: sip:[email protected];tag = 70133df4 
Call-ID: 76d4861c19c 
CSeq: 1 INVITE 
Accept: application/sdp 
Accept-Language: en 

Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY,SUBSCRIBE 
Contact: <sip:172.22.1.102:5060>; 
Content-Type: application/sdp 
Content-Length: 168 

v = 0
o = PPT 40467 40468 IN IP4 192.168.2.1 
s = - 
c = IN IP4 192.168.2.1 
b = AS:49 
t = 0 0 
b = RR:0 
b = RS:0 
a = rtpmap:97 AMR/8000/1 
m = audio 6000 RTP/AVP 96 
a = fmtp:102 0-15 
a = ptime:20 
a = maxptime:240

O re-CONVITE contém o novo endereço IP do Bowditch nos campos de cabeçalho Via e Contato e informações de mídia SDP.

Mobilidade no meio da chamada (com substituir cabeçalho)

Na mobilidade no meio da chamada, o conjunto de rotas real (conjunto de proxies SIP que as mensagens SIP devem percorrer) deve ser alterado. Não podemos usar um CONVITE novamente em mobilidade no meio da chamada

Por exemplo, se um proxy for necessário para o NAT traversal, o URI do contato deve ser alterado - um novo diálogo deve ser criado. Portanto, ele deve enviar um novo INVITE com um cabeçalho Replaces, que identifica a sessão existente.

Note - Suponha que A e B estejam em uma chamada e se A receber outro INVITE (digamos de C) com um cabeçalho de substituição (deve corresponder ao diálogo existente), então A deve aceitar o CONVITE e encerrar a sessão com B e transferir todos os recursos para diálogo recém-formado.

O fluxo de chamadas é mostrado na figura a seguir. É semelhante ao fluxo de chamada anterior usando re-INVITE, exceto que um BYE é gerado automaticamente para encerrar o diálogo existente quando o INVITE com o Replaces é aceito.

A seguir estão os pontos a serem observados neste cenário -

A caixa de diálogo existente entre Tom e Jerry inclui o antigo servidor proxy visitado.
A nova caixa de diálogo usando a nova rede sem fio requer a inclusão do novo servidor proxy visitado.
Como resultado, um INVITE with Replaces é enviado por Tom, que cria um novo diálogo que inclui o novo servidor proxy visitado, mas não o antigo servidor proxy visitado.
Quando Jerry aceita o INVITE, um BYE é enviado automaticamente para encerrar o antigo diálogo que roteia através do antigo servidor proxy visitado que agora não está mais envolvido na sessão.
A sessão de mídia resultante é estabelecida usando o novo endereço IP de Tom do SDP no INVITE.

Mobilidade de Serviço

Os serviços em SIP podem ser fornecidos em proxies ou em UAs. Fornecer mobilidade de serviço junto com mobilidade pessoal pode ser desafiador, a menos que os dispositivos do usuário sejam configurados de forma idêntica com os mesmos serviços.

O SIP pode facilmente oferecer suporte à mobilidade de serviço pela Internet. Quando conectado à Internet, um UA configurado para usar um conjunto de proxies na Índia ainda pode usar esses proxies quando estiver em roaming na Europa. Isso não tem nenhum impacto na qualidade da sessão de mídia, pois a mídia sempre flui diretamente entre os dois UAs e não atravessa os servidores proxy SIP.

Os serviços residentes no terminal estão disponíveis apenas quando o terminal está conectado à Internet. Um serviço de encerramento, como um serviço de encaminhamento de chamadas implementado em um terminal, falhará se o terminal tiver perdido temporariamente sua conexão com a Internet. Portanto, alguns serviços são implementados na rede usando servidores proxy SIP.

Às vezes, um servidor proxy encaminha uma única chamada SIP para vários terminais SIP. Este processo é conhecido como bifurcação. Aqui, uma única chamada pode tocar em vários terminais ao mesmo tempo.

Com a bifurcação SIP, você pode fazer com que seu telefone de mesa toque ao mesmo tempo que seu softphone ou um telefone SIP em seu celular, permitindo que você atenda a chamada facilmente de qualquer dispositivo.

Geralmente, em um escritório, suponha que o chefe não possa atender ou desligar a chamada, o bifurcação SIP permite que a secretária atenda chamadas em seu ramal.

A bifurcação será possível se houver um proxy com monitoração de estado disponível, pois ele precisa executar e responder entre os muitos que recebe.

Temos dois tipos de bifurcação -

Bifurcação Paralela
Bifurcação Sequencial

Bifurcação Paralela

Nesse cenário, o servidor proxy bifurcará o INVITE para, digamos, dois dispositivos (UA2, UA3) de cada vez. Ambos os aparelhos vão gerar 180 Ringing e quem receber a chamada vai gerar 200 OK. A resposta (suponha que UA2) que chega primeiro ao Originador estabelecerá uma sessão com UA2. Para a outra resposta, um CANCELAR será acionado.

Se o originador receber ambas as respostas simultaneamente, com base no valor q, ele encaminhará a resposta.

Bifurcação Sequencial

Nesse cenário, o servidor proxy bifurcará o INVITE em um dispositivo (UA2). Se o UA2 estiver indisponível ou ocupado naquele momento, o proxy o transferirá para outro dispositivo (UA3).

Filial - ID e Tag

Os IDs de filial ajudam os proxies a corresponder as respostas a solicitações bifurcadas. Sem os IDs de filial, um servidor proxy não seria capaz de entender a resposta bifurcada. Branch-id estará disponível no cabeçalho Via.

As marcas são usadas pelo UAC para distinguir várias respostas finais de diferentes UAS. Um UAS não pode resolver se a solicitação foi bifurcada ou não. Portanto, é necessário adicionar uma tag.

Os proxies também podem adicionar tags se isso gerar uma resposta final, eles nunca inserem tags nas solicitações ou respostas que encaminham.

Pode ser possível que uma única solicitação também seja bifurcada por vários servidores proxy. Portanto, o proxy que bifurcará deve adicionar seus próprios IDs exclusivos aos branches que criou.

Trecho de chamada e ID de chamada

Um trecho de chamada se refere a um para um relacionamento de sinalização entre dois agentes de usuário. O ID da chamada é um identificador exclusivo transportado na mensagem SIP que se refere à chamada. Uma chamada é uma coleção de trechos de chamada.

Um UAC começa enviando um CONVITE. Devido à bifurcação, ele pode receber vários 200 OK de UAs diferentes. Cada um corresponde a um trecho de chamada diferente dentro da mesma chamada.

Uma chamada é, portanto, um grupo de trechos de chamada. Um trecho de chamada refere-se à conexão ponta a ponta entre UAs.

Os espaços CSeq nas duas direções de um trecho de chamada são independentes. Em uma única direção, o número de sequência é incrementado para cada transação.

Correio de voz

O correio de voz é muito comum hoje em dia para usuários corporativos. É um aplicativo de telefone. Quando a pessoa chamada não estiver disponível ou não puder receber a chamada, o PABX anunciará ao chamador para deixar uma mensagem de voz.

O agente do usuário obterá uma resposta 3xx ou redirecionará para o servidor de correio de voz se o número da parte chamada estiver inacessível. No entanto, algum tipo de ramal SIP é necessário para indicar ao sistema de correio de voz qual caixa postal usar, ou seja, qual saudação reproduzir e onde armazenar a mensagem gravada. Existem duas maneiras de conseguir isso -

Usando uma extensão de campo de cabeçalho SIP
Usando o Request-URI para sinalizar esta informação

Suponha que para o usuário sip:[email protected] tem um sistema de correio de voz em sip: voicemail.tutorialspoint.com que fornece correio de voz, o URI de solicitação do INVITE quando é encaminhado para o servidor de correio de voz pode ser semelhante a -

sip:voicemail.tutorialspoint.com;target = sip:[email protected];cause = 486

A ilustração a seguir mostra como o Request-URI carrega o identificador da caixa de correio e o motivo (aqui 486).

Como sabemos, um servidor proxy pode ser sem estado ou com estado. Aqui, neste capítulo, discutiremos mais sobre servidores proxy e roteamento SIP.

Servidor proxy sem estado

Um servidor proxy sem estado simplesmente encaminha a mensagem que recebe. Este tipo de servidor não armazena nenhuma informação da chamada ou transação.

Os proxies sem estado esquecem a solicitação SIP depois que ela é encaminhada.
A transação será rápida por meio de proxies sem estado.

Servidor proxy com estado

Um servidor proxy com monitoração de estado mantém registro de cada solicitação e resposta que recebe. Ele pode usar as informações armazenadas no futuro, se necessário. Ele pode retransmitir a solicitação se não receber uma resposta do outro lado.

Os proxies com estado se lembram da solicitação depois que ela foi encaminhada, para que possam usá-la para roteamento avançado. Proxies com estado mantêm o estado da transação . A transação implica o estado da transação,notestado de chamada .
A transação não é tão rápida com proxies com estado quanto sem estado.
Proxies com estado podem bifurcar e retransmitir se necessário (por exemplo: encaminhamento de chamada ocupada, por exemplo).

Via e rota de registro

Rota-Registro

O cabeçalho Record-Route é inserido em solicitações por proxies que queriam estar no caminho de solicitações subsequentes para o mesmo ID de chamada. Em seguida, ele é usado pelo agente do usuário para rotear as solicitações subsequentes.

Através da

Os cabeçalhos de via são inseridos pelos servidores em solicitações para detectar loops e ajudar as respostas a encontrar o caminho de volta para o cliente. Isso é útil apenas para as respostas chegarem ao destino.

O próprio UA gera e adiciona seu próprio endereço em um campo de cabeçalho Via ao enviar a solicitação.
Um proxy que encaminha a solicitação adiciona um campo de cabeçalho Via contendo seu próprio endereço ao topo da lista de campos de cabeçalho Via.
Um proxy ou UA que gera uma resposta a uma solicitação copia todos os campos do cabeçalho Via da solicitação na ordem para a resposta e, em seguida, envia a resposta ao endereço especificado no campo de cabeçalho Via superior.
Um proxy que recebe uma resposta verifica o campo do cabeçalho Via superior e corresponde a seu próprio endereço. Se não corresponder, a resposta foi descartada.
O campo de cabeçalho Via superior é então removido e a resposta encaminhada para o endereço especificado no próximo campo de cabeçalho Via.

Os campos de cabeçalho via contêm o nome do protocolo, número da versão e transporte (SIP / 2.0 / UDP, SIP / 2.0 / TCP, etc.) e contêm números de porta e parâmetros como recebidos, rport, ramificação.

Uma tag recebida é adicionada a um campo de cabeçalho Via se um UA ou proxy receber a solicitação de um endereço diferente do especificado no campo de cabeçalho Via superior.
Um parâmetro de ramificação é adicionado aos campos de cabeçalho Via por UAs e proxies, que é calculado como uma função hash do URI de Solicitação e do número Para, De, ID de Chamada e CSeq.

SIP (Softphone) e PSTN (telefone antigo) são redes diferentes e falam idiomas diferentes. Portanto, precisamos de um tradutor (Gateway aqui) para nos comunicarmos entre essas duas redes.

Vamos dar um exemplo para mostrar como um telefone SIP faz uma chamada telefônica para um PSTN por meio do gateway PSTN.

Neste exemplo, Tom (sip:[email protected]) é um telefone sip e Jerry usa um número de telefone global +91401234567.

SIP para PSTN por meio de Gateways

A ilustração a seguir mostra um fluxo de chamadas de SIP para PSTN por meio de gateways.

A seguir, é fornecida uma explicação passo a passo de todo o processo que ocorre ao fazer uma chamada de um telefone SIP para PSTN.

Em primeiro lugar, o telefone SIP (Tom) disca o número global +91401234567 para falar com Jerry. O agente de usuário SIP o entende como um número global e o converte em uri de solicitação usando DNS e aciona a solicitação.
O telefone SIP envia o CONVITE diretamente para o gateway.
O gateway inicia a chamada no PSTN selecionando um tronco SS7 ISUP para a próxima central telefônica no PSTN.
Os dígitos discados do CONVITE são mapeados no ISUP IAM. A mensagem de conclusão do endereço ISUP (ACM) é enviada de volta pelo PSTN para indicar que o tronco foi criado.
O telefone gera toque e vai para a central telefônica. O gateway mapeia o ACM para a resposta de progresso da sessão 183 contendo um SDP indicando a porta RTP que o gateway usará para fazer a ponte entre o áudio do PSTN.
Ao receber o 183, o UAC do chamador começa a receber os pacotes RTP enviados do gateway e apresenta o áudio ao chamador para que ele saiba que o receptor está progredindo no PSTN.
A chamada é concluída quando a parte chamada atende o telefone, o que faz com que a central telefônica envie uma mensagem de atendimento (ANM) ao gateway.
O gateway então corta a conexão de áudio PSTN em ambas as direções e envia uma resposta 200 OK ao chamador. Como o caminho da mídia RTP já está estabelecido, o gateway responde ao SDP no 183, mas não causa alterações na conexão RTP.
O UAC envia um ACK para concluir a troca de sinalização SIP. Como não há mensagem equivalente no ISUP, o gateway absorve o ACK.
O chamador envia BYE ao gateway para encerrar. O gateway mapeia o BYE na mensagem de liberação do ISUP (REL).
O gateway envia o 200OK para o BYE e recebe um RLC do PSTN.

Um codec, abreviação de codificador-decodificador, executa duas operações básicas -

Primeiro, ele converte um sinal de voz analógico em sua forma digital equivalente para que possa ser transmitido facilmente.
Depois disso, ele converte o sinal digital comprimido de volta à sua forma analógica original para que possa ser reproduzido.

Existem muitos codecs disponíveis no mercado - alguns são gratuitos, enquanto outros exigem licença. Codecs variam na qualidade do som e variam na largura de banda de acordo.

Dispositivos de hardware, como telefones e gateways, oferecem suporte a vários codecs diferentes. Enquanto conversam, eles negociam qual codec usarão.

Aqui, neste capítulo, discutiremos alguns codecs de áudio SIP populares que são amplamente usados.

G.711

G.711 é um codec que foi introduzido pela ITU em 1972 para uso em telefonia digital. O codec tem duas variantes:A-Law está sendo usado na Europa e em links telefônicos internacionais, uLaw é usado nos EUA e no Japão.

G.711 usa uma compressão logarítmica. Ele comprime cada amostra de 16 bits em 8 bits, assim, atinge uma taxa de compressão de 1: 2.
A taxa de bits é de 64 kbit / s para uma direção, portanto, uma chamada consome 128 kbit / s.
G.711 é o mesmo codec usado pela rede PSTN, portanto, oferece a melhor qualidade de voz. No entanto, ele consome mais largura de banda do que outros codecs.
Funciona melhor em redes locais, onde temos muita largura de banda disponível.

G.729

G.729 é um codec com baixos requisitos de largura de banda; fornece boa qualidade de áudio.

O codec codifica o áudio em quadros de 10 ms de duração. Dada uma frequência de amostragem de 8 kHz, um quadro de 10 ms contém 80 amostras de áudio.
O algoritmo do codec codifica cada quadro em 10 bytes, de modo que a taxa de bits resultante é de 8 kbit / s em uma direção.
G.729 é um codec licenciado. Os usuários finais que desejam usar este codec devem comprar um hardware que o implemente (seja um telefone VoIP ou gateway).
Uma variante frequentemente usada do G.729 é G.729a. É compatível com fio com o codec original, mas tem requisitos de CPU mais baixos.

G.723.1

O G.723.1 é o resultado de um concurso anunciado pela ITU com o objetivo de projetar um codec que permitisse chamadas em links de modem de 28,8 e 33 kbit / s.

Temos duas variantes do G.723.1. Ambos operam em quadros de áudio de 30 ms (ou seja, 240 amostras), mas os algoritmos são diferentes.
A taxa de bits da primeira variante é de 6,4 kbit / s, enquanto para a segunda variante é de 5,3 kbit / s.
Os quadros codificados para as duas variantes têm 24 e 20 bytes de comprimento, respectivamente.

GSM 06.10

GSM 06.10 é um codec projetado para redes móveis GSM. Também é conhecido como GSM Full Rate.

Essa variante do codec GSM pode ser usada livremente, então você a encontrará com frequência em aplicativos VoIP de código aberto.
O codec opera em quadros de áudio de 20 ms de comprimento (ou seja, 160 amostras) e comprime cada quadro em 33 bytes, de modo que a taxa de bits resultante é de 13 kbit /.

Um agente de usuário back-to-back (B2BUA) é um elemento lógico de rede em aplicativos SIP. É um tipo de SIP UA que recebe uma solicitação SIP, a reformula e a envia como uma nova solicitação.

Ao contrário de um servidor proxy, ele mantém o estado de diálogo e deve participar de todas as solicitações enviadas nos diálogos que estabeleceu. Um B2BUA quebra a natureza de ponta a ponta do SIP.

B2BUA - Como funciona?

Um agente B2BUA opera entre dois terminais de uma chamada telefônica e divide o canal de comunicação em dois call legs. B2BUA é uma concatenação de UAC e UAS. Participa de toda a sinalização SIP entre os dois extremos da chamada, conforme estabelecido. Como o B2BUA disponível em um provedor de serviços de diálogo pode implementar alguns recursos de valor agregado.

No trecho de chamada de origem, o B2BUA atua como um servidor de agente de usuário (UAS) e processa a solicitação como um cliente de agente de usuário (UAC) até a extremidade de destino, lidando com a sinalização entre os pontos de extremidade back-to-back.

Um B2BUA mantém o estado completo para as chamadas que trata. Cada lado de um B2BUA opera como um elemento de rede SIP padrão, conforme especificado no RFC 3261.

Funções do B2BUA

Um B2BUA fornece as seguintes funções -

Gerenciamento de chamadas (faturamento, desconexão automática de chamadas, transferência de chamadas, etc.)
Interfuncionamento de rede (talvez com adaptação de protocolo)
Ocultação de componentes internos da rede (endereços privados, topologia de rede, etc.)

Freqüentemente, os B2BUAs também são implementados em gateways de mídia para fazer a ponte entre os fluxos de mídia e obter controle total sobre a sessão.

Exemplo de B2BUA

Muitos sistemas de telefonia corporativa de central privada (PBX) incorporam a lógica B2BUA.

Alguns firewalls incorporam a funcionalidade ALG (Application Layer Gateway), que permite que um firewall autorize o SIP e o tráfego de mídia enquanto mantém um alto nível de segurança.

Outro tipo comum de B2BUA é conhecido como Session Border Controller (SBC).