Der Trend zu Voice-over-IP ist unverkennbar. Doch immer noch verstellen proprietäre Lösungsansätze den Migrationsweg.

Gut elf Jahre ist VoIP jetzt alt, da sollte man endlich auf herstelleroffenere Lösungen zählen dürfen. Zumal die Unternehmen investitionserhaltend aus der bestehenden Systemkonstellation heraus migrieren wollen und auf einem zunehmend globalen Markt immer weniger Interesse an einer Hersteller- und damit Produktbindung haben. Wie steht es um die Interoperabilität der VoIP-Lösungen über Herstellergrenzen hinweg, auch zwischen den Lagern der Netzwerk- und TK-Anlagen-Hersteller?

Network Computing ist dieser Frage nachgegangen und hat dazu zahlreiche Produzenten aus dem Netzwerk- und TK-Anlagen-Bereich befragt. Neun Hersteller – 3Com, Alcatel-SEL, Avaya, Cisco Systems, Enterasys Networks, Hewlett-Packard, Innovaphone, Lucent und Tenovis – haben sich der Recherche gestellt. Soviel vorweg: Ihre Bereitschaft, sich mit ihren Strategien und Produkten zu öffnen, ist ein wenig größer geworden. Von dem notwendigen Maß, das ins globale Internet-Zeitalter passt, sind sie aber immer noch weit entfernt.

Interoperabilität der Systeme

Wie steht es um die Interoperabilität der angebotenen Netzwerksysteme wie Switch-Systeme und Router über Herstellergrenzen hinweg? Und an die TK-Anlagen-Seite: Welche Netzwerksysteme welcher Hersteller lassen sich in die VoIP-Lösung binden? Zu beiden Fragen wurden den Anbietern unter der Prämisse »nachweislich« die Nennung von Herstellern und Voraussetzungen abverlangt.

»Soweit sich die Komponenten anderer Hersteller an verabschiedete Standards halten, entstehen im Zusammenspiel mit unseren Komponenten keine Probleme«, gibt sich Rolf-Dieter Köhler, Senior-Berater bei 3Com, selbstsicher. Er verweist dabei auf Interoperabilitätstests, beispielsweise der Tolly-Group.

Features: Weltoffener über QSIG

In das gleiche Horn stößt Uwe Lepa, Business-Development-Manager bei Cisco. Wichtig sei, dass auch die Systeme der anderen Hersteller QoS adressierten. Als Beispiele für solche QoS führt er neben IEEE 802.1p/Q auf Ebene 2 die TOS (Type-of-Service) inhärenten Mechanismen IP-Precedence und DSCP (DiffServ-Code-Points) für das Tagging von Strömen auf, wobei DSCP mittlerweile IP-Presedence ersetzt hat.

»Alle Avaya-Netzwerkkomponenten – Switch-Systeme, Router, VPN- und WLAN-Komponenten arbeiten harmonisch mit den Komponenten anderer Hersteller zusammen«, streicht Stefan Neumann, Solution Architekt bei Avaya Deutschland, heraus. Er verweist in diesem Zusammenhang auf umfangreiche Dokumente und Interoperabilitätstests. Als unterstützte Netzwerksysteme anderer Hersteller werden die von 3Com, Cisco, Enterasys und Extreme benannt.

Noch herstelleroffener gibt man sich bei Enterasys im Rahmen der Strategie Open-Convergence-Architecture. Andreas Seum, dort Director of Technology und Mitglied im Office of CTO: »Wir setzen auf Industriestandards. Deshalb arbeiten und harmonieren unsere Komponenten mit Geräten anderer Hersteller, die ebenfalls auf standardisierte Protokolle setzen.« Das sei bereits in vielen Projekten nachgewiesen worden. Bleibt die Frage, wieso Enterasys trotz Nachhakens keine konkreten Angaben zu diesen Herstellern machen wollte. Die fehlten allerdings auch bei 3Com und Cisco. Sollte es um die Interoperabilität der Systeme dieser Hersteller doch nicht so gut bestellt sein?

