RFC 3261 SIP: Session Initiation Protocol Junho 2002
em outras seções. Para implementações em conformidade com essa especificação, o valor do parâmetro branch PRECISA começar com o cookie mágico "z9hG4bK", conforme discutido na Seção 8.1.1.7.
Protocolos de transporte definidos aqui são "UDP", "TCP", "TLS", e "SCTP". O "TLS" significa TLS sobre o TCP. Quando uma requisição é enviada a um URI do SIPS, o protocolo ainda indica "SIP", e o protocolo de transporte é o TLS.
Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207
;branch=z9hG4bK77asjd
A forma compacta do campo-cabeçalho Via é v.
Nesse exemplo, a mensagem originada de um host multi-homed com dois endereços, 192.0.2.1 e 192.0.2.207. O enviador adivinhou problema quanto a qual interface de rede seria usada. Erlang.bell-telephone.com observou o problema e adicionou um parâmetro ao valor do campo-cabeçalho Via anterior do hop, que contém o endereço de onde o pacote realmente veio.
O endereço de host ou de rede e número de porta não são exigidos seguir a sintaxe de URI do SIP. Especificamente, LWS em qualquer dos lados do ":" ou "/" é permitido, como mostrado aqui:
Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1
Ainda que essa especificação obrigue que o parâmetro branch esteja presente em todas as requisições, o BNF para o campo-cabeçalho indica que ele é opcional. Isso permite interoperação com elementos da RFC 2543, que não precisa inserir o parâmetro branch.
Dois campos-cabeçalhos Via são iguais se seus campos sent-protocol e sent-by forem iguais, ambos tem o mesmo conjunto de parâmetros, e os valores de todos os parâmetros são iguais.
20.43 Warning
O campo-cabeçalho Warning é usado para transportar informação adicional sobre o status de uma resposta. Os valores do campo-cabeçalho Warning são enviados com respostas e contém um código aviso de três dígitos, hostname e texto de aviso.
O "warn-text" deve estar em uma linguagem natural que seja mais provavelmente inteligível ao usuário humano que recebe a resposta. Essa decisão pode ser baseada em algum conhecimento disponível, como a localização do usuário, o campo Accept-Language em uma requisição, ou o
Rosenberg, et. al. Standards Track [Página 180]
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.
Nenhum comentário:
Postar um comentário