Mensagens SIP

Mensagens SIP

• Mensagens SIP são codificadas em formato texto

ISSO 10646 com codificação UTF-8;
• Mensagens são pedidos (requests) ou respostas
(responses)

Linha de início: pedido ou resposta

Cabeçalhos

Linha em branco

Corpo da mensagem, se houver. Pode ser SDP limpo

ou criptografado, MIME...

Formato genérico da mensagem SIP.

Fonte Telefonia IP - HERSENT, Oliver, GUIDE,David, PETIT, Jean-Pierre.
 Mensagens SIP

CABEÇALHO
• Possui diversos campos, sendo alguns
presentes tanto em pedidos como respostas;

• Na maioria dos casos, segue as regras do

cabeçalho HTTP:

Nome do Campo: campo/valor <CRLF>

• Muitos cabeçalhos possuem forma compacta

(uma única letra para indicar o nome campo);
 Mensagens SIP
Forma compacta de cabeçalhos SIP
Campo Compactado
Accept-Contact a
Allow-Event u
Call-ID i
Contact m
Content-Encoding e
Content-Length l
Content-Type c
Event o
From f
Refer-To r
Referred-By b
Reject-Contact j
Subject s
To t
Via v
 Mensagens SIP

CABEÇALHO - CAMPOS MAIS COMUNS:

• CALL-ID : obrigatório em pedidos e respostas,
é um identificador único para identificar uma
chamada. É composto de um identificador
aleatório único localmente seguido do nome
de um domínio ou endereço IP. Ex:
Call-ID: 34a5d553192cc35@15.34.3.1

i: 35866383092031257@port34.carrier.com
 Mensagens SIP

CABEÇALHO - CAMPOS MAIS COMUNS:

• CSeq: obrigatório nas requisições, o campo de
seqüência de comando é usado para
determinar pedidos fora de seqüência ou
diferencia entre uma nova requisição e uma
retransmissão. Composto de um número
decimal (incrementado a cada novo pedido,
exceto no ACK ou CANCEL) seguido do
método. Ex:
Cseq: 12 INVITE
 Mensagens SIP

CABEÇALHO - CAMPOS MAIS COMUNS:

• From: obrigatório em pedidos e respostas,
indica a origem da requisição. Contém uma
URI (Universal Resource Identifier);
Os endereços SIP são URLs (Uniform Request Location)
Esquema: sip/http/ftp/email, Nome do Usuário,
Senha(Opcionalmente), Nome do Host (Porta
Opcional), Parâmetros, Cabeçalhos e Corpo

Permite o uso de outros prefixos, além do sip,

facilitando a integração com a internet e permitindo o
redirecionamento. Ex:
sip:aluno@ufrn.br; tag=123456
 Mensagens SIP
URIs mais comuns em mensagens SIP

Prefixo Significado
sip SIP URI
sips Secure SIP URI
tel Telephone URI
pres Presence URI
im Instant Message URI
mailto E-mail URL
http Web URL
 Mensagens SIP

CABEÇALHO - CAMPOS MAIS COMUNS:

• To : indica o destino pretendido da requisição.
Contém uma URI (Universal Resource
Identifier) e um tag para auxiliar na
identificação da chamada (obrigatório na RFC
3261). Ex:
sip:aluno2@ufrn.br; tag=654321

To e From são copiados dos pedidos nas respostas, não

são alterados os campos. Indicam sentido de origem do
pedido.
 Mensagens SIP

CABEÇALHO - CAMPOS MAIS COMUNS:

• VIA: usado pra gravar a rota de um pedido,
para que as respostas usem o mesmo caminho.
O user agent gera a requisição colocando seu
próprio endereço no campo Via. Cada proxy
acrescenta um campo Via no topo da lista. O
campo Via contém o nome e versão do
protocolo, transporte e endereço, além de
parâmetros adicionais como received, maddr
(endereço multicast) e ttl. Ex:
Via : SIP/2.0/UDP proxysip.ufrn.br
 Mensagens SIP

