Nebenstelle sendet kein 2. Invite

[anditeich]

Liebe Experten,

ein nicht ganz alltägliches Konstrukt funktioniert leider nicht so, wie es eigentlich sollte (und vom Anbieter versprochen).

Konkret geht es um die Anbindung / Einbindung des Ticketsystems Liveagent in die 3cx. Liveagent ist ein Cloud-Ticketsystem, eingehende und ausgehende Emails, Chats - und eben auch Telefonate - werden dabei in Tickets zur weiteren Bearbeitung überführt.

Es lassen sich dabei verschiedenste VOIP-Anbieter integrieren (z.B.: Plusnet, Placetel, Equada) und eben auch 3cx. Die Anbindung erfolgt über ganz normale Sip-Credentials (Passwort, Username, Port). Für die 3cx gibt es ein eigenes Template, ansonsten noch ein Generic Template.

Das heisst, wir haben für LiveAgent eine eigene Nebenstelle angelegt, auf diese wiederum greift LiveAgent quasi als IP-Telefon zu, Gespräche (eingehend und ausgehend) werden also von/nach LiveAgent über die Nebenstelle abgewickelt, bzw. man telefoniert und empfängt dann Gespräche via Nebenstelle in der LiveAgent-Browserumgebung.

Das Problem: Egal ob wir ein Generic Template verwenden oder das vom Hersteller extra angebotene 3cx-Template: es werden keine ausgehenden Gespräche etabliert (eingehend klappt alles). Ich darf dazu schreiben, dass wir an unserer 3cx mit 3cx-SBCs an verschiedenen Standorten diverse IP-Telefone seit Jahren erfolgreich betreiben.

Unser Aufbau:

- 3cx V20 selbstgehosted bei Hetzner, shared Server, Split DNS
- Gateway: pf.sense
- Trunk: Easybell, Einzelnummer nur für LiveAgent
- In Easybell: Format E164 mit führendem „+“
- LiveAgent schickt Telefonate im Format +49.. heraus
- derzeitige Einstellung im Trunk: From Display Name: CallerDispName, Remote Party ID + P-Asserted Identity: OutboundCallerId

Wir haben vielfache Tests und Änderungen am Trunk selbst und auch am Generic Template von Liveagent probiert (das 3cx-Template ist nur rudimentär, hier lassen sich nur die Nebenstellen-Credentials eintragen).
Ebenso haben wir diverse Wireshark-Mittschnitte gemacht.

Das Muster ist immer gleich: Wenn wir die Nebenstelle bsp. mit einem Softphone verknüpfen oder direkt mit der Nebenstelle via Browser und unserer FQDN telefonieren, so gibt es:

- ein startendes Invite, dann folgt ein zweites Invite (möglicherweise Übergabe von Credentials) das Gespräch wird etabliert.

- bei Liveagent, oder besser gesagt: Wenn dieselbe Nebenstelle mit Liveagent verknüpft ist, schickt die 3cx nie das von Easybell erwartete zweite Invite. Der Trunk antwortet mit: 407 Proxy Authentification Required, gefolgt dann von ACK, das Gespräch wird verworfen, 3cx loggt als unauthorized.

Wir konnten noch nicht herausfinden, wie 3cx überhaupt erkennt, dass die Nebenstelle in diesem Fall nicht mit einem Softphone verbunden ist, sondern mit LiveAgent (obschon es technisch gesehen bei der Registrierung keinen Unterschied gibt?) und dann auf das zweite Invite verzichtet. Im Trunk selbst haben wir bei den Header-Einstellungen herumexperimentiert, erfolglos. Auch gibt es in der V20 ja keine Inbound-Roules mehr, womit wir diese bestimmte Nebenstelle in diesem Konstrukt als vertrauenswürdig hinterlegen können.

Beobachtet haben wir allerdings: Wenn wir den Easybell-Trunk direkt in LiveAgent anmelden (also auf 3cx komplett verzichten), dann klappen ausgehende Gespräche. Also muss die Ursache unserer Ansicht nach in der 3cx zu suchen sein.

