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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


para estimular receptores a responder com mensagens CMS SignedData (por exemplo, ao enviar uma requisição OPTIONS como descrito acima).

o  Implementações S/MIME PRECISAM de um suporte mínimo SHA1 como um algoritmo de assinatura digital, e 3DES como um algoritmo de criptografia. Todos os outros algoritmos de assinatura e criptografia PODEM ser suportados. Implementações podem negociar suporte para esses algoritmos com o atributo "SMIMECapabilities".

o  Cada corpo S/MIME em uma mensagem SIP DEVE ser assinada apenas com um certificado. Se um UA receber uma mensagem com múltiplas assinaturas, a assinatura mais externa deve ser tratada como o único certificado para esse corpo. Assinaturas paralelas NÃO DEVEM ser usadas.

A seguir está um exemplo de um corpo SDP S/MIME criptografado em uma mensagem SIP:

        INVITE sip:bob@biloxi.com SIP/2.0
        Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
        To: Bob <sip:bob@biloxi.com>
        From: Alice <sip:alice@atlanta.com>;tag=1928301774
        Call-ID: a84b4c76e66710
        CSeq: 314159 INVITE
        Max-Forwards: 70
        Contact: <sip:alice@pc33.atlanta.com>
        Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
             name=smime.p7m
        Content-Disposition: attachment; filename=smime.p7m
           handling=required

      *******************************************************
      * Content-Type: application/sdp                       *
      *                                                     *
      * v=0                                                 *
      * o=alice 53655765 2353687637  IN IP4 pc33.atlanta.com *
      * s=-                                                 *
      * t=0 0                                               *
      * c=IN IP4 pc33.atlanta.com                           *
      * m=audio 3456 RTP/AVP 0 1 3 99                       *
      * a=rtpmap:0 PCMU/8000                                *
      *******************************************************








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

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.