# Header SIP: Via, From, To, Call-ID, CSeq, Contact

> Sei header sono obbligatori in ogni richiesta SIP: Via (registra il percorso e trasporta il branch della transazione), From e To (le parti logiche, con i tag), Call-ID (un identificatore univoco di chiamata), CSeq (un numero di sequenza più il metodo) e Max-Forwards (un limite di salti). Insieme, Call-ID, tag From e tag To identificano un dialogo.

- URL canonico: https://www.broadnet.me/it/reference/sip-headers
- Lingua: it
- Ultimo aggiornamento: 2026-07-18
- Editore: BroadNet (https://www.broadnet.me)

Gli header SIP essenziali e cosa fanno: Via (con il parametro branch) per instradare le risposte, From/To con i tag, Call-ID, CSeq, Contact, Max-Forwards, e come dialoghi e transazioni si identificano da essi.

## I sei header obbligatori

RFC 3261 richiede sei campi header in ogni richiesta. Via traccia il percorso seguito dalla richiesta e indica alle risposte come tornare indietro. From e To identificano l'originante e il target logici della richiesta. Call-ID è un token globalmente univoco condiviso da tutti i messaggi di una chiamata. CSeq ordina le richieste all'interno di un dialogo e nomina il metodo. Max-Forwards è un contatore di salti decrescente che previene i loop. Omettete uno qualsiasi di questi e il messaggio è non valido.

*Header SIP obbligatori (RFC 3261)*

| Header | Scopo |
|---|---|
| Via | Registra ogni hop; le risposte ripercorrono lo stesso percorso. Contiene il branch della transazione |
| From | Origine logica; contiene un tag |
| To | Destinatario logico; ottiene un tag nella risposta |
| Call-ID | Identificativo univoco a livello globale per l'intera chiamata |
| CSeq | Numero di sequenza + metodo; ordina le richieste all'interno del dialogo |
| Max-Forwards | Limite di hop (in genere 70); previene i loop di routing |

## Via e il parametro branch

Ogni proxy che inoltra una richiesta inserisce in cima il proprio header Via, costruendo uno stack che le risposte ripercorrono a ritroso — una risposta è instradata unicamente seguendo la lista dei Via, quindi ripercorre il percorso della richiesta. Il parametro branch del Via identifica la transazione; da RFC 3261 deve iniziare con il magic cookie fisso z9hG4bK, che contrassegna il branch come globalmente univoco e conforme a RFC 3261. Abbinare risposte e ritrasmissioni alla transazione corretta dipende da questo valore.

## Tag, dialoghi e transazioni

L'identità del dialogo è composta da tre pezzi: il Call-ID più il tag in From e il tag in To. Il chiamante imposta il tag From quando invia l'INVITE; il chiamato aggiunge il tag To nella sua risposta, e a quel punto il dialogo è pienamente identificato per entrambi i lati. Ogni richiesta successiva nel dialogo (re-INVITE, BYE) trasporta tutti e tre così da essere associata alla chiamata corretta. Le transazioni, al contrario, sono abbinate dal branch del Via e dal metodo — una granularità più fine del dialogo.

*Cosa identifica un dialogo vs una transazione*

| Ambito | Identificato da |
|---|---|
| Dialogo (la chiamata) | Call-ID + From-tag + To-tag |
| Transazione (richiesta+risposte) | Branch del Via + metodo della richiesta |
| Ordinamento delle richieste in un dialogo | Numero CSeq (incrementato a ogni richiesta) |

## Contact, instradamento e altri header comuni

Oltre ai sei obbligatori, diversi header determinano instradamento e capacità. Contact fornisce un URI diretto a cui il mittente può essere raggiunto per richieste future — cruciale in REGISTER e nei messaggi che instaurano un dialogo. Record-Route consente a un proxy di restare nel percorso di segnalazione per l'intero dialogo, e Route indirizza le richieste successive attraverso quei proxy. Expires limita una registrazione o una subscription. Allow, Supported e Require pubblicizzano e negoziano capacità ed estensioni. Content-Type e Content-Length descrivono il body (di norma SDP).

*Lettura degli header chiave di un 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
```

## Domande frequenti

### Cosa fa l'header Via in SIP?

Via registra il percorso seguito da una richiesta: ogni proxy aggiunge in cima il proprio Via e le risposte seguono lo stack dei Via a ritroso fino al mittente. Il suo parametro branch identifica la transazione, così risposte e ritrasmissioni sono abbinate alla richiesta corretta.

### Che cos'è il parametro branch z9hG4bK?

z9hG4bK è il magic cookie obbligatorio con cui un parametro branch SIP deve iniziare secondo RFC 3261. Segnala che il valore del branch è globalmente univoco e conforme a RFC 3261, ed è la chiave usata per abbinare una risposta alla sua transazione.

### Come si identifica un dialogo SIP?

Dalla combinazione di Call-ID, tag dell'header From e tag dell'header To. Il chiamante fornisce il Call-ID e il tag From nell'INVITE; il chiamato aggiunge il tag To nella sua risposta. Tutte le richieste nel dialogo trasportano gli stessi tre valori.

### A cosa serve l'header CSeq?

CSeq contiene un numero di sequenza e il metodo della richiesta, ordinando le richieste all'interno di un dialogo e consentendo a ciascun lato di rilevare ritrasmissioni e messaggi fuori ordine. Il numero incrementa a ogni nuova richiesta; il metodo deve corrispondere alla richiesta che etichetta.

### Qual è la differenza tra Contact e To?

To è il target logico della richiesta e generalmente non cambia. Contact è un URI concreto a cui il mittente può essere effettivamente raggiunto per le richieste successive. I proxy instradano su To/Request-URI, ma le richieste successive nel dialogo sono inviate al Contact.

## Fonti

- [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)

## Correlati

- [Metodi e richieste SIP](https://www.broadnet.me/it/reference/sip-methods-and-requests)
- [Codici di risposta SIP](https://www.broadnet.me/it/reference/sip-response-codes)
- [Flusso di chiamata SIP](https://www.broadnet.me/it/reference/sip-call-flow)
- [SDP: Session Description Protocol](https://www.broadnet.me/it/reference/sdp-session-description-protocol)
- [API vocale e SIP trunking](https://www.broadnet.me/it/answers/voice-api-sip-trunking)