Aula4 Telefonia+Digital+ +VoIP+SIP

Giuseppe M. Stephan

SIP - Session Initiation Protocol

Protocolo SIPSession Initiation Protocol

VoIP - Voice over IP

Giuseppe M. Stephan


Agenda 1 - Introdução

Histórico2 - Chamada SIP

Estabelecimento de uma sessão simplesChamada SIP com Proxy ServerRegistro no SIPRedirecionamento no SIPRedirecionamento SIP via servidor ProxyForkingPresença e Instant Message

3 - Características do SIPMétodos SIPTransações SIPCódigos de resposta

4 - Mensagem SIP5 - Arquitetura SIP


Giuseppe M. Stephan



Introdução ao SIP

Giuseppe M. Stephan


Introdução

Ligação VoIP

Necessita que se estabeleça uma sessão entre o emissor e o receptor.

A sessão pode ser: Simples ligação de voz entre duas pessoas

Ligação envolvendo voz, dados e vídeo

Conferência multimídia, ...

VoIP: principais protocolos de estabelecimento de sessão são:

H.323, MGCP/Megaco e o SIP.


Giuseppe M. Stephan


Introdução

SIP não está limitado à Internet

• Permite estabelecer presença de usuário e localização.

Disponível para aplicações que tenham a noção de sessão:

• Sistemas de Realidade Virtual

• Games de rede

• Vídeo-conferência

• Processamento de Chamadas

• Localização de usuários

• Instant Messaging

• Presença.


Giuseppe M. Stephan


Histórico

Década de 90 : O SIP foi desenvolvido pela IETF (Internet Engineering Task Force)

Mesmo grupo criador do RTP e RTCP em contrapartida ao H.323.

1996: Lançada a 1a. versão do protocolo que apenas estabelecia a sessão

Chamado inicialmente de Session Invitation Protocol.

1997: Lançada a versão 2.0

Novas funcionalidades como controles para conferências

Passou a significar Session Iniatition Protocol,

Mescla entre SIPv1 e o SCIP(Simple Conference Invitation Protocol)

Vantagem em relação aos predecessores

• Comunicação tanto por TCP como por UDP

• Incorporação dos protocolos: HTTP e SMTP.


Giuseppe M. Stephan


Histórico

1999: Publicado em Abril, como RFC 2543.

2000: Escolhido como protocolo de comunicação 3GPP.

2001: IETF decide dividir o grupo de desenvolvedores do SIP

Criação de 3 grupos com focos de pesquisa diferentes:

SIP:Responsável pelas especificações do protocolo/extensões

SIPPING:Session Initiation Protocol Investigation

Investigar aplicações, desenvolver requisitos e BCP.

SIMPLE:SIP for Instant Messaging and Presence Leveraging Extensions

Padronização de Presença e Instant Messenger utilizando o SIP.

2002: A versão SIPv2 proposta como padrão e publicado como RFC 3261,


Giuseppe M. Stephan



Estabelecimento de uma sessão simples

Giuseppe M. Stephan



Premissas

• Os dispositivos podem ser telefones SIP,

hand-helds, palmtops ou ainda celulares

• É assumido que ambos os dispositivos são

conectados para um rede IP

• Cada um sabe o endereço do outro


Giuseppe M. Stephan



O chamador inicia a troca de mensagens enviando um “comando” INVITE para o ponto final chamado.

O INVITE contém detalhes do tipo de sessão ou chamada requisitada.

Pode ser:• uma sessão simples de voz (áudio), • uma sessão multimídia como vídeo- conferência,• ou ainda uma sessão de jogo.


INVITE

Giuseppe M. Stephan


INVITE

O INVITE contém os seguintes campos:

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP lab.uniminas.br:5060;branch=z9hG4bkfw19bMax-Forwards: 70To: Joao Paulo <sip:[email protected]>From: Luiz Claudio <sip:[email protected]>;tag=76341Call-ID: [email protected]: 1 INVITESubject: Aula sobre ProtocolosContact: <sip:[email protected]>Content-Type: application/sdpContent-Length: ???

v=0o=luiz 2890844526 2890844526 IN IP4 lab.uniminas.brs=Chamada Telefonicac= IN IP4 100.101.102.103t= 0 0m=audio 49170 RTP/AVP 0a=rtpmap:0 PCMU/8000


INVITE

Giuseppe M. Stephan


INVITE

O INVITE contém os seguintes campos:

INVITE sip:[email protected] SIP/2.0- Método usado para envio da mensagem- Request-URI: Recurso para o qual a requisição está sendo enviada (requisição destino)- Versão do SIP.

Via: SIP/2.0/UDP lab.uniminas.br:5060;branch=z9hG4bkfw19b- Versão do SIP - /Mídia de transporte- Endereço ou nome do servidor- : Número da Porta utilizada- Identificador de transação para correlação de resposta às requisições.

Max-Forwards: 70- Número inteiro inicial que é decrementado por cada servidor SIP que receber e encaminhar a requisição.


INVITE

Giuseppe M. Stephan


INVITE

To: Joao Paulo <sip:[email protected]>- Destino da requisição SIP.

From: Luiz Claudio <sip:[email protected]>;tag=76341- Originador da Requisição SIP.

Call-ID: [email protected] Identificador usado para manter um rastreamento de uma sessão SIP específica.

Cseq: 1 INVITE- Sequência de comando: O nro é seguido pelo méto- do e incrementado a cada nova requisição enviada.

Subject: Aula sobre Protocolos- Não é usado pelo protocolo mas pode ser mostrado durante o alerting ao ponto final chamado.

Contact: <sip:[email protected]>- Exigido pelo INVITE e contém o endereço do dispositivo chamador.


INVITE

Giuseppe M. Stephan


INVITE

Content-Type: application/sdp- Referencia o corpo da mensagem.

Content-Length: ???- Indica o tamanho do corpo da mensagem em octetos conforme totalização abaixo:

v=0 - Nro da versão 05o=luiz 2890844526 2890844526 IN IP4 lab.uniminas.br

- Origem 59

s=Chamada Telefonica - Assunto

c= IN IP4 100.101.102.103 - Conexão 26

t= 0 0 - Tempo 07

m=audio 49170 RTP/AVP 0 - Mídia 25

a=rtpmap:0 PCMU/8000 - Atributos 22

====================

Total: 158


INVITE

Giuseppe M. Stephan


INVITE

Content-Type: application/sdp- Referencia o corpo da mensagem.

Content-Length: 158- Indica o tamanho do corpo da mensagem em octetos conforme totalização abaixo:

v=0 - Nro da versão 05o=luiz 2890844526 2890844526 IN IP4 lab.uniminas.br

- Origem 59

s=Chamada Telefonica - Assunto 14

c= IN IP4 100.101.102.103 - Conexão 26

t= 0 0 - Tempo 07

m=audio 49170 RTP/AVP 0 - Mídia 25

a=rtpmap:0 PCMU/8000 - Atributos 22

====================

Total: 158


INVITE

Giuseppe M. Stephan



Ringing: Resposta ao INVITE

Indica que a parte chamada recebeu o INVITE e que o Alerting está tomando lugar.

O Alerting pode ser:• um toque no telefone• uma mensagem numa tela• ou outro método que atraia a atenção da pessoa chamada.

