voip und drei router?

Danke Horst, folgendes liegt auch bei mir vor:
ich habe festgestellt, dass "normale" Serveradressen (die in der Anlage eingetragen sind) nicht aufgelöst werden können. Gemerkt habe ich das daran, dass er sich mit der Voreinstellung des Zeitservers nicht die aktuelle Zeit aus dem Netz holte, nun nachdem durch ich diese duch eine numerische ersetzt habe, klappt es, da liegt der Schlüssel.
Das sollte ich vielleicht auch mal versuchen, statt sipgate.de die numerische Auflösung einzutragen. Wo bekomme ich die her?
 
Hallo,
numerische Auflösung versteh ich als IP-Adressen von sipgate.de! Einfach in der Konsole (cmd) ping "www.sipgate.de" (Ohne die Hochkommas bitte).
 
Hat auch nichts geholfen. Interessant ist auch folgendes: Obwohl ich im sip-protokoll der ocl besagten registrierungsfehler erhalte, werden ein- und ausgehende Rufe im Anrufprotokoll auf der sipgate-website registriert. Wenn ich mich selber übers handy anrufe höre ich nach einer bestimmten Wartezeit die Ansage, dass ich nicht erreichbar sei. Wenn ich versuche, einen externen Anschluss anzurufen, höre ich rein gar nichts, jedoch klingelt es auf der Gegenseite. Auch dieser Anruf wird auf der sipgate-website protokolliert. Wie kann das sein, wenn doch die ocl einen permanenten Registrierungsfehler meldet?
 
Probleme bestehen zwar weiter, jedoch habe ich nun, nach dem ich hier doch recht intensiv im Archiv gelesen habe, mehr Fragen als Antworten. Zunächst einmal zum Portforwarding: in manchen Beiträgen heißt es, dass dies nicht nur nicht erforderlich sondern gar schädlich sei, wenn man - wie ich - die Anlage hinter einem anderen router und folglich mit stun-Eintrag betreiben wolle. Folglich habe ich probehalber mal mit, mal ohne portforwarding konfiguriert, indes ohne jeden Einfluss auf das bestehende Problem. Müssen ports nun weitergeleitet werden oder nicht, wenn man die ocl31lan mit stun hinter einem anderen router betreibt? Das zum ersten;

Folgende Beobachtung habe ich im sip-Protokoll der ocl31lan gemacht: Abhängig von der Aktivierung der DNZ-Funktion im vorgeschalteten Netgear, verändert sich NAT von "full cone" auf "port restricted". Nur mit eingeschalteter DMZ-Funktion habe ich "full cone". An dem Registrierungsproblem ändert sich freilich auch dadurch nichts. Mit "port restricted cone" hat der detewe wohl so seine Probleme, zumindest geht das aus den faqs bei detewe hervor. Gehe ich also recht in der Annahme, dass ich DNZ im netgear-Router standardmäßig aktiviert lassen sollte, wenn ich die Konfiguration überhaupt irgendwann einmal zum Laufen zu bringen will? Und was bedeutet die DMZ-Aktivierung für das Portforwarding, falls dieses doch erforderlich sein sollte? In einem britischen Forum habe ich gelesen, dass eine aktivierte DMZ plus weitergeleitete Ports in Konflikt zueinander geraten, wenn sie denn beide die selbe Ziel-IP haben, in meinem Fall also die ip des detewe.
 
Danke für die wie immer rasche Antwort, Horst. "DMZ" kann ich ein- oder abschalten, das ist eine Sache. Aber was bedeutet das für mein Problem, wenn trotz auf die ip der oc31lan aktivierte DMZ-Funktion die selben Fehler fortbestehen? In dem wiki-link steht folgendes:
Exposed Host als „Pseudo-DMZ“ [Bearbeiten]Einige Router für den Heimgebrauch bezeichnen die Konfiguration eines Exposed Host als „DMZ“. Dabei kann man die IP-Adresse eines Rechners im internen Netz angeben, an den Pakete auf allen Ports aus dem Internet weitergeleitet werden. Dieses Verfahren stellt ein erhebliches Sicherheitsrisiko dar. Es eignet sich eher für die Fehlersuche, um temporär den Einfluss der Firewall zu umgehen, etwa bei Problemen mit bestimmten Datenverbindungen.
Auch bei mir wird es sich um eine solche "Pseudo-DMZ" handeln, zumal diese Beschreibung auch zu derjenigen im netgear-Handbuch passt. Wenn es an den firewall-Einstellungen läge, müsste ich die oc31lan doch zumindest mit aktivierter DMZ-Funktion ohne Probleme betreiben können. Oder habe ich da einen Denkfehler? Auf die Fehlfunktionen hat es jedoch keinerlei Auswirkungen, außer, dass sich NAT von "full cone" auf "port restricted" ändert.

