Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


17.2.3 Conferindo Requisições às Transações Servidor

Quando uma requisição for recebida da rede pelo servidor, ela tem que ser conferida com uma transação existente. Isso é realizado da seguinte maneira.

O parâmetro branch no campo-cabeçalho Via mais alto da requisição é examinado. Se ele estiver presente e começa com o cookie mágico "z9hG4bK", a requisição foi gerada por uma transação cliente em conformidade com essa especificação. Portanto, o parâmetro branch será único ao longo de todas das transações enviadas por esse cliente. A requisição confere com uma transação se:

1. o parâmetro branch na requisição for igual àquele no campo-cabeçalho Via superior da requisição que criou a transação, e 

2. o valor sent-by no Via superior da requisição for igual àquele na requisição que criou a transação, e 

3. o método da requisição conferir com aquele criou a transação, exceto para ACK, onde o método da requisição que criou a transação for o INVITE.

Essa regra que confere aplica-se às transações tanto INVITE quanto não-INVITE de forma análoga.

O valor sent-by é usado como parte do processo de conferência, porque poderia haver duplicação acidental ou maliciosa de parâmetros branch de diferentes clientes.

Se o parâmetro branch no campo-cabeçalho Via superior não estiver presente, ou não contiver o cookie mágico, os procedimentos seguintes são usados. Esses existem para lidar com a retro-compatibilidade das implementações em conformidade com a RFC 2543.

A requisição INVITE confere com uma transação se o Request-URI, o tag de To, o tag de From, Call-ID, CSeq e o campo-cabeçalho Via superior conferem com aqueles da requsição INVITE que criou a transação. Neste caso, o INVITE é uma retransmissão do original que criou a transação. A requisição ACK confere com uma transação se o Request-URI, o tag de From, Call-ID, número de CSeq (e não o método) e o campo-cabeçalho Via superior confere com aqueles da requsição INVITE que criou a transação, e o tag de To do ACK confere com o tag de To da resposta enviada pela transação servidor. A Confência é feita baseada nas regras de confência definidas para cada um desses campos-cabeçalho. Inclusão do tag no campo-cabeçalho To no processo de conferência do ACK ajuda eliminar ambigüidade dos ACK para 2xx e dos ACK para outras respostas 



Rosenberg, et. al.          Standards Track                   [Página 138]

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.