RFC 3261 SIP: Session Initiation Protocol Junho 2002
PRECISA estar preparado para receber conexões entrantes em qualquer endereço e porta que seriam selecionados por um servidor baseado nos procedimentos descritos na secção 5 de [4].
Para transportes unicast não confiáveis, o transporte cliente PRECISA estar preparado para receber respostas no endereço IP origem pelo qual a requisição foi enviada (como respostas são retornadas ao endereço origem) e a porta no campo "sent-by". Além disso, quanto aos transportes confiáveis, em certos casos a resposta será enviada em qualquer outro. O cliente PRECISA estar preparado para receber as respostas em qualquer endereço e porta que seriam selecionados por um servidor baseado nos procedimentos descritos na Seção 5 do [4].
Para multicast, o transporte cliente PRECISA estar preparado para receber respostas no mesmo grupo multicast e porta no qual a requisição foi enviada (isto é, ele precisa ser um membro do grupo multicast no qual enviou a requisição).
Se uma requisição for destinada a um endereço IP, porta e transporte em que uma conexão existente está aberta, é RECOMENDADO que essa conexão seja usada para enviar a requisição, mas uma outra conexão pode ser aberta e usada.
Se uma requisição for enviada usando multicast, é enviada ao endereço do grupo, porta e TTL fornecidos pelo usuário de transporte. Se uma requisição for enviada usando transportes unicast não confiáveis, é enviado ao endereço IP e porta fornecidos pelo usuário de transporte.
18.1.2 Recebendo Respostas
Quando uma resposta for recebida, o transporte cliente examina o valor do cabeçalho-campo Via superior. Se o valor do parâmetro "sent-by" em que o valor do campo-cabeçalho não corresponde a um valor que o transporte cliente está configurado para inserir em requisições, a resposta PRECISA ser descartada silenciosamente.
Se houverem quaisquer transações cliente existentes, o transporte cliente usa os procedimentos de conferência da Seção 17.1.3 para tentar bater a resposta com uma transação existente. Se houver uma correspondência, a resposta PRECISA ser passada a essa transação. Do contrário, a resposta PRECISA ser passada ao core (seja ele proxy sem estado, proxy stateful, ou UA) para processamento adicional. Manipulação dessas respostas "perdidas" é dependente do núcleo (um proxy as encaminhará, enquanto um UA irá descartar, por exemplo).
Rosenberg, et. al. Standards Track [Página 144]
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.
Nenhum comentário:
Postar um comentário