sipgate: nur bei Festnetzanrufen kann ich den Angerufenen nicht hören

[Kabelkiller]

Hallo, Ihr da draußen,

folgendes diffuses Problem:

Ich telefoniere seit Neuestem über SIPGate mit DECT-Telefonen, die an einer Fritzbox Fon 7170 angeschlossen ist, die selbst wiederum hinter einem Router hängt (Ubiquity Bullet5).

Der Router macht DSL, NAT, DHCP usw., die Fritzbox fungiert als WLAN-AP und als DECT/SIPGate-Gateway und hat eine feste eingestellte IP-Adresse. Ihre Firmware ist die Aktuellste.

Die Telefonierei funktioniert bis auf folgendes Problem zu meiner Zufriedenheit:

Wenn (über SIPGate) Festnetznummern angerufen werden, kann ich den Angerufenen nicht hören und vorher auch kein Rufzeichen.
Es klingelt aber beim ihm und wenn er abhebt, kann er mich hören.
Die SIPGate-Webseite protokolliert einen ordnungsgemäßen Anruf.

Das ist ja ein oft gehörtes Problem und wird meist mit Hinweisen zum Portforwarding beantwortet.
Aaaber:
Ich kann problemlos zu Mobulfunknetzen telefonieren und auch problemlos aus dem Festnetz angerufen werden - nur bei Anrufen ZUM Festnetz habe ich oben beschriebenes Problem.

Obwohl ich nicht glaube, dass es damit zu tun hat, habe ich auch schon diverse Ports auf dem Router zur Fritzbox geforwardet, wie erwartet ohne Erfolg. (siehe Anhang)
Den sipgate-STUN-Server stun.sipgate.net:10000 habe ich auf der Fritzbox eingetragen und ich habe auch ohne bzw. mit anderen STUN-Servereinträgen probiert - ohne Erfolg.

Dieselbe Problemkonstellation tritt übrigens auch mit der SIPGate-VOIP-Software X-Light auf, also auch da geht alles bis auf die Anrufe ins Festnetz.

Mein Frage ist nun:
Wieso tritt das Problem nur bei ausgehenden Anrufen zum Festnetz hin auf, nicht jedoch bei Mobilfunk eingehend/ausgehend und auch nicht bei Festnetz eingehend ?

Würde mich freuen, wenn jemand eine Idee hätte - der SIPGate-Anschluß ist nämlich der Nachfolger meines gekündigten und abgeschalteten Festnetzanschlusses und so allmählich würde ich gerne wieder aufs Festnetz anrufen können ...

(Ich habe übrigens, um solchen Fragen vorzubeugen, vor dem Kündigen SIPGate mit der Fritzbox getestet und alles hat prima funktioniert, allerdings war damals die Fritzbox auch noch DSL-Router am damaligen DSL-Zugang...)

(Auf Hotlinecalls bei AVM und SIPGate haben ich bisher noch keine Antwort erhalten.)

 

[Brötchen]

Hi, dein Thema widerspricht sich mit dem Inhalt:

"sipgate: nur bei Festnetzanrufen kann mich der Angerufene nicht hören"

und

"Wenn (über SIPGate) Festnetznummern angerufen werden, kann ich den Angerufenen nicht hören und vorher auch kein Rufzeichen. Es klingelt aber beim ihm und wenn er abhebt, kann er mich hören."

Warum es sich so verhält, kann ich auf Anhieb leider nicht sagen. Aber es wird in der Tat eine Port/STUN-Geschichte sein. Das kannst du auch ganz leicht gegenprüfen, wenn du die Fritz!Box wieder an die Front hängst!

Von der Signalisierung also den Inhalten der SIP-Pakete sollte es keine abweichenden Einträge geben - bis auf die Codec-Abhandlung. Vom Prinzip sollte erst der Gateway beim Festnetzbetreiber den Unterschied erkennen.

Das Ergebnis würde mich auch mal interessieren...
Ich tippe ja auf Zusammenspiel mit Portfreigabe/STUN-Server und Gateway!

 

[gandalf94305]

