Gespräche brechen ab [Solution in Progress]

[anonymous]

Hallo,

eingehende Gespräche brechen nach wenigen sekunden ab ...

38.713 [CM503008]: Call(67): Call is terminated
18:57:38.710 [CM503021]: Call(67): ACK is not received
18:57:19.900 Currently active calls - 1: [67]
18:57:16.727 [CM503007]: Call(67): Device joined: sip:[email protected]:5060
18:57:16.722 [CM505001]: Ext.13: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [Sipura/SPA921-4.1.10(b)] PBX contact: [sip:[email protected]:5060]
18:57:16.721 [CM503002]: Call(67): Alerting sip:[email protected]:5060
18:57:16.704 [CM503003]: Call(68): Call to sip:[email protected] has failed; Cause: 487 Request Cancelled; from IP:192.168.0.45:5060
18:57:16.697 [CM503008]: Call(69): Call is terminated
18:57:16.566 [CM503025]: Call(67): Calling @[Dev:sip:[email protected]:5060]
18:57:16.560 [CM503008]: Call(68): Call is terminated
18:57:16.555 [CM505003]: Provider:[SipGate Team (Trunk) - DE,International] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:[email protected]:5061]
18:57:16.354 [CM503007]: Call(69): Device joined: sip:[email protected]:5060
18:57:16.351 [CM503007]: Call(69): Device joined: sip:[email protected]:5488
18:57:16.347 [CM505001]: Ext.13: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [Sipura/SPA921-4.1.10(b)] PBX contact: [sip:[email protected]:5060]
18:57:16.347 [CM503002]: Call(69): Alerting sip:[email protected]:5060
18:57:07.363 [CM503025]: Call(69): Calling Ext:Ext.13@[Dev:sip:[email protected]:5060]
18:57:07.357 [CM503025]: Call(68): Calling Ext:Ext.12@[Dev:sip:[email protected]:5060;user=phone;transport=udp]
18:57:07.318 [CM503004]: Call(69): Route 1: Ext:Ext.13@[Dev:sip:[email protected]:5060]
18:57:07.318 [CM503010]: Making route(s) to
18:57:07.318 [CM503004]: Call(68): Route 1: Ext:Ext.12@[Dev:sip:[email protected]:5060;user=phone;transport=udp]
18:57:07.317 [CM503010]: Making route(s) to
18:57:07.314 [CM505001]: Ext.80: Device info: Device Identified: [Man: 3CX Ltd.;Mod: 3CX Queue;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX Queue Manager (q=80)] PBX contact: [sip:[email protected]:5060]
18:57:07.312 [CM503001]: Call(69): Incoming call from Ext.80 to
18:57:07.305 [CM505001]: Ext.80: Device info: Device Identified: [Man: 3CX Ltd.;Mod: 3CX Queue;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX Queue Manager (q=80)] PBX contact: [sip:[email protected]:5060]
18:57:07.303 [CM503001]: Call(68): Incoming call from Ext.80 to
18:57:06.593 [CM503007]: Call(67): Device joined: sip:[email protected]:5488
18:57:06.591 [CM503007]: Call(67): Device joined: sip:[email protected]:5060
18:57:06.585 [CM505001]: Ext.80: Device info: Device Identified: [Man: 3CX Ltd.;Mod: 3CX Queue;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX Queue Manager (q=80)] PBX contact: [sip:[email protected]:5060]
18:57:06.584 [CM503002]: Call(67): Alerting sip:[email protected]:5488
18:57:06.409 [CM503025]: Call(67): Calling Ext:Ext.80@[Dev:sip:[email protected]:5488]
18:57:06.339 [CM503004]: Call(67): Route 1: Ext:Ext.80@[Dev:sip:[email protected]:5488]
18:57:06.338 [CM503010]: Making route(s) to
18:57:06.336 [CM505003]: Provider:[SipGate Team (Trunk) - DE,International] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:[email protected]:5061]
18:57:06.333 [CM503001]: Call(67): Incoming call from 07382936680@(Ln.10000@SipGate Team (Trunk) - DE,International) to
18:57:06.282 [CM503012]: Inbound any hours rule (+4973822839790) for 10000 forwards to DN:80
18:56:47.349 [CM504004]: Registration succeeded for: 10000@SipGate Team (Trunk) - DE,International

 

[groundhog]

Hat die Sprachübertagung vor Abbruch begonnen? Bidirektional?

 

