Hier wird vieles durcheinander geworfen ... das geht schon bei der Interpretation los, was denn nun in Benutzernamen und Passwort erlaubt ist und was nicht.
Wenn AVM schreibt:
Der Benutzer soll mindestens 8 Zeichen beinhalten und in keinem Fall die Nebenstellennummer drin haben.
, dann ist das sowohl richtig als auch falsch.
Da die FRITZ!Box tatsächlich mind. 8 Zeichen als Benutzername erwartet nach den neuen Richtlinien, kann das "drin haben" sich ja eigentlich nicht auf die komplette Nebenstellennummer beziehen, da das FRITZ!OS nur dreistellige Nebenstellen unterstützt. Andererseits stört es selbst die neueste Labor-Version kein Stück, wenn der Benutzername tatsächlich die Nebenstellennummer
enthält und auch eine erneute Verwendung des Namens des "Telefoniegerätes" interessiert niemanden.
Der folgende REGISTER-Dialog stammt aus einer 113.07.19-irgendwas (also aus der aktuellen Labor-Reihe), das Telefoniegerät heißt "Softphone" und hat die interne Rufnummer 620. Wenn man dem jetzt den Benutzernamen "620Softphone" gibt und dasselbe in einer Phoner-Instanz konfiguriert, funktioniert das ohne jedes Problem, wie man sehen kann ("FB7490" ist der "display name" im Phoner und hat mit dem Hostname der Box nichts zu tun):
Code:
2020-02-11 12:45:06.252 - IN: my=192.168.130.1%14:5060 peer=192.168.168.129 port=64142 TCP, sipiface=none:
REGISTER sip:192.168.130.1 2.0
Via: SIP/2.0/TCP 192.168.168.129:64142;branch=z9hG4bK007fdfe2314bea11a6073e971e599b5d;rport
From: "FB7490" <sip:[email protected]>;tag=48364631
To: "FB7490" <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 REGISTER
Contact: <sip:[email protected]:5060;transport=tcp>;+sip.instance="<urn:uuid:00F58E3F-DC8F-E711-A7B0-4B97BC0B9641>"
Max-Forwards: 70
Allow-Events: org.3gpp.nwinitdereg
User-Agent: SIPPER for phoner
Supported: replaces
Supported: from-change
Supported: gruu
Expires: 900
Allow: INVITE, ACK, BYE, CANCEL, INFO, MESSAGE, NOTIFY, OPTIONS, REFER, UPDATE, PRACK
Content-Length: 0
2020-02-11 12:45:06.255 - OUT: my=(null) peer=192.168.168.129 port=64142 TCP, sipiface=none tcclass=sip_internet, netmark=0:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP 192.168.168.129:64142;branch=z9hG4bK007fdfe2314bea11a6073e971e599b5d;rport=64142
From: "FB7490" <sip:[email protected]>;tag=48364631
To: "FB7490" <sip:[email protected]>;tag=4BC5CEFDE889EB90
Call-ID: [email protected]
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="fritz.box", nonce="DC54C47167933AE8"
User-Agent: FRITZ!OS
Content-Length: 0
2020-02-11 12:45:06.260 - IN: my=192.168.130.1%14:5060 peer=192.168.168.129 port=64142 TCP, sipiface=none:
REGISTER sip:192.168.130.1 2.0
Via: SIP/2.0/TCP 192.168.168.129:64142;branch=z9hG4bK007fdfe2314bea11a6083e971e599b5d;rport
From: "FB7490" <sip:[email protected]>;tag=48364631
To: "FB7490" <sip:[email protected]>
Call-ID: [email protected]
CSeq: 2 REGISTER
Contact: <sip:[email protected]:5060;transport=tcp>;+sip.instance="<urn:uuid:00F58E3F-DC8F-E711-A7B0-4B97BC0B9641>"
Authorization: Digest username="620Softphone", realm="fritz.box", nonce="DC54C47167933AE8", uri="sip:192.168.130.1", response="0173f58437260339e64bdd98f8a4a261", algorithm=md5
Max-Forwards: 70
Allow-Events: org.3gpp.nwinitdereg
User-Agent: SIPPER for phoner
Supported: replaces
Supported: from-change
Supported: gruu
Expires: 900
Allow: INVITE, ACK, BYE, CANCEL, INFO, MESSAGE, NOTIFY, OPTIONS, REFER, UPDATE, PRACK
Content-Length: 0
2020-02-11 12:45:06.263 - OUT: my=(null) peer=192.168.168.129 port=64142 TCP, sipiface=none tcclass=sip_internet, netmark=0:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.168.129:64142;branch=z9hG4bK007fdfe2314bea11a6083e971e599b5d;rport=64142
From: "FB7490" <sip:[email protected]>;tag=48364631
To: "FB7490" <sip:[email protected]>;tag=C1CFA1AC39A19DF0
Call-ID: [email protected]
CSeq: 2 REGISTER
Contact: <sip:[email protected]:5060;transport=tcp>;+sip.instance="<urn:uuid:00F58E3F-DC8F-E711-A7B0-4B97BC0B9641>";expires=300
User-Agent: AVM FRITZ!Box 7490 113.07.19 (Nov 19 2019)
Supported: 100rel,replaces,timer
Allow-Events: telephone-event,refer,reg
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0
Das ist also schon mal eine "urban legend" und man sollte sich einfach mal auf
eine Variante festlegen, die man dann in der FRITZ!Box konfiguriert. Die sollte man dann aber auch beibehalten, wenn sie korrekt ist (was die früheren Versuche mit dem "**NST" schon mal nicht waren) und für eine solche Überprüfung eignet sich praktisch jeder SIP-Client, dessen Konfiguration man sicher beherrscht. Gibt es selbst einen solchen nicht, sollte man noch einmal ein paar Schritte zurückgehen und sich das notwendige Wissen dafür zulegen ... es hilft ungemein bei der Verifikation der eigenen Einstellungen.
Hat man dann einen solchen Account sauber konfiguriert, faßt man den auch nicht sofort wieder an, wenn die Registrierung eines anderen SIP-Clients nicht auf Anhieb klappt ... es sei denn, man will lieber unbekümmert "probieren", bis es (mehr oder weniger zufällig) dann doch mal klappt, anstatt sich systematisch auf die Fehlersuche zu begeben.
Für eine solche Fehlersuche ist ja das Protokollieren der Nachrichten des ATA auf einem Syslog-Server schon mal ein guter Ansatz ... nur muß man dann die angezeigten Informationen eben auch noch richtig interpretieren. Wenn hier offenbar gar keine Reaktion des SIP-Registrars (also der FRITZ!Box) zu sehen ist (das sind ja bisher alles nur REGISTER-Messages per UDP gewesen, keine einzige Antwort und jede Menge Retransmissions), dann muß man sich eben überlegen, woran das wohl liegen könnte und nicht sofort wieder irgendeine Einstellung ändern, ohne zuvor weitere Untersuchungen zu starten.
Denn die nächste Frage wäre es ja, ob die Netzwerk-Pakete die FRITZ!Box überhaupt erreichen ... offenbar funktioniert ja der (HTTP(S)-)Zugriff auf das Gerät und der erfolgt vermutlich auch über die 192.168.178.54. Das legt ja zumindest schon mal nahe, daß das zur Konfiguration verwendete Gerät den ATA erreichen kann. Aber klappt das auch tatsächlich bis zur FRITZ!Box? Um das zu verifizieren, gibt es mind. zwei Möglichkeiten ... entweder man stellt das Transport-Protokoll auf TCP um (dann zeigt ein erfolgreicher 3-Way-Handshake zumindest, daß die Netzwerkkommunikation möglich ist) oder man sieht einfach mal auf der FRITZ!Box nach, ob die Pakete des ATA dort auch tatsächlich ankommen.
Genau dafür gibt es die Support-Daten einer FRITZ!Box, da ist auch ein Protokoll der letzten SIP-Messages und der dazugehörenden Antworten enthalten und erst dann, wenn die REGISTER-Messages des ATA dort auch zu sehen sind, kann man SICHER davon ausgehen, daß diese die FRITZ!Box auch erreichen. Und wenn das so sein sollte, findet man in diesem Protokoll auch gleich die Antwort auf die nächste Frage ... denn die würde ja dann lauten, ob die FRITZ!Box gar keine Antwort sendet (weil sie sich nicht zuständig sieht und dann tatsächlich etwas schmallippig ist, damit sie nicht zuviele Informationen ausposaunt) oder ob diese Antwort jetzt den ATA nicht erreicht. Letzteres kann dann passieren, wenn die FRITZ!Box die Antwort auf dem falschen Interface senden will ... dafür kann es wiederum auch viele Gründe geben. Aber ob das tatsächlich so ist, muß man eben auch erst einmal ermitteln.
Außerdem ist es schon hilfreich, wenn man sich bei den Beschreibungen der eigenen Aktionen nicht auf alte Screenshots mit ebenso alten Anzeigen stützt, sondern zumindest die jeweiligen Veränderungen (angefangen bei der Konfiguration der SIP-Clients in der FRITZ!Box) auch wieder neu dokumentiert ... besonders dann, wenn man das ständig hin und her ändert (hier meine ich explizit die SIP-Anmeldungen).
Denn in den Screenshots in #1 und #2 finde ich den "Registrar-Namen" nirgendwo als "fritz.box" (vielleicht sehe ich ihn ja auch nur nicht - aber bei "Proxy & Registration" steht da in #1 ja noch deutlich die IP-Adresse in BEIDEN Feldern) und auch die REGISTER-Messages mit dem falschen Benutzernamen (**NST) in #7 verwenden die IP-Adresse in der URI. [
BTW ... niemand (wirklich niemand, außer ewigen Opponenten) will Text-Protokolle als Screenshot lesen, denn das geht auch deutlich einfacher und Du kannst ja einfach auch selbst mal versuchen, in Deinen Protokollen (bzw. den Ausschnitten) etwas zu suchen.]
In #22 [
BTW ... man kann solche "Textzeilen" (egal, ob es Protokolle oder Einstellungen sind) wunderbar in einen "CODE"-Block einbetten, dann wird dafür ein Font mit fester Zeichenbreite verwendet und der Inhalt kann in einem (nicht übermäßig hohen) eigenen Bereich gescrollt werden.] sieht man hingegen zwei Einträge:
Code:
[SIP Params]
[...]
REGISTRARIP = '192.168.178.1'
;SHOULDREGISTER is hidden but has non-default value
REGISTRARNAME = 'fritz.box'
und auch im Syslog-Protokoll in #21 steht jetzt "fritz.box" anstelle der IP-Adresse des Registrars. Da mußt Du also noch weitere Änderungen vorgenommen haben - nur sind die m.E. nirgendwo erwähnt und das ist es auch genau, was ich weiter oben meinte.
Wie man aber in meinem CODE-Block oben auch gut sehen kann, versteht die FRITZ!Box es durchaus, wenn man sie als Registrar mit ihrer IP-Adresse in den URIs anspricht ... das wäre dann auch der sichere Weg, denn sie KANN zwar durchaus auch "fritz.box" heißen, muß es aber nicht zwangsläufig.
Und wenn das hier tatsächlich umkonfiguriert sein sollte im FRITZ!OS (zur Konfiguration der FRITZ!Box sind die Informationen mit "dürftig" ja auch noch sehr euphemistisch umschrieben), dann müßte man sich auch nicht wundern, wenn die FRITZ!Box sich im zweiten Versuch ebenfalls als "nicht zuständig" ansieht (beim ersten waren es ja deutlich die falschen Angaben zu den Account-Namen, wenn denen die zwei Sterne aus der internen Rufnummer vorangestellt wurden), selbst wenn hier der Benutzername für den SIP-Account jetzt stimmen sollte. Solange nicht die komplette SIP-URI im REGISTER als "meine" erkannt wird, antwortet die FRITZ!Box in aktuellen Versionen gar nicht erst ... zu den Gründen dafür siehe oben.
Die FRITZ!Box verwendet jedenfalls den angezeigten "Benutzernamen" sowohl für die Authentifizierung (Nachweis der Berechtigung) als auch für die Adressierung (Auswahl des SIP-Accounts und damit letztlich auch der Rufnummern, die mit dem Client verbunden sind) und notfalls muß man den dann auch zweimal eintragen, wenn das Konfigurationsinterface des ATA das so erwarten sollte, daß Account- und Benutzername getrennt angegeben werden.
Aber anhand meines kleinen SIP-Dialogs oben sollte man ja auch ersehen können, was die korrekten Angaben wären (bzw. zumindest welche, die von der FRITZ!Box verstanden werden) und wenn man den ATA erst einmal so konfiguriert hat, daß er dieses Format auch sendet, stellt sich ohnehin wieder die Frage, ob die Pakete die Box tatsächlich erreichen und was mit den Antworten geschieht ... sprich: ob sie überhaupt generiert werden oder ob sie "nur" ihr Ziel auf dem Rückweg dann nicht erreichen.
Jedenfalls muß man schon mal irgendwo in diesen ganzen Versuchen auch einige "Konstanten" haben und nicht ständig nur an allen Stellen herumprobieren, ob es nicht doch noch irgendwie klappen will. Das KANN zwar auch zum Erfolg führen, MUSS es aber nicht zwangsläufig ... und auch wenn SIP-Konfiguration heutzutage eigentlich kein großes Geheimnis mehr ist (selbst wenn das Board hier mal so angefangen hat), kann man immer noch genug dabei falsch machen und mit steigender Anzahl von "Variablen" in so einer Konfiguration (URI, User, Password, Proxy) sinkt die Wahrscheinlichkeit, durch zufälliges Probieren die richtige zu erwischen (wenn man davon ausgeht, daß es nur einen "günstigen" Fall gibt).
Daher bliebe meine Empfehlung, zunächst mal in der FRITZ!Box einen SIP-Client zu definieren und sich von dessen Funktionsfähigkeit zu überzeugen. Dann braucht man den auch erst einmal nicht mehr anzufassen (ja, man SOLLTE das sogar unterlassen) und kann sich bei der Fehlersuche ganz auf die restlichen Einstellungen (das sind noch genug) konzentrieren.