RFC 3261 SIP: Session Initiation Protocol Junho 2002
18.2 Servidores
18.2.1 Recebendo Requisições
Um servidor DEVE estar preparado para receber requisições em qualquer endereço IP, porta e combinação de transporte que pode ser o resultado de uma consulta DNS em um URI do SIP ou do SIPS [4] que é entregue com propósito de se comunicar com esse servidor. Nesse contexto, o "entregar" inclui colocar um URI em um campo-cabeçalho Contact em requisição REGISTER ou resposta redirect, ou em campo-cabeçalho Record-Route em requisição ou em resposta. Um URI também podem ser "entregue", colocando-o em Página-Web ou cartão de visita. É também recomendado que um servidor escute requisições nas portas padrão SIP (5060 para TCP e UDP, 5061 para TLS sobre o TCP) em todas as interfaces públicas. A exceção típica seria redes privadas, ou quando múltplas instâncias do servidor estão rodando no mesmo host. Para qualquer porta e interface que um servidor escuta no UDP, ele PRECISA escutar nessa mesma porta e interface no TCP. Isso ocorre porque uma mensagem pode necessitar ser enviada usando o TCP, em vez de UDP, se ela for muito grande. Como resultado, o inverso não é verdadeiro. Um servidor não precisa ouvir no UDP em um endereço e porta particulares só porque ele está escutando naquele mesmo endereço e porta no TCP. Pode haver, claro, ser outras razões pelas quais um servidor precisa ouvir no UDP em um endereço e porta particulares.
Quando o transporte servidor recebe uma requisição em qualquer transporte, ele PRECISA examinar o valor do parâmetro "sent-by" no valor do campo-cabeçalho Via superior. Se a parte host do parâmetro "sent-by" contém um nome de domínio, ou se ele contém um endereço IP que difere do endereço origem do pacote, o servidor PRECISA adicionar um parâmetro "received" ao valor desse campo-cabeçalho Via. Esse parâmetro PRECISA conter o endereço origem pelo qual o pacote foi recebido. Isto é para ajudar a camada de transporte do servidor no envio da resposta, uma vez que ela precisa ser enviada ao endereço IP origem pelo qual a requisição veio.
Considere uma requisição recebida pelo transporte do servidor que se parece, em parte:
INVITE sip:bob@Biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060
A requisição é recebida com um endereço IP origem de 192.0.2.4. Antes de passar a requisição pra cima, o transporte adiciona um parâmetro "received", de modo que a requisição se pareceria, em parte:
INVITE sip:bob@Biloxi.com SIP/2.0
Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4
Rosenberg, et. al. Standards Track [Página 145]
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