Ebook - Asterisk® SCF™ Expert - SIP Security

Asterisk® SCF™ SIP Security
Professor Especialista Angelo de Barros Delphini

Este eBook É um trabalho de pesquisa para auxiliar os profissionais da área de TI, profissionais
da área de Telecom e estudantes que estão iniciando em “ToIP & VoIP”. Este material é a
reunião de várias informações disponibilizadas pela Internet, Artigos e Livros. Minha intenção
não é plagiar, mas sim oferecer um material onde você possa estudar de maneira simples e
eficiente. Bom estudo!
FALSA FOLHA DE ROSTO
Angelo de Barros Delphini
Asterisk® SCF™ SIP Security
ISBN papel: 202004161509

ISBN pdf: 202004161509
Impresso em Espanha
Editado por Bubok Publishing S.L.
“Reservados todos os direitos. Salvo exceção prevista pela lei, não é permitida a reprodução total ou parcial desta obra,
nem a sua incorporação a um sistema informático, nem a sua transmissão em qualquer forma ou por qualquer meio (ele-
trónico, mecânico, fotocopia, gravação ou outros) sem autorização prévia e por escrito dos titulares do copyright. A infração
de ditos direitos implica sanções legais e pode constituir um delito contra a propriedade intelectual.
Dirija-se a CEDRO (Centro Espanhol de Direitos Reprográficos) se precisa de fotocopiar o digitalizar algum fragmento
desta obra (www.conlicencia.com; 91 702 19 70 / 93 272 04 47).”
Palavra puxa palavra, uma ideia traz outra, e assim se faz um livro,
um governo, ou uma revolução, alguns dizem que assim
é que a natureza compôs as suas espécies.
Machado de Assis.
Índice
Capítulo 1
O protocolo de inicialização de sessão – SIP
A origem e o propósito do SIP
O SIP é definido no RFC 2543 (março de 1999) do grupo de trabalho MMUSIC (Multiparty Multimedia
Session Control) do IETF.
O grupo de trabalho MMUSIC está concentrado em conferências fracamente acopladas da forma como
existe atualmente no MBONE e está trabalhando em uma estrutura completa baseada nos seguintes
protocolas:
• Protocolo de descrição de sessão (Session Description Protocol – SDP) e o Protocolo de Anún-

cio de sessão (Session Announcement Protocol – SAP);
• Protocolo de Fluxo em Tempo Real (Real-Time Stream Protocol – RTSP), para controlar servi-
dores de dados de tempo real;
• Protocolo Simples de Controle de Conferência (Simple Conference Control Protocol – SCCP)
para conferências fortemente acopladas. Esse trabalho começou há pouco tempo com a definição
de um barramento de mensagens (message bus) entre sistemas de conferência;
• Protocolo de Inicialização de Sessão (Session Initiation Protocol – SIP).
Até agora apenas o SIP, o RTSP e o SDP tornaram-se RFCs (Requests For Comments).
Esses protocolos complementam os protocolos IETF existentes, como o RTP do grupo de trabalho
AVT (Audio/Video Transport), para a transferência de dados isócronos ou o RSVP do grupo de traba-
lho INTSERV (Integrated Services), para alocação de largura de banda.
Capítulo 2
Visão geral de uma chamada SIP Simples

Chamada bem-sucedida diretamente para um endereço IP
Aqui consideramos que o iniciador da chamada conhece o endereço IP do ponto de destino da cha-
mada (veremos posteriormente que existem vários outros tipos de endereços SIP). O originador da
chamada poderia estar chamando o seguinte endereço IP:
sip:john@192.190.132.31
As entidades SIP se comunicam usando ‘transações’. O SIP chama cada transação de pedido (p. ex.: o
pedido INVITE detalhado a seguir) e cada pedido provoca uma ou mais respostas (como o 200 OK no
nosso exemplo), até que ocorra uma resposta final (veja a definição a seguir; todas as repostas 2XX,
3XX, 4XX, 5XX e 6XX são finais). O iniciador de um pedido SIP é chamado de cliente SIP (UAC) e
11
a entidade que responde é chamada de servidor SIP (UAS). As mensagens trocadas durante uma tran-
sação compartilham um número Cseq comum, com uma exceção: a mensagem ACK usa o mesmo Cseq
da transação à qual ela se aplica, mas é uma transação diferente.
A primeira etapa consiste em abrir uma conexão de sinalização entre os pontos de origem e de destino
da chamada. Pontos finais (Endpoint ou End Device) SIP podem usar sinalização UDP ou TCP. A
sintaxe das mensagens é independente do protocolo de transporte usado. Quando se usa o TCP, a
mesma conexão pode ser usada para todos os pedidos e respostas SIP (não para os dados de mídia) ou
uma nova conexão TCP pode ser usa para cada transação. Se o UDP for usado, o endereço e a porta a
serem usados para as respostas a pedidos SIP estarão contidos nos parâmetros de cabeçalho ‘VIA’ do
pedido SIP. As respostas não devem ser enviadas para o endereço IP do cliente. Se nenhuma porta for
especificada no endereço SIP, a conexão é feita com a porta 5060 (deve ser liberada no firewall 5060,
5061 e 5062) tanto para o TCP quanto para o UDP.
Um cliente SIP (UAC) chama um outro ponto final (Endpoint) enviando uma mensagem de pedido
INVITE (ver figura 2.1). A mensagem INVITE normalmente contém informações suficientes para
permitir que o terminal de destino estabeleça imediatamente a conexão de mídia solicitada com o ponto
de origem da chamada. Essas informações incluem as capacidades de mídia que o ponto de origem da
chamada pode receber (e enviar: considera-se que capacidades do codificador estão enviando ou rece-
bendo no SIP, a menos que os parâmetros SDP SENDONLY ou RECONLY sejam usados) e o
endereço de transporte onde o ponto de origem da chamada espera que o ponto de destino da cha-
mada envie esses dados de mídia. A maioria dos pontos finais (Endpoint) serão capazes de receber
muitas codificações diferentes para cada tipo de mídia. A codificação em particular escolhida pelo reme-
tente aparece como parte do cabeçalho RTP.
Figura 2.1 – Realizando uma chamada para um endereço IP conhecido
Fonte: IP TELEPHONY - Jean-Pierre Petit, Olivier Hersent, David Gurle (Wiley), 5 outubro 2005.
12
O ponto de destino da chamada precisa indicar que ele está aceitando o INVITE. Este é o objetivo da
mensagem de reposta OK. Uma vez que o pedido foi um INVITE, a resposta OK também contém as
capacidades de mídia do ponto de destino da chamada e onde ela está esperando receber os dados de
mídia. O originador da chamada precisa confirmar que recebeu de maneira adequada a resposta do
ponto de destino da chamada (lembre-se que podemos estar usando UDP) com a mensagem ACK.
A partir desse exemplo simples, podemos ver que o SIP é muito eficiente, o canal de mídia do recebedor
para o originador da chamada pode ser estabelecido com uma ida e uma volta de mensagens e o canal
de mídia do originador para o recebedor pode ser estabelecido com uma ida, uma volta e outra ida
de mensagens. Isso é muito melhor que as várias idas-e-voltas exigidas pelo H.323v1 (o H.323v2 é tão
eficiente quanto o SIP se a configuração de chamada FASTSTART for usada).
Negociação de CODEC
Na chamada anterior, o terminal de Mary ofereceu-se para receber um canal de áudio codificado em
PCMA (Pulse Code Modulation G.711 A-law, usado na Europa e no Brasil – 64 Kbps – MOS 4.41).
Isso pode não ser aceitável para o terminal de John, ou porque John não dispõe de largura de banda
suficiente (o PCMA exige 64 Kbps, mais o OVERHEAD RTP/UDP/IP/PPP) ou porque o terminal
de John não possui um codificador PCMA.
Nesse caso, o terminal de John responderá com um 606 Not Acceptable e finalmente relacionará o
conjunto de codificadores que ele pode usar. Com essa informação, o terminal de Mary pode enviar um
novo pedido INVITE, com o mesmo identificador de chamada, anunciando o código apropriado (mas
se ele tivesse essa capacidade, poderia tê-la enviando como uma escolha no primeiro pedido INVITE)
ou então reiniciar uma chamada por meio de um proxy de transcodificações (ver figura 2.2).
O fórum de Voz Sobre IP (Voice Over Internet Protocol – VoIP), chegou a um consenso sobre um
codificador padrão a ser usado no caso de voz a baixa taxa de bits, o G.723.1, de maneira a manter
mínima a probabilidade desse tipo de incompatibilidade no H.323. Nenhuma recomendação desse tipo
existe para o SIP, mas a maioria dos terminais parece ser capaz de receber PCMA e PCMU (Pulse Code
Modulation G.711 µ-law, usado no Estados Unidos da América – 64 Kbps – MOS 4.41) e também o
GSM (Global System for Mobile Communications – 12~13 Kbps – MOS 3.71). Este é um sistema
padrão popular de serviços de celulares fora dos Estados Unidos. GSM inclui um CODEC, normal-
mente chamado apenas como GSM CODEC. O codec de conversação original 'Full Rate' GSM é cha-
mado RPE-LTP (Regular Pulse Excitation Long-Term Prediction). Este codec usa informações de sam-
ples anteriores (esta informação não muda muito rapidamente) de maneira a prever a sample corrente.
O sinal de conversação é dividido em blocos de 20 ms. Estes blocos são passados para o codec de
conversação, que utiliza uma taxa de 12~13 kbps, de maneira a obter blocos de 260 bits.
OBS: A qualidade de voz é medida em MOS (Mean Opinion Score, ou média dos resultados das opini-
ões). Os testes para MOS seguem a norma P.800 da ITU. O MOS varia em uma escala de 1 (qualidade
ruim) a 5 (qualidade excelente), saiba mais em https://pt.wikipedia.org/wiki/Mean_Opinion_Score.
13
Figura 2.2 – Negociando o estabelecimento da chamada
O SIP não tem uma noção de canais lógicos (como definido no H.323). Quando um cliente se oferece
para receber vários tipos de mídia em varias portas UDP ou TCP, ele tem de estar preparado para
receber mídia imediatamente em qualquer uma dessas portas. No entanto, o terminal de destino pode
decidir enviar dados em apenas algumas portas (por exemplo, ele não possui capacidades de vídeo e
envia apenas áudio). Nada na sinalização informa ao cliente se uma determinada porta estará ativa ou
não. Em geral, isso não é realmente um problema, uma vez que a maioria dos pontos finais podem ficar
escutando as portas não usadas sem um impacto significativo no desempenho. Em alguns casos, no
entanto, as entidades SIP precisam manter vários canais de mídia e têm de reutilizar as portas UDP da
maneira mais eficiente possível – este é o caso de grandes gateways ou recursos de mídia centralizados.
Essas entidades podem ter de multiplexar vários canais de mídia em uma única porta ou fechar portas
inativas com base em heurísticas, por exemplo, após um período sem nenhuma atividade.
14
Finalizando uma chamada
O exemplo anterior (ver figura 2.2) é uma configuração de chamada simples e bem-sucedida. Aqui vemos
a sinalização de chamada completa, incluindo a finalização de chamada feita por John (ver figura 2.3).
Se Mary tivesse finalizado a chamada, ela teria enviado o pedido BYE e os campos FROM e TO seriam
invertidos. Os fluxos de mídia não são mostrados, mas as mensagens de sinalização incluem todos os
cabeçalhos obrigatórios.
Alguns cabeçalhos IP têm formas abreviadas que podem ajudar a manter o tamanho total de uma men-
sagem abaixo do MTU. Nesse exemplo, o terminal de John está usando a forma abreviada.
15
Figura 2.3 – Sinalização da chamada completa entre Mary e John
16
Rejeitando uma chamada
Por vários motivos, John pode não ser capaz de receber uma chamada de Mary. Ele pode não estar lá
ou estar sem vontade de responder ou então pode estar em uma outra conversa. Essas condições podem
ser expressas na mensagem de resposta. O SIP fornece códigos para as condições comuns, mas também
define respostas mais sofisticadas, tais como GONE, PAYMENT ou FORBIDDEN.
Uma simples resposta BUSY HERE (ver figura 2.4) informa a Mary que John não pode ser alcançado
nesse local (mas ela pode tentar alcançar outro local, como o telefone celular de John, por meio de um
GATEWAY ou um VOICE MAIL). Uma outra resposta, 600 Busy Everywhere, informará a ela que
John não pode ser alcançado em nenhum lugar nesse momento.
Figura 2.4 – A resposta BUSY HERE
17
Capítulo 3
Mensagens SIP
Desmistificando as Mensagens SIP
As mensagens SIP são codificadas usando a sintaxe de mensagem HTTP/1.1 (RFC 2068). O conjunto
de caracteres é o ISO 10646 com codificação UTF-8 (RFC 2279). As linhas são terminadas com CRLF
(Carriage Return, Line Feed), mas os receptores devem ser capazes de tratar também CR ou LF.
Há dois tipos de mensagens SIP: pedidos (requests) e repostas (responses). Elas compartilham um
formato comum, mostrado na figura 3.1, onde SP é uma abreviatura para espaço simples (simgle
space).
Alguns campos do cabeçalho estão presentes tanto nos pedidos quanto nas respostas. Eles são parte do
cabeçalho geral.
Figura 3.1 – O formato de Mensagem SIP
►Call-ID (p. ex.: ‘CALLID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com’): o parâmetro

