Deutsche Version.

Why?

Last year, we almost completely replaced the Phone Operation Center (PoC) hardware and software, making it easier to use. This has given us the opportunity to provide functionality that was impossible to implement with our old setup. This includes self-registration of DECT phones, better extendability, self-administration of extensions and call groups and the LDAP phonebook. Now we want to solve another major problem from the user’s point of view. The compatibility of DECT devices. DECT-GAP is a standard which allows free interpretation of some parts. As a result, there is a considerable number of devices that do indicate DECT-GAP conformity in their datsheets, but still do not work at all or only with restrictions on our system. Up to now, no manufacturer has been willing to ensure that the devices work with our system, e.g. through firmware adaptations, even though we have made concrete suggestions for changes that wouldn’t have caused disadvantages with regard to compatibility with their own base stations.

In our test system, we were able to analyze and understand the communication of some devices that had not worked before. We have adapted our system so that it recognizes some of these models by making the required information available to them. With other models, we still don’t have enough information to guarantee reproducible and reliable connections. There are also models where we don’t even know why they don’t work.

We like to get a deeper insights of the DECT infrastructure when many different models from different vendors are registered. (Perhaps) This will enable us to support a greater variety of DECT devices. The basis for this is an understanding of how different devices communicate on the DECT interface. Therefore, we need significantly more sample data than what we can produce by manual tests. Since we do not store any connection data, we are not able to analyze data from past events. Because of this, we want to store connection data on the Easterhegg 2019.

Currently we have not found a way to offer opt-in on a per user basis. We could not answer many questions such as: “What do we do if a participant agrees to capture the data and calls a participant who has not agreed?”; “What happens with a group call where some members have agreed and some have not?”. If we optionally anonymize data per user, you can still see who tried to call from the call setup and you have to delete the attempted call setup for the user who tried to call and vice versa. Since we know that it is basically bad to store data, we have come to the conclusion that the situation doesn’t get any better if we make users believe that it’s safe to click on a checkbox when we can’t make sure it will work. We have decided to make transparent what we intend to do with the data, store it in a responsible way and to delete it safely after a specified period of time. If you do not want your metadata to be stored, you must not use any of our extensions on Easterhegg 2019. We believe that, unlike a Congress or Camp, this is acceptable on an Easterhegg.

What data is affected?

It is basically about the metadata of the DECT extensions. Speech/Voice data is not stored. The control messages between the antennas and the central software component that coordinates the antennae and phones are affected.

In detail, these are the following data:

• the identities of the DECT devices: IPEI, TPUI and IPUI,
• the keys used to encrypt the calls,
• the call setup: Caller and called party
• the call end (duration),
• The mobile device details (capabilities of the mobile device),
• the keystrokes on the device (for some devices),
• the accesses to the phone book (for some devices).

Example: We store when Alice called Bob, how often it rang, how long the call lasted, what device Alice used, which device Bob used, what was shown on the displays and that during the call e.g. key 2 was pressed. This includes all data necessary to set up and disconnect the call as well as the base stations involved.

We do not evaluate keystrokes and accesses to the phone book, but we cannot rule out that this information will be sent.

Where is the data stored and how?

For the Easterhegg, we will take the server to a secure data center. The collected metadata is stored encrypted. Access to the data is exclusively encrypted. The data is explicitly excluded from all backups.

How long is the data stored?

The metadata of Easterhegg 2019 will be stored for a maximum of 4 months, i.e. until 23.08.2019 (end of CCCamp 2019). By 25.08.2019 at the latest, the data will be deleted and the area overwritten. We will officially announce the deletion.

Can I make a phone call without saving the metadata?

Yes, if you use a SIP extension and call another SIP extension, no metadata will be stored. However, you cannot ensure that a user has not converted a SIP extension into a DECT extension or group at short notice. So you have to check if the extension you want to call is a SIP extension at the moment.

Can I use the services of the PoC anonymously?

Yes, you can register with fantasy names and anonymous e‑mail addresses. We will then have the metadata, but we won’t be able to assign it to a real person. Note, however, that you are not using the phone at the camp (or 35C3) with a real name, because then we would be able to merge the data using the IPEI (we don’t intend to).

Do I have a right to information?

Yes.

If you have any questions about the procedure or data protection, please do not hesitate to contact us. You can find contact possibilities here: https://guru3.eventphone.de/support/

Our voluntarily appointed data protection officer is:

Stephan Kambor
Nobistor 40
22767 Hamburg, Germany

E‑Mail: st ‘at’ eventphone.de
DECT on Events: 2078 (20ST)

thomasDOTwtf