Wenn Festnetz- und Mobilfunkanrufe beide über sipgate.de abgewickelt werden, jedoch bei der einen Sorte eine Hälfte der Sprachübertragung fehlt, die andere Sorte dagegen ok ist, liegt das Problem eindeutig bei sipgate.de, da dort die Terminierung über ggf. verschiedene Partner erfolgt.

Eine Portproblematik würde ich ausschließen, daß dies nicht mit Traffic einer bestimmten Sorte zu tun hat, sondern innerhalb eines Protokolls mit zwei Ausprägungen von Zielrufnummern. Das spiegelt sich nicht in Ports wieder.

Es könnte mit Codecs bzw. Transcoding oder dem Fehlen davon zusammenhängen, daher würde ich einen Netzwerktrace empfehlen, um die Sessions in ihrer Aushandlung mal zu beobachten.

--gandalf.

 

[Kabelkiller]

Danke erstmal:

@brötchen:
Stimmt genau, der Fehler ist im Betreff. Es muß richtig heißen " kann ICH den Angerufenen" nicht hören, sry. Habe den Betreff geändert.
Das Umklemmen geht leider nicht, weil der Router (http://www.ubnt.com/bullet) mit einer Funkantenne verschraubt ist und das wird mit der Fritzbox schwierig ( Außerdem ist auf dem Bullet natürlich die gesamte Funkkonfiguration drauf.)

@gandalf94305:
Zu dieser Annahme tendiere ich auch.
Eine Port/STUN-Geschichte erscheint mir unlogisch. So wie du schreibst, macht die weitere Vermittlung SIPGate. Das heisst, die Audio-Pakete kommen in BEIDEN Fällen (ausgehende Telefonate je einmal ins Mobil- und ins Festnetz) von dort, richtig ?

Um die Fritzbox VOIP-Gateway-Funktion auszuschließen (Codecs etc.) wäre eine mögliches Testszenario, sich einen Linksys PAP2T ATA-Adapter zu besorgen und ihn anstelle der Fritzbox VOIP-Gateway spielen zu lassen.
Ich habe einige Fehlermeldungen über VOIP-Probleme von Fritzboxen gefunden, wenn sie hinter Routern betrieben werden. Was haltet ihr davon?

Alternativ probiere ich sobald möglich für die ausgehenden Gespräche (Fritzbox-Wählregeln) einen anderen SIP-Anbieter aus, mal sehen, was das ergibt.

Von SIPGate und AVM habe ich noch keine Antwort.

 

[gandalf94305]

Genau... wenn der einzige Unterschied aus Sicht Deines Endgeräts die angewählte Nummer ist und sogar eingehend Anrufe von diversen Rufnummern funktionieren, halte ich es für unwahrscheinlich, daß es um ein Problem mit dem RTP-Datenstrom geht, denn das müsste dann ja unabhängig vom Content auftreten. Insbesondere würde es konsistent bei allen abgehenden Anrufen zu erwarten sein.

Desgleichen ist nicht einzusehen, warum für bestimmte Nummernkreise nur ein Outbound-Proxy oder ein STUN-Server zu verwenden ist.

Ist es systematisch bei Festnetz festzustellen, daß nur einseitig übertragen wird, wäre die nächste Frage (und daher der Hinweis mit dem Ethernet-Dump per Wireshark oder Packet-Dump der Fritz!Box Fon), ob denn der eingehende RTP-Datenstrom ankommt. Meine Vermutung wäre, daß dies der Fall ist, jedoch der Datenstrom aufgrund falscher SIP-Optionen oder falscher Codecs nicht in der FBF korrekt wiedergegeben werden kann.

Ich hatte auch schon Probleme mit einseitigen Verbindungen meiner Tk-Anlage mit Sipgate, aber das lag am Router und trat konsistent mit allen abgehenden Verbindungen auf, da der Router per SIP-ALG meinte, er müsse den Datenstrom umschreiben und von sich kommen lassen... wenn jedoch Festnetznummern sich anders als Mobilfunknummern verhalten, wäre der letzte Punkt, an dem alles noch ok ist, Sipgate, nicht Dein Router.

Soweit die Vermutungen... nun geht es mal an Fakten sammeln ;-)

