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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Seguindo, o transporte servidor tenta bater a requisição com uma transação servidor. Ele faz isso usando as regras de conferência descritas na Seção 17.2.3. Se uma transação servidor correspondente for encontrada, a requisição é passada a essa transação para processamento. Se nenhuma correspondência for encontrada, a requisição é passada ao núcleo, que pode decidir construir uma nova transação servidor para essa requisição. Note que quando um núcleo UAS envia uma resposta 2xx ao INVITE, a transação servidor é destruída. Isto significa que quando o ACK chega, não haverá nenhuma transação servidor correspondente, e baseado nessa regra, o ACK é passado ao núcleo UAS, onde é processado.


18.2.2 Enviando Respostas

O transporte servidor usa o valor do campo-cabeçalho Via superior a fim de determinar para onde enviar uma resposta. Ele PRECISA seguir o processo seguinte:

o Se o "sent-protocol" for um protocolo de transporte confiável, como o TCP ou o SCTP​​, ou o TLS sobre aqueles, a resposta PRECISA ser enviada usando a conexão existente com a origem da requisição original que criou a transação, se essa conexão ainda estiver aberta. Isso exige do transporte servidor manter uma associação entre transações servidor e conexões de transporte. Se essa conexão não mais estiver aberta, o servidor DEVE abrir uma conexão com o endereço IP no parâmetro "received", se presente, usando a porta no valor "sent-by", ou a porta padrão para esse transporte, se nenhuma porta for especificada. Se essa tentativa de conexão falhar, o servidor DEVE usar os procedimentos [4] para servidores, a fim de determinar o endereço IP e a porta para abrir a conexão e na qual enviar a resposta.

o Do contrário, se o valor do campo-cabeçalho Via contém um parâmetro "maddr", a resposta PRECISA ser encaminhada ao endereço listado lá, usando a porta indicada em "sent-by", ou a porta 5060 se nenhuma estiver presente. Se o endereço for um endereço multicast, a resposta DEVE ser enviada usando o TTL indicado no parâmetro "ttl", ou com um TTL igual a 1, se esse parâmetro não estiver presente. 

o Caso contrário (para transportes unicast não confiáveis), se o Via superior tiver um parâmetro "received", a resposta PRECISA ser enviada ao endereço constando no parâmetro "received", usando a porta indicada no valor de "sent-by", ou usando a porta 5060 se nenhuma for especificada explicitamente. Se isto falhar, por exemplo, induz uma resposta ICMP "port unreachable", os procedimentos da Seção 5 da [4] DEVE ser usados para determinar para onde enviar a resposta.






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

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.