Ebenso wenig konkret wird HP zu dieser Frage, die mit ihrem Pro-Curve-Switch-Systemen ausschließlich auf den LAN-Bereich abzielt. Dennoch nimmt auch Stephen Rommel, Business-Development-Manager Pro-Curve-Network-Business bei Hewlett Packard, für sein Unternehmen in Anspruch: »Die Kompatibilität sowie Einhaltung offener Standards und Protokolle stehen bei HP ganz oben in der Produktstrategie.« Als Beispiele dafür gibt er IEEE 802.1p/Q und DiffServ zur Priorisierung an. Stelle der Wettbewerb das Gleiche zur Verfügung, sei eine fehlerfreie Kommunikation über Herstellergrenzen hinweg möglich.

Tatsächlich beweisen unabhängige Tests, dass die Netzwerkhersteller solche standardisierten QoS-Mechanismen mittlerweile normkonform implementieren. Das war in der jüngsten Vergangenheit nicht immer so. Dadurch steht einer grundsätzlichen Interoperabilität von Router- und Switch-Systemen verschiedener Hersteller seit geraumer Zeit nichts mehr im Wege. Diese propagierte Interoperabilität, zwischen den Anbietern unterschiedlich breit ausgeprägt, sollten sich die Unternehmen aber besser vor der Produktentscheidung von den Herstellern unter Beweis stellen lassen.

Dennoch werden gemischte Installationen auf dem Markt weiter die Ausnahme bleiben. Dafür gibt es zwei maßgebliche Gründe: Jeder Hersteller löst die Konfiguration von QoS mit seiner eigenen Administration und Syntax. Dieser herstellerspezifische Ansatz ist teils schon so komplex, dass die Administratoren in den Unternehmen ihre redliche Mühe haben, damit zurechtzukommen. Wie sollten sie dann dazu Willens und in der Lage sein, sich in einer gemischten Komponentenumgebung parallel mit mehreren herstellerspezifischen Administrationen und Syntaxen auseinanderzusetzen? Zumal sie, zweitens, neben den Standard-QoS- mit zahlreichen proprietären QoS-Mechanismen ohne Standardweihe konfrontiert sind. Deren Reichweite endet zwangsläufig an den Produktgrenzen des jeweiligen Herstellers. Damit bleibt, trotz interoperablen Standard-QoS, unter dem Strich alles beim Alten. Deshalb fällt es den Netzwerkherstellern weiterhin schwer, aus der Praxis Produzenten für das Zusammenspiel mit ihren Komponenten zu benennen.

Ein wenig anders stellt sich die Ausgangssituation für die Hersteller dar, die selbst keine Netzwerkkomponenten entwickeln und fertigen, so für die TK-Anlagen-Produzenten. Sie sind für die Herausbildung einer VoIP-Komplettlösung auf die Router- und Switch-Systeme der Netzwerkhersteller angewiesen. In der Praxis heißt das: Sie müssen sich auf bestehende Netzwerkinstallationen abstimmen. Deshalb meint Udo Reckemeyer, Presseverantwortlicher für Alcatel-SEL: »Unsere VoIP-Lösung harmoniert mit allen Netzwerkkomponenten, die QoS standardkonform sicherstellen.«

Carsten Biermann, Projektleiter VoIP bei Tenovis, stimmt ein und nennt sogar Namen: »Wir können auf Installationen mit Komponenten von Cisco, 3Com, Enterasys und Extreme Networks verweisen. Auch Komponenten anderer Hersteller sollten innerhalb unserer Architektur grundsätzlich einsetzbar sein«.

»Da wir weder Router noch Switch-Systeme verkaufen, müssen unsere Lösungen mit Systemen anderer Hersteller zusammenarbeiten«, bestätigt Torsten Schulz, Product-Marketing-Manager bei Innovaphone. Zurzeit sei ihm keine Netzwerkkomponente bekannt, die nicht mit der Innovaphone-Architektur kompatibel sei.

In die gleiche Richtung geht auch die Argumentation von Lucent. Dirk Leismann, im Bereich Business-Development tätig, verweist auf Interworking-Tests mit anderen Produzenten und eine komplette Liste, die bei Bedarf vorgelegt werden könne. Explizit genannt, obwohl gefordert, werden aber nur die Netzwerkkomponenten von Cisco und Juniper. Mehr wäre glaubhafter gewesen, hätte die propagierte Breite der Interoperabilität mit anderen Herstellerprodukten unter Beweis gestellt.

