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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


conferência definidas para cada um desses campos-cabeçalhos. Quando uma requisição não-INVITE corresponde a uma transação existente, é uma retransmissão da requisição que criou essa transação.

Como as regras de conferência incluem o Request-URI, o servidor não pode bate a uma resposta com uma transação. Quando o TU passar uma resposta à transação servidor, ele precisa passá-lo à transação servidor específica à qual a resposta é intencionada.


17.2.4 Tratando Erros de Transporte

Quando a transação servidor envia uma resposta à camada de transporte a ser enviada, os seguintes procedimentos são seguidos se a camada de transporte indica uma falha.

Primeiro, os procedimentos em [4] são seguidos, que tenta entregar a resposta a um backup. Se esses falharem, baseado na definição de falha em [4], a transação servidor DEVE informar ao TU que ocorreu uma falha, e DEVE transitar ao estado encerrado.


18 Transporte

A camada de transporte é responsável pela transmissão real de requisições e respostas sobre transportes da rede. Isto inclui a determinação da conexão a usar para uma requisição ou resposta no caso de transportes orientados à conexão.

A camada de transporte é responsável por gerenciar conexões persistentes para protocolos de transporte como TCP e SCTP​​, ou TLS sobre eles, incluindo aquelas abertas à camada de transporte. Isso inclui conexões abertas por transportes cliente ou servidor, de sorte que conexões são compartilhadas entre as funções de transporte de cliente e de servidor. Essas conexões são indexados pela tupla formada do endereço, porta e o protocolo de transporte na ponta remota da conexão. Quando uma conexão é aberta pela camada de transporte, esse índice é definido com IP, porta, e transporte do destino. Quando a conexão é aceita pela camada de transporte, esse índice é definido como o endereço IP, porta, e transporte de origem. Note que, como a porta de origem ser frequentemente efémera, e não pode ser conhecida se ela é efêmera ou selecionada através dos procedimentos em [4], conexões aceitas pela camada de transporte não serão reusadas com freqüência. O resultado é que dois proxy's com um relacionamento "peering" usando um transporte orientado à conexão com freqüência terão duas conexões em uso, uma conexão para transações iniciadas em cada direção.





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

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.