RFC 3261 Português Página 50

RFC 3261 SIP: Session Initiation Protocol Junho 2002

Quando uma resposta 100 (Trying) for gerada, qualquer campo-cabeçalho Timestamp presente na requisição PRECISA ser copiado para essa resposta 100 (Trying). Se houver um atraso na geração da resposta, o UAS DEVE adicionar um valor de atraso no valor do Timestamp na resposta. Esse valor PRECISA conter a diferença entre o tempo de envio da resposta e o tempo da recepção da requisição, mensurado em segundos.

8.2.6.2 Cabeçalhos e Tags

O campo From da resposta PRECISA ser igual ao campo-cabeçalho From da requisição. O campo-cabeçalho Call-ID da resposta PRECISA ser igual ao campo-cabeçalho Call-ID da requisição. O campo-cabeçalho CSeq da resposta PRECISA ser igual ao campo CSeq da requisição. Os valores do campo-cabeçalho Via na resposta PRECISA ser igual aos valores do campo-cabeçalho Via na requisição e PRECISAM manter a mesma ordenação.

Se uma requisição continha uma tag To na requisição, o campo-cabeçalho To na resposta PRECISA ser igual a aquele da requisição. Contudo, se o campo-cabeçalho To na requisição não contém um token tag, a URI no campo-cabeçalho To na resposta PRECISA ser igual a URI no campo-cabeçalho To; adicionalmente, o UAS PRECISA adicionar um token tag ao campo-cabeçalho To na resposta (com exceção da resposta 100 (Trying), na qual um token tag PODE estar presente). Isso serve para identificar o UAS que está respondendo, possivelmente resultando em um componente de um dialog ID. O mesmo tag PRECISA ser usado em todas as respostas dessa requisição, tanto resposta final quanto resposta provisória (novamente excetuando a resposta 100 (Trying)). Procedimentos para geração de tags estão definidos na Seção 19.3.

8.2.7 Comportamento Stateless de UAS

Um UAS stateless é um UAS que não mantém estado da transação. Ele responde a requisições normalmente, mas ele descarta qualquer estado que normalmente seria mantido por um UAS após uma resposta ter sido enviada. Se um UAS stateless recebe uma retransmissão de uma requisição, ele regenera a resposta e a reenvia, exatamente como se ele estivesse respondendo à primeira instância da requisição. Um UAS não pode ser stateless a menos que o processamento de requisição para esse método sempre resultaria na mesma resposta se as requisições são idênticas. Isto exclui os registradores stateless, por exemplo. UAS's stateless não usam uma camada de transação; pois eles recebem requisições diretamente da camada de transporte e enviar respostas diretamente à camada de transporte.

A função do UAS stateless é necessária principalmente para manipular as requisições não autenticadas a qual uma resposta desafio é lançada. Se requisições não autenticadas foram tratadas como statefully, então inundações maliciosas de requisições não autenticadas poderiam criar quantidades massivas de estado de transação

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

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.