imported>Fichi: Gramatik korrigiert

2026-03-12T10:00:54Z

Gramatik korrigiert

Neue Seite

{| class="wikitable float-right"
|+ style="background:#C0C0FF; font-size:larger;"| SIP (Session Initiation Protocol)
|-
| '''Familie:'''
| [[Internetprotokollfamilie]]
|-
| '''Einsatzgebiet:'''
| Verwaltung von Streaming-Sitzungen
|-
| '''Port:''' || 5060<br /> 5061 ([[Transport Layer Security|TLS]]-Verschlüsselung)
|-
|colspan="2"|
{{Netzwerk-TCP-UDP-IP-Anwendungsprotokoll|SIP|class="center"}}
|-
| '''Standards:'''
| <nowiki>RFC 3261</nowiki> (SIP, 2004)<ref name="RFC3261" />
|}

Das '''Session Initiation Protocol''' ('''SIP''') (engl. für ''Sitzungs-Initiierungs-Protokoll'' oder auch ''Einleitungs-Protokoll'') ist ein [[Netzwerkprotokoll|Netzprotokoll]] zum Aufbau, zur Steuerung und zum Abbau einer [[Sitzung (Informatik)|Kommunikationssitzung]] zwischen zwei und mehr Teilnehmern. Das Protokoll wird u. a. im <nowiki>RFC 3261</nowiki><ref name="RFC3261" /> [[Spezifikation|spezifiziert]] und häufig in der [[IP-Telefonie]] angewandt.

== Funktionsweise ==
=== Konkurrent H.323 ===
Im Gegensatz zu [[H.323]], das von der [[Internationale Fernmeldeunion|ITU-T]] stammt, wurde SIP von der [[Internet Engineering Task Force|IETF]] entwickelt. H.323 kann stark vereinfacht als [[ISDN over IP]] bezeichnet werden. Dies erlaubte zwar insbesondere den [[Telefonanlage]]n<nowiki></nowiki>herstellern, vergleichsweise schnell und einfach die Kommunikation auf IP-Netzwerke umzustellen, andererseits wurden die Stärken und Schwächen dieser Netze nicht genügend berücksichtigt. Augenscheinlich wird dies insbesondere im Zusammenhang mit [[Network Address Translation|NAT]], der vor allem bei [[Firewall]]s und [[Endkunde]]n<nowiki></nowiki>netzen (z. B. [[Digital Subscriber Line|DSL-Routern]]) notwendigen Übersetzung von [[Netzwerkadresse]]n, welche bei H.323 nur mit viel Aufwand erreicht werden kann.

=== Design ===
Das Design des SIP dagegen lehnt sich an das [[Hypertext Transfer Protocol]] an (ist zu diesem aber ''nicht'' [[Kompatibilität (Technik)|kompatibel]]) und ist deutlich besser für IP-Netze geeignet.

Der Aufbau von SIP erlaubt es, auf einfache Weise neue [[Plug-in|Erweiterung]]en einzufügen, ohne dass alle involvierten [[Endgerät|Gerät]]e diese verstehen müssen.

