In zwei Jahrzehnten als Vollzeitnerd hat sich der ein oder andere Text angesammelt, mit denen ich unseren Azubis versucht habe, Grundlagen über unseren Job (TCP/IP, aber auch bevorzugt Telefonie) zu erklären.

Das stelle ich hier, wann immer ich so einen Text nochmal irgendwo finde, zusammen. Diese Texte haben nicht den Anspruch, zu 100% exakt zu sein (sondern manches ist des besseres Verständnisses wegen vereinfacht worden). 

Heute:

Das Standard-Protokoll für IP-Telefonie ist "SIP". SIP arbeitet in der Regel auf Port 5060 UDP und funktioniert wie folgt:

Alice schickt Bob eine SIP-Nachricht. Bei einem Anrufversuch wäre das eine INVITE-Nachricht (andere Typen s. unten), also eine Einladung zum Gespräch. Diese sieht so aus

INVITE sip:+492211234567@hostname_des_ziels;transport=udp;user=phone SIP/2.0
From: "+49220312345" <sip:+492203123456@hostname_des_absenders;user=phone>
To: "+492211234567" <sip:+492211234567@hostname_des_ziels;user=phone>
Via: SIP/2.0/UDP 123.45.67.89:5060
Call-ID: cd8550003156-6798612ad-18e0899a-1f15b3e0-2aa8e1c-01
CSeq: 25626 INVITE
Contact: <sip:SBCBRLNDE61@89.90.91.92:5060>
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, INFO, REFER, NOTIFY, SUBSCRIBE, UPDATE
Content-Type: application/sdp
Max-Forwards: 70
User-Agent: SIPTel 3000 fiktiver Provider
Content-Length:   263
[SDP-Teil entfernt, den gucken wir uns später an]

In From und To stehen Absender und Empfänger (also Alice und Bob) drin. Die bleiben für den Rest der Kommunikation gleich (d.h. auch in jeder Antwort, die Bobs Endgeräte oder Server schicken, bleibt Bob in der Rolle des "To:" und Alice bleibt "From"). In diesem Fall sind das beides fiktive Kölner Rufnummern, Alice hat 02203 (Köln-Porz), Bob 0221, und beide sind sie in internationaler e164-Schreibweise verfasst, weil das ein Mitschnitt zwischen zwei Servern war. In der Einleitung schrieb ich aber ja bereits, dass so ein Anruf auch aus vielen Teil-Anrufen bestehen könnte. Wenn Alice an ihrem Yealink-Telefon an einer SwyxWare-Telefonanlage die Rufnummer samt Amts-Null eingetippt hätte, dann wäre in dem Fall der Absender (From-Header) auch der Benutzername, mit dem Alice' Yealink-Telefon am SwyxServer angemeldet ist, und als Ziel (To-Header) wäre noch 002211234567 zu sehen und der SwyxServer würde das dann erstmal in Absender- und Empfänger-Rufnummer umwandeln.

Der via-Header deutet darauf hin, dass es noch einen Mittelsmann gab, der die Pakete per SIP weitergeroutet hat (nicht zu verwechseln mit einem normalen IP-Router). Das führt für eine Einführung aber erstmal zu weit.

Die Call-ID ist eine eindeutige Transaktionsnummer (beide Seiten könnten ja vielleicht verschiedene Anrufe gleichzeitig verarbeiten, und die muss man ja auseinander halten). Zur CSeq komme ich später. Unter Contact steht drin, wo Alice' Server erreicht werden kann, wenn man antworten will. Und welche Arten von Antworten Alice versteht, steht unter ALLOW.

Die "Max-Forwards" sollen unendliche bzw. Kreisroutings verhindern. Dieser Anruf darf noch 70x weiter geleitet werden (über via-Mittelsmänner), jeder dreht dabei die max-forwards einen runter. Wenn irgendwann der Zähler bei Null angekommen ist, dann wird der Versuch erfolglos abgebrochen, weil offenbar Bob nicht gefunden werden kann.

Der User-Agent ist der Name des Endgerätes, der Software, o.ä., das diese INVITE-Nachricht verfasst hat. Dieser INVITE-Nachricht angehängt war ein Inhalt vom Typ "application/sdp" mit einer Länge von 263 Byte, das ist der sog. SDP-Teil (Session Description Protocol), dazu kommen wir später.

Exkurs Rufnummernübermittlung