[stefanw]

ACK is not received

Firewall ist entweder nicht konfiguriert oder hat SIP ALG
http: //www.3cx.de/blog/firewall-konfiguration-phonesystem/

 

[anonymous]

Hi,

ausgehende Gespräche sind möglich, eingehende auch, die eingehenden brechen nach wenigen sekunden ab, nach 31 sec.

ausgehende Gespräche brechen nicht ab.

 

[stefanw]

ja, firewall weill bei eingehenden der Provider dir das ACK schicken muss, bei ausgehenden du das ACK schickst. Da die meisten firewall im Outbound nichts fildern geht da nichts daneben.

Dann noch hast du eine Feste IP oder DynDNS?
SP4 installiert?
Was ist der Provider?
Was ist die Firewall?

 

[anonymous]

ja, Sp4 habe ich eben installiert. ...

verwendet wird vorrübergehend ein Speedport w 504 von der blödelcom... ( mein Taschenrechner hat mehr einstellmöglichkeiten)

Provider ist Sipgate Trunk.



welcher Port soll das fürs ACK sein ?

 

[anonymous]

der telekomrouter gehört eingeäschert...

ich habe das problem glaube ich gefunden, auf jedenfall telefoniere ich seit 3 minuten mit mir selber ;O

 

[matictec]

könntest du uns das eventuelle problem nennen?

 

[groundhog]

Würde mich auch interessieren. War es der Router?

 

[anonymous]

Habe zwar nicht das exakt gleiche Problem, aber nach 5 - 15 Minuten sind die Gespräche weg - wäre schön, wenn man hier den ein oder anderen Tipp posten könnte

 

[anonymous]

Guten Morgen,

um das zu erklären muss ich wohl ein wenig aushohlen

unser Netzwerk ist wie folgt aufgebaut

1: Cisco Router 192.168.10.1
2: Firewall 192.168.10.2 zu 192.168.0.1
3: Switsch und co

die lokalen Geräte laufen alle auf 192.168.0.x
nun wurde der Cisco router mit einem "privatkundenprodukt" der Telekom getauscht, da der Ciso keine DSL lahm Technik unterstützt.

der Telekom router ist allerdings dumm genug das man bei der Portöffnun nicht einfach die IP Adresse des Gerätes eingeben kann, worauf er das weiterleiten soll, sondern nur eine Mac Adresse, die IP Adresse sucht sich der Router dann selsbt aus.

Da der Telefeonserver allerdings auf der 0.x läuft, und der Router auf der 10.x hat mit der die regel auf 10.11 statt 0.11 erstellt.

das habe ich leider viel zu spät gesehen,denn daran lag das Problem...

Ich habe das Problem wie folgt gelöst

3cx Server Netwerkkarte 1 auf 192.168.10.11
und die 2te Netzwerkkarte auf 192.168.0.11 geschalten

die 1ste Karte geht direkt an den Telekomrouter,

die 2te Netzwerkkarte ist ganz normal mit dem Netzwerk verbunden, wobei ich diesem keinen Gateway und DNS vergeben habe, damit er keine Verbindung mit dem Internet aufbaut.

Diese Lösung war zwahr etwas umständlich scheint aber zu laufen...

um das in einem wort zu nennen, die Firewall war falsch eingestellt ;O

 

[anonymous]

Hallo

Wir haben eine 3Cx-Zentrale seit mehreren Jahren im Einsatz - seit ein paar Wochen sogar mit Lizenz.
Seit der Installation von SP4 (+ empfohlenen IIS7 Sicherheitseinstellungen) hatten wir jetzt schon 2 Mal das Problem dass die Gespräche nach genau 30 Sekunden beendet werden.
Laut 3cx-Logfile beendet die Zentrale die Gespräche weil sie kein ACK-Signal bekommen hat (von wem - anrufer oder angerufener - ist mir noch unklar)
Fakt ist, dass es passiert egal ob man intern oder extern, ein- oder ausgehend telefoniert. Auch egal ist ob man Snom, Linksys, Cisco oder Snom Softphone verwendet.
Zu sagen ist: 3cx läuft auf einem Server im Datacenter mit öffentlicher IP und die Telefone sind auf mehrere Büro's mit DSL-Routern und NAT verteilt. Die Telefone hatten bisher NAT und STUN aktiviert und damit lief es so mehr oder weniger stabil

