[Diskussion] [HOWTO] Asterisk mit dem Snom-Pickup-Patch patchen

Gibt es vllt. einen anderen Patch für Asterisk 1.6, den in diesem Zusammenhang nutzen könnte?
 
Zuletzt bearbeitet:
So, mit 1.2.16 klappt es; hier kann ich sowohl den Devstate- als auch den Pickup-Patch einspielen.
 
Zuletzt bearbeitet:
Ich habe den ganzen Thread als Asterisk 1.2.x gekennzeichnet. Ist besser so, denke ich.
 
Tag nochmal,

mittlerweile habe ich beide Patche ans Laufen bekommen.
Die LEDs am snom blinken, allerdings wird der Anruf beim drücken hierauf nicht übernommen: Es wird zwar eine Verbindung hergestellt, aber hören tut man nichts. Das andere Telefon klingelt weiter.

Hat jemand einen Tipp?

Viele Grüße,
Philipp.
 
Zuletzt bearbeitet:
Die 1. Taste steht z. B. auf "<sip:21@xxxx;user=phone>".
 
Zuletzt bearbeitet:
wenn du dir den link oben mal angeschaut hast, sollte dir was aufgefallen sein,
Code:
Taste 1: Extension <sip:21@xxxx;user=phone>[color=red]|*8[/color]
 
Ich setze hier in der kommenden "Langeweile im März" das Update von 1.2 auf 1.4 um - bei den Vorbereitungen hatte ich mir mit vorgenommen den PickupPatch zu updaten, s.h. das HOWTO.

Hat jemand Lust das ganze dann so mit-zu dokumentieren das wir 1.2 // 1.4 // 1.6 beschreiben können ?

1.6 werde ich IMHO nicht aktualisieren, daher die Bitte um Unterstützung.

LG Stefan
 
Ich habe Mist erzählt:
> - 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.)
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 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.
...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.

Ich bin immernoch dabei, mir die Zähne an diesem Thema auszubeißen - ich will's ohne Patch. Dabei bin ich darüber gestolpert, womit genau diese Verhalten angesprochen ist. Es läuft wieder mal darauf hinaus, in bestimmten Fällen SIP-Nachrichten bestimmter Bauart zu generieren - entweder in einem Patch für den Asterisk oder einfacher in einer separaten Applikation (Herzliche Grüße an foschi :).

Was meine Meinung zum Update der Telefonanzeige nach Pickup angeht: hier wird viel mit blf <sip...>|*8 gearbeitet. Bei uns ist es üblich, nur genau eine "Holen"-Taste zu haben, die mit <sip:*8@...> belegt ist. Dann gestaltet sich das Ändern der Anzeige wieder anders, womit man bei einer externen Applikation flexibler ist als beim Asterisk-patchen. Aber ohne gültige Subscriptions akzeptieren die Telefone die "dialog-info-xml"-Nachrichten nicht... Ich krieg gerade wieder 'nen Knoten im Kopf...
 
Probleme mit mgernot-Patch und Ringgruppen (Asterisk 1.2)

Mein eben erwähntes Problem:
Ich habe (u.a.)
- Asterisk 1.2.24 mit pickup-mgernoth-2006-10-03.patch
- (FreePBX 2.3.0)
- 11 Telefone, auf jedem eine Überwachung für die 10 anderen Telefone
- 1 Ringruppe, die auf alle 11 Telefone anruft
Kommt nun ein Anruf auf die Ringgruppe rein, laufen die Telefone (oder der Asterisk) Amok: Das Klingeln "stottert" ziemlich übel.
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...
Die Schleife und der channel_walk waren mir irgendwie gleich verdächtig...
 
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...

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.

Unsere Anlage ist zwar nur wenig größer, aber Gott sei Dank will nicht jeder jeden überwachen. Das Problem ist aber schon absehbar, deshalb mein Vorbeugen.

Aber unter uns: was tut dieser Asterisk, wenn 110 Aufrufe ihn derart aus dem Tritt bringen?
 
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.
Ich persönlich patche lieber, als dass ich solche Applikationen oder Daemons laufen habe. Ist aber Geschmackssache.