Respostas são numéricas e classificadas pelo 1o. Dígito.

O 1, Neste caso, indica uma resposta informacional, sendo não-críticas e mostram o progresso da chamada.


INVITE

180 Ringing

Giuseppe M. Stephan


Ringing

Estrutura do 180 Ringing:

SIP/2.0 180 RingingVia: SIP/2.0/UDP lab.uniminas.br:5060;branch=z9hG4bkfw19b;received=100.101.102.103To: Joao Paulo <sip:[email protected]>;tag=a53e42From: Luiz Claudio <sip:[email protected]>;tag=76341Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>Content-Length: 0

São copiados vários campos da mensagem INVITE:Via, To, From, Call-ID e Cseq.


INVITE

180 Ringing

Giuseppe M. Stephan


Ringing

Estrutura do 180 Ringing:

SIP/2.0 180 RingingVia: SIP/2.0/UDP lab.uniminas.br:5060;branch=z9hG4bkfw19b;received=100.101.102.103

- Adiciona o endereço IP, mesmo que o DNS lab.uniminas.br pertencente à linha Via.

To: Joao Paulo <sip:[email protected]>;tag=a53e42From: Luiz Claudio <sip:[email protected]>;tag=76341- To e From não são invertidos, ou seja, mantém a direção da requisição e não da resposta.- To contém a Tag gerada pelo destinatário.

Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>- Contém agora o endereço que o destinatário pode ser contactado diretamente.

Content-Length: 0


INVITE

180 Ringing

Giuseppe M. Stephan



INVITE

180 Ringing

200 OK

OK

SIP/2.0 200 OKVia: SIP/2.0/UDP lab.uniminas.br:5060;branch=z9hG4bkfw19b;received=100.101.102.103To: Joao Paulo <sip:[email protected]>;tag=a53e42From: Luiz Claudio <sip:[email protected]>;tag=76341Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>Content-Type: application/sdpContent-Length: 155

v=0o=luiz 2890844528 2890844528 IN IP4 lab.uniminas.brs=Chamada Telefonicac= IN IP4 200.201.202.203t= 0 0m=audio 60000 RTP/AVP 0a=rtpmap:0 PCMU/8000

- As capacidades de mídia são comunicadas no corpo da mensagem SDP.

Giuseppe M. Stephan



INVITE

180 Ringing

200 OK

OK

SIP/2.0 200 OK

O SDP contém:

200.201.202.203 -> Endereço IP do ponto final

audio -> Formato da mídia

60000 -> Número da porta

RTP -> Protocolo de mídia

PCM -Law -> Codificação da mídia

8000 -> Taxa de amostragem(MHz )

Giuseppe M. Stephan



ACK

ACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP lab.uniminas.br:5060;branch=z9hG4bk321g;Max-Forwards: 70To: Joao Paulo <sip:[email protected]>;tag=a53e42From: Luiz Claudio <sip:[email protected]>;tag=76341Call-ID: [email protected]: 1 ACKContent-Length: 0

Neste último passo, a confirmação que Luiz recebeu de joao, a resposta com sucesso.

- A sequência de comando tem o mesmo número que o INVITE mas o método agora é ACK- O parâmetro branch contém um novo identificador de transação

INVITE

180 Ringing

200 OK

ACK

Sessão de Mídia

Giuseppe M. Stephan



Sessão de Mídia

O método compreendendo o INVITE, 200 OK e o ACK é chamado Three-Way Handshake.

Porquê usar o Three-way ao invés do Two-way handshake?

- A partir deste ponto, é iniciada a sessão de mídia, normalmente com o protocolo RTP.

INVITE

180 Ringing

200 OK

ACK

Sessão de Mídia

Giuseppe M. Stephan



BYE

BYE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP lab.uniminas.br:5060;branch=z9hG4bk392kf;Max-Forwards: 70To : Luiz Claudio <sip:[email protected]>;tag=76341From : Joao Paulo <sip:[email protected]>;tag=a53e42Call-ID: [email protected]: 1 BYEContent-Length: 0

- O campo Via é populado com o endereço

do servidor de João e contém um novo

identificador de transação

- Os campos To e From refletem que a

requisição é originada por João

- Pode-se notar que todos os branchs

começam com z9hG4bk

INVITE

180 Ringing

200 OK

ACK

BYE

Sessão de Mídia

Giuseppe M. Stephan



200 OK

SIP/2.0 200 OKVia: SIP/2.0/UDP lab.uniminas.br:5060;branch=z9hG4bk392kf;received=200.201.202.203To : Luiz Claudio <sip:[email protected]>;tag=76341From : Joao Paulo <sip:[email protected]>;tag=a53e42Call-ID: [email protected]: 1 BYEContent-Length: 0

- A resposta de confirmação para o BYE é um

200 OK

- Essa resposta ecoa o Cseq da requisição

original: 1 BYE.

INVITE

180 Ringing

200 OK

ACK

BYE

Sessão de Mídia

200 OK

Giuseppe M. Stephan



Chamada SIP com Proxy Server

Giuseppe M. Stephan


Chamada SIP com Servidor Proxy

Um SIP Proxy opera de maneira similar a um proxy em HTTP e outros protocolos Internet.

Ele não configura, nem termina sessões.

Se situa no meio da troca de uma mensagem SIP, recebendo mensagens e encaminhando-as.

Como o chamador não sabe exatamente onde o destinatário da chamada está logado e qual dispositivo ele está usando, o Servidor SIP Proxy serve para rotear o INVITE.


INVITE

Giuseppe M. Stephan



INVITE

INVITE (1o.)

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bkmp17aMax forrwards: 70To : Joao Paulo <sip:[email protected]>;From : Luiz Claudio <sip:[email protected]>;tag=42Call-ID: [email protected]: 1 INVITESubject: Chamada com SIP ProxyContact: <sip:[email protected]>Content-Type: application/sdpContent-Length: 159

v=0o=luiz 2890844526 2890844526 IN IP4 100.101.102.103s=Chamada Telefonicat=0 0c= IN IP4 100.101.102.103m=audio 49170 RTP/AVP 0a=rtpmap:0 PCMU/8000

O proxy procura a SIP URI do destinatário em sua base de dados e o localiza.

Giuseppe M. Stephan



INVITE

INVITE (2o.)

INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP proxy.unicamp.br:5060;branch=z9hG4bk83842.1Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bkmp17aMax forrwards: 69To : Joao Paulo <sip:[email protected]>;From : Luiz Claudio <sip:[email protected]>;tag=42Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>Content-Type: application/sdpContent-Length: 159

v=0o=luiz 2890844526 2890844526 IN IP4 100.101.102.103s=Chamada Telefonicac= IN IP4 100.101.102.103t=0 0m=audio 49170 RTP/AVP 0a=rtpmap:0 PCMU/8000

O INVITÉ é então encaminhado para o IP do destinatário encontrado adicionando o segundo campo Via.

INVITE

Giuseppe M. Stephan



INVITE

Ringing

SIP/2.0 180 Ringing Via: SIP/2.0/UDP proxy.unicamp.br:5060;branch=z9hG4bk83842.1;received=100.101.102.105Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bkmp17aTo : Joao Paulo <sip:[email protected]>;tag=314159From : Luiz Claudio <sip:[email protected]>;tag=42Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>Content-Length: 0