Ehrlich gesagt: es war irgendwie brauchbar, aber im Vergleich zu traditionellem Festnetz- oder Mobiltelefon ein absolutes Disaster! ...naja was tut man sich nicht alles an komplizierter und fehleranfälliger Technologie an, nur um zwei/drei Büros an einer gemeinsamen Zentrale betreuen zu können)
Trotzdem, wir wollten nichts unversucht lassen, und da wir TCP/IP-technisch in unserer Firma ja nicht gerade auf den Kopf gefallen sind, haben wir schnell mal ein OpenVPN-netz aufgesetzt, das dann auch gleich mal anstandslos funktioniert hat. Unsere Telefone verbinden sich jetzt über eine private IP ohne NAT und STUN direkt zum 3Cx-Server. Man kann vom Server oder einem Büro aus auch direkt auf die Telefon in anderen Büros zugreifen. (also bitte keine Lösungsversuche in Richtung NAT/Firewall und Port freischalten/weiterleiten)
Unser Eindruck ist, dass Anrufe bzw. generell die Reaktion wesentlich schneller abläuft (obwohl das SNMP-Monitoring sowohl der bisherigen ADSL-Router wie auch der jetzt dazugekommenen VPN-Tunnel immer den gleich geringen Voip-Traffic pro Anruf anzeigen)

f**k FAKT ist aber leider, dass nach ca. 1,5 Tagen die wir jetzt im Glauben waren mit der VPN all diese ständigen Nervigkeiten mit den VOIP-Telefonen gelöst zu haben, schon wieder Gespräche alle 30 Sekunden von der 3cx-zentrale unterbrochen haben, weil diese sich (plötzlich!) irgendwo her irgend ein "ACK" erwartet, obwohl das Gespräch mit Aufbau und Ton in beiden Richtungen ja einwandfrei laufen würde!
Daran geändert hat weder das entfernen der IIS-Sicherheitseinstellungen, ein Neustart vvon 3cx und IIS sowie des gesamten Servers und aller beteiligten VOIP-Telefone.

Mein nächster Post wir vermutlich eine Verkaufsanzeige für diverse Voip-Telefone samt 3cx-Lizenz sein (natürlich sind alle Geräte auf der derzeit mit am wenigsten Fehlern gefüllten Firmware geflasht!)

 

[anonymous]

Noch ein paar Anmerkungen nachdem gestern der ganze Abend und heute schon der halbe Vormittag mit Unproduktivität verschwendet wurde:
1. kann mal jemand für ein vernünfitg brauch- und lesbares "Server Aktivitäten Protokoll" sorgen?
Schaut zwar nett aus wenn man eine Zeile blau markieren kann, richtig "admin-friendly" wärs aber natürlich wenn man den Text auch ganz einfach markieren und kopieren könnte- z.B. um danach zu googeln. (heureka!)
Und weil ich grad dabei bin: Wär's keine gute Idee wenn man in dem Durcheinander an Logeinträgen von versch. Nebenstellen und Anrufen einfach einen Text-Filter setzen könnte, zB. um alle Einträge mit einer bestimmten CM-id zu zeigen?
2.) Ich hab jetzt mehrfach in Blog und Forum gelesen, dass es viele Gründe geben kann warum ein ACK nicht ankommt. Meine Meinung: Das ist mir als Kunde absolut und relativ egal - wenn ich eine Lösung kaufe und nutzen will, dann erwarte ich gelinde gesagt etwas mehr als Bemerkungen der Art "Es gibt mehr als 200 verschiedene Arten von Kopfschmerzen". Kann mir jemand z.B. mal ganz einfach sagen wer wem sich so ein ACK auf welchem Port (welchen Ports) austauschen sollte? Mit so einer Info könnte ich mich mindestens selber auf die Fehlersuche machen und bestimmte Dinge ausschließen.

Aber vielleicht sollte ich auch nur dafür sorgen, dass Voip-Telefone und -Server eine gemeinsame Erdung oder noch besser vielleicht sogar direkten Sichtkontakt haben. Vielleicht läuft das dann ja besser...

 

[stefanw]

ACK = SIP = UDP und 5060
Aber was kann 3CX darüf wenn die Firewal ACKs nicht zustellt?
Es gibt noch den Fall das der SIP Contact Header nach einem IP wechsel nicht geupdatet worden ist.
Aber das Zeigt nur Wireshark und kein anderes log, da wir die NIC uns ansehen müssen...

