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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Falhas DEVEM ser detectadas com códigos de resposta de falha (códigos superior a 399), para erros de rede a transação cliente vai relatar quaisquer falhas da camada de transporte ao usuário da transação. Observe que alguns códigos de resposta (detalhado em 8.1.3.5) indicam que a requisição pode ser repetida; requisições que são repetidas de novo não devem ser considerados falhas.

Quando uma falha para um endereço de contato particular for recebido, o cliente DEVE tentar o próximo endereço de contato. Isso implicará na criação de uma nova transação cliente para entregar uma nova requisição.

A fim de criar uma requisição baseada no endereço de contato em uma resposta 3xx, um UAC PRECISA copiar o URI inteira do destino definida no Request-URI, exceto os parâmetros "method-param" e "header" do URI (ver Seção 19.1.1 para a definição desses parâmetros). Ele usa os parâmetros "header" para criar valores do campo-cabeçalho para a nova requisição, sobreescrevendo valores do campo-cabeçalho associados com a requisição redirecionada em conformidade com as orientações da Seção 19.1.5.

Note que em alguns casos, campos-cabeçalhos que tenham sido comunicados no endereço de contato pode em vez de anexar campos-cabeçalhos existentes da requisição na requisição original redirecionada. Como regra geral, se o campo-cabeçalho pode aceitar uma lista de valores separada por vírgulas, então o novo valor do cabeçalho-campo PODE ser anexado a quaisquer valores existentes na requisição original redirecionada. Se o campo-cabeçalho não aceitar múltiplos valores, o valor da requisição original redirecionada PODE ser sobreescrito pelo valor do campo-cabeçalho comunicado no endereço de contato. Por exemplo, se um endereço de contato for retornado com o seguinte valor:

sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>

Então qualquer campo-cabeçalho Subject na requisição original redirecionada é sobreescrito, mas o URL HTTP é meramente anexada a quaisquer valores existentes no campo-cabeçalho Call-Info.

É RECOMENDADO que o UAC reuse os mesmos To, From e Call-ID usados na requisição original redirecionada, mas o UAC PODE também escolher atualizar o valor do campo-cabeçalho Call-ID para novas requisições, por exemplo.

Finalmente, uma vez que a nova requisição tenha sido construída, ela é enviada usando uma nova transação cliente, e portanto, PRECISA ter um novo branch ID no campo Via mais alto como discutido na Seção 8.1.1.7.







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

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.