Thomas ist Eventphone Fullstack Entwickler und gehört seit Jahren zum Team. Er liefert aber nicht nur Code und administriert das Blech, sondern ist auch im Kundensupport, der Logistik, im Backoffice sowie im Marketing und der “Unternehmenskommunikation” aktiv.

Auf den letzten Congressen wurde neben dem 2G Netzwerk ein 3G Mobilfunk Netzwerk zur Verfügung gestellt. Das ist auch auf dem 35C3 der Fall. Das 3G Netzwerk unterstützt Sprache zum aktuellen Zeitpunkt nur eingeschränkt.

Aus diesem Grund wird das 3G Netzwerk zum 35C3 als Opt-In angeboten. Das bedeutet, dass alle SIM-Karten aktuell nur über eine Berechtigung zur Nutzung des 2G Netzwerks verfügen. Ein Einbuchen in das 3G Netz ist nicht möglich. Damit wollen wir sicherstellen, dass das Telefonieren für die GSM-Geräte zunächst einmal unabhängig von den Einstellungen des verwendeten Handys mit 2G funktioniert. Bisher musste im Handy explizit 3G ausgeschaltet werden, damit Sprache möglich war.

Man kann sich aber mit einer neuen Funktion in guru3 nun dazu entscheiden das 3G Mobilfunknetz zu testen. Diese Einstellung wird in die Handy-Netze übertagen und nach ca. 1 Minute aktiv.

Die Einstellung findet sich auf der Detailseite einer Extension:

Viel Spass beim ausprobieren.

–

At the last congresses a 3G mobile network was provided in addition to the 2G network. This is also the case on the 35C3. The 3G network supports speech only to a limited extent at the moment.

For this reason, the 3G network is offered as an opt-in to the 35C3. This means that all SIM cards currently only have permission to use the 2G network. Logging in to the 3G network is not possible. With this we want to ensure that telephoning for the GSM devices initially works independently of the settings of the mobile phone used with 2G. Until now, 3G had to be explicitly turned off in the mobile phone to enable voice.

With the new function in guru3 you can now decide to test the 3G mobile network anyways. This setting is transferred to the mobile phone networks and becomes active after approx. 1 minute.

Have fun!

thomasDOTwtf

Thomas ist Eventphone Fullstack Entwickler und gehört seit Jahren zum Team. Er liefert aber nicht nur Code und administriert das Blech, sondern ist auch im Kundensupport, der Logistik, im Backoffice sowie im Marketing und der “Unternehmenskommunikation” aktiv.

Das AVM Fritz!Fon.

Viele Menschen haben auf Events, per E‑Mail, Ticket oder Twitter nach nach der Kompatibilität von AVM Fritz!Fons mit der EVENTPHONE Telefon-Anlage gefragt. Bisher hatten wir das DECT-Netzwerk auf Basis einer Alcatel Telefon-Anlage betrieben. Hier gab es eine grundsätzliche Inkompatibilität zu Fritz!Fons.

2016 gab es eine Bemühung von AVM diesen Zustand zu ändern. Die Anstrengungen dazu sind allerdings im Sande verlaufen. Ein Debugging ohne entsprechende Diagnose-Fimware für die Telefone von AVM gestaltete sich sehr problematisch. 

Das automatische Zeitalter.

Mit der bisherigen DECT-Anlage musste jedes der 2.500 Endgeräte beim letzten Congress manuell durch Helpdesk-Engel angemeldet werden. Diese Situation hat sich durch die wachsende Anzahl an Endgeräten zugespitzt. Ein erster Schritt zum letzten Congress war die Einführung eines Warteschlangensystems. Das hat den Engpass der Registrierung etwas entschärft, weil die Leute nicht mehr zwei Stunden in der Warteschlange warten mussten, sondern Zeitfenster bekommen haben, in denen sie ihr Gerät anmelden konnten. Das eigentliche Problem wurde damit allerdings nicht gelöst. Es musste eine radikalere Lösung für die Anmeldung her. Technisch bedingt, war diese Lösung mit der bisherigen DECT-Anlage nicht möglich, weshalb wir nach einem neuen DECT-System gesucht haben, dass eine parallele Anmeldung von Endgeräten zulässt. Gleichzeitig sollten bis zu 10.000 Endgeräte und eine große Anzahl von DECT-Basen inkl. Handover unterstützt werden. Entstanden ist ein vollständig automatisierter Anmelde-Prozess und eine komplett neu entwickelte Telefon-Anlage auf Basis von Yate und dem eiem neuen DECT-System. Details zur neuen Anmeldung finden sich hier: Die neue DECT-Anmeldung.

Neue Technologie und Ihre Folgen.