Und die vollen logs gibt es auch, das in der 3CX ist nur für einen Anruf gedacht aber nicht eine Analyse.
CrogramData3CataLogs

 

[anonymous]

Hallo
ok, dann werden wir mal versuchen SIP(5060) zu testen und überwachen.
Firewall haben wir eben keinen mehr zwischen den Telefonen und dem 3cx-server, da alles über eine VPN geroutet wird.

VOIPTel VPNRouter ADSLRouter Internet FirewallDatacenter VPNServer 3cxServer

VOIPTel = 10.9.3.149/16
VPNRouter = 10.9.3.1/16
VPNServer = 10.10.54.159/16
3cxServer = 10.10.0.53 (mit statischer Router für 10.9.x.y nach 10.10.54.159)
Außerdem hat der 3cxServer noch eine öffentliche IP um sich mit SIP-Providern zu verbinden.
von dort eingehende Anrufe an die Clients funktionieren länger als 30 Sekunden. Jeder von einer Nebenstelle ausgehende Anruf - egal ob an andere Nebenstelle oder externe Rufnummer - wird von der Zentrale nach 30 Sekunden mangels ACK beendet.

Ping von/zum VoipClient wie auch -server läuft einwandfrei.
Anmeldung an der Zentrale ebenfalls, genauso wie der Aufbau und die ersten 30 Sekunden eines Gesprächs.

Der 3cx-Server erstellt ebi der Installation ja selbst seine Windows-Firewall-Regeln, ich gehe also davon aus, dass diese für einen reibungslosen Betrieb ausreichend sind.

Die Frage ist also, warum kann laut unseren Tests und unserem Verständnis wirklich ALLES zwischen den Clients und dem Server komplett frei übertragen werden, nur dieses ACK-nowledgement nicht?
Und weiter: Ist es nur Zufall, dass dies erst nach der Installation von SP4 auftritt?
Warum hat es nach Implementierung der VPN gut 1,5 Tage lang einwandfrei funktioniert und dann auf einmal nicht mehr?

Um zum Anfang dieses Posts zurückzukommen: "ACK = SIP = UDP und 5060" ... UDP und 5060 sowie SIP scheint zu funktionieren, nur ACK nicht. Ich weiß momentan wirklich nicht ob ich so etwas als sonderbar oder ärgerlich bezeichnen soll.

Könnt ihr nicht den ganzen SIP-Krempel über den Haufen werfen und was so rock-solides wie ein Skype-Protokol verwenden? Das telefoniert auf manchen Computern sogar noch wen der nichtmal eine Webseite aufbekommt, weil kein DNS konfiguriert ist.

 

[groundhog]

Hast Du schon folgendes Prozedere versucht?

1. Sicherung aus 3CX heraus
2. 3CX de-installieren
3. Server (die ganze Hardware-Kiste) neu starten
4. 3CX mit allen SP's neu installieren
5. Sicherung zurückspielen
6. Server (die ganze Hardware-Kiste) neu starten

Das mache ich bei jedem Update so und habe damit viele Probleme vermieden, die bei anderen aufgetreten sind.
Ich weiss das es keine Universallösung ist aber bei unerklärlich auftretenden Problemen ist es einen Versuch wert, finde ich.

 

[anonymous]

...letzte Notiz: nach gut 23 Stunden mit lauter 30-sekündigen Gesprächen mit unseren Kunden und allen nur erdenklichen Tests läuft es jetzt genauso unerklärlich wieder wie es gestern Abend begonnen hat. Wir warten also auf den nächsten zufälligen Zeitpunkt un den kommenden Tagen wo wieder irgendwas keine Lust auf ACK mehr hat.

 

[anonymous]

Bin für jeden Tipp dankbar. Heute heist es mal die ganze vergeudete Zeit der letzten zwei Tage aufzuholen. Wenn's nochmal klemmt werd ich Deinen Tipp befolgen.

 

[anonymous]

Hallo,

da dieser Thread ganz gut passt, dachte ich mir ich wiederbelebe ihn am besten, anstelle einen neuen auf zu machen.
Wir haben auch das Problem, das Gespräche spuradisch nach 4-5 Minuten abbrechen. Wir gehen über einen Patton SmartNode 4554 raus. Im Eventlog steht ist leider nichts ersichtlich, es steht einfach da, Call is terminated...

Wir nutzen Snom 370 mit der aktuellen Firmware. Jemand einen Rat?