Das bringt mich zu meinem nächsten Problem. Auf der Homepage von Detewe steht:
6. Wie betreibe ich meine OpenCom 31lan hinter einem Router? (Firmware 2.30 vorausgesetzt)

Der Betrieb der OpenCom 31lan hinter einem Router setzt voraus, dass Ihr Router eine der folgenden NAT-Instanzen unterstützt:
Open
Full Cone
Die Kompatibilität mit Routern mit der Betriebsart „Port Restricted Cone“ ist von verschiedenen Rahmenbedingungen abhängig und muss von Fall zu Fall erprobt werden.
Full Cone habe ich aber nur mit aktivierter DMZ im Netgear. Ansonsten steht im sip-log der ocl31lan "Port Restricted Cone"*. Wenn die obige Aussage stimmt, weiß ich nicht einmal, ob meine Kombination überhaupt möglich ist. Wie gesagt, ich bin absolut neu in der Materie, gebe mir Mühe, den massenhaften input der letzten Tage zu verstehen, muss aber zugeben, dass mich das eine oder andere an (für mich) neuen Fachtermini doch recht verwirrt. Deshalb bitte um Nachsicht, auch wenn ich die eine oder andere (für Euch) dumme Frage stelle ;).

* Nachtrag: unabhängig davon, ob ich ports selber weitergeleitet habe oder nicht.
 
Interessant. Habe unter http://www.ip-phone-forum.de/showthread.php?t=114801&highlight=stun+portforwarding+sipgate
folgenden Beitrag gelesen
O.k., heute war die Geschichte erfolgreich. Mit der FBF 5050 hinter dem Buffalo-Router (beide UPNP ausgeschaltet) war genau gar keine zusätzliche Information nötig. Weder Portforwarding, noch STUN, noch SIP-Proxy. Einfach von sipgate Telefonnummer, ID, Paßwort und Registrar eingetragen, die FBF resettet und Telefonate klappten einwärts wie auswärts. So sollte es immer sein.
... und daraufhin spasseshalber den stun-Eintrag in der oc31lan gelöscht. Telefonieren kann ich zwar immer noch nicht, aber merkwürdigerweise haben sich die Registrierungsprobleme damit erledigt. Statt der Fehlermeldung steht im sip-log nun:
2005-01-01 00:00:03 Registering with SIP server account #1(sipgate.de)
2005-01-01 00:00:03 Registering with SIP server account #2(sipgate.de)
2005-01-01 00:00:03 Registering with SIP server account #3(sipgate.de)
2005-01-01 00:00:03 Successfully registered with SIP server account #1(sipgate.de) for 3603 seconds
2005-01-01 00:00:03 Successfully registered with SIP server account #2(sipgate.de) for 3603 seconds
2005-01-01 00:00:03 Successfully registered with SIP server account #3(sipgate.de) for 3603 seconds

Habe stun nun wieder drin, probeweise auch mal den von gmx probiert. Alte Fehlermeldung bei der Registrierung:
2005-01-01 00:00:07 STUN: NAT Type for account #1(sipgate.de): Full cone NAT
2005-01-01 00:00:12 STUN: NAT Type for account #2(sipgate.de): Full cone NAT
2005-01-01 00:00:17 STUN: NAT Type for account #3(sipgate.de): Full cone NAT
2005-01-01 00:00:22 Registering with SIP server account #1(sipgate.de)
2005-01-01 00:00:27 Registering with SIP server account #2(sipgate.de)
2005-01-01 00:00:32 Registering with SIP server account #3(sipgate.de)
2005-01-01 00:01:05 Register timed out, retrying
 
Zuletzt bearbeitet:
Mittlerweile habe ich dmz wieder aus und die ports entsprechend weitergeleitet. Es scheint in der Tat mit dem stun-Eintrag zu tun zu haben. Folgendes Problem:

mit stun in der sip-konfiguration der oc31lan --> keine erfolgreiche Registrierung bei sipgate möglich

ohne stun in der sip-konfiguration der oc31lan --> zwar Registrierung ohne Probleme, dafür aber - wohl eben wegen der Ermangelung eines stun-servers (?) - keinerlei Telefonate möglich.

In beiden Varianten werden Testanrufe, ob kommend oder gehend, im sip-log der oc31lan registriert, wie etwa mein Anruf auf die Testnummer 10000:
2005-01-01 00:02:32 Calling number sip:[email protected] via account #1(sipgate.de)
2005-01-01 00:02:32 <<<<<<<<<< New Call >>>>>>>>>>
2005-01-01 00:02:32 Remote took call
2005-01-01 00:02:32 Audio codec for call is: GSM full rate
Da passiert rein gar nichts, kein piepsen, kein tuten, nichts. Was hat das "remote took call" zu bedeuten, ist das normal?
 
Sorry, hatte den Beitrag davor gelesen, war aber noch in einer Testsituation!

