Aula4 Telefonia+Digital+ +VoIP+SIP

SIP - Session Initiation Protocol
VoIP - Voice over IP
Protocolo SIP Session Initiation Protocol

Giuseppe M. Stephan

Agenda
1 - Introduo Histrico 2 - Chamada SIP Estabelecimento de uma sesso simples Chamada SIP com Proxy Server Registro no SIP Redirecionamento no SIP Redirecionamento SIP via servidor Proxy Forking Presena e Instant Message 3 - Caractersticas do SIP Mtodos SIP Transaes SIP Cdigos de resposta 4 - Mensagem SIP 5 - Arquitetura SIP
Giuseppe M. Stephan
Introduo ao SIP
Giuseppe M. Stephan

Introduo Ligao VoIP Necessita que se estabelea uma sesso entre o emissor e o receptor.
A sesso pode ser: Simples ligao de voz entre duas pessoas Ligao envolvendo voz, dados e vdeo Conferncia multimdia, ...
VoIP: principais protocolos de estabelecimento de sesso so:

H.323, MGCP/Megaco e o SIP.
Giuseppe M. Stephan

Introduo SIP no est limitado Internet Permite estabelecer presena de usurio e localizao. Disponvel para aplicaes que tenham a noo de sesso: Sistemas de Realidade Virtual Games de rede
Vdeo-conferncia
Processamento de Chamadas Localizao de usurios Instant Messaging Presena.
Giuseppe M. Stephan

Histrico Dcada 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: Lanada a 1a. verso do protocolo que apenas estabelecia a sesso Chamado inicialmente de Session Invitation Protocol.
1997: Lanada a verso 2.0

Novas funcionalidades como controles para conferncias Passou a significar Session Iniatition Protocol, Mescla entre SIPv1 e o SCIP(Simple Conference Invitation Protocol)
Vantagem em relao aos predecessores

Comunicao tanto por TCP como por UDP Incorporao dos protocolos: HTTP e SMTP.
Giuseppe M. Stephan

Histrico 1999: Publicado em Abril, como RFC 2543.
2000:
2001:
Escolhido como protocolo de comunicao 3GPP.

IETF decide dividir o grupo de desenvolvedores do SIP
Criao de 3 grupos com focos de pesquisa diferentes: SIP: Responsvel pelas especificaes do protocolo/extenses SIPPING:Session Initiation Protocol Investigation Investigar aplicaes, desenvolver requisitos e BCP. SIMPLE: SIP for Instant Messaging and Presence Leveraging Extensions Padronizao de Presena e Instant Messenger utilizando o SIP. 2002: A verso SIPv2 proposta como padro e publicado como RFC 3261,
Giuseppe M. Stephan
Estabelecimento de uma sesso simples
Giuseppe M. Stephan

Premissas
Os dispositivos podem ser telefones SIP,
hand-helds, palmtops ou ainda celulares
assumido que ambos os dispositivos so conectados para um rede IP
Cada um sabe o endereo do outro
Giuseppe M. Stephan

O chamador inicia a troca de mensagens enviando um comando INVITE para o ponto final chamado. O INVITE contm detalhes do tipo de sesso ou chamada requisitada. Pode ser: uma sesso simples de voz (udio), uma sesso multimdia como vdeoconferncia, ou ainda uma sesso de jogo.
INVITE
Giuseppe M. Stephan

INVITE O INVITE contm os seguintes campos:
INVITE sip:joao@uniminas.br SIP/2.0 Via: SIP/2.0/UDP lab.uniminas.br:5060;branch=z9hG4bkfw19b Max-Forwards: 70 To: Joao Paulo <sip:joao@uniminas.br> From: Luiz Claudio <sip:luiz@uniminas.br>;tag=76341 Call-ID: 123456789@lab.uniminas.br Cseq: 1 INVITE Subject: Aula sobre Protocolos Contact: <sip:luiz@lab.uniminas.br> Content-Type: application/sdp Content-Length: ??? v=0 o=luiz 2890844526 2890844526 IN IP4 lab.uniminas.br s=Chamada Telefonica c= IN IP4 100.101.102.103 t= 0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000
Giuseppe M. Stephan
INVITE

INVITE O INVITE contm os seguintes campos:
INVITE sip:joao@uniminas.br SIP/2.0
- Mtodo usado para envio da mensagem - Request-URI: Recurso para o qual a requisio est sendo enviada (requisio destino) - Verso do SIP.
Via: SIP/2.0/UDP lab.uniminas.br:5060;branch=z9hG4bkfw19b
INVITE
- Verso do SIP - /Mdia de transporte - Endereo ou nome do servidor - : Nmero da Porta utilizada - Identificador de transao para correlao de resposta s requisies.
Max-Forwards: 70
- Nmero inteiro inicial que decrementado por cada servidor SIP que receber e encaminhar a requisio.
Giuseppe M. Stephan

INVITE
To: Joao Paulo <sip:joao@uniminas.br>
- Destino da requisio SIP.
From: Luiz Claudio <sip:luiz@uniminas.br>;tag=76341
- Originador da Requisio SIP.
INVITE
Call-ID: 123456789@lab.uniminas.br
- Identificador usado para manter um rastreamento de uma sesso SIP especfica.

Cseq: 1 INVITE
- Sequncia de comando: O nro seguido pelo mtodo e incrementado a cada nova requisio enviada.
Subject: Aula sobre Protocolos
- No usado pelo protocolo mas pode ser mostrado durante o alerting ao ponto final chamado.
Contact: <sip:luiz@lab.uniminas.br>
- Exigido pelo INVITE e contm o endereo do dispositivo chamador.

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 totalizao abaixo:

v=0
INVITE
- Nro da verso - Origem 59 - Assunto
05
o=luiz 2890844526 2890844526 IN IP4 lab.uniminas.br s=Chamada Telefonica t= 0 0
c= IN IP4 100.101.102.103 - Conexo
26
- Tempo
07
m=audio 49170 RTP/AVP 0 - Mdia a=rtpmap:0 PCMU/8000
25
22
- Atributos 158
==================== Total:
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 totalizao abaixo:

v=0
INVITE
- Nro da verso - Origem 59 - Assunto
05
o=luiz 2890844526 2890844526 IN IP4 lab.uniminas.br s=Chamada Telefonica t= 0 0
14 26 07
c= IN IP4 100.101.102.103 - Conexo
- Tempo
m=audio 49170 RTP/AVP 0 - Mdia a=rtpmap:0 PCMU/8000
25
22
- Atributos 158
==================== Total:
Giuseppe M. Stephan

Estabelecimento de uma sesso simples 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 mtodo que atraia a ateno da pessoa chamada. Respostas so numricas e classificadas pelo 1o. Dgito. O 1, Neste caso, indica uma resposta informacional, sendo no-crticas e mostram o progresso da chamada.
Giuseppe M. Stephan
INVITE
180 Ringing

Ringing Estrutura do 180 Ringing: SIP/2.0 180 Ringing
Via: SIP/2.0/UDP lab.uniminas.br:5060;branch=z9hG4bkfw19b; received=100.101.102.103
To: Joao Paulo <sip:johann@uniminas.br>;tag=a53e42 From: Luiz Claudio <sip:luiz@uniminas.br>;tag=76341 Call-ID: 123456789@lab.uniminas.br Cseq: 1 INVITE Contact: <sip:luiz@uniminas.br> Content-Length: 0
INVITE
180 Ringing
So copiados vrios campos da mensagem INVITE: Via, To, From, Call-ID e Cseq.
Giuseppe M. Stephan