Com a presença de dois campos Via, Joao, sabe que o INVITE foi roteado através de um servidor proxy.

Recebido o INVITE, ele envia uma resposta para o proxy por meio do 180 Ringing.

Apenas o 1o. Campo Via contém o parâmetro received.

INVITE

180 Ringing

Giuseppe M. Stephan



INVITE

Ringing

SIP/2.0 180 Ringing Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bkmp17aTo : Joao Paulo <sip:[email protected]>;tag=314159From : Luiz Claudio <sip:[email protected]>;tag=42Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>Content-Length: 0

O proxy recebe a resposta, checa que o 1o.

Campo Via contém seu próprio endereço,

usa o identificador de transação, remove o

campo Via e encaminha a resposta para o

endereço designado, neste caso,

100.101.102.103 na porta 5060.

INVITE

180 Ringing180 Ringing

Giuseppe M. Stephan



INVITE

200 OK (1o.)

SIP/2.0 200 OK Via: SIP/2.0/UDP proxy.unicamp:5060;branch=z9hG4bk83842.1;received=100.101.102.105Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bkmp17aTo : Joao Paulo <sip:[email protected]>;tag=314159From : Luiz Claudio <sip:[email protected]>;tag=42Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>Content-Length: 159

v=0o=joao 2890844526 2890844526 IN IP4 200.201.202.203s=Chamada Telefonicac= IN IP4 200.201.202.203t=0 0m=audio 49172 RTP/AVP 0a=rtpmap:0 PCMU/8000

A resposta deve ser roteada pelo mesmo conjunto de proxies que efetuou a requisição.A chamada é aceita e Joao envia uma resposta 200 OK.

INVITE


200 OK

Giuseppe M. Stephan



INVITE

200 OK (2o.)

SIP/2.0 200 OK Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bkmp17aTo : Joao Paulo <sip:[email protected]>;tag=314159From : Luiz Claudio <sip:[email protected]>;tag=42Call-ID: [email protected]: 1 INVITEContact: <sip:[email protected]>Content_Type: application/sdpContent-Length: 159

v=0o=joao 2890844526 2890844526 IN IP4 200.201.202.203c= IN IP4 200.201.202.203t=0 0m=audio 49170 RTP/AVP 0a=rtpmap:0 PCMU/8000

A resposta deve ser roteada pelo mesmo conjunto de proxies que efetuou a requisição.A chamada é aceita e Joao envia 200 OK.

INVITE


200 OK200 OK

Giuseppe M. Stephan



INVITE

ACK

ACK sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bkka42Max Forwards: 70To : Joao Paulo <sip:[email protected]>;tag=314159From : Luiz Claudio <sip:[email protected]>;tag=42Call-ID: [email protected]: 1 ACKContent-Length: 0

A presença do campo Contact com o endereço de Joao no 200 OK permite que Luiz envie um ACK diretamente para o destinatário, bypassando o proxy.

INVITE


200 OK200 OK

ACK

Giuseppe M. Stephan



INVITE

Sessão de mídia

Na realidade, o servidor proxy não “está na chamada”.

Ele simplesmente facilita aos dois pontos finais, localizarem e contactarem um ao outro.

O servidor proxy pode derrubar o caminho de sinalização se extrapolar um determinado tempo sem troca de mensagens.

A mensagem pode ser forçada a ser roteada por ele pela inserção do campo, Record-Route.

Pode-se notar que a sessão de mídia é sempre fim-a-fim.

INVITE


200 OK200 OK

ACK

Sessão de mídia

Giuseppe M. Stephan



INVITE

BYE

BYE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bk4332Max Forwards: 70To : Luiz Claudio <sip:[email protected]>;tag=42From : Joao Paulo <sip:[email protected]>;tag= 314159Call-ID: [email protected]: 2000 BYEContent-Length: 0

A sessão de mídia é finalizada quando Joao envia uma mensagem BYE.

Nota-se que Cseq foi inicializado com 2000. Isto porque cada dispositivo SIP controle sua sequência de numeração de forma independente.

INVITE


200 OK200 OK

ACK

Sessão de mídia

BYE

Giuseppe M. Stephan



INVITE

200 OK

SIP/2.0 200 OKVia: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bk4332To : Luiz Claudio <sip:[email protected]>;tag=42From : Joao Paulo <sip:[email protected]>;tag= 314159Call-ID: [email protected]: 2000 BYEContent-Length: 0

A sessão de mídia é finalizada quando Joao envia uma mensagem BYE.

Nota-se que Cseq foi inicializado com 2000. Isto porque cada dispositivo SIP controle sua sequência de numeração de forma independente.

INVITE


200 OK200 OK

ACK

Sessão de mídia

BYE

200 OK

Giuseppe M. Stephan



Registro no SIP

Giuseppe M. Stephan



Registro no SIP

Quando um agente é conectado a um sistema de telefonia baseado em SIP, o primeiro passo é se registrar em um servidor de registro.

Dessa forma, as mensagens de entrada no sistema que sejam destinadas ao usuário poderão ser encaminhadas corretamente para a localização corrente do usuário.

O processo de registro pode ser feito de modo direto como no exemplo a seguir ou, como é feito geralmente, através de um servidor proxy.

No exemplo, Ana Claudia envia uma requisição SIP REGISTER para um servidor conhecido como Servidor de Registro.

Maria

Giuseppe M. Stephan



Registro no SIP

O servidor de registro:- recebe a mensagem- trata a informação contida na requisição- atualiza o banco de dados usado pelos proxies para rotear as mensagens SIP.

REGISTER sip:registrar.uniminas.br SIP/2.0Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bkus19Max-Forwards: 70To: Ana Claudia<sip:[email protected]>From: Ana Claudia<sip:[email protected]>;tag=3431Call-ID: [email protected]: 1 REGISTERContact: sip:[email protected]: 3600Content-Length: 0

To: Endereço de registro, ou seja, o endereço a ser associado ao usuário sendo registrado.

From: Endereço do indivíduo que iniciou o registro.

Maria

REGISTER

Contact: sip:[email protected]

Giuseppe M. Stephan



Registro no SIP

Contact: Identificação do usuário e a localização atual do usuário para onde futuras mensagens SIP serão envidas.

Expire: Indica o tempo (segundos) solicitado para se manter o registro ativo no servidor de registro.

HLR x Servidor de Registro

O registro é similar ao processo executado no telefone móvel quando ele é ligado.

Da mesma forma que este envia sua identidade para uma BS que encaminha a localização e o número do telefone para o HLR, o servidor de registro pode armazenar as informações do usuário SIP.

Este banco, tal qual o HLR, é consultado é para se saber informações dos envolvidos na comunicação.

Maria

REGISTER


Giuseppe M. Stephan



Registro no SIP

O servidor de registro reconhece o pedido e promove a aceitação deste enviando uma resposta 200 OK para maria.

A resposta ecoa a informação Contact que foi armazenada no banco de dados.

O Tag para o campo To é incluído.

SIP/2.0 200 OKVia: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bkus19To: Ana Claudia<sip:[email protected]>;tag=8771From: Ana Claudia<sip:[email protected]>;tag=3431Call-ID: [email protected]: 1 REGISTERContact: sip:[email protected];expires=3600Content-Length: 0

