• Eigenständig gehostete oder lokal installierte Instanzen sind komplexer in der Einrichtung und Fehlerbehebung und erfordern daher kostenpflichtigen technischen Support. Kostenlosen Support erhalten Sie mit 3CX StartUP oder einer gehosteten 3CX-Installation mit einen unterstützten SIP-Trunk-Anbieter.

Vodafone Anlagenanschluss R.4a sporadische Verbindungsprobleme

kaivonderchromit

Bronze Partner
Basic Certified
Mitglied seit
19. Juni 2019
Beiträge
23
Hallo,

ich habe bereits alle Beiträge in diesem Forum durchsucht, bei denen es um Vodafone ging, leider habe ich bisher keine Antwort auf meine Frage/Problemstellung gefunden und hoffe nun, dass hier jemand noch einen Tipp hat, wo ich weiter suchen kann.

Folgende Installation:
  • 3CX Ver. 16.0.273 Linux-Version auf XCP-ng-Server.
  • Als Provider haben wir die Vodafone mit einem Anlagenanschluss R.4a.
  • Zwischen uns und der Vodafone steht eine Fortigate Firewall 80C mit aktueller Firmware und nach Anleitung abgeschaltetem ALG/SIP-Helper.
  • Der Firewalltest der 3CX läuft ohne Beanstandung durch und zeigt am Ende alles grün.
  • Feste IP ist korrekt und von außer erreichbar
  • Inbound- wie Outbound Calls laufen in der Regel
  • Vodafone-Trunk ist mittels "transport-tcp.<customername>.ngn.vodafone.de" auf TCP geschaltet und konfiguriert.
  • PAI-Header ist wie der Vodafone-Support mir sagte auf die +49<Kopfrufnummer_mit_00>@ngn.vodafone.de gestellt, damit ich nicht am SBC der Vodafone abpralle
Jetzt kommt das Problem: Inbound wie Outbound laufen in der Regel, aber ohne erkennbaren Einfluss (Uhrzeit, Laufzeit etc.) hört alles, was über die Vodafone laufen soll, auf zu funktionieren, kein Call geht mehr raus oder rein. Nach irgendeinem anderen Ereignis (kein Neustart etc.) läuft alles wieder, als wäre nichts gewesen, alle Extensions sind wieder von außen erreichbar und können nach draußen telefonieren.

Internetverbindung steht die ganze Zeit, QOS-Rules muss die Firewall in der Zeit nicht mal bemühen, da der Anschluss hoffnungslos überdimensioniert ist. Gleiches gilt für den Virtualisierer, soviel Leistungsreserven haben wir bei unserer eigenen Anlage nicht und diese Arbeitet mit gleichem XCP-ng-Server, gleicher Firewall nur anderem (nicht unterstützten) Provider tadellos.

Leider hatte ich noch nicht das Glück, das Verhalten mit einem Wireshark-Capture zu erwischen, das einzige was ich sehe ist, dass im Log der 3CX folgender Eintrag erscheint:

"SIP Server/Call Manager ID: 12294
Call or Registration to +49xxxxxxxx@(Ln.10000@Vodafone) has failed. 0.0.0.0 replied: 408 Request Timeout; internal
06/18/2019 2:48:44 PM"

Interne Telefonie zwischen den Extensions ist in der Zeit des Ausfalls kein Problem, auch Abfrage von Voicemails etc, also schließe ich die 3CX selbst als Fehlerquelle aus. Leider kann mir der Vodafone-Support nur Eingeschränkt Hilfe leisten, da sie Zeit, A und B Teilnehmer mit min. drei Beispielen brauchen.

Daher meine Frage: Hat jemand von euch schon mal ähnliches Verhalten debuggen müssen? Wie war/wäre euer Vorgehen? Gibt es einen Weg aus der Fehlermeldung in den weiteren Logs die Nebenstelle, die den Call abgesetzt hat zu extrahieren?

Vielen Dank für jede Hilfe und Tipps.

Viele Grüße

Kai
 
Zuletzt bearbeitet von einem Moderator:
Hallo Kai,

schwierig. Läuft der Firewallchecker komplett durch?
 
Zuletzt bearbeitet von einem Moderator:
Hallo ilias,

wie ich schrieb, ja, der Firewallcheck in der 3CX zeigt keinerlei Fehler, alles leuchtet grün und ich kann ihn immer wieder laufen lassen und er kommt immer wieder zum selben Ergebnis, egal wann ich das tue.

Und ja, der Link, s.o. ist genau der von euch, nachdem ich alles eingerichtet habe. Nur als Ergänzung, habe ich den Transport (nach einem Beitrag hier im Forum) auf TCP gestellt, indem ich vor die Adresse "transport-tcp." gesetzt habe, da via UDP keine Verbindung mit der Vodafone zu Stande kommt.

