RFC 3261 Português Página 142

RFC 3261 SIP: Session Initiation Protocol Junho 2002

É RECOMENDADO que conexões sejam mantidas abertas por um período definido na implementação após a última mensagem ter sido enviada ou recebida por essa conexão. Essa duração DEVE, pelo menos, ser igual à maior quantidade de tempo que o elemento necessitaria a fim de trazer uma transação da instância ao estado encerrado. Isso deve fazer que transações sejam provavelmente concluídas na mesma conexão que elas foram iniciadas (por exemplo, requsição, resposta, e no caso de INVITE, ACK para respostas não-2xx). Isso geralmente significa, pelo menos, 64*T1 (ver a Seção 17.1.1.1 para definição de T1). No entanto, ele poderia ser maior em um elemento que tem um TU com um valor grande para o temporizador C (destaque 11 da Seção 16.6), por exemplo.

Todos os elementos SIP PRECISAM implementar UDP e TCP. Elementos SIP PODEM implementar outros protocolos.

Tornar o TCP obrigatório ao UA é uma mudança substancial desde a RFC 2543. Isso surgiu da necessidade de lidar com mensagens maiores, que PRECISAM usar o TCP, como discutido abaixo. Assim, mesmo que um elemento nunca envie mensagens grandes, ele pode receber uma e precisa ser capaz de tratá-las.

18.1 Clientes

18.1.1 Enviando Requisições

O lado cliente da camada de transporte é responsável por enviar a requisição e receber respostas. O usuário da camada de transporte passa ao transporte cliente a requisição, um endereço IP, porta, transporte e, possivelmente, TTL para destinos multicast.

Se uma requisição é de 200 bytes do caminho MTU, ou se ela é maior que 1.300 bytes e o caminho MTU for desconhecido, a requsição PRECISA ser enviada usando um protocolo de transporte controlado por congestionamento RFC 2914 [43], como o TCP. Se isso causar uma mudança no protocolo de transporte daquele indicado no Via superior, o valor no Via superior PRECISA ser alterado. Isso evita fragmentação de mensagens sobre o UDP e fornece controle de congestionamento para mensagens maiores. No entanto, as implementações PRECISAM ser capazes de lidar com mensagens até o tamanho máximo do datagrama de pacote. Para o UDP, esse tamanho é 65.535 bytes, incluindo cabeçalhos IP e UDP.

O "buffer" 200 byte entre o tamanho da mensagem e o MTU acomoda o fato de que a resposta em SIP pode ser maior que a requisição. Isso acontece devido à adição de valores ao campo-cabeçalho Record-Route nas respostas a INVITE, por exemplo. Com o buffer extra, a resposta pode ser em torno de 170 bytes maior que a requisição, e ainda não ser fragmentado no IPv4 (cerca de 30 bytes

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

Página Anterior

Tabela de Conteúdo

Página Seguinte



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.