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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


         INVITE                   [RFC3261]
         ACK                      [RFC3261]
         BYE                      [RFC3261]
         CANCEL                   [RFC3261]
         REGISTER                 [RFC3261]
         OPTIONS                  [RFC3261]
         INFO                     [RFC2976]

A tabela de código resposta é inicialmente preenchida da Seção 21, as partes rotuladas Informational, Success, Redirection, Client-Error, Server-Error e Global-Failure. A tabela tem o seguinte formato:

      Tipp (p.ex., Informacional)
            Number    Frase Razão Padrão         [RFC3261]

A informação seguinte precisa ser fornecida em uma publicação RFC a fim de registrar uma novo código resposta ou método:

o  O número RFC em que o metódo ou código resposta está registrado;

o  o número do código resposta ou nome do método sendo registrado;

o  a frase razão padrão para esse código resposta, se aplicável;


27.5 O tipo "message/sip" do MIME

Esse documento registra o tipo "message/sip" de mídia MIME a fim de permitir mensagens SIP serem tuneladas como corpos dentro do SIP, primariamente para os propósitos de segurança fim-a-fim. Esse tipo de mídia é definido pela seguinte informação:

Nome do tipo de mídia: mensagem
Nome do subtipo de mídia: sip
Parametros exigidos: nenhum

Parâmetros opcionais: version
version: O número de Versão do SIP da mensagem enclosed (e.g., "2.0"). Se não presente, o version é padronizado como "2.0".
Esquema de codificação: mensagens SIP consistem de um cabeçalho de 8-bits opcionalmente seguido por um objeto dado MIME binário. Como tal, mensagens SIP precisam ser tratadas como binário. Sob circunstâncias normais mensagens SIP são transportadas sob transportes capazes de binário, nenhuma codificação especial é necessária.




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

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.