RFC 3261 SIP: Session Initiation Protocol Junho 2002
21.5.7 513 Message Too Large
O servidor foi incapaz de processar a requisição porque o tamanho da mensagem excedeu suas capacidades.
21.6 Global Failures 6xx
Respostas 6xx indicam que um servidor tem informação definitiva sobre um usuário particular, e não apenas a instância particular indicada no Request-URI.
21.6.1 600 Busy Everywhere
O sistema fim do receptor foi contactado com êxito, mas o receptor está ocupado e não deseja atender a chamada nesse momento. A resposta PODE indicar um melhor momento a chamar no campo-cabeçalho Retry-After. Se o receptor não quer revelar a razão por declinar a chamada, o receptor usa código status 603 (Decline) em vez desse. Essa resposta status é retornada só se o cliente sabe que nenhum outro endpoint (como um sistema voicemail) vai responder a requisição. Do contrário, 486 (Busy Here) deve ser retornado.
21.6.2 603 Decline
Máquina do receptor foi contactada com sucesso, mas o usuário explicitamente não quer ou não pode participar. A resposta PODE indicar um momento melhor a chamar no campo-cabeçalho Retry-After. Esta resposta status é retornado só se o cliente sabe que nenhum outro endponit vai atender a requisição.
21.6.3 604 Does Not Exist Anywhere
O servidor tem informação autorizativa que o usuário indicado no Request-URI não existe em nenhum lugar.
21.6.4 606 Not Acceptable
O agente do usuário foi contatado com êxito, mas alguns aspectos da descrição da sessão, como a mídia requisitada, largura de banda ou estilo de endereçamento eram não aceitáveis.
Uma resposta 606 (Not Acceptable) significa que o usuário deseja se comunicar, mas não pode suportar adequadamente a sessão descrita. A resposta 606 (Not Acceptable) PODE conter uma lista de razões em um campo-cabeçalho Warning que descreve o porque a sessão descrita não pode ser suportada. Códigos razão de aviso estão listados na Seção 20.43.
Rosenberg, et. al. Standards Track [Página 192]
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