Ringing Estrutura do 180 Ringing: SIP/2.0 180 Ringing
- Adiciona o endereo IP, mesmo que o DNS lab.uniminas.br pertencente linha Via.
INVITE
180 Ringing
To: Joao Paulo <sip:johann@uniminas.br>;tag=a53e42 From: Luiz Claudio <sip:luiz@uniminas.br>;tag=76341
- To e From no so invertidos, ou seja, mantm a direo da requisio e no da resposta. - To contm a Tag gerada pelo destinatrio.
Call-ID: 123456789@lab.uniminas.br Cseq: 1 INVITE Contact: <sip:joao@uniminas.br>
- Contm agora o endereo que o destinatrio pode ser contactado diretamente.

Content-Length: 0
Giuseppe M. Stephan

OK SIP/2.0 200 OK
To: Joao Paulo <sip:johann@uniminas.br>;tag=a53e42 From: Luiz Claudio <sip:luiz@uniminas.br>;tag=76341 Call-ID: 123456789@lab.uniminas.br Cseq: 1 INVITE Contact: <sip:joao@uniminas.br> Content-Type: application/sdp Content-Length: 155
INVITE
180 Ringing 200 OK
v=0 o=luiz 2890844528 2890844528 IN IP4 lab.uniminas.br s=Chamada Telefonica c= IN IP4 200.201.202.203 t= 0 0 m=audio 60000 RTP/AVP 0 a=rtpmap:0 PCMU/8000
- As capacidades de mdia so comunicadas no corpo da mensagem SDP.

Giuseppe M. Stephan

OK SIP/2.0 200 OK O SDP contm:
200.201.202.203 audio 60000
-> Endereo IP do ponto final -> Formato da mdia
INVITE
180 Ringing 200 OK
-> Nmero da porta
RTP
PCM -Law 8000
-> Protocolo de mdia

-> Codificao da mdia -> Taxa de amostragem(MHz )
Giuseppe M. Stephan

ACK ACK sip:joao@uniminas.br SIP/2.0
Via: SIP/2.0/UDP lab.uniminas.br:5060;branch=z9hG4bk321g;
Max-Forwards: 70 To: Joao Paulo <sip:johann@uniminas.br>;tag=a53e42 From: Luiz Claudio <sip:luiz@uniminas.br>;tag=76341 Call-ID: 123456789@lab.uniminas.br Cseq: 1 ACK Content-Length: 0
INVITE
180 Ringing 200 OK ACK
Neste ltimo passo, a confirmao que Luiz recebeu de joao, a resposta com sucesso. - A sequncia de comando tem o mesmo nmero que o INVITE mas o mtodo agora ACK - O parmetro branch contm um novo identificador de transao
Sesso de Mdia
Giuseppe M. Stephan

Sesso de Mdia O mtodo compreendendo o INVITE, 200 OK e o ACK chamado Three-Way Handshake.
INVITE
Porqu usar o Three-way ao invs do Two-way handshake?
180 Ringing 200 OK ACK
- A partir deste ponto, iniciada a sesso de mdia, normalmente com o protocolo RTP.
Sesso de Mdia
Giuseppe M. Stephan

BYE BYE sip:luiz@uniminas.br SIP/2.0
Via: SIP/2.0/UDP lab.uniminas.br:5060;branch=z9hG4bk392kf;
Max-Forwards: 70 To : Luiz Claudio <sip:luiz@uniminas.br>;tag=76341 From : Joao Paulo <sip:johann@uniminas.br>;tag=a53e42 Call-ID: 123456789@lab.uniminas.br Cseq: 1 BYE Content-Length: 0
INVITE
180 Ringing 200 OK
- O campo Via populado com o endereo do servidor de Joo e contm um novo identificador de transao - Os campos To e From refletem que a requisio originada por Joo
ACK
Sesso de Mdia BYE
- Pode-se notar que todos os branchs comeam

com z9hG4bk
Giuseppe M. Stephan

200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP lab.uniminas.br:5060;branch=z9hG4bk392kf; received=200.201.202.203
To : Luiz Claudio <sip:luiz@uniminas.br>;tag=76341 From : Joao Paulo <sip:johann@uniminas.br>;tag=a53e42 Call-ID: 123456789@lab.uniminas.br Cseq: 1 BYE Content-Length: 0
INVITE
180 Ringing 200 OK
- A resposta de confirmao para o BYE um 200 OK - Essa resposta ecoa o Cseq da requisio original: 1 BYE.
ACK
Sesso de Mdia BYE 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 no configura, nem termina sesses. Se situa no meio da troca de uma mensagem SIP, recebendo mensagens e encaminhando-as. Como o chamador no sabe exatamente onde o destinatrio da chamada est logado e qual dispositivo ele est usando, o Servidor SIP Proxy serve para rotear o INVITE.
INVITE
Giuseppe M. Stephan

INVITE (1o.) INVITE sip:joao@unicamp.br SIP/2.0
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bkmp17a Max forrwards: 70
To : Joao Paulo <sip:joao@unicamp.br>; From : Luiz Claudio <sip:luiz@uniminas.br>;tag=42 Call-ID: 10@100.101.102.103 Cseq: 1 INVITE Subject: Chamada com SIP Proxy Contact: <sip:luiz@lab1.uniminas.br> Content-Type: application/sdp Content-Length: 159
INVITE
v=0 o=luiz 2890844526 2890844526 IN IP4 100.101.102.103 s=Chamada Telefonica t=0 0 c= IN IP4 100.101.102.103 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000
O proxy procura a SIP URI do destinatrio em sua base de dados e o localiza.

Giuseppe M. Stephan

INVITE (2o.) INVITE sip:joao@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP proxy.unicamp.br:5060;branch=z9hG4bk83842.1 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bkmp17a Max forrwards: 69
To : Joao Paulo <sip:joao@unicamp.br>; From : Luiz Claudio <sip:luiz@uniminas.br>;tag=42 Call-ID: 10@100.101.102.103 Cseq: 1 INVITE Contact: <sip:luiz@lab1.uniminas.br> Content-Type: application/sdp Content-Length: 159
INVITE
INVITE
v=0 o=luiz 2890844526 2890844526 IN IP4 100.101.102.103 s=Chamada Telefonica c= IN IP4 100.101.102.103 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000
O INVIT ento encaminhado para o IP do destinatrio encontrado adicionando o segundo campo Via.
Giuseppe M. Stephan

Ringing SIP/2.0 180 Ringing
Via: SIP/2.0/UDP proxy.unicamp.br:5060;branch=z9hG4bk83842.1; received=100.101.102.105 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bkmp17a
To : Joao Paulo <sip:joao@unicamp.br>;tag=314159 From : Luiz Claudio <sip:luiz@uniminas.br>;tag=42 Call-ID: 10@100.101.102.103 Cseq: 1 INVITE Contact: <sip:joao@200.201.202.203> Content-Length: 0
INVITE
INVITE 180 Ringing
Com a presena de dois campos Via, Joao, sabe que o INVITE foi roteado atravs de um servidor proxy. Recebido o INVITE, ele envia uma resposta para o proxy por meio do 180 Ringing. Apenas o 1o. Campo Via contm o parmetro received.
Giuseppe M. Stephan