CABEÇALHO - CAMPOS MAIS COMUNS:

Campos que se relacionam com o corpo da

mensagem:
• Content-Type: descreve o tipo de conteúdo do
corpo da mensagem. Ex:
Content-Type: application/sdp

Content-Type: multipart/mixed

• Content-Lenght: o tamanho do corpo da

mensagem em octetos
 Mensagens SIP

CABEÇALHO - CAMPOS MAIS COMUNS:

• Max-Forwards: campo utilizado para indicar o
máximo de hops que o pedido pode fazer. O
valor é decrementado por cada proxy que
encaminhar o pedido. Um proxy que receba o
campo com valor 0 descarta a mensagem e
retorna uma mensagem de erro 483 (Too
Many Hops). Obrigatório na RFC 3261 para
controle de loop (feito pelo campo Via na RFC
2543).
 Mensagens SIP

CABEÇALHO
• Muitos outros campos foram definidos e tem
uso de acordo com a requisição ou resposta:
Accept, Accept-Encoding, Accept-Language, Alert-Info, Allow, Allow-
events, Authentication-Info, Authorization, Call-Info, Contact,
Content-Disposition, Content-Encoding, Content-Language, Content-
Length, Content-Type, Date, Error-Info, Expires, In-Reply-To, Max-
Forwards, Min-Expires, MIME-Version, Organization, Priority, Proxy-
Authenticate, Proxy-Authorization, Proxy-Require, Record-Route,
Reply-To, Require, Retry-After, Route, Server, Subject, Supported,
Timestamp, Unsupported, User-Agent, Warning, WWW-Authenticate;
 Mensagens SIP
LISTA DE CAMPOS QUE
PODEM INSERIDOS OU
CABEÇALHO MODIFICADOS POR PROXIES
Alert-Info
Call-Info
• Proxies não necessitam
Content-Length
entender novos métodos Date

e campos de cabeçalho: Error-Info

Max-Forwards
extensões podem ser Organization

feitas ao protocolo sem Priority

Proxy-Authenticate
necessitar mudança da Proxy-Authorization
estrutura de rede. Proxy-Require
Record-Route
Reason
Require
Route
Via
WWW-Authenticate
 Mensagens SIP

Linha de início: pedido ou resposta

Cabeçalhos

Linha em branco

Corpo da mensagem, se houver. Pode ser SDP limpo

ou criptografado, MIME...

Linha de início: determina se a mensagem é um pedido

ou uma resposta. Composta de método,
uri e versão do SIP. Ex:

INVITE sip:aluno@ufrn.br SIP/2.0

 Mensagens SIP

Requisições e respostas
• Pedidos, requisições ou métodos especificam a ação
a ser tomada por outro user agent ou servidor. A RFC
3261 define 6 métodos: INVITE, REGISTER, BYE,
ACK, CANCEL E OPTIONS. Outros 7 métodos são
definidos em outras RFCs: REFER, SUBSCRIBE,
NOTIFY, MESSAGE, UPDATE, INFO e PRACK;

• Respostas contém um código de status e uma frase

de justificativa inteligível por pessoas. Podem ser
informativas (1xx), de Sucesso (2xx), de
redirecionamento (3xx), de erro de cliente (4xx).
 Mensagens SIP

Requisições - INVITE
• É o método utilizado para estabelecer
sessões entre user agents;

• Sempre é confirmado com ACK;

• Geralmente possui um corpo que

descreve as informações de mídias da
origem;

• O User agent cria um Call-ID para ser

usado enquanto durar a chamada.
 Mensagens SIP

Requisições - INVITE
• CSeq é utilizado para controle de
retransmissões;

• No caso de ser necessário mudar as

características da mídia, um re-INVITE
pode ser usado com o CSeq
incrementado;

• Os clientes transmitem INVITE com

backoff exponencial: 500ms, 1s, 2s, 4s.

• Retransmissões cessam quando

chegam respostas provisórias (100
trying).
 Mensagens SIP

Requisições - ACK
• Método usado para confirmação final
para requisições INVITE;

