Suchergebnisse

Heute und auch in den vergangenen Tagen waren Verbindungen sehr leise. Über andere Provider nicht. Kann das jemand bestätigen?

Webseite lädt nicht, Registrierung klappt nicht: -- Registration for '[email protected]' timed out, trying again (Attempt #11) Internet ist ok, auch sipgate erreichbar: PING sipgate.de (217.10.79.9) 56(84) bytes of data. 64 bytes from sipgate.de (217.10.79.9): icmp_req=1 ttl=55...

Du hast im Kontext "eingehend" keine extension 42 konfiguriert. Dort gehört hin: [eingehend] exten => 42,1,Dial(SIP/42)

Das Problem ist, dass Asterisk ja alle paar Sekunden sip Pakete verschickt. Daher werden die NAT Einträge nie gelöscht, auch nicht, wenn der Rechner längst eine neue IP bekommen hat, denn es wird immer die falsche source IP genattet. Da hilft nur, die sip einträge aus der conntrack-Tabelle zu...

Liegt am NAT Ihr müsst die entsprechenden Einträge aus der NAT Tabelle löschen, am besten beim Abbauen der PPP Vebindung: conntrack -F löscht die ganze NAT Tabelle, ihr könnt aber auch gezielt die SIP-Einträge löschen.

Erledigt Geht seit 14:08 Uhr schon wieder, danke.

[Jul 6 14:00:02] NOTICE[22796]: chan_sip.c:11500 sip_reg_timeout: -- Registration for '[email protected]' timed out, trying again (Attempt #18) Standort: Berlin-Schöneberg Für Anforderung hohe Verfügbarkeit leider noch immer unbrauchbar. Ohne ISDN-Fallback no way. Schade.

Geht wieder Ich hoffe, solche Ausfälle kommen nicht noch öfter.

Langsam wird sipgate als Telefondienstleister entschieden zu unzuverlässig. [Apr 8 11:03:09] NOTICE[3591]: chan_sip.c:11502 sip_reg_timeout: -- Registration for '*********@sipgate.de' timed out, trying again (Attempt #81) Liegt nicht an der Internetverbindung. PING sipgate.de...

Ja, hier auch Auch das Einloggen per SIP geht nicht...

Berlin auch.

Deadlock in V2 Ich habe mal wieder einen Deadlock entdeckt. 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...

Vielleicht liegt es an der alten Firmware, das könnte sein. 8.2.5 bietet aber protocolversion 9 an und 8.3.5 12. An dem Phone hängt ein 7914 Wenn dann ein Anruf hereinkommt und man hebt ab, resettet das Phone sofort. mit protocolversion=6 gibt es kein Problem. Es gab sogar einen...

Problem mit 7971 und protocolversion 9 Mit protocolversion 9 oder 12 kommen die 7971er nicht klar: Danach resetten die Phones sofort.

Hmm, eigentlich darf die ISDN-Anlage die führende 0 gar nicht weitergeben. Nimm mal an, die ISDN-Anlage hinge direkt am T-Com Netz. Dann dürfte auch keine zusätzliche Null mitgeschickt werden. Ich habe eine Siemens Hipath am Asterisk, und die kann man so konfigurieren, dass sie keine...

Wow, hier hat sich ja eine Menge getan! Ich hatte leider wenig Zeit, und unser System läuft ja auch super (Uptime > 3 Monate), nämlich Asterisk 1.4.17-bristuffed mit chan-sccp-b SVN rev. 302. Nun musste ich was an der SCCP-Konfig ändern, und bei der Gelegenheit habe ich mal die aktuelle...

Im Prinzip geht das schon, mit Hilfe der Asterisk Datenbank, z.B. so: Bedienung: Man wählt *Rufnummer, um die Umleitung einzuschalten und ** um sie auszuschalten. [rufumleitung] ;Rufumleitung an exten => _*.,1,NoOp(Rufumleitung ein) exten => _*.,n,Answer exten =>...

Bei uns läuft das so: 2x Beronet BN4S0 (4 Ports NT an Hipath 3000, 4 Ports TE an Amt) Asterisk 1.4 mit Bristuff Läuft seit etwa einem Jahr problemlos.

So, habe mich mal getraut, 1.4.21 mit svn-trunk (302) zu testen. Aber auch da tritt das Problem auf, dass Channels im Down State hängenbleiben, wie bei jedem Asterisk nach 1.4.18: -- ATA1D452C83B801: >> Got message SoftKeyEventMessage -- ATA1D452C83B801: Got Softkey: EndCall (9)...

Siehe auch: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448171