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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


o Comparação do userinfo de URI's do SIP e do SIPS é case-sensitive. Isto inclui userinfo que contenha senhas ou formatada como assinantes telefônico. Comparação de todos os outros componentes do URI não é case-sensitive, a menos que seja explicitamente definido em contrário.

o A ordenação de parâmetros e campos-cabeçalhos não é significativo em comparação com URI's do SIP e do SIPS.

o Caracteres diferentes desses no conjunto "reserved" (veja a RFC 2396 [5]) são equivalentes aos seus ""%" HEX HEX" codificados.

o Um endereço IP que é o resultado de uma busca DNS de nome de host não bater com esse nome de host.

o Para dois URI's serem iguais, os componentes: usuário, senha, host e porta precisam bater.

Um URI omitindo o componente usuário não vai bater com um URI que o inclui. Um URI omitindo o componente senha não bater com um URI que a inclui.

Um URI omitindo qualquer componente com um valor padrão não vai bater com um URI explicitamente contendo esse componente com seu valor padrão. Por exemplo, um URI omitindo o componente opcional porta, não vai conferir com um URI declarando explicitamente a porta 5060. O mesmo é verdadeiro para os componentes transport-parameter, ttl-parameter, o user-parameter e method.

Definir sip:user@host não é equivalente a sip:user@host:5060 é uma mudança desde a RFC 2543. Quando derivando endereços de URI's, endereços equivalentes são experados de URI's equivalentes. O URI sip:user@host:5060 sempre resolverá a porta 5060. O URI sip:user@host pode resolver para outras portas pelos mecanismos DNS SRV detalhados em [4].

o Componentes URI uri-parameter são comparados como a seguir:

- Qualquer uri-parameter aparecendo em ambos URI's precisam bater.

- user, ttl ou parâmetro uri method aparecendo em só um URI nunca confere, mesmo que ele contenha o valor padrão.

- O URI que inclui um parâmetro maddr não baterá com um URI que não contenha nenhum parâmetro maddr.

- Todos os outros uri-parameters aparecendo em só um URI são ignorados quando comparando os URI's.



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

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.