chan-sccp-b release für asterisk 1.2 und 1.4

Hi,
okay, danke für die Info :)

Nur leider sind v2 und v3 dennoch von diesem 7920<->7940/60 Problem betroffen und es passieren regelmäßig Abstürze. Leider gibt es ja keine Alternative. Es sei denn, man würde eine noch ältere chan_sccp-Version aufspielen :)

mfg,
CTU
 
Hi!

Das Problem dürfte das 7920 sein!

Es wirft sich nach Ablauf der keep-alive-time selber raus, registriert sich jedoch sofort wieder.
Dieser Vorgang hat leider auch Auswirkungen auf die restlichen Geräte (in meinem Fall ein 7940G), welches ebenfalls raus fliegt, sich jedoch nicht so schnell wieder neu anmeldet :-(
 
Hallo Netview,
ich glaube wir sprechen von 2 unterschiedlichen Problematiken.
Denn zum einen müssten - wenn deine These mit dem 7920 stimmt - auch die anderen Cisco-Modelle, also 7961/7970 usw. Probleme machen, was nicht der Fall ist. Zum anderen, gibt es bei mir nicht während der Registrierung Probleme, sondern beim Gesprächsaufbau zwischen einem 7920 und einem 7940/60.

mfg,
CTU
 
Hallo,
ja, absolut, auch v2 ! Ich kann mal schauen, ob ich einen Abschnitt aus der Konsole rauskriege, wenn der Fehler auftritt. Aber eins ist klar: Wenn ich in den letzten Tagen nach einem Asterisk-Aufhänger in die Konsole geschaut habe, war immer ein 7920-7940 bzw. 7920-7960-Gespräch der letzte Eintrag und "sccp show channels"
mfg,
CTU
 
Deadlock in V2

Ich habe mal wieder einen Deadlock entdeckt.

Code:
Thread 8 (process 30375):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7ee6c99 in __lll_lock_wait () from /lib/i686/cmov/libpthread.so.0
#2  0xb7ee20d3 in _L_lock_291 () from /lib/i686/cmov/libpthread.so.0
#3  0xb7ee1b36 in pthread_mutex_lock () from /lib/i686/cmov/libpthread.so.0
#4  0x0807d838 in ast_queue_frame (chan=0x83388d0, fin=0xb6d840ec) at /tmp/buildd/asterisk-1.4.21.2~dfsg/include/asterisk/lock.h:755
#5  0x0808050a in ast_queue_hangup (chan=0x83388d0) at channel.c:958
#6  0xb6d9dd43 in sccp_channel_endcall (c=0x83481b8) at sccp_channel.c:773
#7  0xb6da5550 in sccp_line_kill (l=0x8258328) at sccp_line.c:39
#8  0xb6db40a8 in sccp_socket_thread (ignore=0x0) at sccp_socket.c:134
#9  0x080e3ac7 in dummy_start (data=0x823a3d8) at utils.c:895
#10 0xb7ee04c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
#11 0xb7df36de in clone () from /lib/i686/cmov/libc.so.6

Hier soll der Channel 0x83388d0 beendet werden. Das Problem dabei ist nur:

Code:
Thread 5 (process 14049):
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7ee6c99 in __lll_lock_wait () from /lib/i686/cmov/libpthread.so.0
#2  0xb7ee20d3 in _L_lock_291 () from /lib/i686/cmov/libpthread.so.0
#3  0xb7ee1b36 in pthread_mutex_lock () from /lib/i686/cmov/libpthread.so.0
#4  0xb6d9c61b in sccp_channel_get_active_wo (d=0x81d1cd8, locked=0) at /usr/include/asterisk/lock.h:755
#5  0xb6dac6ac in ?? () from /usr/lib/asterisk/modules/chan_sccp.so
#6  0x0807fded in ast_hangup (chan=0x83388d0) at channel.c:1502
#7  0xb6b36116 in hanguptree (outgoing=0x82b7018, exception=0x0) at app_dial.c:336
#8  0xb6b377ca in dial_exec_full (chan=0x83381e0, data=0xb5cfc998, peerflags=0xb5cfa914, continue_exec=0x0) at app_dial.c:1754
#9  0xb6b3c05e in dial_exec (chan=0x83381e0, data=0xb5cfc998) at app_dial.c:1776
#10 0x080b8c7b in pbx_exec (c=0x83381e0, app=0x81b8c58, data=0xb5cfc998) at pbx.c:537
#11 0x080b9992 in pbx_extension_helper (c=0x83381e0, con=<value optimized out>, context=0x8338360 "droste-incoming", exten=0x83383b0 "23", priority=10, label=0x0,
    callerid=0x8339e60 "", action=E_SPAWN) at pbx.c:1862
