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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


é consumido pelo IP/UDP, assumindo que não há IPSec). 1300 é escolhido quando o caminho MTU não é conhecido, baseado na suposição de um MTU Ethernet de 1500 byte.

Se um elemento envia uma requisição sobre o TCP por causa dessas restrições de tamanho de mensagem, e que a requisição teria do contrário sido enviada por UDP, se a tentativa de estabelecer a conexão gera tanto um ICMP Protocol Not Supported, ou resulta em TCP reset, o elemento DEVE reenviar a requisição, usando o UDP. Esta é apenas para fornecer retro-compatibilidade com implementações em conformidade com a RFC 2543 que não suportam o TCP. É previsto que esse comportamento será descontinuado em uma revisão futura da presente especificação.

Um cliente que envia uma requisição a um endereço multicast PRECISA adicionar o parâmetro "maddr" ao valor de seu campo-cabeçalho Via contendo o endereço multicast destino, e para o IPv4, DEVE adicionar o parâmetro "ttl" com valor 1. Uso de multicast IPv6 não é definido nessa especificação, e será uma assunto de normatização futura quando surgir a necessidade.

Essas regras resultam em uma limitação proposital de multicast no SIP. Sua função principal é fornecer um serviço "single-hop-discovery-like", entregando uma requisição a um grupo de servidores homogêneos, onde só é necessário para processar a resposta de qualquer um deles. Essa funcionalidade é muito útil ao processar registro. De fato, baseado nas regras de processamento de transações da Seção 17.1.3, a transação cliente vai aceitar a primeira resposta, e ver quaisquer outras como retransmissões porque todas elas contêm o mesmo identificador branch do campo Via.

Antes de uma requisição ser enviada, o transporte cliente PRECISA inserir um valor do campo "sent-by" no campo-cabeçalho Via. Este campo contém um endereço IP ou nome de host e a porta. O uso de FQDN é RECOMENDADA. Esse campo é usado para enviar respostas sob certas condições, descritas a seguir. Se a porta estiver ausente, o valor padrão depende do transporte. É 5060 para UDP, TCP e SCTP, e 5061 para TLS.

Para transportes confiáveis, a resposta é normalmente enviada sobre a conexão em que a requisição foi recebida. Portanto, o transporte cliente PRECISA estar preparado para receber a resposta na mesma conexão usada para enviar a requisição. Sob condições de erro, o servidor pode tentar abrir uma nova conexão para enviar a resposta. Para tratar esse caso, a camada de transporte também PRECISA estar preparada para receber uma conexão entrante no endereço IP origem pelo qual a requisição foi enviada e a porta no campo "sent-by". Ele também 



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

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.