Aber unter uns: was tut dieser Asterisk, wenn 110 Aufrufe ihn derart aus dem Tritt bringen?
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.
Und ich habe noch kurz in den channel_walk- bzw. channel_find_locked-Code reingeschaut, da wird doch noch das eine oder andere gemacht (und wiederum 1 bis 2 geschachtelte Schleifen), da wundert mich nichts mehr... Und ich habe nun glaubs auch die Erklärung für die "initial deadlock"-Einträge in meinem Log...
Ich komme - zum spontanen und damit evtl. voreiligen Schluss, dass channel_walk ungeeignet ist.
 
Also das stottern ist eine Kombination aus Snom Firmware und dem Asterisk was das hervorruft. Zumindest hat mir jemand bei Snom gesagt das Sie dieses verhalten "beobachtet" hätten aber immer noch die Nadel im Heuhaufen suchen. Ich habe hier auch ein paar Telefone und wenn ich alle Leuten lasse gibs arg Probleme wie Ihr auch habt.

Das Problem ist bei mir schon lange siehe hier auch in diesem Thread.

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.

Gruss,

Jörg
 
Das Problem ist bei mir schon lange siehe hier auch in diesem Thread.
Uuups. Sorry, der Thread hier wird langsam unübersichtlich... Ich finde schon meine eigenen Beiträge nicht mehr.
Jedenfalls scheint das Verhalten bei uns ziemlich genau das von Dir beschriebene zu sein. Danke!
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.
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...
In Asterisk 1.6.0.6 habe ich zumindest nichts gefunden bezüglich snom-konformem dialog-info-xml.

Philipp

Update: Doch gefunden! In asterisk-1.6.2.0-beta1 scheint das doch tatsächlich endlich drin zu sein.
Freue ich schon auf (m)meinen Backport-Patch (falls das möglich ist...)!
Ist wohl SVN-Revision r154187 | seanbright | 2008-11-04 10:49:38 -0600 (Tue, 04 Nov 2008 ) bzw. Issue 0013827, siehe auch ChangeLog, channels/chan_sip.c, configs/sip.conf.sample (notifycid = yes).
...und in asterisk-1.6.1.0-rc3 und asterisk-1.6.0.7-rc2 doch tatsächlich nicht drin; also wohl nur im 1.6.2er-Pfad.
Nochmals Update: Verwendet ast_channel_search_locked() ohne while drum herum.
 
Zuletzt bearbeitet:
@pwalker: Ich hatte diesen "Stottern-Thread" auch im Hinterkopf, hätte ihn aber auch nicht gefunden.

Wenn nun zum wiederholten Male der channel_walk kritisch beäugt wird - ich wage hier nicht, ein Urteil zu fällen - was sind denn intelligentere Strategien? Denn in einem wie auch immer gearteten Alternativansatz muss man ja doch durch die Channels walken (argh - schlecht geschrieben).
 
Da wollte sich einer von den digium leuten drum kümmern. Ich weiss nich ob das im 1.6 asterisk verwirklicht wurde. Aber das würde man ja feststellen wenn mal jemand mit dem 1.6 spielt :)

P.S.: Philipp scheint sich ja der Sache mal anzunehmen. Ich habe dafür zzt. leider keine Zeit.

Gruss,

Jörg
 
Da wollte sich einer von den digium leuten drum kümmern.
Die Chancen für Backports solcher Änderungen nach 1.4 oder sogar 1.2 von den offiziellen Entwicklern sind wohl gering.
Ich weiss nich ob das im 1.6 asterisk verwirklicht wurde.
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.
Aber das würde man ja feststellen wenn mal jemand mit dem 1.6 spielt :)
Genau. Habe leider wirklich keinen 1.6er im Moment...
P.S.: Philipp scheint sich ja der Sache mal anzunehmen.
Im Moment höchstens für den (uralten) 1.2er...
Ich habe dafür zzt. leider keine Zeit.
Ich eigentlich auch nicht...
 
Hallo Gemeinde,

ich habe hier aktuell einen Test-PC herumstehen und werde mir das ganze mal ansehen, (foschi - ich bin Deinem Rat mal gefolgt und habe einen Patton angeschafft, somit darf ich mISDN eintüten :D)

Spricht eigentlich aktuell etwas GEGEN einen Einsatz der 1.6(.2)er Reihe in Bezug auf notify/snom-einsatz/etc?

LG Stefan
 
Hallo,

nach 7 Stunden habe ich es nun auch geschafft, die richtige Pickup Info auf den Display zu bringen. :)

Post #222 war sehr hilfreich, vielen Dank!

Viele Grüße,
Philipp
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.