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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002
Requisições da transação servidor são passados ao núcleo proxy. O núcleo proxy determina para onde rotear a requisição, escolhendo um ou mais locais do próximo salto. Uma requisição sainte para cada local do próximo salto é processada por seu próprio cliente transação associado. O núcleo proxy recolhe as respostas das transações clientes e as usa para enviar as respostas à transação servidor.
Um proxy stateful cria uma nova transação servidor para cada nova requisição recebida. Quaisquer retransmissões da requisição será então tratada por essa transação servidor conforme a Seção 17. O núcleo proxy PRECISA se comportar como um UAS no que diz respeito ao envio de uma provisória imediatamente nessa transação servidor (como 100 Trying), como descrito na Seção 8.2.6. Assim, um proxy stateful NÃO DEVE gerar respostas 100 (Trying) a requisições não-INVITE.
Esse é um modelo de comportamento de proxy, e não de software. Uma implementação é livre para seguir qualquer abordagem que replique o comportamento externo como define esse modelo.
Para todas requisições novas, incluindo quaisquer métodos desconhecidos, um elemento que pretendam proxy-ar a requisição PRECISA:
1. Validar a requisição (Seção 16.3)
2. Pre-processar informação de roteamento (Seção 16.4)
3. Determinar alvo(s) para a requisição (Seção 16.5)
            +--------------------+
            |                    | +---+
            |                    | | C |
            |                    | | T |
            |                    | +---+
      +---+ |       Proxy        | +---+   CT = Transação Cliente
      | S | |  "Higher" Layer    | | C |
      | T | |                    | | T |   ST = Transação Servidor
      +---+ |                    | +---+
            |                    | +---+
            |                    | | C |
            |                    | | T |
            |                    | +---+
            +--------------------+
       Figura 3: Modelo do Proxy Stateful
Rosenberg, et. al.          Standards Track                    [Página 93]


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.