--gandalf.

 

[imagomundi]

Hatte ähnliches Problem mit Sipgate: ich konnte mein Gegenüber nie hören, er mich aber sehr wohl. Meine FB (7170), an der das für die Telefonie benutzte Gerät hängt, ist selbst Client einer weiteren FB (7240), die die DSL-Verbindung herstellt.

Seit heute ist das Problem gelöst nachdem ich (per Export, Editieren mit einem Texteditor und Zurückspielen auf die Box) in der VOIP-CFG bei Sipgate folgende Einträge geändert habe:

is_nat_aware = yes;
localip = 192.168.178.xx;
ignore_received_header = yes;

Der 7170 habe ich im 7240-Netzwerk eine feste IP gegeben und diese als "localip" eingetragen. Die beiden anderen Daten von "no" auf "yes" gesetzt - und seither kein Problem mehr. Ich denke, daß die feste "localip" und das Ignorieren der (vom Sipgate-Server) erhaltenen Header-Daten die entscheidenden Änderungen sind. Die Header-Daten könnten auch erklären, weshalb das Phänomen nur bei Sipgate, Dusnet und Terrasip aufgetreten ist (die mir jeweils eine "Festnetz"nummer zur Verfügung stellen), nicht jedoch bei den Betamaxen. Letztere übermitteln "reine" SIP-Daten.

 

[Kabelkiller]

@gandalf94305:
Ich habe heute nochmal getestet und es ist nun heute so, dass ich auch bei Anrufen zum Mobilnetzen den Angerufenen nicht hören kann, also zusätzlich zu den Anrufen auf Festnetz. Ich hatte zwar ausführlich getestet und war mir auch sicher, aber heute ist es so wie beschrieben ...
Das würde dann doch auf eine Port/STUN-Problem hindeuten.

Von SIPGate und AVM habe ich Rückmeldungen der Supportlines bekommen, die im Wesentlichen mir bekannte Hinweise enthielten, u.a. Portfreigaben. Die Hinweise von Beiden habe ich kombiniert und habe nun die Portfreigaben wie im Anhang vorgenommen.

SIPGate empfahl:
"Aktivieren Sie bitte die Weiterleitung (Portforwarding/Virtual Server) folgender
Ports an Ihrem Router auf die IP der Fritz Box:

Port: 3478 / UDP
Port: 5060 / UDP
Port: 7078 / UDP
Port: 7079 / UDP

Löschen Sie, falls eingetragen, den Stun-Server: stun.sipgate.net aus der
Internettelefonie Einstellung der Fritz Box."

Das habe ich gemacht, FB und Router neu gestartet - Problem noch da.

AVM empfahl:
- STUN-Server eintragen, (Siehe SIPGAte!)
- "Portweiterleitung aktiv halten" auf 30sek (war schon gemacht) und
- statische Portweiterleitungen vom Router
"Von einem beliebigen UDP-Port größer oder gleich 1024 (z.B. 6060) auf Port 5060 der Fritz!Box. Der UDP-Port darf noch nicht verwendet werden. Von einem beliebigen UDP-Port größer oder gleich 1024 (z.B. 6078-6097) auf Port 7078-7097 der Fritz!Box. Die UDP-Ports dürfen noch nicht verwendet werden." - habe ich wie im Anhang umgesetzt, aber die Portfreigabeliste des Routes ist begrenzt :-(


@imagomundi:
Das habe ich im Einzelschrittverfahren ausprobiert und leider nie mein Ziel erreicht.
Wenn ich den localip-Eintrag setze, natürlich mit meiner IP, kann die FB sich nicht mehr bei SIPGate anmelden. Mehrmals probiert; mit Eintrag gesetzt bzw. wieder 0.0.0.0 Nach dem FB-Reboot war reproduzierbar kein Sipgate-Anmelden mehr möglich, wenn der Eintrag nicht auf 0.0.0.0 sondern der IP meiner FB stand.
Die anderen beiden machten keine Probleme, haben allerdings auch nichts genützt ;-)

