Seis cabeçalhos são obrigatórios em cada pedido SIP: Via (regista o caminho e transporta o branch da transação), From e To (as partes lógicas, com tags), Call-ID (um identificador único de chamada), CSeq (um número de sequência mais o método) e Max-Forwards (um limite de saltos). Juntos, Call-ID, tag do From e tag do To identificam um diálogo.
Os seis cabeçalhos obrigatórios
A RFC 3261 exige seis campos de cabeçalho em cada pedido. O Via traça a rota que o pedido tomou e diz às respostas como regressar. From e To identificam o originador e o alvo lógicos do pedido. O Call-ID é um token globalmente único partilhado por todas as mensagens de uma chamada. O CSeq ordena os pedidos dentro de um diálogo e nomeia o método. O Max-Forwards é um contador de saltos decrescente que previne ciclos. Omita qualquer destes e a mensagem é inválida.
| Cabeçalho | Finalidade |
|---|---|
| Via | Regista cada hop; as respostas fazem o caminho de volta. Carrega o branch da transação |
| From | Originador lógico; carrega uma tag |
| To | Destinatário lógico; recebe uma tag na resposta |
| Call-ID | Identificador global único para toda a chamada |
| CSeq | Número de sequência + método; ordena as solicitações dentro do diálogo |
| Max-Forwards | Limite de saltos (normalmente 70); evita loops de encaminhamento |
O Via e o parâmetro branch
Cada proxy que reencaminha um pedido insere o seu próprio cabeçalho Via no topo, construindo uma pilha que as respostas percorrem no sentido inverso — uma resposta é encaminhada puramente seguindo a lista de Via, pelo que refaz o caminho do pedido. O parâmetro branch do Via identifica a transação; desde a RFC 3261 tem de começar com o magic cookie fixo z9hG4bK, que marca o branch como globalmente único e conforme à RFC 3261. Associar respostas e retransmissões à transação certa depende deste valor.
Tags, diálogos e transações
A identidade do diálogo é montada a partir de três peças: o Call-ID mais o tag no From e o tag no To. O chamador define o tag do From quando envia o INVITE; o chamado acrescenta o tag do To na sua resposta, e nesse ponto o diálogo fica totalmente identificado para ambos os lados. Cada pedido posterior dentro do diálogo (re-INVITE, BYE) transporta os três para ficar associado à chamada certa. As transações, por contraste, são associadas pelo branch do Via e pelo método — uma granularidade mais fina que a do diálogo.
| Âmbito | Identificado por |
|---|---|
| Diálogo (a chamada) | Call-ID + From-tag + To-tag |
| Transação (requisição+respostas) | Branch do Via + método da solicitação |
| Ordenação das solicitações num diálogo | Número CSeq (incrementado a cada solicitação) |
Contact, encaminhamento e outros cabeçalhos comuns
Para além dos seis obrigatórios, vários cabeçalhos moldam o encaminhamento e as capacidades. O Contact dá um URI direto no qual o remetente pode ser alcançado para pedidos futuros — crítico no REGISTER e nas mensagens que estabelecem o diálogo. O Record-Route permite a um proxy manter-se no caminho de sinalização durante todo o diálogo, e o Route dirige os pedidos subsequentes através desses proxies. O Expires limita um registo ou subscrição. Allow, Supported e Require anunciam e negoceiam capacidades e extensões. Content-Type e Content-Length descrevem o corpo (normalmente SDP).
Via: SIP/2.0/UDP pc.example.com;branch=z9hG4bK74bf9 ← transaction id
From: Alice <sip:alice@example.com>;tag=9fxced76sl ← caller + From-tag
To: Bob <sip:bob@biloxi.com> ← callee (To-tag added in reply)
Call-ID: 3848276298220188511@pc.example.com ← whole-call id
CSeq: 1 INVITE ← sequence + method
Contact: <sip:alice@pc.example.com> ← where to reach the caller
Max-Forwards: 70 ← hop limitPerguntas frequentes
O que faz o cabeçalho Via no SIP?
O Via regista o caminho que um pedido toma: cada proxy acrescenta o seu próprio Via no topo, e as respostas seguem a pilha de Via de volta ao remetente. O seu parâmetro branch identifica a transação, para que as respostas e retransmissões sejam associadas ao pedido correto.
O que é o parâmetro branch z9hG4bK?
z9hG4bK é o magic cookie obrigatório com que um parâmetro branch SIP tem de começar segundo a RFC 3261. Sinaliza que o valor do branch é globalmente único e conforme à RFC 3261, e é a chave usada para associar uma resposta à sua transação.
Como é identificado um diálogo SIP?
Pela combinação de Call-ID, do tag do cabeçalho From e do tag do cabeçalho To. O chamador fornece o Call-ID e o tag do From no INVITE; o chamado acrescenta o tag do To na sua resposta. Todos os pedidos dentro do diálogo transportam os mesmos três valores.
Para que serve o cabeçalho CSeq?
O CSeq contém um número de sequência e o método do pedido, ordenando os pedidos dentro de um diálogo e permitindo a cada lado detetar retransmissões e mensagens fora de ordem. O número incrementa a cada novo pedido; o método tem de corresponder ao pedido que rotula.
Qual é a diferença entre Contact e To?
O To é o alvo lógico do pedido e geralmente não muda. O Contact é um URI concreto onde o remetente pode efetivamente ser alcançado para pedidos subsequentes. Os proxies encaminham por To/Request-URI, mas os pedidos posteriores dentro do diálogo são enviados para o Contact.
Especificações de origem
Os padrões publicados nos quais esta página se baseia. Abre num novo separador.