Zum Inhalt springen
Unabhängige Referenz zum Future Railway Mobile Communication System

Anwenden · 2.5

SIP und IMS im FRMCS-Kontext

Zeit: etwa 8–11 Minuten einschliesslich Aufgabe; Schätzung

Leitfrage: Wie unterscheiden sich Registrierung, Sitzungssteuerung und Medienübertragung?

Lernziel: Du liest einen vereinfachten SIP-Ablauf und ordnest IMS-Funktionen ein.

Voraussetzungen: Die vorausgehenden Lektionen bis 2.4; insbesondere die dort erklärte Fallakte.

Warum der Anruf Steuerinformationen braucht

Lea möchte Niko erreichen. Bevor Sprache nutzbar ausgetauscht wird, müssen beteiligte Softwarefunktionen eine Sitzung aufbauen und passende Medienbedingungen vereinbaren. SIP, das Session Initiation Protocol, überträgt dafür Anfragen und Antworten. IMS, das IP Multimedia Subsystem, ist eine Architektur, in der SIP-basierte Dienste organisiert werden. SIP ist damit ein Protokoll; IMS beschreibt zusammenarbeitende Funktionen. [S21]

Ein SIP User Agent ist die Software, die SIP-Anfragen erzeugt oder beantwortet. Ein Proxy leitet Anfragen entsprechend den vorgesehenen Routingregeln weiter. Ein Registrar bearbeitet Registrierungen und ordnet eine SIP-Adresse einer aktuellen Kontaktadresse zu. Registrierung schafft damit Erreichbarkeitsinformation; sie ist noch kein Gespräch.

IMS-Funktionen sinnvoll einordnen

In der IMS-Terminologie begegnen dir P-, I- und S-CSCF. CSCF steht für Call Session Control Function. Die Proxy-CSCF (P-CSCF) ist der erste SIP-Kontaktpunkt auf der IMS-Seite; die Interrogating-CSCF (I-CSCF) unterstützt die Auswahl beziehungsweise Auffindung der zuständigen Steuerung beim Eintritt in ein Heimnetz; die Serving-CSCF (S-CSCF) übernimmt zentrale Registrierungs- und Sitzungssteuerungsaufgaben. Ein Application Server führt die für einen Dienst vorgesehene Logik aus. Die Namen bezeichnen logische Aufgaben und nicht zwingend getrennte Geräte. [S49, Abschnitt 4]

Für FRMCS betrachten wir den spezifizierten SIP Core und seine Anbindung an MCX. Ein beliebiges IMS-Produkt erfüllt nicht automatisch das erforderliche FRMCS-Profil. Die allgemein erklärte IMS-Funktionssicht muss deshalb auf die tatsächlich verwendeten Schnittstellen und Verfahren abgebildet werden. [S09, Abschnitt 5.1.2]

Einen SIP-Ablauf lesen

Zwei Verfahrensgruppen trennen Registrierung und Sitzung; RTP ist der Medienweg.
G11 · Eigene vereinfachte Lehrdarstellung. Zwei Verfahrensgruppen trennen Registrierung und Sitzung; RTP ist der Medienweg.

Grafik in voller Grösse öffnen (SVG, neuer Tab) G11

Der Lehrablauf zeigt eine SIP-Sitzung, noch keinen vollständigen bahnspezifischen Ruf. REGISTER richtet beziehungsweise erneuert die SIP-Registrierung. Eine erfolgreiche Registrierung bestätigt nicht automatisch die Autorisierung für jeden MC-Dienst. INVITE fordert eine Sitzung an; eine Antwort der Klasse 1xx beschreibt einen vorläufigen Zustand. 200 OK ist eine erfolgreiche abschliessende Antwort auf die betreffende Anfrage. ACK bestätigt die erfolgreiche INVITE-Antwort. BYE beendet eine bestehende Sitzung. CANCEL würde dagegen eine noch offene Anfrage abbrechen und ist kein Ersatz für BYE. [S21]

SDP, das Session Description Protocol, beschreibt Medienparameter, beispielsweise Medienart und Codec-Angebote. Ein Codec legt fest, wie Audio digital dargestellt wird. Beim Offer/Answer-Verfahren bietet eine Seite Parameter an und die andere antwortet mit einer passenden Auswahl. SDP überträgt nicht selbst die Sprache. RTP übernimmt im Sprachbeispiel den zeitbezogenen Medientransport. Die konkreten MCPTT-Erweiterungen kommen in der Sprachlektion hinzu. [S22; S43; S44]