Allerdings treffen auch die VoIP-Lösungen aus dieser Ecke bald an ihre Grenzen, wenn darin Netzwerkkomponenten unterschiedlicher Hersteller zum Einsatz kommen sollen. Die Ausgangslage – eine kaum zu bewältigende Administration sowie eine eingeengte Kommunikation durch proprietäre QoS-Mechanismen – ist in diesem Fall für den Anwender die gleiche wie bei einer VoIP-Lösung in Reinkultur aus der Ecke der Netzwerkproduzenten. Dazu kommt bei der Offerte von der Seite der TK-Anlagen-Hersteller die klassische Telefonie, die zusätzlich administriert werden muss. Das verkompliziert die Gesamtinstallation weiter.

Tragfähigkeit von Q.SIG

Nicht zu vergessen ist eine weitere Herstellerbindung, die dem Anwender mit dieser VoIP-Lösungsofferte in Haus steht, nämlich an den betreffenden TK-Anlagen-Produzenten. Oder legen die mittlerweile mehr Offenheit in einem gemischten Bereich aus ISDN- und IP-Telefonie an den Tag? Für diesen Fall müssten sie sich stärker als in der Vergangenheit über den Signalisierungsstandard Q.SIG (Quer-Signalisierung) öffnen. Aber auch die Netzwerkhersteller müssten auf ihrer Seite die über Q.SIG möglichen Leistungsmerkmale für ihre IP-Telefone abbilden. Auf diesen Sachverhalt zielt die zweite Frage an beide Herstellergruppen ab: Welche Leistungsmerkmale eröffnet ihre VoIP-Lösung an den IP-Telefonen im Zusammenspiel mit ISDN-Telefonen bei Einsatz von Q.SIG? Dazu sollten die Anbieter explizit die möglichen Leistungsmerkmale für eine mehr oder weniger komfortable Telefonie zwischen beiden Welten benennen.

»Alle Leistungsmerkmale, die über Q.SIG für den jeweiligen Fremdhersteller freigegeben sind, werden unterstützt«, so Reckemeyer von Alcatel-SEL. Er deutet damit gleich zwei Restriktionen an: Einmal sieht der TK-Anlagen-Produzent in den anderen VoIP-Anbietern augenscheinlich weiterhin eine Bedrohung (Fremdhersteller), denen man zum anderen, je nach Hersteller, über Q.SIG mehr oder weniger Leistungsmerkmale bereitstellt.

Wenig Erhellendes zum Zusammenspiel zwischen klassischer und IP-Telefonie mit einem akzeptablen Komfort trägt auch Leismann von Lucent bei. Er zieht es vor, die Standardschiene Q.SIG, die für den Anwender für eine investitionserhaltende und herstelleroffenere Migration so wichtig ist, komplett auszusparen, in dem er ausführt: »Die Dienste, die im Zusammenhang mit VoIP angeboten werden können, gehen weit über das hinaus, was heute unter den ISDN-Leistungsmerkmalen bekannt ist.« Als Beispiele dafür benennt er Video-Telefonie, Video-Konferenzen, Instant-Messaging, Presence-enabled-Services und Field-Mobile-Conversion. Leistungsmerkmale in einer reinen IP-Telefonie-Welt waren aber nicht gefragt. Solche Ausweichmanöver signalisieren wenig Bereitschaft, den Kundenerwartungen entgegenzukommen: ohne schmerzliche Telefoniekomforteinbußen, aber auch ohne strikte Herstellerbindung allmählich zu VoIP zu migrieren.

Wenig Mut in Richtung Q.SIG als gemeinsame Standard-Signalisierungsschiene macht indirekt auch Schulz von Innovaphone. Zwar könnten mit der VoIP-Lösung dieses Herstellers »alle Q.SIG-Nachrichten über eine PBX-zu-PBX-Verbindung getunnelt werden«. Als in dieser Konstellation mögliche Leistungsmerkmale, obwohl explizit gefragt, fallen ihm aber lediglich »Name Display«, »Call Completion« und» Call Rerouting« ein. Viel mehr Raum für Komfort zwischen beiden Telefoniewelten scheinen die TK-Anlagen-Hersteller Innovaphone anscheindend nicht zu lassen. Oder sollte Innovaphone für das Zusammenspiel zwischen beiden Welten via Q.SIG noch nicht mehr an Leistungsmerkmalen umgesetzt haben?