Ringing SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bkmp17a
INVITE
INVITE 180 Ringing 180 Ringing
O proxy recebe a resposta, checa que o 1o. Campo Via contm seu prprio endereo, usa o identificador de transao, remove o campo Via e encaminha a resposta para o endereo designado, neste caso, 100.101.102.103 na porta
5060.
Giuseppe M. Stephan

200 OK (1o.) SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.unicamp:5060;branch=z9hG4bk83842.1; received=100.101.102.105 Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bkmp17a
INVITE
INVITE 180 Ringing 180 Ringing 200 OK
v=0 o=joao 2890844526 2890844526 IN IP4 200.201.202.203 s=Chamada Telefonica c= IN IP4 200.201.202.203 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
A resposta deve ser roteada pelo mesmo conjunto de proxies que efetuou a requisio. A chamada aceita e Joao envia uma resposta 200 OK.
Giuseppe M. Stephan

200 OK (2o.) SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bkmp17a
To : Joao Paulo <sip:joao@unicamp.br>;tag=314159 From : Luiz Claudio <sip:luiz@uniminas.br>;tag=42 Call-ID: 10@100.101.102.103 Cseq: 1 INVITE Contact: <sip:joao@200.201.202.203> Content_Type: application/sdp Content-Length: 159
INVITE
INVITE 180 Ringing 200 OK 180 Ringing 200 OK
v=0 o=joao 2890844526 2890844526 IN IP4 200.201.202.203 c= IN IP4 200.201.202.203 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000
A resposta deve ser roteada pelo mesmo conjunto de proxies que efetuou a requisio. A chamada aceita e Joao envia 200 OK.
Giuseppe M. Stephan

ACK ACK sip:joao@200.201.202.203 SIP/2.0
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bkka42 Max Forwards: 70
To : Joao Paulo <sip:joao@unicamp.br>;tag=314159 From : Luiz Claudio <sip:luiz@uniminas.br>;tag=42 Call-ID: 10@100.101.102.103 Cseq: 1 ACK Content-Length: 0
INVITE
INVITE 180 Ringing 200 OK ACK 180 Ringing 200 OK
A presena do campo Contact com o endereo de Joao no 200 OK permite que Luiz envie um ACK diretamente para o destinatrio, bypassando o proxy.
Giuseppe M. Stephan

Sesso de mdia Na realidade, o servidor proxy no est na chamada. Ele simplesmente facilita aos dois pontos finais, localizarem e contactarem um ao outro. O servidor proxy pode derrubar o caminho de sinalizao se extrapolar um determinado tempo sem troca de mensagens. A mensagem pode ser forada a ser roteada por ele pela insero do campo, Record-Route. Pode-se notar que a sesso de mdia sempre fim-a-fim.
INVITE
INVITE 180 Ringing 200 OK ACK Sesso de mdia 180 Ringing 200 OK
Giuseppe M. Stephan

BYE BYE sip:luiz@lab1.uniminas.br SIP/2.0
Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bk4332 Max Forwards: 70
To : Luiz Claudio <sip:luiz@uniminas.br>;tag=42 From : Joao Paulo <sip:joao@unicamp.br>;tag= 314159 Call-ID: 10@100.101.102.103 Cseq: 2000 BYE Content-Length: 0
INVITE
INVITE 180 Ringing 200 OK ACK Sesso de mdia BYE 180 Ringing 200 OK
A sesso de mdia finalizada quando Joao envia uma mensagem BYE. Nota-se que Cseq foi inicializado com 2000. Isto porque cada dispositivo SIP controle sua sequncia de numerao de forma independente.
Giuseppe M. Stephan

200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bk4332
To : Luiz Claudio <sip:luiz@uniminas.br>;tag=42 From : Joao Paulo <sip:joao@unicamp.br>;tag= 314159 Call-ID: 10@100.101.102.103 Cseq: 2000 BYE Content-Length: 0
INVITE
INVITE 180 Ringing 180 Ringing 200 OK
A sesso de mdia finalizada quando Joao envia uma mensagem BYE.

Nota-se que Cseq foi inicializado com 2000. Isto porque cada dispositivo SIP controle sua sequncia de numerao de forma independente.
200 OK ACK
Sesso de mdia 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.
Maria
Dessa forma, as mensagens de entrada no sistema que sejam destinadas ao usurio podero ser encaminhadas corretamente para a localizao corrente do usurio. O processo de registro pode ser feito de modo direto como no exemplo a seguir ou, como feito geralmente, atravs de um servidor proxy. No exemplo, Ana Claudia envia uma requisio SIP REGISTER para um servidor conhecido como Servidor de Registro.
Giuseppe M. Stephan

Registro no SIP O servidor de registro: - recebe a mensagem - trata a informao contida na requisio - atualiza o banco de dados usado pelos proxies para rotear as mensagens SIP.
REGISTER sip:registrar.uniminas.br SIP/2.0 Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bkus19 Max-Forwards: 70 To: Ana Claudia<sip:ana.claudia@uniminas.br> From: Ana Claudia<sip:ana.claudia@uniminas.br>;tag=3431 Call-ID: 23@200.201.202.203 Cseq: 1 REGISTER Contact: sip:ana.claudia@200.201.202.203 Expire: 3600 Content-Length: 0
Maria REGISTER Contact: sip:maria@200.201.202.203
To: Endereo de registro, ou seja, o endereo a ser

associado ao usurio sendo registrado. From: Endereo do indivduo que iniciou o registro.
Giuseppe M. Stephan

Registro no SIP Contact: Identificao do usurio e a localizao atual do usurio para onde futuras mensagens SIP sero envidas.
Maria
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 mvel quando ele ligado. Da mesma forma que este envia sua identidade para uma BS que encaminha a localizao e o nmero do telefone para o HLR, o servidor de registro pode armazenar as informaes do usurio SIP. Este banco, tal qual o HLR, consultado para se saber informaes dos envolvidos na comunicao.
REGISTER Contact: sip:maria@200.201.202.203
Giuseppe M. Stephan

Registro no SIP O servidor de registro reconhece o pedido e promove a aceitao deste enviando uma resposta 200 OK para maria.
Maria
A resposta ecoa a informao Contact que foi armazenada no banco de dados. O Tag para o campo To includo.
REGISTER Contact: sip:maria@200.201.202.203
200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bkus19 To: Ana Claudia<sip:ana.claudia@uniminas.r>;tag=8771 From: Ana Claudia<sip:ana.claudia@uniminas.br>;tag=3431 Call-ID: 23@200.201.202.203 Cseq: 1 REGISTER Contact: sip:ana.claudia@200.201.202.203;expires=3600 Content-Length: 0
Giuseppe M. Stephan

Registro SIP atravs de Proxy O usurio do agente utiliza um esquema simples de autenticao com o servidor proxy. O registro aceito pelo servidor de registro. Fluxo da mensagem Assim que o usurio inicializa o agente, uma requisio REGISTER enviada para a servidor proxy
Maria
REGISTER
Giuseppe M. Stephan

Registro SIP atravs de Proxy
Maria
Fluxo da mensagem - O servidor proxy recebe a requisio REGISTER
REGISTER
100 Trying
- Envia a resposta 100 Trying para o usurio

- A resposta serve para informar ao usurio que a requisio foi recebida
- Dispensa a necessidade de retransmiti-la.
Giuseppe M. Stephan