Maria

REGISTER


200 OK

Giuseppe M. Stephan



Registro SIP através de Proxy

O usuário do agente utiliza um esquema simples de autenticação com o servidor proxy.

O registro é aceito pelo servidor de registro.

Fluxo da mensagem

Assim que o usuário inicializa o agente, uma requisição REGISTER é enviada para a servidor proxy

Maria

REGISTER

Giuseppe M. Stephan




Fluxo da mensagem

- O servidor proxy recebe a requisição REGISTER

- Envia a resposta 100 Trying para o usuário

- A resposta serve para informar ao usuário que

a requisição foi recebida

- Dispensa a necessidade de retransmiti-la.

Maria

REGISTER

100 Trying

Giuseppe M. Stephan



Maria

REGISTER

100 Trying

REGISTER


Fluxo da mensagem

- O esquema de autenticação é simplificado

- O servidor proxy não precisa trocar maiores

mensagens como o usuário para autenticá-lo

- O servidor proxy simplesmente encaminha a

requisição REGISTER para o servidor de registro

Giuseppe M. Stephan



Maria

REGISTER

100 Trying

REGISTER


Fluxo da mensagem

- O servidor de registro envia a resposta 200 OK

para o servidor proxy.

- A operação de registro não utiliza a mensagem

ACK.

200 OK

Giuseppe M. Stephan



Maria

REGISTER

100 Trying

REGISTER

200 OK

200 OK


Fluxo da mensagem

- O servidor proxy encaminha a resposta 200 OK

para o usuário

- Esse passo notifica que o usuário está

registrado no sistema.

Giuseppe M. Stephan



Redirecionamentono SIP

Giuseppe M. Stephan


Redirecionamento no SIP

Durante o estabelecimento de comunicação entre os participantes de uma chamada SIP, normalmente é necessário determinar a localização desses participantes.

Esse processo é feito como o apoio do Servidor de Redirecionamento.

A solicitação do serviço de redirecionamento deve ser feita com o envio da requisição INVITE para o servidor de redirecionamento.

No cabeçalho da mensagem, o campo From indica o endereço do usuário que solicita o mapeamento.

O campo To indica o endereço do usuário a ser localizado

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP lab.uniminas.br

From: Luiz Claudio <[email protected]>

To: Pedro Henrique <[email protected]>

Call-ID: [email protected]

Cseq: 1 INVITE

Subject: Redirecionamento no SIP

Content-Length: 256

Content-Type: application/sdp

(corpo da mensagem)

Giuseppe M. Stephan



Operação de localização requer um serviço que mantém mapeamentos entre uma única URI e um conjunto de uma ou mais localizações alternativas que permitem encontrar o elemento referenciado pela URI.

Contact: Mostra a lista de uma ou mais localizações alternativas.

Resposta: Classe 3xx

Quando o originador de uma requisição recebe a informação de redirecionamento, a mensagem de requisição ACK é enviada para o servidor de redirecionamento.

SIP/2.0 302 Moved Temporarily





Cseq: 1 INVITE

Contact: <sip:[email protected]>

Expire: 3600

Content-Length: 0

Giuseppe M. Stephan



Em seguida, uma nova requisição é enviada com base na URI ou URIs recebidas, podendo ser URIs não SIP.

O usuário Luiz manda uma nova mensagem INVITE para o usuário Pedro.

A URI SIP fornecida pelo servidor de redirecionamento é utilizada na linha de início da mensagem.

INVITE sip:[email protected] SIP/2.0





Cseq: 2 INVITE

Subject: Redirecionamento no SIP

Content-Length: 256

Content-Type: application/sdp

(corpo da mensagem)

Giuseppe M. Stephan



RedirecionamentoSIP via servidor Proxy

Giuseppe M. Stephan



Redirecionamento

Quando o serviço de redirecionamento é utilizado no modo indireto, o servidor

proxy recebe a requisição INVITE do usuário e encaminha essa requisição para

o servidor de redirecionamento.

Em seguida, o servidor proxy utiliza a URI ou URIs, da resposta enviada pelo

servidor de redirecionamento para realizar a nova requisição INVITE em

benefício do usuário.

Pode-se então, entender o fluxo de mensagens para efetivar a comunicação

entre dois agentes devidamente registrados através de servidores proxy.

Giuseppe M. Stephan



REGISTER

B1 - O agente A envia

uma requisição

INVITE para o

servidor proxy

encaminhar para o

usuário B.

A

Giuseppe M. Stephan



A

REGISTER

100 Trying

B2 - O servidor proxy

de A recebe o

INVITE, e notifica o

usuário A enviando

a resposta 100

Trying.

Giuseppe M. Stephan



A

REGISTER

100 Trying

B

INVITE

3 - O esquema de

autenticação é

simplificado e

servidor proxy não

troca maiores

mensagens com o

agente para

autenticação. Ele

simplesmente

encaminha o INVITE

para o servidor de

redirecionamento.

Giuseppe M. Stephan



A

REGISTER

100 Trying

B

INVITE

302 Moved Temp

4 - O servidor de

redirecionamento

envia a resposta

302 Moved

Temporarily com o

mapeamente obtido

a partir do serviço

de localização.

Giuseppe M. Stephan



A

REGISTER

100 Trying

B

INVITE

302 Moved Temp

ACK

5 - O servidor proxy

de A envia a

requisição ACK para

o servidor de

redirecionamento a

fim de completar o

3-handshake.

Giuseppe M. Stephan



A

REGISTER

100 Trying

B

INVITE

302 Moved Temp

ACK

INVITE


de A utiliza a

informação de

mapeamento da

resposta recebida

para gerar um novo

INVITE a ser

enviado para

servidor proxy de B.

Giuseppe M. Stephan



A

REGISTER

100 Trying

B

INVITE

302 Moved Temp

ACK

INVITE

100 Trying


de B recebe o

INVITE e notifica o

servidor proxy de A

enviando a resposta

100 Trying.

Giuseppe M. Stephan



A

REGISTER

100 Trying

B

INVITE

302 Moved Temp

ACK

INVITE

100 Trying

INVITE


de B encaminha a

requisição INVITE

para o servidor de

redirecionamento.

Giuseppe M. Stephan



A

REGISTER

100 Triyng

B

INVITE

302 Moved Temp

ACK

INVITE

100 Triyng

INVITE

302 Moved Temp

9 - O servidor de

redirecionamento

envia a resposta

302 Moved

Temporarily com o

mapeamento obtido

a partir do serviço

de localização.

Giuseppe M. Stephan



A

REGISTER

100 Triyng

B

INVITE

302 Moved Temp

ACK

INVITE

100 Triyng

INVITE

302 Moved Temp

ACK


de B envia a

requisição ACK para

o servidor de

redirecionamento a

fim de completar o

3-handshake.

Giuseppe M. Stephan



A

REGISTER

100 Triyng

B

INVITE

302 Moved Temp

ACK

INVITE

100 Triyng

INVITE

302 Moved Temp

ACK INVITE

11 - O servidor

proxy de B utiliza a

informação de

mapeamento da

resposta recebida

para gerar um novo

INVITE a ser

enviado para o

agente B.

Giuseppe M. Stephan



A