Inzwischen habe ich auch Nachricht von Vodafone, angeblich kommt der INVITE nicht bis zu ihnen durch. Ich weiss allerdings nicht, was ich noch tun soll, denn den Moment alleine zu finden, in dem es einfach so komplett jede Funktion einstellt, ist schon schwer genug und wie debugge ich Infrastruktur der Provider die hinter meiner Firewall sind und die ich eben nicht sehen/tracen kann? Hattet ihr schon mal solchen Fall?

Vielen Dank und viele Grüße

Kai
 

Anhänge

  • oyc-alles grün.PNG
    oyc-alles grün.PNG
    19 KB · Aufrufe: 7
Das hört sich stark nach einem Vodafone Problem an. Bricht dann auch die Verbindung ab?
Vodafone hat auch ab- und zu mal Routing-Probleme (Business) in ihrem eigenen Netz. Hast Du den Vodafone Router oder was besseres gebaut? Besser ist den nur als Modem zu benutzen und etwas vernünftiges zu machen.
Was noch helfen kann ist die NAT ALG Option. Wenn Dein Router das nicht hat und Dir die Option nichts sagt, kann das schon ein Problem ergeben.
 
Hallo Macb,

danke für deine Antwort, ich habe keinen Vodafone-Router, sondern das Internet wird durch einen großen ortsansässigen Provider geliefert. Da unser "Zulieferer" wiederum komplett seit Jahren nur VoIP-Telefonie (zwar mit Asterisk) macht, aber sein Traffic die gleichen Firewalls und den gleichen Internet-Outtake im Rechenzentrum hier nutzt, gehe ich davon aus, dass das nicht das Problem ist.

Nach dem der Anschluss "aus der Wand" fällt, steht dann unser Fortigat 80C. Der ALG-Helper ist deaktiviert. Anbei noch ein Screenshot des eben durchgeführten Firewalls-Checks, dieser testet ja z.B. auch auf ALG.

Viele Grüße

Kai
 

Anhänge

  • OYC_Firewallchecker.png
    1 MB · Aufrufe: 4
Vermutung: Transport unter TCP bei VoIP widerspricht eigentlich dem Sinn und Zweck wie VoIP funktioniert. Wenn Du UDP nicht zum laufen bewegen kannst, wird irgendwas blocken, vielleicht in dem Fortigat 80C (setz mal den Host auf komplett erlauben - testweise). Ich kenne die Fortigat 80C nicht, aber das scheint eine 150 Euro "Firewall" Hardware Applikation zu sein?
Weil TCP ist für VoIP eher ungewöhnlich, und ich weiß nicht wie sich die 3CX da verhält.

Oder es wird etwas in einer davor liegenden Firewall geblockt.
Meiner Erfahrung nach (gilt nicht nur für 3CX) wenn es da nicht rund läuft, sind häufig irgendwelche (Firewall)-Filter-Regeln oder das Routing / Gatewayprobleme verantwortlich
Was außerhalb von Deinem Netz liegt kann man logischerweise nur sehr schwer diagnostizieren, das hängt dann von dem Support außerhalb ab.

Ob Ports sauber durchlaufen kannst Du mit NetIO ganz vernünftig testen, auch UDP. Nimm halt einen außerhalb der 3CX und lass das mal über Nacht laufen.

Gruß
Macb
 
Hi Macb,

Vermutung schön und gut, aber TCP ist das Einzige, was die Vodafone anbietet, findet sich in der Schnittstellenbeschreibung zum Anschluss (im Anhang mal anbei).

