RFC 3261 SIP: Session Initiation Protocol Junho 2002
O parâmetro lr, quando presente, indica que o elemento responsável por esse recurso implementa os mecanismos de roteamento especificado nesse documento. Esse parâmetro será usado no lugar de URI's de proxy's nos valores do campo-cabeçalho Record-Route, e podem aparecer nos URI's em um conjunto de rotas pré-existente.
Esse parâmetro é usado para conseguir retrocompatibilidade com sistemas que implementam os mecanismos roteamento estrito da RFC 2543 e os drafts rfc2543bis até bis-05. Um elemento se preparando para enviar uma requisição baseada em URI não contendo esse parâmetro pode assumir o elemento que recebe que implementa roteamento estrito e que reformata a mensagem para preservar as informações no Request-URI.
Como o mecanismo uri-parameter é extensível, elementos SIP PRECISAM silenciosamente ignorar quaisquer uri-parameter's que eles não compreendem.
Headers: Campos-cabeçalhos a ser incluidos em uma requisição construida a partir do URI.
Campos-cabeçalhos na requisição SIP podem ser especificados com o mecanismo "?" dentro de um URI. Os nomes de cabeçalhos e valores são codificados em pares hname = hvalue separados com E comercial. O hname especial "body" indica que o hvalue associado é o corpo da mensagem da requisição SIP.
A Tabela 1 resume o uso de componentes URI do SIP e do SIPS baseado no contexto em que o URI aparece. A coluna externa descreve URI's que aparecem em qualquer lugar fora de uma mensagem SIP, por exemplo, em página Web ou cartão de visita. Entradas marcadas com "m" são obrigatórios, aqueles marcados com "o" são opcionais, e aqueles marcados com "-" não são permitidos. Elementos que processam URI's DEVEM ignorar quaisquer componentes não permitidos se estiverem presentes. A segunda coluna indica o valor padrão de um elemento opcional, se não estiver presente. O "--" indica que o elemento nem é opcional, e nem possui valor padrão.
URI's nos campos-cabeçalhos Contact têm diferentes restrições dependendo do contexto em que o campo-cabeçalho aparece. Um conjunto se aplica as mensagens que estabelecem e mantém diálogos (INVITE e sua resposta 200 (OK)). O outro se aplica às mensagens de registro e redirecionamento (REGISTER, sua resposta 200 (OK), e as respostas de classe 3xx para qualquer método).
Rosenberg, et. al. Standards Track [Página 151]
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