RFC 3261 Português Página 66

RFC 3261 SIP: Session Initiation Protocol Junho 2002

Para cada endereço, o registrador então busca na lista bindings atuais usando as

regras de comparação de URI. Se o binding não existir, ele é provisoriamente

acrescentado. Se o binding existir, o registrador verifica o valor do Call-ID.

Se o valor do Call-ID no binding existente difere do valor do Call-ID na

requisição, o binding PRECISA ser removido se o tempo de expiração for zero e

atualizado em caso contrário. Se eles são iguais, o registrador compara o valor do

CSeq. Se o valor for maior do que aquele binding já existente, ele PRECISA

atualizar ou remover o binding como acima. Caso contrário, a atualização PRECISA

ser abortada e não a requisição falha.

Esse algoritmo garante que requisições fora-de-ordem do mesmo UA sejam ignoradas.

Cada registro binding registra os valores do Call-ID e do CSeq da requisição.

As atualizações de binding PRECISAM ser comunicadas (ou seja, ser tornadas visíveis ao

servidor proxy ou ao redirect) se e somente se todas atualizações e adições binding

foram bem sucedidos. Se algum delas falhar (por exemplo, porque a transação com o

database subjancente falhou), a requisição PRECISA falhar com uma Resposta 500

(Server Internal Error) e todas as tentativas de atualizações binding PRECISAM ser desfeitas.

8. O registrador retorna uma resposta 200 (OK). A resposta PRECISA conter valores do

campo-cabeçalho Contact que enumeram todos os bindings atuais. Cada valor de Contact

PRECISA apresentar um parâmetro "expires" para indicar seu intervalo de expiração

escolhido pelo registrador. A resposta DEVE incluir um campo-cabeçalho Date.

11 Consultando Capacidades

O método OPTIONS do SIP permite a um UA consulta outro UA ou um servidor proxy quanto a

suas capacidades. Isso permite a um cliente descobrir informações sobre métodos suportados,

tipos de conteúdo, extensões, codecs, etc, sem "encomodar" a outra parte. Por exemplo,

antes de um cliente inserir um campo-cabeçalho Require em INVITE listando uma opção que

ele não está certo que o UAS destino suporta, o cliente pode consultar o UAS destino com

uma OPTIONS pra ver se essa opção é retornada em um campo-cabeçalho Supported. Todos UA's

PRECISAM suportar o método OPTIONS.

O alvo da requisição OPTIONS é identificado pelo Request-URI, que poderia identificar

outro UA ou um servidor SIP. Se a requisição OPTIONS for dirigida a um servidor proxy, o

Request-URI é definida sem a parte usuário, similar a forma de um Request-URI que é

definida por uma requisição REGISTER.

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

Página Anterior

Tabela de Conteúdo

Página Seguinte

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.