Drei Anmeldungen nicht verwechseln

Die Anmeldung im Mobilfunknetz ermöglicht zunächst dessen Nutzung. Die SIP-Registrierung stellt SIP-Erreichbarkeit her. Die MC-Dienstautorisierung entscheidet über den erlaubten Dienstzugriff. Beim Fehlersuchen wird jede Bestätigung ihrem Verfahren zugeordnet. Ein SIP 200 OK auf REGISTER ist kein erfolgreicher Rufaufbau; ein 200 OK auf INVITE ist kein Audioempfangsnachweis.

Prüfe dein Verständnis

Ein Mitschnitt enthält ein erfolgreiches REGISTER und später INVITE, 200 OK und ACK. Niko hört dennoch nichts. Was ist belegt, was fehlt, und weshalb hilft ein Blick auf die Medienparameter?

Musterantwort

Belegt sind die beobachtete Registrierung und der erfolgreiche SIP-Aufbauabschnitt. Es fehlen unter anderem dienstspezifische Sprechberechtigung, passender Medienfluss und Audioausgabe. Medienparameter helfen zu prüfen, ob Sender und Empfänger kompatible Audioformate und den richtigen Empfangsweg verwenden. Sie beweisen für sich weder Paketankunft noch Lautsprecherfunktion.

Das nimmst du mit

SIP steuert Sitzungen, SDP beschreibt Medienbedingungen, RTP trägt Sprachmedien. IMS ordnet Steuerungsfunktionen; MCX ergänzt dienstspezifisches Verhalten.

Deine Talbahn-Fallakte

Ergänze eine Spur mit Nachricht, Verfahren, Sender, Empfänger und Aussagegrenze. Notiere getrennt die drei Anmeldezustände.

Quellen

  • S09 · ETSI TS 103 765-2: FRMCS Service Stratum

    ETSI TS 103 765-2: FRMCS Service Stratum

    Version: 1.1.1, Januar 2026 · Geprüft: 2026-10-11

    Bezug: Dienstarchitektur; Begriffsdefinition SIP Core; Registrierung und MC-Dienste.

    Geltungsgrenze: IMS und SIP nicht gleichsetzen; Architektur erlaubt die spezifizierten SIP-Core-Alternativen.

    Verwendet in: 1.9, 2.1, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9, 2.10, 2.14, 2.19, 2.22, 3.5, 3.16

  • S21 · IETF RFC 3261: SIP

    IETF RFC 3261: SIP

    Version: Juni 2002 · Geprüft: 2026-10-11

    Bezug: Sitzungsaufbau, Änderung und Beendigung.

    Geltungsgrenze: SIP-Grundlagen, kein vollständiger MCPTT-Ablauf.

    Verwendet in: 2.5, 3.4

  • S22 · IETF RFC 3550: RTP

    IETF RFC 3550: RTP

    Version: Juli 2003 · Geprüft: 2026-10-11

    Bezug: Echtzeitmedien und zeitliche Zuordnung.

    Geltungsgrenze: RTP bietet für sich keine Ende-zu-Ende-Qualitätsgarantie.

    Verwendet in: 2.5

  • S43 · IETF RFC 8866: SDP

    IETF RFC 8866: SDP

    Version: 2021 · Geprüft: 2026-10-11

    Bezug: Beschreibung von Medienparametern.

    Geltungsgrenze: Benannte Lehrausgabe; keine pauschale Produkt- oder Projektfreigabe.

    Verwendet in: 2.5

  • S44 · IETF RFC 3264: Offer/Answer

    IETF RFC 3264: Offer/Answer

    Version: 2002 · Geprüft: 2026-10-11

    Bezug: Angebot und Antwort für Medienbedingungen.

    Geltungsgrenze: Benannte Lehrausgabe; keine pauschale Produkt- oder Projektfreigabe.

    Verwendet in: 2.5

  • S49 · 3GPP TS 23.228 / ETSI TS 123 228: IMS

    3GPP TS 23.228 / ETSI TS 123 228: IMS

    Version: 18.10.0 · Geprüft: 2026-10-11

    Bezug: Allgemeine IMS-Architektur, insbesondere Abschnitt 4.

    Geltungsgrenze: Benannte Lehrausgabe; keine pauschale Produkt- oder Projektfreigabe.

    Verwendet in: 2.5

Gemeinsames Quellenregister

Dein Fortschritt wird in diesem Browser auf diesem Gerät gespeichert.