[Problem] be.ip plus, seit 2 Jahren keine stabile IP Telefonie, Hilfe beim Analysieren?

[MaltiMartin]

Hi,
ich habe bei Freunden eine be.ip Plus, die seit Anbeginn (> 2 Jahre) nur Probleme mit der IP Telefonie macht. Teilweise abbrechende Gespräche, teilweise werden Anrufe nicht aufgebaut. Durch stetes wiederholen geht es dann irgendwann. Gegenkontrolle mit Handy schließt in der Regel den Gesprächspartner als Ursache aus.
Ich versuche das nun immer weiter einzugrenzen, und habe heute mal ein Sip Trace eines (versuchten) Anrufes aufgezeichnet, bei dem Abgehend kein Freizeichen und kein Gesprächspartner zu hören ist, es aber beim Angerufenen klingelt und er abnimmt...aber auch nix hört.
Das ganze war heute morgen mehrfach reproduzierbar.
Kann mir hier jemand helfen, dass Sip-Trace zu verstehen? Wenn ja, würde ich es hochladen.

Gruß,
Maritn

 

[sonyKatze]

1. Selbst wenn wir die Ursache finden würden, hast Du den Zugang/Berechtigung bei Bintec-Elmeg sowas wie Software-Bugs zu melden?
2. Welchen Telefonie-Anbieter nutzt Ihr?

 

[MaltiMartin]

1) Nein, aber ich tippe eher auf Probleme mit dem VDSL Anschluss oder das die Anlage nicht optimal konfiguriert ist.
2) Telekom im Deutschland LAN Tarif.

[Edit Novize: Beiträge zusammen gefasst - siehe Forumsregeln]

So, habe das Trace mal auf Google Drive abgelegt. Es sollte genau Anruf-Versuch abdecken, plus das Grundrauschen der anderen Geräte im Haus.
Öffentliche IP, Absender- und Empfänger-Telefonnummer habe ich partiell unkenntlich gemacht. Datei ist Plain-Text mit ca. 300kb.
Absendernummer endet auf xxx298, angerufene Nummer endet auf x222. Interne Anschlussnummer ist die 53.

SipTrace

Gruß,
Martin

 

[sonyKatze]

1. Könntest Du den Test-Aufbau nochmals ganz ohne das elmeg DECT150, ohne die elmeg IP630 und auch ohne das Grandstream HT704 machen? Also statt einem DECT-Mobilteil hinter der elmeg DECT150, ein elmeg IP630 oder noch besser nur ein analoges Telefon direkt an der be.IP plus nehmen?
2. Aus reiner Neugierde: Wozu dient der Grandstream überhaupt?
3. Welches DECT-Mobilteil (Hersteller/Modell/Firmware) startete den Anruf?
4. Im Log findet sich die Zeile: c=IN IP4 xxx.xxx.xxx.159. War das eine private IP-Adresse oder eine öffentliche?
5. Aus reiner Neugierde: Ist die be.IP plus auch der DSL-Modem/Router oder irgendwo im Heimnetz?
6. Vielleicht egal: Hast Du eine Idee, warum Deine elmeg DECT150 ausschließlich G.711 A-law (PCMA) anbietet?
7. Firmwarestände sehen soweit gut aus. Aber gibt es einen Grund, warum der Grandstream noch nicht aktuell ist?

 

[MaltiMartin]

1) Oh, das ganze ist "produktiv", da kann ich nix ändern im laufenden Betrieb. Eventuell kann man das ganze von einer analogen Nebenstelle reproduzieren, muss ich aber fragen. Würde es langen den Rest einfach abzuschalten oder muss die Konfig raus?
2) Der Grandstream dient zur Einbindung weiterer analoger Nebenstellen...historisch wollte man in jedem Zimmer ein Telefon haben, obwohl die Kids schon ausgezogen sind. Bin mir grad nicht sicher, ob da außer dem Schlafzimmer der Eltern noch was dranhängt
3) Ein Elmeg D131, aktuellste Firmware
4) Die öffentliche...daher unkenntlich gemacht. Die privaten im Netz sind alle sichtbar
5) Ja, die be.IP ist an der vordersten Front
6) Das war ein Lösungsansatz, den ich mal verfolgt habe...seitdem ich die Codecs auf G.711a u. DTMF beschränkt habe, gibt es gefühlt weniger Probleme (außer zu mir, wenn ich da anrufe hab ich mehr Probleme, könnte aber an meinem KDG Anschluss liegen, der will wohl immer G.722 aushandeln)
7) Ok, den hab ich nicht auf dem Schirm gehabt, da muss ich mal schauen. Das war Plug&Play vor 3 Jahren und seitdem nicht mehr eingeloggt da

 

