Seite 1 von 2 12 LetzteLetzte
Zeige Ergebnis 1 bis 15 von 20

Thema: Probleme wärend Betrieb (Anlage verliert Verbindung zu Telefonen)

  1. #1
    STARFACE User

    Registriert seit
    04.03.2016
    Beiträge
    69

    Standard Probleme wärend Betrieb (Anlage verliert Verbindung zu Telefonen)

    Hallo Zusammen,
    ich habe z.Z ein Problem mit einer kürzlich installierten Starface Advanced.
    Hier kurz die Eckdaten zum Aufbau:

    Starface Advanced PBX
    44 User
    45 Yealink 46G Telefone
    2 Dect-Basen Gigaset
    1 Patton Smart Node 4118

    Die Starface läuft in einem eigens konfiguriertem Vlan, die Telefone hängen an
    zwei 48-Port-POE-Switchen von HP. Die verbindung ins Haupnetz (für UCC-Client-Installationen) erfolgt über eine Patchverbindung
    zum Firmennetz-Switch. Die Starface hat einen Proxy und einen internen Exchange als Mailserver eingetragen.

    Nun zum Problem:
    In unregelmäßigen Abständen verliert die Anlage komplett die Verbindung zu allen Telefonen
    -->Anmelden an der Weboberfläche ist möglich, Telefonie (intern und extern) nicht.
    Laut Aussage des Kunden hat Sie sich auch schon einmal komplett neu gestartet.
    In den Logs finde ich nichts, was mich weiterbringt..
    Irgendwelche Ideen?
    Vielen Dank für die unterstützung!

  2. #2
    STARFACE Expert
    Benutzerbild von fwolf
    Registriert seit
    28.12.2011
    Ort
    72622 Nürtingen
    Beiträge
    2.331

    Standard

    Da kommt leider sehr sehr viel in Betracht...

    Was mir in Projekten schon begegnet ist:
    - Rogue DHCP-Server im Netz, wodurch sich der primäre Windows DHCP-Dienst beendet. Nach Ablauf der Lease-Time sind alle Endgeräte offline. STARFACE ist meist statisch konfiguriert und erreichbar.
    - IP-Adress-Konflikt: Statisch konfiguriertes Gerät mit IP-Adresse der STARFACE kam in unregelmäßigen Abständen ins Netz (im konkreten Fall war es ein Mobiltelefon, welches per WLAN angebunden war) und sorgte dafür, dass in den Switches die IP der STARFACE auf die MAC des Mobiltelefons umgebogen wurde. Die STARFACE war so für die Endgeräte nur noch eingeschränkt erreichbar – je nachdem, über welchen Switch man mit der STARFACE verbunden wurde.
    - Schleifen im Netz: Kunde baut am Telefon mit Netzwerkkabeln eine Schleife, woraufhin das STP auf den Switches die Kommunikation einschränkt oder der Switch ohne STP durch Broadcast-Stürme abgeschossen wird.
    - Defekte GBICs/SFPs für die Uplinks

    Mehr fällt mir auf die Schnelle nicht ein... passiert das häufiger, so dass man mal einen Trace machen kann?
    Grüße,
    Fabian

    STARFACE Excellence Partnerwww.fluxpunkt.deinfo@fluxpunkt.de

    Informationen über Fluxpunkt Module für STARFACE
    Produktupdates, Neuigkeiten & sonstiges gezwitscher: Fluxpunkt bei Twitter

  3. #3
    STARFACE User

    Registriert seit
    04.03.2016
    Beiträge
    69

    Standard

    Zitat Zitat von fwolf Beitrag anzeigen
    - Rogue DHCP-Server im Netz, wodurch sich der primäre Windows DHCP-Dienst beendet. Nach Ablauf der Lease-Time sind alle Endgeräte offline. STARFACE ist meist statisch konfiguriert und erreichbar.
    - IP-Adress-Konflikt: Statisch konfiguriertes Gerät mit IP-Adresse der STARFACE kam in unregelmäßigen Abständen ins Netz (im konkreten Fall war es ein Mobiltelefon, welches per WLAN angebunden war) und sorgte dafür, dass in den Switches die IP der
    Die Telefone haben alle feste IP-Adressen bekommen. Ein Wlan gibt es nicht, und da die Zugänge zu den beiden Switchen nicht einfach frei sind, glaube ich auch eher nicht daran, dass es ein IP-Adress-konflikt ist.
    Ich bin heute noch einmal vor ort, vll. kann ich noch mehr Informationen sammeln.
    Nach dem Ausfall heute vormittag habe ich nun auch keine Verbindung mehr zum Mailserver (Exchange im Firmennetz), im Staface-Mail-Log erscheint die Meldung "Unable to relay"
    Vll. ist das ganze ja ein Problem mit der Starface, bzw. mit dem eingetragenen DNS in der Anlage?
    Der Exchange arbeitet ohne Authentifizierung, und wenn er die Anlage nicht ordentlich auflösen kann, verweigert er die Mailannahme (theoretisch)..

  4. #4
    STARFACE Expert
    Benutzerbild von fwolf
    Registriert seit
    28.12.2011
    Ort
    72622 Nürtingen
    Beiträge
    2.331

    Standard

    Wenn die Telefone statische IP-Adressen haben und es keinen DHCP-Server gibt, klingt das nach einer möglichen Ursache.
    Die STARFACE verändert zwar die "network.*"-Parameter im Yealink nicht, aber durch ein Zurücksetzen des Geräts ist dort wieder DHCP eingestellt.

    Gibt es einen Grund, warum für über 40 Telefone kein DHCP-Server bereitgestellt wird? Das ist doch ein administrativer Albtraum – vor allem, beim Zurücksetzen der Endgeräte, z.B. bei einem Firmware-Update.

    Die Meldung "Unable to relay" ist übrigens meist eine Exchange-Meldung bzw. eine Nachricht des Mail-Relays. In diesem Fall funktioniert die Verbindung zum Exchange, aber der Exchange kann die Email nicht weiterleiten.
    Grüße,
    Fabian

    STARFACE Excellence Partnerwww.fluxpunkt.deinfo@fluxpunkt.de

    Informationen über Fluxpunkt Module für STARFACE
    Produktupdates, Neuigkeiten & sonstiges gezwitscher: Fluxpunkt bei Twitter

  5. #5
    STARFACE User

    Registriert seit
    04.03.2016
    Beiträge
    69

    Standard

    Naja, es war so gewünscht, dass die Telefone klar durch IP-Adressen zuzuordnen sind.
    Ich denke darüber ließe sich aber nun auch reden.
    Es gibt einen DHCP, der umfasst aber lediglich 20 Adressen und war zb. für den Patton notwendig.
    Gäbe es eine schnelle, elegante Möglichkeit alle Yealinks auf DHCP zu setzten (Wenn der Bereich vergrößert wurde)
    ohne bei jedem auf die Webconfig zu gehen?

  6. #6
    STARFACE User

    Registriert seit
    04.03.2016
    Beiträge
    69

    Standard

    Und wie ist das überhaupt wenn ich im nachhinein auf DHCP umstelle?
    Werden die Telefone nocheinmal komplett neu benannt?
    Muss ich jedes Telefon nocheinmal neu provisionieren und dem entsprechenden User zuweisen?

  7. #7
    STARFACE Expert
    Benutzerbild von fwolf
    Registriert seit
    28.12.2011
    Ort
    72622 Nürtingen
    Beiträge
    2.331

    Standard

    Die Telefone können auf Werkseinstellungen zurückgesetzt werden (langes Drücken der OK-Taste mit anschließender Bestätigung).
    Die Geräte müssen dabei nicht neu benannt oder neu zugewiesen werden. Die STARFACE stört sich nicht daran, dass sich IP-Adressen der Endgeräte ändern – über die MAC-Adresse lassen sich diese eindeutig zuordnen.
    Grüße,
    Fabian

    STARFACE Excellence Partnerwww.fluxpunkt.deinfo@fluxpunkt.de

    Informationen über Fluxpunkt Module für STARFACE
    Produktupdates, Neuigkeiten & sonstiges gezwitscher: Fluxpunkt bei Twitter

  8. #8
    STARFACE User

    Registriert seit
    04.03.2016
    Beiträge
    69

    Standard

    Guten Morgen,
    leider haben sich die Probleme mit der Anlage noch nicht verbessert, im Gegenteil.
    Jeden Morgen (und manchmal auch noch einmal am Nachmittag) verliert die Anlage die Verbindung zu allen Telefonen,
    keine internen und externen Gespräche sind mehr möglich.
    Ich habe dazu am 27.07. einen Supportticket bei Starface eröffnet. Leider war alles, was bis jetzt von dort kam,
    die Meldung: Der Astersisk hängt sich komplett auf.
    Wieso, weshalb, warum weiß ich nicht.
    Ich habe schon auf eigene Faust die Logs durchsucht, aber etwas außergewöhnliches ist mir bislang nicht aufgefallen.
    Hat vielleicht jemand hier im Forum noch eine Idee?
    Support-Überlastung wegen neuer Version hin oder her, ich finde trotzdem man sollte einem Supportticket dieser Art (Neue Anlage, >50 User, regelmäßiger Totalausfall)
    Priorität geben..

    Edit:
    Die Telefone können auf Werkseinstellungen zurückgesetzt werden (langes Drücken der OK-Taste mit anschließender Bestätigung).
    Die Geräte müssen dabei nicht neu benannt oder neu zugewiesen werden. Die STARFACE stört sich nicht daran, dass sich IP-Adressen der Endgeräte ändern – über die MAC-Adresse lassen sich diese eindeutig zuordnen.
    Ich habe ein paar Telefone auf DHCP umgestellt, diese sind aber genauso "ausgesteiegen" wie die anderen
    Geändert von Co77 (02.08.2016 um 07:19 Uhr)

  9. #9
    STARFACE Expert
    Benutzerbild von nucom
    Registriert seit
    11.12.2012
    Ort
    9443 Widnau
    Beiträge
    1.830

    Standard

    Hallo m.coch

    Wir hatten auch Probleme mit einer Anlage, welche sich in Regelmässigen Abständen aufgehängt hat.

    Wir haben ein Backup der SF gezogen, die SF ab Stick neu-installieret, Backup wieder eingespielt, und wir hatten unseren Frieden.

    MfG

    Fabian
    Modulhersteller aus der Schweiz
    __________________________________________________ ________
    STARFACE Excellence Partner: Info | Certified Module Creator Kontakt

  10. #10
    STARFACE User

    Registriert seit
    04.03.2016
    Beiträge
    69

    Standard

    Hey Fabian,
    danke für deine Antwort.
    Gabs bei euch irgendeine Meldung seitens des Supports?
    Die Anlage komplett neu aufsetzten mit Backup einspielen ist natürlich auch ein Aufwand,
    den keiner zahlt und der auch in diesem Fall rein zeitlich schwer umzusetzten ist.
    War das bei euch eine Appliance oder VM?
    Gruß

  11. #11
    STARFACE Expert
    Benutzerbild von fwolf
    Registriert seit
    28.12.2011
    Ort
    72622 Nürtingen
    Beiträge
    2.331

    Standard

    Auszüge aus den Logs, die den "Ausstieg" zeigen, wären hilfreich. Insbesondere:
    Code:
    /var/log/asterisk/full
    /var/log/messages
    Grüße,
    Fabian

    STARFACE Excellence Partnerwww.fluxpunkt.deinfo@fluxpunkt.de

    Informationen über Fluxpunkt Module für STARFACE
    Produktupdates, Neuigkeiten & sonstiges gezwitscher: Fluxpunkt bei Twitter

  12. #12
    STARFACE User

    Registriert seit
    04.03.2016
    Beiträge
    69

    Standard

    Klar, kein Problem.
    Die logs sind von gestern, am Morgen ist uns aufgefallen dass der Asterisk wieder hängt.
    Wie lange er schon gehangen ist, kann ich nicht sagen, da am Wochenende kein Betrieb ist.
    Wir mussten die Anlage dann gegeb 08:40 Uhr über den Reset-Knopf neustarten, da selbst die Dienste- und Neustart-Funktion hing
    (Bei dem Fenster, wo normalerweise angezeigt wird, wie viel im Augenblick telefoniert wird)

    var/log/asterisk/full:
    Code:
    [Aug  1 08:00:35] VERBOSE[2379] asterisk.c:     -- Remote UNIX connection
    [Aug  1 08:00:35] VERBOSE[8386] asterisk.c:     -- Remote UNIX connection disconnected
    [Aug  1 08:00:46] VERBOSE[8383][C-00000010] pbx.c:   == Spawn extension (dialstart, 45, 1) exited non-zero on 'SIP/1017.ylnkt46-00000010'
    [Aug  1 08:00:46] VERBOSE[8383][C-00000010] pbx.c:     -- Executing [h@dialstart:1] NoOp("SIP/1017.ylnkt46-00000010", "HC 0") in new stack
    [Aug  1 08:00:46] VERBOSE[8383][C-00000010] pbx.c:     -- Executing [h@dialstart:2] Goto("SIP/1017.ylnkt46-00000010", "_exit_,0") in new stack
    [Aug  1 08:00:46] VERBOSE[8383][C-00000010] pbx.c:     -- Goto (dialstart,_exit_,0)
    [Aug  1 08:00:54] VERBOSE[2691][C-00000011] netsock2.c:   == Using SIP RTP TOS bits 184
    [Aug  1 08:00:54] VERBOSE[2691][C-00000011] netsock2.c:   == Using SIP RTP CoS mark 5
    [Aug  1 08:00:54] VERBOSE[8393][C-00000011] pbx.c:     -- Executing [001703206177@dialstart:1] AGI("SIP/1017.ylnkt46-00000011", "agi:async,,,,") in new stack
    [Aug  1 08:00:54] VERBOSE[8393][C-00000011] pbx.c:   == Spawn extension (dialstart, 001703206177, 1) exited non-zero on 'SIP/1017.ylnkt46-00000011'
    [Aug  1 08:00:54] VERBOSE[8393][C-00000011] pbx.c:     -- Executing [h@dialstart:1] NoOp("SIP/1017.ylnkt46-00000011", "HC 0") in new stack
    [Aug  1 08:00:54] VERBOSE[8393][C-00000011] pbx.c:     -- Executing [h@dialstart:2] Goto("SIP/1017.ylnkt46-00000011", "_exit_,0") in new stack
    [Aug  1 08:00:54] VERBOSE[8393][C-00000011] pbx.c:     -- Goto (dialstart,_exit_,0)
    [Aug  1 08:01:06] VERBOSE[2691][C-00000012] netsock2.c:   == Using SIP RTP TOS bits 184
    [Aug  1 08:01:06] VERBOSE[2691][C-00000012] netsock2.c:   == Using SIP RTP CoS mark 5
    [Aug  1 08:01:06] VERBOSE[8425][C-00000012] pbx.c:     -- Executing [01703206177@dialstart:1] AGI("SIP/1017.ylnkt46-00000012", "agi:async,,,,") in new stack
    [Aug  1 08:01:09] VERBOSE[8425][C-00000012] pbx.c:   == Spawn extension (dialstart, 01703206177, 1) exited non-zero on 'SIP/1017.ylnkt46-00000012'
    [Aug  1 08:01:09] VERBOSE[8425][C-00000012] pbx.c:     -- Executing [h@dialstart:1] NoOp("SIP/1017.ylnkt46-00000012", "HC 0") in new stack
    [Aug  1 08:01:09] VERBOSE[8425][C-00000012] pbx.c:     -- Executing [h@dialstart:2] Goto("SIP/1017.ylnkt46-00000012", "_exit_,0") in new stack
    [Aug  1 08:01:09] VERBOSE[8425][C-00000012] pbx.c:     -- Goto (dialstart,_exit_,0)
    [Aug  1 08:01:18] WARNING[2691] chan_sip.c: Retransmission timeout reached on transmission 3972787305@10.183.62.154 for seqno 2 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
    Packet timed out after 32000ms with no response
    [Aug  1 08:01:26] WARNING[2691] chan_sip.c: Retransmission timeout reached on transmission 1833659465@10.183.62.154 for seqno 2 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
    Packet timed out after 32000ms with no response
    [Aug  1 08:01:35] VERBOSE[2379] asterisk.c:     -- Remote UNIX connection
    [Aug  1 08:01:35] VERBOSE[8435] asterisk.c:     -- Remote UNIX connection disconnected
    [Aug  1 08:01:36] VERBOSE[2691][C-00000013] netsock2.c:   == Using SIP RTP TOS bits 184
    [Aug  1 08:01:36] VERBOSE[2691][C-00000013] netsock2.c:   == Using SIP RTP CoS mark 5
    [Aug  1 08:01:36] VERBOSE[8437][C-00000013] pbx.c:     -- Executing [e1749@dialstart:1] AGI("SIP/1039.ylnkt46-00000013", "agi:async,,,,") in new stack
    [Aug  1 08:01:41] WARNING[2691] chan_sip.c: Retransmission timeout reached on transmission 2422294294@10.183.62.154 for seqno 2 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
    Packet timed out after 32000ms with no response
    [Aug  1 08:02:08] VERBOSE[8437][C-00000013] pbx.c:   == Spawn extension (dialstart, e1749, 1) exited non-zero on 'SIP/1039.ylnkt46-00000013'
    [Aug  1 08:02:08] VERBOSE[8437][C-00000013] pbx.c:     -- Executing [h@dialstart:1] NoOp("SIP/1039.ylnkt46-00000013", "HC 0") in new stack
    [Aug  1 08:02:08] VERBOSE[8437][C-00000013] pbx.c:     -- Executing [h@dialstart:2] Goto("SIP/1039.ylnkt46-00000013", "_exit_,0") in new stack
    [Aug  1 08:02:08] VERBOSE[8437][C-00000013] pbx.c:     -- Goto (dialstart,_exit_,0)
    [Aug  1 08:02:35] VERBOSE[2379] asterisk.c:     -- Remote UNIX connection
    [Aug  1 08:02:35] VERBOSE[8460] asterisk.c:     -- Remote UNIX connection disconnected
    [Aug  1 08:02:40] WARNING[2691] chan_sip.c: Retransmission timeout reached on transmission 322934119@10.183.62.168 for seqno 2 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
    Packet timed out after 32001ms with no response
    [Aug  1 08:03:35] VERBOSE[2379] asterisk.c:     -- Remote UNIX connection
    [Aug  1 08:03:35] VERBOSE[8484] asterisk.c:     -- Remote UNIX connection disconnected
    [Aug  1 08:04:35] VERBOSE[2379] asterisk.c:     -- Remote UNIX connection
    [Aug  1 08:04:35] VERBOSE[8508] asterisk.c:     -- Remote UNIX connection disconnected
    [Aug  1 08:05:35] VERBOSE[2379] asterisk.c:     -- Remote UNIX connection
    [Aug  1 08:05:35] VERBOSE[8537] asterisk.c:     -- Remote UNIX connection disconnected
    [Aug  1 08:06:35] VERBOSE[2379] asterisk.c:     -- Remote UNIX connection
    [Aug  1 08:06:35] VERBOSE[8561] asterisk.c:     -- Remote UNIX connection disconnected
    [Aug  1 08:07:35] VERBOSE[2379] asterisk.c:     -- Remote UNIX connection
    [Aug  1 08:07:35] VERBOSE[8587] asterisk.c:     -- Remote UNIX connection disconnected
    [Aug  1 08:08:36] VERBOSE[2379] asterisk.c:     -- Remote UNIX connection
    [Aug  1 08:08:36] VERBOSE[8616] asterisk.c:     -- Remote UNIX connection disconnected
    Var/log/messages:
    Code:
    Aug  1 00:08:17 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 00:24:19 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 00:40:22 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 00:56:25 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 01:12:28 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 01:28:31 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 01:44:33 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 02:00:36 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 02:16:38 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 02:32:41 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 02:48:44 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 03:04:47 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 03:20:50 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 03:36:52 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 03:52:55 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 04:08:58 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 04:25:00 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 04:41:03 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 04:57:06 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 05:13:09 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 05:29:11 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 05:45:14 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 06:01:17 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 06:17:20 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 06:33:22 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 06:49:25 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 07:05:27 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 07:21:30 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 07:37:33 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 07:53:36 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 08:09:39 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 08:25:41 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Aug  1 08:41:44 localhost ntpd_intres[3204]: host name not found EAI_NODATA: 2.de.pool.ntp.org
    Der NTP_Server ist mittlwerweile angepasst worden.
    Danke schon mal,
    Gruß
    Geändert von Co77 (02.08.2016 um 08:36 Uhr)

  13. #13
    STARFACE Expert
    Benutzerbild von nucom
    Registriert seit
    11.12.2012
    Ort
    9443 Widnau
    Beiträge
    1.830

    Standard

    Hallo m.coch

    Zitat Zitat von m.coch Beitrag anzeigen
    Hey Fabian,
    danke für deine Antwort.
    Gabs bei euch irgendeine Meldung seitens des Supports?
    Gruß
    Das Support Ticket wurde geschlossen, da wir ja das Problem selbst behoben haben.

    Die Anlage komplett neu aufsetzten mit Backup einspielen ist natürlich auch ein Aufwand,
    den keiner zahlt und der auch in diesem Fall rein zeitlich schwer umzusetzen ist.
    Natürlich ist dahinter ein grösserer Aufwand, jedoch war unser Endkunde bereits uns dies zu Zahlen, in unserem Fall Provisionierten sich die Telefone fast stündlich neu, also war um einiges schlimmer.
    Wir haben es deshalb auch Untertags durchgeführt, damit der Normalbetrieb so schnell wie möglich wieder einkehren konnte.

    War das bei euch eine Appliance oder VM?
    Es war eine Compact Appliance.

    MfG

    Fabian
    Modulhersteller aus der Schweiz
    __________________________________________________ ________
    STARFACE Excellence Partner: Info | Certified Module Creator Kontakt

  14. #14
    STARFACE Expert
    Benutzerbild von fwolf
    Registriert seit
    28.12.2011
    Ort
    72622 Nürtingen
    Beiträge
    2.331

    Standard

    Der Ausschnitt von 08:00 Uhr bis 08:08 Uhr zeigt keinen hängenden Asterisk.
    Auffällig sind jedoch die Retransmission-Timeouts, die meist ein Indiz für Netzwerkprobleme sind.
    Grüße,
    Fabian

    STARFACE Excellence Partnerwww.fluxpunkt.deinfo@fluxpunkt.de

    Informationen über Fluxpunkt Module für STARFACE
    Produktupdates, Neuigkeiten & sonstiges gezwitscher: Fluxpunkt bei Twitter

  15. #15
    STARFACE User

    Registriert seit
    04.03.2016
    Beiträge
    69

    Standard

    Zitat Zitat von fwolf Beitrag anzeigen
    Der Ausschnitt von 08:00 Uhr bis 08:08 Uhr zeigt keinen hängenden Asterisk.
    Auffällig sind jedoch die Retransmission-Timeouts, die meist ein Indiz für Netzwerkprobleme sind.
    Okay. Die logs der beiden POE-Switche habe ich schon überprüft, die laufen durch.

    Zum Verständnis: Dieser Abschnitt beschreibt doch ein "Gesprächsversuch", der nicht zustande kommt, oder?

    Code:
    [Aug  1 08:00:54] VERBOSE[2691][C-00000011] netsock2.c:   == Using SIP RTP TOS bits 184
    [Aug  1 08:00:54] VERBOSE[2691][C-00000011] netsock2.c:   == Using SIP RTP CoS mark 5
    [Aug  1 08:00:54] VERBOSE[8393][C-00000011] pbx.c:     -- Executing [001703206177@dialstart:1] AGI("SIP/1017.ylnkt46-00000011", "agi:async,,,,") in new stack
    [Aug  1 08:00:54] VERBOSE[8393][C-00000011] pbx.c:   == Spawn extension (dialstart, 001703206177, 1) exited non-zero on 'SIP/1017.ylnkt46-00000011'
    [Aug  1 08:00:54] VERBOSE[8393][C-00000011] pbx.c:     -- Executing [h@dialstart:1] NoOp("SIP/1017.ylnkt46-00000011", "HC 0") in new stack
    [Aug  1 08:00:54] VERBOSE[8393][C-00000011] pbx.c:     -- Executing [h@dialstart:2] Goto("SIP/1017.ylnkt46-00000011", "_exit_,0") in new stack
    [Aug  1 08:00:54] VERBOSE[8393][C-00000011] pbx.c:     -- Goto (dialstart,_exit_,0)

Ähnliche Themen

  1. Voicemail verliert regelmäßig Ansage
    Von cursondax im Forum STARFACE Einrichtung & Administration
    Antworten: 7
    Letzter Beitrag: 03.06.2016, 18:28
  2. UCC verliert ständig die Verbindung
    Von ffischer im Forum STARFACE Benutzerfrontend
    Antworten: 9
    Letzter Beitrag: 03.08.2015, 12:59
  3. Antworten: 4
    Letzter Beitrag: 31.07.2015, 13:15
  4. Gigaset DE700 IP Pro verliert Einstellungen
    Von Ahnungsloser im Forum Hersteller Informationen & Hardware Kompatibilität
    Antworten: 1
    Letzter Beitrag: 01.04.2015, 20:17
  5. Antworten: 1
    Letzter Beitrag: 16.04.2010, 15:11

Lesezeichen

Forumregeln

  • Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
  • Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
  • Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
  • Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.
  •