Embed Size (px)
Citation preview
Curso de Engenharia de Computação
CONTROLADOR DE SESSÕES SIP PARA REDES DE TERCEIRA GERAÇÃO
USANDO ASTERISK
Márcio Aikawa Furuzawa
Campinas – São Paulo – Brasil
Dezembro de 2008
Curso de Engenharia de Computação
CONTROLADOR DE SESSÕES SIP PARA REDES DE TERCEIRA GERAÇÃO
USANDO ASTERISK
Márcio Aikawa Furuzawa
Monografia apresentada à disciplina de Trabalho de Conclusão do Curso de Engenharia de Computação da Universidade São Francisco, sob a orientação do Prof. Carlos Eduardo Pagani, como exigência parcial para conclusão do curso de graduação. Orientador: Prof. Carlos Eduardo Pagani
Campinas – São Paulo – Brasil
Dezembro de 2008
AIKAWA, Márcio Furuzawa. Controladores de Sessões SIP para Redes de Terceira
Geração usando Asterisk. Monografia defendida e aprovada em 12 de Dezembro de
2008 pela Banca Examinadora assim constituída pelos professores:
Prof. Carlos Eduardo Pagani (Orientador)
USF – Universidade São Francisco – Campinas – SP.
Prof. Carlos Eduardo Câmara
USF – Universidade São Francisco – Campinas – SP.
Prof. Sidney Pio de Campos
USF – Universidade São Francisco – Campinas – SP.
à meus amados pais, Lucília e Fernando, pelos
sacrifícios que fizeram em prol da minha
educação e formação.
v
Agradecimentos
Agradeço a minha família, que me apoiou e me deu condições e incentivou
para concluir mais esta etapa da vida.
Ao meu orientador, Prof. Carlos Eduardo Pagani, que acreditou e me orientou
com profissionalismo para realizar este trabalho.
Finalizo agradecendo a todos que, de alguma forma direta ou indireta me
ajudaram a concluir mais essa etapa da vida.
vi
Sumário
Lista de Siglas ....................................................................................................................................... viii
Lista de Siglas ....................................................................................................................................... viii
Lista de Figura ..........................................................................................................................................x
Resumo.....................................................................................................................................................x
Abstract....................................................................................................................................................xi
1 Introdução......................................................................................................................................... 1 1.1 Definição do problema a ser tratado ......................................................................................... 2 1.2 Estrutura do Texto..................................................................................................................... 3
2 PROTOCOLO................................................................................................................................... 3 2.1 Entidades de rede SIP .............................................................................................................. 4 2.2 Estabelecimento de chamada SIP ............................................................................................ 5 2.3 Vantagens SIP sobre outros protocolos de sinalização............................................................ 5 2.4 Sintaxe mensagem SIP............................................................................................................. 6 2.5 Pedido SIP ................................................................................................................................ 7 2.6 Respostas SIP........................................................................................................................... 7 2.7 Endereçamento SIP .................................................................................................................. 8 2.8 Seqüência da Mensagem SIP................................................................................................... 8
3 Arquitetura IMS............................................................................................................................... 10 3.1 QoS para serviços multimídia ................................................................................................. 11 3.2 Política IP – Uso correto dos recursos.................................................................................... 12 3.3 Componentes da Arquitetura IMS........................................................................................... 12 3.4 O HSS e o SLF........................................................................................................................ 13 3.5 O CSCF................................................................................................................................... 14
3.5.1 O P-CSCF ........................................................................................................................ 14 3.5.2 O I-CSCF ......................................................................................................................... 14 3.5.3 O S-CSCF ........................................................................................................................ 15
3.6 O AS........................................................................................................................................ 16 3.7 O MRF..................................................................................................................................... 16 3.8 O BGCF................................................................................................................................... 16 3.9 O PSTN/CS Gateway.............................................................................................................. 16 3.10 SGW........................................................................................................................................ 17 3.11 MGCF...................................................................................................................................... 17 3.12 MGW ....................................................................................................................................... 17 3.13 Registro/Autenticação ............................................................................................................. 17 3.14 Acesso Seguro – IPsec ASs ................................................................................................... 19 3.15 Estabelecimento de uma sessão ............................................................................................ 21 3.16 Serviços................................................................................................................................... 22 3.17 Estudo ..................................................................................................................................... 23
4 ASTERISK...................................................................................................................................... 24 4.1 Requisitos................................................................................................................................ 24 4.2 Configuração SIP .................................................................................................................... 24
4.2.1 SIP.CONF ........................................................................................................................ 25 4.3 Configuração do Plano de discagem ...................................................................................... 26
vii
4.3.1 Contexto........................................................................................................................... 26 4.3.2 Extensões ........................................................................................................................ 26 4.3.3 Prioridades ....................................................................................................................... 27 4.3.4 Aplicação.......................................................................................................................... 27
4.4 O Gateway de Interface do Asterisk (AGI).............................................................................. 28 4.4.1 Fundamentos da Comunicação AGI................................................................................ 28 4.4.2 O modelo de comunicação AGI ....................................................................................... 28 4.4.3 Chamando um script AGI do Plano de discagem............................................................ 29
4.5 Estudo ..................................................................................................................................... 29
5 TESTE / ANÁLISE.......................................................................................................................... 30 5.1 Ambiente de Teste com Asterisk ............................................................................................ 30
5.1.1 – Configuração de Serviço............................................................................................... 31 5.1.2 – Resultados .................................................................................................................... 32
5.2 Ambiente de Teste com SDS.................................................................................................. 37 5.3 Análise..................................................................................................................................... 43
5.3.1 Semelhanças ................................................................................................................... 43 5.3.1.1 Registro..................................................................................................................... 44 5.3.1.2 Início de Sessão ....................................................................................................... 44 5.3.1.3 Encerramento de Sessão ......................................................................................... 44
5.3.2 Diferenças ........................................................................................................................ 44 5.3.2.1 Registro..................................................................................................................... 44 5.3.2.2 Serviços .................................................................................................................... 44
5.4 Proposta de Mudanças ........................................................................................................... 45
6 Conclusão....................................................................................................................................... 46 6.1 Contribuições .......................................................................................................................... 47 6.2 Trabalhos futuros .................................................................................................................... 47
Anexo A – Sip.conf ................................................................................................................................ 48 Anexo B - Extensions.conf..................................................................................................................... 49
Anexo C – Script PHP ativa_servico.agi ............................................................................................... 50
Anexo D – Script PHP valida_servico.agi.............................................................................................. 51
Anexo E – Teste de Resultado do Wireshark...................................................................................52 Anexo F – Log do Wireshark.................................................................................................................54
Referências Bibliográficas ..................................................................................................................... 73
viii
Lista de Siglas
3GPP 3rd Generation Partnership Project
ADSL Asynchronous Digital Subscriber Line
AGI Asterisk Gateway interface
AKA Authentication and Key Agreement
ANSI American National Standards Institute
AS Applications Servers
AV Authentication Vector
B2BUA Back-to-Back User Agent
BGCF Breakout Gateway Control Functions
CK Ciphering Key
CSCF Call/Session Control Functions
ETSI European Telecommunications Standards Institute
GSM Global System for Mobile Communications
GPRS General Packet Radio Service
HSS Home Subscriber Servers
I-CSCF Interrogating- Call/Session Control Functions
IETF Internet Engineering Task Force
IK Integrity Key
IMS IP Multimedia Subsystem
IP Internet Protocol
IPsec SAs Internet Protocol security Security Associations
ITU International Telecommunication Union
MGCF Media Gateway Controller Function
MGW Media Gateway
MRF Media Resource Functions
MRFC Media Resource Function Controllers
MRFP Media Resource Function Processors
OMA Open Mobile Alliance
PDA Personal Digitals Assistants
P-CSCF Proxy- Call/Session Control Functions
PSTN Public Switched Telephone Network
RTP Real Time Protocol
S-CSCF Serving- Call/Session Control Functions
SDS Service Development Studio
SGW Signaling Gateway
SIP Session Initiation Protocol
SLF Subscriber Locations Functions
ix
THIG Topology Hiding Inter-network Gateway
UE User Equipment
URI Uniform Resource Identifier
VoIP Voice over IP
WLAN Wireless Local Area Network
x
Lista de Figura
Figura 1: Controle sessão SIP - Modelo de teste ...................................................................................2
Figura 2.1: Separação lógica da sessão de mídia e o sinal SIP ............................................................4
Figura 2.2: Exemplo de um fluxo de chamada[3] ...................................................................................5
Figura 2.3: seqüência de pedido SIP(estabelecimento e encerramento de uma chamada) [3] ............9
Figura 3.1: uma visão da arquitetura IMS [6] .......................................................................................12
Figura 3.2: um exemplo do BGCF e um gateway PSTN que faz interface com a rede PSTN [6] .......17
Figura 3.3: Fluxo de Autenticação e Registro no IMS ..........................................................................18
Figura 3.4: Estabelecimento de AS durante um registro inicial ............................................................20
Figura 3.5: Estabelecimento de sessão na Arquitetura IMS .................................................................21
Figura 3.6: Exemplo de solicitação e execução de serviço ..................................................................23
Figura 5.1: Comunicação entre dois usuários usando Asterisk ...........................................................31
Figura 5.2: Fluxo da execução de script AGI .......................................................................................32
Figura 5.3 : Pacotes UDP capturados no registro dos usuários e no início de uma sessão SIP .........33
Figura 5.4: pacotes capturados após uma sessão SIP ter iniciado ......................................................34
Figura 5.5: fluxo de uma sessão entre dois usuários .......................................................................... 35
Figura 5.6: Tela inicial de instalação SDS ............................................................................................37
Figura 5.7: Caminho para iniciar o Provisioning ...................................................................................38
Figura 5.8: Tela configuração de DNS .. ..............................................................................................38
Figura 5.9: Tela de criação do Profile do usuário .................................................................................39
Figura 5.10: Tela de cadastro de serviços ............................................................................................39
Figura 5.11: Comunicação entre dois usuários usando arquitetura IMS ..............................................40
Figura 5.12: Caminho para iniciar o “Start Test Agent” .......................................................................40
Figura 5.13: Construção de um pedido REGISTER no SDS ...............................................................41
Figura 5.14: Envio do pedido REGISTER e retorno de resposta 200 OK.............................................41
Figura 5.15: fluxo de pedidos e respostas SIP usando IMS .................................................................42
Figura 5.16: Fluxograma simples do processo com o Script Java........................................................45
xi
Resumo
O objetivo desta monografia é testar e analisar o comportamento do
software Asterisk para verificar e propor alterações para que esta possa executar as
funções que um controlador de sessões para redes de 3G. A rede 3G possibilita o
usuário a acessar todos os serviços que a Internet oferece, via celular. O elemento
chave de algumas redes 3G é a arquitetura IMS (IP Multimedia Subsystem). O
protocolo SIP é usado na arquitetura IMS para o controle de sessões multimídia.
Para o estudo e análise é mostrado a arquitetura IMS e seus principais
componentes, o funcionamento do protocolo SIP, o software Asterisk e a análise dos
resultados obtidos nos testes.
PALAVRAS-CHAVE: IMS, SIP e Asterisk.
Abstract
The objective of this monograph is to test and to analyze if it is possible to
control SIP sessions in Third Generation (3G) networks using the Asterisk software.
The 3G network makes possible the user access all services that the internet
provides, by cellphone. The key element of the 3G network is an IMS (IP Multimedia
Subsystem) architecture. The SIP protocol is used in the architecture IMS to control
multimedia session. For the study and analysis, it is showed the IMS architecture and
their main components, the SIP functioning, the Asterisk software and the results
gotten in the test.
KEY WORDS: IMS, SIP and Asterisk.
1
1 INTRODUÇÃO
Hoje, a maioria das redes de comunicação operam no modo comutado por
circuito. Há tempo vem se estudando a evolução e a migração destas redes para
comutação de pacotes com suporte a tráfego multimídia. Estas são freqüentemente
chamadas de “NGN” (New Generation Network ou Redes Convergentes), ou
referidas como suporte à aplicação VoIP (Voice over IP). Entretanto é necessário
atentar a alguns requisitos, como: suporte a serviços sofisticados de multimídia,
conexão orientada a sessão, rede orientada a pacote com convergência de voz e
dados, mobilidade sem restrições, convergência fixo/móvel de serviço e operação da
rede, interface aberta para todos os elementos, base de dados para simplificar
operação, e suporte aos assinantes e serviços legados. [1]
A convergência permite aplicações do tipo telefonia via IP acessar a web
através de telefones móveis. O canal nestas redes podem oferecer uma gama de
serviços diferenciados e unificados em tempo real, combinar voz, dados e
vídeos,independentes do dispositivo utilizado.
A arquitetura IMS (IP Multimedia SubSystem) é a resposta para estes
requisitos. Esta arquitetura da rede é desenvolvida pelo 3GPP/3GPP2, e
padronizado pelos órgãos (ITU / ANSI / ETSI /OMA / IETF). [1]
O maior benefício da arquitetura IMS é a disponibilidade de serviços
sofisticados para os assinantes. As redes atuais já disponibilizam serviços de valor
agregado para os assinantes, com algumas limitações: baixa interação entre
plataformas de serviços, e baixa eficiência na administração de bases de dados. [1]
A arquitetura IMS fornece uma forma eficiente de implementar novos serviços
sofisticados. Por exemplo, o HSS (Home Subscriber System) onde são
armazenados dados dos clientes, pode ser acessado através de protocolos abertos
pelas plataformas de serviços. Um outro exemplo são serviços que podem ser
executados simultaneamente numa mesma sessão.
A arquitetura IMS possui o mecanismo de autenticação dos usuários no IMS
para a reserva de recurso, e também possui mais mecanismos de controle de QoS,
aumentando a segurança.
A arquitetura IMS foi desenvolvida para aplicações em redes móveis 3G, mas
ultimamente as redes fixas vêm mostrando um grande interesse nesta arquitetura.
2
Esta é vista como o caminho adequado para implementação de redes de nova
geração.
O software Asterisk [2] de código aberto (Softwares disponibilizados
gratuitamente com o seu código fonte, permitindo alterações de acordo com a
necessidade do usuário) inicialmente concebido como um software PBX (Private
Branch eXchange) sobre IP, ao longo de suas melhorias e desenvolvimento foi se
tornando uma poderosa máquina servidora SIP, por permitir integrar qualquer
hardware ou software de telefonia a outras aplicações com extrema facilidade.
A idéia desse estudo é testar e analisar a possibilidade do software Asterisk
atuar como um controlador de sessão SIP da arquitetura IMS. Com a análise final
propor alterações no comportamento do Asterisk, como mostra a Figura 1.
Figura 1: Controle sessão SIP - Modelo de teste
1.1 Definição do problema a ser tratado
O principal objetivo desta monografia é sugerir o software Asterisk como um
controlador de sessão na arquitetura IMS, conforme a Figura 1, onde o
comportamento do Asterisk precisa ser igual ao do componente S-CSCF (Serving-
Call/Session Control Function) da arquitetura IMS. Para isso, é apresentado o
protocolo SIP usado no envio de pedidos e respostas, a arquitetura IMS e seus
principais componentes, o software Asterisk e por final o resultado da comparação
de sessões SIP na arquitetura IMS com as sessões no Asterisk.
3
1.2 Estrutura do Texto
No Capítulo 2 é apresentado o protocolo SIP, no Capítulo 3 é apresentada a
arquitetura IMS, no Capítulo 4 é apresentado o software Asterisk, no Capítulo 5 são
apresentados os ambientes de testes, testes e análises e no Capítulo 6: são
apresentadas as Conclusões e proposta para trabalhos futuros.
2 PROTOCOLO
“Esta sessão tem como referência o livro do autor COLLINS, Daniel [Carrier
Grade Voice Over IP – 2a. edição] [3]”.
O SIP é considerado como uma solução simples, flexível, fácil de se
implementar, pode suportar dispositivos inteligentes, e é adequado para
implementações futuras, produtos e serviços podem ser desenvolvidos e
disponibilizados rapidamente. O SIP é considerado uma alternativa ao protocolo
H.323, hoje utilizado em telefonia VoIP. O protocolo H.323 que foi criado pelo ITU-T
(International Telecommunication Union - Telecommunication Standardization
Sector) e disponibilizado em 1996 é um protocolo de sinalização usado para o
estabelecimento, controle e término de chamadas em redes comutadas por pacotes.
Além disso, é usado para estabelecer padrões de codificação e decodificação em
fluxo de dados de áudio e vídeo em tempo real, garantindo a interoperabilidade. O
H.323 é um protocolo mais antigo e complexo, se comparado com o protocolo SIP.
[2]
O protocolo SIP foi proposto pela IETF (Internet Engineering Task Force), com a
função de gerenciar, configurar, iniciar e encerrar sessões multimídia. Este protocolo
foi projetado para trabalhar juntamente com outras aplicações já existentes, e
também para operar em conjunto com outros protocolos IETF para descrever as
características de sessões dos participantes. O protocolo SIP pode também operar
com protocolos de transporte de mídia, por exemplo, o RTP (Real-Time Transport
Protocol). Assim, numa sessão SIP, deve ser considerado que a sinalização SIP
trafega separadamente da sessão mídia. Esta separação lógica mostrada na Figura
2.1 é importante porque o sinal pode chegar ao destino passando por um ou mais
proxies enquanto que o fluxo de mídia pode pegar um caminho mais direto. [3]
4
Figura 2.1: Separação lógica da sessão de mídia e o sinal SIP
2.1 Entidades de rede SIP
SIP é um protocolo cliente-servidor, chamadas VoIP usando SIP são gerados
pelo cliente e terminado em um servidor. Exemplo: um aplicativo cliente emite pedido
SIP, e um servidor emite uma resposta a esse pedido. Existem quatro tipos de
servidor: servidor proxy, servidor de redirecionamento, servidor de agente de usuário
e o servidor de registro.
A funcionalidade do servidor proxy é igual à de um servidor proxy usado para
web em redes locais (LAN), primeiro o cliente envia o pedido para o proxy, este
encaminha o pedido para outros servidores através de mensagens.
Um servidor de redirecionamento que suporta pedido SIP possui o mecanismo
de mapear o endereço de destino com os outros endereços da rede. Depois de
efetuado o mapeamento, um endereço é retornado ao destinatário. Com isso o
destinatário pode enviar pedido nesse novo endereço.
Um servidor de agente de usuário aceita pedidos SIP. O dispositivo SIP pode
funcionar como cliente usuário-agente ou servidor usuário-agente. Agindo como
cliente usuário-agente, este pode fazer um pedido SIP. Agindo como servidor
usuário-agente, este pode receber e responder pedidos SIP. Na prática isto significa
que o dispositivo SIP pode iniciar ou receber chamadas, e também pode ser usado
para comunicação peer-to-peer.
SIP tem o conceito de registro de usuário, com isso SIP suporta mobilidade
pessoal. Por exemplo, um usuário que possui um computador com um dispositivo
SIP instalado, ao conectar o computador na rede, este emite um pedido SIP
REGISTER para um registrador. Com isso chamadas poderão ser roteadas para o
computador registrado na rede. Quando é feita a troca de ambiente do computador é
necessário que um novo registro de dispositivo seja efetuado.
5
2.2 Estabelecimento de chamada SIP
O estabelecimento de chamada SIP mostrado na Figura 2.2, se inicia com a
mensagem SIP INVITE, a qual é enviada do emissor até o destinatário. Esta
mensagem convida o destinatário a participar de uma sessão. Depois da mensagem
SIP INVITE ter iniciado uma chamada, várias respostas intercalares podem ser feitas
antes do destinatário aceitar a chamada. Por exemplo, o emissor precisa manter-se
informado do status da chamada, se a chamada se encontra na fila ou se o
destinatário ainda não atendeu a chamada. Subseqüentemente, o destinatário
responde a chamada, que gera uma resposta OK para o emissor. O emissor então,
envia uma mensagem de ACK de reconhecimento para o destinatário. Após isso a
mídia é trocada, a troca mais comum é para uma mídia de discurso, mas também
pode ser trocado por um de vídeo. No final do discurso, ambos, o emissor ou o
destinatário podem enviar uma mensagem de BYE, a parte que receber o BYE emite
uma outra mensagem de OK, neste momento, a chamada é finalizada.
Figura 2.2: Exemplo de um fluxo de chamada[3]
2.3 Vantagens SIP sobre outros protocolos de sinalização
O estabelecimento e a liberação de chamadas são pontos fortes do protocolo
SIP. Qualquer protocolo de sinalização de chamada possui um meio onde é feita a
aceitação e a liberação de uma chamada. O fato de poder existir trocas de meio de
comunicação ou a troca do tipo de transporte durante uma sessão SIP, deixa claro
que o SIP provê mais flexibilidade do que as telefonias tradicionais. [3]
Mensagens SIP podem conter campos específicos de usuários, que possibilitam
ao usuário executar decisões inteligentes no tratamento de mensagens e
possibilitam também a implementação de futuros serviços inteligentes. Por exemplo,
6
suponha que uma chamada é direcionada para uma pessoa que não está presente.
O SIP RESPONSE irá indicar que o usuário está indisponível. Neste caso o terminal
poderá fazer duas coisas. Primeiro: o terminal pode responder que o destinatário
estará disponível somente às 16h. Segundo: após 16h o terminal perguntará se o
remetente deseja efetuar a chamada novamente, dependendo da resposta, a
chamada é efetuada automaticamente.[3]
2.4 Sintaxe mensagem SIP
SIP é um protocolo de sinalização que tem a sintaxe baseada em texto, usa um
conjunto de caractere International for Standardization Organization (ISO 10646) e
tem uma similaridade com o Hypertext Transfer Protocol (HTTP). A vantagem dessa
similaridade é que programas projetados para usar o HTTP pode ser adaptado
facilmente para ser usado com SIP. A desvantagem é a largura de banda
consumida. [3]
As respostas do servidor para o cliente e o pedido do cliente para o servidor que
usam as mensagens SIP, possuem um cabeçalho e o corpo da mensagem.
No cabeçalho da mensagem há informações do usuário como: criador da
mensagem, receptor da mensagem, informações do meio a ser carregado, tipo de
pedido ou sucesso/falha e as informações adicionais. [3]
No corpo da mensagem geralmente é descrito o tipo de sessão a ser
estabelecida e uma descrição da mídia a ser trocada. SIP não define uma estrutura
para o corpo da mensagem. A estrutura é obtida usando os protocolos disponíveis.
A estrutura mais comum para o corpo da mensagem é o Session Description
Protocol (SDP). De fato o corpo da mensagem pode conter diversas partes, cada
uma codificada para diferentes estruturas. [3]
Em algumas situações, esta capacidade pode ser usada para carregar uma
mensagem ISDN User Part (ISUP) no formato binário, habilitando o SIP a carregar
mensagens ISUP. SIP faz apenas o envio do corpo da mensagem de uma ponta a
outra. No caso de haver a necessidade de examinar o corpo da mensagem, apenas
as duas pontas estão habilitadas a executar esse papel. [3]
7
2.5 Pedido SIP
Existem seis métodos diferentes de pedido definido pela RFC 3261: Invite
(definido pela RFC 4235), Ack , Options, Bye, Cancel, e Register (definido pela RFC
3608). SIP define outros três métodos de pedido, como Info (definido pela RFC
2976), Refer (definido pela RFC 3515) e Update (definido pela RFC 3311).
O método Invite é usado para iniciar uma sessão de chamada entre duas partes
ou iniciar uma conference call. A mensagem criada por esse método, contém
informações do remetente, do destinatário e o tipo de mídia a ser trocada. [3]
O método ACK é usado para confirmar o recebimento de uma mensagem. [3]
O método Bye pode ser usado para encerrar uma sessão. [3]
O método Options pode ser usado para determinar se o usuário suporta um tipo
de mídia específico. Em outras palavras, esse método pode ser usado para
descobrir a capacidade do usuário. [3]
O método Cancel pode ser usado para cancelar um pedido que se encontra
pendente. Por exemplo, um Invite a espera de um ACK. [3]
O método Register é usado para o registro de usuários em servidores SIP,
facilitando a sua localização. [3]
Um cliente pode ter seu registro em vários servidores e um usuário pode possuir
múltiplos registros em um único servidor. Um usuário que possui múltiplos registros
para um único número, pode receber uma chamada através de todos os destinos
cadastrados. [3]
O método SIP Info significa a transferência de informação no meio de uma
chamada. Essa informação pode ser usada pelo usuário cliente, usuário servidor e
pelo proxy. [3]
2.6 Respostas SIP
O início de uma resposta SIP contém uma linha de status representado por 3
dígitos, esta linha indica o resultado da resposta de um pedido. Nesta linha também
contêm um texto de resposta que é interpretado e lido pelo software cliente.
O intervalo de numeração definido para representar o status no SIP é de 100 a
699, onde o primeiro dígito representa a classe de resposta.
- 1XX – provisório (por exemplo, o status 181 indica que uma chamada está
sendo enviada)
8
- 2XX – Sucesso (indica que um pedido foi aceito e executado)
- 3XX – redirecionamento (um exemplo, é quando uma parte chamada não se
encontra no endereço especificado no pedido e este endereço precisa ser editado
para um novo endereço incluído na resposta)
- 4XX – Falha (pode indicar que um pedido não foi aceito por causa da
autorização, endereço não encontrado, a necessidade da autorização, entre outros)
- 5XX – Falha no servidor (pode indicar que a versão do SIP não é suportada,
mensagem muito grande, problema interno no servidor, tempo excedido, entre
outros)
- 6XX – Problema global (pode indicar que um usuário não existe, todos os
lugares estão ocupados, e queda de uma rede)
2.7 Endereçamento SIP
No SIP o endereço de pedido e resposta são conhecidos como SIP Uniform
Resource Indicators (URIs). Esses endereços são similares com endereços de e-
mail, tem a forma de sip:user@host .
Para que a rede SIP opere com a rede tradicional de telefonia (comutada por
circuito), o SIP habilita a possibilidade de um número telefônico ser um endereço
SIP. Assim, o endereço SIP pode ficar sip: [email protected]. O endereço SIP
pode ser usado para criar um canal de comunicação a ser roteado entre um gateway
e a telefonia fixa. [3]
2.8 Seqüência da Mensagem SIP
Primeiro é feito o registro de um cliente, pelo envio do pedido REGISTER, este
registro é necessário para informar o servidor, do endereço a ser usado numa
sessão SIP. No pedido REGISTER contêm campos importantes, como: o endereço
propriamente dito, o protocolo de transporte a ser usado, e o tempo que o registro
deve ficar ativo. [3]
Segundo, o pedido INVITE é usado para iniciar uma sessão. Neste pedido é
incluso o endereço origem, o endereço destino, o tipo de mídia a ser usada. [3]
Após o envio do pedido INVITE, o chamador recebe uma resposta que o usuário
está sendo chamado. [3]
9
Subseqüentemente, o remetente pode receber uma outra mensagem de OK do
usuário, subseqüentemente, o remetente emite um ACK para confirmar o
recebimento da resposta. [3]
E por final, ocorrer o encerramento de uma sessão, com a emissão de um pedido
BYE por um dos usuários. [3]
Um exemplo de seqüência de mensagem é mostrado na figura 2.3.
Figura 2.3: seqüência de pedido SIP(estabelecimento e encerramento de uma chamada) [3]
10
3 ARQUITETURA IMS
“Esta sessão tem como referência o livro dos autores Miika Poikselkä, Georg
Mayer, Hisham Khartabil e Aki Niemi [The IMS – IP Multimedia Concepts and
Services – 2a. edição] [5] e também o livro dos autores Gonzalo Camarillo e Miguel
A. García - Martín [The 3G IP Multimedia Subsystem (IMS) – 2a. edição] [6].
Aqui encontra-se uma introdução a arquitetura IMS, os principais componentes
da Arquitetura IMS, e os casos (registro de usuário, chamadas e serviços) que serão
usados no estudo.“
No mundo móvel, o sistema de primeira geração (1G) foi introduzido em meados
da década de 1980. Esta rede oferecia serviços básicos para os usuários. Em 1990,
o sistema de segunda geração (2G) trouxe alguns serviços de dados e serviços mais
sofisticados para o usuário. A rede de terceira geração (3G) permite altas taxas de
transferência de dados e diversos serviços multimídia. [5]
O tradicional Public Switched Telephone Network (PSTN) e a rede Integrated
Services Digital Network (ISDN) dominaram a comunicação tradicional de voz e
vídeo. Nos últimos anos, o acesso a conexão rápida e barata a Internet aumentou
gradativamente, possibilitando a comunicação e jogos em tempo real. Esse acesso é
disponibilizado pela tecnologia ADSL (Asymmetric Digital Subscriber Line), o qual
permite transferência digital de dados e comunicação em alta velocidade via linha
telefônica.
Com o crescimento do número de dispositivos móveis, a convergência rápida de
fixo e o mundo móvel estão acompanhando esse crescimento. Estes dispositivos
móveis incluem câmera com alta resolução e qualidade, e diversos aplicativos de
entretenimento. Numa comunicação entre aplicativos desses dispositivos baseados
em IP (Internet Protocol) é necessário que o mesmo tenha o mecanismo que
encontre o correspondente. Atualmente, a rede de telefonia fornece esta tarefa de
estabelecer conexões em redes IP, porém, essa conectividade IP é oferecida
apenas em ambientes isolados. Há a necessidade de um sistema global, a solução
para isso é o IP Multimedia Subsystem (IMS). O IMS permite aplicações IP a
estabelecer conexões par-a-par, facilmente e segura. [5]
11
A rede 3G funde os dois paradigmas mais bem sucedidos na comunicação: a
rede de celular e a Internet. Para isso, foi desenvolvida a arquitetura IMS, que provê
acesso a todos os serviços de internet numa taxa de transferência rápida. [5]
As redes de comunicações existentes oferecem serviços de voz, vídeo e serviços
de mensagem usando circuito comutado. O IMS torna a comunicação mais elevada,
oferecendo um meio de comunicação mais enriquecida. Um usuário IMS é capaz de
misturar e unir uma variedade de serviços IP, da maneira que desejar durante uma
simples sessão de comunicação. Usuários podem integrar voz, vídeo e texto,
compartilhar dados e podem adicionar ou excluir serviços. Por exemplo, durante
uma sessão de voz entre duas pessoas, ambos podem adicionar outros aplicativos
(vídeo, e-mail e jogos) durante a mesma sessão. [5]
Além dessas vantagens mencionadas acima, a rede 3G com a arquitetura IMS
oferece também: QoS (Quality of Service), cargas, e integração de diferentes
serviços.
Uma das razões da criação do IMS, foi oferecer QoS exigido e sessões
multimídia em tempo real.
Outra razão para a criação do IMS é ser capaz de carregar sessões multimídia
apropriadamente. Numa videoconferência, geralmente uma grande massa de dados
é transferida, com isso, é necessário o controle de transmissão de dados. Em uma
sessão pode ser determinada a quantidade de bytes que cada mensagem deve ter
para ser transmitida. [5]
3.1 QoS para serviços multimídia
Na Internet, em algumas circunstâncias podem ocorrer atrasos, perdas ou
entrega de pacotes fora da ordem. Este não é o caso do IMS. No início de uma
sessão IMS, o equipamento do usuário (celular, notebook, PDA, etc) negocia alguns
parâmetros de QoS a serem utilizados durante a sessão, tais como: sua capacidade
de transferência via protoloco SIP (Session Initiation Protocol), o tipo de mídia,
direção do tráfego, taxa de transferência, tamanho do pacote, uso do protocolo RTP
e adaptação da largura de banda. Esses dados são essenciais para que o acesso à
rede seja feito de maneira apropriado.
Após ter criado uma comunicação com QoS fim-a-fim, o equipamento do usuário
codifica e empacota dados com um protocolo apropriado e os transporta usando o
protocolo da camada de transporte (ex. TCP ou UDP). [6]
12
3.2 Política IP – Uso correto dos recursos
O IMS usa a política de controle IP para controlar e autorizar o uso do tráfego. A
política de controle é dividida em três categorias:
- O controle de política é responsável por verificar se os parâmetros negociados
na sinalização SIP são os mesmos usados na ativação do trafego;
- O controle de política é também capaz de identificar o status do tráfego entre
as extremidades em uma sessão SIP no IMS;
- E, por último, o controle de política é capaz de receber notificação caso o
acesso ao serviço de rede tiver modificado, suspenso ou liberado o transporte
de um usuário associado a uma sessão. Isto permite que o IMS libere uma
sessão em progresso, caso o usuário não esteja mais na área de cobertura.
[6]
3.3 Componentes da Arquitetura IMS
A arquitetura IMS é a coleção de funções conectadas por interfaces
padronizadas. Fica a critério do usuário combinar duas funções em um único nó, e
vice-versa. [6]
Um simples exemplo com as interfaces mais relevantes da arquitetura IMS,
padronizadas pelo 3GPP é mostrado na figura 3.1.
Figura 3.1: uma visão da arquitetura IMS [6]
13
No lado esquerdo há o terminal IMS ou UE (equipamento eletrônico pelo qual o
usuário estará apto a receber e efetuar chamadas - podendo ser PDAs(Personal
Digitals Assistants), computadores, ou telefonia móvel). O terminal IMS liga com a
rede de pacote como uma rede GPRS (General Packet Radio Service) através de
um link ou rádio. Outras alternativas de acessos são: via WLAN (Wireless Local
Access Network) que é uma rede local sem fio, sua comunicação é feita via onda de
rádios e tem como restrição à distância dos equipamentos com o ponto de acesso;
ou via ADSL (Asymmetric Digital Subscriber Line), o qual permite transferência
digital de dados e comunicação em alta velocidade via linha telefônica.
No lado direito da figura são mostrados os nós conhecidos como núcleos do
subsistema da rede Multimídia IP. Os nós são:
- HSS’s (Home Subscriber Servers) banco de dados do usuário e SLFs
(Subscriber Locations Functions);
- CSCF’s (Call/Session Control Functions) servidores SIP;
- AS’s (Applications Servers);
- MRF’s(Media Resource Functions), divididos em MRFC (Media Resource
Function Controllers) e MRFP (Media Resource Function Processors);
- BGCF’s (Breakout Gateway Control Functions);
- PSTN gateways, cada um decomposto em um SGW (Signaling Gateway), um
MGCF (Media Gateway Controller Function), e um MGW (Media Gateway).
Cada um desses componentes é explicado nas subseções seguinte.
3.4 O HSS e o SLF
No HSS (Home Subscriber Server) são armazenados os dados do usuário
usados para controlar uma sessão multimídia. Esses dados são: informação do
local, segurança, informações do usuário e o S-CSCF alocado ao usuário, que age
como um servidor SIP, controlando sessões dos usuários registrados nele.
Nas redes que contêm mais de um HSS, é necessária a presença do
componente SLF (Subscription Locator Function), responsável em selecionar o HSS
que contêm as informações dos usuários. Para a seleção do HSS, o SLF utiliza o
endereço do usuário que está contido no cabeçalho do pedido.
14
3.5 O CSCF
O CSCF (Call/Session Control Function) é um servidor SIP e considerado um nó
essencial para a arquitetura IMS. O CSCF processa sinais SIP no IMS. Há 3 tipos de
CSCFs dependentes.
- P-CSCF (Proxy-CSCF).
- I-CSCF (Interrogating-CSCF).
- S-CSCF (Serving-CSCF).
3.5.1 O P-CSCF
O P-CSCF é o primeiro contato entre a rede IMS e o terminal IMS, é por ele que
trafegam todos os pedidos SIP gerados pelo usuário, e as respostas SIP destinados
ao usuário, isso significa que o P-CSCF age como um servidor proxy.
O P-CSCF possui diversas funções, algumas relacionadas a segurança. Um
exemplo, é a verificação da integridade de uma mensagem que pode ser feita
através do número de segurança IPSec estabelecido durante o registro de um
terminal IMS. [6]
Um outro mecanismo importante do P-CSCF é a verificação dos pedidos SIP.
Esta verificação é necessária para evitar a propagação de pedidos SIP fora do
padrão.
O P-CSCF também possui o mecanismo de compactar e descompactar
mensagens SIP. As mensagens SIP transmitidas numa conexão banda larga pode
ser considerada rápida, porém, a transmissão de uma mensagem SIP grande sobre
um canal de banda estreita pode levar alguns segundos. Nesses casos, o
mecanismo de compactar é útil para reduzir o tamanho da mensagem, e em
conseqüência disso, o tempo de transmissão da mensagem também é reduzido.
Uma mensagem que é compactada, a mesma é descompactada no outro extremo.
O P-CSCF pode ser encontrado na rede local ou em redes visitadas.[6]
3.5.2 O I-CSCF
O I-CSCF é um proxy SIP localizado na extremidade de um domínio
administrativo. O DNS (Domain Name System) possui o endereço do I-CSCF.
Esses endereços são usados pelo servidor SIP para encontrar o próximo salto SIP.
[6]
15
O I-CSCF também possui a opção de criptografar mensagem SIP, o I-CSCF
criptografa parte da mensagem onde contêm informações importantes, tais como o
número de servidores no domínio, seus nomes DNS, ou suas capacidades. Esta
funcionalidade é denominada como THIG (Topology Hiding Inter-network Gateway).
[6]
Uma rede incluirá tipicamente um número de I-CSCFs por motivo de
escalabilidade e redundância. O I-CSCF geralmente é localizado na rede local,
embora em algumas ocasiões especiais, tais como um I-CSCF(THIG), este possa
ser localizado em redes visitadas também.
3.5.3 O S-CSCF
O S-CSCF é o nó central do plano de sinalização. O S-CSCF é um servidor SIP,
que executa o controle de sessão e também age como um registrador SIP. O S-
CSCF mantém uma ligação entre o usuário local e o endereço do registro do usuário
SIP (também conhecido como uma Identidade de usuário público). [6]
O S-CSCF se comunica com o HSS para:
- O S-CSCF efetua o download do vetor de autenticação e o utiliza para a
autenticação do usuário no IMS;
- O S-CSCF usa o perfil de serviço incluído no perfil do usuário obtido do HSS
para criar uma mensagem SIP a ser direcionada através de um ou mais
servidor de aplicação;
- Informar o HSS qual é o S-CSCF alocado para o usuário durante o registro.
O S-CSCF tem a função de inspecionar todos os pedidos SIP que são enviados e
recebidos pelo terminal IMS, com isso, o S-CSCF é capaz de determinar se o pedido
SIP deve passar por um ou mais servidor de aplicação até cegar ao destino final.
O serviço principal do S-CSCF é oferecer o serviço de roteamento SIP. No caso
de um usuário discar um número através do SIP URI (Uniform Resource Identifier) o
S-CSCF executa a tradução, baseado em DNS E.I64 tradução do número (como
descrito em RFC 2916). [6]
Por motivo de escalabilidade e redundância, uma rede pode conter números de
S-CSCFs. Cada S-CSCF aulixia uma quantidade adequada de terminal IMS. O S-
CSCF está sempre alocado na rede local. [6]
16
3.6 O AS
O AS (Application Server) é uma entidade SIP que hospeda e executa serviços
Multimídia IP. Dependendo do atual serviço o AS pode operar no modo SIP proxy,
modo SIP UA (User Agent) (ex. endpoint), ou modo B2BUA SIP (Back-to-Back User
Agent) (ex. uma conexão de 2 SIP User Agents). O AS relaciona com o S-CSCF
usando SIP.
O AS está localizado na rede local ou na terceira parte de uma rede visitante, no
qual um usuário mantém um serviço. O AS estando fora da rede local, este não faz
interface com o HSS.[6]
3.7 O MRF
O MRF (Media Resource Function) fornece os recursos de mídia, tais como: tocar
anúncios, misturar fluxo, codificar/comunicar entre diferentes codecs, e análise de
tipo de mídias. O MRF possui o nó de sinalização chamado MRFC (Media Resource
Function Controller) e o nó de plano de mídia chamado MRFP (Media Resource
Function Processor). O MRFC possui uma interface com o S-CSCF e é responsável
em controla o recurso de mídia do MRFP. O MRFP é o responsável em implementar
as funções multimídia, tais como tocar e trocar mídia.[6]
O MRF sempre está localizado na rede local.[6]
3.8 O BGCF
O BGCF é um servidor SIP que é acionado apenas em casos que é necessário
selecionar uma rede apropriada, e rotear chamadas iniciadas de um terminal IMS à
um usuário de uma rede de circuito-comutado, tais como o PSTN, ou o PLMN.
3.9 O PSTN/CS Gateway
Os terminais IMS utilizam o serviço fornecido pelo PSTN gateway, para fazer e
receber chamadas de uma rede de circuito comutado. Na figura 3.2 é mostrado um
exemplo de interface do gateway PSTN com a rede PSTN. [6]
17
Figura 3.2: um exemplo do BGCF e um gateway PSTN que faz interface com a rede PSTN [6]
3.10 SGW
O SGW se comunicar com a rede CS, e efetua a conversão de protocolos. O
SGW pode pegar os dados que veio da rede CS pelo protocolo MTP e transportar
esses dados com o SCTP (Stream Control Transmission Protocol) sobre IP. [6]
3.11 MGCF
O MGCF é o nó central do gateway PSTN/CS, efetua a conversão de protocolos
e também faz o mapeamento SIP a um outro ISUP sobre IP. Além disso, o MGCF é
responsável também em controlar os recursos do MGW (Media Gateway), via
protocolo H.248. [6]
3.12 MGW
O MGW faz interface da rede PSTN ou CS com o plano de mídia. O MGW recebe
e envia mídia IMS sobre o protocolo RTP (Real Time Protocol). E também decodifica
codec’s que um terminal IMS recebe de uma rede CS. Isto ocorre quando o terminal
IMS não suporta o codec que está sendo usado.[6]
3.13 Registro/Autenticação
A arquitetura IMS possui diversos tipos de segurança. Duas delas são: a
autenticação entre o usuário e a rede, e os ASs (Aplications Server) entre o UE e o
P-CSCF. Estes procedimentos de autenticações são executados no momento do
registro do usuário.
A autenticação IMS é baseada num compartilhamento secreto e num número de
seqüência (SQN), disponível apenas no HSS e no cartão de aplicação ISIM (cartão
onde contêm os parâmetros de identificação e autenticação do usuário) do UE. O S-
CSCF é o responsável em executar o procedimento de autenticação e os
parâmetros relacionados a segurança. [6]
18
Numa sessão IMS, a UE que deseja se autenticar usa o cabeçalho HTTP para
transportar os dados de autenticação, dentro de um pedido REGISTER. Baseando
em alguns dados armazenados dentro da aplicação ISIM, a UE inclui no cabeçalho
de autenticação os principais dados:
- O campo username – onde é especificada a identidade privada do UE que está
se autenticando, esse dado é usado pelo S-CSCF e HSS selecionar um AV
correspondente ao usuário;
- Os campos realm e URI, cujos identificam o domínio do usuário;
Os campos nonce e response, porém vazios. Esses campos são obrigatórios pelo
HTTP Digest, mas não são usados no pedido REGISTER inicial.
Figura 3.3: Fluxo de Autenticação e Registro no IMS
Na figura 3.3 é mostrado o procedimento de registro e autenticação de um UE
IMS, o UE emite um pedido REGISTER na rede, o P-CSCF recebe esse pedido e
encaminha para o I-CSCF responsável em localizar um S-CSCF adequado para o
UE. O S-CSCF baseado nos dados do pedido, efetua o download do AV do HSS. O
S-CSCF então encaminha alguns dados do AV ao UE, numa resposta com status
401 (Unauthorized). A resposta percorre o mesmo caminho de ida para chegar até o
UE.
No AV há alguns parâmetros que habilitam o S-CSCF a executar a autenticação
sem saber o SQN, esses parâmetros são: um desafio aleatório (RAND); o resultado
esperado (XRES), o token de autenticação da rede (AUTN), uma chave de
integridade (IK) e a chave de cálculo (CK).
19
Quando o P-CSCF recebe a resposta 401(Desautorizado), este remove dois
parâmetros (CK e o IK) da resposta antes de enviar para o UE. O IK é usado para
estabelecer uma comunicação entre o P-CSCF e o UE.
Quando o UE recebe a resposta, este entrega os parâmetros recebidos para a
aplicação ISIM, que:
- Verifica o AUTN baseado no compartilhamento secreto e o SQN – caso a
verificação do AUTN seja executada com sucesso, a rede é autenticada;
- Efetua o cálculo do resultado (RES) baseado no parâmetro RAND recebido e
no compartilhamento secreto;
- Efetua o calculo do IK, o qual é compartilhado entre o P-CSCF e o UE e servirá
como base para estabelecer o IPSec do SAs, por onde o UE enviará o segundo
pedido REGISTER.
Após o ISIM do UE ter executado esses três procedimentos com sucesso, o UE
envia um outro pedido REGISTER para o S-CSCF com os campos anteriormente
enviados, e mais um campo adicional, que contêm a resposta de autenticação
(RES).
O P-CSCF recebe o pedido, verifica a integridade, em caso de sucesso o P-
CSCF envia o pedido REGISTER para o I-CSCF.
Ao receber o segundo pedido REGISTER, o S-CSCF compara o RES com o
XRES. Caso essa comparação seja executada com sucesso, o S-CSCF irá executar
o processo de registro do usuário, e retornará uma resposta 200 (OK) para o UE.
A cada nó (UE, P-CSCF, I-CSCF e S-CSCF) que o pedido REGISTER visita, são
adicionados novos campos com seus respectivos endereços. Isso facilita com que a
resposta desse pedido faça o mesmo percurso. No retorno da resposta, os nós tiram
os campos que possuem seus respectivos endereços.
3.14 Acesso Seguro – IPsec ASs
Durante o processo de registro, dois pares de IPsec SAs (referidos como “jogo de
SAs”) são estabelecidos entre o UE e o P-CSCF. Os pares de IPsec SAs são
apenas associações lógicas entre o UE e o P-CSCF que permite a troca segura de
mensagens SIP.
20
Figura 3.4: Estabelecimento de AS durante um registro inicial
Conforme podemos ver na figura 3.4 os jogos de SAs necessitam de 4 portas:
- A porta cliente protegida no UE (uc1);
- A porta servidor protegida no UE (us1);
- A porta cliente protegida no P-CSCF (pc1);
- A porta servidor protegida no P-CSCF (ps1).
Essas portas são negociadas durante o registro inicial, pelo UE e o P-CSCF,
usando os cabeçalhos do Mecanismo de Serviço Seguro do SIP. Para o
estabelecimento dessas portas o UE e o P-CSCF precisam de uma chave
compartilhada. Conseqüentemente, o P-CSCF utiliza o parâmetro IK (Integrity - Key)
recebido da resposta 401 (Desautorizado), como a chave compartilhada para obter o
jogo de SAs, e o UE, baseado no desafio recebido na resposta 401 (Desautorizado)
efetua o calculo do IK. Feito isto o UE usa o IK como a chave compartilhada para
obter o jogo de SAs.
Por meio do IK, o P-CSCF e o UE podem estabelecer o jogo de SAs entre as
quatro portas que foram negociadas no pedido REGISTER inicial, resultando em:
21
- enviar pedido SIP do UE para o P-CSCF, entre uc1 e ps1;
- enviar resposta do P-CSCF para o UE, entre uc1 e ps1;
- enviar pedido SIP do P-CSCF para o UE, entre us1 e pc1;
- enviar resposta SIP do UE para o P-CSCF, entre uc1 e ps1.
Por meio do estabelecimento dos jogos de SAs, o UE enviará todas as respostas
e pedidos subseqüentes, porém, o UE só poderá usar esse jogo de SAs após o
procedimento de autenticação entre o UE e o P-CSCF estiver concluído. O
procedimento de autenticação só é finalizado após o recebimento da resposta
200(OK) pelo UE.
3.15 Estabelecimento de uma sessão
Figura 3.5: Estabelecimento de sessão na Arquitetura IMS
Para o estabelecimento de uma sessão de chamada no IMS é necessário que os
usuários estejam registrados no S-CSCF. Na figura 3.5 é mostrado a criação e o
encerramento de uma sessão entre dois usuários de redes distintas.
Para o usuário Marcio iniciar uma conversa com a Alice, o UE de Marcio emite
um pedido INVITE com destino ao UE de Alice, este pedido primariamente passa
pelo P-CSCF, que verifica se o pedido foi recebido sobre um IPsec AS válido,
garantindo que sim, o P-CSCF envia o pedido INVITE para o S-CSCF. Ao receber o
22
pedido, o S-CSCF verifica o estado do registro e a autenticação da identidade do
usuário. Feito isso, o S-CSCF cria rota para a rede de Alice.
Para a criação de rota entre as redes, o S-CSCF envia o pedido para o I-CSCF,
responsável em localizar e enviar o pedido para o S-CSCF onde o UE de Alice está
registrado. Ao receber o pedido INVITE, o S-CSCF de Alice verifica a integridade do
pedido e subseqüentemente encaminha o pedido para o P-CSCF de Alice. O P-
CSCF checa o pedido e o encaminha para o UE de Alice.
Durante esse processo de envio do pedido entre os nós (UE, P-CSCF, S-CSCF,
I-CSCF), cada nó na medida que recebem o pedido, encaminham o pedido para o
nó seguinte e emite uma resposta com status (100) Trying para o nó anterior, cujo
qual enviou o pedido. Esse processo também ocorre quando o UE de Alice recebe o
pedido, o UE emite duas respostas, uma com status (180) Ringing e a outra com
status (200) OK, com destino ao UE de Marcio. Estas respostas passam pelos
mesmos nós que o pedido INVITE passou.
Quando o UE de Marcio recebe a resposta (200) OK, o mesmo envia uma
resposta ACK para o UE de Alice, finalizando a criação de uma sessão.
Para encerrar a sessão um pedido BYE é emitido pelo UE de Marcio com destino
ao UE de Alice. E por final UE de Alice responde com uma resposta de (200) OK,
encerrando a sessão.
3.16 Serviços
Durante o processo de registro do usuário, o S-CSCF efetua o download do perfil
do usuário do HSS, onde contém a lista organizada por prioridade de serviços que o
usuário tem acesso e os ASs adequados para executar cada serviço. Com base
nessa lista, o S-CSCF ao receber uma solicitação de serviço em um pedido de
criação de sessão (INVITE, OPTIONS, SUBSCRIBE, etc), seleciona e envia o
pedido ao AS adequado a executar o serviço.
Um exemplo de solicitação de serviço é mostrado na figura 3.6. Após o registro
do usuário Marcio, um pedido INVITE é emitido. Este pedido passa primeiro pelo P-
CSCF que o encaminha para o I-CSCF, que seleciona o S-CSCF alocado para o
usuário Marcio. Ao receber o pedido, o S-CSCF encaminha o pedido para o AS
adequado. O AS, ao receber o pedido pode apenas executar o serviço e retornar
uma resposta de OK para o S-CSCF, como também pode solicitar o serviço do
MRFC. Neste exemplo o AS apenas executou o serviço e retornou a resposta 200
23
(OK) para o S-CSCF. A resposta 200(OK) passou pelos mesmos nós até chegar no
UE do Marcio.
Figura 3.6: Exemplo de solicitação e execução de serviço
3.17 Estudo
Da arquitetura estudada nessa sessão, serão usados nos testes e nas análises
do estudo: o registro de usuário, descrito no tópico 3.15; o estabelecimento de uma
sessão, descrito no tópico 3.16; e a solicitação de serviço descrito no tópico 3.17.
Para isso, é importante que haja o bom entendimento dos componentes da
arquitetura IMS que farão parte do estudo, tais como: o UE, o S-CSCF, o DNS, o
HSS e o AS, descrito na sessão 2.3.
24
4 ASTERISK
O Asterisk é um software PABX de código aberto, que foi primariamente
desenhado para rodar no Linux. O nome Asterisk veio da idéia do seu criador Mark
Spencer em 1999. A idéia dele era que esse software se tornasse um coringa da
telefonia, se baseando no símbolo que é muito usado em sistemas. [2]
Além dos serviços (envio de mensagens, monitoramento, chamada em espera,
música de espera, opção de conferencing call, etc) disponibilizados pelos PABX
padrão, o Asterisk pode oferece recursos avançados com um custo menor
comparando-se com os do PABX proprietários. Uma das vantagens do Asterisk
sobre outros softwares é a forma de como foi desenhada a sua arquitetura, o
Asterisk suporta a voz sobre IP em diversos protocolos, e também pode ser
integrado com outras tecnologias, tornando-se uma poderosa plataforma
convergente de telefonia flexível.
O Asterisk pode se conectar com o mundo afora, via interfaces analógicas,
circuitos digitais e via protocolos VoIP (SIP, H.323 e IAX).
4.1 Requisitos
O software Asterisk pode ser instalado em plataformas Linux e em algumas
plataformas não Linux. O requisito de uma máquina para operar com o Asterisk não
depende de números de usuários, mas sim pelo número de canais a ser suportados
simultaneamente.
Em uma instalação grande em que envolva o Asterisk, é comum que haja mais
de uma central para o processamento de chamadas e tarefas, com isso, quando um
servidor Asterisk está de posse de diversos processamentos de chamas e tarefas
periféricas, este servidor pode distribuir as tarefas para outros servidores presentes.
4.2 Configuração SIP
O objetivo deste protocolo é ajudar no início, durante e no encerramento de uma
chamada. Seguindo as mudanças (transferências de chamada) durante a chamada.
O protocolo SIP é simplesmente um protocolo de sinal, no entanto ele não
carrega mídias (voz). O transporte das mídias entre os pontos é feito pelo protocolo
chamado Real-Time Transport Protocol (RTP).
25
4.2.1 SIP.CONF
A configuração do SIP no Asterisk é feita no arquivo sip.conf.
O arquivo sip.conf contêm parâmetros relacionados a configuração do acesso do
cliente SIP ao servidor Asterisk. Os clientes precisam ser configurados aqui antes,
para serem capazes de receber e fazer chamadas usando Asterisk. Abaixo um
exemplo básico e funcional do arquivo sip.conf.
[general] context=default ; bindaddr=192.168.0.1 [1000] type=friend context=test secret=password host=dynamic
O arquivo sip.conf pode possuir n sessões, são nas sessões que são definidos,
habilitados e configurados os serviços de cada ramal ou usuário.
A primeira seção do arquivo sip.conf [general] vem definida como default, esta
seção é usada para todos os clientes SIP e troncos.
A segunda seção ou cliente, no nosso exemplo é nomeada como [1000]. Para a
nomeação, pode-se usar qualquer tipo de nome.
Nas duas seções há o parâmetro context, neste parâmetro é especificada a
localização das instruções a serem usadas em chamadas recebidas. O nome
definido aqui deve ser igual ao que é definido no arquivo (extensions.conf) que
contém as instruções.
No parâmetro bindaddr é especificado o endereço IP a ser esperado por uma
conexão SIP.
No parâmetro secret, é especificado uma senha para autenticação, uma
segurança a mais.
No parâmetro type é configurado se o cliente está apto a enviar e receber
chamadas - se type definido como friend. Há também mais duas opções para esse
parâmetro: user, é configurado para fazer chamadas através do servidor Asterisk ; e
o peer é configurado para receber chamadas do servidor Asterisk. [2]
26
O parâmetro host é usado para definir a localização de um cliente na rede,
quando o Asterisk precisa enviar uma chamada. Este parâmetro pode ter um
endereço especificado ou pode estar como dynamic. Quando host está definido
como dynamic, e o cliente está configurado para se registrar, o Asterisk receberá o
sinal de REGISTER com o endereço IP que o cliente está usando. [4]
4.3 Configuração do Plano de discagem
O plano de discagem é especificado no arquivo extension.conf. Neste arquivo
contém as lógicas (canais com aplicações e serviços) inteligentes de roteamento de
chamadas.
O plano de discagem é formado por: contextos, extensões, prioridades e
aplicações.
4.3.1 Contexto
O plano de discagem é dividido em seções denominados contextos. Os contextos
não se comunicam entre si, uma extensão definida em um contexto é
completamente isolada das extensões de outros contextos, a menos que iterações
sejam definidas. [2]
O plano de discagem possui dois contextos especiais e padrões chamados
[general] e [globals]. Nestes contextos contêm algumas definições de variáveis
globais e uma lista de configurações do Asterisk, esses dados podem ser acessados
por qualquer usuário que tenha acesso ao servidor Asterisk.
A nomeação ou a definição de um contexto é colocada entre [], que pode ser feita
por caracteres ou números. As instruções do contexto são colocadas logo abaixo de
seu nome e elas só acabam quando é definido um próximo contexto ou em branco.
[2]
4.3.2 Extensões
Extensões definem uma série de etapas que o Asterisk deve seguir para
completar uma chamada. Dentro de cada contexto pode ser definida inúmera
extensão, conforme a necessidade.
[general]
.....
[teste]
27
.....
O parâmetro usado para definir extensões é exten. Uma extensão completa
possui 3 partes: o nome ou número da extensão, a prioridade e a aplicação. No caso
de aplicações que necessita de argumentos de entrada, um quarto componente é
incluso na definição de uma extensão.
Exemplo de extensão:
exten => 999, 1, Answer()
exten => 999, 2, Hangup()
Veja que cada parte ou componente da extensão é separado por vírgulas.
4.3.3 Prioridades
Conforme mencionado no tópico anterior, um contexto pode possuir várias
extensões. Quando essas extensões fazem partes de um único ramal, ou, uma
extensão possui várias etapas, essas precisam ser ordenadas por prioridades, para
que o Asterisk reconheça qual extensão ele deve executar primeiro, e qual será a
próxima a ser executada.
Nas versões recentes do Asterisk, não há a necessidade de numerar as
prioridades, basta colocar o caracter ‘n’ neste componente. Internamente o Asterisk
calcula a próxima prioridade toda vez que encontrar o caracter ‘n’. Importante
observar que apenas na primeira extensão de um contexto é necessário colocar o
numero 1 no componente prioridade.
Exemplo de prioridade
exten => 999,1,Answer() exten => 999,n,do something exten => 999,n,Hangup()
4.3.4 Aplicação
As aplicações são eventos executados no plano de discagem. Essas aplicações
podem ser: tocar som, fazer uma chamada, atender uma chamada, espera, etc.
As aplicações podem ser dependentes ou independentes de argumentos. Os
argumentos são passados para a aplicação, no intuito de informar como a aplicação
deve ser executada. Esses argumentos são passados entre parênteses, seguido de
suas aplicações e separados por vírgula.
Exemplo do uso da aplicação:
exten => 999,1,Answer()
28
exten => 999,1,Playback(hello-world)
Aplicações: Answer(),Hangup(), Playback(),Background(), WaitExten(),Goto()
4.4 O Gateway de Interface do Asterisk (AGI)
O Gateway de Interface do Asterisk fornece uma interface padronizada para que
programas externos possam se comunicar com o plano de discagem do Asterisk.
Tornando fácil a implementação de lógicas avançadas, a comunicação com banco
de dados externos (tais como MySQL) e iteração com outros servidores de
aplicação. Os scripts AGI’s podem ser escritos em quase todas as linguagens de
programação: Java, PHP, Perl, dentre outras.
4.4.1 Fundamentos da Comunicação AGI
A comunicação do script AGI e o Asterisk é feito via canais de comunicação
conhecidos como STDIN, STDOUT, e STDERR.
STDIN, STDOUT, e STDERR são canais por onde informações são recebidas e
enviadas de/para um programa externo. STDIN é usado em scripts AGI, para obter
informações do Asterisk, via teclado ou programa. STDOUT é usado para enviar
dados para o Asterisk. E para finalizar, o STDERR é usado para escrever
mensagens de erro para o console do Asterisk. [2]
4.4.2 O modelo de comunicação AGI
A comunicação entre o script AGI e o Asterisk segue um padrão predefinido. O
script AGI recebe do Asterisk uma lista de variáveis e seus respectivos valores. As
variáveis devem se parecer como segue abaixo:
agi_request: test.py agi_channel: Zap/1-1 agi_language: en agi_callerid: agi_context: default agi_extension: 123 agi_priority: 2
Após o envio da ultima variável, o Asterisk envia uma linha em branco, para
sinalizar ao script AGI que é a vez dele controlar o plano de discagem. A partir daí, o
script AGI começa a escrever e enviar comandos para o Asterisk, no STDOUT. A
cada comando recebido, o Asterisk envia uma resposta ao script AGI. Esta ação de
envio e resposta pode ocorrer até o termino da execução do script AGI.
29
4.4.3 Chamando um script AGI do Plano de discagem
Para usar um script AGI no plano de discagem, é necessário chamar o script AGI
usando o aplicativo AGI(). Igual o exemplo abaixo:
exten => 999,1,Answer( )
exten => 999,n,AGI(agi-test.agi)
Geralmente, os scripts AGI’s são armazenados em um diretório padrão do
Asterisk (/var/lib/asterisk/agi-bin), caso o script não esteja armazenado nesse
diretório, é necessário especificar o endereço completo do script AGI, para que o
plano de discagem possa encontrar.
4.5 Estudo
Nesse capítulo foi estudado a arquitetura do Asterisk. Desse capítulo, para o
nosso estudo, será usado a configuração do SIP e do Plano de discagem e o AGI,
mostrado nos tópicos 4.2, 4.3 e 4.4 respectivamente.
30
5 TESTE / ANÁLISE
O foco principal do teste foi comparar a comunicação e o desempenho do
software Asterisk com a arquitetura IMS se comunicando via protocolo SIP. Para
essa comparação foram definidos 3 casos de testes: registro do usuário,
encaminhamento de chamadas e serviços.
A comparação foi feita usando uma plataforma de referência, o SDS[7] e uma
rede de teste montada como explicado a seguir.
No primeiro ambiente de teste, foi montada uma conexão entre duas máquinas,
onde cada uma possuía o sistema operacional Linux Fedora 9 e os softwares:
Asterisk versão 1.4.22 [8], MySQL versão 5.0 [9], servidor web Apache versão 2.2.9
[10], linguagem PHP versão 5.2.6 [11], Wireshark versão 1.1.0 [12], e o X-Lite versão
3 [13].
No segundo ambiente, foi instalado o software SDS da Ericsson numa máquina
com o sistema operacional Windows Vista.
5.1 Ambiente de Teste com Asterisk
Para o teste deste ambiente, foi utilizada a arquitetura proposta no estudo do
Marcelo Moraes, 2007 [17], onde ele propôs uma arquitetura com softwares de
código aberto para implementar serviços em redes convergentes multimídia para
controle de clientes SIP.
Depois da instalação dos softwares, foi efetuada a configuração do Asterisk e do
X-Lite, possibilitando uma comunicação entre eles. No lado do Asterisk, foi
configurado o plano de discagem (/etc/asterisk/extension.conf – Anexo B), e o SIP
(/etc/asterisk/sip.conf – Anexo A). E no lado do X-Lite foram configurados os
números a serem chamados e também foi atribuído o IP do servidor Asterisk.
Os números configurados no X-Lite foram os mesmos configurados no plano de
discagem. Para o usuário Marcio foi atribuído o número 1000 e para Alice o número
1001.
Antes de inserir serviços para o usuário no plano de discagem, foi efetuado um
teste de comunicação simples entre os X-Lites para verificar se o Asterisk estava
conseguindo fazer os dois se comunicarem. Um grande desafio encontrado aqui, foi
31
no momento da não comunicação, foi identificar se o problema estava no plano de
discagem ou na configuração do X-Lite.
Depois de ter conseguido uma comunicação entre o Asterisk e o X-Lite, o
próximo passo dado no teste foi, a comunicação do Asterisk com o banco de dados
MySQL, para isso, foi montado um script AGI e implementado-o no plano de
discagem do Asterisk. O ambiente ficou igual a Figura 5.1.
Figura 5.1: Comunicação entre dois usuários usando Asterisk
Antes de efetuar um teste unitário do Apache com o MySQL e o PHP, foram
efetuados testes desses softwares separadamente, para verificar se ambos estavam
operando corretamente. Para isso, foram executados os testes básicos que as
próprias fabricantes disponibilizam em seus sites.
Efetuados os testes acima, foi dado início à configuração de serviços no plano de
discagem dos usuários.
5.1.1 – Configuração de Serviço
Os serviços configurados no plano de discagem dos usuários são partes do
programa de um exemplo em PHP disponível em Meggelen, 2005[16]. Com base
nesse exemplo, foram montados dois scripts AGIs em PHP (Anexos C e D). Um
script que ativa e desativa o serviço “Não Perturbe” e o outro que verifica se o
usuário está com o serviço ativado.
O primeiro script foi configurado no plano de discagem para que ativasse ou
desativasse o serviço não perturbe quando o usuário discasse o número 123. A
ativação do serviço era efetuada com a atribuição do carácter “1” no campo flag do
banco de dados. A desativação do serviço era efetuada ao retirar o carácter “1”.
exten => 5769,n,AGI(ativa_servico.agi)
32
O segundo script foi configurado no plano de discagem para ser executado
quando o Asterisk recebesse um pedido INVITE de início de sessão destinado ao
um dos usuários. A função do script era verificar no banco de dados se o usuário
chamado estava com o serviço de não perturbe ativado. Caso não estivesse era
dado continuidade ao processo de início de sessão.
exten => 5769,n,AGI(valida_servico.agi)
O processo para executar os scripts é mostrado na Figura 5.2:
Figura 5.2: Fluxo da execução de script AGI
Nos testes de serviço, o grande desafio foi encontrar o problema encontrado na
comunicação do Asterisk com o script AGI. O script AGI não executava e também
não retornava erro. Nesse ponto, o problema era maior, por que já envolvia dois
servidores e com vários softwares rodando, um dependendo do outro. O método
adotado para encontrar esse problema foi testar as aplicações separadamente, e
conforme ia obtendo sucesso nos teste, a arquitetura foi reconstruída até voltar a ser
a arquitetura inicial ao teste.
5.1.2 – Resultados
Após ter tido sucessos nos testes, os mesmos foram executados novamente,
para que fosse possível a obtenção dos fluxos de mensagens SIP que ocorreram no
início, durante e no encerramento de sessões. As capturas dos fluxos das
mensagens foram feitas pelo software Wireshark, este software foi configurado para
capturar apenas pacotes UDP, o protocolo de transporte que o Asterisk usa para
transportas as mensagens SIP.
Com o software Wireshark, foi possível obter dois tipos de resultados, o resultado
em tela, que mostrou em tempo real o envio e o recebimento dos pacotes. Esse tipo
33
de resultado pode ser visto na Figura 5.3 e 5.4. Outas telas de resultado podem ser
encontradas no Anexo E.
Figura 5.3 : Pacotes UDP capturados no registro dos usuários e no início de uma sessão SIP
34
Figura 5.4: pacotes capturados após uma sessão SIP ter iniciado
O outro tipo de resultado do Wireshark foi obtido em modo texto. No final da
captura foi gerado um arquivo texto com todos os pedidos e respostas SIP. Abaixo é
mostrado um trecho desse arquivo. O log inteiro do Wireshark pode ser encontrado
no Anexo F.
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 422 Checksum: 0x5746 [correct] Session Initiation Protocol Request-Line: REGISTER sip:192.168.0.3 SIP/2.0 Method: REGISTER Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.0.4:5060;rport;branch=z9hG4bK05B63B2DBDBF436E364113B320FA597A From: 1001 <sip:[email protected]>;tag=207460698 SIP Display info: 1001 SIP from address: sip:[email protected] SIP tag: 207460698 To: 1001 <sip:[email protected]> SIP Display info: 1001 SIP to address: sip:[email protected] Contact: "1001" <sip:[email protected]:5060> Contact Binding: "1001" <sip:[email protected]:5060> URI: "1001" <sip:[email protected]:5060> SIP Display info: "1001" SIP contact address: sip:[email protected]:5060 Call-ID: [email protected] CSeq: 55783 REGISTER
35
Expires: 1800 Max-Forwards: 70 User-Agent: X-Lite release 1105d Content-Length: 0
Neste trecho contêm o pedido REGISTER gerado e enviado pelo X-Lite do
usuário 1001 ao 1000. Neste pedido contêm todos os cabeçalhos do pedido SIP que
o Asterisk precisará para registrar o usuário.
Com base no estudo teórico e nos fluxos de pedidos e respostas capturados pelo
Wireshark, foi montado a Figura 5.5.
Figura 5.5: fluxo de uma sessão entre dois usuários
Conforme podemos observar na Figura 5.5, no momento em que os X-Lites
conseguiram se conectar ao servidor PABX Asterisk, os X-Lites emitiram pedidos
REGISTERs para o Asterisk. Com base nos dados dos pedidos REGISTER o
Asterisk respondeu esses pedidos com o status “Trying” (nesse momento o Asterisk
36
verificou se os usuários estavam configurados no arquivo sip.conf ) e logo em
seguida emitiu respostas de OK. A partir daí ambos já estavam aptos a executar
chamadas entre eles.
Após o registro, foi ativado o serviço de não perturbe para o terminal de Alice.
Esse processo se iniciou ao digitar 123 e ao clicar no botão do X-Lite da Alice. Um
pedido foi gerado e enviado para o servidor Asterisk, que ao receber, executou o
script do plano de discagem da Alice.
Alice não estava apta a receber chamadas, para verificar realmente se o serviço
estava ativado, do terminal do Marcio foi discado o ramal de Alice e tentado iniciar
uma chamada. Um pedido INVITE foi gerado e enviado para o servidor Asterisk, que
ao receber, executou o script AGI do plano de discagem da Alice, que verificou se a
Alice estava apta a receber ligações. Como o serviço “não perturbe” estava ativado
para ela, o servidor Asterisk retornou uma resposta para o usuário Marcio.
Após alguns segundos foi desativado o serviço de não perturbe da usuária Alice,
depois de discado o número 123 e clicado no botão , um pedido foi gerado e
enviado ao servidor do Asterisk, que executou o script AGI, desativando o serviço
não perturbe. Para testar se o serviço tinha sido desabilitado, novamente foi tentado
criar uma chamada do usuário Marcio para a Alice.
No terminal do usuário Marcio, foi discado o ramal de Alice e clicado no botão
chamar . Com essa ação, um pedido INVITE foi enviado para o usuário Alice. Este
pedido, antes de chegar ao destinatário final, passou pelo servidor Asterisk, que ao
receber o pedido, executou o script AGI, configurado no plano de discagem da Alice,
verificando se o serviço de “não perturbe” estava ativado. Como o serviço não
estava ativado, o servidor Asterisk encaminhou o pedido INVITE para o usuário
Alice, que em conseqüência disso, enviou duas respostas para o usuário Marcio,
uma com status RINGING e outra com status 200 (OK). E por final, uma resposta
ACK foi enviada pelo terminal do Marcio após o recebimento da resposta 200 (OK).
Ambas passaram pelo servidor Asterisk antes de chegar ao destinatário final. Nesse
momento a sessão foi criada, e ambos ficaram aptos a conversar.
Para finalizar a sessão, o usuário Marcio clicou no botão , que resultou no envio
do pedido BYE para o usuário Alice, tendo que passar pelo servidor Asterisk. Ao
receber esse pedido, o usuário Alice emitiu um pedido OK para o usuário Marcio,
que o mesmo também passou pelo servidor Asterisk.
37
5.2 Ambiente de Teste com SDS
Aqui é descrito o ambiente de teste utilizado para obter os resultados dos casos
de testes na arquitetura IMS.
Para o teste, foi utilizado o aplicativo “Start Test Agent” e o “Automated Testing
Framework” do software SDS (Service Development Studio) versão 4.1
disponibilizado pela Ericsson [7] O SDS usa o Eclipse como ambiente de
desenvolvimento e Java, versão JDK 1.5 [14] como linguagem de programação.
Além dos softwares especificados acima, foi necessário a instalação e a
configuração do servidor GlassFish versão 2 [15] no Eclipse.
A instalação do SDS vem com todas as dependências prontas para serem
instaladas, o que facilitou na hora da instalação. Restou apenas selecionar as quais
seriam utilizados nos testes. A Figura 5.6 mostra essa tela inicial da instalação.
Figura 5.6: Tela inicial de instalação SDS
Depois de instalado e configurado o SDS, foi dado início à montagem do
ambiente de teste no SDS. O passo seguinte foi configurar o DNS, os serviços e os
proflies dos usuários (menu SDS -> Server -> Provisioning). A Figura 5.7 mostra o
caminho seguido para efetuar essas configurações.
38
Figura 5.7: Caminho para iniciar o Provisioning
O DNS foi configurado primeiro, comforme é apresentado na Figura 5.8. Aqui, foi
configurado os DNSs que foram usados nos endereços públicos dos usuários.
Figura 5.8: Tela configuração de DNS
O próximo passo foi dado com a configuração e inclusão dos usuários no HSS. A
tela de inclusão de usuários é mostrada na Figura 5.9. Um ponto importante que foi
destacado é que o endereço DNS configurado na identidade pública do usuário
precisa estar cadastrado na “aba DNS”, porém o SDS não mostrou uma mensagem
de erro quando foi inserido um DNS que ainda não tinha sido cadastrado.
39
Figura 5.9: Tela de criação do Profile do usuário
Na Figura 5.10 é mostrada a tela onde foram adicionados e atrelados os serviços
dos usuários.
Figura 5.10: Tela de cadastro de serviços
Para evitar problemas futuros nos testes, foi necessário tomar alguns cuidados
nessa etapa inicial. Os cuidados foram: cadastrar os DNSs que foram especificados
na identidade pública dos usuários; cadastrar serviços corretamente somente para
os usuários que já tinham sido cadastrados; e como foi a primeira experiência com o
40
software SDS, para efetuar as configurações e os testes, foi seguido o manual que o
próprio desenvolvedor do SDS disponibiliza.
Concluído a etapa de configuração, foi necessário iniciar o servidor CSCF, o DNS
(menu SDS -> CSCF -> Start CSCF e SDS -> DNS -> Start DNS ) e o servidor
GlassFish, para dar início aos três casos de testes.
Na figura 5.6 é mostrado o ambiente de teste construído dentro do SDS, onde
temos dois usuários se comunicando em uma mesma rede e no mesmo domínio
usando arquitetura IMS.
Figura 5.11: Comunicação entre dois usuários usando arquitetura IMS
Depois de iniciado os servidores. Foi dado início aos testes. Para isso foi
necessário iniciar o aplicativo “Start Test Agent”, conforme pode ser visto na Figura
5.12.
Figura 5.12: Caminho para iniciar o “Start Test Agent”
A Figura 5.13 mostra a construção do pedido REGISTER, essa construção tomou
como base os dados que foram imputados nos campos de entrada localizados no
lado esquerdo da figura. A criação do pedido foi finalizada ao clicar no botão “OK”.
No lado esquerdo da Figura 5.14, podemos ver o pedido que foi gerado e enviado
ao clicar no botão “Send Message”, no canto superior direito da figura é mostrado o
41
pedido que o servidor CSCF recebeu e na parte inferior é mostrado a resposta do
servidor CSCF, nesse caso foi “200 OK”.
Esse mecanismo de criação de pedidos e o retorno de respostas foi utilizado
durante todo o teste até obter o resultado de todos os casos de testes.
Figura 5.13: Construção de um pedido REGISTER no SDS
Figura 5.14: Envio do pedido REGISTER e retorno de resposta 200 OK.
42
Na Figura 5.15, são mostrados os fluxos de pedidos e respostas obtidos nos
casos de testes.
Figura 5.15: fluxo de pedidos e respostas SIP usando IMS
Conforme a figura 5.15, o primeiro passo para obter a comunicação entre os
usuários, foi efetuado no registro e na autenticação dos usuários no servidor CSCF.
Para isso, os usuários emitiram pedidos REGISTER ao servidor CSCF, que ao
receber, fez a verificação da existência do domínio no servidor DNS. Após isso o
servidor CSCF consultou o HSS se os usuários possuíam um Profile e se o mesmo
estava autenticado, como os usuários não estavam autenticados, o CSCF enviou
uma resposta de status “401 (Unauthorized)” com os parâmetros de autenticação.
Os usuários ao receberem a resposta, estes efetuaram o cálculo de autenticação e
enviaram um segundo pedido REGISTER com o resultado para o servidor CSCF. Ao
receber este segundo pedido, o CSCF verificou a chave de autenticação e registrou
e autenticou os usuários no servidor CSCF, conseqüentemente respostas 200 (OK)
43
foram enviadas para os usuários. O registro dos usuários no servidor possuía um
tempo de expiração de 1 hora.
Depois de efetuado o registro e a autenticação no CSCF, o próximo passo foi
efetuar uma chamada (ou criar sessão) entre os usuários. O início a uma chamada
se deu pelo envio de um pedido INVITE pelo usuário Márcio, com destino a Alice.
Este pedido antes de chegar a Alice, passou pelo servidor CSCF. Ao receber o
pedido INVITE, o CSCF emitiu uma resposta com status Trying para Marcio e
também enviou o pedido INVITE para a Alice. Recebendo o pedido, Alice enviou
uma mensagem com status Ringing para o usuário Marcio e após alguns milésimos
de segundo, Alice emitiu uma outra mensagem com status 200 (OK) para o mesmo
destinatário, autorizando a chamada. As duas mensagens passaram antes pelo
servidor CSCF. O usuário Marcio ao receber esta mensagem, enviou uma outra
mensagem com status ACK para Alice, neste momento a sessão foi estabelecida.
Esta ultima mensagem também passou pelo servidor CSCF.
Após a criação de uma sessão entre os usuários, foi possível efetuar o último
caso de teste, o serviço na arquitetura IMS. O serviço aqui testado foi a troca de
mensagens entre os usuários. Com a sessão criada, um canal direto entre os
usuários foi formado, possibilitando a transmissão direta de mensagens entre os
usuários, em outras palavras, as mensagens trafegaram diretamente para o usuário,
sem ter que passar pelo servidor CSCF.
A cada mensagem recebida pelo usuário, uma resposta de 200 (OK) foi emitida
para o emissor.
Para finalizar a sessão o usuário Marcio enviou um pedido BYE para Alice
subseqüentemente Alice respondeu esse pedido com uma mensagem 200 (OK),
finalizando a sessão.
5.3 Análise
Com base nos resultados obtidos dos testes efetuados na arquitetura Asterisk e
no SDS, foram destacadas algumas semelhanças e algumas diferenças.
5.3.1 Semelhanças
Uma semelhança observada nos resultados dos dois ambientes foi que todos os
pedidos e respostas de registros, início de sessão, termino de sessão, passaram
44
pelos servidores, e em nenhuma vez foram transmitidos diretos para o usuário final.
Abaixo são descritas as semelhanças e as diferenças dos resultados.
5.3.1.1 Registro
Foi destacado que as únicas semelhanças em um registro: é no momento em que
o usuário envia um pedido de registro para os servidores (CSCF e Asterisk); e no
momento em que o servidor envia a resposta confirmando que o usuário foi
registrado.
5.3.1.2 Início de Sessão
Em inícios de sessões os resultados quase que se igualaram, houve envios de
pedidos e respostas, ambos passaram pelos servidores (CSCF e Asterisk) antes de
chegarem aos destinos.
5.3.1.3 Encerramento de Sessão
Nos encerramentos de sessões não foram observadas diferenças nos resultados,
ambos se comportaram de forma parecida. O usuário enviou um pedido BYE que
conseqüentemente recebeu uma resposta 200(OK). O pedido e resposta passaram
pelos servidores (Asterisk e CSCF).
5.3.2 Diferenças
5.3.2.1 Registro
No registro dos usuários, foi destacada uma grande diferença nos resultados
obtidos dos testes. Na arquitetura IMS emulada pelo SDS, houve a necessidade do
usuário se autenticar antes de efetuar o registro, diferente do registro no Asterisk.
5.3.2.2 Serviços
Os serviços dos usuários da arquitetura IMS são armazenados em servidores de
aplicação (AS), e os mesmos são solicitados via pedido SIP pelo servidor S-CSCF.
No teste efetuado no Asterisk, os serviços foram executados de acordo com a
configuração de cada usuário no plano de discagem, esses serviços estavam
armazenados em um banco de dados.
45
5.4 Proposta de Mudanças
De acordo com as análises obtidas dos casos de testes e com os estudos da
arquitetura IMS, do Asterisk e do SIP, foi concluído que há semelhanças no modo do
Asterisk e o controlador de sessão da arquitetura IMS operarem, porém, para que o
Asterisk se comporte como um controlador IMS, algumas alterações precisam ser
feitas, conforme é listado abaixo.
No momento em que é feito o registro do usuário no servidor, é necessário
acrescentar uma rotina de autenticação de usuário. Essa rotina se dá início com a
resposta ao primeiro pedido SIP REGISTER com os parâmetros de autenticação.
Com a autenticação é gerado um canal seguro entre o P-CSCF e o
equipamento do usuário, cujo processo já se encontra na arquitetura IMS,
independente do qual controlador de sessão é usado.
Os serviços que o IMS dispõe aos usuários são armazenados nos servidores
de aplicação (AS). As solicitações desses serviços ocorrem por meio de pedidos
SIP. No Asterisk não há esse mecanismo de solicitação de serviços via pedido SIP,
porém o Asterisk suporta AGI baseado em Java, com isso, para suprir essa
necessidade, pode se criar um banco de dados para armazenar esses serviços e
escrever um programa em Java para suprir essa necessidade, um fluxograma desse
processo pode ser visto na Figura 5.16.
Figura 5.16: Fluxograma simples do processo com o Script Java.
Asterisk
Plano de Discagem
Script Java
- ACK_RECIEVE
- doOK
- doACK
- doBYE
Alguns parâmetros
que o script deve conter
Variáveis de controle.
46
As mudanças propostas aqui se tornam possíveis, devido a possibilidade que o
Asterisk tem, de iteragir com programs externos em seu plano de discagem.
6 CONCLUSÃO
O protocolo SIP é uma boa alternativa ao H.323 por ser menos complexo e
fácil de se implementar, em aplicações VoIP.
O Asterisk é um software PABX de código aberto que vem ganhando espaço
no mercado, devido o seu grande potencial e versatilidade. No Asterisk é possível
implementar funções no plano de discagem, facilitando a inclusão de serviços para
os usuários e a interface com programas esternos e banco de dados.
O IMS surgiu com forças no mercado devido as suas grandes vantagens sobre
a atual rede de telefonia, oferecendo mais benefícios e entretenimento aos usuários
e também devido ao QoS que é oferecido para serviços multimídia.
Um ponto em comum entre o Asterisk e a arquitetura IMS, e que facilitou o
estudo. È o protocolo SIP que ambos utilizam na criação de sessão entre os
equipamentos dos usuários e o servidor, a padronização e os nomes dados aos
cabeçalhos nos pedidos e respostas, facilitaram a análise dos resultados obtidos.
A arquitetura IMS possui o mecanismo de autenticação do usuário, que é feito
no momento do registro do usuário. Essa autenticação gera um canal seguro entre o
equipamento do usuário e o ponto de entrada da rede 3G. Esse mecanismo torna a
comunicação mais segura.
Independente se a arquitetura IMS está operando na rede local ou visitante,
cada componente dessa arquitetura tem sua própria função, isso faz com que a
arquitetura seja organizada e fácil de se entender. Os componentes são
dependentes um do outro, as comunicações entre eles são efetuados via pedidos e
respostas SIP. Há redes que podem possuir mais de um mesmo componente, esse
é o caso dos servidores de aplicação, onde os servidores de aplicações são
divididos por tipos de serviços a ser executado.
O Asterisk possui um grande potencial para ser um controlador de sessão SIP
da arquitetura IMS, porém, algumas melhorias precisam ser feitas, tais como: incluir
o mecanismo de autenticação de usuário, subseqüente a autenticação, criar um
canal entre o equipamento do usuário e o ponto de entrada da rede 3G e por final,
acrescentar uma comunicação SIP entre o servidor de aplicação e o Asterisk.
47
6.1 Contribuições
Esse estudo ajudou a entender o funcionamento e a selecionar os pontos em
que o Asterisk deve melhorar para se tornar um controlador de sessão da arquitetura
IMS. Com as alterações aqui sugeridas, o Asterisk pode se tornar um poderoso
controlador de sessão da rede 3G.
O Asterisk tornando-se um controlador de sessão da rede 3G é bastante
significante para o próprio software como também para os usuários dessa rede. O
fato de o Asterisk ser um software livre, com a aplicação desse software, o custo
operacional é reduzido. Essa redução pode ser passada para os usuários ou
aplicada em outros aspectos, beneficiando o usuário.
6.2 Trabalhos futuros
Como trabalho futuro sugiro os seguintes tópicos:
- Implementar as melhorias no Asterisk discutido nesse estudo, tais como:
autenticação de usuário no momento do registro, conseqüentemente gerar um
canal seguro entre o equipamento do usuário e o ponto de entrada da rede 3G
(o P-CSCF) e também criar um script AGI em Java que faça a comunicação do
banco de dados de serviço com o Asterisk, via pedidos SIP;
- Analisar e testar se é possível implementar o “serviço de presença” da
arquitetura IMS no Asterisk;
- Analisar e testar se é possível implementar o “serviço Push to talk Over
Cellular” da arquitetura IMS no Asterisk;
- Após aplicação das melhorias discutidas nesse estudo no Asterisk, analisar
essa nova arquitetura com um outro componente da arquitetura IMS, o
componente MRF, responsável em fornecer recursos de mídia, quando
solicitado pelo AS; Efetuar testes mais aprofundados usando outros
componentes da arquitetura IMS (MRF, BGCF, SGW, MGCF e MGW);
- Efetuar teste no trâmite de vídeo usando arquitetura IMS;
48
Anexo A – Sip.conf
; SIP Configuration for Asterisk ; Syntax for specifying a SIP device in extensions.conf is ; SIP/devicename where devicename is defined in a section below. ; You may also use ; SIP/username@domain to call any SIP user on the Internet ; (Don't forget to enable DNS SRV records if you want to use this) ; If you define a SIP proxy as a peer below, you may call ; SIP/proxyhostname/user or SIP/user@proxyhostname ; where the proxyhostname is defined in a section below ; Useful CLI commands to check peers/users: ; sip show peers Show all SIP peers (including friends) ; sip show users Show all SIP users (including friends) ; sip show registry Show status of hosts we register with ; ; sip debug Show all SIP messages ; ; reload chan_sip.so Reload configuration file ; Active SIP peers will not be reconfigured ; [general] type=friend secret=welcome context=phones host=dynamic disallow=all allow=ulaw allowoverlap=no ; Disable overlap dialing support. (Default is yes) bindport=5060 ; UDP Port to bind to (SIP standard port is 5060) ; bindport is the local UDP port that Asterisk will ;listen on bindaddr=0.0.0.0 ; IP address to bind to (0.0.0.0 binds to all) srvlookup=yes ; Enable DNS SRV lookups on outbound calls ; Note: Asterisk only uses the first host
; in SRV records [1000] username=Marcio type=friend host=dynamic context=phones secret=123 fromuser=Alice ; This allows a channel definition to be referenced ;with a name other than that used to authticate dtmfmode=rfc2833 [1001] username=Alice type=friend host=dynamic context=phones secret=123 fromuser=Marcio dtmfmode=rfc2833
49
Anexo B - Extensions.conf
; extensions.conf - the Asterisk dial plan ; Static extension configuration file, used by ; the pbx_config module. This is where you configure all your ; inbound and outbound calls in Asterisk. ; This configuration file is reloaded ; - With the "extensions reload" command in the CLI ; - With the "reload" command (that reloads everything) in the CLI ; The "General" category is for certain variables. [general] static=yes ; if static=yes and writeprotect=no, you can save dialplan by ; CLI command 'save dialplan' too writeprotect=no ; If autofallthrough is not set, then if an extension runs out of ; things to do, Asterisk will wait for a new extension to be dialed ; (this is the original behavior of Asterisk 1.0 and earlier). ;autofallthrough=no ; If clearglobalvars is not set, then global variables will persist ; through reloads, and even if deleted from the extensions.conf or ; one of its included files, will remain set to the previous value. clearglobalvars=no ; User context is where entries from users.conf are registered. The ; default value is 'default' userscontext=phones [globals] [default] [incoming_calls] [phones] include => internal include => remote [internal] exten => _2XXX,1,NoOp() exten => _2XXX,n,Dial(SIP/${EXTEN},30) exten => _2XXX,n,Playback(the-party-you-are-calling&is-curntly-unavail) exten => _2XXX,n,Hangup() [remote] exten => _1XXX,1,NoOp() exten => _1XXX,n,Dial(SIP/1001/${EXTEN}) exten => _1XXX,n,Hangup() [phones] include => 1000 include => 1001 [1000] exten => 1000,1,AGI(valida_servico.agi) exten => 1000,2,Dial(SIP/1000) exten => 1000,3,Hangup() exten => 123,1,Answer() exten => 123,2,AGI(ativa_servico.agi) [1001] exten => 1001,1,AGI(valida_servico.agi) exten => 1001,1,Dial(SIP/1001) exten => 1001,2,Hangup() exten => 123,1,Answer() exten => 123,2,AGI(ativa_servico.agi)
50
Anexo C – Script PHP ativa_servico.agi
#!/usr/bin/php-cgi -q <?php #don't let this script run for more than 60 seconds set_time_limit(60); #turn off output buffering ob_implicit_flush(false); #turn off error reporting, as it will most likely interfere with the AGI interface error_reporting(0); #create file handles if needed if (!define('STDIN')){ define('STDIN', fopen ('php://stdin', 'r')); } if (!define('STDOUT')){ define('STDOUT', fopen ('php://stdout', 'w')); } if (!define('STDERR')){ define('STDERR', fopen ('php://stderr', 'w')); } #retrieve all AGI variables from Asterisk while (!feof(STDIN)){ $temp = trim(fgets(STDIN,4096)); if (($temp == "") || ($temp == "\n")) { break; } $s = split(":",$temp); $name = str_replace("agi_","",$s[0]); $agi[$name] = trim($s[1]); } #print all AGI variables for debugging purposes foreach($agi as $key=>$value){ fwrite(STDERR,"-- $key = $value\n"); fflush(STDERR); } #CONECTA AO BANCO DE DADOS $db_host = "localhost"; $db_user = "Asterisk"; $db_pass = "123456"; $db_base = "Asterisk"; $db_connection = mysql_connect($db_host,$db_user,$db_pass) or die(mysql_error()); #Open MySQL Connection $db_select = mysql_select_db($db_base,$db_connection) or die(mysql_error()); #Select database $ext = $agi[callerid]; #If connection to MySQL sucessfull, insert into table Servicos $insert="SELECT flag FROM Asterisk.Servicos where ext = '$ext'"; #Query MySQL command result $insert_result=mysql_query($insert); #Check if it's necessary to play "not available" record and hung up or do nothing and complete the call if ($insert_result == "1"){ fwrite(STDOUT,"STREAM FILE vm-nobodyavail.gsm \"\"\n"); fflush(STDOUT); fwrite(STDOUT,"EXEC HANGUP() \"\"\n"); fflush(STDOUT); } #Cleaning MySQL-resources mysql_free_result($insert_result); mysql_close($db_connection); ?>
51
Anexo D – Script PHP valida_servico.agi
#!/usr/bin/php-cgi -q <?php #don't let this script run for more than 60 seconds set_time_limit(60); #turn off output buffering ob_implicit_flush(false); #turn off error reporting, as it will most likely interfere with the AGI interface error_reporting(0); #create file handles if needed if (!define('STDIN')){ define('STDIN', fopen ('php://stdin', 'r')); } if (!define('STDOUT')){ define('STDOUT', fopen ('php://stdout', 'w')); } if (!define('STDERR')){ define('STDERR', fopen ('php://stderr', 'w')); } #retrieve all AGI variables from Asterisk while (!feof(STDIN)){ $temp = trim(fgets(STDIN,4096)); if (($temp == "") || ($temp == "\n")) { break; } $s = split(":",$temp); $name = str_replace("agi_","",$s[0]); $agi[$name] = trim($s[1]); } #print all AGI variables for debugging purposes foreach($agi as $key=>$value){ fwrite(STDERR,"-- $key = $value\n"); fflush(STDERR); } #conecta ao banco de dados $db_host = "localhost"; $db_user = "Asterisk"; $db_pass = "123456"; $db_base = "Asterisk"; $db_connection = mysql_connect($db_host,$db_user,$db_pass) or die(mysql_error()); #Open MySQL Connection $db_select = mysql_select_db($db_base,$db_connection) or die(mysql_error()); #Select database $ext = $agi[callerid]; #If connection to MySQL sucessfull, insert into table $insert="REPLACE INTO Asterisk.Service VALUES ('$ext','1')"; #Query MySQL command result $insert_result=mysql_query($insert); #Cleaning MySQL-resources mysql_free_result($insert_result); mysql_close($db_connection); ?>
52
Anexo E – Teste de Resultado do Wireshark
53
54
Anexo F – Log do Wireshark
No. Time Source Destination Protocol Info 1 0.000000 192.168.0.4 192.168.0.3 SIP Request: REGISTER sip:192.168.0.3 Frame 1 (456 bytes on wire, 456 bytes captured) Arrival Time: Nov 16, 2008 08:32:59.467984000 Time delta from previous packet: 0.000000000 seconds Time since reference or first frame: 0.000000000 seconds Frame Number: 1 Packet Length: 456 bytes Capture Length: 456 bytes Protocols in frame: eth:ip:udp:sip Coloring Rule Name: UDP Coloring Rule String: udp Ethernet II, Src: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed), Dst: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Destination: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Internet Protocol, Src: 192.168.0.4 (192.168.0.4), Dst: 192.168.0.3 (192.168.0.3) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 442 Identification: 0x0000 (0) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xb7db [correct] Good: True Bad : False Source: 192.168.0.4 (192.168.0.4) Destination: 192.168.0.3 (192.168.0.3) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 422 Checksum: 0x5746 [correct] Session Initiation Protocol Request-Line: REGISTER sip:192.168.0.3 SIP/2.0 Method: REGISTER Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.0.4:5060;rport;branch=z9hG4bK05B63B2DBDBF436E364113B320FA597A From: 1001 <sip:[email protected]>;tag=207460698 SIP Display info: 1001 SIP from address: sip:[email protected] SIP tag: 207460698 To: 1001 <sip:[email protected]> SIP Display info: 1001 SIP to address: sip:[email protected] Contact: "1001" <sip:[email protected]:5060> Contact Binding: "1001" <sip:[email protected]:5060> URI: "1001" <sip:[email protected]:5060> SIP Display info: "1001" SIP contact address: sip:[email protected]:5060 Call-ID: [email protected] CSeq: 55783 REGISTER Expires: 1800
55
Max-Forwards: 70 User-Agent: X-Lite release 1105d Content-Length: 0 No. Time Source Destination Protocol Info 2 0.000156 192.168.0.3 192.168.0.4 SIP Status: 100 Trying (1 bindings) Frame 2 (504 bytes on wire, 504 bytes captured) Arrival Time: Nov 16, 2008 08:32:59.468140000 Time delta from previous packet: 0.000156000 seconds Time since reference or first frame: 0.000156000 seconds Frame Number: 2 Packet Length: 504 bytes Capture Length: 504 bytes Protocols in frame: eth:ip:udp:sip Coloring Rule Name: Checksum Errors Coloring Rule String: edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad || udp.checksum_bad Ethernet II, Src: PlanetTe_5c:80:55 (00:30:4f:5c:80:55), Dst: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Destination: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Internet Protocol, Src: 192.168.0.3 (192.168.0.3), Dst: 192.168.0.4 (192.168.0.4) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 490 Identification: 0xdbf3 (56307) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x1bb8 [correct] Good: True Bad : False Source: 192.168.0.3 (192.168.0.3) Destination: 192.168.0.4 (192.168.0.4) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 470 Checksum: 0x833f [incorrect, should be 0x833e] Session Initiation Protocol Status-Line: SIP/2.0 100 Trying Status-Code: 100 Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.0.4:5060;branch=z9hG4bK05B63B2DBDBF436E364113B320FA597A;received=192.168.0.4;rport=5060 From: 1001 <sip:[email protected]>;tag=207460698 SIP Display info: 1001 SIP from address: sip:[email protected] SIP tag: 207460698 To: 1001 <sip:[email protected]> SIP Display info: 1001 SIP to address: sip:[email protected] Call-ID: [email protected] CSeq: 55783 REGISTER User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:[email protected]> Contact Binding: <sip:[email protected]> URI: <sip:[email protected]> SIP contact address: sip:[email protected]
56
Content-Length: 0 No. Time Source Destination Protocol Info 3 0.002296 192.168.0.3 192.168.0.4 SIP Status: 200 OK (1 bindings) Frame 3 (585 bytes on wire, 585 bytes captured) Arrival Time: Nov 16, 2008 08:32:59.470280000 Time delta from previous packet: 0.002140000 seconds Time since reference or first frame: 0.002296000 seconds Frame Number: 3 Packet Length: 585 bytes Capture Length: 585 bytes Protocols in frame: eth:ip:udp:sip Coloring Rule Name: Checksum Errors Coloring Rule String: edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad || udp.checksum_bad Ethernet II, Src: PlanetTe_5c:80:55 (00:30:4f:5c:80:55), Dst: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Destination: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Internet Protocol, Src: 192.168.0.3 (192.168.0.3), Dst: 192.168.0.4 (192.168.0.4) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 571 Identification: 0xdbf4 (56308) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x1b66 [correct] Good: True Bad : False Source: 192.168.0.3 (192.168.0.3) Destination: 192.168.0.4 (192.168.0.4) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 551 Checksum: 0x8390 [incorrect, should be 0xec2b] Session Initiation Protocol Status-Line: SIP/2.0 200 OK Status-Code: 200 Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.0.4:5060;branch=z9hG4bK05B63B2DBDBF436E364113B320FA597A;received=192.168.0.4;rport=5060 From: 1001 <sip:[email protected]>;tag=207460698 SIP Display info: 1001 SIP from address: sip:[email protected] SIP tag: 207460698 To: 1001 <sip:[email protected]>;tag=as627a972d SIP Display info: 1001 SIP to address: sip:[email protected] SIP tag: as627a972d Call-ID: [email protected] CSeq: 55783 REGISTER User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Expires: 1800 Contact: <sip:[email protected]:5060>;expires=1800 Contact Binding: <sip:[email protected]:5060>;expires=1800 URI: <sip:[email protected]:5060> SIP contact address: sip:[email protected]:5060
57
Date: Sun, 16 Nov 2008 10:32:59 GMT Content-Length: 0 No. Time Source Destination Protocol Info 4 5.094910 192.168.0.4 192.168.0.3 UDP Source port: 5060 Destination port: 5060 Frame 4 (60 bytes on wire, 60 bytes captured) Arrival Time: Nov 16, 2008 08:33:04.562894000 Time delta from previous packet: 5.092614000 seconds Time since reference or first frame: 5.094910000 seconds Frame Number: 4 Packet Length: 60 bytes Capture Length: 60 bytes Protocols in frame: eth:ip:udp:data Coloring Rule Name: UDP Coloring Rule String: udp Ethernet II, Src: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed), Dst: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Destination: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Trailer: 00000000000000000000000000000000 Internet Protocol, Src: 192.168.0.4 (192.168.0.4), Dst: 192.168.0.3 (192.168.0.3) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 30 Identification: 0x0000 (0) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xb977 [correct] Good: True Bad : False Source: 192.168.0.4 (192.168.0.4) Destination: 192.168.0.3 (192.168.0.3) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 10 Checksum: 0x49f0 [correct] Data (2 bytes) 0000 0d 0a .. No. Time Source Destination Protocol Info 5 7.344738 192.168.0.4 192.168.0.3 SIP/SDP Request: INVITE sip:[email protected], with session description Frame 5 (774 bytes on wire, 774 bytes captured) Arrival Time: Nov 16, 2008 08:33:06.812722000 Time delta from previous packet: 2.249828000 seconds Time since reference or first frame: 7.344738000 seconds Frame Number: 5 Packet Length: 774 bytes Capture Length: 774 bytes Protocols in frame: eth:ip:udp:sip:sdp Coloring Rule Name: UDP Coloring Rule String: udp Ethernet II, Src: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed), Dst: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Destination: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address
58
Source: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Internet Protocol, Src: 192.168.0.4 (192.168.0.4), Dst: 192.168.0.3 (192.168.0.3) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 760 Identification: 0x0000 (0) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xb69d [correct] Good: True Bad : False Source: 192.168.0.4 (192.168.0.4) Destination: 192.168.0.3 (192.168.0.3) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 740 Checksum: 0xe032 [correct] Session Initiation Protocol Request-Line: INVITE sip:[email protected] SIP/2.0 Method: INVITE Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.0.4:5060;rport;branch=z9hG4bK008D428712CB2F2A2F9CCC82D093BB05 From: 1001 <sip:[email protected]>;tag=116251041 SIP Display info: 1001 SIP from address: sip:[email protected] SIP tag: 116251041 To: <sip:[email protected]> SIP to address: sip:[email protected] Contact: <sip:[email protected]:5060> Contact Binding: <sip:[email protected]:5060> URI: <sip:[email protected]:5060> SIP contact address: sip:[email protected]:5060 Call-ID: [email protected] CSeq: 46028 INVITE Max-Forwards: 70 Content-Type: application/sdp User-Agent: X-Lite release 1105d Content-Length: 307 Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): 1001 2765897642 2765897651 IN IP4 192.168.0.4 Owner Username: 1001 Session ID: 2765897642 Session Version: 2765897651 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.0.4 Session Name (s): X-Lite Connection Information (c): IN IP4 192.168.0.4 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 192.168.0.4 Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Media Description, name and address (m): audio 8000 RTP/AVP 0 8 3 98 97 101 Media Type: audio Media Port: 8000 Media Proto: RTP/AVP Media Format: ITU-T G.711 PCMU
59
Media Format: ITU-T G.711 PCMA Media Format: GSM 06.10 Media Format: 98 Media Format: 97 Media Format: 101 Media Attribute (a): rtpmap:0 pcmu/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 0 pcmu/8000 Media Attribute (a): rtpmap:8 pcma/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 8 pcma/8000 Media Attribute (a): rtpmap:3 gsm/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 3 gsm/8000 Media Attribute (a): rtpmap:98 iLBC/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 98 iLBC/8000 Media Attribute (a): rtpmap:97 speex/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 97 speex/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 101 telephone-event/8000 Media Attribute (a): fmtp:101 0-15 Media Attribute Fieldname: fmtp Media Attribute Value: 101 0-15 Media Attribute (a): sendrecv No. Time Source Destination Protocol Info 6 7.345283 192.168.0.3 192.168.0.4 SIP Status: 100 Trying Frame 6 (501 bytes on wire, 501 bytes captured) Arrival Time: Nov 16, 2008 08:33:06.813267000 Time delta from previous packet: 0.000545000 seconds Time since reference or first frame: 7.345283000 seconds Frame Number: 6 Packet Length: 501 bytes Capture Length: 501 bytes Protocols in frame: eth:ip:udp:sip Coloring Rule Name: Checksum Errors Coloring Rule String: edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad || udp.checksum_bad Ethernet II, Src: PlanetTe_5c:80:55 (00:30:4f:5c:80:55), Dst: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Destination: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Internet Protocol, Src: 192.168.0.3 (192.168.0.3), Dst: 192.168.0.4 (192.168.0.4) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 487 Identification: 0xdbf5 (56309) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x1bb9 [correct] Good: True Bad : False Source: 192.168.0.3 (192.168.0.3) Destination: 192.168.0.4 (192.168.0.4) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 467
60
Checksum: 0x833c [incorrect, should be 0xda0d] Session Initiation Protocol Status-Line: SIP/2.0 100 Trying Status-Code: 100 Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.0.4:5060;branch=z9hG4bK008D428712CB2F2A2F9CCC82D093BB05;received=192.168.0.4;rport=5060 From: 1001 <sip:[email protected]>;tag=116251041 SIP Display info: 1001 SIP from address: sip:[email protected] SIP tag: 116251041 To: <sip:[email protected]> SIP to address: sip:[email protected] Call-ID: [email protected] CSeq: 46028 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:[email protected]> Contact Binding: <sip:[email protected]> URI: <sip:[email protected]> SIP contact address: sip:[email protected] Content-Length: 0 No. Time Source Destination Protocol Info 7 7.384454 192.168.0.3 192.168.0.4 SIP Status: 180 Ringing Frame 7 (517 bytes on wire, 517 bytes captured) Arrival Time: Nov 16, 2008 08:33:06.852438000 Time delta from previous packet: 0.039171000 seconds Time since reference or first frame: 7.384454000 seconds Frame Number: 7 Packet Length: 517 bytes Capture Length: 517 bytes Protocols in frame: eth:ip:udp:sip Coloring Rule Name: Checksum Errors Coloring Rule String: edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad || udp.checksum_bad Ethernet II, Src: PlanetTe_5c:80:55 (00:30:4f:5c:80:55), Dst: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Destination: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Internet Protocol, Src: 192.168.0.3 (192.168.0.3), Dst: 192.168.0.4 (192.168.0.4) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 503 Identification: 0xdbf6 (56310) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x1ba8 [correct] Good: True Bad : False Source: 192.168.0.3 (192.168.0.3) Destination: 192.168.0.4 (192.168.0.4) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 483 Checksum: 0x834c [incorrect, should be 0x44ce] Session Initiation Protocol Status-Line: SIP/2.0 180 Ringing
61
Status-Code: 180 Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.0.4:5060;branch=z9hG4bK008D428712CB2F2A2F9CCC82D093BB05;received=192.168.0.4;rport=5060 From: 1001 <sip:[email protected]>;tag=116251041 SIP Display info: 1001 SIP from address: sip:[email protected] SIP tag: 116251041 To: <sip:[email protected]>;tag=as0b318557 SIP to address: sip:[email protected] SIP tag: as0b318557 Call-ID: [email protected] CSeq: 46028 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:[email protected]> Contact Binding: <sip:[email protected]> URI: <sip:[email protected]> SIP contact address: sip:[email protected] Content-Length: 0 No. Time Source Destination Protocol Info 8 13.286660 192.168.0.3 192.168.0.4 SIP/SDP Status: 200 OK, with session description Frame 8 (828 bytes on wire, 828 bytes captured) Arrival Time: Nov 16, 2008 08:33:12.754644000 Time delta from previous packet: 5.902206000 seconds Time since reference or first frame: 13.286660000 seconds Frame Number: 8 Packet Length: 828 bytes Capture Length: 828 bytes Protocols in frame: eth:ip:udp:sip:sdp Coloring Rule Name: Checksum Errors Coloring Rule String: edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad || udp.checksum_bad Ethernet II, Src: PlanetTe_5c:80:55 (00:30:4f:5c:80:55), Dst: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Destination: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Internet Protocol, Src: 192.168.0.3 (192.168.0.3), Dst: 192.168.0.4 (192.168.0.4) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 814 Identification: 0xdbf7 (56311) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x1a70 [correct] Good: True Bad : False Source: 192.168.0.3 (192.168.0.3) Destination: 192.168.0.4 (192.168.0.4) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 794 Checksum: 0x8483 [incorrect, should be 0xb738] Session Initiation Protocol Status-Line: SIP/2.0 200 OK Status-Code: 200 Resent Packet: False
62
Message Header Via: SIP/2.0/UDP 192.168.0.4:5060;branch=z9hG4bK008D428712CB2F2A2F9CCC82D093BB05;received=192.168.0.4;rport=5060 From: 1001 <sip:[email protected]>;tag=116251041 SIP Display info: 1001 SIP from address: sip:[email protected] SIP tag: 116251041 To: <sip:[email protected]>;tag=as0b318557 SIP to address: sip:[email protected] SIP tag: as0b318557 Call-ID: [email protected] CSeq: 46028 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:[email protected]> Contact Binding: <sip:[email protected]> URI: <sip:[email protected]> SIP contact address: sip:[email protected] Content-Type: application/sdp Content-Length: 283 Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): root 3010 3010 IN IP4 192.168.0.3 Owner Username: root Session ID: 3010 Session Version: 3010 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.0.3 Session Name (s): session Connection Information (c): IN IP4 192.168.0.3 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 192.168.0.3 Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Media Description, name and address (m): audio 17708 RTP/AVP 3 0 8 101 Media Type: audio Media Port: 17708 Media Proto: RTP/AVP Media Format: GSM 06.10 Media Format: ITU-T G.711 PCMU Media Format: ITU-T G.711 PCMA Media Format: 101 Media Attribute (a): rtpmap:3 GSM/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 3 GSM/8000 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 0 PCMU/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 8 PCMA/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 101 telephone-event/8000 Media Attribute (a): fmtp:101 0-16 Media Attribute Fieldname: fmtp Media Attribute Value: 101 0-16 Media Attribute (a): silenceSupp:off - - - - Media Attribute Fieldname: silenceSupp Media Attribute Value: off - - - - Media Attribute (a): ptime:20 Media Attribute Fieldname: ptime Media Attribute Value: 20 Media Attribute (a): sendrecv No. Time Source Destination Protocol Info 9 13.295971 192.168.0.4 192.168.0.3 SIP Request: ACK sip:[email protected] Frame 9 (409 bytes on wire, 409 bytes captured) Arrival Time: Nov 16, 2008 08:33:12.763955000 Time delta from previous packet: 0.009311000 seconds
63
Time since reference or first frame: 13.295971000 seconds Frame Number: 9 Packet Length: 409 bytes Capture Length: 409 bytes Protocols in frame: eth:ip:udp:sip Coloring Rule Name: UDP Coloring Rule String: udp Ethernet II, Src: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed), Dst: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Destination: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Internet Protocol, Src: 192.168.0.4 (192.168.0.4), Dst: 192.168.0.3 (192.168.0.3) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 395 Identification: 0x0000 (0) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xb80a [correct] Good: True Bad : False Source: 192.168.0.4 (192.168.0.4) Destination: 192.168.0.3 (192.168.0.3) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 375 Checksum: 0xe972 [correct] Session Initiation Protocol Request-Line: ACK sip:[email protected] SIP/2.0 Method: ACK Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.0.4:5060;rport;branch=z9hG4bK5B9831A375E6E131D282FD5452900F57 From: 1001 <sip:[email protected]>;tag=116251041 SIP Display info: 1001 SIP from address: sip:[email protected] SIP tag: 116251041 To: <sip:[email protected]>;tag=as0b318557 SIP to address: sip:[email protected] SIP tag: as0b318557 Contact: <sip:[email protected]:5060> Contact Binding: <sip:[email protected]:5060> URI: <sip:[email protected]:5060> SIP contact address: sip:[email protected]:5060 Call-ID: [email protected] CSeq: 46028 ACK Max-Forwards: 70 Content-Length: 0 No. Time Source Destination Protocol Info 10 13.296201 192.168.0.3 192.168.0.4 SIP/SDP Request: INVITE sip:[email protected]:5060, with session description Frame 10 (819 bytes on wire, 819 bytes captured) Arrival Time: Nov 16, 2008 08:33:12.764185000 Time delta from previous packet: 0.000230000 seconds Time since reference or first frame: 13.296201000 seconds Frame Number: 10 Packet Length: 819 bytes Capture Length: 819 bytes
64
Protocols in frame: eth:ip:udp:sip:sdp Coloring Rule Name: Checksum Errors Coloring Rule String: edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad || udp.checksum_bad Ethernet II, Src: PlanetTe_5c:80:55 (00:30:4f:5c:80:55), Dst: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Destination: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Internet Protocol, Src: 192.168.0.3 (192.168.0.3), Dst: 192.168.0.4 (192.168.0.4) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 805 Identification: 0xdbf8 (56312) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x1a78 [correct] Good: True Bad : False Source: 192.168.0.3 (192.168.0.3) Destination: 192.168.0.4 (192.168.0.4) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 785 Checksum: 0x847a [incorrect, should be 0x1128] Session Initiation Protocol Request-Line: INVITE sip:[email protected]:5060 SIP/2.0 Method: INVITE Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK0d833950;rport From: <sip:[email protected]>;tag=as0b318557 SIP from address: sip:[email protected] SIP tag: as0b318557 To: 1001 <sip:[email protected]>;tag=116251041 SIP Display info: 1001 SIP to address: sip:[email protected] SIP tag: 116251041 Contact: <sip:[email protected]> Contact Binding: <sip:[email protected]> URI: <sip:[email protected]> SIP contact address: sip:[email protected] Call-ID: [email protected] CSeq: 102 INVITE User-Agent: Asterisk PBX Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: 282 Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): root 3010 3011 IN IP4 192.168.0.3 Owner Username: root Session ID: 3010 Session Version: 3011 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.0.3 Session Name (s): session Connection Information (c): IN IP4 192.168.0.3
65
Connection Network Type: IN Connection Address Type: IP4 Connection Address: 192.168.0.3 Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Media Description, name and address (m): audio 8000 RTP/AVP 3 0 8 101 Media Type: audio Media Port: 8000 Media Proto: RTP/AVP Media Format: GSM 06.10 Media Format: ITU-T G.711 PCMU Media Format: ITU-T G.711 PCMA Media Format: 101 Media Attribute (a): rtpmap:3 GSM/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 3 GSM/8000 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 0 PCMU/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 8 PCMA/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 101 telephone-event/8000 Media Attribute (a): fmtp:101 0-16 Media Attribute Fieldname: fmtp Media Attribute Value: 101 0-16 Media Attribute (a): silenceSupp:off - - - - Media Attribute Fieldname: silenceSupp Media Attribute Value: off - - - - Media Attribute (a): ptime:20 Media Attribute Fieldname: ptime Media Attribute Value: 20 Media Attribute (a): sendrecv No. Time Source Destination Protocol Info 11 13.304532 192.168.0.4 192.168.0.3 SIP Status: 100 Trying Frame 11 (384 bytes on wire, 384 bytes captured) Arrival Time: Nov 16, 2008 08:33:12.772516000 Time delta from previous packet: 0.008331000 seconds Time since reference or first frame: 13.304532000 seconds Frame Number: 11 Packet Length: 384 bytes Capture Length: 384 bytes Protocols in frame: eth:ip:udp:sip Coloring Rule Name: UDP Coloring Rule String: udp Ethernet II, Src: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed), Dst: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Destination: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Internet Protocol, Src: 192.168.0.4 (192.168.0.4), Dst: 192.168.0.3 (192.168.0.3) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 370 Identification: 0x0000 (0) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11)
66
Header checksum: 0xb823 [correct] Good: True Bad : False Source: 192.168.0.4 (192.168.0.4) Destination: 192.168.0.3 (192.168.0.3) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 350 Checksum: 0xa233 [correct] Session Initiation Protocol Status-Line: SIP/2.0 100 Trying Status-Code: 100 Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK0d833950;rport From: <sip:[email protected]>;tag=as0b318557 SIP from address: sip:[email protected] SIP tag: as0b318557 To: 1001 <sip:[email protected]>;tag=116251041 SIP Display info: 1001 SIP to address: sip:[email protected] SIP tag: 116251041 Contact: <sip:[email protected]:5060> Contact Binding: <sip:[email protected]:5060> URI: <sip:[email protected]:5060> SIP contact address: sip:[email protected]:5060 Call-ID: [email protected] CSeq: 102 INVITE Server: X-Lite release 1105d Content-Length: 0 No. Time Source Destination Protocol Info 12 13.309167 192.168.0.4 192.168.0.3 SIP/SDP Status: 200 Ok, with session description Frame 12 (720 bytes on wire, 720 bytes captured) Arrival Time: Nov 16, 2008 08:33:12.777151000 Time delta from previous packet: 0.004635000 seconds Time since reference or first frame: 13.309167000 seconds Frame Number: 12 Packet Length: 720 bytes Capture Length: 720 bytes Protocols in frame: eth:ip:udp:sip:sdp Coloring Rule Name: UDP Coloring Rule String: udp Ethernet II, Src: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed), Dst: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Destination: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Internet Protocol, Src: 192.168.0.4 (192.168.0.4), Dst: 192.168.0.3 (192.168.0.3) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 706 Identification: 0x0000 (0) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xb6d3 [correct] Good: True Bad : False Source: 192.168.0.4 (192.168.0.4) Destination: 192.168.0.3 (192.168.0.3)
67
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 686 Checksum: 0x8378 [correct] Session Initiation Protocol Status-Line: SIP/2.0 200 Ok Status-Code: 200 Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK0d833950;rport From: <sip:[email protected]>;tag=as0b318557 SIP from address: sip:[email protected] SIP tag: as0b318557 To: 1001 <sip:[email protected]>;tag=116251041 SIP Display info: 1001 SIP to address: sip:[email protected] SIP tag: 116251041 Contact: <sip:[email protected]:5060> Contact Binding: <sip:[email protected]:5060> URI: <sip:[email protected]:5060> SIP contact address: sip:[email protected]:5060 Call-ID: [email protected] CSeq: 102 INVITE Content-Type: application/sdp Server: X-Lite release 1105d Content-Length: 307 Message body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): 1001 2765897642 2765903617 IN IP4 192.168.0.4 Owner Username: 1001 Session ID: 2765897642 Session Version: 2765903617 Owner Network Type: IN Owner Address Type: IP4 Owner Address: 192.168.0.4 Session Name (s): X-Lite Connection Information (c): IN IP4 192.168.0.4 Connection Network Type: IN Connection Address Type: IP4 Connection Address: 192.168.0.4 Time Description, active time (t): 0 0 Session Start Time: 0 Session Stop Time: 0 Media Description, name and address (m): audio 8000 RTP/AVP 3 0 8 98 97 101 Media Type: audio Media Port: 8000 Media Proto: RTP/AVP Media Format: GSM 06.10 Media Format: ITU-T G.711 PCMU Media Format: ITU-T G.711 PCMA Media Format: 98 Media Format: 97 Media Format: 101 Media Attribute (a): rtpmap:0 pcmu/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 0 pcmu/8000 Media Attribute (a): rtpmap:8 pcma/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 8 pcma/8000 Media Attribute (a): rtpmap:3 gsm/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 3 gsm/8000 Media Attribute (a): rtpmap:98 iLBC/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 98 iLBC/8000 Media Attribute (a): rtpmap:97 speex/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 97 speex/8000 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute Fieldname: rtpmap Media Attribute Value: 101 telephone-event/8000 Media Attribute (a): fmtp:101 0-15 Media Attribute Fieldname: fmtp Media Attribute Value: 101 0-15
68
Media Attribute (a): sendrecv No. Time Source Destination Protocol Info 13 13.309396 192.168.0.3 192.168.0.4 SIP Request: ACK sip:[email protected]:5060 Frame 13 (409 bytes on wire, 409 bytes captured) Arrival Time: Nov 16, 2008 08:33:12.777380000 Time delta from previous packet: 0.000229000 seconds Time since reference or first frame: 13.309396000 seconds Frame Number: 13 Packet Length: 409 bytes Capture Length: 409 bytes Protocols in frame: eth:ip:udp:sip Coloring Rule Name: Checksum Errors Coloring Rule String: edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad || udp.checksum_bad Ethernet II, Src: PlanetTe_5c:80:55 (00:30:4f:5c:80:55), Dst: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Destination: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Internet Protocol, Src: 192.168.0.3 (192.168.0.3), Dst: 192.168.0.4 (192.168.0.4) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 395 Identification: 0xdbfa (56314) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x1c10 [correct] Good: True Bad : False Source: 192.168.0.3 (192.168.0.3) Destination: 192.168.0.4 (192.168.0.4) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 375 Checksum: 0x82e0 [incorrect, should be 0xef88] Session Initiation Protocol Request-Line: ACK sip:[email protected]:5060 SIP/2.0 Method: ACK Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.0.3:5060;branch=z9hG4bK375967c5;rport From: <sip:[email protected]>;tag=as0b318557 SIP from address: sip:[email protected] SIP tag: as0b318557 To: 1001 <sip:[email protected]>;tag=116251041 SIP Display info: 1001 SIP to address: sip:[email protected] SIP tag: 116251041 Contact: <sip:[email protected]> Contact Binding: <sip:[email protected]> URI: <sip:[email protected]> SIP contact address: sip:[email protected] Call-ID: [email protected] CSeq: 102 ACK User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 No. Time Source Destination Protocol Info 14 15.096360 192.168.0.4 192.168.0.3 UDP Source port: 5060 Destination port: 5060
69
Frame 14 (60 bytes on wire, 60 bytes captured) Arrival Time: Nov 16, 2008 08:33:14.564344000 Time delta from previous packet: 1.786964000 seconds Time since reference or first frame: 15.096360000 seconds Frame Number: 14 Packet Length: 60 bytes Capture Length: 60 bytes Protocols in frame: eth:ip:udp:data Coloring Rule Name: UDP Coloring Rule String: udp Ethernet II, Src: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed), Dst: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Destination: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Trailer: 00000000000000000000000000000000 Internet Protocol, Src: 192.168.0.4 (192.168.0.4), Dst: 192.168.0.3 (192.168.0.3) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 30 Identification: 0x0000 (0) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xb977 [correct] Good: True Bad : False Source: 192.168.0.4 (192.168.0.4) Destination: 192.168.0.3 (192.168.0.3) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 10 Checksum: 0x49f0 [correct] Data (2 bytes) 0000 0d 0a .. No. Time Source Destination Protocol Info 15 19.885955 192.168.0.4 192.168.0.3 SIP Request: BYE sip:[email protected] Frame 15 (443 bytes on wire, 443 bytes captured) Arrival Time: Nov 16, 2008 08:33:19.353939000 Time delta from previous packet: 4.789595000 seconds Time since reference or first frame: 19.885955000 seconds Frame Number: 15 Packet Length: 443 bytes Capture Length: 443 bytes Protocols in frame: eth:ip:udp:sip Coloring Rule Name: UDP Coloring Rule String: udp Ethernet II, Src: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed), Dst: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Destination: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Internet Protocol, Src: 192.168.0.4 (192.168.0.4), Dst: 192.168.0.3 (192.168.0.3)
70
Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 429 Identification: 0x0000 (0) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xb7e8 [correct] Good: True Bad : False Source: 192.168.0.4 (192.168.0.4) Destination: 192.168.0.3 (192.168.0.3) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 409 Checksum: 0xee38 [correct] Session Initiation Protocol Request-Line: BYE sip:[email protected] SIP/2.0 Method: BYE Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.0.4:5060;rport;branch=z9hG4bK26B127E4BB5B9EEA427B2E09DA2C0432 From: 1001 <sip:[email protected]>;tag=116251041 SIP Display info: 1001 SIP from address: sip:[email protected] SIP tag: 116251041 To: <sip:[email protected]>;tag=as0b318557 SIP to address: sip:[email protected] SIP tag: as0b318557 Contact: <sip:[email protected]:5060> Contact Binding: <sip:[email protected]:5060> URI: <sip:[email protected]:5060> SIP contact address: sip:[email protected]:5060 Call-ID: [email protected] CSeq: 46029 BYE Max-Forwards: 70 User-Agent: X-Lite release 1105d Content-Length: 0 No. Time Source Destination Protocol Info 16 19.886145 192.168.0.3 192.168.0.4 SIP Status: 200 OK Frame 16 (509 bytes on wire, 509 bytes captured) Arrival Time: Nov 16, 2008 08:33:19.354129000 Time delta from previous packet: 0.000190000 seconds Time since reference or first frame: 19.886145000 seconds Frame Number: 16 Packet Length: 509 bytes Capture Length: 509 bytes Protocols in frame: eth:ip:udp:sip Coloring Rule Name: Checksum Errors Coloring Rule String: edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad || udp.checksum_bad Ethernet II, Src: PlanetTe_5c:80:55 (00:30:4f:5c:80:55), Dst: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Destination: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Internet Protocol, Src: 192.168.0.3 (192.168.0.3), Dst: 192.168.0.4 (192.168.0.4) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00)
71
.... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 495 Identification: 0xdc06 (56326) Flags: 0x00 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x1ba0 [correct] Good: True Bad : False Source: 192.168.0.3 (192.168.0.3) Destination: 192.168.0.4 (192.168.0.4) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 475 Checksum: 0x8344 [incorrect, should be 0x2f13] Session Initiation Protocol Status-Line: SIP/2.0 200 OK Status-Code: 200 Resent Packet: False Message Header Via: SIP/2.0/UDP 192.168.0.4:5060;branch=z9hG4bK26B127E4BB5B9EEA427B2E09DA2C0432;received=192.168.0.4;rport=5060 From: 1001 <sip:[email protected]>;tag=116251041 SIP Display info: 1001 SIP from address: sip:[email protected] SIP tag: 116251041 To: <sip:[email protected]>;tag=as0b318557 SIP to address: sip:[email protected] SIP tag: as0b318557 Call-ID: [email protected] CSeq: 46029 BYE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:[email protected]> Contact Binding: <sip:[email protected]> URI: <sip:[email protected]> SIP contact address: sip:[email protected] Content-Length: 0 No. Time Source Destination Protocol Info 17 25.251105 192.168.0.4 192.168.0.3 UDP Source port: 5060 Destination port: 5060 Frame 17 (60 bytes on wire, 60 bytes captured) Arrival Time: Nov 16, 2008 08:33:24.719089000 Time delta from previous packet: 5.364960000 seconds Time since reference or first frame: 25.251105000 seconds Frame Number: 17 Packet Length: 60 bytes Capture Length: 60 bytes Protocols in frame: eth:ip:udp:data Coloring Rule Name: UDP Coloring Rule String: udp Ethernet II, Src: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed), Dst: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Destination: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) Address: PlanetTe_5c:80:55 (00:30:4f:5c:80:55) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Source: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) Address: 00:21:5a:f8:83:ed (00:21:5a:f8:83:ed) .... ...0 .... .... .... .... = Multicast: This is a UNICAST frame .... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address Type: IP (0x0800) Trailer: 00000000000000000000000000000000 Internet Protocol, Src: 192.168.0.4 (192.168.0.4), Dst: 192.168.0.3 (192.168.0.3) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0
72
.... ...0 = ECN-CE: 0 Total Length: 30 Identification: 0x0000 (0) Flags: 0x04 (Don't Fragment) 0... = Reserved bit: Not set .1.. = Don't fragment: Set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0xb977 [correct] Good: True Bad : False Source: 192.168.0.4 (192.168.0.4) Destination: 192.168.0.3 (192.168.0.3) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Source port: 5060 (5060) Destination port: 5060 (5060) Length: 10 Checksum: 0x49f0 [correct] Data (2 bytes) 0000 0d 0a ..
73
REFERÊNCIAS BIBLIOGRÁFICAS
[1] TELECO INFORMAÇÃO EM TELECOMUNICAÇÕES.
Evolução das redes de telecomunicações: Arquitetura IMS. Disponível em
http://www.teleco.com.br/tutoriais/tutorialims/pagina_2.asp. Acesso em Março, 2008.
[2] [Asterisk] MEGGELEN, Jim, Van; SMITH Jared; SMITH, Leif Madsen. The future of telephony
2nd. Ed. O’Reilly Media, Inc, 2007
[3] [Collins, 2003] COLLINS, Daniel. Carrier Grade Voice Over IP. Chapter 5: The Session
Initiation Protocol (SIP). 2nd ed. [s.l.]: McGraw-Hill, 2003.
[4] [Kurose, 2003] KUROSE, James F.; ROSS, Keith W. Rede de Computadores e a Internet: uma
nova abordagem. Tradução: Arlete Simille Marques; revisão técnica Wagner Luiz Zucchi. 1. ed. [s.l.]:
Addison Wesley, 2003.
[5] [The IMS] POIKSELKA, Miika; MAYER Georg; KHARTABIL, Hisham; NIEMI, Aki. IP Multimedia
Concepts and Services 2nd. Ed. John Wiley & Sons, Ltd, 2006.
[6] [The 3G IP Multimedia Subsystem (IMS)] CAMARILLA, Gonfalon; GARCIA-MARTIn, Miguel. Merging the Internet and the Cellular Worlds 2nd. Ed. John Wiley & Sons, Ltd, 2006.
[7] ERICSSON - THE WORLD-LEADING SUPPLIER IN TELECOMMUNICATIONS. http://www.ericsson.com. Acesso em Novembro, 2008.
[8] ASTERISK – THE OPEN SOURCE PBX & TELEPHONY PLATFORM http:// www.asterisk.org. Acesso em Julho, 2008.
[9] MYSQL 5.1 http://www.mysql.com. Acesso em Julho, 2008.
[10] THE APACHE SOFTWARE FOUNDATION http://www.apache.org. Acesso em Julho, 2008.
[11] PHP: HYPERTEXT PREPROCESSOR http://www.php.net. Acesso em Julho, 2008.
74
[12] WIRESHARK: GO DEEP http://www.wireshark.org. Acesso em Julho, 2008.
[13] X-LITE – CNET DOWNLOAD.COM http://www.download.com/X-Lite/3000-2349_4-10547103.html. Acesso em Julho, 2008.
[14] SUN MICROSYSTEM http://www.sun.com. Acesso em Julho, 2008.
[15] SAILFIN: SAILFIN PROJECT https://sailfin.dev.java.net. Acesso em Novembro, 2008.
[16] [Meggelen, 2005] MEGGELEN, Jim V.; SMITH, J.; MADSEN, L. Asterisk: The Future of Telephony. 1st ed. [s.l.]: O’Reilly, 2005.
[17] MORAIS, M. C., Serviços em redes convergentes multimídia para controle de Clientes SIP. Trabalho de Conclusão de Curso. Universidade São Francisco, Campinas, 2007.
