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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


O campo-cabeçalho Contact contém uma URI em  que Bob pode ser diretamente alcançado em seu telefone SIP. Os campos Content-Type e Content-Length se referem ao corpo da mensagem (não mostrado) que contém informações SDP da mídia de Bob.

Além de DNS e consultas ao serviço de localização é mostrado nesse exemplo, os servidores proxy pode tornar flexível "decisões de roteamento" decidir para onde enviar uma requisição. Por exemplo, se telefone SIP de Bob retornou uma resposta 486 (Busy Here), o servidor proxy biloxi.com poderia Proxy-ar o INVITE para o servidor voicemail de Bob. Um servidor proxy também pode enviar um INVITE para inúmeros locais ao mesmo tempo. Este tipo de consulta paralela é conhecida como forking.

Nesse caso, a resposta 200 (OK) é roteada de volta através dos dois proxy's e é recebida pelo softfone de Alice, que pára o tom ringback e indica que a chamada foi atendida. Finalmente, softfone de Alice envia uma mensagem confirmação, ACK, para o telefone SIP de Bob para confirmar a recepção da resposta final (200 (OK)). Nesse exemplo, o ACK é enviado diretamente de softfone de Alice para o telefone SIP de Bob ignorando os dois proxy's. Isso ocorre porque as pontas remotas aprenderem o endereço um do outro a partir dos campos-cabeçalhos Contact através da troca INVITE/200 (OK), que não era conhecidos quando o INVITE inicial foi enviado. As consultas realizadas pelos dois proxy's não são mais necessárias, de modo que os proxy's cerceiam o fluxo da chamada. Isso completa o handshake de três vias INVITE/200/ACK usado para estabelecer sessões SIP. Detalhes completos sobre o estabelecimento de sessão estão na Seção 13.

A sessão de mídia de Alice e Bob já começou, e eles enviam pacotes de mídia usando o formato para o qual eles concordaram na troca do SDP. Em geral, os pacotes de mídia de fim-a-fim seguem um caminho diferente daquele das mensagens de sinalização SIP.

Durante a sessão, tanto Alice quanto Bob pode decidir alterar as características da sessão de mídia. Isso é realizado enviando um re-INVITE contendo uma nova descrição de media. Esse re-INVITE referencia o diálogo existente de modo que a outra parte sabe que é para modificar uma sessão existente em vez de estabelecer uma nova sessão. A outra parte envia uma resposta 200 (OK) para aceitar a mudança. O requisitante responde a resposta 200 (OK) com um ACK. Se a outra parte não aceitar a mudança, ele envia uma resposta de erro, como 488 (Not Acceptable Here), que também recebe um ACK. No entanto, a falha do re-INVITE não faz a chamada existente para falhar - a sessão mantém as características anteriormente negociadas. Todos os detalhes sobre a modificação de sessão estão na Seção 14.





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

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.