#12 0x080bab15 in __ast_pbx_run (c=0x83381e0) at pbx.c:2419
#13 0x080bb588 in ast_pbx_run (c=0x83381e0) at pbx.c:2677
#14 0xb70d9dd6 in ss_thread (data=0x83381e0) at chan_zap.c:5682
#15 0x080e3ac7 in dummy_start (data=0x8309430) at utils.c:895
#16 0xb7ee04c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
#17 0xb7df36de in clone () from /lib/i686/cmov/libc.so.6

Hier soll offenbar der selbe Channel auch beendet werden, nur mit ast_hangup statt mit ast_queue_hangup. Dafür wird hier sccp_channel_get_active_wo aufgerufen:

Code:
sccp_channel_t * sccp_channel_get_active_wo(sccp_device_t * d, int locked)
{
        sccp_channel_t * c = NULL;

        if (!d)
                return NULL;

        sccp_device_lock(d);

        sccp_log(10)(VERBOSE_PREFIX_3 "%s: Getting the active channel on device.\n", DEV_ID_LOG(d));

        if((c = d->active_channel)) {
                if(c->state != SCCP_CHANNELSTATE_ZOMBIE && c->state != SCCP_CHANNELSTATE_DOWN) {
                        if(locked)
                                sccp_channel_lock(c);
                } else {
                        sccp_device_unlock(d);
                        return NULL;
                }
        }

        sccp_device_unlock(d);

        return c;
}

Man sieht, dass der fragliche Channel in der Funktion tatsächlich gelockt wird.

Ach ja, Asterisk 1.4.21 (debian), SCCP channel Release: v2 - 785M
 
Hallo,
wurde in der aktuellen Version eigentlich schon das Konferenz Feature implantiert?

Mit besten Grüßen

Streetfighter12
 
Hi, nachdem ich die Cisco-Geräte mit SIP und Asterisk getestet habe, steht jetzt der Gegentest mit Skinny und Asterisk an ;)

Habe mir die aktuelle chan_sccp geladen,kompiliert und eingebaut. Ging auch wunderbar.

Dann habe ich eine minimale sccp.conf erstellt:

Code:
[general]
keepalive = 30

context = general
dateFormat = D.M.YA
bindaddr = 192.168.52.50
port = 2000
debug = 0

[7971]
devicetype = 7971

[SEP001ABCDEFGH0](7971)
description = 7971
autologin = 29100
button = line, 29100


[lines]
id=29100
pin = 12345
label = 29100
context = default
description =Cisco 7971
line => 29100

Das Telefon meldet sich auch problemlos am Asterisk an, aber es holt sich keine Line.
Code:
Current settings for selected Device
------------------------------------

MAC-Address           : SEP001ABCDEFGH0
Protocol Version      : Supported '17', In Use '17'
Keepalive             : 30
Registration state    : Ok(3)
State                 : OnHook(0)
MWI handset light     : OFF
Description           : Cisco 7971
Config Phone Type     : 7971
Skinny Phone Type     : Cisco7971(119)
Softkey support       : Yes
Autologin             : 
Image Version         : 
Timezone Offset       : 0
Capabilities          : 0x10c (ulaw|alaw|g729)
Codecs preference     : ()
Can DND               : Reject
Can Transfer          : Yes
Can Park              : Yes
Private softkey       : Enabled
Can CFWDALL           : No
Can CFWBUSY           : No
Can CFWNOANSWER       : No
Dtmf mode             : In-Band
Nat                   : No
Direct RTP            : No
Trust phone ip        : No
Early RTP             : No
IP ToS RTP audio      : EF
IP ToS RTP video      : AF41
Device State (Acc.)   : OnHook
Last Used Accessory   : Speaker
Wenn man den Hörer abnimmt, kriegt man im CLI entsprechend:
Code:
sccp_actions.c:1001 sccp_handle_onhook: No lines registered on SEP001C58F0B3B0 to put OnHook


