Integrationen - Webhooks¶
Webhooks werden durch ein Anrufereignis ausgelöst, wie z. B. einen klingelnden Anruf, einen angenommenen Anruf, einen aufgelegten Anruf usw. Wenn dieses Ereignis eintritt, stellt die VoIPstudio-Plattform eine HTTPS-Anfrage (POST) an die für den Webhook konfigurierte URL - einen Webserver (API) eines Drittanbieters. Siehe mehr auf Wikipedia
- Klicken Sie auf Integrationen.
- Scrollen Sie nach unten zu Webshooks und Aktivieren.
- Wählen Sie Webhook hinzufügen, um einen neuen zu erstellen.
- Geben Sie einen beliebigen Namen für den neuen Webhook ein, um ihn zu identifizieren.
- Wählen Sie die Ereignisse aus, auf die Sie warten möchten. Beachten Sie, dass der Typ
Call State change
alle Ereignisse einschließt. - Geben Sie die von Ihrer Anwendung verwendete URL ein.
- Um einen Webhook zu bearbeiten, klicken Sie einfach auf den Namen.
- Wenn nicht mehr benötigt, klicken Sie einfach auf Webhooks deaktivieren.
HINWEIS: Es wird nur das HTTPS-Protokoll unterstützt.
HINWEIS: Damit eine URL gespeichert werden kann, muss diese gültig sein und auf https-Anfragen antworten.
Verfügbare Ereignisse¶
Mit VoIPtudio WebHooks überwachen wir folgende Kategorien von Anrufstatusereignissen:
- Entgangener Anruf
- Anruf läutet
- Anruf verbunden
- Anruf beendet
- Call State Change - dieser letzte umfasst alle vorherigen Ereignistypen. Er wird bei jeder Änderung des Anrufstatus ausgelöst: INITIAL, KLINGELN, VERBUNDEN, ON_HOLD, AUFLEGEN.
Beachten Sie, dass überwachte Ereignisse den Anrufstatus anzeigen und mit SIP-Signalisierungsmeldungen übereinstimmen, wie unten beschrieben:
- INITIAL: SIP INVITE senden an den entsprechenden Endpunkt (Telefon).
- RINGING: Antwort des Endpunkts von SIP INVITE. Es zeigt an, dass der Endpunkt aktiv ist und es bereits klingelt.
- CONNECTED: SIP 200-Nachricht, die anzeigt, dass der Benutzer den Anruf angenommen hat.
- ON_HOLD: Der Anruf ist pausiert. Dies entspricht einem SIP INVITE mit
body: a=sendonly
- HANGUP: Zeigt an, dass der Anruf beendet wurde. Dies entspricht einer SIP BYE Message.
Neben den Ereignissen zum Anrufstatus sind die folgenden zusätzlichen Ereignisse verfügbar:
- Empfangene SMS
Ereignis-Attribute¶
Ereignisse werden als HTTPs POST-Anfragen mit JSON-Body geliefert - zum Beispiel:
{
"id":"uk003.608920d55f7ac3.77053295",
"event_time":"2021-04-28 08:46:13",
"event_name":"call.hangup",
"call_id":139543232,
"state":"HANGUP",
"connected_at":"2021-04-28 08:46:02",
"start_time":"2021-04-28 08:45:55",
"context":"LOCAL_USER",
"destination":"in",
"duration":11,
"t_cause":"Normal Clearing",
"src":"447854740947",
"src_id":"0",
"src_name":"\"442035141598\" <2035141598>",
"dst":"441183211001",
"dst_id":"10002",
"dst_name":"John Smith"
}
Die Attribute sind wie folgt:
id
(String) - eindeutige ID eines Ereignissesevent_time
(string) - Zeit eines Ereignisses im Format J-m-d H:i:s UTC-Zeitzoneevent_name
(string) - Name eines Ereignisses, einer von:call.initial
- Anruf im Ausgangszustandcall.ringing
- Anruf läutetcall.missed
- Verpasster (unbeantworteter) Anrufcall.connected
- Anruf ist verbundencall.hangup
- Anruf wird beendetcall.hold
- Anruf wird gehaltencall.unhold
- Anruf wird aufgehoben
call_id
(Ganzzahl) - dies ist die numerische ID des Aufrufs. Sie kann später für den Zugriff auf Ressourcen über die REST-API verwendet werden. Die Beziehung zu REST-API-Ressourcen ist:call.id
- Beispiel REST-API-Anfrage:cdr.live_id
- Beispiel REST-API-Anfrage: GET/v1.1/cdrs?filter=[{"property": "live_id", "operator":"=", "value":"{call.id}"}]
monitor.live_id
- Beispiel einer REST-API-Anfrage: GET/v1.1/monitors?filter=[{"property": "live_id", "operator":"=", "value":"{call.id}"}]
state
(String) - Zustand des Aufrufs, einer von:INITIAL
- Anfangszustand des AnrufsACCEPTED
- Click-2-Ruf wurde angenommenRINGING
- Ziel wird angerufenCONNECTED
- Anruf ist verbundenON_HOLD
- Anruf wird gehaltenHANGUP
- Anruf wird beendet
connected_at
(String) - Uhrzeit, zu der der Anruf verbunden wurde, im Format Y-m-d H:i:s UTC-Zeitzone. Voreinstellungnull
start_time
(string) - Uhrzeit, zu der der Anruf gestartet wurde im Format Y-m-d H:i:s UTC timezone.context
(string) - Kontext des Anrufs innerhalb der TK-Anlagedestination
(string) -in
für eingehenden Anruf,out
für ausgehenden Anrufduration
(Integer) - Dauer des Anrufs in Sekundent_cause
(string) - Beendigungsursachesrc
(string) - Nummer der Rufquellesrc_id
(integer) - Numerische ID der Rufquellesrc_name
(string) - Name der Rufquelledst
(String) - Nummer des Anrufzielsdst_id
(integer) - Numerische ID des Anrufzielsdst_name
(String) - Name des Rufziels
SMS-Empfangsereignisattribute sind wie folgt:
id
(string) - eindeutige ID eines Ereignissesevent_time
(string) - Zeit eines Ereignisses im Format Y-m-d H:i:s UTC-Zeitzoneevent_name
(string) - Name eines Ereignissessms.received
- customer_id` (integer) - Numerische ID des Kundenkontos, das die SMS-Nachricht erhalten hat
user_id
(integer) - Numerische ID des Benutzerkontos, das die SMS-Nachricht erhalten hat (optional, Standard:null
)from_no
(string) - Absenderrufnummer- to_no` (string) - Rufnummer, die die SMS-Nachricht erhalten hat
- Text" (String) - Inhalt der empfangenen Nachricht
Zugehörige REST-API-Endpunkte¶
Nach dem Empfang des Webhook-Ereignisses wie im obigen Beispiel (call_id
= 139543232
) kann man die Anrufressource über die REST-API abrufen und aktualisieren:
GET /v1.1/calls/139543232
und den Anruf an die Nebenstelle 2002
weiterleiten:
PATCH /v1.1/calls/139543232
{
"dst": "2002"
}
Hinweis: Die REST-API-Ressource /calls
repräsentiert einen aktiven laufenden Anruf. Sobald der Anruf beendet und das Ereignis call.hangup
empfangen wurde, ist er nicht mehr am Endpunkt /calls
verfügbar. Stattdessen kann auf sie über die Endpunkte /cdrs
(Call Details Report) und /monitors
(Call Recordings) zugegriffen werden, indem ein Filter auf das Attribut live_id
mit dem Wert call_id
aus dem Webhook-Ereignis verwendet wird, zum Beispiel:
GET /v1.1/cdrs?filter=[{"property":"live_id","operator":"=","value":"139543232"}]
or
GET /v1.1/monitors?filter=[{"property":"live_id","operator":"=","value":"139543232"}]
Fehlersuche bei Webhooks¶
Mit den detaillierten Berichten aus dem VoIPstudio-Dashboard können Kunden den Workflow aller SIP-Pakete in einer grafischen Ansicht für jeden einzelnen Anruf überwachen. Es zeigt auch die Webhooks-Benachrichtigungen an, die an Ihre Listening-URL gesendet wurden, einschließlich ihres Inhalts. Dies kann bei der Fehlersuche in Ihrer Webhooks-Benachrichtigungsverteilung sehr nützlich sein.
Sie brauchen nur den Call Detailed Report zu durchsuchen und auf die entsprechenden Anrufe zu klicken, um die übermittelten Ereignisse und deren Inhalt zu überprüfen. Dies sollte mit der Benachrichtigung übereinstimmen, die Sie auf dem Server erhalten haben. Bitte führen Sie die folgenden Schritte aus:
- Öffnen Sie im Admin-Dashboard den Abschnitt
History
. - Klicken Sie auf
CDR
, um eine Liste der letzten Anrufe zu öffnen, die unter der PlattformVoIPstudio
verarbeitet wurden. - Identifizieren Sie den Anruf, den Sie prüfen möchten, und klicken Sie darauf, um detaillierte Informationen zu dem entsprechenden Anruf zu erhalten.
- Identifizieren Sie unter
Call Flow
die Spalte Ihres API-Servers. - Sie müssen sehen, dass für jedes Ereignis, das Sie als Webhook-Ereignis eingestellt haben, eine POST-Anfrage an den Server gesendet wird. Klicken Sie darauf, um sie zu erweitern.
- Hier werden die Details der Webhook-Post-Antwort angezeigt.