P.Hoffmann
Neuer User
- Mitglied seit
- 1 Feb 2009
- Beiträge
- 179
- Punkte für Reaktionen
- 0
- Punkte
- 0
Gibt es vllt. einen anderen Patch für Asterisk 1.6, den in diesem Zusammenhang nutzen könnte?
Zuletzt bearbeitet:
Mit dem Pickup-Patch müsste die Nummer eigentlich beim Pickup geändert d.h. korrekt angezeigt werden (getestet mit modifiziertem pickup-mgernoth-2006-10-03.patch und Asterisk 1.2.24)> - Nach dem Pickup steht im Display z.B. *821 und nicht die Nummer des Anrufers
Ist so. Um das zu ändern, müsste in den Pickup-Patch quasi der Patch zum Ändern der angezeigten Rufnummer (SIP INFO message mit c: message/sipfrag und Inhalt "From: xxx\nTo: yyy", siehe Quelle und Ziel eines Anrufs ändern bzw. snom Wiki/FAQ, voip-info Wiki) eingearbeitet werden (bzw. zumindest die relevanten Teile davon.)
...da bin ich mir nicht ganz sicher, wie das Verhalten ist und ich kann's im Moment nicht mehr testen, da der Pickup-Patch wegen Problemen gerade wieder deaktiviert werden musste... Weitere Infos zu den Problemen und hoffentlich ein Test des "Anruflisten-Verhaltens" werde (hoffentlich) folgen...> - Nach dem Pickup zeigt das "andere" Telefon einen Anruf in Abwesenheit
Auch dazu müsste der Pickup-Patch wohl um Code aus einem anderen Patch ergänzt werden: Diesmal wäre dies der "Call answered elsewhere" Patch, siehe Asterisk,Snom und unbeantwortete Anrufe.
Beides geht dann aber nur mit Snom.
> Nach dem Pickup zeigt das "andere" Telefon einen Anruf in Abwesenheit
Auch dazu müsste der Pickup-Patch wohl um Code aus einem anderen Patch ergänzt werden: Diesmal wäre dies der "Call answered elsewhere" Patch, siehe Asterisk,Snom und unbeantwortete Anrufe.
Beides geht dann aber nur mit Snom.
Könnte das evtl. an der while-Schleife und/oder ast_channel_walk_locked in der Funktion transmit_state_notify im Patch liegen? Mit 11 x 10 Überwachungen gibt das immerhin 110 ast_channel_walk_locked-Aufrufe...
Ich persönlich patche lieber, als dass ich solche Applikationen oder Daemons laufen habe. Ist aber Geschmackssache.foschi würde jetzt laut "JAAA" rufen. Ich habe mit ihm schonmal diskutiert und teile mittlerweile seine Meinung: eine am Manager-Interface lauschende Applikation kümmert sich um das ganze LED und Display-Gedöns. Und da bin ich (gedanklich) dran. Wäre auch schicker, da man den Asterisk dann freiweg updaten könnte, ohne großes Rumgepatche.
Sind ja nicht 110 Anrufe, und aus dem Tritt kommt evtl. auch das Telefon, nicht der * . Es treffen halt wohl an jedem Telefon (durch die ganzen Aufrufe) leicht verzögert 10 dialog-Info-Meldungen ein, die das Telefon verarbeiten muss, und dann stottert der Klingelton... Ist jedenfalls meine spontane Erklärung.Aber unter uns: was tut dieser Asterisk, wenn 110 Aufrufe ihn derart aus dem Tritt bringen?
Uuups. Sorry, der Thread hier wird langsam unübersichtlich... Ich finde schon meine eigenen Beiträge nicht mehr.Das Problem ist bei mir schon lange siehe hier auch in diesem Thread.
Habe leider (?) keinen 1.6er am laufen. Und da Digiums Web-SVN zur Abwechslung mal wieder nicht funktioniert, kann ich's nicht mal im aktuellsten Code anschauen...Was ist mit 1.6 gibs da das Problem auch noch ? Damit sollte es ja alles ohne patch funktionieren. Zumindest konnt ich das damals schonmal kurz testen.
Die Chancen für Backports solcher Änderungen nach 1.4 oder sogar 1.2 von den offiziellen Entwicklern sind wohl gering.Da wollte sich einer von den digium leuten drum kümmern.
Gemäss einem kurzen Blick auf den Code würde ich eben sagen, ab 1.6.2.irgendwas sieht's gut aus. (Es wäre zu testen, ob das so mit den snoms auch klappt, oder ob die sich trotzdem verschlucken.Ich weiss nich ob das im 1.6 asterisk verwirklicht wurde.
Genau. Habe leider wirklich keinen 1.6er im Moment...Aber das würde man ja feststellen wenn mal jemand mit dem 1.6 spielt
Im Moment höchstens für den (uralten) 1.2er...P.S.: Philipp scheint sich ja der Sache mal anzunehmen.
Ich eigentlich auch nicht...Ich habe dafür zzt. leider keine Zeit.