703741_Redes Multisserviços-Redes-SIP-5.pdf

Redes Multisserviços

Arquitetura SIP

The Internet Multimedia Conferencing Architecture

• O IETF desenvolveu um conjunto de protocolos específicos para serviços multimídia.

• Aplicações 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 Multimídia

The Internet Multimedia Conferencing Architecture

Transport of Real-Time Data: RTP

Requisitos

– Mínimo atraso;– Mínimo jitter;– Entrega ordenada de pacotes;

• Jitter e sequenciamento de Datagramas

• Redes IP introduzem atraso em cada pacote que a atravessa.

• A quantidade de atraso depende de vários 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 tráfego, o atraso será variável, surgindo o efeito de jitter.

• Sendo o jitter suficientemente grande, um pacote pode chegar ao destino antes de outro enviado posteriormente. Os pacotes estarão fora de sequência.

• 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 numeração de sequência no header do pacoter.

• A sequência numérica do Header RTP possibilita ao receptor reordenar o pacote de acordo com a correlação de tempo original dos dados de payload, tais como áudio e vídeo.

• 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 também incorpora informação sobre a fonte que originou o payload.

• Por exemplo, numa conversação por voz tem-se

– O enviador produz pacotes RTP contendo áudio codificado;

– O receptor implementa um buffer para armazenar os pacotes RTP.

– Os pacotes são ordenados de acordo com o número de sequência.

– Um pacote RTP é removido do buffer quando seu timestamp indica que é o momento de ser executado (play).

– O buffer deve ser de tamanho suficientepara que os pacotes tenham tempo de chegar

• Além disto, buffers devem ser o menor possível para que o atraso advindo não tornea conversação impossível.

• Se o pacote não chega no tempo requerido, um algoritmo de preenchimento deve ser usado por meio de técnicas de interpolação.

• RTP pode ser usado para estabelecer o timing de diversos media streams;

• Por exemplo, em uma vídeo conferência pode ser usado para sincronizar áudio e vídeo.

• Para dar suporte a sincronização de mídias, é utilizado o RTCP Real-time Transport Control Protocol [RFC 1889].

• Sua função é associar timestamps e relógio de tempo real. Cada sessão RTP tem associada uma sessão RTCP.

• Além da sincronização de mídia, RTCP provê informações sobre os membros da sessão e da qualidade da comunicação.

• RTCP informa quantos pacotes foram descartadosdurante a sessão de forma que o enviador saiba da qualidade de recepção que o receptor está percebendo

Session Announcement Protocol(SAP)

• Quando alguém decide assistir TV, um procedimento possível seria verificar o guia de programação para saber quais canais estão transmitindo conteúdo de seu interesse;

• Uma vez selecionado o conteúdo de broadcast de interesse, a pessoa então sintoniza o canal de interesse na TV;

• A Internet utiliza um procedimento similar;

• Seleciona-se a sessão multicast de maior interesse entre aqueles disponíveis no momento;

• É necessário configurar ferramentas multimídia para receber a sessão escolhida;

• É importante conhecer, por exemplo, se a sessão consiste apenas de áudio ou de há também vídeo.

• Session Announcement Protocol (SAP) [RFC 2974] foi estabelecido para distribuirinformações sobre sessões multicast entre potenciais receptores.

• SAP efetua a tarefa de descrever sessões multicast em um endereço e porta conhecidos (veja figura a seguir).

• Devido à tecnologia multicast não ser confiável, anúncios SAP também tornam-se não confiáveis e devem ser retransmitidos,periodicamente.

• A taxa de retransmissão pode ser configurada para cada sessão.

• Quanto mais sessões estão presentes, maior será o intervalo de retransmissão.

• SAP pode ser criptografado e pode usar mecanismos de autenticação.

• Isto provê certo nível de privacidade e verifica a identidade do criador de uma sessão particular.

• SAP não define um formato para a descrição de sessões multicast para potenciais receptores.

• Vários formatos podem ser usados, e não há um mecanismo para negociar o formato a ser utilizado.

• É possível que um receptor não entenda a descrição de uma sessão devido a isto.

• O IETF recomenda o uso do formato SDP - Session Description Protocol [RFC 2327].)

• SDP serve como um protocolo comum para descrever sessões e todas as aplicações devem suportá-lo.

Session Description Protocol (SDP)

• Session Description Protocol [RFC 2327] especificacomo informações necessárias para descrever uma sessão devem ser codificadas;

• SDP não inclui qualquer mecanismo de transporte ou qualquer mecanismo de negociação de parâmetros;

• SDP descreve um conjunto de informações para que o sistema possa integrar-se a um sessão multimídia;

• Inclui, por exemplo, endereço IP, porta, horários e datas nas quais o sessão será ativada.

• SDP Syntax• SDP é baseado em texto e não em

formato binário.• Um descrição de sessão por SDP consiste

em um conjunto de linhas, tais como:

• Type = value

• SDP contém informações sobre a sessão e sobre a mídia;

• As informações de sessão aplicam-se a sessão como um todo (nome do originador da sessão, por exemplo);

• As informações sobre mídia aplicam-se somente a um media stream particular (o codec usado, por exemplo, para codificar áudio ou a portaonde o video stream está disponibilizado).

• Começa com informações sobre sessão e seguem-se informações sobre mídia.

• Se houver Informações de sessão, estas começam com V=0, onde v é o type e 0 é o value:

– (SDP version 0).