Maria
Fluxo da mensagem - O esquema de autenticao simplificado
REGISTER
100 Trying REGISTER
- O servidor proxy no precisa trocar maiores

mensagens como o usurio para autentic-lo - O servidor proxy simplesmente encaminha a
requisio REGISTER para o servidor de registro
Giuseppe M. Stephan

Maria
Fluxo da mensagem - O servidor de registro envia a resposta 200 OK
REGISTER
100 Trying REGISTER
para o servidor proxy.

- A operao de registro no utiliza a mensagem ACK.
200 OK
Giuseppe M. Stephan

Maria
Fluxo da mensagem - O servidor proxy encaminha a resposta 200 OK
REGISTER
100 Trying REGISTER
para o usurio
- Esse passo notifica que o usurio est registrado no sistema.
200 OK 200 OK
Giuseppe M. Stephan
Redirecionamento no SIP
Giuseppe M. Stephan
Redirecionamento no SIP Durante o estabelecimento de comunicao entre os participantes de uma chamada SIP, normalmente necessrio determinar a localizao desses participantes. Esse processo feito como o apoio do Servidor de Redirecionamento. A solicitao do servio de redirecionamento deve ser feita com o envio da requisio INVITE para o servidor de redirecionamento. No cabealho da mensagem, o campo From indica o endereo do usurio que solicita o mapeamento. O campo To indica o endereo do usurio a ser localizado
Giuseppe M. Stephan
INVITE sip:pedro@redirect.uniminas.br SIP/2.0 Via: SIP/2.0/UDP lab.uniminas.br From: Luiz Claudio <luiz@uniminas.br> To: Pedro Henrique <pedro@uniminas.br> Call-ID: 12345678@lab.uniminas.br Cseq: 1 INVITE Subject: Redirecionamento no SIP Content-Length: 256 Content-Type: application/sdp (corpo da mensagem)
Redirecionamento no SIP Operao de localizao requer um servio que mantm mapeamentos entre uma nica URI e um conjunto de uma ou mais localizaes alternativas que permitem encontrar o elemento referenciado pela URI. Contact: Mostra a lista de uma ou mais localizaes alternativas. Resposta: Classe 3xx Quando o originador de uma requisio recebe a informao de redirecionamento, a mensagem de requisio ACK enviada para o servidor de redirecionamento.
SIP/2.0 302 Moved Temporarily Via: SIP/2.0/UDP lab.uniminas.br From: Luiz Claudio <luiz@uniminas.br> To: Pedro Henrique <pedro@uniminas.br> Call-ID: 12345678@lab.uniminas.br Cseq: 1 INVITE Contact: <sip:pedro@ufu.br> Expire: 3600 Content-Length: 0
Giuseppe M. Stephan
Redirecionamento no SIP Em seguida, uma nova requisio enviada com base na URI ou URIs recebidas, podendo ser URIs no SIP. O usurio Luiz manda uma nova mensagem INVITE para o usurio Pedro. A URI SIP fornecida pelo servidor de redirecionamento utilizada na linha de incio da mensagem.
INVITE sip:pedro@ufu.br SIP/2.0 Via: SIP/2.0/UDP lab.uniminas.br From: Luiz Claudio <luiz@uniminas.br> To: Pedro Henrique <pedro@uniminas.br> Call-ID: 12345678@lab.uniminas.br Cseq: 2 INVITE Subject: Redirecionamento no SIP Content-Length: 256 Content-Type: application/sdp (corpo da mensagem)
Giuseppe M. Stephan
Redirecionamento SIP via servidor Proxy
Giuseppe M. Stephan

Redirecionamento Quando o servio de redirecionamento utilizado no modo indireto, o servidor proxy recebe a requisio INVITE do usurio e encaminha essa requisio 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 requisio INVITE em benefcio do usurio. Pode-se ento, entender o fluxo de mensagens para efetivar a comunicao entre dois agentes devidamente registrados atravs de servidores proxy.
Giuseppe M. Stephan
A REGISTER
1 - O agente A envia uma requisio INVITE para o servidor proxy encaminhar para o usurio B.
Giuseppe M. Stephan
A REGISTER 100 Trying
2 - O servidor proxy de A recebe o INVITE, e notifica o usurio A enviando a resposta 100 Trying.
Giuseppe M. Stephan
A REGISTER 100 Trying INVITE
3 - O esquema de autenticao simplificado e servidor proxy no troca maiores
mensagens com o
agente para autenticao. Ele simplesmente encaminha o INVITE para o servidor de redirecionamento.
Giuseppe M. Stephan
A REGISTER 100 Trying INVITE 302 Moved Temp
4 - O servidor de redirecionamento envia a resposta 302 Moved Temporarily com o mapeamente
obtido a partir do
servio de localizao.
Giuseppe M. Stephan
A REGISTER 100 Trying INVITE 302 Moved Temp ACK
5 - O servidor proxy de A envia a requisio ACK para o servidor de redirecionamento a
fim de completar o 3-
handshake.
Giuseppe M. Stephan
6 - O servidor proxy de A utiliza a informao de mapeamento da resposta recebida
INVITE
para gerar um novo

INVITE a ser enviado para servidor proxy de B.
Giuseppe M. Stephan
7 - O servidor proxy de B recebe o INVITE e notifica o servidor proxy de A enviando a resposta
INVITE
100 Trying
100 Trying.
Giuseppe M. Stephan
8 - O servidor proxy de B encaminha a requisio INVITE para o servidor de redirecionamento.
INVITE
100 Trying INVITE
Giuseppe M. Stephan
A REGISTER 100 Triyng INVITE 302 Moved Temp ACK
9 - O servidor de redirecionamento envia a resposta 302 Moved Temporarily com o mapeamento
INVITE
100 Triyng INVITE 302 Moved Temp
obtido a partir do
servio de localizao.
Giuseppe M. Stephan
1 - O servidor proxy de B envia a requisio ACK para o servidor de redirecionamento a
INVITE
100 Triyng INVITE 302 Moved Temp ACK
fim de completar o 3-
handshake.
Giuseppe M. Stephan
11 - O servidor proxy de B utiliza a informao de mapeamento da resposta recebida
INVITE
100 Triyng INVITE 302 Moved Temp ACK INVITE
para gerar um novo

INVITE a ser enviado para o agente B.
Giuseppe M. Stephan
12 - O agente B recebe o INVITE e notifica o servidor proxy de B enviando a resposta 100 Trying.
INVITE
100 Triyng INVITE 302 Moved Temp ACK INVITE 100 Triyng
Giuseppe M. Stephan
Forking
Giuseppe M. Stephan

Forking Quando um agente se encontra registrado em mais de uma localizao, aps consulta ao servidor de redirecionamento, o servidor proxy recebe vrias URIs associadas ao agente, cada uma referente a uma localizao distinta. Para tentar contactar o agente, o servidor proxy recorre operao forking, em que um INVITE enviado para as diferentes localizaoes, em paralelo ou sequencialmente. No modo paralelo, o servidor proxy recebe vrias 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

Tomando a sequncia do
A INVITE INVITE B C
fluxo apresentado anteriormente. 11 - O SPb utiliza a informao de mapeamento da resposta recebida para gerar um novo INVITE a ser enviado para o usurio B. 12 - O SPb utiliza a informao de mapeamento da resposta recebida para gerar um novo INVITE a ser enviado ao agente C.
SPb (Servidor Proxy B)
SPa (Servidor Proxy A)