Verbunden mit einer Änderung unserer zentralen Komponente, der Telefonanlage, sind alle bisherigen Informationen zur Kompatibilität von Endgeräten neu zu erforschen gewesen. Bei ersten Tests hat uns positiv überrascht, dass z. B. bisher inkompatible Panasonic Endgeräte auf einmal funktionierten. Auch die bisher sehr gut kompatiblen (Siemens) Gigaset Telefone funktionierten, ebenso die System-Spezifischen Alcatel DECT-Telefone. Da es im Umfeld der von uns besuchten Veranstaltungen viele technikaffine Menschen gibt, die zu Hause AVM Geräte nutzen, hatten wir die Hoffnung diese nun integrieren zu können. Hoffnungsvoll packten wir das AVM Fritz!Fon aus meldeten es an einer Fritz!Box an und installierten die aktuelle Firmware. 

FRITZ!Fon an der FRITZ!Box.

Das Fritz!Fon war wegen des Firmware-Updates bereits an der AVM Fritz!Box angemeldet.  Daher haben wir zuerst die Funktionalität per SIP getestet. Anrufe funktionieren wie erwartet in beide Richtungen inkl. Audio. Die Informationen zum Anrufer wurden komplett dargestellt. 

Anmeldung am Eventphone DECT-System.

Als nächstes haben wir das Fritz!Fon an unserem neuen DECT-System angemeldet. Die gute Nachricht ist, dass eine Anmeldung grundsätzlich funktioniert hat. Die schlechte Nachricht ist, die Rufnummeranzeige funktioniert nicht wie erwartet. Test-Anrufe in beide Richtungen zeigen, dass Anrufe nur mit “Intern” signalisiert werden. Es wird keine Rufnummer übertragen.

Der Teufel steckt im Detail.

Das neue DECT-System kennt zwei Entitäten, zum einen Geräte und zum anderen Benutzer. Wenn ein Gerät mit einem Benutzer verknüpft ist, kann das Gerät mit der Rufnummer des Benutzers verwendet werden. Diese Verknüpfung kann manuell oder durch ein “Login” am Endgerät erfolgen. Dazu wird ein Feature-Code gewählt und das Endgerät fragt nach einem PIN. Hier ist uns ein weiteres Detail aufgefallen: das Fritz!Fon sendet als PIN ohne Nutzer-Rückfrage immer statisch 1234.

Eine Zeitreise zum Anfang des Jahres.

Das Problem mit der Darstellung von Rufnummern war uns wichtiger als der Login-Prozess. Die Anmeldung von DECT-Geräten erfolgt per Token und benötigt nicht den DECT Feature-Code. Um das Problem der Rufnummern-Darstellung zu klären, haben wir uns im Februar an AVM gewandt, um Licht ins Dunkel zu bringen.

Zunächst hat AVM auf den Einsatzzweck von Fritz!Fons im Heimbereich und nicht an Business-Telefonanlagen aufmerksam gemacht. Es entwickelte sich jedoch ein Dialog, der im April damit endete,  dass wir einen DECT-Trace (einen Mitschnitt der übertragenen Daten) übermitteln sollten. Dazu haben wir einen ersten Versuch mit einem DECT-Sniffer auf dem Easterhegg 2018 unternommen, welcher leider nicht von Erfolg gekrönt war. In der Zwischenzeit ging die Entwicklung unserer Telefonanlage weiter und wir lernten die Tools des neuen Systems besser kennen. In der Vorbereitung zum Congress haben wir eine Möglichkeit gefunden aus unserem DECT-System heraus einen Mitschnitt (Trace) der Kommunikation zwischen PP (Portal Part / Fritz!Fon) und einem RFP (Radio Fixed Part / Antenne) zu erzeugen.

Damit sind wird dann wieder in die Kommunikation mit AVM eingestiegen. Das Trace-Format ist eher umständlich zu interpretieren. Zum genauen Verständnis muss man muss die Dokumentation des DECT-Standards zu Rate ziehen: EN 300 175–5 – V2.4.0 Seite 108. Wir haben den Anruf-Aufbau mit einem GAP-Konformen Endgerät aufgezeichnet und AVM bereitgestellt.

03 SETUP
05 08 80 B0 10 02 EA 6C ED E6
06 06 A0 A0 10 2A F1 2C
E0 80
E4 40
6C 17 40 80 32 30 30 33 20 74 68 6F 6D 61 73 44 4F 54 77 74 66 20 53 49 50

Die erste Idee zur Lösung.

Die Rückmeldung hat nicht lange auf sich warten lassen. Schon am nächsten Tag haben wir eine Antwort bekommen, die darauf hindeutete, dass die folgende Rufnummern-Anzeige nicht funktioniert, weil die Rufnummer Buchstaben enthält und sehr lang ist. Genauer gesagt, war dies der Inhalt des Information Element für die Calling Party Information der aufgezeichneten Kommunikation:

• 6C (Information Element Type: Calling Party Number)
• 17 (Content Length: 23 byte)
• 40 (Number Type: Subscriber Number, Numbering Plan: Unknown)
• 80 (Presentation indicator: Presentation allowed, Screening indicator: User-provided, not screened)
• 32 (2) 30 (0) 30 (0) 33 (3) 20 (space) 74 (t) 68 (h) 6F, (o) 6D (m) 61 (a) 73 (s) 44 (D) 4F (O) 54 (T) 77 (w) 74 (t) 66 (f) 20 (space) 53 (S) 49 (I) 50 (P)

Die Anzeige sollte also 2003 thomasDOTwtf SIP lauten. Angezeigt wurde jedoch Intern.

Der erneute Test.

Auf Basis des Feedbacks zu unserem ersten Mitschnitt haben wir einen weiteren Test durchgeführt. Diesmal ohne Buchstaben und mit einer deutlich kürzeren Rufnummer. Wir haben den Inhalt durch eine Dummy-Nummer ersetzt, die vom Format her einer Mobilfunknummer entspricht. Die Reaktion des Fritz!Fons blieb unverändert. Anrufe wurden weiterhin mit “Intern” signalisiert.

03 SETUP
05 08 80 B0 10 02 EA 6C ED E6
06 06 A0 A0 10 2A F1 2C
E0 80
E4 40
6C 0D 40 80 30 31 37 32 30 30 30 30 30 30 30
7C 04 80 02 00 84

• 6C (Information Element Type: Calling Party Number)
• 0D (Content Length: 13 byte)
• 40 (Number Type: Subscriber Number, Numbering Plan: Unknown)
• 80 (Presentation indicator: Presentation allowed, Screening indicator: User-provided, not screened)
• 30 (0) 31 (1) 37 (7) 32 (2) 30 (0) 30 (0) 30 (0) 30 (0) 30 (0) 30 (0) 30 (0)

Die Anzeige sollte also 01720000000 lauten. Angezeigt wurde jedoch wieder Intern. Die Aussage, dass es am Inhalt des Feldes liegt war also nicht korrekt. 

Die Hoffnung stirbt zuletzt, aber sie stirbt!

Eine Antwort ließ erneut nicht lange auf sich warten. Allerdings nicht mit dem gewünschten Ergebnis. Das Fritz!Fon legt in das Alerting-Pattern (E4 40) eine Semantik die beim Pattern 0 das Auswerten weiterer Info-Elemente aus der SETUP-Nachricht ignoriert. Der Standard EN 300 175–5 – V2.4.0 Seite 97 sieht dieses Vorgehen allerdings nicht vor. AVM nutzt oder interpretiert an dieser Stelle den Standard so, dass die Geräte nicht an Anlagen funktionieren können, die den Standard wie beschrieben implementiert haben. Warum AVM das so macht ist uns nicht bekannt.

Nachdem wir das so erläutert hatten, gab es keine weitere technische Diskussion. Die Kommunikation mit der Pressesprecherin von AVM war sehr freundlich und zügig. Unser Wunsch nach einen Telefonat mit der Fachabteilung, um mögliche Alternativen zu besprechen (die es aus unserer Sicht gibt), wurde von AVM mit der Begründung: nicht möglich abgelehnt. Es wurde auf die Mitteilung vom Februar verwiesen, in der uns bereits geschrieben wurde, dass FRITZ!Fons nur für den Heimgebrauch an der Fritz!Box und nicht für die Verwendung an einer Business-Telefonanlage konzipiert sind. 

Leider konnten wir AVM nicht davon überzeugen, ihre DECT Geräte außerhalb des FRITZ!Box Universums nutzbar zu machen. Vielleicht ändert die Firma ihre Meinung, wenn Sie über Twitter oder ihre Supportkanäle erfahren, wie viele ihrer Kundinnen und Kunden ein FRITZ!Fon an der EVENTPHONE Anlage verwenden möchten. Mit einem Softwareupdate wäre das zu bewerkstelligen. Die aktuelle Software der Telefone ist im Moment so gestaltet, dass die Benutzung mit anderen Systemen nicht oder nur eingeschränkt möglich ist. Zum aktuellen Zeitpunkt können wir AVM Geräte leider nicht unterstützen. Welche Geräte funktionieren könnt ihr in unserem Wiki sehen: DECT Phone Compatibility List (since 2018).

thomasDOTwtf

Thomas ist Eventphone Fullstack Entwickler und gehört seit Jahren zum Team. Er liefert aber nicht nur Code und administriert das Blech, sondern ist auch im Kundensupport, der Logistik, im Backoffice sowie im Marketing und der “Unternehmenskommunikation” aktiv.