Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


U1 envia:

      INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0
      Contact: <sip:caller@u1.leftprivatespace.com>

P1 usa seu serviço de localização e envia o seguinte a U2:

      INVITE sip:callee@rightprivatespace.com SIP/2.0
      Contact: <sip:caller@u1.leftprivatespace.com>
      Record-Route: <sip:gateway.rightprivatespace.com;lr>

U2 devolve essa 200 (OK) a P1:

      SIP/2.0 200 OK
      Contact: <sip:callee@u2.rightprivatespace.com>
      Record-Route: <sip:gateway.rightprivatespace.com;lr>

P1 reescreve seu parâmetro no campo-cabeçalho Record-Route para fornecer um valor que U1 achará útil, e envia o seguinte a U1:

      SIP/2.0 200 OK
      Contact: <sip:callee@u2.rightprivatespace.com>
      Record-Route: <sip:gateway.leftprivatespace.com;lr>

Depois, U1 envia a requisição seguinte BYE a P1:

      BYE sip:callee@u2.rightprivatespace.com SIP/2.0
      Route: <sip:gateway.leftprivatespace.com;lr>

que P1 encaminha para U2 como:

      BYE sip:callee@u2.rightprivatespace.com SIP/2.0


17 Transações

O SIP é um protocolo transacional: interações entre os componentes ocorrem em uma série de troca de mensagens independente. Especificamente, uma transação SIP consiste de uma única requisição e todas as respostas a essa requisição, que incluem zero ou mais respostas provisórias e uma ou mais respostas finais. No caso de uma transação quando a requisição for um INVITE (conhecido como transação INVITE), a transação também inclui o ACK somente se a resposta final não for uma resposta 2xx. Se a resposta for uma 2xx, o ACK não é considerado parte da transação.

A razão para esta separação está enraizada na importância de entregar todas as respostas 200 (OK) a um INVITE ao UAC. Para entregá-las todas ao UAC, a UAS só assume a responsabilidade 




Rosenberg, et. al.          Standards Track                   [Página 122]

Observações importantes a cerca dessa tradução:
A tradução de algumas terminologias do SIP:

User agent ficou como agente-usuário;
Header field como campo-cabeçalho;
Requests ficou em português como requisições no plural e no singular requisição.

Quanto às palavras/verbos usadas em documentos RFC's tramitando em trilha de 
padronizações, que obedecem as regras da RFC 2119/IETF, foram traduzidas
para o português conforme a seguir:

MUST:
  PRECISA, REQUERER, OBRIGAR, EXIGIR, FORÇAR, É OBRIGATÓRIO, É FORÇOSO, 
  NECESSITAR, É MANDATÓRIO.

MUST NOT:
  NÃO PODE, É PROIBIDO, É VEDADO.

SHOULD:
  DEVE, É RECOMENDADO.

SHOULD NOT:
  NÃO DEVE, NÃO É RECOMENDADO.

MAY:
  PODE, É OPCIONAL.