Giuseppe M. Stephan

13 - O agente C recebe o
A INVITE INVITE 100 Trying 100 Trying B C
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.

Giuseppe M. Stephan

15 - O agente C aceita a
A INVITE INVITE 100 Trying 100 Trying 180 Ringing 180 Ringing B C
descrio da sesso e envia a resposta 180 Ringing indicando que o agente est sendo notificado da existncia de uma chamada. Essa mensagem ser roteada atravs 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.

Giuseppe M. Stephan

17 - O SPa encaminha a
A INVITE INVITE 100 Trying 100 Trying 180 Ringing 180 Ringing 180 Ringing 180 Ringing B C
mensagem 180 Ringing do agente C para o agente A. 18 - O agente B aceita a descrio da sesso e envia a resposta 180 Ringing indicando que o usurio est sendo notificado da existncia de uma chamada. Essa mensagem ser roteada atravs do sistema at o agente A, com base nos campos header Via.

Giuseppe M. Stephan

19 - O SPb encaminha a
A INVITE INVITE 100 Trying 100 Trying 180 Ringing 180 Ringing 180 Ringing 180 Ringing 180 Ringing 180 Ringing 200 OK B C
mensagem 180 Ringing do usurio B para o SPa. 20 - O SPa encaminha a mensagem 180 Ringing do usurio B para o usurio 21 - Quando o usurio C atende chamada, a resposta 200 OK enviada para o SPb.

Giuseppe M. Stephan

22 - Assim que recebe a
A INVITE INVITE 100 Trying 100 Trying 180 Ringing 180 Ringing 180 Ringing 180 Ringing 180 Ringing 180 Ringing 200 OK 200 OK 200 OK CANCEL B C
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 usurio A. 24 - O SPa encaminha o 200 OK do agente C para o agente A.

Giuseppe M. Stephan

25 - Assim que recebe o
A INVITE INVITE 100 Trying 100 Trying 180 Ringing 180 Ringing 180 Ringing 180 Ringing 180 Ringing 180 Ringing 200 OK 200 OK 200 OK ACK ACK ACK CANCEL 200 OK B C
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. 27 - O SPa encaminha o ACK do agente A para o SPb. 28 - O SPb encaminha o ACK do agente A para o agente C.

Giuseppe M. Stephan

29 - Os dois canais de mo
A INVITE INVITE 100 Trying 100 Trying 180 Ringing 180 Ringing 180 Ringing 180 Ringing 180 Ringing 180 Ringing 200 OK 200 OK 200 OK ACK ACK ACK VOZ (RTP) CANCEL 200 OK B C
nica esatabelecidos entre os agentes, um de A para C e outro de C para A, atravs de RTP, so utilizados pelos usurios para conversao.

Giuseppe M. Stephan

30 - Para encerrar a
A INVITE INVITE 100 Trying 100 Trying 180 Ringing 180 Ringing 180 Ringing 180 Ringing 180 Ringing 180 Ringing 200 OK 200 OK 200 OK ACK ACK ACK VOZ (RTP) BYE CANCEL 200 OK B C
comunicao, o agente C envia um BYE para o SPb. 31 - O SPb encaminha o BYE do agente C para o SPa. 32 - O Spa encaminha o BYE do agente C para o agente A.
BYE
BYE

Giuseppe M. Stephan

33 - O agente A recebe a
A INVITE INVITE 100 Trying 100 Trying 180 Ringing 180 Ringing 180 Ringing 180 Ringing 180 Ringing 180 Ringing 200 OK 200 OK 200 OK ACK ACK ACK VOZ (RTP) BYE 200 OK CANCEL 200 OK B C
requisio BYE e envia a resposta 200 OK para o SPa, finalizando a chamada e fechando o canal de voz. 34 - O SPa encaminha o 200 OK do agente A para o SPb. 35 - O SPb encaminha o 200 OK do agente A para o agente C.
BYE 200 OK
BYE 200 OK

Giuseppe M. Stephan
N o modo sequencial, o servidor proxy deve encaminhar o INVITE para cada localizao, uma por vez. O encaminhamento feito para a prxima localizao apenas se a localizao corrente no atender chamada. A busca encerrada se alguma das localizaes atender chamada ou se delas nenhuma atender chamada.
Giuseppe M. Stephan
Presena e Instant
Message
Giuseppe M. Stephan

Presena Estado de um usurio ou dispositivo em um momento particular. Autenticado ou no Ativo ou inativo em sua estao Desocupado ou distante Localizao baseado em coordenadas Termos gerais como no escritrio, viajando ou no laboratrio
Smiles que retratam que est relaxando, trabalhando ou stressado.

SUBSCRIBE : requisita status ou atualizaes de presena do servidor de presena.
NOTIFY:
entrega a informao 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 informao de presena para Paulo enviando uma mensagem SUBSCRIBE.
SUBSCRIBE sip:paulo@ietf.org SIP/2.0 Via SIP/2.0/TCP lab.academia.br:5060; branch=z9hG4bk348471123 Carlos SUBSCRIBE Paulo
Max-Forwards: 70
To: Paulo Maia <sip:paulo@ietf.org> From: Carlos Lara <sip:carlos@academia.br>;tag=21171 Cseq: 3412 SUBSCRIBE Allow_events: presence Allow: ACK, INVITE, CANCEL, BYE, NOTIFY, SUBSCRIBE, MESSAGE Contact: <sip:cl@lab.academia.br;transport=tcp> Event: presence Content-Length: 0
Giuseppe M. Stephan

Presena TCP usado como transporte. Isto indicado no campo Via e no parmetro transport=tcp do campo Contact. Contm os campos Allow Allow-Events que so usados para advertir sobre as capacidades. Carlos suporta receber sete mtodos (Allow) e tambm subscrio de
presena contido em Allow-Event.

SUBSCRIBE est criando um dilogo de maneira anloga ao INVITE. O campo From contm um tag mas o campo To ainda no.
Giuseppe M. Stephan

Paulo aceita a requisio de subscrio enviando uma resposta 202 Accepted de volta a Carlos.
SIP/2.0 202 Accepted Via SIP/2.0/TCP lab.academia.br:5060; branch=z9hG4bk348471123;received=19.34.3.1 To: Paulo Maia <sip:paulo@ietf.org>;tag=25140 From: Carlos Lara <sip:carlos@academia.br>;tag=21171 Call-ID: 58dkfj349241k34452k592520 Cseq: 3412 SUBSCRIBE Allow_events: presence Allow: ACK, INVITE, CANCEL, BYE, NOTIFY, SUBSCRIBE, MESSAGE Contact: <sip:pm@sipping.ietf.org;transport=tcp> Event: presence Carlos SUBSCRIBE 202 Accepted Paulo
Expires=3600
Content-Length: 0
Giuseppe M. Stephan

