# Cabeçalhos SIP: Via, From, To, Call-ID, CSeq, Contact

> 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.

- URL canônico: https://www.broadnet.me/pt/reference/sip-headers
- Idioma: pt
- Última atualização: 2026-07-18
- Editor: BroadNet (https://www.broadnet.me)

Os cabeçalhos SIP essenciais e o que fazem: Via (com o parâmetro branch) para encaminhar respostas, From/To com tags, Call-ID, CSeq, Contact, Max-Forwards, e como os diálogos e transações são identificados a partir deles.

## 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çalhos SIP obrigatórios (RFC 3261)*

| 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.

*O que identifica um diálogo vs uma transação*

| Â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).

*Ler os cabeçalhos principais de um INVITE*

```text
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 limit
```

## Perguntas 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.

## Fontes

- [IETF RFC 3261 — Header fields (§20)](https://datatracker.ietf.org/doc/html/rfc3261#section-20)
- [IANA — SIP header field registry](https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml)

## Relacionados

- [Métodos e solicitações SIP](https://www.broadnet.me/pt/reference/sip-methods-and-requests)
- [Códigos de resposta SIP](https://www.broadnet.me/pt/reference/sip-response-codes)
- [fluxo de chamada SIP](https://www.broadnet.me/pt/reference/sip-call-flow)
- [SDP: Session Description Protocol](https://www.broadnet.me/pt/reference/sdp-session-description-protocol)
- [Trunking de voz API & SIP](https://www.broadnet.me/pt/answers/voice-api-sip-trunking)