Zu meinen anderen beiden Tests (anderer SIP-Provider) und Linksys PAP2T ATA-Adapter bin ich noch nicht gekommen. Ein Netzwerktrace ist der nächste VErsuch, dazu komme ich aber erst in einigen Tagen.

 

[imagomundi]

Kannst Du an Deinem vorgeschalteten Router den Port 5060 (und evtl. auch 7078) auf die 7170 weiterleiten?

 

[Kabelkiller]

@imagomundi:
Ich denke, das habe ich gemacht (siehe hochgeladenes Bild), auch wenn ich damit keine Veränderung feststellen konnte.

 

[gandalf94305]

Aha... nun, wenn sich Festnetz- und Mobilfunkziele gleich verhalten, dann würde ich wirklich zu einem Netzwerktrace raten, um zu sehen, ob der RTP-Datenstrom korrekt ankommt.

Ich hatte bei meinem Netgear-Router dieses Problem und konnte nur durch Abschalten von SIP-ALGs im Router einen normalen Zustand herstellen. Du kannst parallel ja mal klären, ob der Router irgendwelche SIP-ALGs unterstützt und man diese abschalten kann. Außerdem wäre zu klären, ob der Router symmetrisches NAT verwendet (STUN darf dann nicht genutzt werden) oder ein anderes NAT (dann kann STUN verwendet werden bzw. erforderlich sein).

Der Wireshark-Mitschnitt wird mehr sagen... ob Adressen und Ports nicht passen... ob ein Datenstrom nicht ankommt... ob Codecs falsch sind...

--gandalf.

 

[imagomundi]

Ich denke, das habe ich gemacht (siehe hochgeladenes Bild)

Ja, sorry, habe ich übersehen. Ich denke, die Problematik liegt tatsächlich IN dem vorgeschalteten Router.

 

[sven_h]

Vor dem selben Problem stehe ich auch gerade. Die Konstellation ist fast die gleiche wie bei dir, also 7170 hinter Router etc. pp.

In diesem Falle funktionieren Anrufe zu anderen Sipgate Teilnehmern einwandfrei. Anrufe zu Telekom Festnetz und Mobilfunk hat nur einseitige Kommunikation (Telefon an Fritz hört nichts). Ebenfalls funktionieren Anrufe zu einem Festnetzanschluss eines Telekomkonkurrenten. Ups!

Da Sipgate zu Sipgate funktioniert kann meiner Meinung nach das Problem nicht an fehlenden Portweiterleitungen liegen. Merkwürdiges Verhalten.

Gruß aus Spanien

 

[imagomundi]

@ sven _h:

Als erste Ursachenquelle wird der vorgeschaltete Router (dort: ALGs bzw. welche Art NAT?) vermutet. Deshalb: Welcher Router?

@ kabelkiller: Das Datenblatt zu Deinem Bullet5 gibt leider keinen Aufschluß über die hier benötigen Details. Scheint auch eine nicht allzu bekannte Spezies von Router zu sein.

 

[sven_h]

@ sven _h:

Als erste Ursachenquelle wird der vorgeschaltete Router (dort: ALGs bzw. welche Art NAT?) vermutet. Deshalb: Welcher Router?

Nicht böse sein, aber das vermute ich eben nicht. Das ganze ist eine Installation hinter einer Funkstrecke. Ich müsste mir die Finger wund tippen alles aufzuzählen. Die Installation hat bis vor kurzem tadellos funktioniert.

Viel entscheidender: Ich kann telefonieren! Alle Pakete werden korrekt geroutet. Sprache und Signalisierung OK. Aber eben nur solange die Gegenstelle ebenfalls ein Sipgate Anschluss ist. Die Entscheidung darüber fällt ja erst auf Sipgate Seite ob es ein Festnetzanschluss oder ein interner Sipgate Anschluss ist.

Mich interessiert ob der SIP Header bei Endteilnehmer Festnetz ein anderer ist als bei Endteilnehmer Sipgate Account.

Dazu kommt: Ein weiterer "vermeintlicher" Festnetzanschluss funktioniert ebenfalls. Bei diesem handelt es sich um einen mir nicht benannten Telekomkonkurrenten. Ich vermute jetzt einfach mal dieser vermittelt seine Gespräche ebenfalls übers Internet.

