RFC 3261 Português Página 79

RFC 3261 SIP: Session Initiation Protocol Junho 2002

Um campo-cabeçalho Accept (Seção 20.1) PODE estar presentes no INVITE. Ele indica quais Content-Types são aceitáveis pelo UA, em ambos a resposta recebida por ele, e em todas requisições subsequentes enviadas dentro de diálogos estabelecidos pelo INVITE. O campo-cabeçalho Accept é especialmente útil para indicar suporte a vários formatos de descrição de sessão.

O UAC PODE adicionar um campo-cabeçalho Expires (Seção 20.19) para limitar a validade do convite. Se o tempo indicado no campo-cabeçalho Expires for alcançado e nenhuma resposta final ao INVITE foi recebida, o núcleo do UAC DEVE gerar uma requisição CANCEL ao INVITE, conforme a Seção 9.

Um UAC PODE também achar que é útil acrescentar, entre outros, os campos-cabeçalhos Subject (Seção 20.36), Organization (Seção 20.25) e User-Agent (Seção 20.41). Todos eles contêm informações relacionadas ao INVITE.

O UAC PODE escolher adicionar um corpo de mensagem ao INVITE. A Seção 8.1.1.10 trata como construir os campos-cabeçalhos -- Content-Type, entre outros -- necessários para descrever o corpo da mensagem.

Existem regras especiais para corpos de mensagem que contêm uma descrição de sessão - seu Content-Disposition correspondente é "session". O SIP usa um modelo oferta/aceite onde um UA envia uma descrição de sessão, chamada a oferta, que contém uma descrição da sessão proposta. A oferta indica os meios de comunicação desejados (áudio, vídeo, jogos), parâmetros desses meios (como tipos de codec) e endereços para receber media do respondente. O outro UA responde com outra descrição de sessão, chamada aceite, que indica quais meios de comunicação são aceitos, parâmetros que se aplicam a esses meios, e endereços para receber mídia do ofertante. Uma troca oferta/aceite está dentro do contexto de um diálogo, de sorte que se um INVITE do SIP resultar em múltiplos diálogos, cada um é uma troca oferta/aceite separada. O modelo oferta/aceite define restrições a cerca de quando ofertas e aceites podem ser feitas (por exemplo, você não pode fazer uma nova oferta, enquanto uma está em progresso). Isso resulta em restrições sobre quando ofertas e aceites podem aparecer em mensagens SIP. Nessa especificação, ofertas e aceites só podem aparecer em requisições INVITE e respostas, e ACK. O uso de ofertas e aceites é mais restrito. Para a transação INVITE inicial, as regras são:

o O offer inicial PRECISA estar tanto em um INVITE, se não houver, quanto na primeira mensagem confiável de não-falha do UAS de volta ao UAC. Nessa especificação, essa é a resposta final 2xx.

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

Página Anterior

Tabela de Conteúdo

Página Seguinte



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.