REGISTER

100 Triyng

B

INVITE

302 Moved Temp

ACK

INVITE

100 Triyng

INVITE

302 Moved Temp

ACK INVITE

100 Triyng

12 - O agente B

recebe o INVITE e

notifica o servidor

proxy de B

enviando a resposta

100 Trying.

Giuseppe M. Stephan



Forking

Giuseppe M. Stephan



Forking

Quando um agente se encontra registrado em mais de uma localização, após

consulta ao servidor de redirecionamento, o servidor proxy recebe várias URIs

associadas ao agente, cada uma referente a uma localização distinta.

Para tentar contactar o agente, o servidor proxy recorre à operação forking, em

que um INVITE é enviado para as diferentes localizaçãoes, em paralelo ou

sequencialmente.

No modo paralelo, o servidor proxy recebe várias respostas 180 Ringing. Assim

que o primeiro atender ele envia um 200 OK e para os demais enviará a

mensagem CANCEL. Por fim, deverá receber um 200 OK de todos estes últimos.

Giuseppe M. Stephan



A B

Tomando a sequência do

fluxo apresentado

anteriormente.

11 - O SPb utiliza a

informação de

mapeamento da resposta

recebida para gerar um

novo INVITE a ser

enviado para o usuário B.

12 - O SPb utiliza a

informação de

mapeamento da resposta

recebida para gerar um

novo INVITE a ser

enviado ao agente C.

C

SPb (Servidor Proxy B) SPa (Servidor Proxy A)

INVITE

INVITE

Giuseppe M. Stephan



A B

13 - O agente C recebe o

INVITE e notifica o SPb

enviando a resposta 100

Trying. A resposta de um

agente pode chegar

antes da resposta de

outro, no forking paralelo.

14 - O agente B recebe o

INVITE e notifica o SPb

enviando a resposta 100

Trying.

C


INVITE

INVITE

100 Trying

100 Trying

Giuseppe M. Stephan



A B

15 - O agente C aceita a

descrição da sessão e

envia a resposta 180

Ringing indicando que o

agente está sendo

notificado da existência

de uma chamada. Essa

mensagem será roteada

através do sistema até o

agente A com base nos

campos Header Via.

16 - O SPb encaminha a

mensagem 180 Ringing

do agente C para ao SPa.

C


INVITE

INVITE

100 Trying

100 Trying


Giuseppe M. Stephan



A B

17 - O SPa encaminha a


do agente C para o

agente A.

18 - O agente B aceita a

descrição da sessão e

envia a resposta 180

Ringing indicando que o

usuário está sendo

notificado da existência

de uma chamada. Essa

mensagem será roteada

através do sistema até o

agente A, com base nos

campos header Via.

C


INVITE

INVITE

100 Trying

100 Trying

180 Ringing180 Ringing180 Ringing

180 Ringing

Giuseppe M. Stephan



A B

19 - O SPb encaminha a


do usuário B para o SPa.

20 - O SPa encaminha a


do usuário B para o

usuário ª

21 - Quando o usuário C

atende à chamada, a

resposta 200 OK é

enviada para o SPb.

C


INVITE

INVITE

100 Trying

100 Trying


180 Ringing180 Ringing 180 Ringing

200 OK

Giuseppe M. Stephan



A B

22 - Assim que recebe a

resposta 200 OK do

agente C, o SPb envia um

CANCEL para o agente B.

23 - O SPb encaminha o

200 OK do agente C para

o usuário A.

24 - O SPa encaminha o

200 OK do agente C para

o agente A.

C


INVITE

INVITE

100 Trying

100 Trying



200 OK

200 OK200 OK

180 Ringing

CANCEL

Giuseppe M. Stephan



A B

25 - Assim que recebe o

CANCEL, o agente B

envia a resposta 200 OK

para o SPb.

26 - O agente A, tendo

recebido as respostas

180 Ringing e 200 OK,

envia um ACK para o SPa.


ACK do agente A para o

SPb.


ACK do agente A para o

agente C.

C


INVITE

INVITE

100 Trying

100 Trying



200 OK

200 OK200 OK

200 OK

180 Ringing

CANCEL

ACKACK

ACK

Giuseppe M. Stephan



A B

29 - Os dois canais de

mão única esatabelecidos

entre os agentes, um de

A para C e outro de C

para A, através de RTP,

são utilizados pelos

usuários para

conversação.

C


INVITE

INVITE

100 Trying

100 Trying



200 OK

200 OK200 OK

200 OK

180 Ringing

CANCEL

ACKACK

ACK

VOZ (RTP)

Giuseppe M. Stephan



A B

30 - Para encerrar a

comunicação, o agente C

envia um BYE para o SPb.


BYE do agente C para o

SPa.

32 - O Spa encaminha o

BYE do agente C para o

agente A.

C


INVITE

INVITE

100 Trying

100 Trying



200 OK

200 OK200 OK

200 OK

180 Ringing

CANCEL

ACKACK

ACK

BYE BYE BYE

VOZ (RTP)

Giuseppe M. Stephan



A B C


INVITE

INVITE

100 Trying

100 Trying



200 OK

200 OK200 OK

200 OK

180 Ringing

200 OK200 OK200 OK

CANCEL

ACKACK

ACK

BYE BYE BYE

VOZ (RTP)

33 - O agente A recebe a

requisição BYE e envia a

resposta 200 OK para o

SPa, finalizando a

chamada e fechando o

canal de voz.


200 OK do agente A para

o SPb.


200 OK do agente A para

o agente C.

Giuseppe M. Stephan


N o modo sequencial, o servidor proxy deve encaminhar o INVITE para

cada localização, uma por vez.

O encaminhamento é feito para a próxima localização apenas se a

localização corrente não atender à chamada.

A busca é encerrada se alguma das localizações atender à chamada

ou se delas nenhuma atender à chamada.

Giuseppe M. Stephan



Presença e Instant Message

Giuseppe M. Stephan



Presença

Estado de um usuário ou dispositivo em um momento particular.

• Autenticado ou não

• Ativo ou inativo em sua estação

• Desocupado ou distante

• Localização baseado em coordenadas

• Termos gerais como “no escritório”, “viajando” ou “no

laboratório”

• Smiles que retratam que está relaxando, trabalhando ou

stressado.

SUBSCRIBE : requisita status ou atualizações de presença do servidor

de presença.

NOTIFY: entrega a informação para o requisitante.

Giuseppe M. Stephan



No exemplo ao lado, Carlos deseja se

comunicar com Paulo e para encontrar o

status de Paulo, ele subscreve a

informação de presença para Paulo

enviando uma mensagem SUBSCRIBE.

SUBSCRIBE sip:[email protected] SIP/2.0

Via SIP/2.0/TCP lab.academia.br:5060;

branch=z9hG4bk348471123

Max-Forwards: 70

To: Paulo Maia <sip:[email protected]>

From: Carlos Lara

<sip:[email protected]>;tag=21171

Cseq: 3412 SUBSCRIBE

Allow_events: presence

Allow: ACK, INVITE, CANCEL, BYE, NOTIFY, SUBSCRIBE,

MESSAGE

Contact: <sip:[email protected];transport=tcp>

Event: presence

Content-Length: 0

Carlos SUBSCRIBE

Paulo