CALLID serve para muitos propósitos. Nos pedidos REGISTER e OPTIONS, ele serve para coincidir
os pedidos com as respostas correspondentes. Para os pedidos INVITE e REGISTRATION ele tam-
bém ajuda a detectar cópias duplicadas (pedidos de INVITE duplicados podem ocorrer quando há um
proxy de bifurcação – FORKING PROXY – no caminho).
Os pedidos, INVITE sucessivos com o mesmo CALLID, mas com parâmetros diferentes, podem ser
usados para mudar parâmetros dinamicamente em uma conferência.
A primeira parte do CALLID deve ser um padrão único dentro de cada computador e a ultima parte,
um nome de domínio ou o endereço IP de uma máquina, torna-o globalmente único (no caso de um
18
endereço IP ser usado, ele deve ser roteável, isto é, endereços privados tais como 10.X.X.X não podem
ser usados). Um novo CALLID deve ser gerado para cada chamada;
►Cseq (p. ex.: Cseq: 1234 INVITE): cada pedido tem de ter um campo de cabeçalho Cseq, composto
por um número (sem sinal) de sequência e pelo nome do método. Dentro de uma chamada, o número
de sequencia é incrementado a cada novo pedido (a menos que o pedido seja uma retransmissão de um
pedido anterior estritamente idêntico) e começa com um valor aleatório. As únicas exceções são os
pedidos ACK e CANCEL, que mantêm o numero Cseq da resposta recebida (para ACK) ou do pedido
cancelado (para o CANCEL). O servidor deve copiar o valor Cseq do pedido nas respostas correspon-
dentes (ver figura 3.2);
►From (p. ex.: From: ‘MyDisplayName’<sip:myaccount@company.com>): este campo deve estar pre-
sente em todos os pedidos e repostas. Ele contém um nome opcional a ser mostrado opcional e o
endereço do originador do pedido. Etiquetas (TAGS) opcionais podem ser adicionadas. Observe que
o campo FROM contido na resposta SIP é simplesmente copiado a partir do pedido e, portanto, não
designa o originador da resposta;
►To (p. ex.: To: HelpDesk<sip:helpdesk@company.com>;tag=287447): esse campo deve estar pre-
sente em todos os pedidos e respostas e indica o destino pretendido de um INVITE. Ele é simplesmente
copiado nas respostas. A etiqueta é usada principalmente quando uma única URI (Uniform Resource
Identifier) SIP designa vários pontos finais possíveis (como no caso de um helpdesk). Nesse caso, uma
etiqueta aleatória é adicionada às respostas para permitir ao cliente distinguir as respostas de pontos finais
diferentes;
Figura 3.2 – Uso do Cseq
19
►Via (p. ex.: Via: SIP/2.0/UDP PXY1.provider.com/ receiveid 10.0.0.3): o campo ‘Via’ é usado para
gravar a rota de um pedido, de maneira a permitir que servidores SIP intermediários retransmitam as
respostas ao longo do mesmo caminho (ver figura 3.2).
Para conseguir isso, cada proxy adiciona um novo campo ‘Via’ com o seu próprio endereço à lista de
campos ‘Via’ existentes. O recebedor do pedido pode adicionar parâmetros adicionais, por exemplo,
para indicar que ele recebeu o pedido a partir de um endereço que não é o endereço contido no ultimo
campo ‘Via’ recebido. Usando um endereço que não é o endereço contido no ultimo campo ‘Via’ rece-
bido. Usando essa informação, um proxy pode retransmitir os pedidos ao remetente original, mesmo se
houver um dispositivo de tradução de endereços de rede no caminho. No exemplo anterior, o CALL
CENTER usa apenas endereços privados (10.X.X.X) e está conectado à INTERNET por meio de
um roteador que faz a tradução de endereços de rede. Quando recebe o pedido INVITE vindo do proxy
PXY1, o endereço IP de origem do pedido não é 192.9.5.3; mas terá sido mudado pelo dispositivo NAT
para 10.0.0.3.
Então o sistema de distribuição automática de chamadas (Automatic Call Disttibuition – ACD) grava
essa informação em um parâmetro RECEIVED. Ao receber a resposta para essa questão, ele saberá
que deve retransmitir o pedido para o endereço 10.0.0.3 e não para o endereço de PXY1@provi-
der.com. Esse mecanismo também funciona quando se envia um pedido para fora de um domínio IP
usando-se endereços não-roteáveis.
Esse exemplo também mostra como o multicast foi levado em conta. Quando um parâmetro MADDR
está presente em um campo ‘Via’, a resposta é retransmitida em multicast usando-se o endereço
MADDR (e o valor TTL armazenado no parâmetro TTL).
O Campo de cabeçalho ‘Via’ é uma das características mais poderosas do SIP e mostra que o SIP foi
projetado tendo-se os problemas de redes IP em mente;
►Encryption (p. ex.: Encryption: PGP version=2.6.2, encoding=ascii): esse campo de cabeçalho espe-
cifica que o corpo da mensagem e, possivelmente, alguns cabeçalhos de mensagem foram criptografados.
Para obter mais detalhes, veja a seção sobre segurança mais adiante.
Alguns campos de cabeçalho aplicam-se diretamente ao corpo da mensagem e fazem parte do cabeça-
lho de entidade:
►Content-Type (p. ex.: Content-Type: application/sdp): isso descreve o tipo de mídia do conteúdo do
corpo da mensagem. No exemplo, o corpo da mensagem contem uma descrição de sessão usando o
protocolo IETF SDP. Um outro exemplo é TEXT/HTRML;
►Content-length: o número de octetos do corpo da mensagem.
20
Figura 3.4 – O campo Via
21
Pedidos SIP
Os pedidos SIP (ver figura 3.5) são enviados do terminal cliente para o terminal servidor. Há vários
métodos para ser fazer isso:
Figura 3.5 – O campo Via
►ACK: um pedido ACK é enviado pelo cliente para confirmar que ele recebeu uma resposta final do
servidor, como 200 OK;
►BYE: um pedido BYE é enviado pelo agente de origem ou pelo agente de destino para interromper
uma chamada;
►CANCEL: um pedido CANCEL pode ser enviado para interromper um pedido que foi enviado
anteriormente enquanto o servidor ainda não tiver enviado uma resposta final;
►INVITE: o pedido INVITE é usado para iniciar uma chamada;
►OPTIONS: um cliente envia um pedido OPTION ao servidor para saber suas capacidades. O ser-
vidor envia de volta uma lista com os métodos que ele suporta. Em alguns casos, ele também pode
responder com o conjunto de capacidades do usuário mencionado na URL (Uniform Resource Locator)
e como ele teria respondido a cum INVITE;
►REGISTER: clientes podem registrar sua localização atual (um ou mais endereços) com o pedido
REGISTER. Um servidor SIP capaz de aceitar uma mensagem REGISTER é chamado de REGIS-
TRAR.
22
Além dos campos do cabeçalho geral, os pedidos podem transportar campos no cabeçalho pedido:
►ACCEPT (p. ex.: Accept: application/sdp, text/html): esse cabeçalho opcional indica quais tipos de
mídia são aceitáveis na resposta. A sintaxe é especificada no RFC 1288;
►ACCEPT-LANGUAGE (p. ex.: Accept-Langague: fr, en-gb; q=0.8, en; q=0.7): isso indica as línguas
preferidas do originador da chamada. A sintaxe é especificada no RFC 1288;
►EXPIRES – INVITE e REGISTER - (p. ex.: Expires: Thu, 01 Dec 2000 16:00:00 GMT ou Expires:
in 5 seconds): para uma mensagem REGISTER, esse campo de cabeçalho indica por quanto tempo o
registro será válido. O REGISTER pode diminuir o valor desejado em sua resposta. Para uma mensa-
gem INVITE, isso pode ser usado para limitar a duração de buscas;
►PRIORITY (p. ex.: Priotiry: emergency): os valores são os do RFC 2076, mais EMERGENCY;
►RECORD-ROUTE – também um campo de cabeçalho de resposta - (p. ex.: Record-Router:

sip:acd.support.com; maddr=192.190.123.234, sip:billing.netcentrex.net; maddr=192.194.126.23): al-
guns proxies podem adicionar/atualizar esse campo de cabeçalho, se eles quiserem estar no caminho de
todas as mensagens de sinalização. No exemplo, o pedido atravessou um proxy de tarifação e então um
ACD (DAC). Essas entidades precisam monitorar o estado das chamadas para que possam trabalhar
adequadamente. O servidor de tarifação, por exemplo, poderia controlar um FIREWALL para forçar a
politica de tarifação;
►SUBJECT (p. ex.: Subject: ‘Conference call on the SIP chapter’): isso é um texto livre que deveria
fornecer alguma informação sobre a natureza da chamada.
Respostas SIP
Um servidor SIP responde a um pedido SIP com uma ou mais respostas SIP. A maioria das respostas
(2XX, 3XX, 4XX, 5XX e 6XX) são respostas finais e finalizam a transação SIP. As respostas 1XX são
provisórias e não finalizam a transação SIP.
A primeira linha de uma reposta SIP sempre contém um código de status e uma frase de justificativa
inelegível por pessoas. A maior parte da seção de cabeçalho é copiada a partir da mensagem de pedido
original. Dependendo do código de status, pode haver campos de cabeçalho adicionais e parte dos dados
de resposta pode estar vazia, ou ela pode conter dados SDP ou texto explicativo (ver figura 3.6).
23
Figura 3.6 – O formato da resposta SIP
Até agora foram definidas seis categorias de códigos de status, dependendo do primeiro digito, como
mostrado na Tabela 3.1.
Essa classificação torna mais fácil adicionar novos códigos de status. Quando um terminal antigo não
entende um novo código CXX, ele deve trata-lo como um código C00.
Assim, até mesmo terminais antigos serão capazes de reagir de maneira inteligente quando se depararem
com códigos de status desconhecidos. Esses terminais também podem dar algumas informações adicio-
nais ao usuário se uma frase de justificativa estiver presente.
24
Tabela 3.1 – As seis categorias de códigos de status
25
Capítulo 4
Session Description Protocol – SDP