[KunterBunter]

Das war Plug&Play vor 3 Jahren und seitdem nicht mehr eingeloggt da

Das Update gab es schon vor 3 Jahren.

 

[MaltiMartin]

Das Update ist durch...ganze Uptime von über 1000 Tagen verhagelt... ;-)

https://imgs.xkcd.com/comics/devotion_to_duty.png

Wahrscheinlich weil kein Firmware Update Server dringestanden hat...hab es angepasst und neu gebootet, jetzt ist 1.0.10.3 drauf.

 

[sonyKatze]

Würde es langen den Rest einfach abzuschalten?

Ja. Einfach kurz abschalten, Anruf machen, wieder anschalten.
Und am liebsten ein analoges Telefon direkt an der be.IP Plus. Wenn das nicht geht von einem Tisch-Telefon aus. DECT ist mir schon zu viel Voodoo.

Das war ein Lösungsansatz …

Ne, bitte nicht. Das wäre bereits ein Workaround. Du landest bei diesem Test-Anruf im IMS der Telekom Deutschland. Kann sein, dass das G.711 direkt bis auf das Mobiltelefon durchgereicht wird. Einige Netz-Betreiber haben die Mobiltelefon-Hersteller verdonnert auch G.711 anzubieten. Kann glatt sein, dass ein chinesischer Programmierer ein bisschen zu pragmatisch war und zwar so tut als ob G.711 A-law vorhanden ist – aber gar nicht da ist. Eine be.IP plus hat mit den standardmäßig eingestellten Audio-Codecs zu laufen. Wenn nicht, muss man schauen, warum nicht.

Puh. Aber ansonsten sieht für mich alles gut aus. Original Modelle. Aktuelle Firmware. Vielleicht hat @Kalle2006 noch eine Idee. Was für ein Tarif im „DeutschlandLAN IP“ ist das genau?

Wahrscheinlich weil kein Firmware Update Server dringestanden hat.

Bei Grandstream steht der falsche Server von Haus aus drin … ohne Worte.

 

[MaltiMartin]

Ich versuche die Leute zu erreichen und einen Test zu ermöglichen. Wenn ich den Telefonen die Lizenz entziehe, müsste ja "Ruhe auf der Leitung" sein?
Angerufene Nummer war aber auch Festnetz Telekom, so viel hab ich vergessen zu schreiben.
Tarif ist DeutschlandLAN IP Voice/Data S mit 2 zusätzlich gebuchten Sprachkanälen und der Option VDSL 100 IP
Ja das mit Grandstream will mir eine Lehre sein... ;-)

 

[sonyKatze]

Du bist nicht vor Ort, oder? Ich würde an Deiner Stelle nämlich einfach die Strom-Stecker oder die Ethernet-Anschlüsse der Geräte ziehen.

Festnetz Telekom

OK. Man weiß heute aber auch nicht mehr, ob nicht doch ein Sub-Netz oder was für ein Anschluss-Art (Glasfaser, MSAN-POTS, IP-basiert, …).

 

[MaltiMartin]

Nein, bin nicht Vorort, habe nur Remote Zugriff auf die Systeme.
Stecker ziehen wird die Leute spätestens bei der DECT 150 Basis bzw. dem Grandstream überfordern, sind beide Ü60 und reine Anwender...wenn ich denen sage, macht den Verteilerschrank auf ist Feierabend...

Und ja, klar, hast recht, was für eine Anschlussart bei der Gegenstelle zugrunde liegt kann ich nicht sagen...jetzt verstehe ich auch den Einwand besser...hab vorhin nur an Mobiltelefone gedacht...

