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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


respostas de falhas que solicitam uma alteração em uma requisição (por exemplo, um desafio de autenticação), essas requisições repetidas não são consideradas novas requisições e, portanto, não necessitam de novos campos-cabeçalhos Call-ID, consulte a Seção 8.1.3.5.

Uso de identificadores criptograficamente aleatórios (RFC 1750 [12]) na geração de Call-ID é RECOMENDADO. Implementações PODEM usar a forma "localid@host". Call-ID's são sensíveis a maiúsculo-minúsculo e são simplesmente comparados byte-por-byte.

Usando identificadores criptograficamente aleatórios fornece alguma proteção contra seqüestro de sessão e reduz a possibilidade de colisões não intencionais de Call-ID.

Nenhum provisionamento ou interface humana é necessário para a seleção do valor do campo-cabeçalho Call-ID para uma requisição.

Para mais informações sobre o campo-cabeçalho Call-ID, ver a Seção 20.8.

Exemplo:

Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com


8.1.1.5 CSeq

O campo-cabeçalho CSeq serve como uma forma para identificar e ordenar transações. Ele consiste de um número de seqüência e um método. O método PRECISA bater com o método da requisição. Para requisições não-REGISTER fora de um diálogo, o valor do número de sequência é arbitrário. O valor do número de seqüência PRECISA ser expresso como um inteiro de 32 bits sem sinal e PRECISA ser inferior a 2**31. Desde que ele sega as orientações acima, um cliente pode usar qualquer mecanismo que gostaria para selecionar valores do campo-cabeçalho CSeq.

A Seção 12.2.1.1 discute a construção do CSeq para requisições em um diálogo.

Exemplo:

CSeq: 4711 INVITE










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

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.