Sintaxe de descrição de sessão, SDP
O SIP usa o protocolo de descrição de sessão (Session Description Protocol – SDP) especificado no
RFC 2237. O SDP também é um produto do grupo de trabalho MMUSIC e é muito usado atualmente
no contexto do MBONE, a rede de comunicação multicast que funciona na INTERNET.
Para ser capaz de receber uma sessão MBONE, o receptor precisa saber:
• Qual endereço multicast será usado pela sessão;
• Qual será a porta de destino UDP;
• Os codificadores de áudio e/ou vídeo que serão usados (PCMA, H.261 etc.);
• Algumas informações sobre a sessão (nome, breve descrição);
• Informação para contato;
• Programa de atividades.
O objetivo principal do SDP é definir uma sintaxe padrão para esse tipo de informação.
A descrição de sessão SDP pode ser transportada usando-se uma variedade de métodos de transporte,
dependendo do contexto:
• O protocolo de anuncio de sessão (Session Announcement Protocol – SAP) no MBONE;

• O protocolo de fluxo em tempo real (Real-Time Streaming Protocol – RTSP) para aplicações
baseadas em fluxos (streaming);
• O SIP para configurar comunicações ponto a ponto e multiponto.
O SDP é um protocolo em formato legível por pessoas, que consiste em varias linhas <type>=<value>
terminadas por um CRLF. Os nomes dos campos e os atributos usam caracteres US-ASCII, mas cam-
pos de texto livres podem ser encontrados uma vez que o SIP usa o conjunto completo de caracteres
ISO 10646. Essa filosofia, ao contrário de condições binarias como o ASN-1 PER, facilita a programa-
ção e a depuração, ao custo do uso de uma maior largura de faixa. No entanto, a largura de faixa
usada por um protocolo de sinalização é desprezível comparada com os fluxos de mídias reais, de
maneira que a relação custo-benefício é muito boa.
A descrição de sessão é estruturada em uma seção que se aplica à sessão toda (começando com v=...) e
varia seções de descrição de mídia (cada uma começando com m=...). Os parâmetros nas seções de mídia
podem suprimir os parâmetros padrões de seção do nível de sessão. A Tabela 4.1 descreve os vários
tipos de campos definidos pela RFC 2237 para cada seção.
26
Tabela 4.1 A – Tipos de campos descritos por RFC 2237
27
Tabela 4.1 B – Tipos de campos descritos por RFC 2237 (continuação)
28
Tipos de payload dinâmicos e estático
Sob um determinado perfil, alguns tipos de PAYLOAD RTP são estáticos, isto é, seu significado é
completamente definido no perfil (por exemplo, RTP/AVP 0 é o PCMU (µ-law) 64 Kbit/s). Outros
tipos de PAYLOAD RTP têm um significado somente em associação com uma sessão em particular
descrita no SDP. Estes são tipos de PAYLOAD dinâmicos. O RFC do SDP fornece o exemplo do
áudio estéreo com codificação linear de 16 bits amostrado a 16 Khz. Não há nenhum tipo de PAYLOAD
definido que corresponderia exatamente a isso. Em vez disso, usaremos um número arbitrário para o
tipo de PAYLOAD, digamos 98 (m=vídeo 49232 RTP/AVP 98) e descreveremos o formato dos dados
transportados no SDP:
a=rtpmap:98 L16/16000/2
O formato é a=rtpmap:<tipo do payload><nome da codificação>/<taxa do clock>[/parâme-

tros de codificação>] que, no nosso caso, traduz-se em 16 linear, amostragem a 16000 Hz, dois canais.
Por extensão, o termo tipo de PAYLOAD dinâmico se aplica a qualquer fluxo RTP para o qual as
características de codificação de mídia são transportadas fora da banda (p. ex.: por meio de uma mensa-
gem H.245 OpenLogicalChannel).
29
Capítulo 5
Serviços avançados com SIP

Entidades SIP
Sem quaisquer extensões, o SIP permite muitas características para tratamento das chamadas – a maioria
dos serviços telefônicos comuns podem ser implementados com REGISTRARs, proxies e servidores de
redirecionamento SIP.
REGISTRAR - REGISTER
Um REGISTRAR é um servidor que aceita pedidos REGISTER. O mesmo servidor também pode
implementar outras funções SIP (p. ex.: servir como um proxy). Os REGISTRARs são necessários
para manter-se informado da localização atual de um usuário. O endereço IP de um usuário pode mudar
sob várias circunstancias – conexão por meio de um provedor de INTERNET que fornece endereços
dinâmicos, conexão em uma LAN que fornece endereços via DHCP ou um usuário móvel. Para ser
capaz de alcançar esse usuário a partir de seu endereço SIP, uma entidade na rede SIP precisa manter o
mapeamento entre endereços SIP e endereços IP. Este é o objetivo do REGISTRAR.
Para facilitar a mobilidade do usuário e evitar ao máximo configurações manuais, o SIP define um en-
dereço bem conhecido ALL SIP SERVERS (sip.mcast.net:224.0.1.75). Um cliente pode registrar seu
endereço IP atual com uma mensagem REGISTER multicast (ver figura 5.1). Por alguma razão, o SIP
restringe o TTL (Time To Live) dessa mensagem a 1, limitado o método de descoberta à sub-rede local.
30
Figura 5.1 – Registro MultiCast
Essa característica é aproximadamente equivalente ao método de descoberta do GATEKEEPER des-