Giuseppe M. Stephan



Presença

TCP é usado como transporte.

Isto é indicado no campo Via e no parâmetro transport=tcp do campo

Contact.

Contém os campos Allow Allow-Events que são usados para advertir sobre

as capacidades.

• Carlos suporta receber sete métodos (Allow) e também subscrição de

presença contido em Allow-Event.

• SUBSCRIBE está criando um diálogo de maneira análoga ao INVITE.

• O campo From contém um tag mas o campo To ainda não.

Giuseppe M. Stephan



Paulo aceita a requisição de subscrição

enviando uma resposta 202 Accepted de

volta a Carlos.

SIP/2.0 202 Accepted


branch=z9hG4bk348471123;received=19.34.3.1

To: Paulo Maia <sip:[email protected]>;tag=25140

From: Carlos Lara

<sip:[email protected]>;tag=21171

Call-ID: 58dkfj349241k34452k592520

Cseq: 3412 SUBSCRIBE



MESSAGE


Event: presence

Expires=3600

Content-Length: 0

Carlos Paulo SUBSCRIBE

202 Accepted

Giuseppe M. Stephan



A subscrição atual é iniciada por Paulo

enviando o primeiro NOTIFY de volta para

Carlos.

NOTIFY sip: [email protected] SIP/2.

Via SIP/2.0/TCP sipping.ietf.org:5060;


To: Carlos Lara <sip:[email protected]>;tag=21171

From:Paulo Maia <sip:[email protected]>;tag=25140

Call-ID: 58dkfj349241k34452k592520

Cseq: 1026 NOTIFY


MESSAGE

Allow_events: dialog


Subscription-State: active;expires=3600

Event: presence

Content_Type: application/cpim-pidf+xml

Content-Length: 244


202 Accepted

NOTIFY

Giuseppe M. Stephan



<?xml version=“1.0” encoding=“UTF-8”?>

<presence xmlns=“urn:ietf:params:xml:ns:cpim-pidf”

entity=“sip:[email protected]”>

<tuple id=“452426775”>

<status>

<basic>closed</basic>

</status>

</tuple>

</presence>

O NOTIFY é enviado dentro de um diálogo

estabelecido com o SUBSCRIBE.

Ele usa o mesmo identificador de diálogo

(Call-ID, local e tags remotas).

A requisição é enviada para o Contact

fornecido por Carlos na chamada da

subscrição.


202 Accepted

NOTIFY

Giuseppe M. Stephan



O campo Subcription-State indica que a

subscrição foi autorizada e ativada e que irá

expirar em 1 hora, a não ser que seja

atualizada por Carlos.

Commom Presence and Instant Message

Presence Information Data Format (CPIM

PIDF) é o corpo da mensagemem XML que

contém a informação de status de que Paulo

está atualmente off-line (closed).


202 Accepted

NOTIFY

Giuseppe M. Stephan



Carlos envia uma resposta 200 Ok para o

NOTIFY para confirmar que foi recebido com

sucesso.Carlos Paulo

SUBSCRIBE

202 Accepted

NOTIFY

200 Ok

SIP/2.0 200 OK





Call-ID: 58dkfj349241k34452k592520

Cseq: 1026 NOTIFY

Content-Length: 0

Giuseppe M. Stephan



Mais tarde, quando Paulo se conecta, esta

informação é fornecida em um segundo

NOTIFY contendo a alteração do status.Carlos Paulo

SUBSCRIBE

202 Accepted

NOTIFY

200 Ok

NOTIFY

Mais tarde...

NOTIFY sip: [email protected] SIP/2.





Call-ID: 58dkfj349241k34452k592520

Cseq: 1027 NOTIFY


MESSAGE



Subscription-State: active;expires=1800

Event: presence

Content_Type: application/cpim-pidf+xml

Content-Length: 325

Giuseppe M. Stephan



<?xml version=“1.0” encoding=“UTF-8”?>

<presence xmlns=“urn:ietf:params:xml:ns:cpim-pidf”

entity=“sip:[email protected]”>

<tuple id=“452426775”>

<status>

<basic>open</basic>

</status>

<contact>sip:[email protected];transport=tcp

</contact>

</tuple>

</presence>

O tempo de expiração indicado no campo

Subscription-State indica que 30 minutos se

passaram desde que a subscrição foi

estabelecida.

O CPIM PIDF XML indica que Paulo está on-line

(open) e pode ser acessado via a URI

sip::[email protected];transport=tcp.


202 Accepted

NOTIFY

200 Ok

NOTIFY

Mais tarde ...

Giuseppe M. Stephan



Carlos confirma o recebimento do NOTIFY com

um 200 OK de resposta.


202 Accepted

NOTIFY

200 Ok

NOTIFY

Mais tarde ...

200 OK

SIP/2.0 200 OK





Call-ID: 58dkfj349241k34452k592520

Cseq: 1027 NOTIFY

Content-Length: 0

Giuseppe M. Stephan



Agora que Carlos sabe que Paulo está on-line,

ele envia um instant-message para ele usando

o Contact URI do NOTIFY.Carlos Paulo

SUBSCRIBE

202 Accepted

NOTIFY

200 Ok

NOTIFY

Mais tarde

200 OK

MESSAGE

MESSAGE sip:[email protected] SIP/2.0


branch=z9hG4bk3gtr2

Max-Forwards: 70

To: Paulo Maia <sip:[email protected]>

From: Carlos Lara <sip:[email protected]>;tag=4542

Call-ID: 9dkei93vjq1ei3

Cseq: 15 MESSAGE



MESSAGE

Content-Type: text/plain

Content-Length: 10

Ow, ta ai?

Giuseppe M. Stephan



A resposta 200 OK é usada para reconhecer o

recebimento do instant-message.


202 Accepted

NOTIFY

200 Ok

NOTIFY

Mais tarde

200 OK

MESSAGE

SIP/2.0 200 OK

Via SIP/2.0/TCP lab.academia.org:5060;

branch=z9hG4bk3gtr2;received=19.34.3.1

To: Paulo Maia <sip:[email protected]>;tag=2321

From:Carlos Lara <sip:[email protected]>;tag=4542

Call-ID: 9dke193vjq1e13

Cseq: 15 MESSAGE

Content-Length: 0

200 Ok

Giuseppe M. Stephan



Paulo responde com uma mensagem, com

novo Call-ID e novo tag From (um instant-

message nunca é enviado em uma resposta

200 OK).Carlos Paulo

SUBSCRIBE

202 Accepted

NOTIFY

200 Ok

NOTIFY

Mais tarde

200 OK

MESSAGE

200 Ok

MESSAGE sip:[email protected] SIP/2.0



Max-Forwards: 70

To: Carlos Lara <sip:[email protected]>


Call-ID: 1k34452k592520

Cseq: 2321 MESSAGE



MESSAGE

Content-Type: text/plain

Content-Length: 23

to sim, e as novidades? MESSAGE

Giuseppe M. Stephan



E uma nova resposta é enviada.


202 Accepted

NOTIFY

200 Ok

NOTIFY

Mais tarde

200 OK

MESSAGE

200 Ok

MESSAGE

200 Ok

SIP/2.0 200 OK



To: Carlos Lara

<sip:[email protected]>;tag=mc3bg5q77wms