• A seção de descrição de mídia começa com uma linha m e inclui as próximas até uma nova linha m ou até o fim da descrição da sessão.

• 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

• Neste exemplo, a descrição da sessão consiste das primeiras 9 linhas, de v=0 até a=recvonly, e possui três sessões de mídia: uma de audio stream e duas de video streams.

• A linha o indica o criador da sessão ( neste caso, Bob) e o endereço IP do seu site.

• A linha s contém o nome da sessão;

• A linha i contém informações gerais sobre a sessão.

• A linha u fornece um Uniform Resource Locator (URL) onde mais informações sobre o tópico da sessão podem ser obtidas;

• A linha e contém o endereço de e-mail da pessoa de contato para esta sessão;

• A linha c descreve o endereço de multicast onde a sessão pode ser recebida;

• A linha t indica quando a sessão estará ativa. • A última linha do nível de sessão, linha a, indica

que esta não é uma sessão interativa.

• A linha a seguir, linha m, começa com o media type;• Neste caso, media type pode ser de dois tipo, áudio

para o primeiro media stream e vídeo para os dois outros.

• m=<media type> <port number> <transport protocol> <media formats>

• O port number indica onde a mídia 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 vídeo codificados são transportados usando RTP sobre UDP;

• O media formats depende do tipo de mídia 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 informações sobre o formato de mídia utilizado, tais como taxa de clock ou número de canais;

• No segundo media stream, o media format number 31 refere-se ao H.261 e usa clock de 90 KHz.

• Extending SDP

• As linhas de atributo de mídia, linhas a, fornecem um mecanismo para estender o protocolo SDP, quando uma aplicação requer funcionalidades que não existem no SDP.

• Por exemplo, se o criador da sessão deseja que os receptores executem o áudio em um certo volume, ele pode definir um novo atributo de mídia:

• m=audio 49170 RTP/AVP 0• a=volume:8

• Aplicações que entendam esta nova linha, executarão o áudio no volume 8.

• SDP Next Generation (SDPng)• Originalmente, SDP foi desenvolvido para

descrever sessões multimídia no Mbone (Porção da Internet que dá suporte a multicast).

• Mas encontrou usos em muitos outros contextos:– Real-Time Streaming Protocol (RTSP) [RFC 2326]

para serviços de streaming;– SIP para convites em conferencias;– Dispositivos com configuração mestre/escravo

usando Media Gateway Control Protocol (MGCP) [RFC 2705] ou H.248.

– Devido ao fato que SDP não ter sido desenhado para operar em todos estes ambientes, existem diversas lacunas de implementação.

– Em aplicações futuras que envolvam mecanismos de descrição de sessões também haverá novos requisitos.

– O sucessor do SDP está em desenvolvimento, chamado de SDP nextgeneration (SDPng) e sendo desenvolvido pelo grupo de trabalho do IETF - Multiparty Multimedia Session Control (MMUSIC).

– SDPng irá enriquecer as descrições e possibilitar um mecanismo melhor de negociação do que o SDP.

Real-Time Streaming Protocol(RTSP)

• Real-Time Streaming Protocol (RTSP) [RFC 2326] é usado para controle de servidores multimídia, tipicamente em aplicações de streaming.

• Seu uso pode ser comparado ao de um controle remoto de um DVD player;

• O usuário poderá dizer ao servidor, por exemplo, para iniciar um certo stream de áudio/vídeo usando o “botão play”;

• Também poderá pausar, avançar, retroceder, gravar, etc...

Cenário de uso do conjunto de protocolos vistos

• Uso de protocolos em conjunto para implementar um serviço Internet multimídia destinado a distribuir um filme por multicast.

• O usuário que controla o multcast elabora um descrição de sessão usando SDP, indicando quando o filme será enviado por multcast, sobre o que o filme trata e parâmetros necessários para receber a mídia;

• Estes parâmetros incluirão, pelo menos, endereço de multcast, número da porta e formato da mídia;

• SDP com a descrição da sessão será distribuído via SAP para os potenciais interessados, usando roteamento de multicast;

Usuários interessado examinarão SDP e configurarão suas ferramentas de mídia adequadamente de forma que possam assistir ao filme no tempo designado;

• Quando o filme é programado, o controlador de sessão usa RSTP para alertar o servidor multimídia, onde o filme está armazenado, para iniciar o multicast usando o SDP previamente distribuído.

O servidor de mídia enviará pacotes multicast RTP contendo áudio e vídeo do filme;

• RTCP será usado para coletar e armazenar estatísticas sobre a recepção e qualidade experimentada pelos receptores.

• RSVP deve ser usado para obter certo grau de QoS entre o servidor de mídia e os usuários.

SIP- Session Initiation Protocol

• A arquitetura proposta pelo Internet multimedia conferencing possui uma lacuna importante:

– Não há uma forma explícita de convidar um usuário a se juntar a uma sessão em particular.

Uma sessão multicast pode ser anunciada via SAP, por exemplo, mas caberá aos potenciais receptores verificar os anúncios de sessões periodicamente para decidir juntar-se, ou não, à sessão.

• Não é possível a um usuário avisar outro usuário sobre a sessão e convidá-lo para participar.

Originalmente SIP foi concebido para convidar usuários a se juntarem a uma sessão multcastno Mbone.

O protocolo evoluiu e inclui seu uso para convidar usuários para diversos tipos de sessão multcastou ponto-a-ponto.

SIP - Session Initiation Protocol

• SIP estabelece, modifica e termina sessões multimídia.