crito no H.323. No entanto, no H.323, os GATEKEEPERs que estão querendo tratar o pedido podem
responder, permitindo ao cliente selecionar o GATEKEEPER apropriado e contacta-lo diretamente
mais tarde. No momento, os servidores SIP não podem responder a uma mensagem REGISTER mul-
ticast, portanto, o cliente não tem a oportunidade de apreender o endereço do servidor SIP apropriado
ou até mesmo de saber se existe um servidor SIP que aceitou o REGISTER (registro).
O REGISTRAR também pode ser contactado por unicast se o endereço do REGISTRAR for co-
nhecido. Nesse caso, o procedimento é o mesmo que para qualquer outro pedido SIP. O estado regis-
trado não é permanente. Se não for atualizado, ele expirará após uma hora (esse valor padrão pode mudar
como especificado no campo de cabeçalho EXPIRES). Para manter o REGISTER (registro), um ter-
minal precisa enviar menagens de atualização periodicamente. Se o terminal (ou usuário) se move e
desejar modificar os parâmetros do REGISTER (registro), ele pode cancelar um REGISTER (registro)
existente enviando um valor de contato ‘*’ e, então, enviar um novo REGISTER (registro, ver figura
5.2).
31
Figura 5.2 – Carga de registro
Proxy
Um servidor PROXY age como servidor por um lado (recebendo pedidos) e como cliente pelo outro
lado (possivelmente enviando pedidos) (ver figura 5.3). Um proxy pode passar adiante um pedido sem
nenhuma mudança para seu destino final ou pode mudar alguns parâmetros antes de passar o pedido.
Ele pode até mesmo decidir enviar uma resposta gerada localmente.
Figura 5.3 – Carga de registro
32
Os cabeçalhos VIA e RECORD ROUTE
Um pedido de A para B pode ser roteado por meio de vários proxies. É desejável forçar a(s) resposta(s)
a esse pedido seguir o mesmo caminho de volta. Por exemplo, um proxy pode estar tarifando a chamada,
ou controlando um firewall, e precisa ter acesso a todas as informações referentes à chamada.
Quando uma conexão TCP é usada para uma transação SIP, isso geralmente não é um problema – a
resposta a um pedido volta automaticamente para a outra ponta TCP porque o TCP mantém um con-
texto ao longo de toda a conexão. Por outro lado, quando o UDP é usado, algumas informações devem
estar presentes no datagrama de pedido para que o receptor possa saber para onde enviar a resposta.
Como o SIP é um protocolo independente, todos os pedidos e respostas SIP contêm cabeçalhos VIA
para esse fim. Isso ajuda a evitar laços (loops) de roteamento (cada proxy verifica se ele já está na lista
VIA). Toda vez que um proxy SIP passa um pedido adiante, ele adiciona seu nome à lista de proxies
gravada nos cabeçalhos VIA. Quando um proxy repassa uma resposta, ele inverte o processo e remove
seu nome da lista. Detalhes adicionais a respeito do uso de mensagens VIA podem ser encontrados na
seção sobre mensagens mais adiante.
Se não apenas os pedidos e repostas, mas também todos os pedidos devem ser roteados ao longo do
mesmo caminho, o cabeçalho VIA não é suficiente e os proxies tem de usar o cabeçalho RECORD
ROUTE. Isso ocorre porque os clientes SIP podem adicionar um campo de cabeçalho CONTACT
que permite que os servidores lhes enviem pedidos (p. ex.: pedidos BYE) diretamente, portanto, não se
pode garantir que os proxies estejam no caminho de todos os pedidos. Quando os proxies atualizam o
cabeçalho RECORD ROUTE, eles inserem sua URL SIP, com um parâmetro MADDR, na primeira
posição da lista.
Quando os proxies SIP são usados para rotear mensagens de sinalização, o modelo de chamada é seme-
lhante ao modelo de chamada roteado por GATEKEEPER do H.323, exceto que as mensagens SIP
contem informações suficientes para permitir a construção de proxies sem-estado (stateless)(no entanto,
nem todas as funcionalidades podem ser implementadas em um proxy desse tipo – proxies de contabi-
lidade/tarifação, por exemplo, precisariam manter-se a par de todas as mensagens e estados de comuni-
cação para verificar a coerência da sinalização).
Proxies de Bifurcação
Proxies de Bifurcação (Forking Proxies) podem duplicar um pedido e enviar copias dele a várias
máquinas, permitindo que elas possam ser usadas para tentar contactar vários pontos finais pertencentes
à mesma pessoa. Elas não são transparentes e filtram algumas respostas antes de repassá-las de volta ao
cliente. O pseudocódigo complete de um Proxy de Bifurcação é descrito no documento preliminar do
SIP.
Os Proxies de Bifurcação podem fazer com que algumas máquinas recebam cópias duplicadas do
mesmo pedido com o mesmo CaLLID, mas elas têm de responder a cada pedido.
33
Servidor de Redirecionamento
Um servidor de redirecionamento responde a um pedido INVITE com uma resposta 3XX (ou recusa a
chamada com um erro de cliente ou um erro de servidor).
►A RESPOSTA 300 (múltiplas escolhas) pode ser usada quando a URL SIP do INVITE puder ser
contactada em vários endereços alternativos. As escolhas são relacionadas como campos de contato.
Como exemplo, o campo de contato retornado poderia ser: Contact: sip:john_gsm@com-
pany.com,sip:john_home@family.org;
►A RESPOSTA 301 (movido permanentemente) indica que a URL SIP não pode mais ser contactada
nessa localização. O cliente deve tentar contactar a nova localização fornecida no campo de cabeçalho
CONTACT da resposta. Essa mudança é permanente e poder ser memorizada pelo cliente. O cabeçalho
CONTACT também pode mencionar vários destinos possíveis;
►A RESPOSTA 302 (movido temporariamente) redireciona o cliente para uma nova localização, como
anteriormente, mas por tempo limitado, como indicado no campo EXPIRES;
►A RESPOSTA 380 (serviço alternativo) é mais complexa e pode parecer um pouco redundante em
relação às respostas anteriores. Além de fornecer um novo destino no campo CONTACT, a resposta
também pode conter uma descrição de sessão no corpo da mensagem que representa as capacidades de
envio do novo destino. Espera-se que o originador da chamada envie um pedido INVITE a esse novo
destino e ofereça em sua descrição de sessão SDP as capacidades apropriadas (uma cópia dos parâmetros
SDP da resposta 380, exceto para as portas receptoras RTP).
Outras respostas (303, 305) foram definidas em documentos preliminares SIP primitivos, mas se torna-
ram obsoletas. Um servidor de redirecionamento pode ser usado em conjunção com um REGISTRAR
para redirecionar chamadas para a localização atual do originador da chamada. Ele também pode atuar
como uma forma primitiva do sistema de distribuição de chamadas, como mostrado na figura 5.3.
Um servidor de redirecionamento pode ser uma ferramenta útil para melhorar a escalabilidade de
servidores de distribuição de chamadas ou servidores agentes de chamadas. Inserido como um
FRONT END, ele pode distribuir chamadas entre um grupo de servidores secundários, alcançando
equilíbrio de carga. Isso é permitido pelo parâmetro MADDR do campo CONTACT:
<sip:originaladdress@callcenter.com:999;maddr=sophisticatedACD3.callcenter.com>
Retornando a isso, o servidor de redirecionamento indica que o originador da chamada deve enviar um
INVITE com o mesmo destino (originaladdress@callcenter.com), mas ao terceiro servidor ACD do
grupo (ACD3.callcenter.com). O parâmetro MADDR instrui o originador da chamada a desviar do
procedimento normal para encontrar o servidor SIP apropriado a partir da parte da URL referente ao
domínio e então usar o nome do domínio fornecido.
A funcionalidade de servidor de redirecionamento é semelhante ao papel desempenhado pelo GATE-

KEEPER H.323 quando se usa o modelo de chamada direta.
34
Figura 5.4 – Um servidor de redirecionamento usado com sistema de distribuição de chamadas
Capítulo 6
Localização e mobilidade do usuário
Localização usuários: endereços SIP
Os endereços SIP são URLs (Uniform Resource Locators). As URLs são de fato nomes (com exceção
dos endereços SIP que usam o endereço de um host IP, como o endereço usado no nosso exemplo
simples de chamada); elas não se referem ao endereço de transporte a ser chamado, mas, sim, a uma
entidade abstrata que pode ser um usuário ou um servidor multimidia. O documento preliminar SIP
especifica que o formato geral das URLs SIP é user@host. Na verdade, a parte host também pode ser
um nome de domínio. Opcionalmente, uma URL SIP pode conter um numero de porta (veja a Tabela
6.1).
35
Tabela 6.1 – URLs SIP válidas
Em muitos casos, o endereço SIP de um usuário será o mesmo que seu endereço de e-mail. A maioria
das extensões (cabeçalhos, maddr etc.) não são permitidas nos parâmetros TO e FROM dos pedidos e
respostas SIP, mas podem ser usadas nos parâmetros CONTACT. O SIP define uma forma de localizar
o ponto final físico a partir do nome (também chamado URL SIP). Isso é feito em dois estágios.
►Primeiro a URL SIP permite ao originador da chamada localizar um servidor SIP. Esse servidor SIP
será o destino da mensagem INVITE inicial. O servidor SIP pode ser o destino final da chamada; se
não for, ele deve saber o endereço de transporte do ponto de destino da chamada;
►Se o servidor SIP não for o destino final da chamada, ele vai redirecionar o pedido INVITE para o
ponto de destino da chamada. Isso pode ser feito instruindo-se o ponto de destino da chamada a enviar
um novo pedido INVITE a uma outra localização usando a resposta 302 (movido) ou repassando de
maneira transparente a mensagem INVITE ao endereço de transporte apropriado. O primeiro modelo
é semelhante ao modelo de chamada direta do H.323, o segundo é semelhante ao modelo de chamada
roteado por GATEKEEPER do H.323.
Para localizar um servidor SIP, um terminal SIP usará DNS (ver figura 6.1). Um nome de domínio de
uma URL SIP deve ter um registro SRV, um registro MX e um registro CNAME ou A.
Primeiro, o terminal vai recuperar os registros de recurso SRV para o nome de domínio considerado.
Depois ele guardara apenas os registros do tipo sip.udp ou sip.tcp. Se houver um registro sip.udp, o
terminal vai contactar o servidor SIP usando UDP nos endereços de transporte especificados. Ele usara
a porta especificada na URL SIP ou o padrão para a porta especificada no REGISTER (registro)
sip.udp. Se houver um registro sip.tcp, o mesmo método será usado, mas sobre TCP. Se nenhum
registro SRV for encontrado, o terminal tentara obter o endereço IP de um servidor SIP olhando
primeiro nos registros MX (normalmente usados para apontar para um servidor de e-mail), depois nos
registros CNAME (apontando para uma alias) e, finalmente, em um registro A (apontando para um
endereço IP).
36
Figura 6.1 – Localizando o servidor SIP
Apontar para um servidor SIP em vez de apontar o ponto de destino da chamada diretamente permite
que este se mude (o endereço de transporte muda), ao passo que permite algum esquema de cache. Se o
endereço do ponto de destino da chamada estiver armazenado diretamente do DNS, poderá haver mui-
tos problemas com o cache do DNS. Normalmente todos os registros DNS podem ser armazenados
em cache pelo resolvedor DNS. O registro no cache expira após TTL segundos. O valor de TTL é
armazenado no registro DNS. Portanto, quando o terminal mudar de lugar, o originador da chamada
ainda poderia ter um endereço errado no cache do resolvedor DNS e a chamada falharia. A única solução
é colocar o valor de TTL em zero e atualizar o registro primário de DNS quando o terminal se mudar
- não muito fácil.
Por outro lado, é improvável que o servidor SIP se mude com muita frequência e armazenar seu ende-
reço em um registro DNS SRV, MX ou A não causa nenhum problema. O servidor SIP é notificado
sobre a localização atual do terminal de destino da chamada e pode redirecionar o pedido INVITE para
a localização apropriada.
37
Agentes de chamada
Um agente de chamada é um serviço que trata chamadas que chegam e/ou saem em nome de um
usuário. Na telefonia tradicional, esse tipo de função é executado pela infraestrutura de rede inteligente
da operadora ou pelo PBX (Private Branch Exchange) da empresa. O conceito de agente de chamada
foi introduzido na área de Telefonia IP (Telephony Over Internet Protocol – ToIP) na descrição de
um Agente de Gerenciamento de Chamada (Call Management Agent – CMA) feita por Scott Pe-
track.
Um agente de chamada pode realizar as seguintes tarefas:

• Tentar encontrar o usuário por meio do redirecionamento das mensagens de configuração da
chamada (SIP INVITE ou H.323 SETUP) para a localização apropriada ou várias localiza-
ções possíveis simultaneamente;
• Implementar regras de redirecionamento de camada como repasse de chamada (Call For-
warding) em caso de ocupado, repasse de chamada em caso de ausência de resposta, repasse
de chamada incondicional;
• Implementar filtragem de chamadas com regras dependentes da Origem (SOURCE)/Tempo
(TIMING);
• Gravar tentativas de chamada malsucedidas (Renunciations – Renitências) para referências
futuras;
• Executar qualquer outra tarefa de gerenciamento de chamada em nome do usuário.
Todas essas funções podem ser executadas pelo Proxy SIP. Características simples de redirecionamento
de chamada e de filtragem (repasse de chamada incondicional, filtragem dependente da Origem
(SOURCE)/Tempo (TIMING)) também podem ser implementadas em um servidor SIP de redireci-
onamento. O servidor Proxy SIP é o que oferece a maior flexibilidade, uma vez que ele pode escolher
retransmitir toda a sinalização de chamada e, portanto, monitorar e controlar todos os aspectos da cha-
mada. Para ser capaz de usar esses serviços, o usuário deve forçar todas as tentativas de chamada que
chegam em direção ao Proxy SIP apropriado. O melhor modo de se fazer isso é configurar o registro
DNS SRV de maneira a apontar para o servidor Proxy SIP.
Na figura 6.2 mostramos um repasse de chamada em caso de ausência de resposta. Observe que, se John
não estiver com sessão aberta na mesa 1 e o proxy também atuar como um REGISTRAR, o redirecio-
namento pode ser imediato se o registro de John tiver expirado.
O agente de chamada também pode ser uma funcionalidade do software do usuário final, mas isso ge-
ralmente é menos pratico que usar um servidor proxy centralizado separado, uma vez que a estação de
trabalho do usuário final pode ser desligada a qualquer instante e pode ter um endereço IP dinâmico.
38
Figura 6.2 – Um repasse de chamada (Call Forward) em caso de ausência de resposta
Acessando o BANDO DE DADOS! (banco de dados), de um REGISTRAR, um Proxy SIP pode

solucionar a maioria dos problemas de mobilidade/mudança de endereço se os terminais dos usuários
finais estiverem configurados para usar registros dinâmicos (isto é, não permanentes) Por exemplo, toda
vez que um usuário se conecta à Internet por meio de um provedor, ele recebe um novo endereço IP.
Mas se seu software SIP registrar esse novo endereço IP, o proxy será capaz de retransmitir todas as
chamadas para o novo endereço IP.
Atendimento direcionado e outros serviços avançados
Alguns PBXs permitem serviços sofisticados como discagem preditiva (automação das chamadas a par-
tir de um bando de dados, para serviços de pesquisa de opinião) DIRECTED PICKUP (Atendimento
Direcionado – a capacidade de responder a uma chamada que está tocando em uma extensão, a partir
de um terminal local) ou distribuição automática de chamadas com PARKING (distribuição das cha-
madas que chegam usando uma QUEUE ou ACD/DAC).
No documento preliminar SIP original faltam alguns dos elementos de protocolo necessários para su-
portar alguns desses serviços e não há explicações detalhadas de como implementá-los. Um outro tra-
balho em andamento (draft-ietf-mmusic-sip-cc-00.txt – SIP CALL CONTROL SERVICES) de-
fine um conjunto de extensões para o protocolo básico (org.ietf.sip.call). Nem todas as entidades SIP
39
suportarão essas extensões, portanto, um cliente que planeja usá-las deve incluir um campo REQUIRE
para org.ietf.sip.call. Esse documento preliminar ainda está em seu estágio inicial e até agora contém:
• Uma lista de serviços avançados de telefonia e diretrizes de como fornece-los com o SIP. É um
tipo de lista de itens desejados que provavelmente evoluirá para um guia de implementação;
• Extensões (e campos de cabeçalho tipo REPLACE) que permitem ao cliente instruir o servidor
a enviar um INVITE ou um BYE a terceiros. Isso permite ao cliente estabelecer e cancelar
conferencias com muitas conexões e facilita a implementação de aplicações de discagem preditiva;
• Extensões para o cabeçalho de localização, para descrever melhor o destino, por exemplo, uma
etiqueta de serviço que permite a uma localização ser identificada como um FAX (abreviaturas
do termo latino facsimile e telefacsimile), um Telefone IP, uma RTPC (Rede pública de telefo-
nia comutada), um telefone POTS (Plain Old Telephone Service – Serviço Telefônico Simples e
Antigo), um telefone ISDN (Integrated Service Digital Network – Rede Digital de Serviços Inte-
grados) ou um PAGER (paging).
Conferências com diversos participantes
O SIP pode ser usado para estabelecer conferencias multiponto (lembre-se de que esse protocolo vem
do grupo MMUSIC). No entanto, o SIP não fornece nenhuma maneira de controle de base (floor con-
trol) até o momento.
Conferências MultiCast
Uma conferência MultiCast é aquela na qual os fluxos de mídia são enviados usando-se MultiCast. A
sinalização referente a essa conferencia pode ser enviada usando-se Multi-UniCast ou MultiCast (ver
figura 6.3).
Figura 6.3 – Multi-UniCast versus MultiCast
No caso de sinalização Multi-UniCast, não há nenhuma diferença significativa em relação ao caso fim
a fim, exceto que as descrições de sessão SDP indicam endereços MultiCast.
No caso de sinalização Multi-UniCast, não há nenhuma diferença significativa em relação ao caso fim
a fim, exceto que as descrições de sessão SDP indicam endereços MultiCast.
Quando sinalização MultiCast é usada para estabelecer conferências com diversos participantes, os pe-
didos SIP são transportados usando-se UDP, pois este é o único protocolo de transporte que pode
40
suportar MultiCast sobre IP. Espera-se que os pedidos MultiCast sejam usados principalmente para
configurar chamadas em conferencias, portanto, a URL seja usada principalmente para configurar cha-
madas em conferências em vez de um indivíduo, por exemplo, para buscas MultiCast. As respostas a
um pedido SIP são então enviadas de volta à porta UDP que enviou o pedido no mesmo endereço
MultiCast. Para reduzir o trafego na rede e evitar uma possível tempestade de respostas sincronizadas,
existem algumas modificações em relação ao procedimento de convite Multi-UniCast, incluindo:
• 2XX não são enviados;
• Respostas 6XX só serão enviadas se a URL de destino corresponder ao nome de um usuário
naquela máquina (isto é, o pedido é uma busca MultiCast em vez de um convite para uma confe-
rência com diversos participantes);
• As respostas são enviadas após um atraso aleatório que vai de 0 a 1 segundo.
Se todas as mensagens, INVITE, forem enviadas a partir de uma entidade central em UniCast, essa
entidade poderá fornecer uma maneira simples de controle de base (floor control) enviando novas men-
sagens INVITE com o parâmetro ‘c’ colocado em nulo ‘0.0.0.0’ para silenciar um ponto final (esse uso
do SDP é uma convenção descrita no documento preliminar SIP) e reconvidá-lo mais tarde (parâmetro
‘c’ não nulo) quando for permitido entrar na conferência.
O SIP suporta de maneira nativa codificações em camadas. Essa classe de codificadores codifica as
informações de mídia usando vários fluxos de dados simultâneos. Um fluxo contém informações básicas
(apenas o suficiente para fornecer um sinal de baixa qualidade) e os demais fluxos incluem informações
adicionais que podem ser usadas para reconstruir o sinal com uma maior qualidade, por exemplo, um
codificador de vídeo poderia enviar intraquadros em um canal e quadros delta em outro. Assim, um
receptor pode escolher a melhor relação entre largura de banda/qualidade optando por receber um, dois
ou mais fluxos de dados. Isto é especificamente adequado para conferência MultiCast, permitindo que
todos os receptores sintonizem a recepção de acordo com suas melhores configurações, ao mesmo
tempo que liberar o transmissor de ter de enviar fluxos de dados personalizados para cada receptor. O
SIP descreve um fluxo codificado em camadas como:
c=<endereço multicast base>/<ttl>/<número de endereços>
Por exemplo: c=IN IP4 224.2.1.1/127/3. Os endereços MultiCast usados precisam ser contínuos
(224.2.1.1, 224.2.1.2, 224.2.1.3).
Conferências Multi-UniCast
O suporte do SIP a conferências Multi-UniCast é limitado. Uma entidade central pode ser configu-
rada para atuar como um MCU para misturar ou comutar os fluxos de mídia que chegam (ver a figura
6.4). A única maneira de suportar comutação adequada de mídia atualmente seria enviar um INVITE
SIP com o parâmetro SDP ‘c’ colocado em zero (0.0.0.0), uma vez que isto sinalizará o transmissor para
parar a transmissão (mute) e reativará a transmissão quando o locutor se tornar ativo novamente (isto
deve começar com um intraquadros) enviando um parâmetro ‘c’ não nulo.
Isso ainda não é trivial porque os codificadores de vídeo H26X enviam quadros completos apenas de
tempos em tempos e quadros delta entre elas. Na maior parte do tempo, o instante em que um partici-
pante decide falar não coincidirá com o envio de um quadro completo.
41
Figura 6.4 – Um MCU de comutação muito simples
Portanto, se o MCU simplesmente copiar o fluxo de vídeo que chega para o fluxo de vídeo que chega
para o fluxo de saída, os receptores terão de esperar pelo próximo quadro completo para obter uma
imagem. Assim, o MCU teria de recodificar completamente o fluxo para poder enviar um quadro com-
pleto quando o vídeo comutar. Na pratica, isso consumiria muita CPU e seria bastante ineficiente.
Em um caso semelhante, o H.323 pode suspender o fluxo de vídeo de locutores não ativos e solicitar
um quadro completo quando ele comutar para um locutor ativo (mensagem VideoFastUpdate) O SIP
não fornece nenhuma sinalização específica para isso, mas um pacote RTCP FIR (Full Intra Request)
poderia servir para esse propósito.
Conferência Ad-Hoc
O SIP fornece uma maneira simples e elegante para se comutar de uma chamada fim a fim existente (A-
B) para uma conferência com diversos participantes (A-B-C). A pessoa (p. ex.: A) que deseja convidar
um novo participante para a conferência envia uma mensagem INVITE à outra parte (B) e ao novo
participante (C), com os parâmetros para a nova sessão (isto é, um endereço MultiCast e, por fim, novos
codificadores em vez de um endereço UniCast), mas mantém o antigo CallID. Manter o mesmo CallID
informa a (B) que isso não é uma nova chamada, mas, sim, novos parâmetros para a chamada existente.
Esse método também pode ser usado para mudar parâmetros em uma sessão existente.
Configurando o tratamento de chamadas com base em rede
Características para o tratamento de chamadas podem ser instaladas em um PROXY/REGISTRAR