Firewall ist so konfiguriert wie von 3CX empfohlen und ist leider keine FrustBox oder T-Com-Plastikware, sondern eine echte Firewall (https://www.3cx.com/docs/fortigate-firewall-configuration/)

Der Support der Vodafone ist nicht in der Lage sporadische Fehler zu finden. Die erreicht man ja selber nicht am Telefon oder man hat Aussetzer - scheinen nicht grade Leuchten in Sachen VoIP zu sein...

Mein Problem: eigentlich geht alles, aber zu div. Tages- bzw. Nachzeiten kann der Anschluss nicht mehr raus bzw. rein telefonieren. In diesen Zeiten gibt es keine hohe Netzlast (außerdem haben wir QoS auf dem Switch - und auch hier haben wir einen echten Catalyst, kein Pastespielzeug). Wir reden hier von einer echten Installation für 80-100 Menschen und keiner kann Helfen - wir als Dienstleister bekommen natürlich den Frust ab - wo soll der Kunde auch anders damit hin...

Ich bin hier für jede Idee dankbar, aber Firewallchecker, Wireshark, etc, haben wir alles durch... Leider kann ich meinem Kunden nicht 5 Minuten nach dem Einzug empfehlen, mal eben den Vodafone-Anschluss zu kündigen und zu XYZ zu wechseln. Da Vodafone auf der 3CX-Seite mit eigener Anleitung steht, ging ich davon aus, das läuft - zu 90% tut es das jaauch, aber eben nur zu 90%....

Danke für alle Ideen und Hinweis, aber ich bin inzwischen echt verzweifelt...

Kai
 

Anhänge

  • IP_Anlagen-Anschluss_R4.a_Schnittstellenbeschreibung.pdf
    998,7 KB · Aufrufe: 11
Bei der Bestellung eines VF-IP-Anlagenanschlusses kann man als Transportprotokoll zwischen UDP und TCP wählen. Von VF war dort bei mir TCP vorbelegt; mit der Bemerkung "Standard: UDP".
Habe dann dort den Haken bei UDP gesetzt.
Seit der Einrichtung des Trunks (ohne transport-tcp Prefix), funktioniert der einwandfrei.
Ich würde bei VF die Umstellung auf UDP beauftragen und dann das Verhalten prüfen.

Btw. ist der Haken bei "Versand von INVITES an IP-Adresse des Registrars erzwingen" in den VF SIP-Trunk Optionen gesetzt (wegen INVITES kommen nicht an) ?
 
Hallo RVogt,

danke für den Hinweis, leider hatte ich genau das Stückchen Papier nicht in der Hand, da war der Agentur-Mensch wohl schneller als ich bzw. unser Kunde. Ich habe heute bei VF gefragt, ob eine Umstellung möglich ist, das geht jetzt in die Technische Abteilung, mal gucken, was die Kollegen sagen.

Der Haken bei "Force Invites to be sent to IP of Registrar " ist gesetzt. Das Verrückte ich ja auch, dass der Anschluss 85% der Zeit tadellos funktioniert, aber dann für 5-10 Minuten aussetzt und nichts mehr geht, ohne das dann jemand etwas tut, ist der Spuk wieder vorbei...

Vielen Dank und viele Grüße

Kai
 
Ohne intensives Monitoring (intern/extern) bleibt das ein fischen im Trüben.
Funktioniert das Routing/DNS zu diesem Zeitpunkt?
 
Hallo mbehrens,

ja, alle Routen raus wie rein sind in dem Moment verfügbar, genau so wie die DNS-Auflösung.

Morgen um 16:00 Uhr will die Vodafone das Transportprotokoll von TCP auf UDP ändern, ich bin gespannt, ob sich das Verhalten des Anschlusses ändert und werde berichten.

Vielen Dank und viele Grüße

Kai
 
Hallo Kai,

ich habe das gleiche Problem mit meinem Vodafone SIP-Trunk.
Hat die Änderung von tcp auf udp geholfen?

Viele Grüße
Heino
 
Hallo Heino,

ja, die Umstellung hat definitiv geholfen, hatte ganz vergessen zu schreiben. Bisher gibt es bei diesem Kunden keine Probleme mehr mit Vodafone.

Viele Grüße

Kai
 
  • Like
Reaktionen: heino
Hi Kai,

Danke dir für die Info!
 
Hallo Leute, bei mir das gleiche Problem, ich glaube Ihr rettet mir mit dem Hinweis Umstallung von TCP auf UDP gerade das leben.

By the way:
Ich konnte das Verhalten am Vodafone Anlagenanschluss einwandfrei nach Geschäftsschluss wie folgt reproduzieren:
- Nach dem letzten abgehenden externen Anruf 5 Minuten warten
- Externen Anruf versuchen --> dieser schlägt fehl
- Danach soft weiteren externen Anruf absetzen --> funktioniert
- Gegentest: alle externen Anrufe die innerhalb von 5 Min. nach dem letzten erfolgreichen Call
gemacht werden gehen bei ersten Mal ohne Probleme raus.

--> Es sieht für mich so aus, dass bei TCP der Trunk nach 5 Min. die Registrierung
verliert.Diese wird durch den ersten (erfolglosen) Anruf neu getriggert und reinitialisiert den Anruf

Frage an Kai:
Wie hast Du die Umstellung veranlasst. Über den Vodafone Vertrieb?
 
Hallo Twin2Turbo,

ich habe die technische Hotline aus dem Vertrag angerufen und dort den Techniker um Umstellung gebeten, wichtig war, dass du die PDTP-Nummer an der Hand hast, sonst finden die Jungs dich im System nicht. Ich meine es war die 0800 / 00 69300 aber bitte nicht erschießen, falls ich mich jetzt verguckt hab...

Viele Grüße und viel Erfolg

Kai
 

Statistik des Forums

Themen
22.254
Beiträge
112.176
Mitglieder
71.296
Neuestes Mitglied
Thomas12345
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 register cta
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.