• Pode ser usado para convidar novos membros para uma sessão existente ou criar novas sessões.

• SIP é independente do tipo de sessão multimídia e do mecansimo usado para descrever a sessão.

• É usual para videoconferencias, chamadas de áudio, ou sessões de jogos.

• Sessões consistindo de streams RTP transportam áudio e vídeo, sendo descritas por SDP.

• Outros tipos de sessões podem ser descritas por outros tipos de descritores (p.ex, sessão de jogo de xadrez descrito por um protocolo específico).

• SIP é usado para distribuir descrições de sessões entre participantes potenciais.

• SIP pode ser usado para negociar e modificar parâmetros de sessões e terminar sessões.

• Exemplo:

Bob deseja ter uma sessão de áudio-vídeo com Laura e planeja usar codec PCM para codificar voz.

A distribuição de sessão consiste de Bob enviando a Laura uma descrição de sessão 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 configuração usando

codec GSM para voz.A sessão não é estabelecida antes de

concluir esta negociação.

• SIP URL• Usuários SIP são identificados por meio do SIP

Uniform Resource Locators (URLs).• O formato é similar ao de um endereço de e-

mail, geralmente consiste de um nome de usuário (username) e um nome de domínio(domain name)

• SIP:Bob.Johnson@company.com.

• O usuário efetua seu registro em um servidorSIP o qual direciona os SDPs para o usuário.

• Mobilidade (User Mobility)

• O usuário pode ter mais de uma localidadeonde pode ser encontrado (escola, trabalho, casa, site da empresa em outra cidade, etc…)

• Ele poderá ser encontrado em diferentes endereços IP dependendo de que computador esteja usando e no qual deseje ser encontrado para receber convites para sessões.

• Registro (Registration)

• Os usuários registram sua localização corrente em um servidor se ele desejar ser encontrado.

• No exemplo, Bob está trabalhando em um computador cujo endereço IP é 131.160.1.112.

• Seu login name é Bob.

• Ele registra sua localização corrente no servidor da companhia (vide figura).

• Laura deseja chamar Bob.

• Ela conhece seu endereço 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 conexão a ser feita.

• Nesta situação, SIP provê dois modos de operação: redirect e proxy.

• No modo proxy, o servidor contactaBob no endereço IP 131.160.1.112 e entrega a descrição de sessão de Laura.

• No modo redirect, o servidor diz a Laura para tentar o endereço SIP:Bob@131.160.1.112.

Um usuário pode registrar várias localizações em um servidor;

ou pode resgistrar sua localização em vários servidores.

• Não é pouco usual vários servidores serem contactados antes de que o usuário seja encontrado.

SIP Proxy Server

SIP Redirect Server

SIP- Elementos da Arquitetura

• O protocolo SIP define algumas entidades que cumprem um papel específico 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 usuário.

• Possui uma interface direta com o usuário.

• Usuários interagem com UA através de uma interface – frequentemente uma janela com botões de seleção.

• Quando Bob clica o botão para chamar Laura, o UA trigga a mensagem SIP apropriada para estabelecer uma chamada

• Laura também possui um UA SIP em seu computador.

• Quando o UA de Laura recebe um convite de Bob, ele alertaLaura mostrando uma janela de pop-up com dois botões:

–Accept call e Reject call .

• Dependendo de qual botão Laura clicar, seu UA envia uma mensagem SIP diferente para o UA de Bob.

• Todas as interações entre usuários e o protocolo SIP são mediados pelo UA.

SIP- Entidades SIP

Nem todos os sistemas usando SIP estão diretamente conectados a usuários.

Por exemplo, Bob pode redirecionar todos os convites para sessões recebidas de meia noite às 7 da manhã para uma máquina de resposta automática.

A máquina automaticamente irá estabelecer sessõespara gravar mensagens.

Ela também possui um UA que não necessariamente mantém interação com o usuário, mas pode responder convites em seu lugar.

SIP- Entidades SIP• Media Tools

• SIP entrega um descrição de sessão para o SIP UA.

• Se a sessão descreve uma sessão de voz, o UA deverá entregá-la para uma ferramenta de voz que irá tratar o áudio.

• Para outros tipos de sessões, o UA irá encaminhar a sessões para uma ferramenta de mídia apropriada.

• Uma sessão de áuido e vídeo não pode ser estabelecida semuma ferramenta de áudio e uma ferramenta de vídeo.

SIP- Entidades SIP

Se estes elementos são combinados sob a mesma interface de usuário, elas aparecerão como uma simples aplicação:

videoconferencia.

• A separação entre o UA tratando a entrega da sessão e as ferramentas de mídia tratando o conteúdo da mídia possibilita que SIP estabeleça qualquer tipo de sessão.

• SIP UA pode ser executado em um computador ou em dispositivos específicos ( telefone SIP, PABX-IP, p. ex.)

SIP- Entidades SIP

• Redirect Servers

• Redirect servers auxiliam na localizaçãode SIP UAs provendo locais alternativosonde o usuário pode ser encontrado.

• Para cada local é associado um endereço diferente.

SIP- Entidades SIP

• Redirect Servers

Se for feita uma tentativa de buscar um usuáriono seu endereço público (preferencial) e ele não estiver logado naquele servidor, o SIP redirect server irá tratar as solicitações que chegam para o usuário, redirecionando para o endereço onde o usuário 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 endereço SIP:Bob@131.160.1.112 (escritório) ou em Bob@university.com (universidade).

SIP- Entidades SIP