Dabei gibt es doch TK-Anlagen-Hersteller wie Tenovis, die via Q.SIG und gegenüber IP-Telefonen anderer Produzenten offensichtlich mehr Leistungsmerkmale möglich machen. Biermann liefert eine Tabelle von immerhin 24 solcher Funktionen. Die eröffne man via Q.SIG unabhängig davon, welcher Hersteller die IP-Telefonieseite realisiere. Via Q.SIG und den IP-Telefonen des eigenen Hauses seien zusätzlich sechs weitere Leistungsmerkmale, Q.SIG+-Funktionen, möglich.

Diese ein wenig offenere Haltung von Tenovis kann aber nicht über die weiterhin generell geringe Bereitschaft der TK-Anlagen-Hersteller hinweg täuschen, sich über Q.SIG zu öffnen. Leidtragende dieser Strategie sind die Anwender, die an einer allmählichen Migration von der klassischen zur IP-Telefonie interessiert sind. Er trifft auf der TK-Anlagen-Seite meist auf Produzenten, die über ihre proprietären Signalisierungsprotokolle weiterhin auf eine strikte Hersteller- und damit Kundenbindung aus sind. Das erschwert, ohne tragfähigen Q.SIG-Standard, auch den Netzwerkproduzenten das Leben, ihre IP- auf die klassische Telefonie abzustimmen.

Und wie kommen die Netzwerkhersteller mit dieser eher bescheidenen Ausgangssituation via Q.SIG zurecht? Berater Köhler von 3Com stellt heraus, dass IP-Telefone nur über ein Gateway (ISDN oder analog) kommunizieren können. Q.SIG als Signalisierungsprotokoll innerhalb der TK-Anlagen-Welt ende in diesem Gateway. Ein Telefonie-Komfortvergleich zwischen beiden Welten sei damit nicht möglich. Seine Ausführung ändert aber wenig daran, dass die Anwender in einer gemischten Telefoniewelt auch an den IP-Telefonen auf die gewohnten und für sie wichtigen Leistungsmerkmale nicht verzichten wollen. Und: Solche Leistungsmerkmale wären mit einer offeneren Q.SIG-Politik der TK-Anlagen-Hersteller durchaus auf die IP-Telefonie-Seite abbildbar. Eine weitere Konsequenz aus der mangelnden Offenheit an der Gateway-Schnittstelle macht der 3Com-Berater gleich mit deutlich: »Die Funktionen der IP-Telefone sind weiterhin hersteller- und produktspezifisch.« Das heißt nicht anderes als: Der Anwender ist auch bei den IP-Telefonen, unabhängig davon, aus welcher Ecke sie stammen, mit einer Produktbindung konfrontiert.

Enterasys wollte für ihre VoIP-Lösung nicht auf die Unterstützung von Q.SIG und ihren Umfang eingehen. Für die Avaya-Lösung »Communication Manager« beansprucht Neumann mehr als 700 Leistungsmerkmale, ohne, wie gefordert, explizit auf mögliche Funktionen im Zusammenspiel mit dem Standard Q.SIG einzugehen. Dazu lediglich Kürzel wie ISO, ETSI und ECMA zu benennen, ist einfach zu wenig. Zumal das Gremium ECMA (European Computer Manufacturers Association) mit der geforderten Signalisierung gegenüber Q.SIG nichts zu tun hat. Bei Cisco erkennt man dagegen mittlerweile den Stellenwert von Q.SIG. Nach Lepa unterstütze der Cisco-Call-Manager in der aktuellen Version folgende QSIG-Leistungsmerkmale, implementiert nach der ISO-Spezifikation:

• CLIP /CLIR (Calling-Line-Presentation/-Restriction)

• CNIP (Calling-Name-Id.-Presentation)

• CNIR (Calling-Name-Id.-Restriction)

• COLR (Connected-Line-Restriction)

• CONP (Connected-Name-Id.-Presentation)

• CONR (Connected-Name-Id.-Restriction)

• Call-Completion-on-BusyE Call-Completion-on-No-Reply

• Call-Forward-Unconditional

• Call-Transfer

• MWI (Message-Waiting-Indicator)

• Diversion-Counter

