# Méthodes et requêtes SIP

> Les requêtes SIP sont désignées par une méthode. RFC 3261 en définit six : INVITE (démarrer une session), ACK (confirmer une réponse finale à un INVITE), BYE (terminer une session), CANCEL (avorter un INVITE en attente), REGISTER (enregistrer un emplacement) et OPTIONS (interroger les capacités). Des RFC d'extension ajoutent INFO, PRACK, UPDATE, SUBSCRIBE/NOTIFY, REFER, MESSAGE et PUBLISH.

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

Chaque méthode de requête SIP et son rôle : les six méthodes de base de RFC 3261 (INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS) et les extensions courantes (INFO, PRACK, UPDATE, SUBSCRIBE/NOTIFY, REFER, MESSAGE, PUBLISH).

## Les six méthodes de base

RFC 3261 définit l'ensemble de requêtes de base que toute implémentation SIP prend en charge. INVITE établit une session et porte l'offre SDP initiale. ACK acquitte une réponse finale à un INVITE — il est singulier en étant une requête qui complète l'établissement en trois temps de l'INVITE plutôt que d'attendre sa propre réponse. BYE termine une session établie. CANCEL avorte un INVITE n'ayant pas encore reçu de réponse finale (un appel qui sonne encore). REGISTER indique à un registrar où un utilisateur est joignable. OPTIONS interroge les capacités d'un pair et est largement réutilisé comme keepalive léger.

*Méthodes SIP de base (RFC 3261)*

| Méthode | Objectif | Note |
|---|---|---|
| INVITE | Lancer une session | Transmet l'offre SDP ; crée un dialogue |
| ACK | Confirmer une réponse INVITE finale | Achève la négociation INVITE en trois temps |
| BYE | Mettre fin à une session en cours | Envoyé par l'une ou l'autre des parties au dialogue |
| CANCEL | Annuler une INVITE en attente | Uniquement avant une réponse finale (sonne encore) |
| REGISTER | Enregistrer l'adresse Contact d'un utilisateur | Actualisé périodiquement (Expires) |
| OPTIONS | Interroger les capacités | Souvent réutilisé comme keepalive / contrôle d'état |

## Pourquoi ACK et CANCEL sont particuliers

Deux méthodes de base se comportent différemment des autres. ACK n'est pas une paire requête/réponse ordinaire : il acquitte la réponse finale à un INVITE et ne porte aucune réponse propre. Pour un 2xx, il est envoyé de bout en bout comme une transaction distincte ; pour un échec non-2xx, il est généré saut par saut au sein de la transaction INVITE. CANCEL n'a de sens que tant qu'un INVITE est encore en attente — une fois une réponse finale arrivée, utilisez BYE. Bien maîtriser ces deux méthodes est le nœud d'une machine à états SIP correcte.

## Méthodes d'extension courantes

Au-delà des six méthodes de base, un ensemble de méthodes d'extension gère la messagerie, les événements et les mises à jour en cours d'appel. SUBSCRIBE/NOTIFY implémentent le cadre d'événements (présence, indication de message en attente, état de dialogue). REFER déclenche le transfert d'appel. MESSAGE porte les messages instantanés / SMS-sur-SIP. UPDATE modifie une session avant son établissement complet (early media). PRACK acquitte de façon fiable les réponses provisoires. INFO porte des informations en cours de session comme le DTMF. PUBLISH soumet un état d'événement à un serveur.

*Méthodes d'extension SIP courantes*

| Méthode | RFC | Objectif |
|---|---|---|
| INFO | RFC 6086 | Informations en cours de session (ex. chiffres DTMF) |
| PRACK | RFC 3262 | Accusé de réception fiable des réponses provisoires (1xx) |
| UPDATE | RFC 3311 | Modifier une session avant la réponse finale (médias anticipés) |
| SUBSCRIBE / NOTIFY | RFC 6665 | Abonnement aux événements et notification (présence, MWI) |
| REFER | RFC 3515 | Demander un transfert à une autre partie |
| MESSAGE | RFC 3428 | Messagerie instantanée / messagerie en mode page |
| PUBLISH | RFC 3903 | Soumettre l'état de l'événement (par exemple, la présence) à un serveur |

## Une ligne de requête sur le fil

Une requête SIP commence par une ligne de requête : la méthode, l'URI de requête (la destination courante) et la version SIP. Les en-têtes et un corps optionnel suivent. L'exemple est le début d'un INVITE vers un appelé ; l'URI de requête est réécrite par les proxies au fil du routage, tandis que l'en-tête To reste fixe comme cible logique.

*Le début d'une requête INVITE*

```text
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP host.example.net;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=1928301774
Call-ID: a84b4c76e66710@host.example.net
CSeq: 314159 INVITE
Contact: <sip:alice@host.example.net>
Content-Type: application/sdp
Content-Length: 142
```

## Questions fréquentes

### Quelles sont les six méthodes SIP de base ?

INVITE (démarrer une session), ACK (confirmer une réponse finale à un INVITE), BYE (terminer une session), CANCEL (avorter un INVITE en attente), REGISTER (enregistrer l'emplacement d'un utilisateur) et OPTIONS (interroger les capacités). Elles sont définies dans RFC 3261 ; tout le reste est une extension.

### Quelle différence entre CANCEL et BYE ?

CANCEL avorte un INVITE n'ayant pas encore reçu de réponse finale — un appel qui sonne encore. BYE termine une session déjà établie. Utilisez CANCEL avant que l'appel soit décroché et BYE après ; se tromper laisse la machine à états incohérente.

### Pourquoi ACK n'obtient-il pas de réponse ?

ACK existe pour acquitter la réponse finale à un INVITE et compléter l'établissement en trois temps ; il est donc défini pour ne pas avoir de réponse propre. Pour un 2xx, c'est une transaction distincte de bout en bout ; pour un échec, il est généré saut par saut dans la transaction INVITE.

### Comment le DTMF est-il envoyé en SIP ?

Le plus souvent sous forme de paquets RTP telephone-event (RFC 4733) dans le flux média, et alternativement via des messages SIP INFO portant les chiffres dans le chemin de signalisation. Le RTP telephone-event est préféré car il reste synchronisé avec l'audio.

### Quelle méthode transfère un appel ?

REFER (RFC 3515). Elle demande au destinataire d'initier une nouvelle requête (généralement un INVITE) vers un tiers nommé dans l'en-tête Refer-To, implémentant le transfert d'appel. Des messages NOTIFY rapportent ensuite la progression de l'appel transféré à l'auteur du transfert.

## Sources

- [IETF RFC 3261 — SIP](https://datatracker.ietf.org/doc/html/rfc3261)
- [IETF RFC 6665 — SIP-Specific Event Notification](https://datatracker.ietf.org/doc/html/rfc6665)

## Voir aussi

- [Vue d'ensemble du protocole SIP](https://www.broadnet.me/fr/reference/sip-protocol-overview)
- [Codes de réponse SIP](https://www.broadnet.me/fr/reference/sip-response-codes)
- [En-têtes SIP](https://www.broadnet.me/fr/reference/sip-headers)
- [Flux d'appel SIP](https://www.broadnet.me/fr/reference/sip-call-flow)
- [API voix et trunking SIP](https://www.broadnet.me/fr/answers/voice-api-sip-trunking)