Zusätzlicher IN-Push

[phortx]

Ich implementiere gerade einen Bot, der Benutzer-Daten automatisiert prüfen soll.

Der Ablauf ist im etwa wie folgt:

• Kunde gibt eine Bestellung auf
• Er wird von SipGate angerufen
• Er bekommt via AWS Polly seine Daten vorgelesen mit der Frage ob sie richtig sind
• Er kann dann 1 oder 2 drücken

Das funktioniert soweit alles wunderbar. Heute haben wir das auf dem Test-Server in Betrieb genommen und dabei ist etwas passiert, was bisher in meiner lokalen Entwicklungsumgebung nicht passiert ist: Nachdem ich das Telefonat angenommen habe, bekomme ich zusätzlich zu dem direction=out Push Aufruf auch einen direction=in Push Aufruf.

Hier die beiden Requests:

event: newCall
direction: in
callId: 54576B150B0C0D3A5D5745595259735A5253515C525950547D5D5C4753564D524444421D1A
origCallId: 52546B150B0C0D3A5D0618050605780B08020F48525B51557C5B5D5059545953474D465B1A50005E5E5F40725C5B4B597D527C55560E5D585B5C424B5A4E5D0E7141185E
from: ...
to: ...
user[]: ...
userId[]: ...
fullUserId[]: ...

event: newCall
direction: out
callId: 52546B150B0C0D3A5D0618050605780B08020F48525B51557C5B5D5059545953474D465B1A50005E5E5F40725C5B4B597D527C55560E5D585B5C424B5A4E5D0E7141185E
origCallId: 52546B150B0C0D3A5D0618050605780B08020F48525B51557C5B5D5059545953474D465B1A50005E5E5F40725C5B4B597D527C55560E5D585B5C424B5A4E5D0E7141185E
from: ...
to: ...
user[]: ...
userId[]: ...
fullUserId[]: ...

Ich dachte erst, das sei eine Art Weiterleitung, aber dann müsste laut Doku ein diversion Feld vorhanden sein, oder?

Warum bekomme ich diesen in-Aufruf? Wie kann ich das debuggen? Und was mache ich mit dem zweiten Aufruf?

Ich habe mal zum Spaß einfach mal ein Reject als Antwort auf den in-Aufruf gesendet, dann bricht der Anruf ab.

Lokal habe ich mit einem SipGate Basic-Account entwickelt (keine in-Aufrufe). Auf dem Test-Server arbeite ich mit einem Team-Account (mit in-Aufrufen).

[phortx]

Zwischenstand: Das Problem besteht weiterhin und seit Monaten keine Reaktion von SipGate auf das Ticket, meine Mails an den Support oder meine Anrufe.

Ich weiß mittlerweile, dass es nicht an den unterschiedlichen Accounts liegt. Lokal auf meinem Rechner tritt das Problem des IN-Events nicht auf, auf dem Server schon.

[maxnowack]

@phortx rufst du vielleicht eine Rufnummer an, die auch mit deinem Team-Account verbunden ist? Wenn die Rufnummer in keinster Weise mit sipgate zu tun hat, kann ich mir das Verhalten nicht erklären …

[phortx]

Moin und danke für die Antwort!

Tatsächlich sind from und to des newCall Events identisch und beides die Nummern des SipGate Team Accounts. Warum, ist mir nicht ganz klar, aber auf meinem Rechner ist das auch so und funktioniert einwandfrei.

Ich initiiere den Call via Request an sessions/calls mit folgenden Parametern:

{
  deviceId: 'e0',
  callee: '(sipgate team nummer)',
  callerId: '(sipgate team nummer)',
  caller: '(anzurufende Nummer)',
}

[DennisBecker]

Durch den API Call auf /sessions/calls startest du einen Click2Dial Call, weshalb zuerst ein eingehender Anruf auf die e0 durchgeführt wird und wenn dieser Anruf angenommen wurde, wirdnein ausgehender Anruf gestartet. Daher auch 2 Events.

[phortx]

Interessant. Warum muss ich den Call nicht annehmen, wenn ich das ganze auf meinem lokalen Rechner mache mit dem selbem Account? Tatsächliche brauche ich eigentlich gar keine Gegenstelle, da ich nur via Push API ein paar Sound-Files abspiele und auf DTMF Events reagiere. Meine Lösung sieht bisher so aus, dass ich via /sessions/calls einen Anruf starte und diesen dann via Push API fernsteuere. Ist das sinnvoll oder gibt es einen besseren Weg einen solchen Bot zu realisieren?

[phortx]

Es wirkt ein wenig so als wäre ich die erste Person, die einen solchen Bot implementiert 😄