• O redirect server irá indicar para o UA de Laura que tente encontar Bob nestes endereços ao invés do endereço da empresa.

• O redirect server também pode priorizarum endereço, dizendo ser mais provávelencontrá-lo, por exemplo, na universidade.

SIP- Entidades SIP

• O UA de Laura então tentará os dois endereços, priorizando o da universidade como foi recomendado.

• O redirect server não retorna o endereço onde o usuário efetivamenteestá. Ele apenas informa o endereço do servidor que pode saber onde Bob está.

SIP- Entidades SIP

• O redirect server não efetua qualquer ação para localizar o usuário, apenas retorna uma lista de possíveis locaisonde ele possa ser encontrado.

• O UA faz todas as tentativas de localizar o usuário.

SIP- Entidades SIP

• Esta é a diferença principal entre redirect server e proxy server.

• Proxy servers faz sucessivas tentativasde encontrar o usuário ao invés de enviar informações de contato deste.

SIP- Entidades SIP

• Proxy Servers• Proxy servers efetuam as tentativas de

localizar um usuário convidado a participar de uma sessão;

• Diferentemente do redirect server, proxy server não envia para o solicitante opções de localidades nas quais o usuário pode ser encontrado

SIP- Entidades SIP

• Proxy Servers• Ao invés disto, ele próprio envia

mensagens a possíveis servidores os quais potencialmente conheçam o paradeiro do usuário solicitado.

SIP- Entidades SIP

• Como exemplo, suponha que haja um proxy server no domínio company.com capaz de tratar convites que sejam direcionado a usuários do domínio.

• Quando o UA de Laura tenta contactar SIP:Bob.Johnson@company.com, a mensagem chegará ao proxy server do domínio company.com, que buscaráSIP:Bob@university.com em nome do UA de Laura’s.

SIP- Entidades SIP

• Se o domínio university.com também possuir um proxy server, ele tentará o endereço SIP:Bob@workstation1234.university.com onde Bob está.

• Neste cenário, o UA de Laura tentará somente um local, mas vários proxies estão no caminho entre os UAs. Veja figura.

SIP- Entidades SIP

• Forking Proxies• Quando um proxy server tenta mais de uma

localidade, é dito haver uma ramificação de convites.• Forking proxies pode executar buscas sequenciais ou

paralelas, dependendo da configuração.• Uma busca paralela consiste de tentar-se todas os

locais possíveis ao mesmo tempo;• Uma busca sequencial consiste de tentar cada local a

cada vez

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 situação.

SIP- Entidades SIP

• Registrars

• Registrar refere-se ao servidor SIP que recebe registros de usuários;

• Registrar usualmente é colocado no mesmo local do servidor SIP

SIP- Entidades SIP

Location Servers• Location servers não são entidades SIP, mas

desempenham um importante papel na arquitetura do sistema.

• Um location server armazena e retorna possíveis locais em que o usuário pode ser encontrado.

• Pode usar informações dos registrars ou de outra base de dados.

• Em geral, os registrars enviam a localização dos usuários para os location server quando as recebem. Veja figura.

SIP- Entidades SIP

• O proxy server em company.comconsulta o location server para o SIP URL onde Bob deve ser encontrado.

• O location server fornece esta informação ao proxy server porque o registrar enviou esta informação previamente.

SIP- Entidades SIP

• No entanto, SIP não é usado entre os location servers e os SIP servers.

• Alguns location servers usamLightweight Directory Access Protocol (LDAP) [RFC1777] para comunicar com SIP servers.

SIP- Características

• 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- Características

• Por exemplo, se um novo mecanismo de autenticação for implementado pelo IETF, SIP poderá incorporá-lo sem modificações;

• 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 requisições (requests);

Um server é uma entidade SIP que recebe requisições 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 requisição SIP com a resposta associada é denominada transação SIP (SIP transaction);

SIP Responses/Request

• SIP Responses• Ao receber uma requisição o servidor

deternima uma de várias respostas possíveis;

• Cada resposta possui um código que indica o status da transação;

• Códigos de status são números inteiros na faixa de 100 a 699 e são agrupados em classes como mostra a tabela seguinte,

• Respostas com status de 100 a 199 são consideradas provisionais.

• Respostas de 200 a 699 são respostas finais.

• Uma transação SIP entre um client e um server compreende um solictação do client, uma ou mais respostas provisionais e uma resposta final.

• Junto com o código de status, a resposta SIP transporta uma frase

• Esta frase contém uma informação que pode ser entendida por um humano, enquanto o código será tratado por um dispositivo computacional.

Por exemplo, o código 180 significa que o usuário convidado para uma sessão está sendo avisado do convite.

• A frase associada contém a expressão “Ringing” ;• A frase pode ser escrita em uma outra lingua além do

inglês;• O dispositivo SIP que processa a mensagem irá

ignorar a frase e tratará apenas o código;• O dispositivo poderá exibir a frase para um operador

humano que achará mais fácil enteder a mensagem;

• SIP Requests

• São definidos seis tipos de solicitaçõesna especificação (core) SIP, cada uma com um diferente propósito.

• Cada SIP request contém um campo denominado método, que denota seu propósito.

• INVITE• ACK• OPTIONS• BYE• CANCEL• REGISTER

• Tanto as requisições quanto as respostas podem conter um corpo de mensagem (SIP bodies).

• O corpo da mensagem é o seu payload.• SIP bodies usualmente consistem de uma

descrição de sessão.

• INVITE• INVITE solicita um usuário a participar de uma