Neben "From": gibt es auch noch drei Header, die ich oben weggelassen habe, die die Rufnummernsignalisierung steuern:

P-Asserted-Identity: <sip:+492203112345@hostname_des_absenders;user=phone>
P-Preferred-Identity: <sip:+492203123456@hostname_des_absenders>
Privacy: none

Die P-Asserted-Identität ist die Rufnummer des tatsächlichen Anrufers. Die P-Preferred-Identität ist die, die der Anrufer übertragen möchte. Die können abweichend sein, weil ein Mitarbeiter mit Telefon-Durchwahl -10 raustelefoniert, aber die Vertriebsdurchwahl -55 mitschicken will, oder weil jemand "fremde" Nummern mitsenden will (im ISDN-Netz gab es dafür ein Leistungsmerkmal "CLIP no screening"), in dessen Auftrag er anruft. Letztlich braucht man das auch bei einer Rufumleitung: Alice ruft Bob im Büro an, der hat eine Rufumleitung auf sein O2-Handy. Für das Gespräch zu O2 hin wäre Bob der Auftraggeber ("P-Asserted-Identity"), aber natürlich will er auf seinem Handy ja sehen, wer ihn anruft, darum schickt seine Telefonanlage als P-Preferred-Identity dann Alice' Nummer mit.

Soll gar keine Rufnummer übermittelt werden ("anonym"), würde man das über den Header "Privacy: id" (statt wie hier: none) angeben.

Theoretisch ließe sich beides auch nur über den From-Header lösen, man braucht nicht zwingend die drei P-Header dafür:

From: "anonymous" <sip:+492203123456@hostname_des_absenders;user=phone>
      oder
From: "+4980002210221" <sip:+492203123456@hostname_des_absenders;user=phone>

Das sind zwei Möglichkeiten, um die eigene echte Identität (+492203123456) mitzuschicken und trotzdem entweder gar keine Rufnummer ("anonymous") oder eine völlig andere ("0800/02210221") zu zeigen. 

Welche Version ("alt" über den From-Header, oder "neu" über die P-*-Identity-Header) zum Einsatz kommt, ist von Anbieter/Produkt/Konfiguration/... abhängig.

Nun ist SIP ja UDP und damit verbindungslos, d.h. Alice weiß erstmal nicht, ob die Nachricht angekommen ist. Also ist Bob in der Pflicht, so schnell wie möglich zu antworten (denn sonst würde Alice vom Gegenteil ausgehen und die INVITE-Nachricht nochmal abschicken. Und nochmal. Und nochmal).

Die wahrscheinlichste Antwort lautet als das "100 Trying", das sieht so aus:

SIP/2.0 100 Trying
From: "+49220312345" <sip:+492203123456@hostname_des_absenders;user=phone>
To: "+492211234567" <sip:+492211234567@hostname_des_senders;user=phone>
Call-ID: cd8550003156-6798612ad-18e0899a-1f15b3e0-2aa8e1c-01
CSeq: 25626 INVITE

Das 100 Trying ist keine abschließende Antwort, sondern nur eine Eingangsbestätigung, damit Alice weiß, dass das INVITE angekommen ist. Und jetzt kann sich Bob in Ruhe Zeit lassen für die eigentliche Antwort (die dann eben genauso aussieht, nur einen anderen Code statt 100 hat).

From, To und vor allen Dingen die CallID bleiben gleich. Und über das Feld CSeq wird angegeben, auf welche Nachricht (in dem Fall das INVITE mit der Nummer 25626) sich diese Antwort überhaupt bezieht. Denn es könnte ja auch sein, dass Alice danach noch irgendwas anderes geschickt hat (vielleicht den Anruf abgebrochen, weil Alice sich verwählt hat), und darum trägt die Antwort immer die Sequence-Nummer der dazu gehörigen Anfrage, damit man nicht durcheinander kommt.

Nach dem 100 Trying hat Bob also Zeit für die eigentliche Antwort. Die könnte eine der folgenden sein: Entweder, der Anruf wird abgelehnt:

• 302 Moved temporarily - Ist quasi eine Rufumleitung, Bob teilt statt dessen eine neue Rufnummer mit, unter der er erreichbar ist. (Im Zusammenspiel von Systemtelefonen und Rufumleitungen, also z.B. in der Interaktion eines Yealink-Systemtelefons an einem SwyxWare-Server, werden Rufumleitungen aber in der Regel anders gelöst)
• 4xx Fehlercodes lehnen den Anruf aus nicht-technischen Gründen ab, z.B. z.B. 404 Not found = Diese Rufnummer kenne ich nicht, oder 486 Busy here, Bob telefoniert gerade und ist besetzt
• 5xx Fehlercodes, z.B. 500 Internal Server Error lehnt den Anruf aus technischen Gründen (Fehlkonfiguration oder Bob versteht nicht, was Alice will) ab

Oder es klingelt, dafür gibt's zwei Möglichkeiten:

• 180 Ringing: In dem Fall ist Alice' Endgerät selbst dafür verantwortlich, ihr ein "tuuuut .... tuuuuuuut" abzuspielen
• 183 Session Progress heißt: Der Wahlvorgang ist in Bearbeitung und dazu wird Ton übertragen. Das kann ein Klingeln sein (in dem Fall liefert Bob eben den Klingelton selbst aus), das kann aber auch eine Systemansage sein („der gerufene Teilnehmer ist z.Zt. nicht erreichbar“) oder eine Warteansage vorher, ohne dass das Gespräch als angenommen gilt

Und irgendwann geht auch mal jemand ran. Dann lautet die Antwort:

• 200 OK. In dem Fall hat die 200 OK-Nachricht im Anhang nochmal einen SDP-Teil (wie das INVITE auch, nur dieses Mal eben Bobs technische Parameter).

Falls Bob direkt weiß, dass er mit 18x, 200, 301, 4xx oder 5xx antworten muss, hätte er das natürlich auch direkt tun dürfen (und auf das 100 Trying verzichten). Aber für den Fall, dass Bob erstmal selbst gucken muss, wem gehört die Rufnummer überhaupt, wo ist das Gerät dazu, ..., gibt eben das 100 Trying.

Wenn Bob die Antwort direkt auf das INVITE hin schickt, erfolgt von Alice keine Quittung (muss ja nicht: Dadurch dass sie aufhört, INVITEs zu senden, bestätigt sie ja den Empfang der Antwort). Jede weitere Antwort (nach dem 100 Trying kommt ja meist ein 180/183, und nach dem 183 irgendwann hoffentlich ein 200) hingegen muss von Alice mit einem ACK quittiert werden, ansonsten würde Bob sein z.B. 200 OK so lange schicken, bis Alice es quittiert.

Nachdem das 200 OK kam, wird telefoniert. Wie das Gespräch abläuft, das kann man aus den SDP-Nachrichten rauslesen, die beim INVITE bzw. beim 200 OK angehängt waren. Als Beispiel für eine solche Session Description Protocol-Info hier der Teil, der oben beim INVITE dran hing und von mir erstmal weggelassen wurde (nur der relevante Teil):

INVITE sip:+492211234567@hostname_des_ziels;transport=udp;user=phone SIP/2.0
From: "+49220312345" <sip:+492203123456@hostname_des_absenders;user=phone>
To: "+492211234567" <sip:+492211234567@hostname_des_ziels;user=phone>
Call-ID: cd8550003156-6798612ad-18e0899a-1f15b3e0-2aa8e1c-01
CSeq: 25626 INVITE
Content-Type: application/sdp
Content-Length:   263

c=IN IP4 123.45.67.89
m=audio 29772 RTP/AVP 9 8 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

In diesem Fall gibt Alice als connection-info ("c=") an, dass sie den Ton geschickt haben möchte an IP 123.45.67.89, und zwar als Medientyp/-port-Protokoll ("m=") per RTP/AVP (RealTime-Protocol for Audio and Video Conferences und damit UDP) an den UDP-Port 29772 und war bevorzugt in den Formaten 9, 8 oder Typ 101.

Mit den Formaten steuert sie die sog. Codecs (Codierung/Decodierung des Audioverkehrs). Der vermutlich bekannteste Codec für Audio ist MP3, spielt aber bei der Telefonie keine Rolle. Alice interessiert sich mehr für folgende:

• ihre erste Präferenz "9" definiert sie als "G722 mit 8000 Hz", das ist die mit IP-Telefonie eingeführte "HD-Audio"-Qualität
• ihre zweite Präferenz, Typ 8, definiert sie als "PCMA", auch bekannt als G.711 alaw, das ist der in Europa übliche Codec für "ISDN-Sprachqualität"
• und mit 101 meint sie "telephone-event" (auch bekannt als "nach RFC2833"), das ist die Art und Weise, wie DTMF-Tastentöne für die Bedienung von Sprachmenüs usw. übertragen werden sollen
• Und das alles vom Typ "sendrecv", also Alice wird sowohl Ton senden, als auch empfangen.