Was fehlt denn in der Konfiguration noch, um die Line zu kriegen?
Dachte das wäre mit dem autologin und dem button getan.
 
Ok, Anfängerfehler....asterisk hatte gar keine Leserechte für die sccp.conf.

Die hab ich ihm jetzt gegeben und die nach dem Beispiel auf der sourceforge-seite angepasst:

Code:
[general]
context = general
dateFormat = D/M/YA
bindaddr = 192.168.52.50
port = 2000
debug = 10


[SEP00ABCDEFGHI0]
type = device
devicetype = 7971
description = 7971
button = line, 29100
keepalive = 60
permit = 192.168.52.0/255.255.255.0

[29100]
type = line
id=29100
label = 29100
context = default
description =Cisco 7971
line => 29100
mailbox = 10000
mussicclass=MOH

Jetzt sehe ich im CLI die Anmeldeversuche, aber Asterisk weist das Telefon zurück mit:
Code:
SCCP: Device 'SEP00ABCDEFGHI0' not found in realtime table 'sccpdevice'
    -- SSEP00ABCDEFGHI0: Rejecting device: not found

Sucht sccp standardmäßig in einer DB nach den Geräten?
 
Und eine Falscheingabe der MAC-Adresse konntest du auschließen, nehe ich mal an oder?
Bzw. das Neustarten des Channels/Asterisk, nachdem du die Änderung in der sccp.conf vorgenommen hast?

mfg,
CTU
 
Mac-Adresse habe ich mehrmals verglichen und zum Schluß auch mit c&p aus der Fehlermeldung in die sccp.conf übernommen.

Habe sowohl das Modul chan_sccp neu geladen, als auch den kompletten asterisk neu gestartet, aber keine Änderung zu sehen.
 
hallo kw_

mach mal bitte keine leerzeichen bei den button, das müssen wir noch fixen. Also Am besten:
Code:
button = line,29100

welche version verwendest du eigentlich, die tar.gz von der webseite oder den trunk aus dem svn?
 
Hi,

das Leerzeichen entfernt, Asterisk neu gestartet = keine Änderung :(

Installiert habe ich das tar.gz von sourceforge. Also die Version 20090602 und Asterisk ist 1.4.21.2 aus den Debian-Repos.
 
Ah ok.

Wie krieg ich die alte am besten gelöscht? Einfach das chan_sccp.so löschen, oder sind noch weitere Dateien vorhanden?
 
ist nur die chan_sccp.so in dem modules ordner von asterisk
Wird aber auch überschrieben wenn du jetzt die neue version verwendest
 
Danke, mit der neuen Version geht's.
Dann kann ich jetzt rumtesten und gucken, ob uns das "günstige" Update auf CM8 erspart bleibt ;)
 
wenn dir was auffällt sag bescheid.
 
Gerne.
Eine Frage hätte ich noch:
Wie krieg ich das Extension Modoul an's laufen?
Reicht da einfach das "addon = 7914" in der sccp.conf oder muss ich auch die SEPMAC.cnf.xml anpassen?

EDIT:
Also in der SEPMAC.cnf.xml habe ich jetzt noch das eingefügt:

Code:
<addOnModules>

<addOnModule  uuid="{4cf8aef7-0a5e-0151-f77e-4908a069c5c8}" idx="1">

<loadInformation>B015-1-0-3</loadInformation>

<phoneTemplateId>a8f5d006-acc0-e095-f812-776579cfb1dc</phoneTemplateId>

</addOnModule>

</addOnModules>
Damit funktioniert das Extension Modul ;)
Aber woher bekomme ich denn ohne CM den Wert für die uuid?

Zur Erklärung: Jetzt habe ich das Telefon+Modul mit dem CCM konfiguriert, mir vom CCM-TFTP die XML-Config gezogen und die IP auf den Asterisk geändert.
Aber für einen richtigen Wechsel ist das natürlich nicht machbar, da man dort das Extension Modul ja auch ohne den CCM konfigurieren können muss.

Und das letzte kleine Problemchen: Ich kann immer nur über die Line auf dem ersten Button telefonieren. Wenn ich eine andere Line auswähle, kriege ich zwar ein Freizeichen aber die Wählkommandos werden nicht angenommen.
 
Zuletzt bearbeitet:
die uuid ist egal, wird nicht benötigt.

Zu Deinem line Problem, stimmt denn der context?
 
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.