sessão.• O corpo de um INVITE contém uma descrição da

sessão.• Por exemplo, quando Bob chama Laura, seu UA envia

um INVITE com uma descrição de sessão para o UA de Laura.

• Suponha que o UA de Bob use SDP para descrever a sessão.

• O UA de Laura receberá um INVITE com a seguinte descrição:

• 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• m=audio 49170 RTP/AVP 0

• O INVITE recebido por Laura significa que Bob está convidando Laura para juntar-se a uma sesão 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 também será informado que a codificação deverá ser em PCM leu u (RTP/AVP 0 na linha m indica PCM.)

• O UA de Laura’s 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 descrição da sessão no copo da mensagem.

• v=0• o=Laura 2891234526 2812342807 IN IP4

138.85.27.10• s=I want to know how you are doing• c=IN IP4 138.85.27.10• t=0 0• m=audio 20000 RTP/AVP 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 sessão, eles devem enviar um novo INVITE.

• Este tipo de INVITE é chamado de re-INVITE, e é utilizado para atualizar a descrição da sessão.

• Pode consistir de novos parâmetros como número de porta ou adicionar um novo media streams.

• Por exemplo, pode ser adicionado um video stream na conversação de voz via um re-INVITE.

• SIP somente trata o convite aos usuários.• A descrição da sessão é feita pelo protocolo de

descrição de sessão (SDP neste caso).

• ACK • ACK são usados para confirmar a recepção 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 método que usa three-way handshake porque é um método especial no estabelecimento da sessão, diferente dos demais métodos onde a ação é mais simples e que demandam uma resposta imediata, requerendo apenas um Two-Way-HandShake;

• Three-way handshake possibilita a implementação do forking proxies.

• Quando ocorre uma ramificação de requisição, o cliente que enviou o request obterá várias respostas de diferentes servidores.

• Enviar um ACK para cada destino que respondeu é essencial para assegurar a operação do SIP sobre protocolos não confiáveis como o UDP.

• CANCEL

• CANCEL requests cancelam transações pendentes.

• Se um SIP server recebeu um INVITE mas não 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 não terá efeitosobre a transação.

• Na Figura, Bob envia uma chamada para Laura e seu SIP phone começa a tocar (ringing), mas ninguém 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 também.

• 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 são usados também quando o servidor envia INVITES devido ao fork proxies pois mais de um INVITE é enviado para locais onde o usuário 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 três locais em paralelo (ao mesmo tempo).

A ramificação proxy (forking proxy) envia três 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 sessão entre Laura e Bob, o servidor proxy precisa parar as outras transaçõesiniciadas e envia dois CANCELs, um para cada local restante.

• BYE

• BYE requests são usados para abandonar uma sessão.

• Em uma sessão com dois participantes, o abandonode uma parte implica em terminar a sessão.

Por exemplo, quando Bob envia um BYE para Laura, a sessão é automaticamente terminada.

Em um cenário multicast, um BYE de um dos participantes apenas significa que ele deixará a sessão.

A sessão em si não é afetada.

REGISTER

• Usuários enviam REGISTER requests para informar um servidor (registrar) sobre sua localização corrente.

• Bob pode enviar um REGISTER para o servidor registrar em company.com determinando que todas as requisições 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 estão no mesmolocal que o servidor SIP registrars.

• O SIP registrar pode enviar todas as informações recebidas de vários REGISTER requests para um único location server, possibilitando qualquer SIP server tentar localizar um usuário.

• OPTIONS

• OPTIONS requests interrogam um servidor sobre suas capacidades, incluindo quais métodos e que protocolos descritores de sessão ele suporta

• Um SIP server poderia responder a um OPTIONS request que ele suporta SDP como descritor de sessão e cinco métodos: INVITE,

• ACK,CANCEL,BYE e OPTIONS.• Devido ao servidor não suportar o método REGISTER

, pode-se deduzir que ele não é do tipo registrar.

SIP Responses/Request• OPTIONS

• O método OPTIONS pode não parecer usual em um primeiro momento, mas com novas versões de SIP com novos métodosimplementadas, pode ser muito útil saber sobre as capacidades de um servidor em um cenário de interoperanilidade.

• O método OPTIONS pode também retornar dados que especifiquem que tipo de codificação para corpo de mensagens o servidor é capaz de entender.

• Um servidor pode, por exemplo, entender certo tipo de compressão. O cliente estará habilitado a enviar descrição de sessão com compressão, economizando alguma banda.

Tipos de Proxy Servers

• Proxy servers podem ser classificados de acordo com a quantidade de informações de estado que eles armazenam durante um sessão.

• SIP define três tipos de proxy servers:– Call stateful;– Stateful;– Stateless.

• Call Stateful Proxy

• Call stateful proxies necessitam ser informados de todas as transações SIP que ocorrem durante a sessão e assim estão sempre no caminho das mensagens SIP trafegando entre os usuários.

• Estes servidores proxies armazenam informações do momento em que a sessão foi estabelecida até o momento que ela termina.

• Call Stateful Proxy

• Um exemplo deste tipo de servidor seria um que implementa um serviço relativo à chamda, onde um e-mail é gerado contendo informação sobre a duração da chamada.

• Para determinar a duração 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 são muitas vezes chamados de stateful proxies de transação porque armazenam informações acerca de transações;

• Um stateful proxy armazena estados relativos a uma dada transação até que ela seja concluída;

• Ele não permanece no caminho dos usuários para obter as mensagens SIP para transações subsequentes.