Bob seinerseits hat in der "200 OK"-Nachricht auch einen SDP-Teil angehängt:

SIP/2.0 200 OK
From: "+49220312345" <sip:+492203123456@hostname_des_absenders;user=phone>
To: "+492211234567" <sip:+492211234567@hostname_des_senders;user=phone>
Call-ID: cd8550003156-6798612ad-18e0899a-1f15b3e0-2aa8e1c-01
CSeq: 25626 INVITE
Content-Type: application/sdp
Content-Length: 273

c=IN IP4 89.90.91.92
m=audio 14378 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

Und damit erfährt nun auch Alice, was Bob sich denn so in seine Richtung vorstellt: RTP-Ton als PCMA (G711) mit DTMF nach RFC2833 ("telephone-event") an die IP 89.90.91.92 auf UDP-Port 14378. Bezogen auf den am Ende auszuwählenden Codec heißt das: 

• Den G722 HD-Audio-Codec hat er Alice nicht angeboten, d.h. entweder kann oder darf (Konfiguration) er den nicht empfangen. Daraus ergibt sich in der Regel auch, dass er umgekehrt Alice' Wunsch nach HD-Audio in die andere Richtung nicht nachkommen wird - einerseits, weil er es nicht kann/darf, und andererseits, weil die Kommunikation in beide Richtung idealerweise mit dem gleichen Codec laufen sollte.
• Falls er ganz andere Codecs kann, behält er das aus dem gleichen Grund für sich (denn er weiß von ihrem INVITE-SDP ja, das sie die nicht versteht)
• Damit bleibt nur das von ihm angebotene PCMA+telephone-event

Das RFC3264, in dem das SDP-Offer/Answer-Modell definiert ist, spricht dabei jeweils von "SHOULD", d.h. ohne triftigen Grund sollte Bob sich bei der Frage, welche Codecs er in welcher Reihenfolge anbietet, nach Alice' Vorschlag richten und beide sollen dann den ersten gemeinsamen Nenner verwenden.  

Falls sich im laufenden Gespräch etwas ändern sollte, können Alice oder Bob ein neues INVITE schicken mit ihren Änderungswünschen, z.B. Zu- oder Abschalten von Video-Codecs oder Umschalten auf T.38 (Faxübertragung als Bilddaten statt als Töne) oder auch das Umschalten von "sendrevc" auf "sendonly" oder "recvonly", wenn z.B. das Gespräch geparkt wird und darum gar keine Töne emfangen bzw. gesendet werden.

Weil das ein erneutes INVITE ist, spricht man dann von "Re-Invite", die SIP-Nachricht dazu heißt aber weiterhin nur INVITE. Der jeweils andere bestätigt das entweder mit 200 OK, oder lehnt es mit 488 Not Acceptable Here ab.

