RFC 3261 SIP: Session Initiation Protocol Junho 2002exemplo) é transportada pela mensagem SIP de um modo que é análogo a um documento anexo sendo transportado por uma mensagem de e-mail ou uma página Web sendo transportada em uma mensagem HTTP.Como o softfone não sabe a localização do Bob ou servidor SIP no domínio biloxi.com, o softphone envia o INVITE ao servidor SIP, que serve ao domínio de Alice, atlanta.com. O endereço do servidor SIP atlanta.com poderia ser configurado no softfone de Alice, ou poderia ser descoberto por DHCP, por exemplo.O servidor SIP atlanta.com é um tipo de servidor SIP conhecido como servidor proxy. Um servidor proxy recebe requisições SIP e as encaminha em nome do requisitante. Nesse exemplo, o servidor proxy recebe a requisição INVITE e envia uma resposta 100 (Trying) de volta ao softfone de Alice. A resposta 100 (Trying) indica que o INVITE foi recebido e que o proxy está trabalhando em seu nome para rotear o INVITE ao destino. Respostas no SIP usam um código de três dígitos seguido por uma frase descritiva. Essa resposta contém os mesmos campos-cabeçalhos To, From, Call-ID, CSeq e parâmetro branch no Via que do INVITE, o que permite ao softfone de Alice correlacionar essa resposta com o INVITE enviado. O servidor proxy atlanta.com localiza o servidor proxy em biloxi.com, possivelmente executando um tipo particular de consulta DNS (Domain Name Service) para localizar o servidor SIP que serve ao domínio biloxi.com. Isso é descrito em [4]. Como resultado, ele obtém o endereço IP do servidor proxy biloxi.com e encaminha, ou proxy's, a requisição INVITE pra lá. Antes de encaminhar a requisição, o servidor proxy atlanta.com adiciona um valor adicional no campo-cabeçalho Via que contém o seu próprio endereço (o INVITE já contém o endereço de Alice no primeiro campo-cabeçalho Via). O servidor proxy biloxi.com recebe o INVITE e responde com uma resposta 100 (Trying) de volta para o servidor proxy atlanta.com para indicar que recebeu o INVITE e está processando a requisição. O servidor proxy consulta uma base de dados, genericamente chamada de serviço de localização, que contém o endereço IP atual de Bob. (Nós veremos na próxima seção como essa base de dados pode ser preenchido). O servidor proxy biloxi.com adiciona um outro valor no campo-cabeçalho Via com seu próprio endereço no INVITE e proxyeia-o ao telefone SIP de Bob.O Telefone SIP de Bob recebe o INVITE e alerta Bob para a chamada entrante de Alice de sorte que Bob pode decidir se atender a chamada, ou seja, o telefone de Bob soa. O telefone SIP de Bob indica isso com uma resposta 180 (Ringing), que é roteada de volta através dos dois proxy's na direção inversa. Cada proxy usa o campo-cabeçalho Via para determinar para onde enviar a resposta e remove o seu próprio endereço do campo Via mais alto. Como resultado, apesar de DNS e consultas no serviço de localização foram obrigados a rotear o INVITE inicial, a resposta 180 (Ringing), a pode ser retornada ao chamador sem consultas ou sem estado sendoRosenberg, et. al. Standards Track [Página 14]
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