neue Beta für OC 31 LAN v2.55beta

[GK]

ich könnte ja ein paar Web-Cent von meinen auf deinen Account übertragen um das zu beschleunigen, evtl. hilft ja auch einer mit, der dieses Problem hat. Ich hätte da kein Problem mit, brauche da nur deine E-Mail von Web.de und die Postleitzahl

Danke für das Angebot
Ich glaube aber auch kaum, dass das was nützt, da bei mir ja z.B. einkommende Rufe funktionieren. Bei den Betroffenen klappt das ja auch schon nicht.

Vielleicht gibt es ja auch noch eine Differenz in der Konfiguration, ansonsten wäre sicherlich ein Ethereal-Trace eines fehlgeschlagenen Anrufes von einem der Betroffenen hilfreich.

Gruß,
Gunnar

 

[tantehorst]

na Gut, denke auch das da ein Trace eines Betroffenen der nächste Schritt sein sollte.
Wie Geheim sind denn die Änderungen in der 2.55? Frage nur, da die OC noch nie solange ohne irgend ein Fehlverhalten lief.

Schönen Tag noch

 

[GK]

Wie Geheim sind denn die Änderungen in der 2.55? Frage nur, da die OC noch nie solange ohne irgend ein Fehlverhalten lief.

Die Änderungen hatte ich ich doch schon gepostet (http://www.ip-phone-forum.de/showpost.php?p=568122&postcount=15).

Gruß,
Gunnar

 

[tantehorst]

sorry, ist mir irgendwie entgangen.

1000 Danke

 

[markesmith]

web.de und 2.5.5

Hallo,

habe in meiner Konfig den Sip-Proxy von sip.web.de in web.de geändert (nach Konfig Gunnar) mit dem Ergebnis, dass nun gar kein Ruf mehr rausgeht.

markesmith

 

[GK]

habe in meiner Konfig den Sip-Proxy von sip.web.de in web.de geändert (nach Konfig Gunnar) mit dem Ergebnis, dass nun gar kein Ruf mehr rausgeht.

Hallo,

bei web.de muss sowohl für den SIP-Proxy als auch für den SIP-Server sip.web.de eingetragen werden, sonst geht's nicht.

Wenn ich für den SIP-Server web.de eintrage und für den Proxy sip.web.de habe ich genau das beschriebene Fehlverhalten ("Diese Rufnummer ist nicht vergeben", keine einkommenden Rufe. Auch die geposteten SIP Logs passen dazu.
In vorherigen Versionen spielte das keine Rolle, da an einigen Stellen fälschlich der Proxy statt des Servers verwendet wurde.
Jetzt ist es so, dass der SIP-Server korrekt in die SIP-URIs eingetragen wird und daher andere "Rufnummern" entstehen:
SIP-Server: web.de => [email protected]
SIP-Server: sip.web.de => [email protected]
Da [email protected] für web.de offenbar keine korrekte SIP-URI ist, kommt die Ansage.

Gruß,
Gunnar

 

[TheChemist]

Hallo,

bei web.de muss sowohl für den SIP-Proxy als auch für den SIP-Server sip.web.de eingetragen werden, sonst geht's nicht.

Wenn ich für den SIP-Server web.de eintrage und für den Proxy sip.web.de habe ich genau das beschriebene Fehlverhalten ("Diese Rufnummer ist nicht vergeben", keine einkommenden Rufe. Auch die geposteten SIP Logs passen dazu.
In vorherigen Versionen spielte das keine Rolle, da an einigen Stellen fälschlich der Proxy statt des Servers verwendet wurde.
Jetzt ist es so, dass der SIP-Server korrekt in die SIP-URIs eingetragen wird und daher andere "Rufnummern" entstehen:
SIP-Server: web.de => [email protected]
SIP-Server: sip.web.de => [email protected]
Da [email protected] für web.de offenbar keine korrekte SIP-URI ist, kommt die Ansage.

Gruß,
Gunnar

Da ich auch "web.de" als SIP-Server eingetragen hatte, dürfte das auch bei mir die Fehlerursache gewesen sein. Ich werde heute abend mal die 2.55 erneut aufspielen.

MfG
The Chemist

 

[TheChemist]

Bestätigung: 2.55 funktioniert mit web.de

Jetzt habe ich ebenfalls die Fw 2.55 aufgespielt. Mit dem auf sip.web.de geändertem Eintrag für den SIP-Server funktioniert die Firmware auch bei mir mit web.de!

MfG
The Chemist

PS: Damit es schneller ging, habe ich diesmal beim Fw-Update auf das "Rücksetzen in den Auslieferungszustand" (R 8 * PIN # 9 0 0 # ) vor und nach dem Update verzichtet (u. a. muss ich dabei jedesmal auch die IP-Adresse der Anlage und der Netzwerkkarte hin und zurück ändern ...). Inwieweit ist dieses Rücksetzen für einen stabilen Betrieb eigentlich erforderlich, es scheint auch so alles zu funktionieren?

PPS: Noch eine Frage zu Web.de und den Ports, die dafür im Router freigegeben werden müssen:
Da ich nicht auf Dauer im Router alle Ports auf die OC31 freischalten will (über DMZ zur OC31), will ich statt dessen nur für die relevanten Ports die "Virtual Server"-Funktion meines Routers (SMC7004ABR v.2EU) nutzen. Wenn ich dort nur die Ports 5060-5062 und 30000-30005 eintrage (nur UDP), funktioniert "FullCone NAT" noch nicht (weiterhin alles nur über STUN).
Trage ich dort jedoch den gesamten RTP-Port-Bereich von 1025 - 65000 ein (ebenfalls nur UDP), geht Full Cone NAT. Kann man das noch stärker eingrenzen (ohne das ich jetzt alles per "Trial and error" austeste), der Port-Bereich erscheint mir doch recht "üppig", den ich für Full Cone NAT frei geben muss?

 

[markesmith]

jetzt auch bei mir...

Hallo,

ich hatte genau das falsche gemacht, sip.web.de durch web.de ersetzt.
Wie im Screenshot.
Jetzt klappt es endlich auch bei mir.

So long.

markesmith

 

[TheChemist]

Hallo,

ich hatte genau das falsche gemacht, sip.web.de durch web.de ersetzt.
Wie im Screenshot.
Jetzt klappt es endlich auch bei mir.

So long.

markesmith

Wie ich sehe hast Du auch einen Router und "Full Cone NAT". Welche Ports hast Du denn in der Router-Firewall zur OC31 freigegeben?

 

[GK]

PS: Damit es schneller ging, habe ich diesmal beim Fw-Update auf das "Rücksetzen in den Auslieferungszustand" (R 8 * PIN # 9 0 0 # ) vor und nach dem Update verzichtet (u. a. muss ich dabei jedesmal auch die IP-Adresse der Anlage und der Netzwerkkarte hin und zurück ändern ...). Inwieweit ist dieses Rücksetzen für einen stabilen Betrieb eigentlich erforderlich, es scheint auch so alles zu funktionieren?

Hallo,

der Factory-Reset ist mehr eine Vorsichtsmaßnahme, normalerweise braucht man das nicht zu machen. Wenn sich das Format der Einrichtdaten zwischen zwei Versionen ändert, macht die Anlage das i.d.R. selbstständig. In seltenen Fällen kann es sein, dass die Anlage das nicht bemerkt und deswegen empfehlen wir, das grundsätzlich immer zu machen. Der Factory-Reset vor dem Update ist nur dann nötig, wenn man eine so exotische Konfiguration hat, dass das Flashload-Programm die Anlage nicht findet, aber das merkt man dann ja.

Da ich nicht auf Dauer im Router alle Ports auf die OC31 freischalten will (über DMZ zur OC31), will ich statt dessen nur für die relevanten Ports die "Virtual Server"-Funktion meines Routers (SMC7004ABR v.2EU) nutzen. Wenn ich dort nur die Ports 5060-5062 und 30000-30005 eintrage (nur UDP), funktioniert "FullCone NAT" noch nicht (weiterhin alles nur über STUN).
Trage ich dort jedoch den gesamten RTP-Port-Bereich von 1025 - 65000 ein (ebenfalls nur UDP), geht Full Cone NAT. Kann man das noch stärker eingrenzen (ohne das ich jetzt alles per "Trial and error" austeste), der Port-Bereich erscheint mir doch recht "üppig", den ich für Full Cone NAT frei geben muss?

Leider ist es in der OC31 so, dass sie sich beliebige RTP-Ports aussucht (1024-65535). Ob sich das in zukünftigen Firmware-Versionen noch mal ändern wird, vermag ich nicht zu sagen.

Gruß,
Gunnar

 

[TheChemist]

...
Leider ist es in der OC31 so, dass sie sich beliebige RTP-Ports aussucht (1024-65535). Ob sich das in zukünftigen Firmware-Versionen noch mal ändern wird, vermag ich nicht zu sagen.
...

Vielen Dank, gut zu wissen, dass der RTP-Port-Bereich bei meiner aktuellen Router-Konfiguration eigentlich immer noch nicht ausreicht und wohl nur zufällig für "Full Cone NAT" ausgereicht hat (Port 1024 und alle Ports über 65000 fehlen noch in der Freigabe). Ich hätte mich in der Folge sicher über nicht reproduzierbaren gelegentlichen Rückfall in den "STUN"-Modus gewundert ...

MfG
The Chemist

PS: Portforwarding über einen derart großen Range verkraftet mein Router scheinbar nicht: die OC31 läuft damit zwar einwandfrei, aber die DNS-Auflösung für die Internetverbindungen der angeschlossenen PCs verabschiedet sich nach einiger Zeit. Also doch wieder DMZ zur OC31 ...

 

[Ganymo]

OpenCom 31lan Firmware Versionen

Hallo, bei DeTeWe steht die neue Beta 2.55 zum download bereit.

Das Update ging problemlos, mal sehen was es uns bringt.

Schönes Wochenende und besonderen Dank an GK

Hallo,
leider scheinen die vorhereigen Updates für die OC 31lan immer wieder von der DeTeWe Seite heruntergenommen zu werden.
Die Neue Version 2.56 läuft bei mir nicht kein SIP (SIP only- über QSC hinter Lucent Modem).
Daher würde ich gerne die Version 2.53 (soll angeblich für QSC laufen) und 2.55 ausprobieren.
Kann Sie jemand hier in den Downloadbereich uploaden bzw. einen Link angeben wo die Versionen stehen.

Gruß Ganymo

 

[mad79]

Hallo Ganymo,

die 2.55 gibt es noch: http://www.detewe.de/downloads/software/oc31_sint_v255.zip

EDIT:
2.53: www.detewe.de/downloads/software/oc31_sde_v253.zip

 

[HermannB]

Ich habe ziemlich sicher beide noch zuhause gespeichert und kann sie heute abend mailen oder uploaden, wenn es noch aktuell ist - bitte dann PN
HermannB

 

[Ganymo]

Hallo,
besten Dank beide Links scheinen noch aktiv zu sein. Habe versucht die Dateien auch hier unter Downloads TeDeWe OC 31lan Firmware hochzuladen; hat aber irgendwie nicht gefunzt. Da sind nämlich nur ganz alte Firmware Versionen drin. Vielleicht kann es ja einer nochmal probieren für die "Nachwelt" falls die irgendwann die Vorgänger Firmwares vom Server nehmen.
Werde dann wohl erst einmal die 2.53 ausprobieren, die soll angeblich mit QSC funktionieren. Komisch nur, daß man sich dann bei den Folgeversionen wieder verschlechter ;-)...zumindest was QSC betrifft.

 

[GK]

Hallo Ganymo,

wenn Du Interesse hast, kann ich Dir auch eine gefixte 2.56 (aka 2.57) schicken, die befindet sich bei uns zwar noch im Test, sollte aber die QSC-Probleme beheben.
Du müsstest mir dann eine PN mit E-Mail-Adresse schicken.

Gruß,
Gunnar

 

[Ganymo]

OpenCom 31lan mit Firmware 2.55 und QSC funktioniert

Hallo die Verbindungsabbrüche nach 2 Minuten sind gefixt und Telefonie läuft mit QSC und OpenCom 31lan jetzt ohne Probleme. Allerdings geht immer noch keine Durchwahl und Rufumleitung. Laut Beschreibung von DeTeWe soll das angeblich auch bei Betreib der Anlage ausschließlich über VOIP funktionieren. Bekomme bei mir allerdings nur ein Freizeichen , dann Call Pickup und dann nur "Leere". Auch die Eingabe des Pincodes ändert daran nichts. Gibt es da eine Lösung bzw. hat es schon jemand geschafft eine Durchwahl (Anlage ohne ISDN Anschluß- VOIP only) hinzubekommen. Wenn ja mit welcher Firmware/Konfiguration?

Gruß Ganymo

P.S.Auch sipgate funktioniert die Konfiguration für DeTeWe OpenCom 31lan und viel andere Anlagen ist unter sipgate.de mit Screenshots aufgeführt.

 

[GK]

Hallo Ganymo,

meinst Du die QSC-proprietäre SIP-Durchwahl?
Die wird die OC31 auch nie unterstützen, da Durchwahl grundsätzlich nicht unterstützt wird (also z.B. auch kein ISDN-Anlagenanschluß).
Oder meinst Du Call-Through von SIP zu SIP? Das sollte funktionieren.
Die größeren DeTeWe-Anlagen (OC100/OC1000) werden das soweit ich weiss in näherer Zukunft können.

Rufumleitung sollte intern eigentlich gehen, nur nicht extern beim SIP-Provider.

Gruß,
Gunnar

 

[Ganymo]

SIP zu SIP Telefonie Call-Through

Hallo Ganymo,

meinst Du die QSC-proprietäre SIP-Durchwahl?
Die wird die OC31 auch nie unterstützen, da Durchwahl grundsätzlich nicht unterstützt wird (also z.B. auch kein ISDN-Anlagenanschluß).
Oder meinst Du Call-Through von SIP zu SIP? Das sollte funktionieren.
Die größeren DeTeWe-Anlagen (OC100/OC1000) werden das soweit ich weiss in näherer Zukunft können.

Rufumleitung sollte intern eigentlich gehen, nur nicht extern beim SIP-Provider.

Gruß,
Gunnar

Hallo Gunnar,
ja habe zuvor mit ISDN und SIP auf meiner Fritzbox ein Callthrough, d.h. mit ISDN Rufnummer rein, Signalton abwarten und über SIP Nummer wieder rauswählen, hinbekommen.
Über 2 SIP Nummern d.h. SIP rein, Signalton, Code eingeben, Nummer wählen SIP raus scheint es nicht zu funktionieren, weder bei der Fritzbox noch bei der OpenCom 31lan. Habe auch schon die Kombination von 2 verschiedenen SIP Anbietern versucht, ebenso ist die Zahl der max. Verbindungen in der Anlage auf 4 gesetzt, aber trotzdem klappt es irgendwie nicht.

Gruß

Ganymo