A subscrio atual iniciada por Paulo enviando o primeiro NOTIFY de volta para Carlos.
NOTIFY sip: cl@lab.academia.br SIP/2. Via SIP/2.0/TCP sipping.ietf.org:5060; branch=z9hG4bk348471123;received=19.34.3.1 To: Carlos Lara <sip:carlos@academia.br>;tag=21171 From:Paulo Maia <sip:paulo@ietf.org>;tag=25140 Call-ID: 58dkfj349241k34452k592520 Cseq: 1026 NOTIFY Allow: ACK, INVITE, CANCEL, BYE, NOTIFY, SUBSCRIBE, MESSAGE Allow_events: dialog Contact: <sip:pm@sipping.ietf.org;transport=tcp> Subscription-State: active;expires=3600 Carlos SUBSCRIBE 202 Accepted NOTIFY Paulo
Event: presence
Content_Type: application/cpim-pidf+xml Content-Length: 244
Giuseppe M. Stephan

<?xml version=1.0 encoding=UTF-8?> <presence xmlns=urn:ietf:params:xml:ns:cpim-pidf entity=sip:paulo@academia.org> <tuple id=452426775> <status> Carlos SUBSCRIBE 202 Accepted NOTIFY Paulo
<basic>closed</basic>
</status> </tuple> </presence>
O NOTIFY enviado dentro de um dilogo estabelecido com o SUBSCRIBE. Ele usa o mesmo identificador de dilogo (Call-ID, local e tags remotas). A requisio enviada para o Contact fornecido por Carlos na chamada da subscrio.
Giuseppe M. Stephan

O campo Subcription-State indica que a subscrio foi autorizada e ativada e que ir expirar em 1 hora, a no ser que seja atualizada por Carlos. Commom Presence and Instant Message Presence Information Data Format (CPIM PIDF) o corpo da mensagemem XML que contm a informao de
Carlos SUBSCRIBE 202 Accepted NOTIFY Paulo
status de que Paulo est atualmente off-line

(closed).
Giuseppe M. Stephan

Carlos envia uma resposta 200 Ok para o NOTIFY para confirmar que foi recebido com sucesso.
SIP/2.0 200 OK Via SIP/2.0/TCP sipping.ietf.org:5060; branch=z9hG4bk4321;received=24.32.1.3 To: Carlos Lara <sip:carlos@academia.br>;tag=21171 From:Paulo Maia <sip:paulo@ietf.org>;tag=25140 Call-ID: 58dkfj349241k34452k592520 Cseq: 1026 NOTIFY NOTIFY 200 Ok Carlos SUBSCRIBE 202 Accepted Paulo
Content-Length: 0
Giuseppe M. Stephan

Mais tarde, quando Paulo se conecta, esta informao fornecida em um segundo NOTIFY contendo a alterao do status.
NOTIFY sip: cl@lab.academia.br SIP/2.
Via SIP/2.0/TCP sipping.ietf.org:5060; branch=z9hG4bk334241 To: Carlos Lara <sip:carlos@academia.br>;tag=21171 From:Paulo Maia <sip:paulo@ietf.org>;tag=25140 Call-ID: 58dkfj349241k34452k592520 Cseq: 1027 NOTIFY Allow: ACK, INVITE, CANCEL, BYE, NOTIFY, SUBSCRIBE, MESSAGE Allow_events: presence Contact: <sip:pm@sipping.ietf.org;transport=tcp> Subscription-State: active;expires=1800 Event: presence Content_Type: application/cpim-pidf+xml Content-Length: 325 NOTIFY 200 Ok Mais tarde... Carlos SUBSCRIBE 202 Accepted NOTIFY Paulo
Giuseppe M. Stephan

<?xml version=1.0 encoding=UTF-8?> <presence xmlns=urn:ietf:params:xml:ns:cpim-pidf entity=sip:paulo@academia.org> <tuple id=452426775> <status> Carlos SUBSCRIBE 202 Accepted NOTIFY 200 Ok Mais tarde ... NOTIFY Paulo
<basic>open</basic>
</status> <contact>sip:pm@sipping.ietf.org;transport=tcp </contact> </tuple> </presence>
O tempo de expirao indicado no campo Subscription-State indica que 30 minutos se passaram desde que a subscrio foi estabelecida.
O CPIM PIDF XML indica que Paulo est on-line

(open) e pode ser acessado via a URI sip::pm@sipping.ietf.org;transport=tcp.
Giuseppe M. Stephan

Carlos confirma o recebimento do NOTIFY com um 200 OK de resposta.
SIP/2.0 200 OK Via SIP/2.0/TCP sipping.ietf.org:5060; branch=z9hG4bk334241;received=24.32.1.3 To: Carlos Lara <sip:carlos@academia.br>;tag=21171 From:Paulo Maia <sip:paulo@ietf.org>;tag=25140 Call-ID: 58dkfj349241k34452k592520 Cseq: 1027 NOTIFY NOTIFY 200 Ok Mais tarde ... NOTIFY 200 OK Carlos SUBSCRIBE 202 Accepted Paulo
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.
MESSAGE sip:paulo@sippinf.ietf.org SIP/2.0
Via SIP/2.0/TCP lab.academia.br:5060; branch=z9hG4bk3gtr2 Max-Forwards: 70 To: Paulo Maia <sip:pm@sipping.ietf.org> From: Carlos Lara <sip:carlos@academia.br>;tag=4542 Call-ID: 9dkei93vjq1ei3 Cseq: 15 MESSAGE Allow_events: presence Allow: ACK, INVITE, CANCEL, BYE, NOTIFY, SUBSCRIBE, MESSAGE Content-Type: text/plain Content-Length: 10 Ow, ta ai? NOTIFY 200 OK MESSAGE 200 Ok Mais tarde Carlos SUBSCRIBE 202 Accepted NOTIFY Paulo
Giuseppe M. Stephan

A resposta 200 OK usada para reconhecer o recebimento do instant-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:paulo@sipping.ietf.org>;tag=2321 From:Carlos Lara <sip:carlos@academia.br>;tag=4542 Call-ID: 9dke193vjq1e13 Cseq: 15 MESSAGE NOTIFY 200 Ok Mais tarde NOTIFY 200 OK MESSAGE Carlos SUBSCRIBE 202 Accepted Paulo
Content-Length: 0
200 Ok
Giuseppe M. Stephan

Paulo responde com uma mensagem, com novo CallID e novo tag From (um instant-message nunca enviado em uma resposta 200 OK).
MESSAGE sip:carlos@academia.br SIP/2.0
Via SIP/2.0/TCP sipping.ietf.org:5060; branch=z9hG4bk4526245 Max-Forwards: 70 To: Carlos Lara <sip:carlos@academia.br> From:Paulo Maia <sip:pm@sipping.ietf.org>;tag=14083 Call-ID: 1k34452k592520 Cseq: 2321 MESSAGE Allow_events: presence Allow: ACK, INVITE, CANCEL, BYE, NOTIFY, SUBSCRIBE, MESSAGE Content-Type: text/plain Content-Length: 23 to sim, e as novidades? NOTIFY 200 OK MESSAGE 200 Ok Mais tarde Carlos SUBSCRIBE 202 Accepted NOTIFY Paulo
200 Ok
MESSAGE
Giuseppe M. Stephan