From: Paulo Maia <sip:[email protected]>;tag=14083

Call-ID: 1k34452k592520

Cseq: 2321 MESSAGE

Content-Length: 0

Giuseppe M. Stephan



Características do SIP

Giuseppe M. Stephan


Descrição do protocolo

6 tipos de serviços

Localização do Usuário: Localizar o terminal para estabelecer a conexão

Disponibilidade do Usuário: Estabelecer uma sessão de comunicação

Recursos do Usuário: Determinar os meios a serem utilizados.

Características de Negociação: Negociar e acordar funcionalidades entre as

partes

Gestão da Sessão : Iniciar, terminar ou colocar em espera as sessões

Modificar Sessão : Modificar uma sessão em andamento.

Giuseppe M. Stephan


Características

• Protocolo tipo Cliente/Servidor (porta 5060)

• Escalabilidade e simplicidade (Princípio KISS – Keep It Simple Stupid)

• Cada funcionalidade como proxying, redirection, location, ou registration pode

residir em servidores físicos distintos

• Mobilidade: terminais diferentes, mesma identificação

• Localização do usuário através de um endereçamento tipo e-mail

Giuseppe M. Stephan


Características

• URLs para endereçamento

• Comunicação entre domínios admistrativos através de DNS

• Herança do protocolo HTTP: requisições e respostas no formato texto

• MIME-TYPES: conteúdo no corpo das mensagem: fotos, vídeos, páginas web,

etc.

• Independência do protocolo de rede (UDP, TCP, SCTP, AAL5, X.25)

Giuseppe M. Stephan


Características

O SIP utiliza um modelo cliente-servidor:

UAC: user-agent client (Cliente) => Aplicação chamadora

UAS: user-agent server (Servidor) => Aceita, redireciona e recusa

chamadas

E ainda:

redirect server: Solicitações de redirecionamento

proxy server: Servidor + Cliente

registrar: tracking de localização de usuários.

Ao iniciar, o Cliente se registra de forma autenticada em um Servidor (via

multicast) de modo a informar o local proxy de sua localização.

Este registro expira conforme configuração do servidor.

Giuseppe M. Stephan


Características

Decisões de design:

• Pode ser executado sobre camadas confiáveis (TCP, SCTP) ou não-confiáveis

(UDP)

• Requisição de roteamento: direto (performance) ou por proxy (controle)

• Separação em sinalização e descrição da mídia

• Extensibilidade: indica e requer capacidades dos proxies e UAs

• Requisições subsequentes e retransmissões podem tomar rotas diferentes

Giuseppe M. Stephan


Métodos SIP

Giuseppe M. Stephan


Transações SIP

• Compostas por dois tipos de métodos:

• requisições iniciadas pelo CLIENTE e

• respostas enviadas pelo SERVIDOR.

• Define poucos métodos, de modo a reduzir a complexidade e novos

métodos podem ser introduzidos sem necessidade de mudança no

protocolo.

• Requisições e respostas podem conter qualquer tipo de objeto (binário/texto).

• Requisições contém a descrição da sessão (mídia), enquanto as respostas

contém a descrição da sessão em caso de sucesso, HTML ou texto puro em

caso de falha.

Giuseppe M. Stephan


Métodos

A RFC 3261 (SIP) introduziu seis métodos de requisição:

• INVITE : Indica que o usuário/serviço foi convidado a participar da sessão.

• ACK: Funciona como a confirmação de um INVITE.

• OPTIONS: Indaga as capacidades do SERVIDOR.

• BYE: CLIENTE indica ao SERVIDOR que deseja encerrar a chamada.

• CANCEL: Cancela uma requisição pendente mas ainda não completada.

• REGISTER: Registra o endereço do usuário em um Servidor SIP.

Giuseppe M. Stephan


Métodos

Outras requisições introduzidas a posteriori no SIP foram:

PRACK: Confirma o provisionamento.

SUBSCRIBE: Registra-se para uma Notificação de Evento do Notifier

NOTIFY: Notifica o assinante de um novo evento.

INFO: Usado para transportar informações “out-of-band” (dígitos DTMF).

MESSAGE: Utilizada para transportar mensagens instantâneas usando SIP.

UPDATE: Modifica o estado da sessão sem modificar o estado do diálogo.

REFER: Solicita ao destinatário que envie uma requisição SIP (transferência de chamada).

Giuseppe M. Stephan


Códigos de Resposta

Mensagem gerada por um UAS ou um servidor SIP, para responder a uma

solicitação. Existem 6 tipos de classes de Códigos de Resposta:

1xx: Informação. Recebe informação sobre o progresso do pedido. A 1a.

mensagem dessa classe recebida pelo usuário, confirma o recebimento do

INVITE pelo servidor e indica que o usuário deve parar de enviar

solicitações INVITE. [Searching, Ringing, Trying...]

2xx: Sucesso. Informa que o pedido foi aceito e atendido. No caso de ser uma

solicitação INVITE, deve ser enviado um ACK confirmando. [Sucess]

3xx: Redirecionamento. Em geral, enviado por um servidor SIP de

redirecionamento, serve para indicar que o destinatário não está nessa

localização e informar sua nova a localização. [Forwarding]

Giuseppe M. Stephan



4xx: Erro por parte do Cliente. Informa que houve um erro na solicitação por

parte do cliente, que deverá refazer a solicitação de acordo com o erro

indicado. [Client Mistakes]

5xx: Erro por parte do Servidor. Informa que a mensagem não pode ser

enviada com sucesso em decorrência de um erro com o servidor. [Server

Failures]

6xx: Classe Erro Global. Informa que houve um erro e que essa mensagem irá

falhar em qualquer servidor, portanto não deverá ser reenviada. [Busy,

Refuse, not available anywhere]

Caso uma mensagem em particular não possa ser entendida por um UAC, ele

deverá entendê-la pela descrição da classe, por exemplo, um UAC recebe uma

mensagem 599 (servidor desconectado) e não compreende a mensagem, ele

deverá interpretá-la como a classe 5xx, erro do servidor.

Giuseppe M. Stephan



1xx – I nf ormativo Pedido recebido, continuando aprocessar o pedido

100 Tentando180 Chamando181 Chamada sendo retransmitida182 Colocado na fi la

2xx – Sucesso A ação f oi recebida, entendida eaceita com sucesso

200 OK3xx - Redirecionamento Uma ação adicional deve ser

tomada para completar o pedido300 Múltiplas escolhas

Giuseppe M. Stephan



Giuseppe M. Stephan


Mensagem SIP

Giuseppe M. Stephan


Mensagens SIP

Transação

• Sequência de mensagens SIP iniciada com um pedido

• Pode conter uma ou mais respostas temporárias (1xx)

• Contém uma ou mais respostas finais (não 1xx)

Diálogo

• Sequência de mensagens entre dois agentes usuários

• Iniciado em geral com um pedido INVITE e finalizado com BYE

• Constituído por uma ou mais transações sucessivas

Chamada

• Sequência de mensagens originadas por um INVITE de um agente usuário

• Inclui um diálogo ou múltiplos diálogos no caso de chamadas em

conferência

Giuseppe M. Stephan


Mensagens SIP

Giuseppe M. Stephan


Mensagens SIP