• O CSeq não é incrementado para o

ACK, mas alterado para a próxima
requisição;

• Opcionalmente, pode conter uma

mensagem SDP;

• Para respostas 2xx (sucesso), o ACK é

fim-a-fim, mas todas as outras são
hop-by-hop quando statefull proxies
estão envolvidos.
 Mensagens SIP

Requisições – BYE

• Método usado para encerrar uma

sessão já estabelecida;

• Enviado apenas pelos users agents

envolvidos, nunca por proxies;

• É um método fim-a-fim;
 Mensagens SIP

Requisições – CANCEL

Método utilizado para terminar

buscas pendentes ou tentativas de chamadas.
O pedido pode ser gerado pelos user agents ou
proxies que receberam uma mensagem
informativa provisória (1xx) mas não
receberam a mensagem final.
 Mensagens SIP

Requisições – OPTION

Método utilizado para um cliente

saber sobre as capacidades do servidor. A
resposta contém uma lista dos métodos
permitidos.
 Mensagens SIP

Requisições – REGISTER

Método utilizado pelo user agent

para notificar a rede SIP da sua localização
atual (Contact URI – IP Address – um ou mais
endereço).
 Mensagens SIP

Requisições RFC 3261 Requisições de outras RFCs

• INVITE • REFER

• REGISTER • SUBSCRIBE

• BYE • NOTIFY

• ACK • MESSAGE

• CANCEL • UPDATE

• OPTIONS. • INFO

• PRACK.
 Mensagens SIP

Requisições
• REFER: método usado por um user agent para requisitar que
outro user agent acesse uma URI ou URL. Pode ser utilizado,
por exemplo, para implementar uma transferência de
chamada;

• SUBSCRIBE: método usado por um user agent para

estabelecer uma inscrição com o propósito de receber
notificações (Ex: informações de presença - online/offline)

• NOTIFY: método usado para transportar informações sobre

eventos particulares, definidos na subscrição;

• MESSAGE: usado para transporte de mensagens instantâneas

usando SIP. Pode conter anexos MIME
 Mensagens SIP

Requisições
• UPDATE: usado para modificar o estado da sessão sem
mudança de estado do diálogo. Usado no lugar de re-
INVITE enquanto o INVITE não foi confirmado.

• INFO: usado para que o user agent envie informações

de sinalização da chamada para outro agente com o
qual estabeleceu uma conexão multimídia. Diferente do
re-INVITE pois não muda as características da sessão.
Proposto para transportar algumas informações de
sinalização PSTN;

• PRACK: ACK provisório, utilizado para reconhecimento

de mensagens provisórias (1xx).
 Mensagens SIP

RESPOSTAS
Respostas contém um código de status e
uma frase de justificativa inteligível por
pessoas.
Classes de Status Code:
100-199 (1XX) :Informação Provisória
200-299 (2XX) :Sucesso
300-399 (3XX) :Redirecionamento
400-499 (4XX) :Erro no Cliente
500-599 (5XX) :Erro no Servidor
600-699 (6XX) :Falha Global
 Mensagens SIP

RESPOSTAS
Status Code
• 100-199 : são consideradas respostas
provisórias e sem confiabilidade;
• 200-699 :são as respostas finais, definitivas,
terminam uma transação no ambiente SIP.

Cabeçalho da Resposta
Os campos Call-ID, To, From,CSeq são
espelhadas em respostas para suportar o
match (verificação) de campos entre
requisição e resposta.
 Mensagens SIP
Categorias de códigos de status
1xx Informativo (Pedido recebido, continuando a processar o pedido)
100 Tentando
180 Chamando
181 A chamada está sendo retransmitida
182 Colocado na fila

2xx Sucesso (a ação foi recebida, entendida e aceito com sucesso)

200 OK

3xx Redirecionamento (uma ação adicional deve ser tomada para

completar o pedido)
300 Múltiplas escolhas
301 Movido permanentemente
302 Movido temporariamente
380 Serviço alternativo
 Mensagens SIP
