Update zum Projekt: Vodafone SIP Trunk Telefonie und FritzBox 7590. Exkurs
Vorheriger Text: http://www.art-events.de/weblog/fritzbox-7590-und-der-vodafone-sip-trunk-anlagenanschluss/
Wir haben zwischenzeitlich diverse Testreihen mit einem SIP Trunk Gateway durchgeführt – nachstehend TK Anlage genannt. Besonders kompliziert ist das SIP Protokoll nicht. Für das grundsätzliche Telefonieren sind erst einmal folgende Dinge wichtig:
- Telefone (FXS Clients) sollen sich registrieren
- Abgehende Anrufe (Outbound)
- Eingehende Anrufe (Inbound)
Hilfreich ist ein Log der SIP Protokolle. Mit unserem Telefon Analog Gateway können wir bequem ein Logging aktivieren, um uns die Datenpakete im SIP Stream anzuschauen.
Dann könnt Ihre Euch jedes Mal ansehen, was Eurer Gateway / die TK Anlage sendet und wie der SBC (in unserem Fall von von Vodafone) antwortet.
Wenn man jetzt noch weiß, wie es aussehen soll, rückt eine brauchbare Datenanalyse in greifbare Nähe:
Fall 1: Registrierung (simpel)
1.1. TK Anlage sendet an den SBC eine Registrierungs-Anforderung.
1.2. Der SBC antwortet mit einem OK Block. Oder halt mit einem Fehler, wenn er die Registrierung abweist. Die Art der Fehlermeldung sollte Aufschluss liefern, warum der SBC keine Lust auf Eure TK Anlage hat.
Fall 2: Outbound (simpel)
2.1. TK Anlage sendet INVITE Block an SBC
2.2. SBC baut Verbindung auf, antwortet mit TRYING und RINGING Block
2.3. Wenn Verbindung besteht sendet der SBC einen OK Block an TK Anlage.
2.4. TK Anlage antwortet mit einen ACK Block. Telefonie möglich!
Es sei noch erwähnt, dass Outbound Anrufe in vielen Fällen auch ohne die SIP Registrierung durchgeführt werden können. Kurzum: ganz im Sinne des Außerirdischen ET: Nach Hause telefonieren geht (meistens).
Fall 3: Inbound (anspruchsvoll)
3.1. SBC sendet INVITE Block an TK Anlage
3.2. TK Anlage antwortet mit TRYING und RINGING. Ein Telefon sollte klingeln – wenn ihr es mit der TK Anlage verbunden und entsprechend logisch verheiratet habt
3.3. Wenn Ihr den Hörer abnimmt, sendet TK Anlage dem SBC einen OK Block, der der als Antwort auf INVITE (3.1.) gedacht ist.
3.4. Der SBC antwortet mit einem ACK Block. Telefonie möglich!
Ein häufiges Problem mit dem NAT Routing: Die Antwort 3.4. erfolgt an eine im Contact-Header angegebene Adresse aus 3.3! Das ist ein bisserl heikel und erfordert in den meisten Fällen Euren Eingriff, damit die Antwort auch an Eurer TK Anlage ankommt. Beispiel in 3.3. steht:
Contact: <sip:051369794699@PBX:5060;transport=tcp>
Der Contact Header enthält Eure öffentliche PBX Adresse des Anschlusses. Hier müsst Ihr also mit internem Routing auf dem Router (!) sicherstellen, dass das das nachfolgende erwartete ACK (3.4.) auch korrekt an Eure TK Anlage weiter geroutet wird. Sonst bekommt die das ACK nicht mit – und es ist Essig mit dem Telefonieren!
In der Praxis sieht das dann so aus, dass Eure TK Anlage den OK Block unter 3.3. so lange wiederholt, bis ein Timeout ausgelöst wird und sie entnervt den Leitung wieder freigibt.
Auf unserem Server in TEAM, Verzeichnis Vodafone_SIPTests befinden sich zahlreiche Log Dateien, die detaillierte Kommunikationsprotokolle beinhalten. Da in diesen aber auch private Daten enthalten sind, werden sie hier nicht veröffentlicht.
Die Protokolle zeichen sich flink auf. Wir müssen sie speichern und analysieren. Da sie auch reihenweise private Daten enthalten, beschränken wir uns hier auf zwei Muster, die den Ablauf und die Kommunikationsblödies sinngemäß darstellen:
Beispiel für INVITE Block von SBC an TK gem. 3.1.:
AESYSTEME — 2020-09-28 15:32:17.205 RECEIVING FROM 1xxxxx:5060 INVITE sip:+4951xxxx690@xxxxxxt.ngn.vodafone.de;user=phone SIP/2.0 Via: SIP/2.0/TCP 176.95.xxxx:5060;branch=z9hG4bK0h0ain30aou2hijsqem0.1 To: sip:+4xxxxxx0@nbxxx.ngn.vodafone.de;user=phone From: sip:+xxxxxxxx8@ims.vodafone.de;user=phone;tag=SDrib4d01-3fd67f39 Call-ID: SDrib4d01-7dd5a32128f042caeef4e1dc0960fd80-ct4u830000 CSeq: 1 INVITE Max-Forwards: 59 Contact: sip:+4xxxxxx8@1xxxxx2:5060;transport=tcp Date: Mon, 28 Sep 2020 22:32:16 GMT Allow: INVITE, ACK, PRACK, CANCEL, BYE, OPTIONS, MESSAGE, NOTIFY, UPDATE, REGISTER, INFO, REFER, SUBSCRIBE Supported: resource-priority,100rel P-Asserted-Identity: sip:+4916xxxxx8@ims.vodafone.de;user=phone Accept: application/sdp P-Early-Media: supported Content-Type: application/sdp Content-Length: 201 v=0 o=- 0 0 IN IP4 176.xxxx s=IMSS c=IN IP4 1xxx22 t=0 0 m=audio 31476 RTP/AVP 9 8 98 99 a=rtpmap:98 telephone-event/8000 a=rtpmap:99 telephone-event/16000 a=ptime:20 a=maxptime:30
Beispiel für OK Block als Antwort auf INVITE (Den RINGING Block haben wir ausgelassen), gem. 3.3.:
AESYSTEME — 2020-09-28 15:32:21.140 SENDING TO 1xxxxx22:5060 SIP/2.0 200 OK Via: SIP/2.0/TCP 1xxxx.61.22:5060;branch=z9hG4bK0h0ain30aou2hijsqem0.1 From: sip:+4xxxx@ims.vodafone.de;user=phone;tag=SDrib4d01-3fd67f39 To: sip:+495xxxx@nbgsxxxxxxn.vodafone.de;user=phone;tag=253361975 Call-ID: SDrib4d01-7dd5a32128f042caeef4e1dc0960fd80-ct4u830000 CSeq: 1 INVITE Contact: sip:05xxxxx@2.xxxx:5060;transport=tcp;user=phone Supported: replaces, path, timer, eventlist User-Agent: AESYSTEME Logging 1.10.17.5 Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE Content-Type: application/sdp Content-Length: 226 v=0 o=05xxxxx0 8000 8000 IN IP4 2.207.xxxx s=SIP Call c=IN IP4 2.207.xxxx t=0 0 m=audio 55000 RTP/AVP 9 98 a=sendrecv a=rtpmap:9 G722/8000 a=ptime:20 a=rtpmap:98 telephone-event/8000 a=fmtp:98 0-16,32-36,54
Daten enthalten Beispiele. Private Werte anonymisiert.
Der obligatorische Hinweis: Alle Angaben ohne Gewähr. Diese Beschreibung bezieht sich auf unsere Installation und stellt keine Bewertung der verwendeten Techniken da.