usando simplesmente mensagens REGISTER. Por exemplo um usuário que deseja redirecionar tem-
porariamente sua linha telefônica para uma outra extensão apenas envia um pedido REGISTER com
o seu nome (ou extensão regular) no campo de cabeçalho TO e a nova extensão no campo de cabeçalho
CONTACT, com o valor EXPIRES apropriado. Isso é aproximadamente equivalente ao serviço ofe-
recido pelo H.450.3.
42
Recursos mais sofisticados para o tratamento de chamadas (como agentes de chamadas) estão fora do
escopo do SIP e provavelmente serão configurados usando-se outros protocolos, como o HTTP. Os
Endpoints (pontos finais) SIP provavelmente serão PCs multimidias e o navegador Web é uma in-
terface perfeita para personalizar o comportamento de um proxy sofisticado.
Tarifando as chamadas SIP
Por definição, todos os participantes convidados por uma fonte comum estão na mesma chamada
SIP. Essa chamada é identificada por um CallID globalmente único. Com essa definição, uma confe-
rência com diversos participantes (conhecida como sessão multimidia em termos SIP) pode ser com-
posta de várias chamadas SIP – cada usuários que chamou o controlador multiponto diretamente tem
um único CallID.
Dentro de uma chamada podem existir várias CALL LEGs (chamadas ativas entre apenas dois usuá-
rios), sendo que cada LEG pode ser identificada por uma combinação dos campos TO, FROM e Cal-
lID. Todas as LEGs podem ser agrupadas em uma sessão multimidia comum usando a descrição de
sessão.
Na RTPC, uma chamada geralmente é paga pela pessoa que a inicia. Um proxy que retransmite toda a
sinalização a partir do terminal de um usuário pode criar registros apropriados para contabilidade arma-
zenando os pedidos INVITE, CANCEL e BYE, bem como as respostas. A duração de cada LEG
pode ser deduzida a partir do primeiro pedido INVITE aceito até o primeiro pedido BYE.
Para forçar o usuário a usar o proxy, uma maneira conveniente, como descrito na figura 6.5, é controlar
um firewall na rede a partir do proxy. Isso impede o usuário de tentar evitar que um recurso do proxy
contabilize as chamadas.
Figura 6.5 – Contabilidade de chamada no proxy
43
Formas de Tarifação em Telefonia IP
Muitas pessoas contestam o fato de as operadoras ITSP (Internet Telephony Service Provider) e PSTN
(Public Switched Telephone Network), fazer uso da terceira casa decimal para tarifação (assim como
postos de combustíveis), só que a prática é legal, pois a regulamentação para a terceira casa depois da
vírgula está presente em portaria tanto da ANATEL (Agência Nacional de Telecomunicações) quando
da ANP (Agência Nacional do Petróleo) criada ainda sob a vigência do Plano Real, em 1994. As portarias
ainda preveem que o valor final não pode ser pago da mesma forma. Nesse caso, então, anula-se a última
casa. Por exemplo: se o valor da chamada somar R$ 2,187, o consumidor irá pagar R$ 2,18. Se o total
fosse registrado com duas unidades após a vírgula, o valor seria arredondado para R$ 2,20.
Sobre o tempo de tarifa: "s"
Exemplo: você determinou que custa R$ 1.000 real a tarifa em tempo "s", então ele vai tarifar por
segundo até completar o 1 real, portanto se nessa rota a pessoa falou 30 segundos, sua chamada custara
R$ 0,300 centavos de real, em modo "s".
Sobre o tempo de tarifa: "c"
Em modo "c" a tarifa será cobrada por chamada. Por exemplo a pessoa ligou e ficou 30 segundos, logo
será cobrado o valor do minuto inteiro. Por outro lado, ela pode ficar o tempo que quiser que vai só
custar R$ 1.000 real.
Sobre o tempo de tarifa: "m"
Em modo "m" será cobrado R$ 1.000 real, a cada minuto, se você permanecer por 5 minutos será
cobrado o valor de R$ 5,000 reais. E se forem 5 minutos e 10 segundos? Então sera cobrado 6.00 reais,
pois foram cobrados os minutos inteiros.
Sobre o tempo de tarifa: "1m+s"
Em modo "1m+s" o primeiro minuto será cobrado integral já no primeiro segundo, após o primeiro
minuto a tarifa será dividida por segundo. Por exemplo se você falou 1 minuto e 10 segundos será
cobrado R$ 1,100 reais.
Sobre o tempo de tarifa: "30s+s"
Em "30s+s" será cobrado metade do valor antes dos 30 segundos, após isso será cobrado o segundo.
Por exemplo a pessoa ficou 12 segundos será cobrado R$ 0.500 centavos de reais, a pessoa ficou 32
segundos será cobrado R$ 0.530 centavos de reais.
44
Sobre o tempo de tarifa: "30s+6s"
Em "30s+6s" será cobrado metade do valor antes dos 30 segundos após isso será cobrado o segundo.
Exemplo: 12 segundos na chamada, será cobrado R$ 0.500 centavos de reais, 32 segundos será cobrado
R$ 0.600 centavos de reais, neste modelo de tarifa, sempre vão ser arredondado para cima.
Capítulo 7
Segurança SIP
Segurança da mídia
A criptografia de mídia é especifica pelo SDP. O parâmetro k do SDP armazena o algoritmo de segurança
em uso bem como a chave. Os seguintes formatos são definidos no RFC 2327 (SDP).
► k=cler:<chave de criptografia>
Esse formato refere-se aos algoritmos de criptografia descritos no RFC 1890 (perfil RTP para confe-
rências de áudios e vídeo com controle mínimo, RFC 1890, janeiro de 1996). O RFC 1890 descreve
primeiro como extrair uma chave a partir de uma PASS PHRASE de uma forma padrão. A PASS
PHRASE é colocada em uma forma canônica (espaços em branco no início e no fim removidos, carac-
teres colocados em minúsculo etc.) e, então, dividida em 16 octetos pelo algoritmo MD5. Chaves com
menos de 128 bits são formadas truncando-se o sumario MD5. As chaves são extraídas em ordem para
os algoritmos que precisam de mais de uma (p. ex.: três chaves para DES triplo).
O nome do algoritmo em uso é inserido antes da chave e separado dela com uma única barra. Identifi-
cadores padrão para os algoritmos mais comuns pode ser encontrados no RFC 1423: DES-CBC, DES-
ECB; o padrão é DES-CBC. O RFC 1423 também descreve como armazenar parâmetros adicionais
necessários para determinados algoritmos, como o vetor de inicialização de 64 bits do DES-CBC, por
exemplo:
k=clear:DES-CBC/aZ25rYg7/12eR5t6y
► k=base64:<chave de criptografia codificada>
O formato é o mesmo que o anterior, mas o base64 é codificado para esconder caracteres não permitidos
pelo SDP.
► k=prompt
Solicita ao usuário uma chave. O algoritmo padrão é o DES-CBC.
45
Segurança na troca de mensagens
Se a chave de criptografia de mídia tiver de ser protegida, os pedidos e repostas SDP deverão ser crip-
tografados. Há diversas outras razões para proteger as mensagens SIP. Como esconder a origem e o
destino das chamadas e os campos de informação relacionados (SUBJECT etc.). As mensagens SIP
também podem ser autenticadas, o que é útil não apenas para evitar chamadas enganosas, mas também
para contabilidade e tarifação.
As mensagens SIP podem ser criptografadas a cada passo, usando, por exemplo, IPSEC (a estrutura de
segurança definida pelo grupo de trabalho do protocolo IP SECurity do IETF. O SIP também des-
creve uma estratégia de criptografia de fim a afim com base em uma chave secreta compartilhada entre
o remetente e o receptor ou em um mecanismo de chave pública. Se uma chave secreta comum a ambos
for usada, o receptor da mensagem será capaz de decriptografar a mensagem criptografada pelo reme-
tente. Se um esquema de chave pública for usado, o remetente criptografa a mensagem usando a chave
publica do receptor. A criptografia pode ser executada pelo remente do pedido ou por um proxy de
segurança intermediário.
► Pedidos
A linha de pedido e os cabeçalhos não criptografados são enviados primeiro e devem incluir um campo
de cabeçalho ENCRYPTION que indica ao método de criptografia em uso, por exemplo, Encryption:
PGP Version=2.6.2, Encoding=ascii.
A parte criptografada começa após a primeira linha vazia (CRLF da linha anterior imediatamente se-
guido por um CRLF). A figura 7.1, considerada do documento preliminar SIP, é um exemplo.
Se apenas o corpo da mensagem tiver de ser criptografado, uma linha vazia extra deverá ser inserida no
corpo antes da criptografia para evitar que o receptor confunda os dados do corpo da mensagem com
os cabeçalhos criptografados.
Existem problemas específicos com o cabeçalho VIA, uma vez que ele é usado por proxies para rotear
o pedido de volta para a fonte. O documento preliminar SIP descreve como substituir a informação
sensível VIA um índice que serve para a mesma finalidade sem revelar dados sensíveis.
► Respostas
O remetente do pedido também deve indicar qual chave deve ser usada para criptografar a resposta. Um
servidor SIP que recebe um pedido criptografado não deve, na sua resposta, enviar de maneira limpa
(não-criptografada) qualquer campo que foi crptofrafado anteriormente.
46
Figura 7.1 – Criptografia em um pedido
► Autenticação
Os pedidos e respostas SIP podem ser autenticados usando uma assinatura digital. O campo de cabeça-
lho AUTHORIZATION é usado para esse fim (veja a figura 7.2). Ele contém a assinatura:
• Da primeira linha (linha de pedido ou linha de status);
• De todos os cabeçalhos após o cabeçalho AUTHORIZATION;
• Do corpo da mensagem.
Essa semântica permite a exclusão de alguns campos variáveis (como o campo VIA) dos dados assina-
dos.
Figura 7.2 – Autenticação por meio do campo de cabeçalho Authorization
47
Firewall SIP
Os terminais SIP podem ser configurados para enviar todos os seus pedidos para um servidor proxy
SIP, em vez de tentar alcançar o servidor SIP apropriado usando registros DNS. O suporte nativo para
o NAT (ver a figura 7.3) por parte das entidades SIP permite a configuração de sinalização para comu-
nicações de saída sem nenhum requisito especifico no firewall. Mas, para os fluxos de mídia, o firewall
precisa estar ciente dos fluxos UDP que chegam, para repassa-los à entidade apropriada. As chamadas
que chegam precisam ser tratadas por um proxy de sinalização SIP do firewall.
Figura 7.3 – NAT
Nota sobre o NAT: O NAT (Network Address Translation) é uma técnica usada para segurança, bem
como para evitar problemas de re-endereçamento.
Capítulo 8
O SIP e o H.323
O que o SIP faz e o H.323 não faz
► Velocidade
A primeira coisa que impressiona quando você lê o documento preliminar SIP é a sua simplicidade. O
SIP faz em uma transação o que o H.323.v1 fez em quatro ou cinco trocas de mensagem, cada uma
delas especificada em documento ITU diferentes. Além disso, o SIP pode usar UDP, ao passo que o
H.323.v1 e 2 tem de usar o TCP. A combinação dessas diferenças resultou em um tempo de configura-
ção muito menor para os Endpoints (pontos finais) SIP. Isso inspirou diretamente algumas modifica-
ções introduzidas no H.323.v2, a saber, o procedimento FAST CONNECT e a capacidade de TU-
NELAR mensagens H.245 em mensagens Q.931. Outras melhorias estão a caminho, como a capaci-
dade de usar sinalização UDP.
► MultiCast
O IETF ganhou muita experiencia em MultiCast. Há milhares de usuários regulares do M-bone e cada
vez mais aplicações MultiCast. O SIP foi projetado para funcionar me Backbones com capacidade para
MultiCast, não apenas para os fluxos de mídia, como o H.323, mas também para as mensagens de
48
sinalização. Por exemplo, uma mensagem INVITE pode ser enviada para um grupo MultiCast. Isso é
útil para CALL CENTERs ou quando se quer encontrar uma pessoa em uma empresa. As versões 1 e
2 do H.323 precisam usar Multi-UniCast para o mesmo fim.
► Uso de URLs
O uso de URLs como identificadores é poderoso. À primeira vista pode parecer não haver grande dife-
rença entre um alias de e-mail H.323 (john@name.com) e uma URL SIP (sip:john@name.com). Na
verdade, há uma diferença: um alias de e-mail H.323 considera que o protocolo usado seja o H.323, ao
passo que o SIP o especifica o protocolo na URL. Por causa disso, um servidor SIP pode redirecionar
uma chamada para servidores não SIP de maneira bastante flexível. Um terminal SIP, quando recebe
uma chamada de um outro terminal SIP, pode redirecionar a chamada para uma página Web ou para
uma URL mailto. Isso facilita a integração de aplicações de áudio e vídeo com outras aplicações mul-
timídia.
Esse recurso agora está disponível com o tipo URL-ID do Alias Address no H.225v2, mas o esquema
global de nomes do H.225 está começando a parecer um pouco desordenado (h323-ID, URL-ID,
TRANSPORT-ID, EMAIL-ID, PARTYNUMBER).
► Priorização de chamadas
O campo de cabeçalho PRIORITY é um adicional útil que foi negligenciado no H.323. Muitos países
têm exigências legais para priorizar algumas linhas telefônicas.
► Codificação de texto
A codificação de texto é uma característica atrativa para uns e um problema para outros. Esta é uma das
muitas intermináveis guerras religiosas entre programadores. A codificação de texto tem muitas vanta-
gens – é simples, pode ser depurada facilmente usando-se simples SNIFFERS de rede e faz com que
problemas de interoperabilidade sejam detectáveis visualmente. A maioria dos programadores concor-
dam sobre esses recursos.
O problema pode ser desempenho e tamanho, como alguns sustentam que protocolos binários são mais
fáceis de codificar de decodificar. Obviamente o tamanho das mensagens de texto é muito maior que o
tamanho das mensagens codificadas em binário.
49
Capítulo 9
O H.323 e o SIP
O que o H.323 faz e o SIP não faz
► Canais lógicos
O H.323 faz uma distinção clara entre os tipos de mídia que podem ser enviados ou recebidos e as
combinações que podem ser válidas por um lado (capacidades) e os tipos de mídia que estão ativos e,
de fato, enviados para a rede (canais lógicos) por outro lado. O SIP não tem uma distinção como esta,
uma vez que os pontos finais SIP divulgam apenas os codificadores que eles podem receber e não há
nenhum procedimento para abrir uma conexão de mídia em separado do ato de efetivamente enviar a
mídia. Isso simplifica a sinalização e pode parecer uma vantagem à primeira vista.
No entanto, em alguns casos, especialmente quando se implementam servidores que fazem uso intensivo
de recursos, isso pode ser um problema, porque toda vez que o servidor divulga uma capacidade, ele
precisa criar um soquete de escuta. Ao contrário, um cliente H.323 precisa abrir um soquete apenas
quando ele recebe uma mensagem Open Logical Channel (se não estiver no modo Fast Start). Esse
comportamento do SIP pode resultar em vários soquetes inativos e como a maioria dos codificadores
de voz verem querendo enviar dados de mídia, a estratégia para fechar esses soquetes inativos não é
completamente trivial.
► Controle de conferências
O H.323, sozinho ou em combinação com o H.323, possui recursos poderosos para controle de confe-
rências. O SIP não foi projetado para o controle de conferência e, consequentemente, muitos dos recur-
sos necessários para fazer uma conferência controlada não existem (ainda).
► Codificação binária
As mensagens H.323 são codificadas de acordo com o Q.931 para o subconjunto de mensagens H.225
provenientes do Q.931. Todas as outras mensagens, bem como as extensões H.323 para mensagens
Q.931. Todas as outras mensagens, bem como as extensões (Packet Encoding Rules - PER) ASN.1
(Abstract Syntax Notation 1). Isso provavelmente gerou tanto interesse a respeito da complexidade do
H.323. O fato é que misturar dois métodos de codificação com regras totalmente diferentes não é a
melhor das ideias. Isso implica também grandes esforços de programação por parte das empresas que
ainda não têm uma implementação Q.931 e um compilador ASN.1.
Finalmente, depurar os problemas de interoperabilidade entre os terminais H.323 exige monitores de

rede com capacidades de decodificação tanto Q.931 quanto PER ASN.1. Existem alguns (um foi distri-
buído pela Microsoft aos membros do SG16 do ITU como uma parte das ferramentas.
50
Portanto, há de fato uma curva de aprendizado íngreme, mas uma vez que uma empresa tenha um
compilador ASN.1 e uma implementação Q,931, existem algumas vantagens em usar uma codificação
binária:
• Tamanho do PDU é otimizado;
• (talvez) o desempenho é melhor.
O tamanho dos PDUs de sinalização não é, em geral, um problema nas redes modernas. No entanto, se
o H.323 para o sistema móvel de terceira geração, UMTS), isso seria uma vantagem.
O desempenho é discutível no caso do H.323. É verdade que a maioria dos protocolos binários são
extremamente rápidos porque os programadores simplesmente mapeiam as estruturas C para os BUF-
FERS e vice-versa. Tanto o PER quanto o Q.931 são muito mais complexos que isso e o desempenho
depende da implementação.
► Descoberta de GATEKEEPERs
No estado atual do RFC SIP, a descoberta de GATEKMEEPERs MultiCast parece ser mais sólida
no H.323, permitindo que um terminal saiba qual GATEKEEPER está respondendo. Mas isso é um
detalhe secundário que pode ser facilmente corrigido em versões posteriores do protocolo.
► Gateways de H.323 para SIP
Esses gateways são possíveis. O seguimento fluxo de informação mostrado na Tabela 9.1 pode ser usado.
Se novos canais lógicos forem abertos durante a conversa pelo ponto final H.323, o proxy enviaria uma
nova mensagem INVITE ao Endpoint (ponto final) SIP, como mostrado na Tabela 9.2.
Tabela 9.1 – Fluxo de Informação entre gateways H.323 e SIP
Tabela 9.2 – Abrindo novas sessões de mídia
51
Conclusão sobre o futuro do SIP e sua relação com o H.323
Todos os documentos preliminares (DRAFTS) IETF começam da seguinte forma: É inadequado usar
documentos preliminares da INTERNET como material de referencia ou citá-los de outra forma que
não seja trabalho em andamento.
MEA MAXIMA CULPA – Usar um documento preliminar como material de referencia é exatamente
o que fizemos ao logo de todo este trabalho de pesquisa. Pensamos que isso seria útil para dar um
INSIGHT sobre o que poderia ser um sério desafiante para o H.323. Fazer isso antes de o protocolo
estar maduro e completamente entendido provavelmente nos levou a erros e mal-entendidos. A pesquisa
foi revisada quando o SIP se tornou um RFC mas, ainda assim, encorajamos o leitor a ler o RFC original
antes de se colocar contra ou a favor do SIP.
Dizer que o SIP é um trabalho em andamento do IETF também explica sua posição em que, uma vez
que uma recomendação tenha sido publicada, ela não mudara. Assim, foi possível organizar os testes de
interoperabilidade do H.323v1 (0 IMTC organiza testes desse tipo frequentemente) muito cedo. Atual-
mente, a indústria está trabalhando com H.323v2, porque todos confiam no fato de que agora que ele
foi aprovado, permanecerá estável. Alguns operadores já investiram muito em hardware de Telefonia
IP (ToIP) e, em um mercado imaturo como este, a estabilidade relativa fornecida pelo H.323 veio como
um alívio.
Agora, parece que o mercado está se concentrando mais em serviços de valor agregado e sua simplicidade
pode ser uma vantagem real. Provavelmente alguém tem um gateway de SIP para H.323 funcionando,
no qual o SIP seria usado em um domínio privado para permitir mais serviços flexíveis, enquanto o
H.323 garantiria a interoperabilidade com outras soluções. Mas quão simples é simples? Protocolos de
estímulo, como o MGCP, que já têm um suporte significativo da indústria, podem ser colocados como
possíveis concorrentes do SIP, com controladores de chamada mais complexos, mas terminais mais
simples. A guerra dos protocolos está longe de acabar.
O uso da Internet como meio de transporte de Voz tem alguns casos de sucesso, principalmente nas
chamadas de longa distância. Hoje o usuário que está fazendo uma chamada desse tipo não consegue
identificar o tipo de tecnologia que está sendo usada, e mesmo qual o caminho que a sua conversa está
seguindo. Entretanto, nem todas as aplicações têm o mesmo resultado. O mercado corporativo e mesmo
residencial ainda tem dificuldades para usar de forma generalizada esse tipo de tecnologia.
A medida em que o mercado for demandando novos serviços através da Internet, a estrutura de preci-
ficação desses serviços poderá ser aperfeiçoada de forma a definir o custo do acesso de acordo com o
tipo de aplicação do usuário. Esse novo formato de remuneração pode permitir o aperfeiçoamento da
própria arquitetura da Internet, através da implantação de protocolos mais sofisticados que permitem a
definição de prioridades para o transporte dos pacotes de dados de acordo com o tipo de aplicação do
usuário. A força do H.323 tem sido a sua interoperabilidade com o Packet Switched Telephone
Network (PSTN) e disponibilidade de sistemas/aplicações desktop e salas de videoconferência de
preço acessível e confiável. O SIP é um protocolo desenvolvido especificamente para Internet e pro-
mete grande escalabilidade e flexibilidade. É provável que o H.323 fique como a tecnologia de confe-
rência para gerenciar serviços de conferência/colaboração pelos próximos 2 ou 3 anos, com o SIP se
tornando mais usado quando o MCU SIP, gateways e servidores passarem além do beta.
52
O RADVISION, por exemplo, tem demonstrado um gateway H.323/SIP em algumas exposições pro-
fissionais, mas ainda não é um produto. Nesse novo contexto, tanto provedores como usuários terão a
oportunidade de usar a Internet para as aplicações de Telefonia IP – ToIP (e para outras mídias) com
custos um pouco superiores aos atuais, porém com a qualidade de serviço adequada.
Referências
ANATEL
Agência Nacional de Telecomunicações.
Disponível em: <http://www.anatel.gov.br/>
ITU
The International Telecommunication Union, órgão responsável pelo desenvolvimento de padronização
para telecomunicações.
IETF
The Internet Engineering Task Force, órgão responsável pelo desenvolvimento de padronização para a
Internet (RFC).
Disponível em: <http://www.ietf.org/>
RFC 3261
Especificação do protocolo SIP. IETF, 2002.
Disponível em: <http://www.ietf.org/rfc/rfc3261.txt>
MOS
Mean Opinion Score.
Disponível em: <https://pt.wikipedia.org/wiki/Mean_Opinion_Score>
CODEC
Disponível em: <https://docs.microsoft.com/pt-br/exchange/audio-codecs-exchange-2013-help>
TELECO
Disponível em: <https://www.teleco.com.br/tutoriais/tutorialmondesvoip/default.asp>
CODEC GSM
Disponível em: <https://www.voip-info.org/gsm-codec/>
CODEC
Disponível em: <https://docs.microsoft.com/pt-br/exchange/audio-codecs-exchange-2013-help>
CODEC
Disponível em: <https://ensinar.wordpress.com/2008/12/21/a-importancia-dos-codecs/>
INTELBRAS
Disponível em: <https://www.intelbras.com/pt-br/comunicacao/telefones/ip-voip>
53
TELEFONIA COMUTADA
Disponível em: <https://pt.wikipedia.org/wiki/Rede_p%C3%BAblica_de_telefonia_comutada>
FAX
Disponível em: <https://pt.wikipedia.org/wiki/Fax>
RTCP
Disponível em: <https://pt.wikipedia.org/wiki/RTCP>
POTS
Plain Old Telephone Service
Disponível em: <https://en.wikipedia.org/wiki/Plain_old_telephone_service>
RDSI
Disponível em: <https://pt.wikipedia.org/wiki/Rede_Digital_de_Servi%C3%A7os_Integrados>
Pager
Disponível em: <https://pt.wikipedia.org/wiki/Pager>
Bibliografia
Em meio eletrônico
PETIT, Jean-Pierre. HERSENT, Olivier. GURLE, David. – IP Telephony – Editora Wiley – 2005.
Acesso Via Amazon Kindle.
HERSENT, Oliver. GUIDE, David, PETIT, Jean-Pierre. – Telefonia IP – Editora Addison Wesley –
2002. Acesso Via Amazon Kindle.
BERNAL FILHO, H. Tutorias sobre banda larga e VoIP. Telefonia IP. 2003;
Disponível em: < http://www.teleco.com.br/tutoriais/tutorialtelip/pagina_1.asp>;
Acesso em dez. 2005.
FARIA, J. P. Voz sobre IP ganha aceitação. Revista Redes, nº 105, out. 2005;
Disponível em: < http://redes.xl.pt/105/400.shtml >;
SOUZA, I. Voice over IP. VoIP, Salvador, 2005;

Disponível em: <twiki.im.ufba.br/pub/MAT060/WebHome/VoIP-Monografia.pdf>
LUSTOSA, L. Semana da Informática. VoIP, Rio de Janeiro, 2005;

Disponível em: < www.voip.nce.ufrj.br/leandro/download/SemandaDaInformaticaUCP.pdf>;
54
SIP versus H.323;
Disponível em: <http://www.iptel.org/info/trends/sip.html>;
Wikipédia. SIP, 2005;

Disponível em: <http://pt.wikipedia.org/wiki/SIP >;
Sobre como redigir monografias
Escrevendo Monografias, Dissertações e Teses;

Disponível em: < http://pessoal.onda.com.br/monografias/index.html >;
Estrutura sugerida no Instituto de Informática da UFRGS e formatação ABNT;

Disponível em: < http:// www.inf.ufrgs.br/biblioteca/html/normas.htm >;
55

Ebook - Asterisk® SCF™ Expert - SIP Security

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ebook - Asterisk® SCF™ Expert - SIP Security

Enviado por

Direitos autorais:

Formatos disponíveis

Asterisk® SCF™ SIP Security

Professor Especialista Angelo de Barros Delphini

ISBN papel: 202004161509

Editado por Bubok Publishing S.L.

• Protocolo de descrição de sessão (Session Description Protocol – SDP) e o Protocolo de Anún-

Visão geral de uma chamada SIP Simples

Figura 2.1 – Realizando uma chamada para um endereço IP conhecido

Figura 2.4 – A resposta BUSY HERE

►Call-ID (p. ex.: ‘CALLID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com’): o parâmetro

Figura 3.2 – Uso do Cseq

►Content-length: o número de octetos do corpo da mensagem.

Figura 3.5 – O campo Via

►INVITE: o pedido INVITE é usado para iniciar uma chamada;

►RECORD-ROUTE – também um campo de cabeçalho de resposta - (p. ex.: Record-Router:

Session Description Protocol – SDP

• O protocolo de anuncio de sessão (Session Announcement Protocol – SAP) no MBONE;

O formato é a=rtpmap:<tipo do payload><nome da codificação>/<taxa do clock>[/parâme-

Serviços avançados com SIP

Essa característica é aproximadamente equivalente ao método de descoberta do GATEKEEPER des-

Figura 5.3 – Carga de registro

A funcionalidade de servidor de redirecionamento é semelhante ao papel desempenhado pelo GATE-

Um agente de chamada pode realizar as seguintes tarefas:

Acessando o BANDO DE DADOS! (banco de dados), de um REGISTRAR, um Proxy SIP pode

Atendimento direcionado e outros serviços avançados

Conferências com diversos participantes

Figura 6.3 – Multi-UniCast versus MultiCast

c=<endereço multicast base>/<ttl>/<número de endereços>

Configurando o tratamento de chamadas com base em rede

Características para o tratamento de chamadas podem ser instaladas em um PROXY/REGISTRAR

Tarifando as chamadas SIP

Figura 6.5 – Contabilidade de chamada no proxy

Sobre o tempo de tarifa: "s"

Sobre o tempo de tarifa: "c"

Sobre o tempo de tarifa: "m"

Sobre o tempo de tarifa: "1m+s"

Sobre o tempo de tarifa: "30s+s"

► k=base64:<chave de criptografia codificada>

Solicita ao usuário uma chave. O algoritmo padrão é o DES-CBC.

Figura 7.2 – Autenticação por meio do campo de cabeçalho Authorization

Figura 7.3 – NAT

Finalmente, depurar os problemas de interoperabilidade entre os terminais H.323 exige monitores de

► Gateways de H.323 para SIP

Tabela 9.1 – Fluxo de Informação entre gateways H.323 e SIP

Tabela 9.2 – Abrindo novas sessões de mídia

SOUZA, I. Voice over IP. VoIP, Salvador, 2005;

LUSTOSA, L. Semana da Informática. VoIP, Rio de Janeiro, 2005;

Wikipédia. SIP, 2005;

Sobre como redigir monografias

Escrevendo Monografias, Dissertações e Teses;

Estrutura sugerida no Instituto de Informática da UFRGS e formatação ABNT;

Você também pode gostar