# SIP-Methoden und -Requests

> SIP-Requests werden durch eine Methode benannt. RFC 3261 definiert sechs: INVITE (eine Sitzung starten), ACK (eine finale INVITE-Response bestätigen), BYE (eine Sitzung beenden), CANCEL (ein anstehendes INVITE abbrechen), REGISTER (einen Ort registrieren) und OPTIONS (Fähigkeiten abfragen). Erweiterungs-RFCs ergänzen INFO, PRACK, UPDATE, SUBSCRIBE/NOTIFY, REFER, MESSAGE und PUBLISH.

- Kanonische URL: https://www.broadnet.me/de/reference/sip-methods-and-requests
- Sprache: de
- Zuletzt aktualisiert: 2026-07-18
- Herausgeber: BroadNet (https://www.broadnet.me)

Jede SIP-Request-Methode und ihre Funktion: die sechs Kernmethoden von RFC 3261 (INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS) und die gängigen Erweiterungen (INFO, PRACK, UPDATE, SUBSCRIBE/NOTIFY, REFER, MESSAGE, PUBLISH).

## Die sechs Kernmethoden

RFC 3261 definiert den Kern-Request-Satz, den jede SIP-Implementierung unterstützt. INVITE baut eine Sitzung auf und trägt das anfängliche SDP-Offer. ACK bestätigt eine finale Response auf ein INVITE — es ist ungewöhnlich, da es ein Request ist, der den Drei-Wege-INVITE-Handshake abschließt, statt eine eigene Response zu erwarten. BYE beendet eine aufgebaute Sitzung. CANCEL bricht ein INVITE ab, das noch keine finale Response erhalten hat (ein noch klingelnder Anruf). REGISTER teilt einem Registrar mit, wo ein Nutzer erreichbar ist. OPTIONS fragt die Fähigkeiten einer Gegenstelle ab und wird häufig als leichtgewichtiges Keepalive wiederverwendet.

*SIP-Kernmethoden (RFC 3261)*

| Methode | Zweck | Hinweis |
|---|---|---|
| INVITE | Eine Sitzung starten | Überträgt das SDP-Angebot; erzeugt einen Dialog |
| ACK | Bestätigt eine finale INVITE-Antwort | Schließt den 3-Wege-INVITE-Handshake ab |
| BYE | Eine bestehende Sitzung beenden | Von einer der beiden Parteien im Dialog gesendet |
| CANCEL | Ausstehende INVITE-Anfrage abbrechen | Nur vor einer endgültigen Antwort (es klingelt noch) |
| REGISTER | Contact-Standort eines Benutzers registrieren | Regelmäßig aufgefrischt (Expires) |
| OPTIONS | Fähigkeiten abfragen | Wird häufig als Keepalive/Health-Check wiederverwendet |

## Warum ACK und CANCEL besonders sind

Zwei Kernmethoden verhalten sich anders als die übrigen. ACK ist kein normales Request/Response-Paar: Es bestätigt die finale Response auf ein INVITE und trägt keine eigene Response. Für ein 2xx wird es Ende-zu-Ende als separate Transaktion gesendet; für einen Nicht-2xx-Fehlschlag wird es hop-für-hop innerhalb der INVITE-Transaktion erzeugt. CANCEL hat nur Bedeutung, solange ein INVITE noch aussteht — sobald eine finale Response eintrifft, verwenden Sie stattdessen BYE. Diese beiden richtig zu handhaben ist der Kern einer korrekten SIP-Zustandsmaschine.

## Gängige Erweiterungsmethoden

Über die sechs Kernmethoden hinaus behandelt ein Satz von Erweiterungsmethoden Messaging, Ereignisse und Mid-Call-Aktualisierungen. SUBSCRIBE/NOTIFY implementieren das Event-Framework (Presence, Message-Waiting-Indication, Dialog-Zustand). REFER löst eine Anrufweiterleitung aus. MESSAGE trägt Sofortnachrichten / SMS-über-SIP. UPDATE ändert eine Sitzung, bevor sie vollständig aufgebaut ist (Early Media). PRACK bestätigt provisorische Responses zuverlässig. INFO trägt Mid-Session-Informationen wie DTMF. PUBLISH übermittelt einen Event-Zustand an einen Server.

*Gängige SIP-Erweiterungsmethoden*

| Methode | RFC | Zweck |
|---|---|---|
| INFO | RFC 6086 | Informationen während der Sitzung (z. B. DTMF-Ziffern) |
| PRACK | RFC 3262 | Zuverlässige Bestätigung vorläufiger (1xx) Antworten |
| UPDATE | RFC 3311 | Eine Sitzung vor der endgültigen Antwort ändern (Early Media) |
| SUBSCRIBE / NOTIFY | RFC 6665 | Ereignisabonnement und Benachrichtigung (Presence, MWI) |
| REFER | RFC 3515 | Weitervermittlung an einen anderen Teilnehmer anfordern |
| MESSAGE | RFC 3428 | Instant Messaging / Nachrichten im Page-Modus |
| PUBLISH | RFC 3903 | Ereignisstatus (z. B. Presence) an einen Server senden |

## Eine Request-Zeile auf der Leitung

Ein SIP-Request beginnt mit einer Request-Zeile: die Methode, die Request-URI (das aktuelle Ziel) und die SIP-Version. Die Header und ein optionaler Body folgen. Das Beispiel ist der Beginn eines INVITE in Richtung eines Angerufenen; die Request-URI wird von Proxies beim Routen des Requests umgeschrieben, während der To-Header als logisches Ziel fest bleibt.

*Der Beginn eines INVITE-Requests*

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

## Häufige Fragen

### Was sind die sechs SIP-Kernmethoden?

INVITE (eine Sitzung starten), ACK (eine finale INVITE-Response bestätigen), BYE (eine Sitzung beenden), CANCEL (ein anstehendes INVITE abbrechen), REGISTER (den Ort eines Nutzers registrieren) und OPTIONS (Fähigkeiten abfragen). Diese sind in RFC 3261 definiert; alles andere ist eine Erweiterung.

### Was ist der Unterschied zwischen CANCEL und BYE?

CANCEL bricht ein INVITE ab, das noch keine finale Response erhalten hat — einen noch klingelnden Anruf. BYE beendet eine bereits aufgebaute Sitzung. Verwenden Sie CANCEL vor der Annahme und BYE danach; die falsche Methode lässt die Zustandsmaschine inkonsistent werden.

### Warum erhält ACK keine Response?

ACK existiert, um die finale Response auf ein INVITE zu bestätigen und den Drei-Wege-Handshake abzuschließen, daher ist es so definiert, dass es keine eigene Response hat. Für ein 2xx ist es eine separate Ende-zu-Ende-Transaktion; für einen Fehlschlag wird es hop-für-hop innerhalb der INVITE-Transaktion erzeugt.

### Wie wird DTMF in SIP gesendet?

Am häufigsten als RTP-Telephone-Event-Pakete (RFC 4733) im Medienstrom und alternativ über SIP-INFO-Nachrichten, die die Ziffern im Signalisierungspfad tragen. RTP-Telephone-Event wird bevorzugt, weil es zeitlich zum Audio passt.

### Welche Methode leitet einen Anruf weiter?

REFER (RFC 3515). Es bittet den Empfänger, einen neuen Request (typischerweise ein INVITE) an einen im Refer-To-Header genannten Dritten zu initiieren, und implementiert so die Anrufweiterleitung. NOTIFY-Nachrichten melden dann den Fortschritt des weitergeleiteten Anrufs an den Weiterleitenden zurück.

## Quellen

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

## Verwandte Seiten

- [SIP-Protokollübersicht](https://www.broadnet.me/de/reference/sip-protocol-overview)
- [SIP-Antwortcodes](https://www.broadnet.me/de/reference/sip-response-codes)
- [SIP-Header](https://www.broadnet.me/de/reference/sip-headers)
- [SIP-Anrufverlauf](https://www.broadnet.me/de/reference/sip-call-flow)
- [Voice API & SIP-Trunking](https://www.broadnet.me/de/answers/voice-api-sip-trunking)