RFC 3261 SIP: Session Initiation Protocol Junho 2002
Via contém o endereço (pc33.atlanta.com) no qual Alice espera receber respostas a essa requisição. Ele também contém o parâmetro branch que identifica essa transação.
O campo-cabeçalho To contém um nome de exibição (Bob) e um URI SIP ou SIPS (sip: bob@biloxi.com) para a qual a requisição foi direcionada originalmente. Nomes de exibição são descritos na RFC 2822 [3].
O campo-cabeçalho From também contém um nome de exibição (Alice) e um URI SIP ou SIPS (SIP: alice@atlanta.com) que indica o originador da requisição. Esse campo cabeçalho também tem um parâmetro tag que contém uma string aleatória (1928301774) que foi adicionado à URI pelo softfone. É utilizado para fins de identificação.
O campo-cabeçalho Call-ID contém um identificador globalmente exclusivo para essa chamada, gerado pela combinação de uma string aleatória e o nome de host ou endereço IP do softphone. A combinação do parâmetro tag do campo-cabeçalho To, do parâmetro tag do campo-cabeçalho From e o Call-ID define completamente uma relação SIP de fim-a-fim entre Alice e Bob e é referido como um diálogo.
O campo-cabeçalho CSeq ou Command Sequence contém um número inteiro e um nome de método. O número CSeq é incrementado para cada nova requisição dentro de um diálogo e é um número seqüencial tradicional.
O campo-cabeçalho Contact contém um URI SIP ou SIPS que representa uma rota direta para contactar Alice, usualmente composto de um nome de usuário (username) na forma de um nome de domínio completamente qualificado (FQDN). Embora o formato FQDN seja o preferido, muitos sistemas remotos não registram nomes de domínio, de sorte que endereços IP são permitidos. Embora o campo-cabeçalho Via informe outros elementos, para onde enviar a resposta, o campo-cabeçalho Contact diz outros elementos para onde enviar requisições futuras.
O campo-cabeçalho Max-Forwards serve para limitar o número de saltos que uma requisição pode dar no caminho até seu destino. Consiste de um número inteiro que é decrementado por um a cada passo.
O campo-cabeçalho Content-Type contém uma descrição do corpo da mensagem (não mostrado).
O campo-cabeçalho Content-Length contém uma contagem de octetos (bytes) do corpo da mensagem.
O conjunto completo de campos-cabeçalhos do SIP é definido na Seção 20.
Os detalhes da sessão, como o tipo de mídia, codec, ou taxa de amostragem, não são descritas usando o SIP. Invés disso, o corpo de uma mensagem SIP contém uma descrição da sessão, codificada em algum outro formato de protocolo. Um desses formatos é o Session Description Protocol (SDP) (RFC 2327 [1]). Essa mensagem SDP (não mostrada no
Rosenberg, et. al. Standards Track [Página 13]
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