ich wuerde vorschlagen falls mir jemals ein Fall ueber den Weg laufen sollte, bei dem es jemandem gelungen ist sein eigenes SIP-Phone (oder gar einen Asterisk) erfolgreich mit den VF SIP Servern zu verbinden, dann poste ich es hier. Sorry wenn das noch ein paar Monate dauern koennte
Na ja ... zumindest für abgehende Gespräche mußt Du da ja nicht lange suchen:
http://www.ip-phone-forum.de/showthread.php?t=286199
Wie das jetzt nach dem 01.08. aussieht, kannst Du ja Deinerseits "abfragen" ... ist zwar offensichtlich kein DOCSIS-Anschluß dort, aber es dürfte das oben stehende Zitat (da steht mal nichts von Kabel oder DOCSIS) zumindest in einer Richtung schon mal "abdecken". Wenn man dann dort weiterliest, dürfte das Problem der eingehenden Anrufe mit dem Timeout der UDP-"Verbindung" im CT zusammengehangen haben und es funktioniert mittlerweile auch für eingehende Gespräche.
Ich verstehe trotzdem immer noch nicht (und ich habe definitiv mit keinem KNB irgendetwas zu tun, daß ich deren Vorgehen jetzt irgendwie verteidigen/unterstützen müßte), warum man eine Schnittstellenbeschreibung - die auf ETSI-Standards zurückgreift (auch wenn diese wieder auf den DOCSIS-Standards von CableLabs basieren) - dafür verantwortlich macht, daß der Handel mit passenden Geräten nicht in Schwung kommt oder die Hersteller hier nicht in die Gänge kommen.
Die EuroPacketcable-2.0-Spezifikation für E-DVA ist aus dem Jahr 2012 (also nun nicht erst vor kurzer Zeit erschienen) und auch der überwiegende Teil der DOCSIS 3.0-Spezifikation (auch
EuroDOCSIS 3.0) wurde 2009 das letzte Mal so richtig überarbeitet (zumindest so, daß es Auswirkungen auf Hardware haben könnte). Warum es also (bisher) so wenige Geräte gibt, die diesen älteren Standards entsprechen, wissen wohl tatsächlich nur die Hersteller ... andererseits war Deutschland nun auch nicht gerade ein Markt, wo man ohne entsprechende Verbindungen zu einem Provider seine Geräte vor dem 01.08. absetzen konnte und - nur mal nebenbei bemerkt - die in D jetzt eingezogene "Routerfreiheit" ist auch in anderen (europäischen) Ländern bei weitem noch nicht überall so angekommen, daß sich da tatsächlich ein größerer Markt ergäbe.
Das ändert aber nichts daran, daß es entsprechende Geräte gibt ... ein Beispiel für ein "Nur-Modem", welches die Anforderungen "wuppen" sollte, wäre das
Hitron CDA-32372. Warum das kein deutscher Distributor im Angebot hat (wenn das tatsächlich so sein sollte, daß es in D nicht vertrieben wird), müßtest Du dann "den Handel" fragen - willst Du das auch einem KNB anlasten?
OT/Verschwörungstheorie: Vielleicht haben die ja auch einen leitenden Beamten der Generalzolldirektion mit irgendwelchen Kompromaten so weit unter ihrer Kontrolle (der unvorsichtigerweise illegale Inhalte über einen VF-Anschluß geladen hat und das wurde dann vom Betreiber im Rahmen der "Netzwerk-Administration" mitgeschnitten), daß jetzt der Zoll alle Container mit derartigen Geräten schon bei der Einfuhr in D besonders gut unter die Lupe nimmt? Aber das CDA-32372 hat sogar ein CE-Kennzeichen ... :gruebel: ... aber BTT.
Wo wurde eigentlich bisher berichtet, daß VF solche Geräte nicht akzeptiert, wenn sie die Spezifikationen einhalten? Das glaube ich schon deshalb nicht, weil das tatsächlich ein Grund für eine Beschwerde bei der BNetzA wäre - alles bisher Verlinkte, wo sich jemand über die Probleme aufregt und mit der BNetzA droht (im
VF-Forum, hier ist die Verschwörungstheorie von Jule-2016 im dritten Beitrag schon richtig "putzig"), ist reiner "Theaterdonner" - spätestens beim Aufzeigen der eigenen Fehler fällt so etwas i.d.R. in sich zusammen.
Hinter diesem Modem sollte sich jedenfalls auch problemlos ein Asterisk-Server betreiben lassen ... wenn es auch noch "ein Router" sein soll, muß der eben auch das Routing mit übernehmen. Die DOCSIS-Spezifikation legt fest, welche Interfaces und Steuerungsmöglichkeiten ein CM auf der CPE-Seite anbieten darf ... wenn Du auch in einem "non-embedded"-Gerät damit klarkommen solltest, kannst Du das auch entsprechend umsetzen.
Aber wieder kannst Du nicht die KNB für den Inhalt der Standards verantwortlich machen (was aus einem CM "rauskommen" darf), die haben diese auch nicht erst "verabschiedet", als die Möglichkeit der Routerfreiheit sich am Horizont zeigte - damit ist die Vermutung, die wären nur dazu erdacht worden, dem deutschen Kunden seine Routerfreiheit gründlich zu vermiesen, irgendwie auch absurd, oder?
Da es in einem eDOCSIS-Gerät nun mal bessere Möglichkeiten der Interaktion/Integration für eCM und eSAFE gibt, wird so ein "AIO" trotzdem immer mehr Möglichkeiten bieten, die man bei der Verteilung von Funktionen auf mehrere Geräte mühsam nachbauen muß und im Extremfall auch niemals so weit integriert hinbekommt, wie es bei einem eDOCSIS-Gerät der Fall sein kann.
Wenn der Asterisk-Server so konfiguriert ist, daß er ausschließlich mit den öffentlichen IP-Adressen des Anschlusses arbeitet in den relevanten SIP-Headern und den SDP-Attributen in entsprechenden Nachrichten, dann sollte das auch funktionieren - ist das nicht so und Du stellst es fest, solltest Du es hier zur Diskussion stellen, damit man (ggf. gemeinsam) an einer Lösung arbeiten kann bzw. wenigstens eine Erklärung dafür findet. Solange es solche "Probleme" nur auf der Basis von "Hörensagen" gibt, ist das genauso mühsam, wie einen Pudding an die Wand zu nageln.
BTW ... schon die Möglichkeit, daß ein (sendender) Kunde mit irgendwelchen LAN-Adressen aus reservierten Netzwerksegmenten (nach RFC) in SIP-Messages an den Provider hantiert, ist normalerweise ein "no go" - hinter einem Stream-"Angebot" mit einer IP-Adresse aus 192.168.0.0/16 kann sich beim Angerufenen schon wieder ein ganz anderer Endpoint verbergen, der im Extremfall den Adressaten über eine Lücke in der RTP-Implementierung angreifen könnte (allerdings könnte das auch der Absender direkt sein, trotzdem würde z.B. ein IPS/IDS bei einem Zugriffsversuch eines nicht-autorisierten Clients aufgrund irgendeiner sinnfreien SDP-Entity auch Alarm schlagen) und da fallen mir noch genug andere Gründe ein, warum eine (von extern kommende) IP-Adresse im LAN von einem Client nicht genutzt werden dürfte.
Wenn hier der Provider bereits einen Riegel vorschiebt und tatsächlich in den SIP-Headern nur korrekte IP-Adresssen zuläßt (das kann ich noch nicht einmal wirklich glauben, auch das Papier der Schnittstellenbeschreibung ist geduldig und solche "Sperren" sind m.E. bisher noch von niemandem
nachgewiesen worden), dann finde ich das tatsächlich überraschend vorausschauend und vielleicht erfolgt ja irgendwann tatsächlich einmal eine entsprechende Filterung. Vielleicht wird so etwas auch erst später erforderlich, wenn es neue (bisher unbekannte) Angriffe auf Lücken im SIP-Protokoll geben sollte ... auch hier gilt wieder, daß ein schon heute festgeschriebenes (und begründbares) Verhalten - selbst wenn es noch gar nicht "forciert" wird - spätere Änderungen der Schnittstellenbeschreibungen (die dann ggf. zu Inkompatibilitäten älterer Geräte und damit zu Streitigkeiten, wer für den Austausch/die Aktualisierung nun verantwortlich ist und die Kosten zu tragen hat, führen) zumindest unwahrscheinlicher (weil seltener notwendig) machen kann.
EDIT: Ich habe gerade gesehen, daß für das CDA-32372 im Datasheet tatsächlich nur "CW93
planned" steht ... wenn das (immer noch - das Gerät ist aus 2012) keine Zertifizierung haben sollte, kann aber VF auch wieder nichts dafür - auch das ist Sache der Hersteller und eigentlich nicht erst seit der Einführung der Routerfreiheit in D "best practice", auch wenn so eine Zertifizierung recht teuer ist und sich damit wohl nur lohnt, wenn der Forecast paßt.
- - - Aktualisiert - - -
Hier findet man - nebenbei bemerkt - ein Sheet mit den zertifizierten Geräten von CableLabs und
hier die Liste der Geräte, die über Excentis geprüft wurden und dann die Zertifizierung erhalten haben. Da steht auch die 6490 drin und auch ein paar ältere Modelle von AVM (hat jemand schon mal etwas von einer 6440 (HWRev 199) gehört im Jahr 2013?), die dann wohl auch zumindest von Excentis getestet wurden. Bei CableLabs taucht aber nur die 6490 auf, nun kann man spekulieren, warum AVM die anderen dort vielleicht nicht eingereicht hat - bisher war das im geschlossenen Ökosystem der KNB wohl nicht erforderlich.
Nach der "Öffnung des Marktes" ist es nun eben anders ... wenn bisher nur finanzielle Erwägungen die anderen Hersteller von der Zertifizierung abgehalten haben sollten (von Hitron taucht tatsächlich nur das CGNV4 bei CableLabs auf und das auch nur in der Version für EPC 1.5) und keine tatsächlichen Inkompatibilitäten, dann sollte das ja irgendwann auch mal kommen - zumindest dann, wenn sich ein Hersteller hier einen Markt verspricht.
Und machen wir uns nichts vor ... es geht hier um ein (vielleicht zwei oder drei) Prozent der Kunden der Provider in Deutschland, die sich überhaupt mit so einem Thema beschäftigen würden oder wollen.
Wenn AVM nicht auch bei anderen Geräten einen (noch?) relativ guten Ruf hätte (egal, ob man AVM mag oder nicht, die Tatsache kann man nun mal nicht leugnen) oder einige Funktionen der Firmware (deren "Anstoß" ja durchaus auch hier im IPPF erfolgt sein könnte - das "Bierholen" legt zumindest nahe, daß da mal gelesen wurde) einen Mehrwert versprechen würden (ob sie den immer und unter allen Umständen auch bieten können, ist gar nicht die Frage, es geht um den "durchschnittlichen Kunden" und der bringt die wirklichen Umsätze), dann würde sich das wohl auch für AVM nicht wirklich lohnen.
Aber hier kommt dann wohl auch wieder die Kombination mit anderen Geräten (DECT-Telefone, AHA) hinzu, die anderen Herstellern "abgeht".
Ich persönlich halte das ja bekanntlich auch für einen Irrweg, Home-Automatisierung über DECT zu betreiben ... aber offensichtlich funktioniert es ja zumindest (leidlich) und auch das muß man ggf. aus der Perspektive des Kunden sehen, der keine Ahnung hat und froh ist, wenn sein DECT200 "auf Knopfdruck" an und aus geht.
Daß der am Ende auch beim Wechsel der Internet-Anbindung (von Kabel über DSL bis Fiber) wieder in einer Abhängigkeit von AVM steckt, wenn er seine DECT-Geräte weiterverwenden will, geht den meisten ohnehin erst zu spät auf ... oder es stört sie auch ganz einfach nicht.
Wer mit der Funktion zufrieden ist, greift immer wieder gerne zu ... deshalb sind ja auch "Skandale" wie der "webcm"-Bug so "schädlich" für das Image eines Herstellers.
Beim "normalen Kunden" bleibt ja nicht das tatsächliche Problem und dessen Auswirkungen im Gedächtnis, sondern das Geschrei, daß sich daraufhin erhebt und der Zusammenhang mit dem Namen "AVM" und der Marke "FRITZ!Box" - da werden selbst lächerliche und/oder längst behobene Probleme im Anschluß schnell erneut zu einem Aufhänger für alle möglichen Mutmaßungen, wie wir anhand der letzten "Warnung vor Rufnummernmißbrauch" mal wieder sehr schön beobachten konnten.
Auch da reichte das Gedächtnis der Leute genau bis zum "webcm"-Bug zurück (selbst bei einigen "Fachredakteuren") ... über den "UPnP-Bug" (eine Petitesse, wo nur der Sohn die Pornos von Papa sehen konnte, wenn der sie über die FRITZ!Box gespeichert hatte - eigentlich war es nur der Zugriff auf NAS-Inhalte über den Media-Server, der ohne Authentifizierung möglich war (und nur aus dem LAN!)) redete da schon niemand mehr, obwohl der durchaus noch ein Thema war, als alle über die Ursache des "webcm"-Bugs (bzw. der dadurch möglichen Angriffe) sich den Kopf zerbrachen.
Nach dem nächsten "Skandal" redet dann kein Mensch mehr über "webcm" ... ist ja ohnehin nicht mehr vorhanden (und deshalb "lückenlos") in neueren Versionen.
