Arquitetura SIP: Elementos e Entidades

Prévia do material em texto

<p>REDES MULTISSERVIÇOS</p><p>Arquitetura SIP</p><p>SIP- ELEMENTOS DA ARQUITETURA</p><p>O protocolo SIP define algumas entidades que</p><p>cumprem um papel específico na arquitetura de</p><p>sistemas SIP.</p><p>User Agents</p><p>Media Tools</p><p>Redirect Servers</p><p>Proxy Servers</p><p>Registrars</p><p>SIP- ELEMENTOS DA ARQUITETURA</p><p>User Agents</p><p>User Agent (UA) é uma entidade SIP que interage com usuário.</p><p>Implementa o protocolo e funcionalidades SIP.</p><p>Possui uma interface direta com o usuário.</p><p>Usuários interagem com UA através de uma interface –</p><p>frequentemente uma janela com botões de seleção.</p><p>SIP- ELEMENTOS DA ARQUITETURA</p><p>Quando Bob clica o botão para chamar Laura, o UA trigga a</p><p>mensagem SIP apropriada para estabelecer uma chamada</p><p>Laura também possui um UA SIP em seu computador.</p><p>SIP- ELEMENTOS DA ARQUITETURA</p><p>Quando o UA de Laura recebe um</p><p>convite de Bob, ele alerta Laura</p><p>mostrando uma janela de pop-up com</p><p>dois botões:</p><p>Accept call e Reject call .</p><p>SIP- ELEMENTOS DA ARQUITETURA</p><p>Dependendo de qual botão Laura</p><p>clicar, seu UA envia uma mensagem</p><p>SIP diferente para o UA de Bob.</p><p>Todas as interações entre usuários e o</p><p>protocolo SIP são mediados pelo UA.</p><p>SIP- ENTIDADES SIP</p><p>Nem todos os sistemas usando SIP estão diretamente conectados</p><p>a usuários.</p><p>Por exemplo, Bob pode redirecionar todos os convites para</p><p>sessões recebidas de meia noite às 7 da manhã para uma</p><p>máquina de resposta automática.</p><p>A máquina automaticamente irá estabelecer sessões para</p><p>gravar mensagens.</p><p>Ela também possui um UA que não necessariamente mantém</p><p>interação com o usuário, mas pode responder convites em seu</p><p>lugar.</p><p>SIP- ENTIDADES SIP</p><p>Media Tools</p><p>SIP entrega um descrição de sessão para o SIP UA.</p><p>Se a sessão descreve uma sessão de voz, o UA deverá entregá-la para uma</p><p>ferramenta de voz que irá tratar o áudio.</p><p>Para outros tipos de sessões, o UA irá encaminhar a sessões para uma</p><p>ferramenta de mídia apropriada.</p><p>Uma sessão de áuido e vídeo não pode ser estabelecida sem uma</p><p>ferramenta de áudio e uma ferramenta de vídeo.</p><p>SIP- ENTIDADES SIP</p><p>Se estes elementos são combinados sob a mesma interface de usuário, eles</p><p>aparecerão como uma simples aplicação: Videoconferencia.</p><p>A separação entre o UA tratando a entrega da sessão e as ferramentas de</p><p>mídia tratando o conteúdo da mídia possibilita que SIP estabeleça qualquer</p><p>tipo de sessão.</p><p>SIP UA pode ser executado em um computador ou em dispositivos específicos</p><p>( telefone SIP, PABX-IP, p. ex.)</p><p>SIP- ENTIDADES SIP</p><p>Redirect Servers</p><p>Redirect servers auxiliam na localização de SIP UAs provendo locais</p><p>alternativos onde o usuário pode ser encontrado.</p><p>Para cada local é associado um endereço diferente.</p><p>SIP- ENTIDADES SIP</p><p>Redirect Servers</p><p>Se for feita uma tentativa de buscar um usuário no seu</p><p>endereço público (preferencial) e ele não estiver</p><p>logado naquele servidor, o SIP redirect server irá tratar</p><p>as solicitações que chegam para o usuário,</p><p>redirecionando para o endereço onde o usuário</p><p>potencialmente pode ser localizado.</p><p>SIP- ENTIDADES SIP</p><p>Redirect Servers</p><p>No exemplo o UA de Laura tenta localizar Bob;</p><p>O redirect server sabe que Bob pode ser localizado no endereço</p><p>SIP:Bob@131.160.1.112 (escritório) ou em Bob@university.com</p><p>(universidade).</p><p>SIP- ENTIDADES SIP</p><p>O redirect server irá indicar para o UA de Laura que tente encontar Bob</p><p>nestes endereços ao invés do endereço da empresa.</p><p>O redirect server também pode priorizar um endereço, dizendo ser mais</p><p>provável encontrá-lo, por exemplo, na universidade.</p><p>SIP- ENTIDADES SIP</p><p>O UA de Laura então tentará os dois endereços, priorizando o da</p><p>universidade como foi recomendado.</p><p>O redirect server não retorna o endereço onde o usuário efetivamente está.</p><p>Ele apenas informa o endereço do servidor que pode saber onde Bob está.</p><p>SIP- ENTIDADES SIP</p><p>O redirect server não efetua qualquer ação para localizar o usuário, apenas</p><p>retorna uma lista de possíveis locais onde ele possa ser encontrado.</p><p>O UA faz todas as tentativas de localizar o usuário.</p><p>SIP- ENTIDADES SIP</p><p>Esta é a diferença principal entre redirect server e proxy server.</p><p>Proxy servers faz sucessivas tentativas de encontrar o usuário ao invés de</p><p>enviar informações de contato deste.</p><p>SIP- ENTIDADES SIP</p><p>Proxy Servers</p><p>Proxy servers efetuam as tentativas de localizar um usuário convidado a</p><p>participar de uma sessão;</p><p>Diferentemente do redirect server, proxy server não envia para o solicitante</p><p>opções de localidades nas quais o usuário pode ser encontrado</p><p>SIP- ENTIDADES SIP</p><p>Proxy Servers</p><p>Ao invés disto, ele próprio envia mensagens a possíveis servidores os quais</p><p>potencialmente conheçam o paradeiro do usuário solicitado.</p><p>SIP- ENTIDADES SIP</p><p>Como exemplo, suponha que haja um proxy server no</p><p>domínio company.com capaz de tratar convites que</p><p>sejam direcionado a usuários do domínio.</p><p>Quando o UA de Laura tenta contactar</p><p>SIP:Bob.Johnson@company.com, a mensagem</p><p>chegará ao proxy server do domínio company.com,</p><p>que buscará SIP:Bob@university.com em nome do UA</p><p>de Laura’s.</p><p>SIP- ENTIDADES SIP</p><p>Se o domínio university.com também possuir um</p><p>proxy server, ele tentará o endereço</p><p>SIP:Bob@workstation1234.university.com onde Bob</p><p>está.</p><p>Neste cenário, o UA de Laura tentará somente um</p><p>local, mas vários proxies estão no caminho entre os</p><p>UAs. Veja figura.</p><p>SIP- ENTIDADES SIP</p><p>SIP- ENTIDADES SIP</p><p>Forking Proxies</p><p>Quando um proxy server tenta mais de uma localidade, é dito</p><p>haver uma ramificação de convites.</p><p>Forking proxies pode executar buscas sequenciais ou paralelas,</p><p>dependendo da configuração.</p><p>Uma busca paralela consiste de tentar-se todas os locais</p><p>possíveis ao mesmo tempo;</p><p>Uma busca sequencial consiste de tentar um local a cada vez</p><p>SIP- ENTIDADES SIP</p><p>SIP- ENTIDADES SIP</p><p>O termo SIP server refere-se de forma geral aos dois tipos de servidores</p><p>(redirect e proxy)</p><p>O mesmo servidor pode operar de forma diferente, dependendo da</p><p>situação.</p><p>SIP- ENTIDADES SIP</p><p>Registrars</p><p>Registrar refere-se ao servidor SIP que recebe registros de usuários;</p><p>Registrar usualmente é co-alocado com o servidor SIP</p><p>SIP- ENTIDADES SIP</p><p>SIP- ENTIDADES SIP</p><p>Location Servers</p><p>Location servers não são entidades SIP, mas desempenham um</p><p>importante papel na arquitetura do sistema.</p><p>Um location server armazena e retorna possíveis locais em que</p><p>o usuário pode ser encontrado.</p><p>Pode usar informações dos registrars ou de outra base de</p><p>dados.</p><p>Em geral, os registrars enviam a localização dos usuários para</p><p>os location server quando as recebem. Veja figura.</p><p>SIP- ENTIDADES SIP</p><p>SIP- ENTIDADES SIP</p><p>O proxy server em company.com consulta o location server para o SIP</p><p>URL onde Bob deve ser encontrado.</p><p>O location server fornece esta informação ao proxy server porque o</p><p>registrar enviou esta informação previamente.</p><p>SIP- ENTIDADES SIP</p><p>SIP- ENTIDADES SIP</p><p>No entanto, SIP não é usado entre os location servers e os SIP servers.</p><p>Alguns location servers usam Lightweight Directory Access Protocol (LDAP)</p><p>[RFC1777] para comunicar com SIP servers.</p><p>SIP- CARACTERÍSTICAS</p><p>IETF projetou SIP com base no paradigma da Internet.</p><p>Usa mecanismos da Internet para prover suas funcionalidades</p><p>Isto provê grande flexibilidade porque SIP pode ser usado com outros</p><p>protocolos Internet e pode ser feito de forma modularizada</p><p>SIP- CARACTERÍSTICAS</p><p>Por exemplo, se um novo mecanismo de autenticação for implementado</p><p>pelo IETF, SIP poderá incorporá-lo sem modificações;</p><p>SIP estará habilitado a usar novos mecanismos de QoS;</p><p>SIP é dito ser a prova de futuro.</p><p>CLIENT/SERVER TRANSACTIONS</p><p>SIP é baseado em HTTP e como este, SIP é baseado em</p><p>um protocolo do tipo request/response;</p><p>Um client é uma entidade SIP que gera requisições</p><p>(requests);</p><p>Um server é uma entidade SIP que recebe requisições</p><p>e retorna respostas (responses);</p><p>CLIENT/SERVER TRANSACTIONS</p><p>Quando dois agentes Sip trocam mensagens, o User</p><p>Agent (UA) que envia mesnsagens é um User Agent</p><p>Client (UAC);</p><p>O UA retornando respostas é o User Agent Server</p><p>(UAS);</p><p>Uma requisição SIP com a resposta associada é</p><p>denominada transação SIP (SIP transaction);</p><p>SIP RESPONSES/REQUEST</p><p>SIP Responses</p><p>Ao receber uma requisição o servidor deternima uma de</p><p>várias respostas possíveis;</p><p>Cada resposta possui um código que indica o status da</p><p>transação;</p><p>Códigos de status são números inteiros na faixa de 100 a</p><p>699 e são agrupados em classes como mostra a tabela</p><p>seguinte,</p><p>SIP RESPONSES/REQUEST</p><p>SIP RESPONSES/REQUEST</p><p>Respostas com status de 100 a 199 são consideradas provisionais.</p><p>Respostas de 200 a 699 são respostas finais.</p><p>Uma transação SIP entre um client e um server compreende um solictação</p><p>do client, uma ou mais respostas provisionais e uma resposta final.</p><p>SIP RESPONSES/REQUEST</p><p>Junto com o código de status, a resposta SIP transporta uma frase</p><p>Esta frase contém uma informação que pode ser entendida por um humano,</p><p>enquanto o código será tratado por um dispositivo computacional.</p><p>SIP RESPONSES/REQUEST</p><p>Por exemplo, o código 180 significa que o usuário convidado</p><p>para uma sessão está sendo avisado do convite.</p><p>A frase associada contém a expressão “Ringing” ;</p><p>A frase pode ser escrita em uma outra lingua além do inglês;</p><p>O dispositivo SIP que processa a mensagem irá ignorar a frase</p><p>e tratará apenas o código;</p><p>O dispositivo poderá exibir a frase para um operador humano</p><p>que achará mais fácil enteder a mensagem;</p><p>SIP RESPONSES/REQUEST</p><p>SIP RESPONSES/REQUEST</p><p>SIP RESPONSES/REQUEST</p><p>SIP Requests</p><p>São definidos seis tipos de solicitações na especificação (core) SIP, cada uma</p><p>com um diferente propósito.</p><p>Cada SIP request contém um campo denominado método, que denota seu</p><p>propósito.</p><p>SIP RESPONSES/REQUEST</p><p>INVITE</p><p>ACK</p><p>OPTIONS</p><p>BYE</p><p>CANCEL</p><p>REGISTER</p><p>SIP RESPONSES/REQUEST</p><p>Tanto as requisições quanto as respostas podem conter um corpo de</p><p>mensagem (SIP bodies).</p><p>O corpo da mensagem é o seu payload.</p><p>SIP bodies usualmente consistem de uma descrição de sessão.</p><p>SIP RESPONSES/REQUEST</p><p>INVITE</p><p>INVITE convida um usuário a participar de uma sessão.</p><p>O corpo de um INVITE contém uma descrição da sessão.</p><p>Por exemplo, quando Bob chama Laura, seu UA envia um</p><p>INVITE com uma descrição de sessão para o UA de Laura.</p><p>Suponha que o UA de Bob use SDP para descrever a sessão.</p><p>O UA de Laura receberá um INVITE com a seguinte descrição:</p><p>SIP RESPONSES/REQUEST</p><p>v=0</p><p>o=Bob 2890844526 2890842807 IN IP4 131.160.1.112</p><p>s=I want to know how you are doing</p><p>c=IN IP4 131.160.1.112</p><p>t=0 0</p><p>m=audio 49170 RTP/AVP 0</p><p>SIP RESPONSES/REQUEST</p><p>O INVITE recebido por Laura significa que Bob está convidando Laura para</p><p>juntar-se a uma sesão de áudio.</p><p>O UA de Laura saberá, pelo INVITE recebido, que o UA de Bob deseja usar</p><p>pacotes RTP para transportar o sinal de voz de Laura e que usará o IP</p><p>131.160.1.112, sendo baseado em UDP, na porta 49170.</p><p>SIP RESPONSES/REQUEST</p><p>O UA de Laura também será informado que a codificação</p><p>deverá ser em PCM lei u (RTP/AVP 0 na linha m indica PCM.)</p><p>O UA de Laura’s sinalizará para Laura sobre a chamada de</p><p>entrada e retornará a resposta “180 Ringing” para o UA de Bob.</p><p>Quando Laura aceitar a chamada, seu UA enviará a resposta</p><p>“200 OK” com a descrição da sessão no corpo da mensagem.</p><p>SIP RESPONSES/REQUEST</p><p>v=0</p><p>o=Laura 2891234526 2812342807 IN IP4 138.85.27.10</p><p>s=I want to know how you are doing</p><p>c=IN IP4 138.85.27.10</p><p>t=0 0</p><p>m=audio 20000 RTP/AVP 0</p><p>SIP RESPONSES/REQUEST</p><p>Neste ponto, Laura aceita a chamada e informa a Bob</p><p>que receberá pacotes RTP em 138.85.27.10, UDP, porta</p><p>20000.</p><p>Se Laura ou Bob desejarem modificar a sessão, eles</p><p>devem enviar um novo INVITE.</p><p>Este tipo de INVITE é chamado de re-INVITE, e é</p><p>utilizado para atualizar a descrição da sessão.</p><p>SIP RESPONSES/REQUEST</p><p>Pode consistir de novos parâmetros como número de</p><p>porta ou adicionar um novo media streams.</p><p>Por exemplo, pode ser adicionado um video stream na</p><p>conversação de voz via um re-INVITE.</p><p>SIP somente trata o convite aos usuários.</p><p>A descrição da sessão é feita pelo protocolo de</p><p>descrição de sessão (SDP neste caso).</p><p>SIP RESPONSES/REQUEST</p><p>SIP RESPONSES/REQUEST</p><p>ACK</p><p>ACK são usados para confirmar a recepção de uma</p><p>resposta final para um INVITE.</p><p>Um client originando um INVITE request, envia um</p><p>ACK request quando recebe uma resposta final para o</p><p>INVITE, provendo um Three-Way Handshake:</p><p> INVITE-final response-ACK</p><p>SIP RESPONSES/REQUEST</p><p>INVITE é o único método que usa three-way handshake porque é um método</p><p>especial no estabelecimento da sessão, diferente dos demais métodos onde</p><p>a ação é mais simples e que demandam uma resposta imediata, requerendo</p><p>apenas um Two-Way-HandShake;</p><p>Three-way handshake possibilita a implementação do forking proxies.</p><p>SIP RESPONSES/REQUEST</p><p>Quando ocorre uma ramificação de requisição, o cliente que enviou o request</p><p>obterá várias respostas de diferentes servidores.</p><p>Enviar um ACK para cada destino que respondeu é essencial para</p><p>assegurar a operação do SIP sobre protocolos não confiáveis como o UDP.</p><p>SIP RESPONSES/REQUEST</p><p>SIP RESPONSES/REQUEST</p><p>CANCEL</p><p>CANCEL requests cancelam transações pendentes.</p><p>Se um SIP server recebeu um INVITE mas não retornou</p><p>uma resposta final, um CANCEL irá parar o</p><p>processamento do INVITE .</p><p>Se o resposta final já foi enviada para o INVITE , um</p><p>CANCEL request não terá efeito sobre a transação.</p><p>SIP RESPONSES/REQUEST</p><p>Na Figura, Bob envia convite para uma chamada para Laura e seu SIP phone começa</p><p>a tocar (ringing), mas ninguém atende.</p><p>Bob decide desconectar-se e envia um CANCEL request para o INVITE anteriormente</p><p>enviado.</p><p>Ao receber o CANCEL, o SIP phone de Laura para o sinal de ring e envia uma</p><p>resposta 200 OK associada ao CANCEL, indicando que o CANCEL foi processado.</p><p>O servidor no SIP phone responde ao INVITE também.</p><p>Ele envia um “487 Transaction Cancelled” e o client (de Bob) finaliza o INVITE three-</p><p>way handshake enviando um ACK (INVITE-487 Transaction Cancelled-ACK).</p><p>SIP RESPONSES/REQUEST</p><p>SIP RESPONSES/REQUEST</p><p>CANCEL requests são usados também quando o servidor envia</p><p>INVITES devido ao fork proxies pois mais de um INVITE é</p><p>enviado para locais onde o usuário possa estar.</p><p>Na figura, Bob pode ser encontrado em</p><p>SIP:Bob@131.160.1.112, SIP:Bob.Johnson@company.com e</p><p>SIP:Bob@university.com.</p><p>Quando o servidor proxy recebe um INVITE de Laura para Bob,</p><p>ele tentará estes três locais em paralelo (ao mesmo tempo).</p><p>SIP RESPONSES/REQUEST</p><p>A ramificação proxy (forking proxy) envia três INVITEs, um para</p><p>cada local.</p><p>Bob está no momento trabalhando em 131.160.1.112, este</p><p>servidor responde a chamada.</p><p>O servidor proxy recebe um 200 OK de</p><p>SIP:Bob@131.160.1.112 e encaminha esta resposta para o UA</p><p>de Laura.</p><p>Uma vez estabelecida a sessão entre Laura e Bob, o servidor</p><p>proxy precisa parar as outras transações iniciadas e envia dois</p><p>CANCELs, um para cada local restante.</p><p>SIP RESPONSES/REQUEST</p><p>SIP RESPONSES/REQUEST</p><p>BYE</p><p>BYE requests são usados para abandonar uma sessão.</p><p>Em uma sessão com dois participantes, o abandono de uma</p><p>parte implica em terminar a sessão.</p><p>Por exemplo, quando Bob envia um BYE para Laura, a sessão é</p><p>automaticamente terminada.</p><p>Em um cenário multicast, um BYE de um dos participantes apenas</p><p>significa que ele deixará a sessão.</p><p>A sessão em si não é afetada.</p><p>SIP RESPONSES/REQUEST</p><p>SIP RESPONSES/REQUEST</p><p>REGISTER</p><p>Usuários enviam REGISTER requests para informar um</p><p>servidor (registrar) sobre sua localização corrente.</p><p>Bob pode enviar um REGISTER para o servidor</p><p>registrar em company.com determinando que todas as</p><p>requisições de entrada para</p><p>SIP:Bob.Johnson@company.com devem ser</p><p>direcionadas (proxie) ou redirecionadas (redirec) para</p><p>SIP:Bob@131.160.1.112</p><p>SIP RESPONSES/REQUEST</p><p>SIP servers normalmente estão no mesmo local que o servidor SIP registrars.</p><p>O SIP registrar pode enviar todas as informações recebidas de vários</p><p>REGISTER requests para um único location server, possibilitando qualquer SIP</p><p>server tentar localizar um usuário.</p><p>SIP RESPONSES/REQUEST</p><p>SIP RESPONSES/REQUEST</p><p>OPTIONS</p><p>OPTIONS requests interrogam um servidor sobre suas</p><p>capacidades, incluindo quais métodos e que protocolos</p><p>descritores de</p><p>sessão ele suporta</p><p>Um SIP server poderia responder a um OPTIONS request que ele</p><p>suporta SDP como descritor de sessão e cinco métodos: INVITE,</p><p>ACK,CANCEL,BYE e OPTIONS.</p><p>Devido ao servidor não suportar o método REGISTER , pode-se</p><p>deduzir que ele não é do tipo registrar.</p><p>SIP RESPONSES/REQUEST</p><p>OPTIONS</p><p>O método OPTIONS pode não parecer usual em um primeiro momento, mas</p><p>com novas versões de SIP com novos métodos implementados, pode ser</p><p>muito útil saber sobre as capacidades de um servidor em um cenário de</p><p>interoperanilidade.</p><p>O método OPTIONS pode também retornar dados que especifiquem que tipo</p><p>de codificação para corpo de mensagens o servidor é capaz de entender.</p><p>Um servidor pode, por exemplo, entender certo tipo de compressão. O cliente</p><p>estará habilitado a enviar descrição de sessão com compressão, economizando</p><p>alguma banda.</p><p>SIP RESPONSES/REQUEST</p>