Gelöst

Cloud PBX API (oder zumindest Webhooks für ein- und ausgehende Gespräche)

vor 6 Jahren

Guten Abend,

 

wir sind ein kleines IT-Systemhaus aus Karlsruhe (Foundata GmbH) und verwenden die Telekom Cloud- PBX selbst. Zudem integrieren wir diese auch in Kundenumgebungen (die Mobilfunkintegration ist unserer Meinung nach weiterhin konkurrenzlos)

 

Zunehmend ist es für uns und unsere Kunden ein großes Problem, dass weiterhin keine wie auch immer geartete API bereitgestellt wird. Vorzugsweise RESTful oder mindestens eine andere über HTTPS ansprechbare Lösung (SOAP, irgendetwas "eigenes"... alles wäre besser als Nichts).
Dies wäre noch zu verschmerzen, wenn es zumindest für Basisevents Webhooks gäbe (so dass die CloudPBX wenigstens anderen Systemen per HTTPS etwas zu eignenden Anrufen mitteilen könnte oder Anrufe über HTTPS initialisiert werden könnten). Der PBX -API/td-p/3381665" target="_blank">Feature Request-Thread ist mir bekannt, aber dort tut sich nix mehr / als gelöst markiert.


Unsere Fragen dazu, wie ist hier der Status?

  1. Gibt es zwischenzeitlich belastbare Informationen ob und wann eine (RESTful) API angeboten wird und welchen Umfang diese haben wird?

    • https://cpbx-hilfe.deutschland-lan.de/de/grundlagen/produktneuerungen#_82282 enthält dazu nichts Substantielles.

    • Es hieß - auch hier im Forum sowie in persönlichen Gesprächen - immer wieder, dass ein API geplant sei und z.B. Q4 2018 käme.
      • Wir konnten uns auch nicht vorstellen dass eine Cloud-Telefonanlage damit nicht ausgestattet würde und haben darauf vertraut, dass irgendwann™ eine halbwegs brauchbare Schnittstelle angeboten würde (alleine schon da jedes ernstzunehmende Konkurrenzprodukt über eine RESTful-API oder zumindest Webhooks verfügt).
      • Zwischenzeitlich kommen mir aber Zweifel und so kann ich eigentlich allen Kunden mit absehbaren Integrationsbedürfnissen abseits des Desktops nicht mehr guten Gewissens zur CloudPBX raten. Um das Thema ist es einfach komplett still geworden.
  2. Die CloudPBX basiert bekanntlich auf Komponenten von BroadSoft/Cisco. Ich PBX -API/m-p/3739437#M3119" target="_blank">lese immer wieder hier im Forum, dass die Boardsoft/Cisco-Basis über ein API verfügen würde und die passende Dokumentation über eine Cisco-Partnerschaft verfügbar sei. Jedoch sind die Angaben so diffus, dass nicht klar ist, ob die API dann auch wirklich (natürlich ohne Support durch die Telekom) ansprechbar wäre, wenn man die passende Dokumentation in den Händen hielte. Daher ganz konkret:

    1. Für welches Produkt genau müsste bei BroadSoft/Cisco die Schnittstellendokumentation besorgt werden um an eine un-supportete API-Beschreibung zu kommen? Ist es Cisco BroadWorks?
    2. Falls ja, geht es dann um XSI (eXtended Services Interface)? Was ja zu vermuten wären wenn man sich die CloudPBX Go-TAPI-Hilfeseite anschaut, wo explizit von XSI-http mit XPS Server https://client.deutschland-lan.de die Rede ist.
    3. Unabhängig davon, ob dies Supported ist oder nicht: Gibt es zumindest ein Einstiegs-Beispiel (wenigstens ein API-Call mit Authentifizierung) oder Hinweise, ob es konkrete Einschränkungen gibt oder z.B. nur eine funktionale Untermenge des XSI genutzt werden kann?

 

Aktuelles Beispiel: Zammad

 

  • Wir wollen die Telefonie an das immer beliebtere Zammad-Ticketsystem anbinden:
    • Damit bei eingehenden Anrufen direkt über eine Websocket-Notification in der UI von Zammad sichtbar ist welche Tickets der Kunde ggf. offen hat
    • und aus der Zammad WebUI Anrufe initialisiert werden können.
  • Dazu wären wirklich nur sehr einfache Hooks notwendig (bei eingehenden Anruf -> HTTPS-REST-Call zu Zammad mit Übertragung der CallerID oder eben umgekehrt ein POST zur Initialisierung eines Anrufs). Es steht sogar eine generische Implemenetierung bereit. Für Sipgate und Cisco(sic!) Placetel bereits dedizierte Integrationen.

 

Wie geht es weiter? GIbt es ggf. doch schon interne Informationen (siehe obige Fragen) die es nicht bis in unser Haus geschafft haben?

 

Wir sind weiterhin sehr von der nativen Mobilfunkintegration ohne lästige SIP-Clients auf Mobiltelefonen (inkl. verzögerter Signalisierung etc. pp) überzeugt (Hauptargument für die Lösung der Telekom) und dass T-Mobile im Vergleich ein gutes Netz sowie auch Mobile IPv6 bereitstellt.

Aber spätestens wenn Placetel Mobilfunk (mutmaßlich auf Vodaphone-Basis) kommt ein Anbieter mit API und ebenfalls brauchbarem Mobilfunknetz ins Spiel (immernoch fehlendes IPv6 können aktuell ja noch viele verschmerzen). Es muss sich unserer Meinung nach an dieser Stelle endlich etwas tun.

 

Viele Grüße

Andreas

3405

7

    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...

    Das könnte Ihnen auch weiterhelfen

    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...