Categorias de códigos de status
4xx Erro de cliente (O pedido contém sintaxe inválida ou não pode ser efetuado
neste servidor)
400 Pedido inválido
401 Não autorizado
402 Necessário pagamento
403 Proibido
404 Não encontrado
405 Método não permitido
406 Não aceitável
407 Necessária autenticação do proxy
408 Tempo para o pedido esgotado
409 Conflito
410 Não mais presente
411 Necessário fornecer comprimento
413 Corpo da mensagem de pedido muito grande
414 URI do pedido muito grande
415 Tipo de mídia não suportado
420 Extensão inválida
480 Temporariamente não disponível
481 Transação ou leg de chamado não existe
482 Laço (loop) detectado
483 Excesso de segmentos (hops)
484 Endereço incompleto
485 Ambíguo
 Mensagens SIP
Categorias de códigos de status

5xx Erro de servidor

500 Erro interno ao servidor
501 Não implementado
502 Gateway inválido
503 Serviço não disponível
504 Tempo esgotado no gateway
505 Versão SIP não suportada

6xx Falha global

600 Ocupado em todos os lugares
603 Declínio
604 Não existe em lugar nenhum
606 Não aceitável
 Mensagens SIP

Linha de início: pedido ou resposta

Cabeçalhos

Linha em branco

Corpo da mensagem, se houver. Pode ser SDP limpo

ou criptografado, MIME...

Corpo da mensagem: obrigatoriamente deve

suportar SDP. Pode utilizar formato MIME
(Multipurpose Internet Mail Extensions) e
S/MIME para aumentar a segurança
(criptografia do corpo da mensagem).
 SDP
Session Description Protocol
 SDP : Session Description Protocol

O Protocolo de descrição de Sessão – SDP -

foi desenvolvido para descrever sessões de

multimídia.

Esta descrição pode ser usada para

negociar uma aceitação de um conjunto de tipos

de mídias compatíveis.
 SDP : Session Description Protocol

O SDP contém informações sobre a sessão, tais como:

• Endereço IP ou host name;

• Número da Porta (usada pelo UDP ou pelo TCP);

• Tipo de mídia (áudio, vídeo, whiteboard interativo);

• Assunto da sessão;

• Tempo de inicio;

• Informações de contato.

Assim como o SIP, SDP usa codificação textual. Uma

mensagem SDP é composta de uma série de linhas,
chamadas campos, cujos nomes são abreviados por uma
única letra.
 SDP : Session Description Protocol
Lista dos principais campos SDP, em sua ordem requerida.
Campo Nome obrigatório/opcional
v= Número da versão do protocolo obrigatório
o= Identificador do proprietário da sessão obrigatório
s= Nome da Sessão obrigatório
i= Informação da sessão opcional
u= Uniform Resource Identifer opcional
e= Endereço de e-mail opcional
p= Número de telefone opcional
c= Informações de conexão obrigatório
b= Informação sobre largura de banda opcional
t= Tempo – início e fim da sessão obrigatório
r= Número de repetições opcional
z= Correções de zonas de horário opcional
k= Chave de criptografia opcional
m= Informações de mídia opcional
a= Atributos da mídia opcional
 SDP : Session Description Protocol

Informações de capacidade de Mídia (m=)

O campo opcional m= contém informações sobre os tipos de
mídias:
m=mídia porta transporte lista-de-formatos
Sendo:
mídia: audio, video, application, data, telephone ou control;
porta: número da porta;
transporte: protocolo de transporte – RTP/AVP ou UDP;
lista-de-formatos: contém os tipos de payload definido nos
perfis RTP de aúdio e vídeo;

Exemplo:
m=audio 49170 RTP/AVP 0
 SDP : Session Description Protocol

Informações de capacidade de Mídia (m=)

• Payloads RTP de 0 a 95 são

estáticos, designados pela IANA Tipo de Codec
(Internet Assigned Numbers payload
Authority). Ex: 0 Áudio PCM, µ law