Ebenfalls im laufenden Gespräch könnte einer von beiden einen Transfer an einen Dritten ("Gespräch weiterverbinden") einleiten. Wenn sagen wir mal Alice ihr Gespräch an ihren Bruder verbinden will, schickt sie REFER + Adresse des Bruders an Bob. Bob quittiert das mit 202 Accepted und ruft seinerseits das Ziel (Alice' Bruder) per INVITE an. Sobald der rangeht (200 OK), schickt Bob ein NOTIFY an Alice, damit die Bescheid weiß, und die legt dann auf (BYE). Genau wie bei der Rufumleitung (siehe weiter oben, Antwort 302) läuft aber auch das Weiterverbinden im Zusammenspiel Systemtelefone-an-Telefonanlage unter Umständen ganz anders ab, je nach Produkt.

Wenn das Gespräch gar nicht erst zustande gekommen ist (letzter Status war immer noch 100 Trying oder 180/183 Klingeln), und Alice legt auf, dann schickt sie ein CANCEL als Abbruch-Kommando.

Wenn das Gespräch zustande kam (200 OK), und einer von beiden zum Ende des Telefonats hin auflegt, schickt derjenige ein BYE als Auflege-Kommando.

BYE sip:+492211234567@hostname_des_ziels
From: "+49220312345" <sip:+492203123456@hostname_des_absenders;user=phone>
To: "+492211234567" <sip:+492211234567@hostname_des_ziels;user=phone>
Via: SIP/2.0/UDP 123.45.67.89:5060
Call-ID: cd8550003156-6798612ad-18e0899a-1f15b3e0-2aa8e1c-01
CSeq: 25627 BYE
Contact: <sip:SBCBRLNDE61@89.90.91.92:5060>
Max-Forwards: 70

Auch hier: Das CANCEL oder BYE wird vom jeweils anderen mit einem 200 OK quittiert (man sieht auch hier das Feld CSeq, aus dem hervorgeht, dass sich das OK auf das BYE bezieht):

SIP/2.0 200 OK
From: "+49220312345" <sip:+492203123456@hostname_des_absenders;user=phone>
To: "+492211234567" <sip:+492211234567@hostname_des_senders;user=phone>
Call-ID: cd8550003156-6798612ad-18e0899a-1f15b3e0-2aa8e1c-01
CSeq: 25627 BYE

Typische NAT-Probleme erkennt man u.U. daran, dass eine oder beide Seiten eine Nachricht mehrfach wiederholen (weil durch den NAT-Router die Antwort nicht durchgereicht wird). Ein Beispiel:

• Gespräch wird ganz normal aufgebaut und geführt. Es dauert so lange, dass der NAT-Router vergisst, dass SIP-Provider draußen und SIP-Telefon drinnen mal auf Port 5060 miteinander was zu tun hatten
• Jetzt legt der externe Gesprächspartner auf. Der SIP-Provider schickt ein BYE in Richtung SIP-Telefon, das bleibt aber am NAT-Router hängen und wird nicht ans SIP-Telefon durchgereicht. Das BYE hat gegenüber den vorherigen Nachrichten eine höhere CSeq-Sequenznummer, es ist ja ein neuer Vorgang.
• Der interne Gesprächspartner legt auch auf (NAT-Probleme hin oder her, man hatte sich ja verbal verabschiedet). Das SIP-Endgerät glaubt (weil es kein BYE bekommen hatte), dass es als erstes auflegt und schickt ein BYE an den Server. Dabei verwendet er als Referenz die letzte ihm bekannte CSeq-Nummer (i.d.R. die aus dem INVITE) 
• Der Server versteht das BYE nicht und lehnt es ab (Fehlercode 500, Out of sequence), da die CSeq-Angabe sagt, dass diese Anfrage veraltet sein muss. Gleichzeitig wiederholt er sein BYE (weil ihm dafür noch vom Endgerät das ACK fehlt).
• Das Endgerät erhält das Server-BYE weiterhin nicht (weil der NAT-Router es nicht weiterleitet). Auch das "Out of sequence" bleibt am NAT-Router hängen. Das SIP-Endgerät glaubt daher, der Server habe das Telefon-BYE nicht erhalten/quittiert und schickt es neu raus.
• Das ganze passiert noch ein Dutzend Mal. Der Server lehnt die Telefon-BYEs als out of sequence ab und schickt ein eigenes Server-BYE. Das Telefon erhält keines von beiden und wiederholt sein eigenes Telefon-BYE.
• Irgendwann nach 10 Versuchen geben beide auf. Der Benutzer bekommt davon gar nichts mit.

Auch wenn das NAT-Problem in diesem Zustand harmlos war, ist es deutlich erkennbar und man könnte die Tatsache, dass da Probleme auftreten, eindeutig nachweisen und einkreisen.

Neben INVITE, das wir ja jetzt kennen, sind noch folgende SIP-Nachrichten-Typen wichtig:

REGISTER

Eine Neu- oder Erneuerungs-Registrierung am SIP-Server. REGISTERs gibt es üblicherweise nicht zwischen Servern (die steuert man über IP-Adressen statt über „Accounts“ an), aber so gut wie immer bei Endgeräten (die registrieren sich am Server unter Vorlage von Zugangsdaten, damit der Server danach weiß, wo er das Gerät erreichen kann). In dem Fall ist Alice das Endgerät und Bob der Server.

Beim REGISTER kommen immer ChallengeResponse-Verfahren zum Einsatz, das heißt:

• Zuerst kommt ein REGISTER von Alice nur mit dem Usernamen ohne Passwort
• Dann kommt als Antwort von Bob ein 401 Unauthorized („Du kommst hier nicht rein“) gefolgt von einer Challenge, d.h. einer kryptografischen Aufgabe ("verschlüssle mir bitte einmal folgenden Zufallstext und verwende dabei das SIP-Passwort als Schlüssel")
• Jetzt verschlüsseln beide Seiten (Alice und Bob) diesen Zufallstext. Sofern beide das gleiche Passwort haben, sollten sie auch auf das gleiche Ergebnis kommen.
• Alice schickt ein neues REGISTER. Im Anhang aber die Response, d.h. die Lösung auf die Aufgabe (das Ergebnis der Verschlüsselung). 
• Bob braucht das nur noch mit seinem eigenen Ergebnis vergleichen und kann so prüfen, ob Alice das richtige Passwort hatte (und antwortet dann mit 200 OK).
• Ein "ACK" ist danach nicht erforderlich, denn Alice weiß ja, dass Bob ihr REGISTER erhalten hat (er hat ja mit 200 OK geantwortet), und Bob weiß, dass Alice sein 200 OK erhalten hat (denn sonst würde sie ja ihr REGISTER sicherheitshalber wiederholen).

Der Vorteil von Challenge Response ist, dass das eigentliche Passwort nicht übertragen werden muss (trotzdem kann Bob prüfen, ob Alice es kennt). Und da Bob die Challenge alle paae Sekunden ändert, kann ein Angreifer auch nicht mit einer früheren Response behaupten, er sei Alice.

Dieses ganze Verfahren (vierstufiges Register) wiederholt sich alle paar Minuten, damit Bob weiß, dass Alice noch da ist. (Könnte ja einerseits sein, dass sie offline gegangen ist, ohne Tschlüss zu sagen. Könnte aber auch andererseits sein, dass ihr Internet-Zugang auf einmal eine ganz andere IP-Adresse hat nach z.B. DSL-Neueinwahl).

Auf den ersten Blick könnte man bei derartigen REGISTER-Meldungen glauben, dass es ein Problem mit den Zugangsdaten gibt (weil alle paar Minuten immer wieder ein "401 Unauthorized" als SIP-Nachricht zu sehen ist). Solange dem danach immer ein 200 OK nach erfolgreicher Challenge-Beantwortung kommt, ist das aber eine optische Täuschung.

Wie oft genau sich das wiederholt bzw. wie oft es sich wiederholen sollte, kann man in der Regel in Alice' Geräteeinstellungen konfigurieren, bzw. Bob kann eine "register expiration time" zurückmelden, also nach welcher Zeit er ein REGISTER als veraltet betrachtet. Weichen diese Zeiten voneinander ab, dann kann es z.B. sein, dass Alice glaubt, sie sei noch am Bob-Server angemeldet (schickt also kein neues REGISTER), während Bob glaubt, sie wäre weg (weil sie sich nicht mehr meldet) und das Endgerät wäre dann unbemerkt nicht mehr anrufbar.  

OPTIONS

Eigentlich nur eine Frage nach „Was kannst Du so für Kommandos“ (Antwort: 200 OK: Ich kann INVITE REGISTER OPTIONS NOTIFY …).

OPTIONS-Nachrichten werden aber gerne benutzt als „Keep alive“-Paket, zum einen sieht man dann, ob der Gegenüber noch da ist (wüsste man sonst dank UDP ja nicht) und zum anderen wird durch ständiges Wiederholen der Kommunikation der jeweilige NAT-Router „daran erinnert“, dass das Yealink Gerät 192.168.irgendwas mit dem SIP-Server 123.45.67.8 in Verbindung stehen, was zur Vermeidung von NAT-Problemen wichtig ist

SUBSCRIBE

Damit sagt das Telefon dem Server „ich brauche für meine z.B. Besetztlampen von Dir bitte automatische Updates zum Kollegen XYZ“

NOTIFY

Damit schickt Alice an Bob irgendwas „zur Info“. Im Inhaltsteil ist dann meistens XML, und zwar entweder mit Infos zum Kollegen XYZ (d.h. dann weiß das Telefon Bob, dass es die Besetztlampe XYZ ein-/ausschalten muss) oder mit z.B. Konfigurationsinfos (z.B. Yealink und Telefonanlage sagen sich gegenseitig, wenn an einem von beiden die „nicht stören“-Taste oder eine Rufumleitung aktiviert wurde)