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.
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 | 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.
| 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).
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 limitDomande 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.
Specifiche della fonte
Gli standard pubblicati su cui si basa questa pagina. Si apre in una nuova scheda.