RFC 3261 SIP: Session Initiation Protocol Junho 2002
Exemplo de resposta a OPTIONS gerada por um UAS (correspondente à requisição da Seção 11.1):
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
;received=192.0.2.4
To: <sip:carol@chicago.com>;tag=93810874
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact: <sip:carol@chicago.com>
Contact: <mailto:carol@chicago.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Accept: application/sdp
Accept-Encoding: gzip
Accept-Language: en
Supported: foo
Content-Type: application/sdp
Content-Length: 274
(o SDP não foi mostrado)
12 Diálogos
Um conceito-chave para um agente-usuário é aquele de um diálogo. Um diálogo representa uma relação SIP de fim-a-fim entre dois agentes-usuários que persiste por certo tempo. O diálogo facilita o seqüenciamento de mensagens entre agentes-usuários e roteamento adequado de requisições entre eles. O diálogo representa um contexto no qual interpretar mensagens SIP. Seção 8 discutiu o método independente de processamento do UA para requisições e respostas fora de um diálogo. Essa seção discute como essas requisições e respostas são usadas para construir um diálogo e então como requisições e respostas subseqüentes são enviadas dentro de um diálogo.
Um diálogo é identificado em cada UA por um ID do diálogo, o qual consiste do valor do Call-ID, uma tag local e uma tag remota. O diálogo ID em cada UA envolvido no diálogo não é igual. Especificamente, a tag local em um UA é idêntico à tag remota no UA peer. As tags são tokens opacos que facilitam a geração de ID's únicos de diálogos.
Um ID do diálogo também está associado com todas respostas e com qualquer requisição que contenha uma tag no campo To. As regras para calcular o ID do diálogo de uma mensagem depende do elemento SIP ser um UAC ou um UAS. Para um UAC, o valor do campo Call-ID do diálogo ID é definido com o Call-ID da mensagem, a tag remota é definida com a tag no campo To da mensagem, e a tag local é definida com a tag no campo From da
Rosenberg, et. al. Standards Track [Página 69]
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