E uma nova resposta enviada.
SIP/2.0 200 OK Via SIP/2.0/TCP sipping.ietf.org:5060; branch=z9hG4bk4526245;received=24.32.1.3 To: Carlos Lara <sip:carlos@academia.br>;tag=mc3bg5q77wms From: Paulo Maia <sip:paulo@sipping.ietf.org>;tag=14083 Call-ID: 1k34452k592520 Cseq: 2321 MESSAGE
Carlos SUBSCRIBE 202 Accepted NOTIFY 200 Ok Mais tarde NOTIFY 200 OK MESSAGE
Paulo
Content-Length: 0
200 Ok
MESSAGE 200 Ok
Giuseppe M. Stephan
Caractersticas do SIP
Giuseppe M. Stephan
Descrio do protocolo 6 tipos de servios Localizao do Usurio: Localizar o terminal para estabelecer a conexo
Disponibilidade do Usurio: Estabelecer uma sesso de comunicao Recursos do Usurio: Determinar os meios a serem utilizados.
Caractersticas de Negociao: Negociar e acordar funcionalidades entre as partes Gesto da Sesso : Iniciar, terminar ou colocar em espera as sesses Modificar Sesso : Modificar uma sesso em andamento.
Giuseppe M. Stephan
Caractersticas
Protocolo tipo Cliente/Servidor (porta 5060) Escalabilidade e simplicidade (Princpio KISS Keep It Simple Stupid) Cada funcionalidade como proxying, redirection, location, ou registration pode residir em servidores fsicos distintos Mobilidade: terminais diferentes, mesma identificao Localizao do usurio atravs de um endereamento tipo e-mail
Giuseppe M. Stephan
Caractersticas
URLs para endereamento
Comunicao entre domnios admistrativos atravs de DNS

Herana do protocolo HTTP: requisies e respostas no formato texto MIME-TYPES: contedo no corpo das mensagem: fotos, vdeos, pginas web, etc. Independncia do protocolo de rede (UDP, TCP, SCTP, AAL5, X.25)
Giuseppe M. Stephan
Caractersticas O SIP utiliza um modelo cliente-servidor: UAC: user-agent client (Cliente) => Aplicao chamadora UAS: user-agent server (Servidor) => Aceita, redireciona e recusa chamadas E ainda: redirect server: Solicitaes de redirecionamento
proxy server:
registrar:
Servidor + Cliente
tracking de localizao de usurios.
Ao iniciar, o Cliente se registra de forma autenticada em um Servidor (via multicast) de modo a informar o local proxy de sua localizao. Este registro expira conforme configurao do servidor.
Giuseppe M. Stephan
Caractersticas Decises de design:
Pode ser executado sobre camadas confiveis (TCP, SCTP) ou no-confiveis (UDP)
Requisio de roteamento: direto (performance) ou por proxy (controle) Separao em sinalizao e descrio da mdia Extensibilidade: indica e requer capacidades dos proxies e UAs Requisies subsequentes e retransmisses podem tomar rotas diferentes
Giuseppe M. Stephan
Mtodos SIP
Giuseppe M. Stephan
Transaes SIP Compostas por dois tipos de mtodos: requisies iniciadas pelo CLIENTE e
respostas enviadas pelo SERVIDOR.
Define poucos mtodos, de modo a reduzir a complexidade e novos mtodos podem ser introduzidos sem necessidade de mudana no protocolo. Requisies e respostas podem conter qualquer tipo de objeto (binrio/texto). Requisies contm a descrio da sesso (mdia), enquanto as respostas contm a descrio da sesso em caso de sucesso, HTML ou texto puro em caso de falha.
Giuseppe M. Stephan
Mtodos A RFC 3261 (SIP) introduziu seis mtodos de requisio:
INVITE :
ACK:
Indica que o usurio/servio foi convidado a participar da sesso.

Funciona como a confirmao de um INVITE.
OPTIONS: Indaga as capacidades do SERVIDOR.
BYE:
CANCEL:
CLIENTE indica ao SERVIDOR que deseja encerrar a chamada.

Cancela uma requisio pendente mas ainda no completada.
REGISTER: Registra o endereo do usurio em um Servidor SIP.
Giuseppe M. Stephan
Mtodos Outras requisies introduzidas a posteriori no SIP foram:
PRACK:
Confirma o provisionamento.
SUBSCRIBE: Registra-se para uma Notificao de Evento do Notifier NOTIFY: Notifica o assinante de um novo evento.
INFO:
MESSAGE: UPDATE:
Usado para transportar informaes out-of-band (dgitos DTMF).

Utilizada para transportar mensagens instantneas usando SIP. Modifica o estado da sesso sem modificar o estado do dilogo.
REFER: Solicita ao destinatrio que envie uma requisio SIP (transferncia de chamada).
Giuseppe M. Stephan
Cdigos de Resposta Mensagem gerada por um UAS ou um servidor SIP, para responder a uma solicitao. Existem 6 tipos de classes de Cdigos de Resposta:
1xx: Informao. Recebe informao sobre o progresso do pedido. A 1a. mensagem dessa classe recebida pelo usurio, confirma o recebimento do INVITE pelo servidor e indica que o usurio deve parar de enviar solicitaes INVITE. [Searching, Ringing, Trying...] 2xx: Sucesso. Informa que o pedido foi aceito e atendido. No caso de ser uma solicitao INVITE, deve ser enviado um ACK confirmando. [Sucess] 3xx: Redirecionamento. Em geral, enviado por um servidor SIP de redirecionamento, serve para indicar que o destinatrio no est nessa localizao e informar sua nova a localizao. [Forwarding]
Giuseppe M. Stephan
Cdigos de Resposta 4xx: Erro por parte do Cliente. Informa que houve um erro na solicitao por parte do cliente, que dever refazer a solicitao de acordo com o erro indicado. [Client
Mistakes]
5xx: Erro por parte do Servidor. Informa que a mensagem no pode ser enviada com sucesso em decorrncia 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 no dever ser reenviada. [Busy, Refuse, not available anywhere]
Caso uma mensagem em particular no possa ser entendida por um UAC, ele dever
entend-la pela descrio da classe, por exemplo, um UAC recebe uma mensagem 599 (servidor desconectado) e no compreende a mensagem, ele dever interpret-la como a classe 5xx, erro do servidor.
Giuseppe M. Stephan

Cdigos de Resposta
1xx Informativo 100 180 181 182 2xx Sucesso 200 3xx - Redirecionamento 300
Pedido recebido, continuando a processar o pedido Tentando Chamando Chamada sendo retransmitida Colocado na fila A ao foi recebida, entendida e aceita com sucesso OK Uma ao adicional deve ser tomada para completar o pedido Mltiplas escolhas
Giuseppe M. Stephan
Cdigos de Resposta
Giuseppe M. Stephan
Mensagem SIP
Giuseppe M. Stephan

Mensagens SIP
Transao
Sequncia de mensagens SIP iniciada com um pedido Pode conter uma ou mais respostas temporrias (1xx) Contm uma ou mais respostas finais (no 1xx) Dilogo Sequncia de mensagens entre dois agentes usurios Iniciado em geral com um pedido INVITE e finalizado com BYE Constitudo por uma ou mais transaes sucessivas Chamada Sequncia de mensagens originadas por um INVITE de um agente usurio
Inclui um dilogo ou mltiplos dilogos no caso de chamadas em conferncia
Giuseppe M. Stephan
Mensagens SIP
Giuseppe M. Stephan
Mensagens SIP Cabealho das mensagens
Campos com informao til para o processamento da mensagem

Campos do cabealho (mais importantes) Via: From: To: Call ID: Mostra o protocolo de transporte usado e a rota requisitada.
Cada proxy adiciona uma linha a este campo

Mostra o endereo do originador da mensagem Mostra o endereo de destinatrio da mensagem Identificador nico da chamada a que corresponde a mensagem
Cseq:
Inicia com um nro aleatrio e sequencialmente identifica a msg

