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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


8.2.4 Aplicando Extensões

Um UAS que pretende aplicar alguma extensão quando gerando resposta NÃO PODE fazer assim a menos que suporte para essa extensão seja indicado no campo-cabeçalho Supported na requisição. Se a extensão desejada não for suportada, o servidor DEVE confiar somente na linha base do SIP e quaisquer outras extensões suportadas pelo cliente. Em circunstâncias raras, onde o servidor não pode processar a requisição sem a extensão, o servidor PODE enviar uma resposta 421 (Extension Required). Essa resposta indica que a resposta adequada não pode ser gerada sem o suporte de uma extensão específica. A(s) extens(ões) necessária(s) PRECISAM ser incluída em um campo-cabeçalho Require na resposta. Esse comportamento NÃO É RECOMENDADO, pois geralmente afetará a interoperabilidade.

Todas as extensões aplicadas a uma resposta não-421 PRECISAM ser listadas em um campo-cabeçalho Require incluído na resposta. Claro, o servidor NÃO PODE aplicar extensões não listadas no campo-cabeçalho Supported na requisição. Como resultado disso, o campo-cabeçalho Require em uma resposta sempre conterá tags de opção somente definida nas RFC's em vias de padronização.


8.2.5 Processando a Requisição

Assumindo que todos as verificações nas subseções anteriores são passadas, o processamento do UAS torna-se específico do método. A Seção 10 cobre a requisição REGISTER, a Seção 11 cobre a requisição OPTIONS, a Seção 13 cobre a requisição INVITE, e a Seção 15 cobre a requisição BYE.>


8.2.6 Gerando a Resposta

Quando um UAS deseja construir uma resposta a uma requisição, ele segue os procedimentos gerais detalhados nas subseções seguintes. Comportamentos adicionais específicos ao código de resposta em questão, os quais não estão detalhados nessa seção, também podem ser necessários.

Uma vez que todos procedimentos associados à geração de uma resposta tenham sido concluídos, o UAS entrega a resposta de volta à transação servidor a partir da qual recebeu a requisição.


8.2.6.1 Enviando uma Resposta Provisional

Uma forte orientação não-específica-de-método para geração de respostas é que UAS's NÃO DEVEM lança uma resposta provisória a uma requisição não-INVITE. Pelo contrário, UAS's DEVEM gerar uma resposta final a uma requisição não-INVITE o mais rapidamente possível.




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

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.