Wir sind inzwischen ratlos, was wir noch probieren können. Dass es mit 3cx grundsätzlich funktionieren sollte, zeigt sich für uns daran, dass LiveAgent ja nicht ohne Grund ein eigenes 3cx-Template entwickelt hat, was bei anderen Kunden wohl ohne Probleme funktioniert.

Gibt es hier evt. jemanden, der uns in eine Richtung „schubsen“ kann?

Danke Euch!

 

[bitn2]

Der Live Agent sollte für die 3cx nichts anderes als ein Softphone bzw ein Endgerät sein. Was sagt das Log der 3cx denn zu so einem Anruf? Ausgehende Regeln korrekt eingerichtet?

 

[anditeich]

Guten Morgen! Danke für die Rückmeldung. Richtig: LiveAgent ist an der Nebenstelle nicht anders als ein Softphone / Ip-Telefon / Endgerät eingerichtet.

Wie schon der Wireshark-Mittschnitt ergibt der Verbose-Mitschnitt:

• Die Nebenstelle 108 (von LiveAgent gesteuert) startet korrekt einen INVITE für den Anruf.
• Die Verbindung erreicht die 3CX-Instanz und wird erkannt.
• 3CX versucht, den Anruf über den Trunk Easybell zu routen.
• Die Antwort des Trunks ist wie erwartet: 407 Proxy Authentication Required.
• ABER: Es erfolgt kein zweiter INVITE mit Credentials, wie er z. B. bei Anrufen über Zoiper oder den Webclient ausgelöst wird.

SIPPROXY|Resuming call from EXT 108 (LA) - Requesting credentials from trunk
SIPPROXY|No subsequent re-INVITE sent — dropping call

Bei Zoiper direkt an der Nebenstelle klappt das, bei Easybell direkt bei LiveAgent (ohne 3cx) terminiert auch. Nur nicht bei LiveAgent an der Nebenstelle für ausgehende Anrufe.

 

[bitn2]

Hmm, nach meinem Wissensstand ist da die 3cx und nicht das Endgerät für zuständig. Warum das nun mit dem Webclient oder Zoiper geht, aber mit dem Liveagent nicht? @fxbastler hast du da noch ne Idee?

 

[anditeich]

Die Proxy-Authentification wird von Easybell korrekt empfangen und im Log registriert:

|CallCtrl::createRouteToTrunk|[CM102002]: Gateway:[EASYBELL_TRUNK] can not be used for outb. call to:[+49XXXXXXXXX] reason:[407 Proxy Authentication Required]

Interpretation:
3CX erkennt also den 407 korrekt, aber:

es interpretiert dies nicht als „normale“ Challenge zur Authentifizierung, wie es bei anderen Szenarien (z. B. mit Zoiper) der Fall ist.
Stattdessen wertet 3CX den Trunk als nicht verwendbar („can not be used“), bricht den Call ab und markiert ihn als „not authorized“.

Ursachen mögliche?

- Der Call wird intern als nicht „trusted“ oder nicht „originated“ von 3CX selbst angesehen, sondern wie eine Art „externe Weiterleitung“. Da es aber keine Inbound-Roules in 3cx mehr gibt, lässt sich hier nichts machen?

- Oder: 3CX erwartet nicht, dass es selbst die Authentifizierung übernimmt, sondern „denkt“, der ursprüngliche SIP-Client (LiveAgent) müsste den INVITE wiederholen.

Oder: In der 3CX-Konfiguration ist der Anruf nicht eindeutig einer internen, registrierten Nebenstelle zugeordnet – dadurch entsteht Unsicherheit in der Authentifizierungslogik?

Grüsse!

 

[bitn2]

Inbound Rules sollten damit ja gar nichts zu tun haben, das ist ja ein ausgehender Call.

 

[anditeich]

