- Verschifft
- 3. September 2026 um 22:54 UTC
- Autor
- Kamo
- Ausschuss
- 754050c
Der AMI-Client meldet sich mit 'Events: Off' an und sendet nur Aktionen, also nichts auf FreePBX eines Kunden hat der Plattform jemals mitgeteilt, dass ein Anruf ankomme. Dieses Schweigen ist was machte einen verpassten Anruf auf dem Handy-Softphone unwiederbringlich: ein Hörer, dessen SIP-Registrierung Android zurückgefordert hatte, war einfach nicht da, und kein zweites Signal existierte, um es zu wecken. Eine ZWEITE AMI-Verbindung hört jetzt mit 'Events: call' und leitet DialBegin (Ring) und DialEnd (beantwortet/ended) auf die Plattform. Getrennte Verbindung weil der Aktionskunde ein strenges Anfrage-/Antwort-Paar ist -- unerbetene Ereignisse würde sich mit seinen Antworten verabreden und es würde das Paket von jemand anderem als seine lesen Eigene Antwort. Details, die entscheiden, ob dies funktioniert: - Linkedid, nicht Uniqueid. Uniqueid ist pro Kanal, so dass die Absage würde unter einer anderen ID ankommen und nie mit dem Ring mithalten soll, den sie beenden soll. - Nur PJSIP/ und SIP/ Endpunktkanäle ergeben eine Erweiterung. Lokal/, IAX2/ und DAHDI/ Beine erreichen alle den Parser und keiner von ihnen ist die Erweiterung eines Mitglieds. - CallerIDName wird fallen gelassen, wenn es nur die Zahl wiederholt, das ist, was Asterisk füllt aus, wenn der Beförderer keinen Namen geschickt hat. - Best-Effort, keine Wiederaufnahmen, ein 5s Timeout: Dies ist auf dem kritischen Weg eines Anrufs Klingeln jetzt, und ein Bericht, der kommt, nachdem der Anrufer aufgegeben hat, ist wert nichts. - Der Ereignis-Endpunkt ist von UPLOAD_URL abgeleitet, so dass ein Operator eine URL konfiguriert und kann die beiden Hälften nicht auf verschiedene Cluster richten -- eine Spaltung, die weiterhin Aufnahmen hochzuladen, während Anrufe leise aufhören zu klingeln. Benötigt einen API-Schlüssel mit dem neuen VOIP_CALL_EVENTS-Maß.