RFC 3261 SIP: Session Initiation Protocol Junho 2002
21.3 Redirection 3xx
Respostas 3xx fornecem informação sobre a nova localização do usuário, ou sobre serviços alternativos que pode ser capaz de satisfazer a chamada.
21.3.1 300 Multiple Choices
O endereço na requisição resolvido para várias escolhas, cada um com sua localização específica, e o usuário (ou UA) pode selecionar um ponto final preferido de comunicação e redirecionar a sua requisição a esse local.
A resposta PODE incluir um corpo de mensagem contendo uma lista de características e localização(s) de recursos a partir do qual o usuário ou UA pode escolher aquele mais adequado, se permitido pelo campo-cabeçalho Accept da requisição. No entanto, nenhum tipo MIME foi definido para esse corpo da mensagem.
As escolhas DEVEM ser também listadas como campos Contact (Seção 20.10). Ao contrário do HTTP, a resposta SIP PODE conter vários campos Contact ou uma lista de endereços em um campo Contact. UA's PODEM usar o valor do campo-cabeçalho Contact para redirecionamento automático, ou PODEM pedir ao usuário para confirmar a escolha. No entanto, essa especificação não define nenhum Padrão para tal seleção automática.
Esse status resposta é adequado se a parte chamada pode ser alcançada em várias localizações diferentes e o servidor não pode ou prefere não proxy-ar a requisição.
21.3.2 301 Moved Permanently
O usuário não pode mais ser encontrado no endereço indicado no Request-URI, e o cliente requsitante DEVE re-tentar o novo endereço fornecido pelo campo-cabeçalho Contact (Seção 20.10). O requsitante DEVE atualizar todos os diretórios locais, agendas, caches de localização do usuário com esse novo valor e redirecionar as requisições futuras para o endereço(s) listados.
21.3.3 302 Moved Temporarily
O cliente requisitante DEVE re-tentar a requisição no novo endereço(s) fornecido pelo campo-cabeçalho Contact (Seção 20.10). O Request-URI da nova requisição usa o valor do campo-cabeçalho Contact na resposta.
Rosenberg, et. al. Standards Track [Página 184]
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.
Nenhum comentário:
Postar um comentário