# En-têtes SIP : Via, From, To, Call-ID, CSeq, Contact

> Six en-têtes sont obligatoires dans chaque requête SIP : Via (enregistre le chemin et porte le branch de transaction), From et To (les parties logiques, avec tags), Call-ID (un identifiant d'appel unique), CSeq (un numéro de séquence plus la méthode) et Max-Forwards (une limite de sauts). Ensemble, Call-ID, tag From et tag To identifient un dialogue.

- URL canonique: https://www.broadnet.me/fr/reference/sip-headers
- Langue: fr
- Dernière mise à jour: 2026-07-18
- Éditeur: BroadNet (https://www.broadnet.me)

Les en-têtes SIP essentiels et leur rôle : Via (avec le paramètre branch) pour router les réponses, From/To avec tags, Call-ID, CSeq, Contact, Max-Forwards, et comment dialogues et transactions en sont identifiés.

## Les six en-têtes obligatoires

RFC 3261 exige six champs d'en-tête dans chaque requête. Via trace la route empruntée par la requête et indique aux réponses comment revenir. From et To identifient l'émetteur et la cible logiques de la requête. Call-ID est un jeton globalement unique partagé par tous les messages d'un même appel. CSeq ordonne les requêtes au sein d'un dialogue et nomme la méthode. Max-Forwards est un compteur de sauts décroissant qui prévient les boucles. En omettre un rend le message invalide.

*En-têtes SIP obligatoires (RFC 3261)*

| En-tête | Objectif |
|---|---|
| Via | Enregistre chaque saut ; les réponses le suivent en retour. Transporte la branche de transaction |
| From | Émetteur logique ; porte une étiquette (tag) |
| To | Destinataire logique ; reçoit une étiquette dans la réponse |
| Call-ID | Identifiant unique global pour l'ensemble de l'appel |
| CSeq | Numéro de séquence + méthode ; ordonne les requêtes dans le dialogue |
| Max-Forwards | Limite de sauts (généralement 70) ; empêche les boucles de routage |

## Via et le paramètre branch

Chaque proxy qui transfère une requête insère son propre en-tête Via en tête, construisant une pile que les réponses redescendent — une réponse est routée uniquement en suivant la liste des Via, retraçant donc le chemin de la requête. Le paramètre branch du Via identifie la transaction ; depuis RFC 3261, il doit commencer par le magic cookie fixe z9hG4bK, qui marque le branch comme globalement unique et conforme à RFC 3261. Le rapprochement des réponses et retransmissions à la bonne transaction dépend de cette valeur.

## Tags, dialogues et transactions

L'identité d'un dialogue est assemblée à partir de trois éléments : le Call-ID plus le tag dans From et le tag dans To. L'appelant fixe le tag From lorsqu'il envoie l'INVITE ; l'appelé ajoute le tag To dans sa réponse, et à ce moment le dialogue est pleinement identifié des deux côtés. Chaque requête ultérieure dans le dialogue (re-INVITE, BYE) porte les trois pour être associée au bon appel. Les transactions, en revanche, se rapprochent par le branch du Via et la méthode — une granularité plus fine que le dialogue.

*Ce qui identifie un dialogue vs une transaction*

| Portée | Identifié par |
|---|---|
| Dialogue (l'appel) | Call-ID + From-tag + To-tag |
| Transaction (requêtes + réponses) | Branche Via + méthode de la requête |
| Ordonnancement des requêtes dans un dialogue | Numéro CSeq (incréments par requête) |

## Contact, routage et autres en-têtes courants

Au-delà des six obligatoires, plusieurs en-têtes façonnent le routage et les capacités. Contact donne une URI directe à laquelle l'émetteur peut être joint pour les requêtes futures — crucial dans REGISTER et dans les messages établissant un dialogue. Record-Route permet à un proxy de rester dans le chemin de signalisation pour tout le dialogue, et Route dirige les requêtes suivantes à travers ces proxies. Expires borne un enregistrement ou un abonnement. Allow, Supported et Require annoncent et négocient les capacités et extensions. Content-Type et Content-Length décrivent le corps (généralement SDP).

*Lecture des en-têtes clés d'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
```

## Questions fréquentes

### Que fait l'en-tête Via en SIP ?

Via enregistre le chemin qu'emprunte une requête : chaque proxy ajoute son propre Via en tête, et les réponses suivent la pile des Via jusqu'à l'émetteur. Son paramètre branch identifie la transaction, si bien que réponses et retransmissions se rapprochent à la bonne requête.

### Qu'est-ce que le paramètre branch z9hG4bK ?

z9hG4bK est le magic cookie obligatoire par lequel un paramètre branch SIP doit commencer sous RFC 3261. Il signale que la valeur du branch est globalement unique et conforme à RFC 3261, et c'est la clé utilisée pour rapprocher une réponse de sa transaction.

### Comment un dialogue SIP est-il identifié ?

Par la combinaison du Call-ID, du tag de l'en-tête From et du tag de l'en-tête To. L'appelant fournit le Call-ID et le tag From dans l'INVITE ; l'appelé ajoute le tag To dans sa réponse. Toutes les requêtes dans le dialogue portent ces trois mêmes valeurs.

### À quoi sert l'en-tête CSeq ?

CSeq contient un numéro de séquence et la méthode de requête, ordonnant les requêtes au sein d'un dialogue et permettant à chaque côté de détecter les retransmissions et les messages hors ordre. Le numéro s'incrémente à chaque nouvelle requête ; la méthode doit correspondre à la requête qu'elle étiquette.

### Quelle différence entre Contact et To ?

To est la cible logique de la requête et ne change généralement pas. Contact est une URI concrète où l'émetteur peut réellement être joint pour les requêtes suivantes. Les proxies routent sur To/URI de requête, mais les requêtes ultérieures dans le dialogue sont envoyées au Contact.

## Sources

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

## Voir aussi

- [Méthodes et requêtes SIP](https://www.broadnet.me/fr/reference/sip-methods-and-requests)
- [Codes de réponse SIP](https://www.broadnet.me/fr/reference/sip-response-codes)
- [Flux d'appel SIP](https://www.broadnet.me/fr/reference/sip-call-flow)
- [SDP : Session Description Protocol](https://www.broadnet.me/fr/reference/sdp-session-description-protocol)
- [API voix et trunking SIP](https://www.broadnet.me/fr/answers/voice-api-sip-trunking)