Drei weitere – CCBS (CallBack-on-Busy), CCNR (Call-Back-on No-Reply) und Path-Replacement – seien für das nächste Release des Call-Manager geplant. Doch selbst dann wäre das Ende der Fahnenstange via Q.SIG nicht erreicht, wie die Liste von Tenovis zeigt. Dazu könnten die Funktionen von Q.SIG+ kommen. Immerhin scheint der Netzwerk-Marktführer allmählich zu erkennen, dass der Weg in die IP-Telefonie über die in den Unternehmen installierten TK-Anlagen führt. Zumal in wirtschaftlich schweren Zeiten Start-ups, auf deren grüner Wiese man sich mit einer VoIP-Lösung in Reinkultur tummeln könnte, zu einer absoluten Mangelware geworden sind.

Das scheint man mittlerweile auch bei HP so zu sehen. »Die Mitel-Networks-3300-ICP unterstützt sowohl die ETSI- als auch die ISO-Variante von Q.SIG«, betont Rommel. Alle Leistungsmerkmale aufzuführen, die darüber für eine Telefonie im gemischten Bereich unterstützt würden, so der HP-Manager, würde den Rahmen sprengen. Er nennt unter anderem Funktionen wie Namen- und Nummernübertragung, Message-Waiting, Rufumleitung/Weiterschaltung, Rückruf bei Besetzt und Nicht-Antwort sowie Routenoptimierung.

Sollte sich bei einigen Netzwerkherstellern wirklich eine Tendenz zur Öffnung gegenüber der klassischen Telefoniewelt abzeichnen? Das sollte eigentlich auch die TK-Anlagen-Hersteller allmählich motivieren, sich endlich gegenüber der IP-Telefonie und den direkten Wettbewerbern, den anderen TK-Anlagen-Produzenten, über Q.SIG mehr zu öffnen.

Der Nutzen des Anwenders

Wie steht es last, but not least um den Anwendernutzen, der aktuell den Unternehmen über die einzelnen VoIP-Lösungen winkt? Dazu stellten wir den Herstellern folgende Frage: Welche Anwendungen welcher Hersteller können auf ihrer Anwendungsschnittstelle, beispielsweise TAPI (Telephony-Application-Programming-Interface), nachweislich aufsetzen?

3Com wollte dazu aus Zeitmangel keine Anwendungsliste liefern. Enterasys Networks ging darauf nicht ein. Für Avaya beließ es Neumann bei der Aufzählung von möglichen Anwendungsschnittstellen innerhalb seiner Communication-Manager-Lösung wie neben TAPI, die Novell-Variante TSAPI, 3TAPI und CYLAN, obwohl die Auflistung integrierter Anwendungen gefordert war. Anders Cisco Systems: Lepa verweist für nähere Informationen auf den Link www.cisco.com/go/apps mit allen entsprechenden Partnerlösungen. Er führt aber auch eine ganze Reihe von Partnern und ihre Anwendungen auf, die auf der TAPI-Schnittstelle des Herstellers aufsetzen können:

• Telesnap: Snapware 4.2

• Telesnap: PM-Operator 4.2

• Netwise: Netwise Now 6.1/CTC 2.1

• ARC: ARC-Console-ConnectVersion 2.1.17

• Checkmate: Checkmate-Legacy-PBX-Gateway 1.0

• Clarus Systems: Clarus-IPC Version 2.02

• Crystal Voice: Crystal-Voice-Remote-Extension Version 3.0

• Nevotek: Nevotek-Adagio-Multi-tenant-Voice-Messaging Version 1.3

• Nevotek: Nevotek-V/IP-Suite- PMS-Interface Version 1.3

• Nice: Nice-CEM 8.8 with VoIP driver for TAPI integration CD-89-CT-CCM-CTM

• SDC: Intellidesk Enterprise Version 5.4

• Verint: Ultra-Intelligent-Recording Version 9

• Zeacom: Corus Version 3.0

Rommel von HP verweist für Mitel-Networks-3300-ICP auf TAPI v.2 für Clients und einen Third-Party-Server, darüber hinaus auf XML als Anwendungs-Schnittstelle. Das Spektrum solcher Anwendungen reiche von der Sprachaufzeichnung via UMS (Unified-Messaging-System) über CTI (Computer-Telephony-Integration) bis hin zu Videokonferenz-Anwendungen. Als getestete und implementierte Lösungen benennt er IXI-Call von Servonics, Pro-Call von Estor sowie Thor von Speech Design. Auch Schulz von Innovaphone steuert für deren VoIP-Lösung eine ganze Reihe an Anwendungen bei, die auf der TAPI dieses Herstellers aufsetzen können:

• Procall von Estos

• IXI-Call von Servonics

• Achat von Authensis

• Snapware von Telesnap

• Caesar von CAE

• Calisto von Seavus

• Outlook von Microsoft

Sparsam mit dem potenziellen Anwendernutzen auf der VoIP-Schiene gibt sich dagegen Reckemeyer von Alcatel-SEL. Er verweist kurz und bündig auf den eigenen TAPI-Premium-Server und die CTI-Schnittstelle, beispielsweise von Netmeeting. Das war´s. Kaum hilfreich für den potenziellen Anwender war die Antwort von Lucent. Anscheinend wurde hier die Frage nicht verstanden, oder es fehlt an nennenswerten Anwendungen, die auf der TAPI-Schnittstelle, sofern vorhanden, aufsetzen können.

Wesentlich anwenderfreundlicher gibt sich Tenovis. Biermann liefert eine umfassende Tabelle, aus der für TAPI – neben dem eigenen Com4-Tel B, PS13-Master-Phone, T1-PC-Link und MCC – Anrufbeantworter und Aufzeichnungssysteme (ASC Telecom), MRS (Cycos Thetacom), Procall (Estos), UPR (Information Management), Desk-Phone-Assistant (Austria), Marketing-Manager (Update.Com Software AG), Pho-Netic und ISDN-Notruf (beide Taskarena) sowie Snapware (Telesnap) hervorgehen.

Info Handling an der Anwendungsschnittstelle

CTI (Computer-Telephony-Integration) stellt die Verbindung zwischen Anrufer und seinen Adressdaten her. Zwischen den Telefonadressdaten und beispielsweise TAPI (Telephony-Application-Programming-Interface) vermittelt wiederum CLI (Caller-Line-Identification), um darüber automatisch Geschäftsanwendungen anzustoßen. Umgekehrt können via TAPI Telefonfunktionen direkt aus den Anwendungen heraus aufgerufen werden. Der Implementationsleitfaden CSTA (Computer-Supported-Telecommunications-Applications) der ECMA (European-Computer-Manufacturers-Association) ebnet dazu den Weg.

Das alles funktioniert aber nur zufriedenstellend innerhalb der IP-Welt. Kommen klassische Telefone ins Spiel, ist das Unternehmen auf der TK-Anlagen-Seite mit einer proprietären und umständlichen Umsetzung konfrontiert. Jeder dieser Hersteller integriert die ISDN-Telefonie auf seine spezifische Art. Dazu führt er die Sprachdaten innerhalb »ihres« TK-Anlagen-Netzes separat zu denen des IP-Netzes. Das verkompliziert die Sache unnötig und führt in der Summe zu einem wenig zufriedenstellenden Lösungsansatz und zur Produktbindung. Auch Anwendungen wie UMS (Unified-Messaging-System) und internetfähiges Communication-Center lassen sich deshalb in diesem gemischten Bereich nur umständlich und nicht immer zufriedenstellend lösen. Dieses Beispiel macht deutlich, dass für den Anwender eine schnellere Ablösung der bestehenden TK-Anlagen-Welt durchaus sinnvoll sein kann.

Eine generelle Crux der TAPI-Schnittstelle als wichtigstes Interface zur Anwendungsintegration bleibt: Sie wird von den TK-Anlagen- wie den Netzwerkherstellern in der Regel so spezifisch angepasst, dass von einem Standard eigentlich keine Rede mehr sein kann. Entsprechend aufwändig ist die Integration jeder einzelnen Anwendung. Auf diese Weise versuchen diese Hersteller die Produktbindung bis hinauf zu den Anwendungen auszudehnen. Für diese umständliche Integration spricht letztlich auch das unterschiedliche sowie mehr oder weniger breit ausgelegte Spektrum an Anwendungen bei den einzelnen VoIP-Herstellern. Mehr Standardtreue besonders bei der TAPI-Implementation wäre nötig, damit die Anwender endlich im weiteren Umfang und ohne strikte Produktbindung von VoIP profitieren könnten. Repräsentieren die Anwendungen für das Unternehmen doch den eigentlichen Nutzen der VoIP-Installation. Hadi Stiel