So, Test erfolgt, Lizenz entziehen langt nicht, die sind immer noch sehr gesprächig im Sip Trace... :-(

Gut, die IP630 könnte ich vielleicht durch Abschalten der Ports im Switch kassieren, aber die DECT 150 und das Grandstream hängen direkt an der be.ip...wobei, hier müsste ich ja auch die Ports kassieren können? Moment mal...

Ja, die DECT150 und das Grandstream kann ich abstellen, beim Switch für die drei IP630 sieht es leider so aus als wäre der Netzwerkplan nicht aktuell...na Klasse (Update: Das habe ich nun auch rausgekriegt dank Mac Table im Switch...könnte also alles kappen bei Bedarf).

Eine Rückmeldung hab ich auch, kann den Test nicht wiederholen, ist/war eine Firma die ab jetzt geschlossen hat. Jetzt muss ich wieder random einen Anschluss finden der Probleme macht...leider ist das beim zweiten oder dritten Versuch nicht mehr reproduzierbar... :-(

Hast du bisher schon einen Verdacht oder war da zu viel Traffic im Trace?

Und noch ein kurzes Update: Man hat jetzt von dem einzigen analogen Telefon im Haus mehrere Anrufe getätigt (ca. 20). Und die haben alle funktioniert. Was bei einer normal gefühlten Fehlerquote von 50% schon enorm ist. Das analoge Telefon ist im Schlafzimmer und wird selten bis nie eingesetzt, daher ist das nie aufgefallen. Fast alle Gespräche laufen normal über DECT. Ein Anschlussinhaber, bei dem die Probleme mit 99% Sicherheit auftreten, ist erst Dienstag wieder zuhause. Dann können wir da nochmal testen.

 

[sonyKatze]

Hast du bisher schon einen Verdacht

Ehrlich gesagt: Nein. Außer eben diese Beschränkung auf G.711 A-law, ist mir nichts aufgefallen.
Man müsste tiefer reinschauen. Hören heißt RTP. Und RTP-Verkehr siehst Du so über dieses Log nicht. Die Frage ist, ob die be.IP plus überhaupt RTP rausschickt, ob RTP bis zur Firewall ankommt (Internet) – und was/ob dann was damit im Heimnetz (Intranet) passiert.

 

[MaltiMartin]

Also das Log auf Level Debug schreibe ich seit Tagen mit, wenn das hilft ;-)
Da könnte ich den passenden Teil rauskopieren.
Dachte nur hier braucht man das Sip Trace...

 

[sonyKatze]

Oft sieht man sowas im SIP, ja. Aber in Deinem Fall sieht SIP soweit gut aus. Jedenfalls ich sehe nichts. Man könnte noch einen Gutfall und Fehlerfall vergleichen. Vielleicht sieht man dann was.

Ich vermute den Fehler eher auf Ebene RTP. Dazu müsste man komplett alle Pakete mitschneiden, einmal vor dem WAN, einmal im LAN, jeweils, also gleichzeitig. Das geht bei einer FRITZ!Box und bei vielen Telekom Speedports vergleichsweise leicht. Bei Bintec-Elmeg kenne ich mich zu wenig aus, ob und wie das geht. So ein Komplett-Mitschnitt besonders vor dem WAN ist auch wichtig, weil wir vielleicht nicht alle SIP-Nachrichten sehen. Alles schon erlebt, dass eine Firewall bzw. ein SIP-ALG einzelne Nachrichten einfach verworfen und nicht weitergereicht hat.

 

[MaltiMartin]

Ja in die Richtung tippe ich auch (bzw. tippte ich auch bis ich durch lesen diverser Beiträge dachte im SIP Trace steht alles drin).
Den kompletten Mitschnitt habe ich, würde ich sagen...zumindest was NAT, Firewall und interner VOIP Handler der Anlage mitschneiden. Aber je länger ich darüber grüble, denke ich, dass man da wirklich wissen muss wie die Anlage tickt. Ich hab schon Gutfälle mit Fehlerfällen verglichen, ich sehe teilweise Unterschiede, aber da werden Status-Marker verwendet die mir nichts sagen und daher komme ich nicht weiter. :-(

 

[sonyKatze]

Bei RTP ist erstmal wichtig, dass es (1) überhaupt fließt, in (2) welche Richtungen es fließt und an (3) welche IP-Adresse bzw. (4) UDP-Port es fließt. Inhaltlich kannst Du in der App Wireshark dann über die eingebauten VoIP-Ergänzungen den Protokoll-Ablauf und sogar in das Gespräch hineinlauschen. Aber normalerweise macht bereits (1) bzw. (3) das Problem.

 

[Kalle2006]

Eine be.IP plus hat mit den standardmäßig eingestellten Audio-Codecs zu laufen. Wenn nicht, muss man schauen, warum nicht.

Falsch, denn die Standard - Codec-Reihenfolge sorgt oft für Probleme.

 

[weißnix_]

Der komplette Paketmitschnitt geht recht einfach. Lokale Dienste -Trace.
Bevor ich mir aber diesen Datenwust antue, versuche ich immer erstmal parallel zum Sip-Trace das Log auf Debug-Level nebeneinanderzulegen. Geht ganz gut in npp. Dann bekommt man erstmal Hinweise, ob in der entsprechenden Zeiteinheit NAT oder Firewall irgendwas gedroppt haben.