• Stateful Proxy

Forking proxies são bons exemplos de stateful proxies.• Eles enviam INVITEs para vários locais e devem

armazenar estados sobre a transação INVITE a fim de saber quando todos os locais tentados retornaram uma resposta final ou não.

• No entanto, uma vez que o usuário foi localizado, o proxy não necessita permanecer mais no caminhoda sinalização.

• ACKs são gerados como resposta final para um INVITE.

• Também são gerados por servidores proxies e por UAC.

• Proxy servers podem gerar ACK somente para respostas finaismal sucedidas, que tem status maior do que 299.

• Respostas bem sucedidas (status entre 200 e 299) são sempre gerados ACKs pelo UA que iniciou o INVITE.

• A figura anterior mostra proxy server enviando ACKs para respostas de operações mal sucedidas nas mensagens (4) e (7).

• Entretanto, o UA envia ACKs para mensagem 200 OK (11).

• Stateless Proxy

• Stateless proxies não mantém qualquer informação sobre estado.

• Eles recebem um request, encaminham-no para o próximo hop e imediatamente deletam todos os estados relativos aos request.

• Quando um stateless proxy recebe uma resposta, ele determina a rota baseado somente em informações do header Via.

• Análise de tráfego IP na rede, sempre mostra que roteadores de núcleo são sobrecarregados com tráfego em comparação com roteadores de borda.

• Isto também é verdadeiro para tráfego SIP.

• SIP servers de núcleo devem tratar muitas mensagens ao contrário 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

requisição, diversos headers, um linha vazia e um corpo de mesagem.

• O corpo de mensagem é opcional, algumas requisições não o usam.

• Request Line• Uma Request Line é composta por três

elementos: método, Request-URI e versão de protocolo.

• O método indica o tipo de requisição;• Request-URI indica o próximo hop, que é para

onde a requisição deve ser roteada.• Na figura, o SIP proxy localizado em

company.com recebe um INVITE com o Request-URI => SIP:Bob.Johnson@company.com.

• Este proxy sabe que Bob pode ser encontrado em dois locais, então 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 contém o endereço do próximo hop no caminho.

• A versão 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 requisições não o usam.

• Status Line• status line possui três elementos: versão do

protocolo, código de status e uma frase.• A versão corrente do protocolo é escrita como

SIP/2.0.• O código de status informa o status da

transação.• Exemplo:

– SIP/2.0 180 Ringing

SIP Headers

• SIP Headers• SIP requests contém alguns SIP headers após

a request line, ao passo que SIPresponsescoloca-os após a status line.

• Headers fornecem informações sobre requestou response e sobre o conteúdo do corpo da mensagem.

• Alguns headers podem ser usados tanto por requests quanto por responses.

SIP Headers

• Outros são específicos.• 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

• Call-ID • Call-ID representa uma sinalização SIP entre um ou

mais usuários.• Identifica um convite particular e todas as transações

subsequentes relacionadas à aquele convite terão a forma a seguir:

• Call-ID: ges456fcdw21lkfgte12ax@workstation1234.university.com

• Um servidor que esteja tratando a sinalização SIP para várias sessões utilizará o Call-ID associado à mensagem de entrada para a sessão correspondente.

SIP Headers

• Por exemplo, Bob convida Laura para uma sessão 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

conversação enquanto o jogo continua.• UA terá um Call-ID diferente do jogo de xadrez.• Quando termina a conversação, 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 conversação ou para o jogo. Veja figura.

SIP Headers

• Contact • Contact header provê um URL onde o

usuário pode ser encontrado.• Esta característica é importante porque

libera o Sip server de permanecer apóso estabelecimento da sessão, após o envio do primeiro INVITE.

SIP Headers

• Exemplo: Laura chama Bob no SIP:Bob.Johnson@company.com.

• O servidor proxy de Company.com encaminha oINVITE para SIP:Bob@131.160.1.112, onde Bob seencontra.

• 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 localização de Bob pode ser encontrada no contact header, sem passar pelo servidor proxy em company.com.

SIP Headers

• Cseq • Command Sequence (Cseq) header

possui dois campos: um inteiro e um nome de método.

• A parte numérica é usada para ordenar diferentes requisições na mesma sessão (definida por um particular Call-ID).

• Também é usado para correlacionar requisições 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 sessão já estabelecida, ele

envia um re-Invite com o seguinte Cseq:• Cseq: 2 INVITE• Se uma retransmissão do 200 OK foi atrasada na

rede e chega no UA de Bob após ele ter gerado o segundo INVITE, ele saberá que esta resposta corresponde ao primeiro INVITE devido à numeração do Cseq.

SIP Headers

• Via • Headers Via armazenam todos os proxies que

trataram o request. • Ele contém o caminho trilhado pelo request.• Esta informação é 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 endereço lá, ele sabe que já tratou este request.

• Típico Header Via:• Via: SIP/2.0/UDP

workstation1234.company.com• Via headers também são 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 direção 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 descrição da sessão.

• Pode contem outros objetos também.• Uma vez que SIP proxies não

necessitam examinar o corpo da mensagem, seu conteúdo é transparente para ele.

• Assim, a descrição da sessão é transmitida diretamente para o UA do usuário final.

• O corpo de mensagem pode ser criptografado fim a fim, por exemplo.

• Alguns proxies server poderão querer examinar o conteúdo da mensagem por exemplo, um servidor de segurança (firewall)pode prevenir fluxos de tráfego não autorizados.

