RFC 3261 Português Página 185 :: Admirável Mundo Novo




Muito Bem Vindo

Prezado Leitor, a proposta desse Blog é compartilhar conhecimento com as pessoas que trabalham com Linux, Asterisk, OpenSER, e com tecnologia de voz sobre a rede IP em geral, através de tutoriais, dicas, howto, notícias entre outros assuntos.

Atente para termo de uso do conteúdo do blog no rodapé da página.

domingo, 10 de julho de 2011

RFC 3261 Português Página 185

RFC 3261            SIP: Session Initiation Protocol           Junho 2002
A duração da validade do URI de Contact pode ser indicado através de um campo-cabeçalho Expires (Seção 20.19) ou um parâmetro expires no campo-cabeçalho Contact. Ambos os proxy's e UA's PODEM cache-ar esse URI para duração de tempo de expiração. Se não houver tempo de expiração explícito, o endereço é válido apenas uma vez para recursing, e NÃO PODE ser armazenado em cache para futuras transações.
Se o URI cache-ado do campo-cabeçalho Contact falhar, o Request-URI da requisição redirecionada PODE ser tentado de novo uma única vez.
O URI temporário pode ter ficado desatualizado mais cedo que o tempo de expiração, e um novo URI temporário pode estar disponível.
21.3.4 305 Use Proxy
O recurso requisitado PRECISA ser acessado pelo proxy fornecido pelo campo Contact. O campo Contact dá o URI do proxy. O destino deverá repetir essa única requisição via o proxy. Respostas 305 (Use Proxy) PRECISAM ser só geradas pelo UAS's.
21.3.5 380 Alternative Service
A chamada não foi bem sucedida, mas serviços alternativos são possíveis.
Os serviços alternativos são descritos no corpo da mensagem da resposta. Formatos tais corpos não são definidos aqui, e podem ser o assunto de normatização futura.
21.4 Request Failure 4xx
Respostas 4xx são respostas de falhas definitivas de um servidor particular. O cliente NÃO DEVE re-tentar a mesma requisição sem modificação (por exemplo, adicionar autorização apropriada). Contudo, a mesma requisição a um servidor diferente pode ser bem sucedido.
21.4.1 400 Bad Request
A requisição não pode ser entendida devido à sintaxe malformada. A Reason-Phrase DEVE identificar o problema de sintaxe em mais detalhes, por exemplo, "Missing Call-ID header field".
21.4.2 401 Unauthorized
A requisição exige autenticação do usuário. Essa resposta é lançada por UAS's e registradores, enquanto 407 (Proxy Authentication Required) é usado por servidores proxy.
Rosenberg, et. al.          Standards Track                   [Página 185]


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:




Creative Commons License
Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP
by Cléviton Mendes de Araújo is licensed under a Creative Commons Atribuição 2.5 Brasil License.