Estabelecendo uma Sessão SIP

A transação mais importante do protocolo SIP é a transação INVITE. A mensagem INVITE é que estabelece as sessões SIP. Nesta seção, será descrito um cenário típico da transação INVITE. Neste cenário, existirão dois terminais SIP, dois proxies e dois servidores de registro, um para cada domínio SIP. A Figura 15 mostra este cenário.

Antes de descrevermos a transação INVITE, vamos supor que os terminais já efetuaram o registro conforme a seção anterior. O Terminal SIP 1 solicitou o registro do endereço SIP davison@hamal.mc21.fee.unicamp.br. O Terminal SIP 2 solicitou o registro do endereço SIP meireang@igniscom.com.br. Ainda neste cenário, nota-se que os proxies e os servidores de registro estão em um mesmo equipamento de rede.

A negociação inicia-se quando o Terminal SIP 1 cria a mensagem INVITE. Esta mensagem pode ser criada por algum estímulo externo, como por exemplo, quando um usuário de um aplicativo clica em algum item que inicia uma sessão de áudio SIP. A mensagem INVITE deverá ser como mostra a Figura 16.

Os campos Via, Max-Forwards, CSeq e o Content-Length têm a mesma função que na mensagem REGISTER. O campo To contém o endereço SIP do destinatário da requisição. Ele também contém uma string com o nome do destinatário da mensagem. Da mesma forma, o campo From também contém uma string com o nome do usuário do Terminal SIP 1 e o seu endereço SIP. Este campo também contém um parâmetro

chamado tag, cujo valor é uma string gerada pseudoaleatoriamente que é adicionada no Terminal SIP 1.

Figura 15. Cenário da transação INVITE

Este tag serve para identificação da chamada. O campo Call-ID contém um identificador para esta chamada. O campo Contact contém um endereço SIP no qual o usuário do Terminal 1 pode ser acessado diretamente. O campo Content-Type contém uma descrição do corpo da mensagem.

Servidor de Registros e o Proxy do domínio hamal.mc21.fee.unicamp.br

Terminal SIP 1

davison@hamal.mc21.fee.unicamp.br _{meireang@igniscom.com.br}Terminal SIP 2 Servidor de Registros e o Proxy do domínio

igniscom.com.br INVITE INVITE INVITE 100 Trying 180 Ringing 200 Ok 100 Trying 180 Ringing 200 Ok 180 Ringing 200 Ok ACK FLUXO DE MÍDIA BYE 200 Ok

INVITE sip:meireang@igniscom.com.br SIP/2.0

Via: SIP/2.0/UDP regulus.mc21.fee.unicamp.br:5060;branch=z9hG4knib74u Max-Forwards: 70

To: Meire Angelica Ferreira <sip:meireang@igniscom.com.br>

From: Davison Gonzaga da Silva <sip:davison@hamal.mc21.fee.unicamp.br>;tag=487jni9 Call-ID: j94nbgh46yu48nbfi CSeq: 7982 INVITE Contact: <sip:davison@regulus.mc21.fee.unicamp.br> Content-Type: application/sdp Content-Length: 142 v=0 o=davison 165468471 216549871332 IN IP4 143.106.50.80 s=audio call u=http://www.mc21.fee.unicamp.br e=davison@decom.fee.unicamp.br c=IN IP4 143.106.50.80/7000 t=0 0 m=audio 7000 udp 0

Figura 16. Mensagem INVITE enviada pelo Terminal SIP 1

Após a criação da mensagem, o Terminal SIP 1 envia a mensagem para o Proxy responsável pelo seu domínio. Uma vez que o Terminal SIP 1 não sabe o endereço final do Terminal SIP 2, ele envia a mensagem para o seu Proxy de domínio, isto é, o Proxy 1. O Proxy 1 recebe a requisição e a envia para o Proxy 2 como se fosse o requisitante e responde para o Terminal SIP 1 com uma mensagem 100 Trying, indicando que o Proxy 1 está tentando localizar o destinatário daquela mensagem. A mensagem 100 Trying é como mostra a Figura 17.

SIP/2.0 100 Trying

Via: SIP/2.0/UDP regulus.mc21.fee.unicamp.br:5060;branch=z9hG4knib74u; received=143.106.50.80

Max-Forwards: 69

To: Meire Angelica Ferreira <sip:meireang@igniscom.com.br>

From: Davison Gonzaga da Silva <sip:davison@hamal.mc21.fee.unicamp.br>;tag=487jni9 Call-ID: j94nbgh46yu48nbfi

CSeq: 7982 INVITE Content-Length: 0

Figura 17. Resposta 100 Trying enviada pelo Proxy 1

O Proxy 1, antes de enviar a requisição para o Proxy 2, adiciona um campo Via na mensagem INVITE. A nova mensagem INVITE fica como mostra a Figura 18.

INVITE sip:meireang@igniscom.com.br SIP/2.0

Via: SIP/2.0/UDP hamal.mc21.fee.unicamp.br:5060;branch=z9hG4k70bneoijb94 Via: SIP/2.0/UDP regulus.mc21.fee.unicamp.br:5060;branch=z9hG4knib74u; received=143.106.50.80

Max-Forwards: 70

To: Meire Angelica Ferreira <sip:meireang@igniscom.com.br>

From: Davison Gonzaga da Silva <sip:davison@hamal.mc21.fee.unicamp.br>;tag=487jni9 Call-ID: j94nbgh46yu48nbfi CSeq: 7982 INVITE Contact: <sip:davison@regulus.mc21.fee.unicamp.br> Content-Type: application/sdp Content-Length: 142 v=0 o=davison 165468471 216549871332 IN IP4 143.106.50.80 s=audio call u=http://www.mc21.fee.unicamp.br e=davison@decom.fee.unicamp.br c=IN IP4 143.106.50.80/7000 t=0 0 m=audio 7000 udp 0