Cabeçalho das mensagens

• Campos com informação útil para o processamento da mensagem

Campos do cabeçalho (mais importantes)

• Via: Mostra o protocolo de transporte usado e a rota requisitada.

Cada proxy adiciona uma linha a este campo

• From: Mostra o endereço do originador da mensagem

• To: Mostra o endereço de destinatário da mensagem

• Call ID: Identificador único da chamada a que corresponde a

mensagem

• Cseq: Inicia com um nro aleatório e sequencialmente identifica a msg

• Contact: Endereço (s) que podem ser usados para contactar o usuário

• User-Agent:O cliente que negocia a comunicação.

Giuseppe M. Stephan


Estrutura da mensagem SIP

Cabeçalho

Via: Campo obrigatório e grava as rotas SIP tomadas por uma requisição e é usado para rotear as resposta de volta ao originador. Por meio dele pode-

se enxergar todos os proxies percorridos pelo caminho. Cada proxy adiciona um branch contendo um tag criptografado.

From(f): Cabeçalho necessário em toda comunicação SIP, ele identifica o transmissor de determinada requisição.

Exemplo de uso:

From:<sip:[email protected].

Giuseppe M. Stephan



Cabeçalho

To: Exigido em todo cabeçalho para indicar o destinatário da requisição. Qualquer resposta gerada pelo user agent adicionará ao cabeçalho um campo

tag.

Contact: Usado para manter uma URI que identifica o recursos requisitado ou o originador da requisição, dependendo se está presente na requisição ou na resposta. Uma vez recebido, o Contact pode ser cacheado e usado para roteamento de futuras requisições dentro do diálogo que permitirão

bypassar o proxy. Esta ação é inibida pelo Recording-Route

Giuseppe M. Stephan



Cabeçalho

Call-ID: cabeçalho indispensável numa comunicação SIP, ele serve como identificador único para uma mensagem, ele é gerado localmente de maneira randômica, contem um @ e um endereço de IP do transmissor.

Exemplo de uso:

i:[email protected]

Cseq: Cabeçalho obrigatório que funciona como um contador para cada requisição feita, com exceção de ACK e CANCEL. O Cseq é utilizado pelos UAS para diferenciar uma requisição nova de uma retransmissão e utilizado pelos UAC para identificar a qual requisição uma determinada resposta pertence.

Exemplo de Uso:

CSeq: 3 OPTIONS

Giuseppe M. Stephan


Arquitetura SIP

Giuseppe M. Stephan


Arquitetura SIP

Servidor Redirect

Servidor de

Locatização

Servidor Registrar

Agente de Usuário

Proxy Server

Gateway

RTPC

Proxy Server

Giuseppe M. Stephan


SIP User Agents

Aplicação que inicia, recebe e termina chamadas:

Ele pode agir tanto como:

• Agente de Usuário Cliente ou CLIENTE ou UAC:

=> Entidade que inicia a chamda, enviando requisições e recebendo

respostas

• Agente de Usuário de Servidor ou SERVIDOR ou UAS:

=> Entidade que recebe uma chamada, enviando respostas e

recebendo requisições.

Os usuários são identificados por nomes ou por endereços de email;

O usuário chamado é alcançado, não importando onde o usuário esteja ou qual endereço IP o seu host esteja utilizando no momento.

Giuseppe M. Stephan


SIP Proxy Server

• Tipo de servidor intermediário do SIP, que atua também como cliente e servidor, recebendo as requisições e passando adiante para servidores mais próximos do destino

Provê um mecanismo centralizado de roteamento das mensagens SIP:

• Usuários enviam pedidos de sessão a um servidor Proxy

• Proxy encaminha os pedidos para o Proxy do domínio de destino

• Proxy do domínio de destino consulta o Servidor de Registro

• Proxy do domínio de destino encaminha o pedido para o usuário

• Dois tipos de Proxy:Outbound Proxy : Envia sinalização para outros

domínios

Inbound Proxy : Envia sinalização para o mesmo domínio

• Funções do Proxy:Resolução de endereçosGerenciamento de políticasFirewalls e Call path hiding

• Existem dois tipos de servidores : Stateful Proxy Server e Stateless Proxy Server

Giuseppe M. Stephan


Stateful Proxy Servers

• Mantém o estado das transações

• Permite dividir a chamada (Fork) para múltiplos servidores na tentativa de localizar o usuário, dessa maneira, cria uma árvore de busca

• Possuem maior confiabilidade

• Capacidade de computar o gasto do cliente

• Utilizam protocolo TCP

Giuseppe M. Stephan


Stateless Proxy Servers

• Não armazenam o estado da transação apenas envia adiante as

requisições e as respostas

• Possuem maior velocidade

• Menos confiabilidade

• Incapacidade de computar gastos do cliente.

Giuseppe M. Stephan


SIP Redirect Server

• Tipo de servidor SIP com a função de informar que determinado usuário está registrado em outro domínio

• Recebe um pedido de sessão e responde com as localizações do

destinatário

• O originário recebe a informação e envia o pedido para o destinatário

• Não reencaminha os pedidos

• Alta capacidade de processamento devido ao menor número de

msgs para processar

• Serviços são dependentes do dispositivo client

Giuseppe M. Stephan


SIP Registrar Server

• O servidor Registrar pode aceitar a autenticação

• Realiza o registro dos agentes de usuários

• Servidor que armazena a localização dos usuários:

usuario@endereçoIP:porta

• Associa identificadores humanos ([email protected]) com endereços IPs dinâmicos

• Fornece um serviço de localização.

Giuseppe M. Stephan


Questões

1) Quais as primitivas do protocolo SIP?

2) Quais os mecanismos de segurança em SIP?

3) Quais as principais vantagens do protocolo SIP?

4) Por que o SIP utiliza o Three-way Handshake em vez do Two- way Handshake?

5) Quais são os três tipos de servidores da arquitetura SIP?

6) Das estruturas do H.323: H.323, H.225.0 + RAS, H.245 e gatekeeper, a que estruturas se referem no SIP?

Giuseppe M. Stephan


Respostas

1) As três primitivas do protocolo SIP são: inicialização, modificação e a finalização das sessões.

2) Encriptação, autenticação e esteganografia.

3) A sua simplicidade, eficiência, flexibilidade e facilidade de comunicação com os protocolos da Internet HTTP e SMTP.

4) Ao enviar uma solicitação de INVITE, o receptor pode demorar muito tempo pra responder, e ao responder pode ser que o emissor não esteja mais conectado, uma maneira de contornar foi o three way handshake, primeiro o emissor solicita um INVITE, o receptor ao confirmar envia uma mensagem 200 OK e caso o emissor ainda esteja conectado, é enviado automaticamente um ACK.

5) Proxy, redirect e registrar

6) SIP + SDP, SIP, SDP+ SMIL, proxy

Giuseppe M. Stephan


Fim

Giuseppe M. Stephan


Pesquisa:

Tema: Tem a ver com: Responsável:===== =======================

- URI: URL/URN/RFC 3305

- Codec: Perdas/Taxas de Bits

- IAD: Características

- ATA: FXO/FXS/Características

- Proxy: Características

- RTP: RTCP/UDP

Documents

Aula4 Telefonia+Digital+ +VoIP+SIP