m=audio 49170 RTP/AVP 0 8 PCM, a law

9 G.722
4 G.723
• Payloads de 96 a 127 são
15 G.728
dinâmicos, negociados pelo
18 G.729
protocolo de controle de
34 Vídeo H.263
conferência. Ex:
31 H.261
m=audio 49170 RTP/AVP 98
a=rtmap:98 L16/16000/2
(Áudio estéreo com codificação de linear de 16 bits amostrado a 16 kHz)
 SDP : Session Description Protocol

Exemplo SDP
v=0
o=johnston 2890844526 2890844526 IN IP4 43.32.1.5
s=SIP Tutorial
i=This broadcast will cover this new IETF protocol
u=http://www.digitalari.com/sip
e=Alan Johnston alan@mci.com
p=+1-314-555-3333 (Daytime Only)
c=IN IP4 225.45.3.56/236
b=CT:144
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 23422 RTP/AVP 31
a=rtpmap:31 H261/90000
 Mensagens SIP

Linha de início: pedido ou resposta

Cabeçalhos

Linha em branco

Corpo da mensagem, se houver. Pode ser SDP limpo

ou criptografado, MIME...
 SIP
Operação
do Protocolo
 Operação do Protocolo

Negociação da sessão
• Destino recebe INVITE com SDP
especificando o formato de mídia / codec
desejado;
• Pedido pode ser aceito ou rejeitado;
• Resposta lista os tipos de mídia
disponíveis. Se aceito, possui o mesmo
tipo (payload RTP);
 Operação do Protocolo

Localização de usuário
• Requisições podem passar por vários servidores
proxy;

• Cada servidor chega se é responsável pelo domínio

requisitado, caso contrario repassa para o servidor
SIP do domínio correspondente;

• Servidores SIP são registrados no DNS através de

registros SRV (DNS location of services ) ou NAPTR
(Naming Authority Pointer).
Operação do Protocolo
Localização de Usuários
 sip:aluno2@ibta.br

Invite 200 OK
ACK

SIP Stateless Proxy Invite SIP Statefull Proxy 2

200 OK
o da
m inh ção
Invite 200 OK Ca alizC a
n K
Si A

M Invi
SIP Statefull Proxy 1 o ved te
Tem
p or
ACK aril
y
Invite 200 OKACK SIP Redirect Server

Mídia (RTP)
sip:aluno@ibta.br
Operação do Protocolo
 Mais informações

• http://www.ietf.org/html.charters/sip-charter.html

• http://www.cs.columbia.edu/sip/

• http://www.sipforum.org/index.php
 Implementações
Ethernet Phones
3Com   bcm   Cisco (docs)   E-tel   Grandstream   Pingtel   Snom   TuxScreen   Way2Call   Siemens
(HiNet LP510)  Siemens optiPoint   Wylus  

WiFi Phones
Zyxel   Senao  

PBX
Citel   Interactive Intelligence   8x8 Intraswitch   Pingtel   SIPquest  

PSTN Gateways
8x8   Epygi   Komodo   Cisco ATA 186 IAD   SIPURA SPA-2000   Interactive Intelligence Mediatrix   Nuera  
Sonus Networks (GSX)   T&S Software   UCL   Vegastream

Firewalls, NAT traversal and ALGs

Cisco Pix   Entel ADSL modem   Ingate   Intertex IX66   Intertex IX 66 with ADSL modem   Jasomi  
Microppliances   Netrake  

Proxies, Registrars and Redirect Servers

3Com   Brekeke   Cisco   Columbia University sipd   dynamicsoft   Fomine   Hewlett Packard   Hotsip  
Hughes Software Systems   Indigo   Interactive Intelligence   iptel.org   Meetinghouse Data
Communications   MicroAppliances   ObjectSoftware   partysip   Pingtel   SIPquest  
Siptrex   Snom   Sonus Networks (PSX)   T&S Software   Terminal Technologies   Ubiquity
  Vovida.org  
 Session
SIP Initiation
Protocol
Sidnei Costa Souza