Figura 18. Mensagem INVITE enviada pelo Proxy 1

Isto é feito para que a mensagem de resposta a esta requisição possa passar pelo mesmo caminho que a requisição e os Proxies possam completar as suas transações abertas. O Proxy 2 recebe a mensagem INVITE e responde com uma resposta 100 Trying para o Proxy 1. O Proxy 2, então, consulta o seu Servidor de Registros para tentar descobrir o endereço IP de meireang@igniscom.com.br. O Proxy 2 encontra o endereço IP do Terminal SIP 2, adiciona um campo Via na requisição com o seu endereço, e envia a mensagem para o Terminal SIP 2.

O Terminal SIP 2 recebe a mensagem INVITE e alerta a Meire do recebimento da mensagem, perguntando se ela deseja aceitar ou não a mensagem. Ao mesmo tempo, responde com uma mensagem 180 Ringing, indicando para o Terminal SIP 1 que o Terminal SIP 2 recebeu a mensagem e que está aguardando uma resposta da Meire. Neste cenário, a Meire resolve aceitar a chamada. Então, o Terminal SIP 2 responde com uma resposta 200 Ok, contendo o corpo da mensagem SDP com o parâmetro de mídia que será estabelecido com o Terminal SIP 1, como mostra a Figura 19.

SIP/2.0 200 Ok

Via: SIP/2.0/UDP igniscom.com.br:5060;branch=z9hG4knvoin0485604; received=143.106.56.200

Via: SIP/2.0/UDP hamal.mc21.fee.unicamp.br:5060;branch=z9hG4k70bneoijb94; received=143.106.50.69

Via: SIP/2.0/UDP regulus.mc21.fee.unicamp.br:5060;branch=z9hG4knib74u; received=143.106.50.80

Max-Forwards: 70

To: Meire Angelica Ferreira <sip:meireang@igniscom.com.br>;tag=bniehb496cv

From: Davison Gonzaga da Silva <sip:davison@hamal.mc21.fee.unicamp.br>;tag=487jni9 Call-ID: j94nbgh46yu48nbfi CSeq: 7982 INVITE Contact: <sip:davison@regulus.mc21.fee.unicamp.br> Content-Type: application/sdp Content-Length: 142 v=0 o=meireang 165468471 216549871332 IN IP4 143.106.50.80 s=audio call u=http://www.mc21.fee.unicamp.br e=meireang@decom.fee.unicamp.br c=IN IP4 143.106.56.193/7000 t=0 0 m=audio 7000 udp 0

Figura 19. Resposta enviada pelo Terminal SIP 2

Após a criação da resposta, o Terminal SIP 2 envia a mensagem de resposta, que passará pelos dois Proxies até chegar ao Terminal SIP 1. Note que a resposta 200 Ok adiciona um tag ao campo To. Isto é feito para que o Terminal SIP 1 crie as peças de um

Diálogo. O Diálogo é um conjunto de informações que identificam os Terminais SIP

envolvidos em uma sessão. Estas informações compreendem os valores dos tag dos campos To e From, do valor do campo Call-ID da requisição, do valor do CSeq da requisição, dos valores dos campos To, From e Contact. Após a criação do diálogo por ambas as partes, as mensagens subseqüentes são trocadas diretamente entre os Terminais SIP. Além disto, as informações contidas nas variáveis armazenadas no Diálogo são utilizadas para gerar as mensagens dentro do Diálogo estabelecido. Quando o Terminal SIP 1 recebe a mensagem de resposta, ele responde com uma mensagem ACK, confirmando o recebimento da resposta 200 Ok e dizendo para o Terminal SIP 2 inicia o fluxo de áudio. O recebimento da resposta 200 Ok faz também que o Terminal SIP 1 estabeleça o diálogo e inicialize o fluxo de áudio. A mensagem ACK é como mostra a Figura 20.

ACK sip:meireang@ignis5.igniscom.com.br SIP/2.0

Via: SIP/2.0/UDP regulus.mc21.fee.unicamp.br:5060;branch=z9hG4knib74u Max-Forwards: 70

To: Meire Angelica Ferreira <sip:meireang@igniscom.com.br>;tag=bniehb496cv

From: Davison Gonzaga da Silva <sip:davison@hamal.mc21.fee.unicamp.br>;tag=487jni9 Call-ID: j94nbgh46yu48nbfi

CSeq: 7982 ACK

Contact: <sip:davison@regulus.mc21.fee.unicamp.br> Content-Length: 0

Figura 20. Mensagem ACK enviada pelo Terminal SIP 1

Durante a sessão INVITE, ou o Terminal SIP 1 ou o Terminal SIP 2 podem querer mudar os parâmetros da sessão. Isto é feito enviando-se um INVITE contendo os novos parâmetros que descrevem a mídia. Esta mensagem INVITE contém várias informações da mensagem INVITE anterior. Caso o outro Terminal aceite os novos parâmetros, ele responde com um 200 Ok para aceitar a mudança. O requisitante, então, responde com um ACK. Se a outra parte não desejar aceitar a mudança, ela responde com uma resposta de erro, como a 406 (Not Acceptable), que também recebe um ACK. Mas, uma falha na negociação de novos parâmetros no meio de uma sessão já estabelecida, não causa a finalização dessa sessão; a sessão continua usando os parâmetros negociados anteriormente.