Hallo,
habe nun die ohne separate Email-Benachrichtung im Dezember offenbar schon seit 16.12.08 existierende FW3.0M Build 000 (stand erst heute in den “News & Facts”) geladen und warte ab, was in Bezug auf VoIP und besonders SipGate und T-Online passiert - hoffe es klappt nun stabil.
Alex
…tja, leider mal wieder zu früh gefreut, d.h. auch mit der FW 3.0M Build 000 steigen nach einigen Stunden die SipGate-Accounts mit Fehler 408 und T-Online mit Fehler 503 aus, d.h. nun ist wieder die FW 2.2G Build 001 drauf, die stabil läuft - schade 
Alex
[quote=PABX-Alex]…tja, leider mal wieder zu früh gefreut, d.h. auch mit der FW 3.0M Build 000 steigen nach einigen Stunden die SipGate-Accounts mit Fehler 408 und T-Online mit Fehler 503 aus, d.h. nun ist wieder die FW 2.2G Build 001 drauf, die stabil läuft - schade
Alex[/quote]
Hi,
hast Du denn inzwischen mal Traces machen können?
[quote=ISDN-Freak]Hi,
hast Du denn inzwischen mal Traces machen können?[/quote]
Hallo,
nein leider nicht - deshalb war das Erste was ich versuchte zu Tracen, aber auch das klappte zumindest von Ferne nicht.
Das dieses Verhalten u.a. in direktem Zusammenhang mit der Firmware steht ist für mich nun eindeutig, doch da es offenbar bei sonst noch keinem aufgetreten ist, dürfte die bei mir verwendete Glasfaser-Strecke (ISIS-Opal), welche bereits vor Erscheinen der neuen FW zur Geschwindigkeitssteigerung von DSL 1000 auf DSL 6000 mit einer anderen Anschaltung versehen wurde, auch eine Rolle spielen.
Auffällig ist auch, dass nur SipGate und T-Online abnippeln, VoIPDiscount (Betamax) bleibt auf mit der FW 3.0K/M stabil, d.h. es wäre zu klären, worin die Unterschiede der Protokolle liegen womit man den Grund des Fehlers weiter eingrenzen könnte.
Momentan ist zumindest bei mir die Verwendung der alten FW zwar noch nicht mit der Einbuße wichtiger Leistungsmerkmale verbunden, doch kann und wird sich das sicher ändern, weshalb es denke ich schon wichtig wäre, das zu klären.
Sicher erinnerst Du Dich noch an die letztendlich nachgewiesene Vertauschung der B-Kanäle in der ISIS-Opal-Software der DTAG, was mir solange keiner glaubte, bis sich schließlich der Hersteller der Vermittlungsstelle (SEL) aufschaltete und den Softwarefehler bestätigte.
Gruß Alex
Hi,
es kann auch die Provider eingesetzte VoIP-Hardware sein. Zum Beispiel bei 1&1 gibt es dieses Problem ebenfalls massiv. Dort benutzt man unterschiedliche Hardware, die sich auch unterschiedlich verhält.
… heraus zu bekommen, welche VoIP-Hardware SipGate & T-Online in “meinem” Fall benutzt, dürfte wohl aussichtslos sein (vielleicht ja auch die gleiche 
), doch werde ich mich schlau machen, welche Anschaltung die T-Com für meinen Anschluß verwendet, eventuell hilft das ja weiter :rolleyes:
Alex
[quote=PABX-Alex]… heraus zu bekommen, welche VoIP-Hardware SipGate & T-Online in “meinem” Fall benutzt, dürfte wohl aussichtslos sein (vielleicht ja auch die gleiche ), doch werde ich mich schlau machen, welche Anschaltung die T-Com für meinen Anschluß verwendet, eventuell hilft das ja weiter :rolleyes:
Alex[/quote]
Eben nicht, da sie sich ja ggf. zu erkennen gibt. Letztendlich ist ja auch das Verhalten ausschlaggebend.
Ach so, ja - mit einem „Sniffer“ könnte das schon klappen…hm…nur läuft das mit dem „Wireshark“ eben auch nicht, zumindest weis ich nicht wie 
Alex
Hallo Zusammen,
leider bleibt mir wohl nichts anderes übrig, als diese immer noch nicht erledigte Thema wieder aufzugreifen, wobei ich auf der CB.2 zwischenzeitlich die FW 3.2G Build 0000 drauf habe und diese SipGate-Problem “nur” noch ca. alle 2-4 Wochen für ca. 1-3 Tage auftritt - ja, so willenlos ist das 
Zur Fehlerbeschreibung :
Der SipGate-Account sind nach Default eingerichtet und funktioniert, wenn er denn funktioniert stabil und ohne jegliche Mucken.
Wenn dieser aber mal wieder aussteigt (wie heute), dann erscheint bei der Registrierung “Fehler 503 Service nicht verfügbar”.
Sämtliche Versuche wie Anlagen- bzw. Gateway-Reboot oder Änderungen an den Account-Settings ändern am Zustand nichts.
Ich habe auch schon sipgate.de getraced und festgestellt, dass dieser schneller und besser erreicht werden kann als voipdiscount.com , welcher ebenso auf der CB.2 läuft und zur gleichen Zeit keinerlei Probleme macht oder je machte.
Wenn ich über einen separaten Linksys-VoIP-Router am gleichen Gateway (Linksys WAG-160N) zum selben SipGate-Account zur gleichen Zeit eine Verbindung aufbaue, funktioniert diese ebenso, wie mit dem SoftClient von SipGate auf dem Rechner.
Irgendwann, geht dieser bzw. diese SipGate-Accounts (sind 2 auf der CB.2) dann ohne irgend welches Zutun wieder 
Als es das VoIP von T-Online bis Anfang September noch gab, hatte ich damit zeitgleich die selben Probleme, seit der Abschaltung bei der offenbar auf einiges in den Netzbetreiber-Netzen bez. VoIP umgestellt wurde, hat sich das Problem wieder verstärkt.
Ich habe diesbezüglich bereits die T-Com und SipGate angetriggert, doch beide beteuern, dass es nicht an denen läge - was tun
Nachdem ich damit nun schon sooo viel Ärger und Aufwand hatte, bin ich nun fest entschlossen diesem Fehl-Verhalten von welcher Seite es auch immer kommen mag auf den Pelz zu rücken und endgültig auszumerzen, denn das nervt extrem - zu bemerken wäre dazu, dass es mit der FW 2.x diesbezüglich keine Probleme gibt !
Gruß Alex
Seit die SIP-ALGs im meinem Router abgeschaltet sind, funktioniert Sipgate mit der 3.x Firmware (zuerst 3.2E-000, jetzt 3.2G-000) ohne Probleme…
Wesentlicher Punkt: ich musste die Echo Cancellation abschalten, damit die Registrierung korrekt funktioniert.
–gandalf.
Meinst Du die Echokompensation in der Tk-Anlage oder etwas in Deinem Router ?
Habe Deine Info gelesen und bin gleich mal auf die Anlage - wie das bei sporadischen Fehlern nun mal dummerweise ist, geht´s gerade (schon) wieder - hatte mich auf Die. oder Mi. eingestellt :rolleyes:, trotzdem habe ich mal die Echokompensation abgeschaltet.
Also mal sehen was passiert oder nicht - wenn länger als 4 Wochen nicht abnippelt, würde ich es schon mal als “Erfolg” werten.
Kannst Du Dir einen Reim drauf machen, was die Echokompensation mit der Registrierung zu tun haben kann ?
Alex
Die Echokompensation ist eine SIP OPTION und damit nicht standardmäßig unterstützt. Ich habe im SIP-Trace seltsame Effekte gesehen, als diese Option auf “an” gestellt war. Mit Echokompensation aus (in der Anlage) bestehen überhaupt keine Probleme mehr… auch keine Echos 
Ansonsten fällt mir noch der Router auf: WAG160N. Hat der nicht symmetrisches NAT, d.h. dann darf man keinen STUN-Server angeben.
–gandalf.
[quote=gandalf94305]
Ansonsten fällt mir noch der Router auf: WAG160N. Hat der nicht symmetrisches NAT, d.h. dann darf man keinen STUN-Server angeben.
–gandalf.[/quote]
Braucht man den bei Sipgate überhaupt noch? Die haben doch einen SBC.
Grüße
Olli
Dass dieses Verhalten nichts mit der “Echokompensation” der CB.2 zu tun haben dürfte, dachte ich mir schon, doch was macht man nicht alles in der Verzweiflung 
- ist wieder aktiviert.
Bez. NAT beim Linksys WAG-160N bin ich offengesagt überfragt, habe es aber aber auch schon mit und ohne STUN-Server probiert, was keinerlei erkennbare Veränderung des Verhaltens ergab.
Settings bez. Echo im WAG-160N gibts so wie beim WAG-300N, den ich zuvor verwendete und damit die gleichen Probleme auftraten, nicht.
Womit ich wieder beim alten Stand der Ermittlungen wäre
Würde gerne mal direkt mit Wireshark tracen, doch weis ich beim besten Willen nicht nach was ich suchen soll, bzw. welche Filter zu setzen sind.
Gruß Alex
Seit ein Paar Stunden ist SipGate wieder “platt”, d.h. Registrierung Fehler 503 
Ich habe sipgate bei mir wie folgt eingerichtet:
Anbietername = sipgate
Domain = sipgate.de
Registrar = sipgate.de
STUN-Server = nein
NAT-Keepalive = nein
Outbound-Proxy = deaktiviert
Zeitspanne für die Registrierung = 5
SIP-UDP-Port = 5063
SIP-Session-Timer = aktiv 10
Jitter-Buffergröße = 50
Keine Zertifikate
Echokompensation = nein
Format der gewählten Rufnummer = Landesvorwahl mit führenden Nullen (z.B. 00495306…)
Art der Rufnummernübermittlung = Im Displaytext
Format der übermittelten Rufnummer = Ohne Landesvorwahl (z.B. 05306…)
Displaytext bei Rufnummernunterdrückung = Anonymous
Rufnummernunterdrückung durch den Anbieter (“Privacy: User” setzen) = nein
Umwandlung kommender VoIP-Rufnummern:
Account “VoIP sipgate” als Mehrgeräteanschluss:
Accountnummer = 70
Benutzername =
Passwort =
Authentifizierungs-Id =
Mehrfachrufnummer (MSN): <meine rufnummer 071…>
Displayname: "Home sipgate"
Klingelrhythmus: 1 x lang
Im Router gibt es folgende Einstellungen:
Damit läuft das bei mir ohne Probleme quasi 24/7. Firmware ist 3.2G-000.
–gandalf.
[quote=gandalf94305]Ich habe sipgate bei mir wie folgt eingerichtet:
Anbietername = sipgate
Domain = sipgate.de
Registrar = sipgate.de
STUN-Server = nein
NAT-Keepalive = nein
Outbound-Proxy = deaktiviert
Zeitspanne für die Registrierung = 5
SIP-UDP-Port = 5063
SIP-Session-Timer = aktiv 10
Jitter-Buffergröße = 50
Keine Zertifikate
Echokompensation = nein
Format der gewählten Rufnummer = Landesvorwahl mit führenden Nullen (z.B. 00495306…)
Art der Rufnummernübermittlung = Im Displaytext
Format der übermittelten Rufnummer = Ohne Landesvorwahl (z.B. 05306…)
Displaytext bei Rufnummernunterdrückung = Anonymous
Rufnummernunterdrückung durch den Anbieter (“Privacy: User” setzen) = nein
Umwandlung kommender VoIP-Rufnummern:
Account “VoIP sipgate” als Mehrgeräteanschluss:
Accountnummer = 70
Benutzername =
Passwort =
Authentifizierungs-Id =
Mehrfachrufnummer (MSN): <meine rufnummer 071…>
Displayname: "Home sipgate"
Klingelrhythmus: 1 x lang
Im Router gibt es folgende Einstellungen:
Damit läuft das bei mir ohne Probleme quasi 24/7. Firmware ist 3.2G-000.
–gandalf.[/quote]
Bei meiner cp3000 mit eigentlich identischen Einstellungen funktioniert Sipgate ebenfalls tadellos.
Grüße
Olli
Moin Zusammen,
habe Eure Hinweise gleich dankend aufgegriffen, d.h. die von der Auerswald-Vorgabe-Konfiguration für Sipgate abweichenden Settings vorgenommen, was auch nach entsprechender Wartezeit leider keinerlei Veränderung ergab.
Dann bin ich auf das Gateway Linksys WAG160N-DE und habe (mal wieder) die Settings insbesondere in Bezug auf Port-Weiterleitung kontrolliert. Dabei stellte ich fest, dass die Portbereichs-Weiterleitung nicht wie von @Gandalf angegeben von 49152-49408 sondern, so wie das Sipgate fordert von 49151-49408 per UDP auf die IP der CB.2 führt.
Habe trotzdem versuchsweise ab 49152 probiert, was aber auch keine Änderung ergab, d.h. ich gehe davon aus, dass sich @Gandalf einfach vertippt hat.
Der Port 5060 (Outbound-Proxy) ist bei meiner CB.2 via UDP und Einzelport-Weiterleitung, die Ports 5061-5069 so wie es die VoIP-Provider angeben via UDP (nicht TCP & UDP) und Portbereichs-Weiterleitung auf die IP der CB.2 eingerichtet.
Versuchsweise habe ich die Ports 5061-5069 anstatt nur via UDP auch über UDP & TCP (Setting: “Beide”) eingerichtet, was jedoch auch keine Veränderung ergab.
Bis jetzt also Stand wie zuvor, d.h. Sipgate Registrationsfehler 503 (Server nicht verfügbar), VoipDiscount (Betamax) geht !
Da ich nun gerade dabei war, habe ich mich dazu entschlossen einen testweise als Alternative für Sipgate eingerichteten, deaktivierten Zugang, der die gleichen Probleme wie Sipgate machte komplett zu löschen und die Ports der einzelnen Provider “aufzuräumen”, d.h. VoipDiscount und ein weiterer deaktivierter Betamax-Provider wurden geändert, wozu ich auch kurz den Port von Sipgate 5063 änderte und diesen dann wieder zurück auf 5063 gesetzt habe.
Zu meiner Verwunderung und obwohl ich solche Aktionen zuvor schon mehrfach durchgeführt hatte, hat sich der SipGate-Zugang daraufhin sofort registriert, was vorher mit keiner Änderung der Settings, Reboot oder sonst was geklappt hat, d.h. nur warten half was mir nun noch mehr Rätsel aufgibt.
Wodurch das bewirkt wurde bzw. ob es einfach nur Zufall war und sich zu diesem Moment die Anlage auch ohne jede Änderung wieder bei Sipgate registriert hätte kann ich letztendlich nicht feststellen
Letztendlich, heißt es nun mal wieder abwarten, denn dieser funktionsfähige Zustand hat zuvor ja schon bis zu ca. 4 Wochen angehalten, bis dann doch wieder der Fehler 503 auftauchte
Zusammenfassung :
Im Moment ist alles so wie von @Gandalf angegeben konfiguriert, bis auf die Port-Bereichsweiterleitung, die bei mir auf 49151-49408 nur via UPD steht, was ich aber auch in UDP & TCP ändern könnte, doch verstehe ich nicht weshalb auch TCP nötig sein soll.
Auffällig ist nach wie vor, dass es mit der CB.2 FW2.x auch mit SipGate keinerlei Probleme gab, VoipDiscount (Betamax) auch wenn SipGate Fehler 503 bringt langzeitstabil läuft, d.h. auch dieser Zugang brachte bei den Versuchen schon mal kurz Fehler 503, was mich vermuten läßt, dass dieses (Fehl-)Verhalten an einem Timeout liegen könnte, wobei SipGate “empfindlicher” als die Betamaxe reagiert.
Der Unterschied zwischen SipGate und den Betamaxen besteht ganz allgemein zumindest schon mal darin, dass SipGate die Port-Bereichsweiterleitung von 49151-49408 benötigt, was eventuell damit zusammenhängen könnte, dass es mit SipGate möglich ist, sich von verschiedenen Punkten gleichzeitig anzumelden (was ich mit betr. Account aber nicht mache), bei den Betamaxen das aber nicht geht, d.h. auf der CB.2 (zumindest noch bis FW 3.2D) sich 2 verschiedene Accounts beim gleichen Betamax-Provider gegenseitig blockieren, d.h. es funktioniert immer nur einer.
Die Betamaxe erfordern diese Port-Bereichsweiterleitung nicht.
Gruß Alex
Zu den RTP-Ports: wenn Du unter Administration -> Montoring -> Portübersicht mal nach den RTP-Ports schaust, dann wirst Du dort den von mir genannten Range lesen. Es geht um den RTP-Port-Range der Anlage, nicht den von sipgate. Sipgate kann viel erzählen und tun, aber RTP-Port-Ranges auf Deiner Anlage wird das nicht ändern. Also: relevant ist die Weiterleitung derjenigen Ports, die in der Aushandlung der Datenströme vereinbart werden - und das sind nun mal die von den jeweiligen Gesprächspartnern vorgeschlagenen Ports - im Falle der COMmander Basic.2 genau die in der Anlage nachzulesenden.
Warum sipgate 49151/udp weitergeleitet haben möchte, ist mir ein Rätsel, wird jedoch nicht schaden. Mehr ist kein Problem… nur wenn es bei Dir weniger Ports (d.h. nur eine Teilmenge der als RTP-Ports genannten Ports der Anlage) wären, bekämst Du ein Problem, wenn in der RTP-Aushandlung genau ein solcher, fehlender genutzt würde.
Für Betamax sollte auch ein Portbereich erforderlich sein, denn bei eingehenden Gesprächen muss ein RTP-Port ausgehandelt werden können. Abgehende Gespräche werden wohl trotzdem funktionieren, da dafür sogar eine ad-hoc-Registrierung ausreicht.
Früher einmal gab es in der COMmander Basic.2 ein Problem damit, daß man VoIP-Anbieter nur aktiv bekam, wenn man mindestens noch einen weiteren eingerichtet hatte… nur ein VoIP-Anbieter (und die anderen - auch die Defaults - gelöscht) funktionierte unter gewissen Umständen nicht korrekt. Keine Ahnung, was in Deiner Anlage hier passiert… ich würde auch eher auf einen Effekt mit dem Router tippen, als auf ein Problem der Anlage.
–gandalf.
Ah ja - jetzt ist das mit dem Port-Bereich klar, bei VoipDiscount konnte ich allerdings keinerlei Angaben finden, d.h. es funktioniert auch ohne Forwardings bestimmter Port-Bereiche.
Bist Du sicher, dass es kein Problem darstellt, wenn der 49151/udp weitergeleitet wird obwohl dieser so wie ich das verstanden habe nicht von der Anlage unterstützt wird, d.h. z.B. Anfragen darüber nicht beantwortet werden ?
“Effekt mit dem Router” ist gut und diplomatisch ausgedrückt - ich schliesse generell gar nichts aus, allerdings können sich sowohl der X-Lite-Softclient von SipGate als auch ein von SipGate erhaltener Netgear V612 VoIP-Router (mit nachträglich aufgesetzter Open-Source Firmware, ging aber auch mit der SipGate-FW) auch dann erfolgreich bei SipGate registrieren, wenn die CB.2 Fehler 503 meldet und wie gesagt CB.2 mit FW2.x macht auch mit SipGate keine Probleme.
Das läßt mich eben doch eher ein Problem der CB.2 mit FW3.x bzw. Netzbetreiber-Probleme oder eine Mischung daraus, bzw. aus allem inkl. dem Gateway vermuten.
Alex
P.S.:
Was ich bez. VoIP-Problemen noch vergessen habe und sich mir als eindeutiger CB.2-Bug darstellt ist, dass eindeutig bestehende VoIP-Verbindungen unter “Belegung ext. Gesprächskanäle” nicht angezeigt werden, d.h. die Anzeige ist immer “grün”, was ich schon vor laaaanger Zeit bemerkte und “reklamierte” - leider hat sich daran immer noch nichts geändert
Das ganze spielt sich übrigens auf dem Mainboard der CB.2 und auf keiner Zusatzkarte ab !