RFC 3261 Português Página 84

RFC 3261 SIP: Session Initiation Protocol Junho 2002

contém um session id e número de versão no campo origin (o). Se o usuário já for um membro da sessão, e os parâmetros da sessão contidos na descrição da sessão foram alterados, o UAS PODE silenciosamente aceitar o INVITE (isto é, envia uma resposta 2xx sem perguntar ao usuário).

Se o INVITE não contiver uma descrição de sessão, o UAS está sendo convidado para participar de uma sessão, e o UAC tem pedido que o UAS forneça o oferta da sessão. Ele PRECISA fornecer o oferta em sua primeira mensagem de não-falha confiável de volta ao UAC. Nessa especificação, essa é uma resposta 2xx ao INVITE.

O UAS pode indicar o progresso, o aceite, o redireciona ou rejeita o convite. Em todos esses casos, ele formula uma resposta usando os procedimentos descritos na Seção 8.2.6.

13.3.1.1 Progresso

Se o UAS não for capaz de responder o convite de imediato, ele pode escolher indicar algum tipo de progresso ao UAC (por exemplo, uma indicação que o telefone está tocando). Isso é conseguido com uma resposta provisória entre 101 e 199. Essas respostas provisórias estabelecem diálogos early's e, portanto, seguir os procedimentos da Seção 12.1.1 para além daqueles da Seção 8.2.6. Um UAS pode enviar tantas respostas provisórias quantas ele queira. Cada uma dessas PRECISA indicar o mesmo diálogo ID. Contudo, essas não serão entregues de forma confiável.

Se o UAS desejar um período de tempo extendido para responder ao INVITE, ele precisará pedir uma "extension" para evitar proxy's de cancelar a transação. Um proxy tem a opção de cancelar uma transação quando houver uma lacuna de três minutos entre respostas em uma transação. Para evitar o cancelamento, o UAS PRECISA enviar uma resposta provisória não-100 a cada minuto, para tratar a possibilidade de perdas de respostas provisórias.

Uma transação INVITE pode continuar por longos períodos quando o usuário é colocado em espera, ou quando se interconectando com sistemas PSTN que permitem as comunicações ocorrer sem o atendimento da chamada. Essa última é comum em sistemas Interactive Voice Response (IVR).

13.3.1.2 O INVITE é Redirecionado

Se o UAS decide redirecionar a chamada, uma resposta 3xx é enviada. Uma resposta 300 (Multiple Choices), 301 (Moved Permanently) ou 302 (Moved Temporarily) DEVE conter um campo-cabeçalho Contact

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

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.