Endereo (s) que podem ser usados para contactar o usurio
Contact:
User-Agent:O cliente que negocia a comunicao.

Giuseppe M. Stephan
Estrutura da mensagem SIP Cabealho Via: Campo obrigatrio e grava as rotas SIP tomadas por uma requisio 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): Cabealho necessrio em toda comunicao SIP, ele identifica o transmissor de determinada requisio. Exemplo de uso: From:<sip:luiz@uniminas.br.
Giuseppe M. Stephan
Estrutura da mensagem SIP Cabealho To: Exigido em todo cabealho para indicar o destinatrio da requisio. resposta gerada pelo user agent adicionar ao cabealho um campo tag. Qualquer
Contact: Usado para manter uma URI que identifica o recursos requisitado ou o originador da requisio, dependendo se est presente na requisio ou na resposta. Uma vez recebido, o Contact pode ser cacheado e usado para roteamento de futuras requisies dentro do dilogo que permitiro bypassar o proxy. Esta ao inibida pelo Recording-Route
Giuseppe M. Stephan
Estrutura da mensagem SIP Cabealho Call-ID: cabealho indispensvel numa comunicao SIP, ele serve como identificador nico para uma mensagem, ele gerado localmente de maneira randmica, contem um @ e um endereo de IP do transmissor. Exemplo de uso: i:34d54321a6cc5676@146.164.98.78 Cseq: Cabealho obrigatrio que funciona como um contador para cada requisio feita, com exceo de ACK e CANCEL. O Cseq utilizado pelos UAS para diferenciar uma requisio nova de uma retransmisso e utilizado pelos UAC para identificar a qual requisio uma determinada resposta pertence.
Exemplo de Uso:
CSeq: 3 OPTIONS
Giuseppe M. Stephan
Arquitetura SIP
Giuseppe M. Stephan
Arquitetura SIP
Servidor de Locatizao
Servidor Redirect
Servidor Registrar
RTPC
Agente de Usurio Proxy Server Proxy Server Gateway
Giuseppe M. Stephan
SIP User Agents Aplicao que inicia, recebe e termina chamadas:
Ele pode agir tanto como:

Agente de Usurio Cliente ou CLIENTE ou UAC: => Entidade que inicia a chamda, enviando requisies e recebendo respostas Agente de Usurio de Servidor ou SERVIDOR ou UAS:
=> Entidade que recebe uma chamada, enviando respostas e recebendo requisies.
Os usurios so identificados por nomes ou por endereos de email;

O usurio chamado alcanado, no importando onde o usurio esteja ou qual endereo IP o seu host esteja utilizando no momento.
Giuseppe M. Stephan
SIP Proxy Server

Tipo de servidor intermedirio do SIP, que atua tambm como cliente e servidor,
recebendo as requisies e passando adiante para servidores mais prximos do destino
Prov um mecanismo centralizado de roteamento das mensagens SIP:

Usurios enviam pedidos de sesso a um servidor Proxy Proxy encaminha os pedidos para o Proxy do domnio de destino Proxy do domnio de destino consulta o Servidor de Registro Proxy do domnio de destino encaminha o pedido para o usurio Dois tipos de Proxy:Outbound Proxy : Envia sinalizao para outros domnios Inbound Proxy : Envia sinalizao para o mesmo domnio
Funes do Proxy:Resoluo de endereos Gerenciamento de polticas
Existem dois tipos de servidores : Stateful Proxy Server e Stateless Proxy Server Giuseppe M. Stephan
Firewalls e Call path hiding
Stateful Proxy Servers

Mantm o estado das transaes
Permite dividir a chamada (Fork) para mltiplos servidores na tentativa de localizar o usurio, 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
No armazenam o estado da transao apenas envia adiante as requisies
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 funo de informar que determinado usurio
est registrado em outro domnio
Recebe um pedido de sesso e responde com as localizaes do destinatrio O originrio recebe a informao e envia o pedido para o destinatrio No reencaminha os pedidos Alta capacidade de processamento devido ao menor nmero de msgs para
processar
Servios so dependentes do dispositivo client
Giuseppe M. Stephan
SIP Registrar Server

O servidor Registrar pode aceitar a autenticao
Realiza o registro dos agentes de usurios Servidor que armazena a localizao dos usurios: usuario@endereoIP:porta Associa identificadores humanos (luiz@uniminas.br) com endereos IPs dinmicos Fornece um servio de localizao.
Giuseppe M. Stephan
Questes
1) Quais as primitivas do protocolo SIP?

2) Quais os mecanismos de segurana 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 so os trs 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 trs primitivas do protocolo SIP so: inicializao, modificao e a finalizao das sesses. 2) Encriptao, autenticao e esteganografia. 3) A sua simplicidade, eficincia, flexibilidade e facilidade de comunicao com os protocolos da Internet HTTP e SMTP. 4) Ao enviar uma solicitao de INVITE, o receptor pode demorar muito tempo pra responder, e ao responder pode ser que o emissor no 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: =====

- URI: - Codec:
Tem a ver com: =============

URL/URN/RFC 3305 Perdas/Taxas de Bits
Responsvel: ==========
- IAD:
- ATA: - Proxy:
Caractersticas
FXO/FXS/Caractersticas Caractersticas
- RTP:
RTCP/UDP
Giuseppe M. Stephan

Aula4 Telefonia+Digital+ +VoIP+SIP

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula4 Telefonia+Digital+ +VoIP+SIP

Enviado por

Direitos autorais:

Formatos disponíveis

SIP - Session Initiation Protocol

VoIP - Voice over IP

Protocolo SIP Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

VoIP: principais protocolos de estabelecimento de sesso so:

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

1997: Lanada a verso 2.0

Vantagem em relao aos predecessores

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

Escolhido como protocolo de comunicao 3GPP.

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

Estabelecimento de uma sesso simples

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

Os dispositivos podem ser telefones SIP,

hand-helds, palmtops ou ainda celulares

assumido que ambos os dispositivos so conectados para um rede IP

Cada um sabe o endereo do outro

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

- Destino da requisio SIP.

From: Luiz Claudio <sip:luiz@uniminas.br>;tag=76341

- Originador da Requisio SIP.

- Identificador usado para manter um rastreamento de uma sesso SIP especfica.

- Exigido pelo INVITE e contm o endereo do dispositivo chamador.

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

- Referencia o corpo da mensagem.

- Indica o tamanho do corpo da mensagem em octetos conforme totalizao abaixo:

- Nro da verso - Origem 59 - Assunto

o=luiz 2890844526 2890844526 IN IP4 lab.uniminas.br s=Chamada Telefonica t= 0 0

c= IN IP4 100.101.102.103 - Conexo

m=audio 49170 RTP/AVP 0 - Mdia a=rtpmap:0 PCMU/8000

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

- Referencia o corpo da mensagem.

- Indica o tamanho do corpo da mensagem em octetos conforme totalizao abaixo:

- Nro da verso - Origem 59 - Assunto

o=luiz 2890844526 2890844526 IN IP4 lab.uniminas.br s=Chamada Telefonica t= 0 0

c= IN IP4 100.101.102.103 - Conexo

m=audio 49170 RTP/AVP 0 - Mdia a=rtpmap:0 PCMU/8000

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol

SIP - Session Initiation Protocol