• Exemplo de SDP:• 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• m=audio 49170 RTP/AVP 0

• Assim como em um e-mail, mensagens podem conter anexos e podem conter vários 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 através de Proxy

• Laura chama Bob em seu endereço público, mas ele não está lá.

• O servidor proxy em company.com efetua o roteamento da chamada para sua localização corrente SIP:Bob@131.160.1.112.

• Isto envolve três diferentes transações: INVITE, ACK e BYE.

• Exemplo: INVITE do UA de Laura para SIP Proxy • O UA de Laura coloca o endereço público do UA de Bob

no campo Request-URI. • Isto adiciona um header Via com seu endereço e cria

um corpo de mensagem com uma descrição SDP• Laura quer receber pacotes RTP contendo voz PCM

sobre UDP, na porta 20002.• Esta solicitação é enviada para o proxy em

company.com porque o domínio contido no Request-URI é company.com.

• 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• m=audio 20002 RTP/AVP 0

Exemplo: INVITE de SIP Proxy para Bob O SIP proxy em company.com recebe um INVITE request.

A parte host do Request-URI contém Bob.Johnson. O proxy sabe que Bob.Johnson pode ser encontrado em • SIP:Bob@131.160.1.112. • Então cria novo INVITE com a localização de Bob no

Request-URI, adicionando seu endereço no header Via:• 131.160.1.110. • Observe que o corpo da mensagem permanece

inalterado.

• INVITE sip:Bob@131.160.1.112 SIP/2.0• 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>• 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• m=audio 20002 RTP/AVP 0

• AO receber o INVITE, o UA de Bob deve iniciar o sinal de ring, então retorna uma resposta provisional informando que o ring iniciou.

• Os Via headers são copiados do INVITE recebido.• Isto irá assegurar que a resposta irá passar pelo proxy primeiro,

131.160.1.110, e então chegar no UA de Laura, workstation1234.university.com, na porta UDP número 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 serão enviados diretamente para o UA de Laura.

• 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• Call-ID: 12345678@workstation1000.university.com• CSeq: 1 INVITE• Contact: Bob Johnson <sip:Bob@131.160.1.112>

• Resposta provisional do Proxy para Laura • Ao receber esta resposta, o proxy remove o Via header com seu

próprio endereço e envia a resposta para o endereço contido no próximo Via. Este proxy não executará nenhuma ação posteriormente.

• SIP/2.0 180 Ringing• 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• Call-ID: 12345678@workstation1000.university.com• CSeq: 1 INVITE• Contact: Bob Johnson <sip:Bob@131.160.1.112>

• Resposta Final de Bob para Proxy• Quando Bob aceita a chamada, seu UA

retorna seu SDP descrevendo a sessão. Ele receberá pacotes RTP na porta UDP 41000.

• SIP/2.0 200 OK• 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• Call-ID: 12345678@workstation1000.university.com• CSeq: 1 INVITE• Contact: Bob Johnson <sip:Bob@131.160.1.112>• Content-Type: application/sdp

• Content-Length: 154• v=0• o=Bob 2891234321 2891234321 IN IP4 131.160.1.112• s=Let us talk for a while• c=IN IP4 131.160.1.112• t=0 0• m=audio 41000 RTP/AVP 0

• 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 endereço contido no próximo Via.

• 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 <sip:Bob.Johnson@company.com>;tag=314159• Call-ID: 12345678@workstation1000.university.com• CSeq: 1 INVITE• Contact: Bob Johnson <sip:Bob@131.160.1.112>• Content-Type: application/sdp• Content-Length: 154

• v=0• o=Bob 2891234321 2891234321 IN IP4 131.160.1.112• s=Let us talk for a while• c=IN IP4 131.160.1.112• t=0 0• m=audio 41000 RTP/AVP 0

• 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 endereço está contido no Contact header recebido.

• ACK sip:Bob@131.160.1.112 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>;tag=314159• Call-ID: 12345678@workstation1000.university.com• CSeq: 1 ACK• Contact: Laura Brown

<sip:Laura@workstation1000.university.com>

• BYE de Laura para Bob • Laura está pronta para encerrar a sessão, assim seu UA envia um

BYE request. Este BYE request é também 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 transação.

• BYE sip:Bob@131.160.1.112 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>;tag=314159• Call-ID: 12345678@workstation1000.university.com• CSeq: 2 BYE• Contact: Laura Brown

<sip:Laura@workstation1000.university.com>

• Response final de Bob para Laura• O UA de Bob recebe o BYE request, termina a sessão

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

<sip:Bob.Johnson@company.com>;tag=314159• Call-ID: 12345678@workstation1000.university.com• CSeq: 2 BYE• Contact: Bob Johnson <sip:Bob@131.160.1.112>

Cenários de AplicaçõesInteroperação PSTN-SIP

• Telefonia é uma das mais importantes aplicações SIP.

• Provedores tradicionais de telefonia estão construindo redes IP para transmissão de voz a fim de explorar a flexibilidade de serviços VOiP

• Para tornar viável 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 conversão de protocolos entre PSTN e a rede IP.

• Gateways atuam como nós de rede para a PSTN e como terminais para a rede SIP.

• Com este mecanismo , a arquitetura SIP não é afetada pela interoperação com protocolos PSTN

• Um gateway tipicamente apresenta-se apenas como um SIP UA para a rede SIP. Então, a rede responde a chamadas PSTN.

• Uma regra geral para interoperação de SIP com outra redes é assegurar que SIP preserve suas características e preserve seu comportamento.