Auch ist es allgemeiner gehalten: Während H.323 nur für Telefonie gedacht ist, können mit SIP Sitzungen beliebiger Art verwaltet werden. Die „[[Nutzdaten|Nutzlast]]“ der Sitzung, also die eigentlichen zu übertragenden [[Datenstrom|Datenströme]], können alle Ströme sein, die sich über ein Netzwerk übertragen lassen. Das Haupteinsatzgebiet findet sich in der Audio- und Video-Übertragung, einige [[Online-Spiel]]e greifen zur Verwaltung der Übertragung ebenfalls auf SIP zurück.<ref>Aameek Singh, Arup Acharya: [https://conferences.sigcomm.org/sigcomm/2004/workshop_papers/net503-singh1.pdf Using Session Initiation Protocol to build Context-Aware VoIP Support for Multiplayer Networked Games.] (PDF; 277 kB) conferences.sigcomm.org</ref>

=== Eingebettetes SDP ===
[[Datei:SIP signaling.svg|mini|400px]]
Um ein [[IP-Telefonie|Internet-Telefonat]] zu führen, braucht man mehr als nur SIP, denn es dient lediglich dazu, die Bedingungen für die [[Nachrichtenverbindung|Verbindung]] zu vereinbaren bzw. auszuhandeln – die eigentlichen Daten für die Kommunikation müssen über andere, dafür geeignete Protokolle ausgetauscht werden. Hierzu wird in SIP häufig das ''[[Session Description Protocol]]'' eingebettet (SDP, <nowiki>RFC 4566</nowiki>,<ref>{{RFC-Internet |RFC=4566 |Titel=SDP: Session Description Protocol |Datum=2006-07}}</ref> die Übersetzung aus dem [[Englische Sprache|Englischen]] „Sitzungs-Beschreibungs-Protokoll“ ist nicht gebräuchlich). Dabei teilen sich die Geräte gegenseitig mit, welche Methoden der Video- und Audio-Übertragung sie beherrschen (die ''[[Codec]]s''), mit welchem Protokoll sie das tun möchten und an welcher [[Netzadresse]] sie senden und empfangen wollen. Diese Medien-Aushandlung ist also kein direkter Bestandteil von SIP, sondern wird durch die Einbettung eines weiteren Protokolls erreicht.

=== RTP ===
Für die Medienübertragung wird bei der Internet-Telefonie das ''[[Real-Time Transport Protocol]]'' (RTP, deutsch ''Echtzeit-Transportprotokoll'', <nowiki>RFC 3550</nowiki><ref>{{RFC-Internet |RFC=3550 |Titel=RTP: A Transport Protocol for Real-Time Applications |Datum=2003-07}}</ref>) verwendet.

=== Stack ===
Der [[Protokollstack]] stellt sich also wie folgt dar:
* SIP handelt die Sitzung aus
* das eingebettete SDP handelt die Medien-Details aus
* RTP ist dann dasjenige Protokoll, welches letztendlich die Video- und Audio-Ströme überträgt.

=== Teilnehmer-Adressen ===
[[Teilnehmer (Kommunikationssystem)|Teilnehmer]]-[[Netzwerkadresse|Adresse]]n werden im [[Uniform Resource Identifier|URI]]-Format geschrieben, welches auch in [[E-Mail]]s und [[World Wide Web|WWW]]-Adressen verwendet wird. Solch eine Teilnehmer-Adresse folgt meist einem der folgenden drei [[Schema (Informatik)|Schema]]ta:
* Unverschlüsselte SIP-[[Nachrichtenverbindung|Verbindung]]: <code><nowiki>sip:user@domain</nowiki></code>.
* Verschlüsselte SIP-Verbindung: <code><nowiki>sips:user@domain</nowiki></code> (s. u.).
* Telefonnummer: <code><nowiki>tel:nummer</nowiki></code>, zum Beispiel <code><nowiki>tel:+49-69-1234567</nowiki></code>. Dieses Schema wird vor allem von Geräten verwendet, die eine Schnittstelle in das „normale“ [[Telefonnetz]] bereitstellen und kann bei Bedarf in eine SIP-[[Uniform Resource Identifier|URI]] gewandelt werden, z. B. in <code><nowiki>sip:+49-69-1234567@domain</nowiki></code>.

=== Verschlüsselung und Sicherheit ===
Durch die Trennung von Sitzung und Medien können beide [[Datenstrom|Datenströme]] auch unabhängig voneinander [[Verschlüsselung|verschlüsselt]] werden. Man kann SIP über das [[Transport Layer Security|TLS]]-Protokoll, auch SIPS genannt, verschlüsseln und den Medienstrom (Sprachdaten) ebenfalls über das [[Secure Real-Time Transport Protocol|SRTP]]. Jede Kombination davon ist möglich, allerdings in Hinsicht auf eine sichere Verschlüsselung nicht sinnvoll.

Zwecks einer sicheren Verschlüsselung müssen beide Datenströme (also Sitzung und Medien) gleichzeitig verschlüsselt werden.
* Die [[Symmetrisches Kryptosystem|symmetrischen]] [[Schlüssel (Kryptologie)|Schlüssel]] des Medienstroms werden über SDP (also SIP) [[Diffie-Hellman-Schlüsselaustausch|ausgetauscht]] und wären damit über ein unverschlüsseltes SIP angreifbar.
* Die symmetrischen Schlüssel von TLS werden zwar am Anfang der Sitzung auch ausgetauscht, jedoch greifen hier die Mechanismen der [[Extended-Validation-Zertifikat|TLS-Zertifikate]], bei denen die symmetrischen Schlüssel wiederum durch die [[Asymmetrisches Kryptosystem|asymmetrischen]] Schlüssel der TLS-Zertifikate verschlüsselt sind.

Da bei SIP eine Übertragung über ein verbindungsloses Netzwerkprotokoll sinnvoller ist, wurde mit [[Datagram Transport Layer Security|DTLS]] ein auf [[User Datagram Protocol|UDP]] basierendes [[Pendant]] zu TLS entworfen, welches auf [[Transmission Control Protocol|TCP]] aufbaut. Allerdings wird es gegenwärtig nur von einem SIP-Stack (nämlich von ReSIProcate) [[implementiert]].

== Netzwerk-Elemente ==
=== User Agent ===
Der [[User Agent]] (UA) ist eine [[Schnittstelle]] zum Be[[nutzer]], die Inhalte darstellt und Befehle entgegennimmt. Auch ein [[SIP-Telefon]] ist ein SIP User Agent, der die traditionellen Ruffunktionen eines Telefons wie Zifferneingabe, Annehmen, Abweisen und Halten bietet.

=== Proxy Server ===
[[Datei:SIP call flow between UA, Redirect Server, Proxy and UA.png|mini|Anruffluss durch Redirect Server und Proxy]]
Ein [[Proxy Server]] ist eine Kommunikationsschnittstelle in einem [[Netzwerk]]. Er arbeitet als [[Routing|Vermittler]], der auf der einen Seite Anfragen entgegennimmt, um dann über seine eigene Adresse eine Verbindung zu einer anderen Seite herzustellen. Er soll sicherstellen, dass Anfragen gezielt an den Benutzer gesendet werden. Proxys sind auch für die Durchsetzung der [[Hierarchie]] nötig.

=== Redirect Server ===
Der Redirect Server entlastet den Proxy Server. Er übergibt die Routing-Informationen direkt an den User Agent Client. Er erzeugt [[Weiterleitung]]en, um eingehende Anträge in einer alternativen Gruppe von [[Uniform Resource Identifier|URIs]] kontaktieren zu können. Der Redirect Server ermöglicht es, SIP-Session-Einladungen an externe Domänen zu übermitteln.

=== Registrar Server ===
[[Datei:SIP-registration-flow.png|mini|SIP UA-Registrierung auf SIP-Registrar mit Authentifizierung durch Login]]
Der Registrar Server dient als zentrale Schaltstelle in der [[Systemarchitektur]] von SIP. Er übernimmt das Registrieren von Anfragen für die [[Domain (Internet)|Domain]], die er verarbeitet. Er bearbeitet eine oder mehrere [[IP-Adresse]]n zu einer bestimmten SIP-URI, die durch das SIP-Protokoll übermittelt werden.

=== Session Border Controller ===
Ein [[Session Border Controller]] ist eine [[Netzwerkkomponente]] zur sicheren Kopplung von [[Rechnernetz]]en mit unterschiedlichen Sicherheitsanforderungen. Er dient als mittlerer Knoten zwischen User Agent und SIP-Server für verschiedene Arten von Funktionen, einschließlich der Unterstützung der [[Network Address Translation|Network Address Translation (NAT)]].

=== Gateway ===
Ein [[Media Gateway|Gateway]] kann als Schnittstelle ein SIP-Netz mit anderen Netzen verbinden, die unterschiedliche Protokolle oder Technologien verwenden, z. B. mit dem öffentlichen [[Fernsprechnetz]].

=== B2BUA ===
[[Datei:SIP-B2BUA-call-flow.png|mini|Einrichtung einer Verbindung mit dem B2BUA]]
B2BUA - (auf Englisch Back-to-Back-User-Agent, wörtlich: der User-Agent "Rücken an Rücken") ist eine [[Middleware]] sowohl im SIP- als auch im [[Real-Time Transport Protocol|RTP]]-[[Datenstrom]]. Gegenüber SIP-Clients verhält sich ein B2BUA wie ein User-Agent-Server auf der einen Seite der Verbindung und wie ein User-Agent-Client auf der anderen. Sinn ist es, die Datenströme manipulieren zu können.
Der B2BUA wird im <nowiki>RFC 3261</nowiki><ref name="RFC3261" /> spezifiziert.

Beispiele für die Anwendung:
* Gesprächsmanagement (u. a. [[Abrechnung]], Anrufweiterleitung, automatische Abschaltung)
* Paarung unterschiedlicher Netzwerke (insbesondere die verschiedenen Dialekte der Protokolle anzupassen, je nach Hersteller)
* Ausblenden der [[Netzwerkstruktur]] (u. a. private Adressen, [[Netzwerktopologie]]).
Grundsätzlich lässt sich ein B2BUA zu einem Proxy mit integriertem Mediagateway ausbauen.

== SIP-Nachrichten ==
Die an einer SIP-Session beteiligten Clients und Server senden sich Anfragen (englisch „requests“) und beantworten diese mittels Antwort-Codes (englisch „responses“).

=== SIP-Anfragen ===
{{Hauptartikel|SIP-Anfragen}}
<nowiki>RFC 3261</nowiki><ref name="RFC3261" /> definiert sechs Anfragen: REGISTER, INVITE, ACK, CANCEL, BYE und OPTIONS.

=== SIP-Status-Codes ===
{{Hauptartikel|SIP-Status-Codes}}
; 1xx – Provisional: Vorläufige Statusinformationen, dass der Server weitere Aktionen durchführt und deshalb noch keine endgültige Antwort senden kann.
; 2xx – Successful: Die Anfrage war erfolgreich.
; 3xx – Redirection: Diese Nachrichten informieren über eine neue Kontaktadresse des Angerufenen oder über andere Dienste, die es ermöglichen die Verbindung erfolgreich aufzubauen.
; 4xx – Request Failures: Die vorangegangene Nachricht konnte nicht bearbeitet werden.
; 5xx – Server Failures: Ein an der Übermittlung beteiligter Server konnte eine Nachricht nicht bearbeiten.
; 6xx – Global Failures: Der Server wurde zwar erfolgreich kontaktiert, jedoch kommt die [[Transaktion (Informatik)|Transaktion]] nicht zustande.

== Verbreitung ==
Unterstützung findet SIP bereits in vielen Geräten diverser Hersteller und scheint sich zum Standard-Protokoll für Voice over IP ([[IP-Telefonie|VoIP]]) zu entwickeln. SIP wurde auch vom ''[[3rd Generation Partnership Project]]'' (3GPP) als Protokoll für [[Multimedia]]<nowiki></nowiki>unterstützung im 3G-[[Mobilfunk]] ([[Universal Mobile Telecommunications System|UMTS]]) ausgewählt. Auch die Spezifizierung des ''[[Next Generation Network]]'' (NGN) beim ''[[Europäisches Institut für Telekommunikationsnormen|European Telecommunications Standards Institute]]'' (ETSI) der Projektgruppe ''Telecommunications and Internet converged Services and Protocols for Advanced Networking'' (TISPAN) stützt sich auf SIP.

== Vor- und Nachteile ==
Zu den Vorteilen von SIP gehört, dass es sich hierbei um einen [[Offener Standard|offenen Standard]] handelt, der mittlerweile sehr weite Verbreitung gefunden hat.

Da SIP-Server [[Verteiltes System|verteilt]] sind, betrifft ein [[Cyberangriff|Angriff]] nur den jeweiligen Anbieter und nicht die gesamte über SIP vermittelte Telefonie.

Ein weiterer Vorteil von SIP ist die Möglichkeit, eine bereits etablierte Sitzung modifizieren zu können. Dazu wird innerhalb der Sitzung eine weitere INVITE-Message mit den neuen [[Session Description Protocol|SDP]]-Sitzungseigenschaften an die Gegenseite gesendet. Somit kann ein neues Medium hinzugefügt oder ein bestehendes Medium modifiziert bzw. entfernt werden. Die entsprechende Nachricht wird auch als ''Re-INVITE Request'' bezeichnet.

Die Trennung von Sitzungs- und Medienaushandlung ist ein weiterer Vorteil von SIP, da sie eine große Flexibilität bei der unterstützten [[Nutzdaten|Nutzlast]] erlaubt: möchte z. B. ein Hersteller SIP für eine spezialisierte [[Anwendungssoftware|Anwendung]] verwenden, so kann er dafür eine eigene Medienaushandlung entwerfen, falls dafür noch kein Protokoll existiert.

=== NAT-Traversal ===
Ein Nachteil von SIP ist, dass es zur Übertragung der Sprachdaten auf [[Real-Time Transport Protocol|RTP]] zurückgreift. Die dafür verwendeten [[User Datagram Protocol|UDP]]-Ports werden dynamisch vergeben, was die Verwendung von SIP in Verbindung mit [[Firewall]]s oder [[Network Address Translation]] (NAT, <nowiki>RFC 2663</nowiki><ref>{{RFC-Internet |RFC=2663 |Titel=IP Network Address Translator (NAT) Terminology and Considerations |Datum=1999-08}}</ref>) schwierig macht, da die meisten Firewalls bzw. NAT-Router die dynamisch vergebenen Ports nicht der Signalisierungsverbindung zuordnen können. Abhilfe für dieses Problem schafft der Einsatz von STUN ([[Session Traversal Utilities for NAT]]), welches NAT-Router erkennt und durchdringt, aber auch andere Protokolle wie [[InterAsterisk eXchange|IAX]] (InterAsterisk eXchange). Durch den Einsatz des STUN-Protokolls werden die IP-Adresse und der Port ermittelt, mit dem die NAT-Firewall bzw. der NAT-Router nach außen (d. h. in das öffentliche Internet) geht. Eine deutlich einfachere Methode dieses Problem zu umgehen ist, dass der Proxyserver bzw. der gerufene Teilnehmer direkt auf die IP-Adresse und den verwendeten Port im IP-Header zurückgreift, wodurch der NAT-Mechanismus auch ohne STUN-Server wieder greift. [[InterAsterisk eXchange|IAX]] kombiniert Signalisierung und Mediendaten auf einer UDP-Verbindung. Wie H.323 ist IAX ein binäres Protokoll, weshalb die Fehlerbehebung schwieriger als bei SIP ist. Zudem befindet sich IAX erst in der Standardisierungsphase.

Ein neueres Verfahren der [[Internet Engineering Task Force|IETF]] zur Lösung des NAT-Traversal-Problems stellt [[Interactive Connectivity Establishment]] (ICE) dar, welches schon von einigen SIP-[[Client]]s unterstützt wird und meist per [[Firmware]]-Upgrade installiert werden kann.

Eine weitere Technik zum NAT-Traversal stellen sogenannte [[Application Layer Gateway]]s (ALG) dar. Diese sind zwischengeschaltete SIP-[[Proxy (Rechnernetz)|Proxys]], die – auf einem NAT-Router bzw. einer Firewall installiert – für reibungslosen Transfer der SIP-Signalisierung und -Medienströme sorgen sollen. Ein ALG kann bei SIP-Telefonaten automatisch für die Öffnung der notwendigen Ports auf einer Firewall sorgen sowie [[Real-Time Transport Protocol|RTP]]-Medienströme mit [[DiffServ]]-Bits markieren, wodurch die Medien-Pakete mit höherer Priorität über IP-Netze transportiert werden können, wenn ein Netz dieses unterstützt. Das Internet bietet grundsätzlich keine Priorisierung, siehe [[Netzneutralität]]. In der Praxis werden die Pakete jedoch meist an eine nicht dafür vorgesehene IP-Adresse geliefert (an den Server resp. Proxy anstatt an das dafür vorgesehene Endgerät), weshalb in vielen Konfigurationen und als Vorgabe von vielen VoIP-Anbietern SIP-ALG abzuschalten ist, um überhaupt Verbindungen herstellen zu können.

Bei der Nutzung von IPv6 als Transportprotokoll entfällt in der Regel NAT und damit auch die Notwendigkeit die NAT-typischen Probleme zu umschiffen. Lediglich die Problematik der Firewall bleibt identisch.

== Beispiele ==
{|
|-
| So könnte ein '''SIP-Request''' aussehen:
|  
|Und so eine '''SIP-Response''':
|-
|
{|
|-
| Startzeile
|class="hintergrundfarbe6"| INVITE <nowiki>sip:8495302002@192.168.2.25</nowiki> SIP/2.0
|-
| [[Header]]
|class="hintergrundfarbe8"| Via: SIP/2.0/UDP 192.168.3.250:5060; branch=1

From: <nowiki>sip:8495305005@192.168.2.25;tag=29ae1249</nowiki>

Max-Forwards: 70

To: <nowiki>sip:8495302002@192.168.2.25</nowiki>

Call-ID: 48c7df2a9b4@myvoip1

Cseq: 1 INVITE

Contact: <nowiki>sip:8495305005@192.168.3.250</nowiki>

Content-Length: 202

Supported: 100rel

Content-Type: application/sdp
|-
| Leerzeile
|-
| Body ([[Session Description Protocol|SDP]])
|class="hintergrundfarbe7"| v=0

o=Anonymous 1234567890 1234567890 IN IP4 192.168.3.250

s=SIGMA is the best

c=IN IP4 192.168.3.250

t=0 0

m=audio 6006 RTP/AVP 8 3 0

a=rtpmap:8 PCMA/8000

a=rtpmap:3 GSM/8000

a=rtpmap:0 PCMU/8000
|}
|  
|
{|
|-
|Startzeile
|class="hintergrundfarbe6"| SIP/2.0 200 OK
|-
|Header
|class="hintergrundfarbe8"| Via: SIP/2.0/UDP 192.168.2.25:5060;branch=z5K8DSbCGCL8593033654

From: <nowiki>sip:8495305005@192.168.2.25;tag=6248550609-457625817474016</nowiki>

To: <nowiki>sip:8495302002@192.168.3.251;user=phone;tag=2e679cbc</nowiki>

Call-ID: 6248550609-781762546450147

Cseq: 15 INVITE

Contact: <nowiki>sip:8495302002@192.168.3.251</nowiki>

Content-Length: 191

Content-Type: application/sdp
|-
|Leerzeile
|-
|Body (SDP)
|class="hintergrundfarbe7"| v=0

o=Anonymous 1234567890 7894561230 IN IP4 192.168.3.251

s=SIGMA is the best

c=IN IP4 192.168.3.251

t=0 0

m=audio 6006 RTP/AVP 8 0

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000
|}
|}

== Siehe auch ==
* [[SIP for Instant Messaging and Presence Leveraging Extensions]]
* [[Telephone Number Mapping|Telephone Number Mapping (ENUM)]]
* [[IP Multimedia Subsystem]]

== Spezifikationen ==
* {{RFC-Internet |RFC=2543 |Titel=SIP |Datum= |Kommentar=veraltete Version}}
* {{RFC-Internet |RFC=3261 |Titel=SIP: Session Initiation Protocol |Datum=2002-06 |Kommentar=aktuell}}
* {{RFC-Internet |RFC=3265 |Titel=Session Initiation Protocol (SIP) – Specific Event Notification |Datum=2002-06 |Kommentar=Erweiterung}}
* {{RFC-Internet |RFC=3515 |Titel=SIP Update: SIP Refer Method |Datum=}}
* {{RFC-Internet |RFC=3665 |Titel=SIP Basic Call Flow Examples |Datum=}}
* {{RFC-Internet |RFC=3581 |Titel=SIP Update: Symmetric Response Routing |Datum=}}
* {{RFC-Internet |RFC=3853 |Titel=SIP Update: Benutzung von AES statt 3DES |Datum=}}
* {{RFC-Internet |RFC=4320 |Titel=SIP Update: Issues with the SIP Non-INVITE Transaction |Datum=}}
* {{RFC-Internet |RFC=4916 |Titel=Connected Identity in the Session Initiation Protocol |Datum=}}

== Literatur ==
* Ulrich Trick, Frank Weber: ''SIP und Telekommunikationsnetze. Next Generation Networks und Multimedia over IP - konkret''. De Gruyter Oldenbourg, 2015, ISBN 978-3-486-77853-3.

== Weblinks ==
* [https://datatracker.ietf.org/wg/sipcore/about/ SIP Core Working Group.] ietf.org
* [https://www.tech-invite.com/ SIP/IMS Technical Portal.] tech-invite.com

== Einzelnachweise ==
<references>
<ref name="RFC3261">
{{RFC-Internet |RFC=3261 |Titel=SIP: Session Initiation Protocol |Datum=2002-06}}
</ref>
</references>

[[Kategorie:Internet-Anwendungsprotokoll]]
[[Kategorie:VoIP]]

Session Initiation Protocol - Versionsgeschichte

imported>Fichi: Gramatik korrigiert