RFC 3261 SIP: Session Initiation Protocol Junho 2002
21.4.21 483 Too Many Hops
O servidor recebeu uma requisição que contém um campo-cabeçalho Max-Forwards (Seção 20.22) com o valor zero.
21.4.22 484 Address Incomplete
O servidor recebeu uma requisição com um Request-URI que estava incompleto. Informação adicional DEVE ser fornecida na frase razão.
Esse código status permite a discagem sobreposta. Com a discagem sobreposta, o cliente não sabe o comprimento da string de discagem. Ele envia strings de tamanho crescente, pedindo ao usuário por mais entrada, até que não mais receba uma resposta status 484 (Address Incomplete).
21.4.23 485 Ambiguous
O Request-URI estava ambíguo. A resposta PODE conter uma lista de possíveis endereços inequívoca no cabeçalho-campos Contact. Ao revelar alternativas podem violar a privacidade do usuário ou da organização. PRECISA ser possível configurar um servidor para responder com status 404 (Not Found) ou para suprimir a lista de escolhas possíveis para Request-URI's ambíguos.
Exemplo de resposta a uma requisição com o Request-URI sip:lee@example.com:
SIP/2.0 485 Ambiguous
Contact: Carol Lee <sip:carol.lee@example.com>
Contact: Ping Lee <sip:p.lee@example.com>
Contact: Lee M. Foote <sips:lee.foote@example.com>
Alguns sistemas de e-mail e de voicemail fornecem essa funcionalidade. Um código status separado de 3xx é usado porque a semântica é diferente: para 300, é assumido que a mesma pessoa ou serviço será alcançado pelas escolhas fornecidas. Enquanto uma escolha automática ou busca seqüencial faz sentido para uma resposta 3xx, a intervenção do usuário é exigida a uma resposta 485 (Ambiguous).
21.4.24 486 Busy Here
O sistema fim da parte chamada foi contactado com sucesso, mas o chamado no momento não está disposto ou capaz de atender chamadas adicionais nesse sistema fim. A resposta PODE indicar um melhor momento a chamar no campo-cabeçalho Retry-After. O usuário pode também estar disponível
Rosenberg, et. al. Standards Track [Página 189]
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