• PSTN usa diversos protocolos de sinalização, então deverá haver diferentes tipos de gateways entre PSTN e SIP.

Interoperação PSTN-SIP

• Uma arquitetura para um gateway particular depende da capacidade e requisitos.

• Gateways de baixa capacidade, usualmente integram sinalização e tratamento de mídia 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 aplicações residenciais ou small office.

• High-Capacity Gateways

• Gateways de alta capacidade são normalmente distribuídos.

• Diferentes partes do gateway desempenharão diferentes funções e serão mantidos separados.

• Um arquitetura comum é mostrada na próxima figura:

• Signalling Gateway (SG) – recebe a sinalizaçãodo lado PSTN e a encapsula em pacotes IP (e vice versa).

• O SG não modifica as mensagens de sinalização, apenas efetua o roteamento para o Media Gateway Controller (MGC).

• Um MGC executa duas tarefas: – (1) converte o sinal entre o protocolo de

sinalização PSTN e o SIP;– (2) Controla o Media Gateway (MG).

• O MG é responsável por converter a mídia. 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 comunicação é do tipo master/slave como MGCP or H.248.

Presence Architecture

• Basicamente, uma instant messaging e presence service são implementados usando duas extensões SIP: – MESSAGE e SUBSCRIBE/MODIFY

• A arquitetura usada para presença consiste basicamente de dois nós:

– Presence User Agent (PUA) – Presence server.

Presence User Agent (SIP UA usado para o serviço de presença),– envia um REGISTER com o status do usuário

no presence server.– Quando o usuário efetua o log off em seu

notebook, o UA do usuário enviará um REGISTER reportando que o usuário está indisponível ao presence server.

• Um usuário pode ter diversos PUAs (workstation e notebook).

• Se um usuário A está interessado na informação de presença de outro usuário B, ele pode assinar o serviço no servidor de presença (SUBSCRIBE).

• Após isto, toda vez que a informação sobre a presença do usuário B mudar, o usuário A receberá um NOTIFY.

Instant Messaging

• Instant Messaging

• Por meio da informação de presença, SIP pode prover uma série de serviços.

• Um que está mais diretamente relacionado à presença é o Instant Message.

• Sistemas de presença tem sido usados para notificar usuários de serviços de mensagensinstantâneas sobre quem está e quem não está disponível para receber mensagens.

Instant Messaging

• Instant Messaging

O método MESSAGE pode ser usado para enviar instant messages no SIP.

• SIP possibilita que informação de presença seja utilizada para estabelecer qualquer tipo de sessão , incluindo instant messaging e sessões multimídia.

Instant Messaging

Arquitetura SIP

703741_Redes Multisserviços-Redes-SIP-5.pdf

Documents

Transcript of 703741_Redes Multisserviços-Redes-SIP-5.pdf

Introdução ao protocolo SIP* - eng.registro.br · Introdução ao protocolo SIP* 1. SIP (Session Initiation Protocol) Podese dizer que SIP tratase de um protocolo de controle referente

Notas Iutep 2010 III Pra2302n Sip

Redes e Multisserviços

Integração do protocolo SIP na Media Framework da ...mei.di.uminho.pt/sites/default/files/dissertacoes/eeum_di_dissert... · Integração do protocolo SIP na Media Framework da

03 Material SIP 1Bim

VOIP Segurança-SIP

Introdução ao protocolo SIP* - Engeng.registro.br/inoc/SIP_iNOC.pdf · Introdução ao protocolo SIP* 1. SIP (Session Initiation Protocol) Podese dizer que SIP tratase de um protocolo

Balanceamento de Chamadas VoIP a Transcodificar · Dissertação apresentada como requisito parcial para a obtenção do título ... 1. Redes de computação ... Open SIP Express

Solução de Valor Agregado de Imagem no Protocolo SIP.

CATÁLOGO GERAL - optexiberia.com · SIP-3020 CAM DN Detectores IVP Médio/Longo Alcance Detector Laser Scan Série REDSCAN Série REDWALL SIP RLS-3060L RLS-3060SH

AG561 Gateway SIP E1 - docs.aligera.com.br

Interoperabilidade entre SIP e H.323

Codigos Sip Paragens Ord Carreira

Datasheet NGC VoIP Manager v1 - digitro.com · PROTOCOLOS VOIP CODECS G ... SINALIZAÇÃO SIP ENTRONCAMENTO SIP SIP Register SIP Trunk MONITORAMENTO SNMP v2 SNMP v3 ... Alguns itens

Arquitectura SIP IPTV para Redes Heterogéneas...A todos os meus amigos e colegas, pela força para seguir em frente nos momentos mais difíceis. Um obrigado especial ao Leandro pelo

Diário Oficial - pontagrossa.pr.gov.br · englobando redes multisserviços para transmissão de voz, dados e imagens, para suprir as necessidades dos órgãos da Administraç ão

Curso de Engenharia de Computação CONTROLADOR DE SESSÕES SIP PARA REDES DE …lyceumonline.usf.edu.br/salavirtual/documentos/1198.pdf · 2008-12-19 · Monografia defendida e aprovada

Soluções Wireless / VoIP para Redes ComunitáriasMIECT... · palavras-chave VoIP – Voz sobre IP, Protocolo Internet, SIP, H.323, IAX, SDP, RTP, SIP Proxing, IP PBX - Asterisk,

Sip pulse presentation

PARA REGISTRO DE ESTABELECIMENTOS SIP/POA