Nee, normal ist das nicht! :mad:
Womit hast du dich denn angerufen, Handy?

Wieso kannst du nicht über die OC Telefonieren?????
Ist da noch was in den Einstellungen der OC, was wir vergessen haben? Aber was?
 
eurasya schrieb:
Was hat das "remote took call" zu bedeuten, ist das normal?
Die Gegenstelle hat das Gespräch angenommen. Das ist normal.
Die nächste Zeile gibt dann aus welcher Audio-Codec verwendet wurde.
 
@mad79: Das könnte es sein. Die Codecs bei der OC! :)

Nur wie kommt man da dran? :noidea:
 
@doc456: Die kann man ganz bequem via Konfigurationsmenü auswählen, damit hat das Problem aber nichts zu tun.
Die OC hinter einem anderen Router ans laufen zu bekommen ist schwierig, ich hatte meiner dafür eigene Zugangsdaten gegeben, das war einfacher.;)

@eurasya: Verteilt der Funkrouter private oder öffentliche IP-Adressen?
 
Ja, über das Handy. Ich weiß nicht mehr weiter. Im Moment erwäge ich ernsthaft, die oc zusammenzupacken und an sipgate retour zu schicken. Vielleicht hole ich mir ja den netgear voip-router, obwohl mir der eigentlich eine analoge Anschlußmöglichkeit zu wenig hat.

Die Gerätekombination, die ich habe, scheint auch recht selten zu sein. Zumindest habe ich in der Suchmaske nichts gefunden, wenn ich "wgt624" und oc31lan kombiniert habe. So fallen auch entsprechende Erfahrungsberichte anderer user weg, resp. ich weiß nicht einmal, ob die Geräte überhaupt kompatibel zueinander sind.
 
Hi mad, der Router der Richtfunkantenne verteilt gar keine ip-adressen mehr. Den habe ich auf die Funktion eines reinen dsl-modems beschränken lassen und direkt mit dem wan-port des netgear wgt624 verbunden. Dieser ist nun auch der DHCP-Server im lan.
 
Sorry, aber beantworte doch mal bitte die Frage von mad79.
Sind das IP-Adressen mit 2xx.xx oder 82.xxx
Poste uns doch bitte mal die Werte, wenn du in der Konsole (Start - Ausführen - cmd), ipconfig /all einträgst, O.K.?
 
Erlaubt mir bitte, dass ich nochmals auf folgende Frage aus obigem Beitrag zurückkomme:
Wenn es an den firewall-Einstellungen läge, müsste ich die oc31lan doch zumindest mit aktivierter DMZ-Funktion im Netgear ohne Probleme betreiben können. Oder habe ich da einen Denkfehler?
Stimmt diese Aussage so? Wenn ja, brauche ich mir über portforwarding und firewalleinstellungen gar keine Gedanken zu machen, dann liegt das Problem woanders. Was ich defintiv nicht verstehe, ist der Umstand, dass die Registrierung am sip-server mit den stun-Einstellungen steht und fällt.
 
Bittteeee, lass die Finger von der DMZ! Du hast dein ganzes Netz da drin. Alles ist offen, bitte nicht!
 
doc456 schrieb:
Sorry, aber beantworte doch mal bitte die Frage von mad79.
Sind das IP-Adressen mit 2xx.xx oder 82.xxx
Poste uns doch bitte mal die Werte, wenn du in der Konsole (Start - Ausführen - cmd), ipconfig /all einträgst, O.K.?
Hoffe, dass ich die Frage richtig verstanden habe. Im lan habe ich ips mit 192...., eben dem Adress-Bereich, den ich selber im netgear definiert hatte. Wenn damit "privat" gemeint ist, dann ja. Im Internet tauche ich mit einer einzigen, von meinem Provider zugewiesenen ip auf, beginnt mit 217... Da ist es auch egal, mit welchem Gerät ich online bin, die ip ist immer die selbe.
 
doc456 schrieb:
Bittteeee, lass die Finger von der DMZ! Du hast dein ganzes Netz da drin. Alles ist offen, bitte nicht!
War ja nur probeweise, ist mittlerweile auch wieder zu. Meine Frage bezog sich darauf, ob die Probleme an den Firewalleinstellungen liegen können, wenn die gleichen Probleme auch mit DMZ bestehen.
 
Mit der 198.er ist alles gut, das sind keine öffentlichen IP's.

Tu mir nur mal bitte einen Gefallen: Mach nicht gleich einen neuen Post, man kommt mit lesen nicht mehr hinterher. Wenn du noch was zusätzlich sagen willst, dann geh auf Ändern der Posts und setzte ein EDIT darunter mit den Zusatzinfos, O.K.!

EDIT: Bitttteeeee, nicht so viele Posts (so geht das)
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,827
Beiträge
2,219,005
Mitglieder
371,520
Neuestes Mitglied
fredl_2
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
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.