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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


Enviar uma requisição formada a partir de um dado URI pode exigir capacidades não disponíveis à implementação. O URI pode indicar uso de um transporte ou extensão não implementados, por exemplo. Uma implementação DEVE recusar-se a enviar essas requisições ao invés de modificá-las para ajustar a suas capacidades. Uma implementação NÃO PODE enviar uma requisição que requer uma extensão que ela não suporta.

Por exemplo, tal requisição pode ser formada através da presença de um parâmetro cabeçalho Require ou um parâmetro URI method com um valor desconhecido ou explicitamente não suportado.


19.1.6 Relação entre URI's do SIP e URL's de tel

Quando um URL tel (RFC 2806 [9]) é convertido em um URI do SIP ou do SIPS, a porção assinante telefônico inteira do URL tel, incluindo quaisquer parâmetros, é colocado na parte userinfo do URI SIP ou SIPS.

Portanto, tel:+358-555-1234567;postd=pp22 torna-se

      sip:+358-555-1234567;postd=pp22@foo.com;user=phone

ou
      sips:+358-555-1234567;postd=pp22@foo.com;user=phone

e não
      sip:+358-555-1234567@foo.com;postd=pp22;user=phone

e nem

      sips:+358-555-1234567@foo.com;postd=pp22;user=phone

Em geral, URL's "tel" equivalentes convertidos em URI's do SIP ou URI's do SIPS desse modo não pode produzir URI's do SIP ou URI's do SIPS equivalentes. O userinfo do URI's SIP e SIPS são comparados como uma string case-sensitive. Variância em porções não case-sensitive do URL's tel e reordenação dos parâmetros URL tel não afeta tel URL equivalente, mas não afeta a equivalência do URI's SIP formado a partir deles.

Por exemplo,

      tel:+358-555-1234567;postd=pp22
      tel:+358-555-1234567;POSTD=PP22

são equivalentes, enquanto

      sip:+358-555-1234567;postd=pp22@foo.com;user=phone
      sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone




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

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.