Wir sind in der Analyse schonmal einen Schritt weiter. Denn wir haben mal die Unterschiede zwischen einem an der Nebenstelle angeschlossenen Softphone und Liveagent mitgeschnitten.


Softphone:
Sendet einen Invite an die Nebenstelle -> 3cx erkennt den Gesprächsversuch -> baut selbst neuen Invite an den Easybell-Trunk -> Easybell fordert Authentifizierung -> 3cx antwortet mit Credentials -> Gespräch kommt zustande.

Unterschied Liveagent - unsere These:

Sendet einen Invite an die Nebenstelle -> 3cx leitet diesen Invite direkt an den Trunk weiter -> 3cx agiert hier also nicht wie üblich als Back-to-Back-User-Agent, sondern eher wie eine Art SIP-Proxy -> Easybell antwortet mit: Bitte authentifizieren -> 3cx leitet diese Antwort an LiveAgent stumpf weiter ("Ich hab schließlich auch mit dem Invite nix zu tun gehabt") -> LiveAgent kann sich aber gar nicht authentifizieren, weil es die Easybell-Credentials nicht hat, sondern sendet seinerseits ein erneutes Invite (mehrfach): Keine Authentiziferung, kein Gespräch

Das sieht man auch ganz gut beim Paketmitschnitt an der pf.sense an der WAN-Schnittstelle beim ausgehenden Gespräch: die 407 Proxy Authentification des Easybell-Trunks erscheint dort - wenige Millisekunden danach dann ein nächstes Invite von Liveagent - und von vorn.

Nun der Knackpunkt aus unserer Sicht: Wenn Liveagent doch wie Zoiper oder ein anderes Softphone ganz normal an der Nebenstelle als Ip-Telefon angeschlossen ist: Warum an-erkennt 3cx Liveagent nicht als Softphone oder Ip-Telefon? Sondern leitet das Invite stattdessen 1:1 durch? Wo gibt es Punkte, bei denen sich LiveAgent und normale Softphone-Clients voneinander unterscheiden könnten?

Wenn wir hier etwas finden könnte uns das der Lösung näher bringen.

 

[bitn2]

Was sagt denn der Support von Liveagent dazu? Das Template stammt ja von denen...

 

[anditeich]

Die haben jetzt einen Paketmittschnitt von der WAN-Schnittstelle angefordert, was ich ihnen schickte. Da wird dann vermutlich herauskommen:

Überprüfen Sie die Konfiguration Ihrer 3cx. Stellen Sie eine geeignete Call Identification Rule auf. Diese soll bewirken, dass SIP-Requests von LiveAgent eindeutig als zu einer registrierten Nebenstelle erkannt werden. So dass 3cx als Back-to-Back-User-Agent fungiert und nicht mehr als Proxy und so die Authentifizierung gegenüber dem SIP-Trunk (Easybell) selbst übernimmt.

Doch genau solche Möglichkeiten gibt es in der V20 ja nicht mehr.

Wir haben jetzt das Problem, ja nicht gelöst, aber zumindest einen funktionierenden Woraround geschaffen: Glücklicherweise funktionieren ja einkommende Anrufe. Das heisst, die ganzen 3cx-Funktionalitäten (IVRs, Warteschleifen etc.) können benutzt werden. Um heraus zu telefonieren beschaffen wir uns dann neue IP-Rufnummern von Easybell, die wir direkt, ohne 3cx, in LiveAgent integrieren. In Easybell erfolgt dann eine Maskierung der Rufnummer auf die Rufnummer für die eingehenden Anrufe. So dass, wenn jemand zurückruft, dieser dann in der 3cx landet - und die dortigen Funktionalitäten durchlaufen kann - bis er dann zu LiveAgent durchgestellt wird.

 

[bitn2]

Puh... da ist aber Liveagent für verantwortlich und nicht 3cx. Jede andere App oder Telefon funktioniert ja, nur deren Produkt nicht. Da scheint in deren Template was falsch zu sein oder nicht angepasst für v20.