RFC 3261 SIP: Session Initiation Protocol Junho 2002
8.1.1.3 From
O campo-cabeçalho From indica a identidade lógica do originador da requisição, possivelmente o endereço-de-registro do usuário. Igual ao campo-cabeçalho To, ele contém uma URI e, opcionalmente, um nome de exibição. Ele é usado por elementos SIP para determinar quais regras de processamento aplicar a uma requisição (por exemplo, rejeição automática de chamada). Como tal, é muito importante que o URI de From não contenha endereços IP ou o FQDN do host no qual o UA está rodando, porque esses não são nomes lógicos.
O campo-cabeçalho From permite um nome de exibição. Um UAC DEVE usar o nome de exibição "Anonymous", junta com um URI sintaticamente correta, mas em vez disso sem significado (como sip:thisis@anonymous.invalid), se a identidade do cliente deve permanecer oculta.
Normalmente, o valor que preenche o campo-cabeçalho From em requisições gerados por um UA particular é pré-definido pelo usuário ou pelos administradores do domínio local do usuário. Se um UA particular for usado por múltiplos usuários, poderia ter perfis selecionáveis que inclue uma URI correspondente à identidade do usuário com perfil. Destinos de requisições podem autenticar o originador de uma requisição para certificar que eles são os mesmos quem declaram o campo-cabeçalho From deles (ver Seção 22 para mais informações sobre autenticação).
O campo From PRECISA conter um novo parâmetro "tag", escolhido pelo UAC. Consulte a Seção 19.3 para detalhes sobre a escolha de um token tag.
Para mais informações sobre o campo-cabeçalho From, consulte a Seção 20.20. Exemplos:
From: "Bob" <sips:bob@biloxi.com> ;tag=a48s
From: sip:+12125551212@phone2net.com;tag=887s
From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
8.1.1.4 Call-ID
O campo-cabeçalho Call-ID age como um identificador único para agrupar junto uma série de mensagens. Ele PRECISA ser o mesmo para todas requisições e respostas enviadas por qualquer UA em um diálogo. Ele DEVE ser o mesmo em cada pedido de registro de um UA.
Em uma nova requisição criado por um UAC fora de algum diálogo, o campo-cabeçalho Call-ID PRECISA ser selecionado pelo UAC como um identificador global único no espaço e no tempo a menos que seja substituído por um comportamento específico de método. Todos UAs SIP precisam ter uma forma de garantir que campos-cabeçalhos Call-ID que eles produzem não serão inadvertidamente gerados por algum outro UA. Note que quando requisições são repetidas após certas
Rosenberg, et. al. Standards Track [Página 37]
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