RFC 3261 Português Página 63 :: 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.

segunda-feira, 11 de julho de 2011

RFC 3261 Português Página 63

RFC 3261            SIP: Session Initiation Protocol          Junho 2002
Se a camada de transação retorna um erro de timeout porque o REGISTER não produziu nenhuma resposta, o UAC NÃO DEVE tentar de novo imediatamente, um pedido de registro ao mesmo registrador.
Uma nova tentativa imediata provavelmente também resultará em timeout. Esperar algum intervalo de tempo razoável para que as condições causadoras do timeout sejam corrigidas reduz carga desnecessária na rede. Nenhum intervalo específico é obrigatório.
10.2.8 Respostas a Erro
Se um UA recebe uma resposta 423 (Interval Too Brief), ele PODE repetir o pedido de registro após fazer o intervalo de expiração para todos endereços de contato na requisição REGISTER igual ou maior que o intervalo de validade dentro do campo-cabeçalho Min-Expires da resposta 423 (Interval Too Brief).
10.3 Processando Requisições REGISTER
Um registrador é um UAS que responde às requisições REGISTER e mantém uma lista de bindings que são acessíveis aos servidores proxy e servidores redirect dentro de seu domínio administrativo. O registrador gerencia requisições de acordo com a Seção 8.2 e a Seção 17.2, mas ele só aceita requisições REGISTER. Um registrador NÃO PODE gerar respostas 6xx.
Um registrador PODE redirecionar requisições REGISTER quando apropriado. Um uso comum seria um registrador escutar em uma interface multicast para redirecionar requisições REGISTER multicast à sua própria interface unicast com uma resposta 302 (Moved Temporarily).
Registradores PRECISAM ignorar o campo-cabeçalho Record-Route se ele for incluído em uma requisição REGISTER. Registradores NÃO PODEM incluir um campo-cabeçalho Record-Route em qualquer resposta a uma requisição REGISTER.
Um registrador pode receber uma requisição que atravessou um proxy o qual trata REGISTER como uma requisição desconhecida e o qual adicionou um valor no campo-cabeçalho Record-Route.
Um registrador precisa saber (por exemplo, através da configuração), o conjunto de domínio(s) para os quais ele mantém bindings. Requisições REGISTER PRECISAM ser processadas por um registrador na ordem que elas forem recebidas. Requisições REGISTER também PRECISAM ser processadas atomicamente, o que significa que uma requisição REGISTER particular seja processada completamente ou não. Cada mensagem REGISTER PRECISA ser processada independentemente de qualquer outro pedido de registro ou alterações binding.
Rosenberg, et. al.          Standards Track                    [Página 63]


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.