KD Hatte mir eine 3. Rufnummer zugewiesen womit mein Eintrag überschrieben wurde.
Nur als "Warnung" ... sowie KDG irgendetwas an den SIP-Einstellungen per SNMP ändert (das kann sogar das schlichte Bestätigen der alten Einstelluingen sein) und irgendwann findet das garantiert statt, wird vom SNMP-Stack - ich habe zwar noch keine Ahnung, welche OID da die entscheidende Rolle spielt, aber ich tippe auf irgendeine Vendor-Erweiterung - über die Kette aus einem Aufruf von "/bin/pacm_state_changed start/pass/off" seitens pacm_mta_control irgendwann folgendes Lua-Script ausgeführt:
Code:
dofile("/etc/lua/boxhelper.lua");
dofile("/etc/lua/sip.lua");
for i=1,20 do
sip_delete(i);
end
Da wird also ganz schlicht erst einmal jede einzelne der ersten 20 SIP-Nummern gelöscht und hinterher werden die vom Provider "gewünschten" Einstellungen wiederhergestellt.
Das Eintragen eines eigenen SIP-Accounts über die Änderung der Konfigurationsdatei ist also immer nur eine temporäre Angelegenheit. Da die SIP-Accounts mit hoher Wahrscheinlichkeit auch auf dem SNMP-Stack abfragbar sind, kann KDG also auch "sehen", wenn die SIP-Einstellungen verändert wurden (sie brauchen es bloß über ein passendes SNMP-Walk zyklisch abfragen oder bei einem TR-069-Inform-Request seitens der Box per SNMP nachhaken) und entsprechend darauf reagieren.
Da das "Definieren" und das korrekte Aktivieren einer Rufnummer (wie schon bei der 6360, Infos dazu kann man im kdgforum.de finden) zwei verschiedene Stellen bei den Einstellungen sind (Definition in der voip.cfg, Aktivierung irgendwo zusätzlich in einer binären Datei), ist das Verhalten Deiner eigenen Rufnummer anstelle der dritten KDG-Nummer nicht sooo verwunderlich (dafür geht dann eben die dritte KDG-Nummer nicht richtig) und relativ leicht zu erklären.
Die binären Dateien (fx_conf oder telefon_misc) scheinen einen festen Aufbau zu haben. Wenn also da irgendwo steht "aktiviert sind die Nummern sip0 bis sip2" (bzw. das steht mit einiger Sicherheit bei den Einträgen an festen Offsets als Flag irgendwo dabei), dann fällt Deine eigene Nummer wegen des "Einschiebens" zwischen die KDG-Nummern da mit hinein ... aber die letzte KDG-Nummer eben heraus.
Wenn man die vierte (fünfte, sechste, ...) Nummer auch in den binären Einstellungen richtig aktiviert, steht sie auch in den anderen Menüs (soweit die bei KDG-Branding zugänglich sind) zur Auswahl zur Verfügung und die "kosmetischen Probleme" (letzen Endes alles auf den falschen Offset zurückzuführen, der Dir ja auch aufgefallen ist bei den diversen anderen Funktionen) sind auch beseitigt.
Hat jemand eine Ahnung wie man diesen MSN-eintrag ändert?
Es steht - wie gesagt - für die 6360 und auch mit ersten Meldungen von Teilerfolgen für die 6490 - im kdgforum.de, an welchen Stellen das in der binären Form geändert werden müßte. Da das aber immer nur eine temporäre Lösung ist für die ersten 20 Accounts, bleibt es eine wackelige Angelegenheit. Bei ausgehenden Gesprächen bemerkt man es ja vielleicht noch, wenn die Nummer nicht funktioniert (vielleicht aber auch nicht immer und dann telefoniert man eben über eine KDG-Nummer zu wesentlich höheren Preisen im schlechtesten Falle) ... blöd nur, wenn man darüber auch angerufen werden will und es eben nicht bemerkt, daß die Nummer wieder mal gelöscht wurde.
Am Ende braucht eine funktionierende SIP-Rufnummer - vermutlich muß ich schreiben, denn ich nutze die SIP-Telefonie über KDG gar nicht, weil mein "offizieller" Anschluß über die Telekom eine umfassendere Flatrate bietet als der von KDG - folgende Einstellungen (die werden jedenfalls beim "sip_delete" oben mit "leer" überschrieben, wenn der Eintrag nicht komplett gelöscht wird, wie es bei allen Einträgen ab dem dritten der Fall ist):
Code:
sip:settings/sip[COLOR="#FF0000"]X[/COLOR]/activated
sip:settings/sip[COLOR="#FF0000"]X[/COLOR]/displayname
sip:settings/sip[COLOR="#FF0000"]X[/COLOR]/registrar
sip:settings/sip[COLOR="#FF0000"]X[/COLOR]/username
sip:settings/sip[COLOR="#FF0000"]X[/COLOR]/password
sip:settings/sip[COLOR="#FF0000"]X[/COLOR]/stunserver
sip:settings/sip[COLOR="#FF0000"]X[/COLOR]/providername
sip:settings/sip[COLOR="#FF0000"]X[/COLOR]/ID
sip:settings/sip[COLOR="#FF0000"]X[/COLOR]/outboundproxy
telcfg:settings/SIP[COLOR="#FF0000"]Y[/COLOR]/MSN
Die Einstellung "outboundproxy" ist dabei offenbar besonders wichtig, denn sie wird tatäschlich gleich doppelt überschrieben in /etc/lua/sip.lua -> sip_delete. :mrgreen:
Für eine "echte" Eintragung einer eigenen Rufnummer, die dann auch - wieder nur im Rahmen der Menüs, die bei KDG-Branding funktionieren - im GUI normal verwendet werden kann und auch normal angezeigt wird (mit grüner LED bei erfolgreicher Registrierung), muß man also mindestens diese Einstellungen irgendwie setzen. Das dann kombiniert mit dem Verhindern des Löschens (die voip.cfg würde - wieder vermutlich, muß man mal testen - sogar Indizes jenseits von ua20 unterstützen, aber in der binären Struktur ist die Anzahl der Einträge für SIP-Nummern wohl auf diese 20 begrenzt) der eigenen Rufnummer oder zumindest dem automatischen Eintragen der o.a. Settings nach dem Löschen seitens des SNMP-Agents, führt zu einer vollständig funktionsfähigen SIP-Rufnummer, mit der man dann - jenseits der offenbar obligatorischen Festnetz-Flatrate - beim Telefonieren sparen kann.
Ich benutze die SIP-Accounts von KDG ja gar nicht, trotzdem wurde - seitdem ich das mitzähle und das ist erst seit ca. 14 Tagen so - schon 4x das o.a. gezeigte snmp_sip_clean.lua ausgeführt. Damit wäre - ohne passende Vorkehrungen - mir persönlich das definitiv zu unhandlich ... man muß dann wirklich vor jedem Anruf kontrollieren, ob der tatsächlich über den eigenen billigeren SIP-Anbieter geht und nicht über eine - ggf. mehrfach teurere - KDG-Nummer.
Daß das Setzen solcher Einstellungen mangels Telnet-Zugang nicht so ohne weiteres möglich ist, hast Du ja selbst richtig festgestellt ... das oben Geschriebene ist also leider auch nur eine Erläuterung, wie man es anstellen müßte. Es sollte irgendwie tatsächlich auch über das Ändern der exportierten Konfiguration funktionieren, das verhindert allerdings Löschen und Neukonfiguration noch nicht und bleibt damit ein "Notnagel".