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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


mantido nos proxy's. Isto também tem a propriedade desejável de que cada proxy que vê o INVITE também verá todas as respostas ao INVITE.

Quando softfone de Alice recebe a resposta 180 (Ringing), ele passa essa informação para Alice, talvez usando um tom de áudio ringback ou exibindo uma mensagem na tela de Alice.

Nesse exemplo, Bob decide atender a chamada. Quando ele tira o fone do gancho, o telefone SIP envia uma resposta 200 (OK) para indicar que a chamada foi atendida. A resposta 200 (OK) contém um corpo de mensagem com a descrição SDP da mídia do tipo de sessão que Bob deseja estabelecer com Alice. Como resultado, há uma troca de mensagens SDP em duas fases: Alice enviou uma a Bob, Bob enviou outra de volta para a Alice. Esta troca de duas fases fornece capacidades de negociação básica e é baseado em um modelo simples de oferta/aceite de troca SDP. Se Bob não quiser atender a chamada ou se estiver ocupado com outra chamada, uma resposta de erro seria enviada ao invés da resposta 200 (OK), o que resultaria em nenhuma sessão de mídia estabelecida. A lista completa dos códigos de resposta SIP está na Seção 21. A resposta 200 (OK) (mensagem F9 na Figura 1) pode se parecer com essa que Bob enviou:

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP server10.biloxi.com
         ;branch=z9hG4bKnashds8;received=192.0.2.3
      Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
         ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
      Via: SIP/2.0/UDP pc33.atlanta.com
         ;branch=z9hG4bK776asdhds ;received=192.0.2.1
      To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
      From: Alice <sip:alice@atlanta.com>;tag=1928301774
      Call-ID: a84b4c76e66710@pc33.atlanta.com
      CSeq: 314159 INVITE
      Contact: <sip:bob@192.0.2.4>
      Content-Type: application/sdp
      Content-Length: 131

      (o SDP de Bob não mostrado)


A primeira linha da resposta contém o código resposta (200) e a frase razão (OK). As linhas restantes contêm campos-cabeçalhos. Os campos-cabeçalhos Via, To, From, Call-ID, e CSeq são copiados da requisição INVITE. (Existem três campos-cabeçalhos Via - um adicionado pelo telefone SIP de Alice, um adicionado pelo proxy atlanta.com, e um adicionado pelo proxy biloxi.com). O telefone SIP de Bob adicionou um parâmetro tag ao campo-cabeçalho To. Essa tag será incorporada por ambas as pontas remotas do diálogo e será incluída em todas as requisições e respostas futuras nessa chamada.







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

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.