Mir geht es erstmal darum theoretisch zu verstehen wie und warum dieser Fehler auftritt.

Also nochmal: Weiss jemand inwiefern sich Endgerät=SIP, Endgerät=Festnetz, Endgerät=Mobiltel z.B. im Sipheader unterscheiden?

Danke und Gruss

 

[imagomundi]

Das ganze ist eine Installation hinter einer Funkstrecke. Ich müsste mir die Finger wund tippen alles aufzuzählen. Die Installation hat bis vor kurzem tadellos funktioniert.

Finger wund tippen muß nicht sein - aber was vor der FRITZ hängt, ist immerhin eine bisher nicht bekannt gewesene Information. Auch, daß es bis vor kurzem funktionierte.

Die Entscheidung darüber fällt ja erst auf Sipgate Seite ob es ein Festnetzanschluss oder ein interner Sipgate Anschluss ist.

Mich interessiert ob der SIP Header bei Endteilnehmer Festnetz ein anderer ist als bei Endteilnehmer Sipgate Account.

.......................................

Mir geht es erstmal darum theoretisch zu verstehen wie und warum dieser Fehler auftritt.

Also nochmal: Weiss jemand inwiefern sich Endgerät=SIP, Endgerät=Festnetz, Endgerät=Mobiltel z.B. im Sipheader unterscheiden?

Spricht da nicht eine erhebliche Wahrscheinlichkeit dafür, daß "vor kurzem" auf Sipgate-Seite Änderungen bei der Weiterleitung (der von dort weitergeleiteten Header-Daten) stattgefunden haben?

Die erste Frage ist generell und wird möglicherweise (hoffentlich) deshalb tatsächlich ein Experte in diesem Forum beantworten können.

Dabei muß die Antwort auf die letzte Frage wegen möglicher spezieller Sipgate-Konfiguration nicht unbedingt identisch sein mit der Antwort auf die generelle Frage.

 

[gandalf94305]

Für diesen Effekt gibt es tatsächlich auch andere Erklärungen als der vorgeschaltete Router. Das ist natürlich immer so ein Verdachtspunkt, aber es können auch Probleme in der Behandlung von SIP-Optionen (z.B. für Inband/Outband-Signalisierung von DTMF) oder der Aushandlung von Codecs auftreten. Es kann natürlich auch ein STUN-Problem sein, wenn bei symmetrischem NAT ein STUN-Server verwendet wird.

Daher ist aus meiner Sicht ein Wireshark-Mitschnitt unumgänglich, um die Unterschiede wirklich festzustellen.

--gandalf.

 

[sven_h]

Problem bei der Aushandlung von Codecs könnte eine plausible Erklärung sein.

Ich werde mir den Netzwerkverkehr mal ansehen. Ich bin aber für jeden weiteren Denkhinweis dankbar.

Danke und Gruss

 

[gandalf94305]

...auf die Gefahr hin, mich zu wiederholen: achte auf jeden Fall auch auf SIP OPTIONS, die in der Session übermittelt/gefordert werden. Das kann bei Nichtunterstützung zu solchen Problemen führen.

--gandalf.

 

[sven_h]

Danke auch für diesen konkreten Hinweis. Ich werde wohl heute nachmittag einen Termin bei der Kundin wahrnehmen und hoffentlich zu einer Lösung finden. Werde dann mal berichten.

Vielen Dank für die Hilfe, Gruss aus Spanien

 

[sven_h]

Tja, so kann man sich irren. Das Problem lag doch in nicht korrekt weitergeleiteten Ports. Da dies nach einer Neukonfiguration auf Seiten der Router des Funkstreckenanbieters auftrat (auf die ich natürlich keinen Zugriff habe), konnte ich mit eurer Hilfe alle Fehler auf unserer Seite ausschliessen. Die Betreiber der Funkstrecke waren kooperativ und die Kundin kann wieder sipgaten. Hinter insgesamt ca. 4 Routern gar nicht so trivial.

In diesem Sinne, Danke und Gruss aus Spanien