Redes Multisserviços-Redes-SIP-5 PDF

Redes Multisservios
Arquitetura SIP
The Internet Multimedia
Conferencing Architecture
O IETF desenvolveu um conjunto de protocolos
especficos para servios multimdia.
Aplicaes podem combinar alguns destes
protocolos para implementar as funcionalidades
requeridas.
A figura a seguir ilustra alguns destes protocolos
operando juntos para implementar funcionalidades.
SIP parte da arquitetura Internet Multimdia
The Internet Multimedia
Conferencing Architecture
Transport of Real-Time Data: RTP
Requisitos
Mnimo atraso;
Mnimo jitter;
Entrega ordenada de pacotes;
Jitter e sequenciamento de
Datagramas
Redes IP introduzematraso em cada pacote
que a atravessa.
A quantidade de atraso depende de vrios
fatores, entre os quais o estado do roteador no
momento em que o pacote for recebido.
Se o roteador est carregado, o pacote ir
esperar na fila;
Se a fila est vazia, o pacote ser transmitido
imediatamente;
Devido ao estado do roteador variar a cada
pacote pertencendo ao mesmo fluxo de trfego,
o atraso ser varivel, surgindo o efeito de
jitter.
Sendo o jitter suficientemente grande, um
pacote pode chegar ao destino antes de
outro enviado posteriormente. Os pacotes
estaro fora de sequncia.
Para reduzir o efeito do jitter, usa-se o RTP Real-time
Transport Protocol (RTP) [RFC 1889], como protocolo
de transporte.
O RTP assinala uma estampa de tempo (timestamps)
e numerao de sequncia no header do pacoter.
A sequncia numrica do Header RTP possibilita ao
receptor reordenar o pacote de acordo com a
correlao de tempo original dos dados de payload, tais
como udio e vdeo.
Um campo denominado payload type descreve o tipo
de dado que est sendo transportado no RTP (p.ex.
udio codificado com codec PCM)
O Header RTP tambm incorpora informao sobre a
fonte que originou o payload.
Por exemplo, numa conversao por voz tem-
se
O enviador produz pacotes RTP contendo
udio codificado;
O receptor implementa um buffer para
armazenar os pacotes RTP.
Os pacotes so ordenados de acordo com o
nmero de sequncia.
Um pacote RTP removido do buffer
quando seu timestamp indica que o
momento de ser executado (play).
O buffer deve ser de tamanho suficiente
para que os pacotes tenham tempo de
chegar
Alm disto, buffers devem ser o menor
possvel para que o atraso advindo no torne
a conversao impossvel.
Se o pacote no chega no tempo requerido, um
algoritmo de preenchimento deve ser usado por
meio de tcnicas de interpolao.
RTP pode ser usado para estabelecer o timing
de diversos media streams;
Por exemplo, em uma vdeo conferncia pode
ser usado para sincronizar udio e vdeo.
Para dar suporte a sincronizao de mdias, utilizado
o RTCP Real-time Transport Control Protocol [RFC
1889].
Sua funo associar timestamps e relgio de tempo
real. Cada sesso RTP tem associada uma sesso
RTCP.
Alm da sincronizao de mdia, RTCP prov
informaes sobre os membros da sesso e da
qualidade da comunicao.
RTCP informa quantos pacotes foram descartados
durante a sesso de forma que o enviador saiba da
qualidade de recepo que o receptor est percebendo
Session Announcement Protocol
(SAP)
Quando algum decide assistir TV, um
procedimento possvel seria verificar o guia de
programao para saber quais canais esto
transmitindo contedo de seu interesse;
Uma vez selecionado o contedo de
broadcast de interesse, a pessoa ento
sintoniza o canal de interesse na TV;
A Internet utiliza um procedimento similar;
(SAP)
Seleciona-se a sesso multicast de maior
interesse entre aqueles disponveis no
momento;
necessrio configurar ferramentas
multimdia para receber a sesso escolhida;
importante conhecer, por exemplo, se a
sesso consiste apenas de udio ou de h
tambm vdeo.
(SAP)
Session Announcement Protocol (SAP) [RFC
2974] foi estabelecido para distribuir
informaes sobre sesses multicast entre
potenciais receptores.
SAP efetua a tarefa de descrever sesses
multicast em um endereo e porta conhecidos
(veja figura a seguir).
Devido tecnologia multicast no ser
confivel, anncios SAP tambm tornam-se
no confiveis e devem ser retransmitidos,
periodicamente.
(SAP)
A taxa de retransmisso pode ser
configurada para cada sesso.
Quanto mais sesses esto presentes,
maior ser o intervalo de retransmisso.
SAP pode ser criptografado e pode usar
mecanismos de autenticao.
Isto prov certo nvel de privacidade e
verifica a identidade do criador de uma
sesso particular.
(SAP)
(SAP)
SAP no define um formato para a descrio de
sesses multicast para potenciais receptores.
Vrios formatos podem ser usados, e no h um
mecanismo para negociar o formato a ser utilizado.
possvel que um receptor no entenda a descrio
de uma sesso devido a isto.
O IETF recomenda o uso do formato SDP - Session
Description Protocol [RFC 2327].)
SDP serve como um protocolo comum para
descrever sesses e todas as aplicaes devem
suport-lo.
Session Description Protocol
(SDP)
Session Description Protocol [RFC 2327] especifica
como informaes necessrias para descrever uma
sesso devem ser codificadas;
SDP no inclui qualquer mecanismo de transporte ou
qualquer mecanismo de negociao de parmetros;
SDP descreve um conjunto de informaes para que
o sistema possa integrar-se a um sesso multimdia;
Inclui, por exemplo, endereo IP, porta, horrios e
datas nas quais o sesso ser ativada.
(SDP)
SDP Syntax
SDP baseado em texto e no em
formato binrio.
Um descrio de sesso por SDP consiste
em um conjunto de linhas, tais como:
Type = value
(SDP)
SDP contm informaes sobre a sesso e
sobre a mdia;
As informaes de sesso aplicam-se a sesso
como um todo (nome do originador da sesso,
por exemplo);
As informaes sobre mdia aplicam-se somente
a um media stream particular (o codec usado,
por exemplo, para codificar udio ou a porta
onde o video stream est disponibilizado).
(SDP)
Comea com informaes sobre sesso e
seguem-se informaes sobre mdia.
Se houver Informaes de sesso, estas
comeam com V=0, onde v o type e 0 o
value:
(SDP version 0).
A seo de descrio de mdia comea com
uma linha m e inclui as prximas at uma nova
linha m ou at o fim da descrio da sesso.
(SDP)
SDP session description:
v=0
o=Bob 2890844526 2890842807 IN IP4 131.160.1.112
s=SIP seminar
i=A Seminar on the Session Initiation Protocol
u=http://www.cs.columbia.edu/sip
e=bob@university.edu
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696 // segundo desde 1900-01-01
a=recvonly
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
(SDP)
Neste exemplo, a descrio da sesso consiste
das primeiras 9 linhas, de v=0 at a=recvonly, e
possui trs sesses de mdia: uma de audio
stream e duas de video streams.
A linha o indica o criador da sesso ( neste
caso, Bob) e o endereo IP do seu site.
A linha s contm o nome da sesso;
A linha i contm informaes gerais sobre a
sesso.
(SDP)
A linha u fornece um Uniform Resource Locator
(URL) onde mais informaes sobre o tpico da
sesso podem ser obtidas;
A linha e contm o endereo de e-mail da
pessoa de contato para esta sesso;
A linha c descreve o endereo de multicast onde
a sesso pode ser recebida;
A linha t indica quando a sesso estar ativa.
A ltima linha do nvel de sesso, linha a, indica
que esta no uma sesso interativa.
(SDP)
A linha a seguir, linha m, comea com o media type;
Neste caso, media type pode ser de dois tipo, udio
para o primeiro media stream e vdeo para os dois
outros.
m=<media type> <port number> <transport
protocol> <media formats>
O port number indica onde a mdia pode ser recebida;
O transport protocol field , normalmente vem com o
valor RTP/AVP, mas pode ter outros valores RTP/AVP
refere-se ao perfil audio/video para RTP;
Neste exemplo, udio e vdeo codificados so
transportados usando RTP sobre UDP;
(SDP)
O media formats depende do tipo de mdia
transportado. Para udio, refere-se ao tipo do CODEC
utilizado. Neste exemplo, o valor zero corresponde a
udio codificado em um canal nico, usando PCM lei
e amostrado a 8kHz.
A linha a=rtpmap cobre informaes sobre o formato de
mdia utilizado, tais como taxa de clock ou nmero de
canais;
No segundo media stream, o media format number 31
refere-se ao H.261 e usa clock de 90 KHz.
(SDP)
Extending SDP
As linhas de atributo de mdia, linhas a, fornecem um mecanismo
para estender o protocolo SDP, quando uma aplicao requer
funcionalidades que no existem no SDP.
Por exemplo, se o criador da sesso deseja que os receptores
executem o udio em um certo volume, ele pode definir um novo
atributo de mdia:
a=volume:8
Aplicaes que entendam esta nova linha, executaro o udio no
volume 8.
(SDP)
(SDP)
(SDP)
SDP Next Generation (SDPng)
Originalmente, SDP foi desenvolvido para
descrever sesses multimdia no Mbone
(Poro da Internet que d suporte a multicast).
Mas encontrou usos em muitos outros
contextos:
Real-Time Streaming Protocol (RTSP) [RFC 2326]
para servios de streaming;
SIP para convites em conferencias;
Dispositivos com configurao mestre/escravo
usando Media Gateway Control Protocol (MGCP)
[RFC 2705] ou H.248.
(SDP)
Devido ao fato que SDP no ter sido
desenhado para operar em todos estes
ambientes, existem diversas lacunas de
implementao.
Em aplicaes futuras que envolvam
mecanismos de descrio de sesses
tambm haver novos requisitos.
(SDP)
O sucessor do SDP est em
desenvolvimento, chamado de SDP next
generation (SDPng) e sendo desenvolvido
pelo grupo de trabalho do IETF - Multiparty
Multimedia Session Control (MMUSIC).
SDPng ir enriquecer as descries e
possibilitar um mecanismo melhor de
negociao do que o SDP.
Real-Time Streaming Protocol
(RTSP)
Real-Time Streaming Protocol (RTSP) [RFC
2326] usado para controle de servidores
multimdia, tipicamente em aplicaes de
streaming.
Seu uso pode ser comparado ao de um
controle remoto de um DVD player;
O usurio poder dizer ao servidor, por
exemplo, para iniciar um certo stream de
udio/vdeo usando o boto play;
Tambm poder pausar, avanar, retroceder,
gravar, etc...
Cenrio de uso do conjunto de
protocolos vistos
protocolos vistos
Uso de protocolos em conjunto para
implementar um servio Internet
multimdia destinado a distribuir um
filme por multicast.
protocolos vistos
O usurio que controla o multcast elabora um descrio
de sesso usando SDP, indicando quando o filme ser
enviado por multcast, sobre o que o filme trata e
parmetros necessrios para receber a mdia;
Estes parmetros incluiro, pelo menos, endereo de
multcast, nmero da porta e formato da mdia;
SDP com a descrio da sesso ser distribudo via
SAP para os potenciais interessados, usando
roteamento de multicast;
protocolos vistos
Usurios interessado examinaro SDP e
configuraro suas ferramentas de mdia
adequadamente de forma que possam assistir
ao filme no tempo designado;
Quando o filme programado, o controlador de
sesso usa RSTP para alertar o servidor
multimdia, onde o filme est armazenado, para
iniciar o multicast usando o SDP previamente
distribudo.
protocolos vistos
O servidor de mdia enviar pacotes multicast RTP
contendo udio e vdeo do filme;
RTCP ser usado para coletar e armazenar
estatsticas sobre a recepo e qualidade
experimentada pelos receptores.
RSVP deve ser usado para obter certo grau de
QoS entre o servidor de mdia e os usurios.
SIP- Session Initiation Protocol
A arquitetura proposta pelo Internet
multimedia conferencing possui uma
lacuna importante:
No h uma forma explcita de convidar
um usurio a se juntar a uma sesso em
particular.
Uma sesso multicast pode ser anunciada
via SAP, por exemplo, mas caber aos
potenciais receptores verificar os anncios
de sesses periodicamente para decidir
juntar-se, ou no, sesso.
No possvel a um usurio avisar outro
usurio sobre a sesso e convid-lo para
participar.
Originalmente SIP foi concebido para convidar
usurios a se juntarem a uma sesso multcast
no Mbone.
O protocolo evoluiu e inclui seu uso para convidar
usurios para diversos tipos de sesso multcast
ou ponto-a-ponto.
SIP - Session Initiation Protocol
SIP estabelece, modifica e termina
sesses multimdia.
Pode ser usado para convidar novos
membros para uma sesso existente ou
criar novas sesses.
SIP independente do tipo de sesso
multimdia e do mecansimo usado para
descrever a sesso.
usual para videoconferencias,
chamadas de udio, ou sesses de jogos.
Sesses consistindo de streams RTP
transportam udio e vdeo, sendo
descritas por SDP.
Outros tipos de sesses podem ser
descritas por outros tipos de descritores
(p.ex, sesso de jogo de xadrez descrito
por um protocolo especfico).
SIP usado para distribuir descries de
sesses entre participantes potenciais.
SIP pode ser usado para negociar e
modificar parmetros de sesses e
terminar sesses.
Exemplo:
Bob deseja ter uma sesso de udio-vdeo
com Laura e planeja usar codec PCM
para codificar voz.
A distribuio de sesso consiste de Bob
enviando a Laura uma descrio de
sesso com codec PCM para a
componente de voz.
Laura prefere usar codec GSM (Global
System for Mobile Communications)
porque consome menos banda.
Ela convence Bob a fazer o mesmo.
Ambos estabelecem a configurao usando
codec GSM para voz.
A sesso no estabelecida antes de
concluir esta negociao.
SIP URL
Usurios SIP so identificados por meio do SIP
Uniform Resource Locators (URLs).
O formato similar ao de um endereo de e-
mail, geralmente consiste de um nome de
usurio (username) e um nome de domnio
(domain name)
SIP:Bob.Johnson@company.com.
O usurio efetua seu registro em um servidor
SIP o qual direciona os SDPs para o usurio.
Mobilidade (User Mobility)
O usurio pode ter mais de uma localidade
onde pode ser encontrado (escola, trabalho,
casa, site da empresa em outra cidade, etc)
Ele poder ser encontrado em diferentes
endereos IP dependendo de que computador
esteja usando e no qual deseje ser encontrado
para receber convites para sesses.
Registro (Registration)
Os usurios registram sua localizao corrente em
um servidor se ele desejar ser encontrado.
No exemplo, Bob est trabalhando em um computador
cujo endereo IP 131.160.1.112.
Seu login name Bob.
Ele registra sua localizao corrente no servidor da
companhia (vide figura).
Laura deseja chamar Bob.
Ela conhece seu endereo SIP publico
(SIP:Bob.Johnson@company.com).
Quando o servidor na companhia contatado e
pergunta por Bob.Johnson, ele sabe onde Bob.Johnson
pode ser encontrado e a conexo a ser feita.
Nesta situao, SIP prov dois modos de operao:
redirect e proxy.
No modo proxy, o servidor contacta
Bob no endereo IP 131.160.1.112 e
entrega a descrio de sesso de
Laura.
No modo redirect, o servidor diz a Laura
para tentar o endereo
SIP:Bob@131.160.1.112.
Um usurio pode registrar vrias
localizaes em um servidor;
ou pode resgistrar sua localizao em
vrios servidores.
No pouco usual vrios servidores
serem contactados antes de que o
usurio seja encontrado.
SIP Proxy Server
SIP Redirect Server
SIP- Elementos da Arquitetura
O protocolo SIP define algumas entidades
que cumprem um papel especfico na
arquitetura de sistemas SIP.
User Agents
Media Tools
Redirect Servers
Proxy Servers
Registrars
User Agents
User Agent (UA) uma entidade SIP que interage com
usurio.
Possui uma interface direta com o usurio.
Usurios interagem com UA atravs de uma
interface frequentemente uma janela com botes de
seleo.
Quando Bob clica o boto para chamar Laura, o UA
trigga a mensagem SIP apropriada para estabelecer
uma chamada
Laura tambm possui um UA SIP em seu computador.
Quando o UA de Laura recebe
um convite de Bob, ele alerta
Laura mostrando uma janela de
pop-up com dois botes:
Accept call e Reject call .
Dependendo de qual boto Laura
clicar, seu UA envia uma
mensagem SIP diferente para o
UA de Bob.
Todas as interaes entre
usurios e o protocolo SIP so
mediados pelo UA.
SIP- Entidades SIP
Nem todos os sistemas usando SIP esto diretamente
conectados a usurios.
Por exemplo, Bob pode redirecionar todos os convites
para sesses recebidas de meia noite s 7 da manh
para uma mquina de resposta automtica.
A mquina automaticamente ir estabelecer sesses
para gravar mensagens.
Ela tambm possui um UA que no necessariamente
mantm interao com o usurio, mas pode
responder convites em seu lugar.
SIP- Entidades SIP
Media Tools
SIP entrega um descrio de sesso para o SIP UA.
Se a sesso descreve uma sesso de voz, o UA dever entreg-
la para uma ferramenta de voz que ir tratar o udio.
Para outros tipos de sesses, o UA ir encaminhar a sesses
para uma ferramenta de mdia apropriada.
Uma sesso de uido e vdeo no pode ser estabelecida sem
uma ferramenta de udio e uma ferramenta de vdeo.
SIP- Entidades SIP
Se estes elementos so combinados sob a mesma interface de
usurio, elas aparecero como uma simples aplicao:
videoconferencia.
A separao entre o UA tratando a entrega da sesso e as
ferramentas de mdia tratando o contedo da mdia possibilita
que SIP estabelea qualquer tipo de sesso.
SIP UA pode ser executado em um computador ou em
dispositivos especficos ( telefone SIP, PABX-IP, p. ex.)
SIP- Entidades SIP
Redirect Servers
Redirect servers auxiliam na localizao
de SIP UAs provendo locais alternativos
onde o usurio pode ser encontrado.
Para cada local associado um
endereo diferente.
SIP- Entidades SIP
Redirect Servers
Se for feita uma tentativa de buscar um usurio
no seu endereo pblico (preferencial) e ele
no estiver logado naquele servidor, o SIP
redirect server ir tratar as solicitaes que
chegam para o usurio, redirecionando para o
endereo onde o usurio pode ser localizado.
SIP- Entidades SIP
Redirect Servers
No exemplo o UA de Laura tenta localizar
Bob;
O redirect server sabe que Bob pode ser
localizado no endereo
SIP:Bob@131.160.1.112 (escritrio) ou
em Bob@university.com (universidade).
SIP- Entidades SIP
O redirect server ir indicar para o UA
de Laura que tente encontar Bob nestes
endereos ao invs do endereo da
empresa.
O redirect server tambm pode priorizar
um endereo, dizendo ser mais provvel
encontr-lo, por exemplo, na
universidade.
SIP- Entidades SIP
O UA de Laura ento tentar os dois
endereos, priorizando o da
universidade como foi recomendado.
O redirect server no retorna o
endereo onde o usurio efetivamente
est. Ele apenas informa o endereo do
servidor que pode saber onde Bob est.
SIP- Entidades SIP
O redirect server no efetua qualquer
ao para localizar o usurio, apenas
retorna uma lista de possveis locais
onde ele possa ser encontrado.
O UA faz todas as tentativas de localizar
o usurio.
SIP- Entidades SIP
Esta a diferena principal entre
redirect server e proxy server.
Proxy servers faz sucessivas tentativas
de encontrar o usurio ao invs de
enviar informaes de contato deste.
SIP- Entidades SIP
Proxy Servers
Proxy servers efetuam as tentativas de
localizar um usurio convidado a
participar de uma sesso;
Diferentemente do redirect server, proxy
server no envia para o solicitante
opes de localidades nas quais o
usurio pode ser encontrado
SIP- Entidades SIP
Proxy Servers
Ao invs disto, ele prprio envia
mensagens a possveis servidores os
quais potencialmente conheam o
paradeiro do usurio solicitado.
SIP- Entidades SIP
Como exemplo, suponha que haja um proxy
server no domnio company.com capaz de
tratar convites que sejam direcionado a usurios
do domnio.
Quando o UA de Laura tenta contactar
SIP:Bob.Johnson@company.com, a
mensagem chegar ao proxy server do
domnio company.com, que buscar
SIP:Bob@university.com em nome do UA de
Lauras.
SIP- Entidades SIP
Se o domnio university.com tambm possuir
um proxy server, ele tentar o endereo
SIP:Bob@workstation1234.university.com
onde Bob est.
Neste cenrio, o UA de Laura tentar somente
um local, mas vrios proxies esto no
caminho entre os UAs. Veja figura.
SIP- Entidades SIP
SIP- Entidades SIP
Forking Proxies
Quando um proxy server tenta mais de uma
localidade, dito haver uma ramificao de convites.
Forking proxies pode executar buscas sequenciais ou
paralelas, dependendo da configurao.
Uma busca paralela consiste de tentar-se todas os
locais possveis ao mesmo tempo;
Uma busca sequencial consiste de tentar cada local a
cada vez
SIP- Entidades SIP
SIP- Entidades SIP
O termo SIP server refere-se de forma
geral aos dois tipos de servidores
(redirect e proxy)
O mesmo servidor pode operar de
forma diferente, dependendo da
situao.
SIP- Entidades SIP
Registrars
Registrar refere-se ao servidor SIP que
recebe registros de usurios;
Registrar usualmente colocado no
mesmo local do servidor SIP
SIP- Entidades SIP
SIP- Entidades SIP
Location Servers
Location servers no so entidades SIP, mas
desempenham um importante papel na arquitetura do
sistema.
Um location server armazena e retorna possveis
locais em que o usurio pode ser encontrado.
Pode usar informaes dos registrars ou de outra
base de dados.
Em geral, os registrars enviam a localizao dos
usurios para os location server quando as recebem.
Veja figura.
SIP- Entidades SIP
SIP- Entidades SIP
O proxy server em company.com
consulta o location server para o SIP
URL onde Bob deve ser encontrado.
O location server fornece esta
informao ao proxy server porque o
registrar enviou esta informao
previamente.
SIP- Entidades SIP
SIP- Entidades SIP
No entanto, SIP no usado entre os
location servers e os SIP servers.
Alguns location servers usam
Lightweight Directory Access Protocol
(LDAP) [RFC1777] para comunicar com
SIP servers.
SIP- Caractersticas
IETF projetou SIP com base no
paradigma da Internet.
Usa mecanismos da Internet para prover
suas funcionalidades
Isto prov grande flexibilidade porque
SIP pode ser usado com outros
protocolos Internet e pode ser feito de
forma modularizada
SIP- Caractersticas
Por exemplo, se um novo mecanismo de
autenticao for implementado pelo
IETF, SIP poder incorpor-lo sem
modificaes;
SIP estar habilitado a usar novos
mecanismos de QoS;
SIP dito ser a prova de futuro.
Client/Server Transactions
SIP baseado em HTTP e como este, SIP
baseado em um protocolo do tipo
request/response;
Um client uma entidade SIP que gera
requisies (requests);
Um server uma entidade SIP que recebe
requisies e retorna respostas (responses);
Client/Server Transactions
Quando dois agentes Sip trocam mensagens, o
User Agent (UA) que envia mesnsagens um
User Agent Client (UAC);
O UA retornando respostas o User Agent
Server (UAS);
Uma requisio SIP com a resposta associada
denominada transao SIP (SIP transaction);
SIP Responses/Request
SIP Responses
Ao receber uma requisio o servidor
deternima uma de vrias respostas possveis;
Cada resposta possui um cdigo que indica o
status da transao;
Cdigos de status so nmeros inteiros na
faixa de 100 a 699 e so agrupados em classes
como mostra a tabela seguinte,
Respostas com status de 100 a 199 so
consideradas provisionais.
Respostas de 200 a 699 so respostas
finais.
Uma transao SIP entre um client e
um server compreende um solictao do
client, uma ou mais respostas
provisionais e uma resposta final.
Junto com o cdigo de status, a
resposta SIP transporta uma frase
Esta frase contm uma informao que
pode ser entendida por um humano,
enquanto o cdigo ser tratado por um
dispositivo computacional.
Por exemplo, o cdigo 180 significa que o usurio
convidado para uma sesso est sendo avisado do
convite.
A frase associada contm a expresso Ringing ;
A frase pode ser escrita em uma outra lingua alm do
ingls;
O dispositivo SIP que processa a mensagem ir
ignorar a frase e tratar apenas o cdigo;
O dispositivo poder exibir a frase para um operador
humano que achar mais fcil enteder a mensagem;
SIP Requests
So definidos seis tipos de solicitaes
na especificao (core) SIP, cada uma
com um diferente propsito.
Cada SIP request contm um campo
denominado mtodo, que denota seu
propsito.
INVITE
ACK
OPTIONS
BYE
CANCEL
REGISTER
Tanto as requisies quanto as
respostas podem conter um corpo de
mensagem (SIP bodies).
O corpo da mensagem o seu payload.
SIP bodies usualmente consistem de uma
descrio de sesso.
INVITE
INVITE solicita um usurio a participar de uma
sesso.
O corpo de um INVITE contm uma descrio da
sesso.
Por exemplo, quando Bob chama Laura, seu UA envia
um INVITE com uma descrio de sesso para o UA
de Laura.
Suponha que o UA de Bob use SDP para descrever a
sesso.
O UA de Laura receber um INVITE com a seguinte
descrio:
v=0
o=Bob 2890844526 2890842807 IN IP4
131.160.1.112
s=I want to know how you are doing
c=IN IP4 131.160.1.112
t=0 0
O INVITE recebido por Laura significa que
Bob est convidando Laura para juntar-se
a uma seso de udio.
O UA de Laura saber, pelo INVITE
recebido, que o UA de Bob deseja usar
pacotes RTP para transportar o sinal de
voz de Laura e que usar o IP
131.160.1.112, sendo baseado em UDP,
na porta 49170.
O UA de Laura tambm ser informado que a
codificao dever ser em PCM leu u (RTP/AVP 0 na
linha m indica PCM.)
O UA de Lauras sinalizar para Laura sobre a chamada
de entrada e retornar a resposta 180 Ringing para o
UA de Bob.
Quando Laura aceitar a chamada, seu UA enviar a
resposta 200 OK com a descrio da sesso no copo
da mensagem.
v=0
o=Laura 2891234526 2812342807 IN IP4
138.85.27.10
c=IN IP4 138.85.27.10
t=0 0
Neste ponto, Laura aceita a chamada e informa
a Bob que receber pacotes RTP em
138.85.27.10, UDP, porta 20000.
Se Laura ou Bob desejarem modificar a sesso,
eles devem enviar um novo INVITE.
Este tipo de INVITE chamado de re-INVITE, e
utilizado para atualizar a descrio da sesso.
Pode consistir de novos parmetros como
nmero de porta ou adicionar um novo media
streams.
Por exemplo, pode ser adicionado um video
stream na conversao de voz via um re-
INVITE.
SIP somente trata o convite aos usurios.
A descrio da sesso feita pelo protocolo de
descrio de sesso (SDP neste caso).
ACK
ACK so usados para confirmar a recepo de
uma resposta final para um INVITE.
Um client originando um INVITE request,
envia um ACK request quando recebe uma
resposta final para o INVITE, provendo um
Three-Way Handshake:
INVITE-final response-ACK
INVITE o nico mtodo que usa three-
way handshake porque um mtodo
especial no estabelecimento da sesso,
diferente dos demais mtodos onde a
ao mais simples e que demandam
uma resposta imediata, requerendo
apenas um Two-Way-HandShake;
Three-way handshake possibilita a
implementao do forking proxies.
Quando ocorre uma ramificao de
requisio, o cliente que enviou o request
obter vrias respostas de diferentes
servidores.
Enviar um ACK para cada destino que
respondeu essencial para assegurar a
operao do SIP sobre protocolos no
confiveis como o UDP.
CANCEL
CANCEL requests cancelam transaes
pendentes.
Se um SIP server recebeu um INVITE mas no
retornou uma resposta final, um CANCEL ir
parar o processamento do INVITE .
Se o resposta final j foi enviada para o
INVITE , um CANCEL request no ter efeito
sobre a transao.
Na Figura, Bob envia uma chamada para Laura e seu SIP phone
comea a tocar (ringing), mas ningum atende.
Bob decide desconectar-se e envia um CANCEL request para o
INVITE anteriormente enviado.
Ao receber o CANCEL, o SIP phone de Laura para o sinal de ring e
envia uma resposta 200 OK associada ao CANCEL, indicando que o
CANCEL foi processado.
O servidor no SIP phone responde ao INVITE tambm.
Ele envia um 487 Transaction Cancelled e o client (de Bob) finaliza o
INVITE three-way handshake enviando um ACK (INVITE-487 Transaction
Cancelled-ACK).
CANCEL requests so usados tambm quando o
servidor envia INVITES devido ao fork proxies pois
mais de um INVITE enviado para locais onde o
usurio possa estar.
Na figura, Bob pode ser encontrado em
SIP:Bob@131.160.1.112,
SIP:Bob.Johnson@company.com e
SIP:Bob@university.com.
Quando o servidor proxy recebe um INVITE de Laura
para Bob, ele tentar estes trs locais em paralelo (ao
mesmo tempo).
A ramificao proxy (forking proxy) envia trs INVITEs,
um para cada local.
Bob est no momento trabalhando em 131.160.1.112,
este servidor responde a chamada.
O servidor proxy recebe um 200 OK de
SIP:Bob@131.160.1.112 e encaminha esta resposta
para o UA de Laura.
Uma vez estabelecida a sesso entre Laura e Bob, o
servidor proxy precisa parar as outras transaes
iniciadas e envia dois CANCELs, um para cada local
restante.
BYE
BYE requests so usados para abandonar uma
sesso.
Em uma sesso com dois participantes, o abandono
de uma parte implica em terminar a sesso.
Por exemplo, quando Bob envia um BYE para Laura, a
sesso automaticamente terminada.
Em um cenrio multicast, um BYE de um dos
participantes apenas significa que ele deixar a
sesso.
A sesso em si no afetada.
REGISTER
Usurios enviam REGISTER requests para
informar um servidor (registrar) sobre sua
localizao corrente.
Bob pode enviar um REGISTER para o
servidor registrar em company.com
determinando que todas as requisies de
entrada para
SIP:Bob.Johnson@company.com devem ser
direcionadas (proxie) ou redirecionadas
(redirec) para SIP:Bob@131.160.1.112
SIP servers normalmente esto no mesmo
local que o servidor SIP registrars.
O SIP registrar pode enviar todas as
informaes recebidas de vrios
REGISTER requests para um nico
location server, possibilitando qualquer
SIP server tentar localizar um usurio.
OPTIONS
OPTIONS requests interrogam um servidor sobre
suas capacidades, incluindo quais mtodos e que
protocolos descritores de sesso ele suporta
Um SIP server poderia responder a um OPTIONS
request que ele suporta SDP como descritor de sesso
e cinco mtodos: INVITE,
ACK,CANCEL,BYE e OPTIONS.
Devido ao servidor no suportar o mtodo REGISTER
, pode-se deduzir que ele no do tipo registrar.
OPTIONS
O mtodo OPTIONS pode no parecer usual em um primeiro
momento, mas com novas verses de SIP com novos mtodos
implementadas, pode ser muito til saber sobre as capacidades
de um servidor em um cenrio de interoperanilidade.
O mtodo OPTIONS pode tambm retornar dados que
especifiquem que tipo de codificao para corpo de mensagens o
servidor capaz de entender.
Um servidor pode, por exemplo, entender certo tipo de compresso.
O cliente estar habilitado a enviar descrio de sesso com
compresso, economizando alguma banda.
Tipos de Proxy Servers
Proxy servers podem ser classificados de
acordo com a quantidade de informaes
de estado que eles armazenam durante
um sesso.
SIP define trs tipos de proxy servers:
Call stateful;
Stateful;
Stateless.
Call Stateful Proxy
Call stateful proxies necessitam ser
informados de todas as transaes SIP que
ocorrem durante a sesso e assim esto
sempre no caminho das mensagens SIP
trafegando entre os usurios.
Estes servidores proxies armazenam
informaes do momento em que a sesso
foi estabelecida at o momento que ela
termina.
Call Stateful Proxy
Um exemplo deste tipo de servidor seria um que
implementa um servio relativo chamda,
onde um e-mail gerado contendo
informao sobre a durao da chamada.
Para determinar a durao da chamada ele
deve permanecer no caminho entre o envio do
INVITE que iniciou a chamada at o BYE que
finaliza a chamada.
Stateful Proxy
Stateful proxies so muitas vezes chamados de stateful
proxies de transao porque armazenam informaes
acerca de transaes;
Um stateful proxy armazena estados relativos a uma
dada transao at que ela seja concluda;
Ele no permanece no caminho dos usurios para
obter as mensagens SIP para transaes
subsequentes.
Stateful Proxy
Forking proxies so bons exemplos de stateful proxies.
Eles enviam INVITEs para vrios locais e devem
armazenar estados sobre a transao INVITE a fim de
saber quando todos os locais tentados retornaram
uma resposta final ou no.
No entanto, uma vez que o usurio foi localizado, o
proxy no necessita permanecer mais no caminho
da sinalizao.
ACKs so gerados como resposta final para um INVITE.
Tambm so gerados por servidores proxies e por UAC.
Proxy servers podem gerar ACK somente para respostas finais
mal sucedidas, que tem status maior do que 299.
Respostas bem sucedidas (status entre 200 e 299) so sempre
gerados ACKs pelo UA que iniciou o INVITE.
A figura anterior mostra proxy server enviando ACKs para respostas
de operaes mal sucedidas nas mensagens (4) e (7).
Entretanto, o UA envia ACKs para mensagem 200 OK (11).
Stateless Proxy
Stateless proxies no mantm qualquer
informao sobre estado.
Eles recebem um request, encaminham-no
para o prximo hop e imediatamente deletam
todos os estados relativos aos request.
Quando um stateless proxy recebe uma
resposta, ele determina a rota baseado somente
em informaes do header Via.
Anlise de trfego IP na rede, sempre mostra que
roteadores de ncleo so sobrecarregados com
trfego em comparao com roteadores de borda.
Isto tambm verdadeiro para trfego SIP.
SIP servers de ncleo devem tratar muitas
mensagens ao contrrio dos servidores na periferia da
rede.
SIP desenhado com servidores stateless no core de
rede.
SIP Request Format
SIP Request consiste de uma linha de
requisio, diversos headers, um linha
vazia e um corpo de mesagem.
O corpo de mensagem opcional,
algumas requisies no o usam.
Request Line
Uma Request Line composta por trs
elementos: mtodo, Request-URI e verso de
protocolo.
O mtodo indica o tipo de requisio;
Request-URI indica o prximo hop, que para
onde a requisio deve ser roteada.
Na figura, o SIP proxy localizado em
company.com recebe um INVITE com o
Request-URI =>
Este proxy sabe que Bob pode ser
encontrado em dois locais, ento gera
dois INVITEs.
Um deles conter
SIP:Bob@university.com como Request-
URI e ser enviado para o servidor em
university.com.
O segundo INVITE ter
SIP:Bob@131.160.1.112 e ser enviado
para 131.160.1.112.
Request-URI contm o endereo do
prximo hop no caminho.
A verso de protocolo SIP/2.0.
O Invite recebido em company.com seria:
INVITE sip:Bob.Johnson@company.com
SIP/2.0
SIP Response Format
SIP response consiste de uma linha de
status, diversos headers, uma linha
vazia, e um corpo de mensagem.
O corpo de mensagem opcional,
algumas requisies no o usam.
Status Line
status line possui trs elementos: verso do
protocolo, cdigo de status e uma frase.
A verso corrente do protocolo escrita como
SIP/2.0.
O cdigo de status informa o status da
transao.
Exemplo:
SIP/2.0 180 Ringing
SIP Headers
SIP Headers
SIP requests contm alguns SIP headers aps
a request line, ao passo que SIPresponses
coloca-os aps a status line.
Headers fornecem informaes sobre request
ou response e sobre o contedo do corpo da
mensagem.
Alguns headers podem ser usados tanto por
requests quanto por responses.
SIP Headers
Outros so especficos.
O header consiste de um header name,
seguido do header value.
Exemplo de header denominado From, que
identifica o originador de um request
particular:
From: Bob Johnson
<sip:Bob.Johnson@company.com>
Neste exemplo o header From possui dois
campos: um nome da pessoa e um SIP URL.
SIP Headers
SIP Headers
Call-ID
Call-ID representa uma sinalizao SIP entre um ou
mais usurios.
Identifica um convite particular e todas as transaes
subsequentes relacionadas aquele convite tero a
forma a seguir:
Call-ID:
ges456fcdw21lkfgte12ax@workstation1234.university.co
m
Um servidor que esteja tratando a sinalizao SIP para
vrias sesses utilizar o Call-ID associado
mensagem de entrada para a sesso correspondente.
SIP Headers
Por exemplo, Bob convida Laura para uma
sesso de xadrez com um CALL-ID particular.
O UA de Laura aceita e o jogo inicia;
Depois de um tempo Bob chama Laura para uma
conversao enquanto o jogo continua.
UA ter um Call-ID diferente do jogo de xadrez.
Quando termina a conversao, o UA de Bob envia um
BYE para o UA de Laura
O UA de Laura usa o Call-ID para decidir sobre o envio
do BYE para a conversao ou para o jogo. Veja
figura.
SIP Headers
SIP Headers
Contact
Contact header prov um URL onde o
usurio pode ser encontrado.
Esta caracterstica importante porque
libera o Sip server de permanecer aps
o estabelecimento da sesso, aps o
envio do primeiro INVITE.
SIP Headers
Exemplo: Laura chama Bob no
O servidor proxy de Company.com encaminha o
INVITE para SIP:Bob@131.160.1.112, onde Bob se
encontra.
Ele aceita e seu UA envia um 200 OK com o Contact
header:
Contact: Bob Johnson <sip:Bob@131.160.1.112>
Quando o UA de Laura recebe o 200 OK, ele envia o
ACK diretamente para o UA de Bob, j que a
localizao de Bob pode ser encontrada no contact
header, sem passar pelo servidor proxy em
company.com.
SIP Headers
SIP Headers
Cseq
Command Sequence (Cseq) header
possui dois campos: um inteiro e um
nome de mtodo.
A parte numrica usada para ordenar
diferentes requisies na mesma sesso
(definida por um particular Call-ID).
Tambm usado para correlacionar
requisies com respostas.
SIP Headers
Bob envia um INVITE para Laura com o seguinte Cseq:
Cseq: 1 INVITE
Laura retorna um 200 OK com o mesmo Cseq do
INVITE.
Se Bob quiser modificar a sesso j estabelecida, ele
envia um re-Invite com o seguinte Cseq:
Cseq: 2 INVITE
Se uma retransmisso do 200 OK foi atrasada na
rede e chega no UA de Bob aps ele ter gerado o
segundo INVITE, ele saber que esta resposta
corresponde ao primeiro INVITE devido numerao
do Cseq.
SIP Headers
SIP Headers
SIP Headers
Via
Headers Via armazenam todos os proxies que
trataram o request.
Ele contm o caminho trilhado pelo request.
Esta informao usada para detectar loops
de roteamento.
Se um request encaminhado em um loop,
qualquer proxy pode detectar isto simplesmente
inspecionando os headers Via.
SIP Headers
Se encontra seu endereo l, ele sabe que j
tratou este request.
Tpico Header Via:
Via: SIP/2.0/UDP
workstation1234.company.com
Via headers tambm so usados para rotear
respostas diretamente para o client que gerou
o request.
Desta forma, um SIP response trilha o mesmo
conjunto de proxies do request, mas na
direo oposta.
SIP Bodies
Tanto requests quanto responses
podem conter um corpo de mensagem,
separado dos headers por uma linha em
branco.
Usualmente o corpo de mensagem
corresponde a uma descrio da sesso.
Pode contem outros objetos tambm.
Uma vez que SIP proxies no
necessitam examinar o corpo da
mensagem, seu contedo
transparente para ele.
Assim, a descrio da sesso transmitida diretamente para o
UA do usurio final.
O corpo de mensagem pode ser criptografado fim a fim, por
exemplo.
Alguns proxies server podero querer examinar o contedo da
mensagem por exemplo, um servidor de segurana (firewall)
pode prevenir fluxos de trfego no autorizados.
Exemplo de SDP:
v=0
o=Bob 2890844526 2890842807 IN IP4 131.160.1.112
c=IN IP4 131.160.1.112
t=0 0
Assim como em um e-mail, mensagens
podem conter anexos e podem conter
vrios corpos de mensagem.
Laura pode enviar um INVITE com dois
corpos de mensagem, um SDP e sua
fotografia.
O UA de Bob pode exibir a foto de Laura
enquanto sinaliza com Ring.
Exemplo: Chamada SIP atravs
de Proxy
Laura chama Bob em seu endereo
pblico, mas ele no est l.
O servidor proxy em company.com efetua
o roteamento da chamada para sua
localizao corrente
SIP:Bob@131.160.1.112.
Isto envolve trs diferentes transaes:
INVITE, ACK e BYE.
de Proxy
de Proxy
Exemplo: INVITE do UA de Laura para SIP Proxy
O UA de Laura coloca o endereo pblico do UA de Bob
no campo Request-URI.
Isto adiciona um header Via com seu endereo e cria
um corpo de mensagem com uma descrio SDP
Laura quer receber pacotes RTP contendo voz PCM
sobre UDP, na porta 20002.
Esta solicitao enviada para o proxy em
company.com porque o domnio contido no Request-URI
company.com.
de Proxy
INVITE sip:Bob.Johnson@company.com SIP/2.0
Via: SIP/2.0/UDP workstation1000.university.com:5060
From: Laura Brown <sip:Laura.Brown@university.com>
To: Bob Johnson <sip:Bob.Johnson@company.com>
Call-ID: 12345678@workstation1000.university.com
CSeq: 1 INVITE
Contact: Laura Brown <sip:Laura@workstation1000.university.com>
Content-Type: application/sdp
Content-Length: 154
v=0
o=Laura 2891234526 2891234526 IN IP4 workstation1000.university.com
s=Let us talk for a while
c=IN IP4 138.85.27.10
t=0 0
de Proxy
Exemplo: INVITE de SIP Proxy para Bob
O SIP proxy em company.com recebe um INVITE request.
A parte host do Request-URI contm Bob.Johnson.
O proxy sabe que Bob.Johnson pode ser encontrado em
SIP:Bob@131.160.1.112.
Ento cria novo INVITE com a localizao de Bob no
Request-URI, adicionando seu endereo no header Via:
131.160.1.110.
Observe que o corpo da mensagem permanece
inalterado.
de Proxy
INVITE sip:Bob@131.160.1.112 SIP/2.0
Via: SIP/2.0/UDP 131.160.1.110
To: Bob Johnson <sip:Bob.Johnson@company.com>
CSeq: 1 INVITE
Contact: Laura Brown <sip:Laura@workstation1000.university.com>
Content-Length: 154
v=0
o=Laura 2891234526 2891234526 IN IP4 workstation1000.university.com
c=IN IP4 138.85.27.10
t=0 0
de Proxy
AO receber o INVITE, o UA de Bob deve iniciar o sinal de ring,
ento retorna uma resposta provisional informando que o ring
iniciou.
Os Via headers so copiados do INVITE recebido.
Isto ir assegurar que a resposta ir passar pelo proxy primeiro,
131.160.1.110, e ento chegar no UA de Laura,
workstation1234.university.com, na porta UDP nmero 5060.
O UA de Bob adiciona um Contact header resposta contendo o
SIP URL onde Bob pode ser encontrado diretamente a partir deste
momento;
Os requests subsequentes sero enviados diretamente para o UA
de Laura.
de Proxy
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 131.160.1.110
Via: SIP/2.0/UDP
workstation1000.university.com:5060
From: Laura Brown
<sip:Laura.Brown@university.com>
To: Bob Johnson
<sip:Bob.Johnson@company.com>;tag=314159
CSeq: 1 INVITE
de Proxy
Resposta provisional do Proxy para Laura
Ao receber esta resposta, o proxy remove o Via header com seu
prprio endereo e envia a resposta para o endereo contido no
prximo Via. Este proxy no executar nenhuma ao
posteriormente.
SIP/2.0 180 Ringing
To: Bob Johnson
CSeq: 1 INVITE
de Proxy
Resposta Final de Bob para Proxy
Quando Bob aceita a chamada, seu UA
retorna seu SDP descrevendo a sesso.
Ele receber pacotes RTP na porta UDP
41000.
de Proxy
SIP/2.0 200 OK
Via: SIP/2.0/UDP 131.160.1.110
To: Bob Johnson <sip:Bob.Johnson@company.com>;tag=314159
CSeq: 1 INVITE
Content-Length: 154
v=0
o=Bob 2891234321 2891234321 IN IP4 131.160.1.112
c=IN IP4 131.160.1.112
t=0 0
de Proxy
Resposta Final de Proxy para Laura
O proxy server efetua o roteamento da
resposta final da mesma forma que roteou
a resposta provisional anterior.
Ele remove o primeiro Via header e envia
a resposta para o endereo contido no
prximo Via.
de Proxy
SIP/2.0 200 OK
To: Bob Johnson <sip:Bob.Johnson@company.com>;tag=314159
CSeq: 1 INVITE
Content-Length: 154
v=0
o=Bob 2891234321 2891234321 IN IP4 131.160.1.112
c=IN IP4 131.160.1.112
t=0 0
de Proxy
ACK de Laura para Bob
Quando o UA de Laura recebe o 200 OK final, ele envia um ACK
request. Este ACK enviado diretamente para o UA de Bob, cujo
endereo est contido no Contact header recebido.
ACK sip:Bob@131.160.1.112 SIP/2.0
To: Bob Johnson
CSeq: 1 ACK
Contact: Laura Brown
<sip:Laura@workstation1000.university.com>
de Proxy
BYE de Laura para Bob
Laura est pronta para encerrar a sesso, assim seu UA envia um
BYE request. Este BYE request tambm enviado diretamente
para o UA de Bob usando o Contact header recebido previamente.
Veja que o Cseq foi incrementado, Este BYE request pertence a
uma nova transao.
BYE sip:Bob@131.160.1.112 SIP/2.0
To: Bob Johnson
CSeq: 2 BYE
Contact: Laura Brown
<sip:Laura@workstation1000.university.com>
de Proxy
Response final de Bob para Laura
O UA de Bob recebe o BYE request, termina a sesso
de udio e retorna um 200 OK response para o BYE.
SIP/2.0 200 OK
Via: SIP/2.0/UDP
workstation1000.university.com:5060
From: Laura Brown
<sip:Laura.Brown@university.com>
To: Bob Johnson
CSeq: 2 BYE
Cenrios de Aplicaes
Interoperao PSTN-SIP
Telefonia uma das mais importantes
aplicaes SIP.
Provedores tradicionais de telefonia
esto construindo redes IP para
transmisso de voz a fim de explorar a
flexibilidade de servios VOiP
Cenrios de Aplicaes
Para tornar vivel o uso de SIP em telefonia,
uma primeira medida compatibilizar SIP com
os protocolos PSTN.
Compatibilidade pode ser obtida por meio de
gateways que efetuem converso de protocolos
entre PSTN e a rede IP.
Gateways atuam como ns de rede para a
PSTN e como terminais para a rede SIP.
Com este mecanismo , a arquitetura SIP no
afetada pela interoperao com protocolos
PSTN
Cenrios de Aplicaes
Um gateway tipicamente apresenta-se apenas
como um SIP UA para a rede SIP. Ento, a
rede responde a chamadas PSTN.
Uma regra geral para interoperao de SIP com
outra redes assegurar que SIP preserve suas
caractersticas e preserve seu
comportamento.
PSTN usa diversos protocolos de
sinalizao, ento dever haver diferentes
tipos de gateways entre PSTN e SIP.
Uma arquitetura para um gateway particular
depende da capacidade e requisitos.
Gateways de baixa capacidade, usualmente
integram sinalizao e tratamento de mdia
em um single box.
Usualmente interagem com a protocolos de
redes de acesso PSTN como Digital Subscriber
Line No. 1 (DSS-1), utilizados para suportar
aplicaes residenciais ou small office.
High-Capacity Gateways
Gateways de alta capacidade so normalmente
distribudos.
Diferentes partes do gateway desempenharo
diferentes funes e sero mantidos separados.
Um arquitetura comum mostrada na prxima
figura:
Signalling Gateway (SG) recebe a sinalizao
do lado PSTN e a encapsula em pacotes IP (e
vice versa).
O SG no modifica as mensagens de
sinalizao, apenas efetua o roteamento para
o Media Gateway Controller (MGC).
Um MGC executa duas tarefas:
(1) converte o sinal entre o protocolo de
sinalizao PSTN e o SIP;
(2) Controla o Media Gateway (MG).
O MG responsvel por converter a
mdia. Incorpora ambas interfaces:
Voz em circuito
VoIP .
Um MGC envia comandos para o MG
tais como abrir canal de voz ou fechar
canal de voz
O protocolo usado para comunicao do
tipo master/slave como MGCP or H.248.
Presence Architecture
Basicamente, uma instant messaging e
presence service so implementados
usando duas extenses SIP:
MESSAGE e SUBSCRIBE/MODIFY
A arquitetura usada para presena
consiste basicamente de dois ns:
Presence User Agent (PUA)
Presence server.
Presence User Agent (SIP UA usado para o
servio de presena),
envia um REGISTER com o status do usurio
no presence server.
Quando o usurio efetua o log off em seu
notebook, o UA do usurio enviar um
REGISTER reportando que o usurio est
indisponvel ao presence server.
Um usurio pode ter diversos PUAs
(workstation e notebook).
Se um usurio A est interessado na
informao de presena de outro usurio
B, ele pode assinar o servio no servidor
de presena (SUBSCRIBE).
Aps isto, toda vez que a informao
sobre a presena do usurio B mudar, o
usurio A receber um NOTIFY.
Instant Messaging
Instant Messaging
Por meio da informao de presena, SIP pode
prover uma srie de servios.
Um que est mais diretamente relacionado
presena o Instant Message.
Sistemas de presena tem sido usados para
notificar usurios de servios de mensagens
instantneas sobre quem est e quem no est
disponvel para receber mensagens.
Instant Messaging
Instant Messaging
O mtodo MESSAGE pode ser usado para
enviar instant messages no SIP.
SIP possibilita que informao de
presena seja utilizada para estabelecer
qualquer tipo de sesso , incluindo instant
messaging e sesses multimdia.
Instant Messaging
Arquitetura SIP

Redes Multisserviços-Redes-SIP-5 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Redes Multisserviços-Redes-SIP-5 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Redes Multisservios

Vous aimerez peut-être aussi