Comutação de Pacotes IP em Telecom - Parte 4

Postado por leopedrini quinta-feira, 22 de março de 2012 09:26:00 Categories: Curso
Rate this Content 0 Votes

Então, finalmente, chegamos aos protocolos de sinalização NGN: SIP e SDP. A imagem abaixo foi extraída da RFC 3261, e dá um exemplo muito bom de um diálogo SIP entre dois usuários, Alice e Bob.

Nota: Visite também meu blog Smolka et Catervarii

 

As entidades envolvidas no estabelecimento da chamada são chamadas User Agents (UA). UAs que solicitem serviços são chamados de User Agent Clients (UAC), e aqueles que preenchem os pedidos são chamados de User Agent Servers (UAS). Embora o modo de funcionamento básico seja end-to-end, o modelo suporta o uso de servidores proxy intermediários, que funcionam como back-to-back User Agents (B2BUA) repassando as requisições de um usuário para outro. Na figura o softphone da Alice e o telefone SIP do Bob são end-to-end User Agents, enquanto há dois servidores proxy: atlanta.com e biloxi.com. Juntando isso com o que já sabemos sobre o IMS, podemos identificar o P-CSCF como um servidor proxy SIP, enquanto os UEs de comunicação são os end-to-end UAs.

Citando a RFC 3261:

"O SIP não faz prestação de serviços. Em vez disso o SIP fornece primitivas que podem ser utilizados para implementar diferentes serviços. Por exemplo, o SIP pode localizar um usuário e entregar a ele um objeto opaco. Se esta primitiva for usada para fornecer uma descrição de sessão do protocolo SDP, por exemplo, os terminais podem negociar os parâmetros de uma sessão. Se a mesma primitiva é utilizada para entregar uma foto do autor da chamada, bem como a descrição da sessão, um serviço de 'identificação de chamada' pode ser facilmente implementado. Como mostra este exemplo, uma única primitiva normalmente é usada para suportar vários serviços diferentes. "

As primitivas do SIP são:

  • REGISTER: Indica o endereço de IP atual do UA e os Uniform Resource Identifiers (URI) para o quais ele pode receber chamadas;
  • INVITE: Usado para estabelecer uma sessão entre UAs;
  • ACK: Confirma uma troca de mensagens com resposta confiável ??(veja abaixo);
  • PRACK (Provisional ACK): Confirma uma troca de mensagens com resposta provisória (ver abaixo). Isto foi incluído pela RFC 3262;
  • OPTIONS: Pedido de informação sobre as capacidades de um servidor proxy SIP ou UA, sem estabelecer uma chamada;
  • CANCEL: Termina uma solicitação pendente;
  • BYE: Termina uma sessão entre dois UAs.

Tipicamente uma mensagem SIP tem que ter uma resposta. Como no protocolo HTTP, as respostas SIP são identificadas com números de três dígitos. O dígito mais à esquerda diz a qual categoria pertence a resposta:

  • Provisória (1xx): pedido recebido e em processamento;
  • Sucesso (2xx): pedido recebido com sucesso, compreendido e aceito;
  • Redirecionamento (3xx): há necessidade de ação adicional pelo remetente para completar o pedido;
  • Erro do cliente (4xx): pedido contém erro de sintaxe, ou não pode ser executado no servidor/UA de destino;
  • Erro do servidor (5xx): O servidor/UA de destino não executou uma solicitação aparentemente válida;
  • Falha Global (6xx): O pedido não pode ser executado em qualquer servidor/UA.

 

Citando a RFC 4566:

"Uma descrição de sessão SDP consiste de uma série de linhas de texto, da forma:

<tipo> = valor

Onde <tipo> deve ser um único caracter, diferenciando maiúsculas e minúsculas, e o valor é um texto estruturado, cujo formato depende do <tipo>. Em geral, o valor pode ser tanto um número de campos delimitados por um caractere de espaço simples, ou um string de formato livre, e diferencia maiúsculas e minúsculas, a menos que um campo específico defina de outra forma. Espaços em branco NÃO DEVEM ser usados de cada lado do sinal ‘=’.

Uma descrição de sessão SDP consiste em uma seção de caracterização da sessão, seguida por zero ou mais seções de caracterização da mídia. A parte do nível de sessão começa com uma linha "v =" e continua até a primeira seção do nível de mídia. Cada seção do nível de mídia começa com uma linha "m =" e continua até a seção de nível de mídia seguinte, ou o final da descrição da sessão. Em geral os valores no nível de sessão são os defaults para todas as seções de mídia, a menos que sejam substituídos por outro valor equivalente no nível de mídia. Algumas linhas em cada descrição são obrigatórias e outras opcionais, mas todas devem aparecer exatamente na ordem mostrada aqui (a ordem fixa facilita a detecção de erros e permite simplifica o parser). Itens opcionais são marcadas com "*".

 

Aqui está um exemplo de uma descrição de sessão SDP:

 

Muito bem. Acho que isso é suficiente para vocês entenderem como funciona a sinalização NGN. Agora é hora de descer um degrau na pilha de protocolos TCP/IP, portanto, em nosso próximo artigo vamos começar a falar sobre os protocolos de transporte, e vamos entender como a API de socket é usada para criar sessões separadas sobre o serviço dos protocolos de transporte.

Au revoir, mes amis.