Probleme bei der Anschaltung / Registrieren eines audiocodes ATA MP-112 an eine Fritzbox 7490

dirktelefon

Neuer User
Mitglied seit
4 Feb 2020
Beiträge
11
Punkte für Reaktionen
0
Punkte
1
Liebe Forum-Kollegen,

ich haben Problme bei der Registrierung von einem oder zweier a/b-Ports des Mediapacks MP-112.
Wer kann mir helfen?
Ich habe an der Fritzbox einen SIP-Telefonaccount intern angelegt, die Passwortrichtlinien wie bei Fritz eingehalten.

Leider schaffe ich es nicht die a/b-Schnittstelle an der Fritz Box zu registrieren und zu betreieben.

Ich stelle hier mal ein paar screenshots ein.

Für Eure Hilfe besten Dank vor ab!
Beiträge zusammengefügt - HabNeFritzbox
...noch weitere Screenshots
 

Anhänge

  • 1.JPG
    1.JPG
    132.6 KB · Aufrufe: 36
  • 2.JPG
    2.JPG
    153.7 KB · Aufrufe: 34
  • 3.JPG
    3.JPG
    151.3 KB · Aufrufe: 32
  • 4.JPG
    4.JPG
    189.9 KB · Aufrufe: 33
  • 5.JPG
    5.JPG
    188.9 KB · Aufrufe: 31
  • 6.JPG
    6.JPG
    186.1 KB · Aufrufe: 29
  • 7.JPG
    7.JPG
    189.9 KB · Aufrufe: 30
  • 8.JPG
    8.JPG
    189.7 KB · Aufrufe: 29
  • 9.JPG
    9.JPG
    191.9 KB · Aufrufe: 30
  • 10.JPG
    10.JPG
    181.7 KB · Aufrufe: 28
  • 11.JPG
    11.JPG
    146.3 KB · Aufrufe: 26
  • 13.JPG
    13.JPG
    144.3 KB · Aufrufe: 26
  • 12.JPG
    12.JPG
    220.4 KB · Aufrufe: 25
  • 14.JPG
    14.JPG
    225.5 KB · Aufrufe: 24
  • 15.JPG
    15.JPG
    235.8 KB · Aufrufe: 26
  • 16.JPG
    16.JPG
    173.9 KB · Aufrufe: 27
Zuletzt bearbeitet von einem Moderator:
Ich habe es erlebt, dass die Fritzbox nach zu vielen vergeblichen Registierungsversuchen Zugänge auch mal gesperrt hat.
Ich habe etwas Erfahrung mit dem M800B, da ist es so, dass du nicht zwingend über Proxy Sets gehen musst, sondern du global SIP-Parameter einstellen kannst. Das Gateway versucht sich dann, über die Telefonnummern an der Gegenstelle zu registrieren.
Contact User sollte gesetzt sein.
Schau mal, ob du eine neuere Firmware bekommst, die scheint schon recht alt zu sein.
Zum Testen ist eine Fritzbox eigentlich nicht so geeignet, da nicht vernünftig debugbar.
Ansonsten guck dir das Log an (ggf. Loglevel hochdrehen), ob das Gateway zumindest versucht, sich zu registrieren oder ob es daran schon scheitert.
 
Hi Danke für die Antwort,

das mit dem Proxy hatte ich auch schon im Verdacht, wie müsste es den ohne Proxy Set gehen?
Die FW ist eigentlich aktuell, ich habe noch eine neuere die kann aber kein Impulswahl, das ich jedoch dringend benötige.

Den Syslog haben ich auch schon laufen lassen da sieht man das eine Registrierung versucht wird, aber von FB keine Registrierung druchgeführt wird.
Mein Problem ist das es überhaupt keine Fehlermeldung im Syslog gibt.
Ich bin am verzeifeln.
Kannst Du mir eine Einstellhilfe bei der Konfig ohne Proxy geben ?
 
Sicher mit der Impulswahl?

Wenn das Gateway sich zu registrieren versucht ist doch schon alles gut. Dann stell' mal ein Log-Ausschnitt zur Verfügung.
Beiträge zusammengefügt - HabNeFritzbox
PS: Ich meine mich zu erinnern, dass die Fritzbox auch gerne mal "dicht" macht, wenn es zu viele ungültige Anmeldeversuche gegeben hat. Ich hatte den Fall mal und das ließ sich nur mit Neustart der Box beheben.
 
Zuletzt bearbeitet von einem Moderator:
Hallo Sunnyman,

hier ein Log meines Audiocodes MP 112.
Es wurden zwei Rufnummern in der Fritzbox konfiguriert, Rufnummer 626 und 627LOG REg Rufnummer 626 und 627.JPG
 
Das was du als Username hast (**626 bspw.) kann nicht korrekt sein für eine FritzBox mit ansatzweiese aktueller Firmware. * würde ich vorsichtshalber eh vermeiden.
Du siehst eindeutig, dass das Audiocodes keine Antwort von der Fritzbox bekommt, es macht ja sogar Retransmits.
Selbst bei alten FritzOS!-Versionen war der Anmeldename eigentlich immer nur die Rufnummer, ohne **. guck für die Teilnehmer mal im Tab Anmeldedaten nach, ansonsten würde ich empfehlen:
- Teilnehmer in der Fritzbox löschen und neu anlegen
- Fritzbox neu starten
 
Schaumal, das hatte mir die Firma AVM als Info zu meinem Ticket geschickt
 

Anhänge

  • AVM.JPG
    AVM.JPG
    56.7 KB · Aufrufe: 24
Dann mach das doch einfach ?!
 
Leider ist diese Antwort von AVM auch nicht korrekt, da ich als Login nämlich "1audio007" und "1audio008" genommen habe, dies wird aber im Log garnicht angezeigt.
 

Anhänge

  • Login am MP112.JPG
    Login am MP112.JPG
    25.9 KB · Aufrufe: 12
Doch, die Antwort von AVM ist korrekt, das zeigt das Log sehr klar. Dann musst du das Audiocodes durchforsten, irgendwo muss er sich die alten Daten noch her holen. Kann auch sein, dass er bestimmte Änderungen erst nach Schreiben ins Flash & Neustart übernimmt.
 
So ganz habe ich es nicht verstanden.

Folgende Daten habe ich in beiden Geräten hinterlegt:
Rufnummer 626 und 627 in Fritz ist es **626 und **627

zwingend muss ein Login bei der aktuellen FW für den Account in der Fritzbox hinterlegt werden, diese sInd "1audio007" und "1audio008", wenn dieser Logins in der Fritzbox die Rufnummern wären, würde es nicht akzeptiert werden von der Fritzbox.

Und dann natürlich das PW, welches den PW Regularien der Fritzbox entspricht, sonst konfiguriert er den account nicht.

Wo müsste ich im Log eigentlich das Login "1audio007" sehen? vielleicht liegt da der Fehler vor.
 
So ganz habe ich es nicht verstanden.
Das glaube ich auch :)
Folgende Daten habe ich in beiden Geräten hinterlegt:
Rufnummer 626 und 627 in Fritz ist es **626 und **627
Rufnummer != Authentifizierung.

zwingend muss ein Login bei der aktuellen FW für den Account in der Fritzbox hinterlegt werden, diese sInd "1audio007" und "1audio008", wenn dieser Logins in der Fritzbox die Rufnummern wären, würde es nicht akzeptiert werden von der Fritzbox.
Jein. Das war schon immer so, Nur seit mehreren Jahren muss man in der Fritzbox zwingend explizit einen Usernamen vergeben, der an Regeln gebunden ist. Gleiches gilt für das Passwort.

Die Audiocodes müssten normalerweise die Rufnummern überhaupt nicht kennen müssen. Die Signalisierung läuft bei SIP auf der Basis der Authentifizierung, also Usernamen ab. Und wenn du beide FXS-Ports sich getrennt registrieren lässt, kann das Gateway das ja auch problemlos auseinander halten.
Wo müsste ich im Log eigentlich das Login "1audio007" sehen? vielleicht liegt da der Fehler vor.
Im SIP REGISTER. From, To, Contact sind alle offenbar inkorrekt.
 
Also habe gerade nochmal in Fritzbox geprüft, es ist nicht möglich eine Rufnummer im Feld Anmeldedaten bei der Fritzbox zu hinterlegen. Sorry geht nicht.
Die Anmeldedaten müssen im Minimum acht Zeichen sein. Es gibt keine Möglichkeit das zu ändern auf der Fritzbox.

Was Du sagst ging vor zwei oder drei Jahren mal mit einer alten FW, die haben irgendwann das gändert, ich habe sogar ein Polycom Telefon nach den alten Konfigdaten also Login = Rufnummer noch in betrieb, will ich das ändern, so wird sofort der Login Name in der neuen Syntax gefordert midestens 8 Zeichen usw.

Leider habe ich das PW des Polycom Telefons nicht mehr, sonst hätte ich den Audiocodes mal testhalber über diesen Account registriert.

Das schneit das Problem zu sein.
 
In Bild 8 und 9 fehlt Username und Password.
 
Ich dachte das wird nur benötigt wenn der ATA komplett mit einem Login registriert wird, dann kann ich die a/b Ports als Sammelgruppe einsetzen.
Zumindestens werden im LOG auch die einzelnen Daten der zwei Ports übertragen.
Diese art der Registrierung wird auch in einem Youtube Video so erklärt.
 
Bitte lies' meine Antworten sorgfältig und reagiere/antworte auf meine Tipps, bevor du weitere Schlussfolgerungen ziehst.
Noch einmal:
Also habe gerade nochmal in Fritzbox geprüft, es ist nicht möglich eine Rufnummer im Feld Anmeldedaten bei der Fritzbox zu hinterlegen. Sorry geht nicht.
Das ist genau dein Problem. Wie ich bereits schrieb: Rufnummer ist nicht Authentifizierung. Dein Gateway versucht aber - unzweifelhaft und durch den AVM-Support bestätigt - sich mit der Rufnummer als Username an der Fritzbox zu registrieren (**626 / **627).

Das ist sowieso merkwürdig, denn meines Wissens nach war das *nie* ein gültiger Username für die Fritzbox. Die Rufnummer ist 626 bzw. 627, "**" ist die Fritzbox-eigene Kennziffer für Internruf.

Wenn du sicher bist, dass du deine Usernamen "1audio007" etc. im Audiocodes bereits richtig hinterlegt hast, dann ist die Konfig. evtl. noch nicht persistent gespeichert und/oder das Gateway muss mal neu gestartet werden (s.o.).

Falls da alles OK ist, brauchst du ja einfach nur die Stelle(n) suchen, wo jetzt noch "**626" steht und da 1audio... etc. rein zu schreiben.
Die Anmeldedaten müssen im Minimum acht Zeichen sein. Es gibt keine Möglichkeit das zu ändern auf der Fritzbox.
Ich habe auch nichts gegenteiliges behauptet. Nochmal der Hinweis: Rufnummer und Username sind zwei verschiedene Dinge, dein Audiocodes setzt aber REGISTER-Nachrichten mit einer Rufnummer als Identifikator ab.
Was Du sagst ging vor zwei oder drei Jahren mal mit einer alten FW, die haben irgendwann das gändert
Das meinte ich, als ich schrieb:
Nur seit mehreren Jahren muss man in der Fritzbox zwingend explizit einen Usernamen vergeben
Aus Kompatibilitätsgründen wurden User nach dem nicht mehr gültigen Schema beibehalten, damit die IP-Endgeräte an einer Fritzbox nach Firmwareupdate weiter laufen. Nur wenn man sie jetzt anfasst, muss man das gültige Schema verwenden. Das stimmt soweit.

Vielleicht hilft es dir, wenn du die Konfig des Audicodes mal als Datei exportierst, da kannst du dann per Texteditor drin suchen.
 
In welchem Bild sind denn die Einträge für dieses Login zu sehen?
Hallo und guten Morgen,

Das Login und PW wird auf Bild 13 gezeigt.
Ich hatte das Login nochmals verändert, es ist jetzt "Audiocodes"
Beiträge zusammengefügt - HabNeFritzbox
Bitte lies' meine Antworten sorgfältig und reagiere/antworte auf meine Tipps, bevor du weitere Schlussfolgerungen ziehst.
Noch einmal:

Das ist genau dein Problem. Wie ich bereits schrieb: Rufnummer ist nicht Authentifizierung. Dein Gateway versucht aber - unzweifelhaft und durch den AVM-Support bestätigt - sich mit der Rufnummer als Username an der Fritzbox zu registrieren (**626 / **627).

Das ist sowieso merkwürdig, denn meines Wissens nach war das *nie* ein gültiger Username für die Fritzbox. Die Rufnummer ist 626 bzw. 627, "**" ist die Fritzbox-eigene Kennziffer für Internruf.

Wenn du sicher bist, dass du deine Usernamen "1audio007" etc. im Audiocodes bereits richtig hinterlegt hast, dann ist die Konfig. evtl. noch nicht persistent gespeichert und/oder das Gateway muss mal neu gestartet werden (s.o.).

Falls da alles OK ist, brauchst du ja einfach nur die Stelle(n) suchen, wo jetzt noch "**626" steht und da 1audio... etc. rein zu schreiben.

Ich habe auch nichts gegenteiliges behauptet. Nochmal der Hinweis: Rufnummer und Username sind zwei verschiedene Dinge, dein Audiocodes setzt aber REGISTER-Nachrichten mit einer Rufnummer als Identifikator ab.

Das meinte ich, als ich schrieb:

Aus Kompatibilitätsgründen wurden User nach dem nicht mehr gültigen Schema beibehalten, damit die IP-Endgeräte an einer Fritzbox nach Firmwareupdate weiter laufen. Nur wenn man sie jetzt anfasst, muss man das gültige Schema verwenden. Das stimmt soweit.

Vielleicht hilft es dir, wenn du die Konfig des Audicodes mal als Datei exportierst, da kannst du dann per Texteditor drin suchen.


Hallo, ich habe nun die Einstellungen verändert, so dass nun das Login "Audiocodes", das steht nun anstelle der Rufnummer, anbei ein Syslog.
Beiträge zusammengefügt - HabNeFritzbox
Code:
Hier der INI. File:
;**************
;** Ini File **
;**************
;Board: MP-112 FXS
;Board Type: 56
;Serial Number: 3401939
;Slot Number: 1
;Software Version: 6.60A.359.001
;DSP Software Version: 204IM3=> 660.15
;Board IP Address: 192.168.178.54
;Board Subnet Mask: 255.255.255.0
;Board Default Gateway: 192.168.178.1
;Ram size: 32M   Flash size: 8M
;Num of DSP Cores: 1  Num DSP Channels: 4
;Profile: NONE
;License Key limits aren't active full features capabilities are available !;
;----------------------------------------------
[SYSTEM Params]
DNSPriServerIP = 192.168.178.1
SyslogServerIP = 192.168.178.27
EnableSyslog = 1
;VpFileLastUpdateTime is hidden but has non-default value
LDAPSEARCHDNSINPARALLEL = 0
[BSP Params]
PCMLawSelect = 3
[Analog Params]
EnablePulseDialDetection = 1
[ControlProtocols Params]
AdminStateLockControl = 0
[MGCP Params]
[MEGACO Params]
EP_Num_0 = 0
EP_Num_1 = 1
EP_Num_2 = 1
EP_Num_3 = 0
EP_Num_4 = 0
[Voice Engine Params]
CallProgressTonesFilename = 'call_progress_germany3_6.0.dat'
IdlePCMPattern = 85
[WEB Params]
LogoWidth = '208'
HTTPSCipherString = 'RC4:EXP'
[SIP Params]
MAXDIGITS = 20
ISPROXYUSED = 1
ISREGISTERNEEDED = 1
GWDEBUGLEVEL = 5
;ISPRACKREQUIRED is hidden but has non-default value
ISUSERPHONE = 0
REGISTRARIP = '192.168.178.1'
;SHOULDREGISTER is hidden but has non-default value
REGISTRARNAME = 'fritz.box'
USETELURIFORASSERTEDID = 1
ENABLEPCHARGINGVECTOR = 1
ENABLEVMURI = 1
ENABLEPASSOCIATEDURIHEADER = 1
REGISTRARTRANSPORTTYPE = 0
MSLDAPPRIMARYKEY = 'telephoneNumber'
USEPROXYIPASHOST = 1
[IPsec Params]
[SNMP Params]
[ DspTemplates ]
;
;  *** TABLE DspTemplates ***
; This table contains hidden elements and will not be exposed.
; This table exists on board and will be saved during restarts.
;
[ \DspTemplates ]
[ TrunkGroup ]
FORMAT TrunkGroup_Index = TrunkGroup_TrunkGroupNum, TrunkGroup_FirstTrunkId, TrunkGroup_FirstBChannel, TrunkGroup_LastBChannel, TrunkGroup_FirstPhoneNumber, TrunkGroup_ProfileId, TrunkGroup_LastTrunkId, TrunkGroup_Module;
TrunkGroup 0 = 0, 255, 1, 1, "Audiocodes", 0, 255, 255;
[ \TrunkGroup ]
[ ProxyIp ]
FORMAT ProxyIp_Index = ProxyIp_IpAddress, ProxyIp_TransportType, ProxyIp_ProxySetId;
ProxyIp 0 = "192.168.178.1", 0, 0;
[ \ProxyIp ]
[ TxDtmfOption ]
FORMAT TxDtmfOption_Index = TxDtmfOption_Type;
TxDtmfOption 0 = 4;
[ \TxDtmfOption ]
[ Authentication ]
FORMAT Authentication_Index = Authentication_UserId, Authentication_UserPassword, Authentication_Port, Authentication_PortType;
Authentication 0 = "Audiocodes", "$1$/85BbWFicGBqNzg+", 1, "FXS";
[ \Authentication ]
[ ProxySet ]
FORMAT ProxySet_Index = ProxySet_EnableProxyKeepAlive, ProxySet_ProxyKeepAliveTime, ProxySet_ProxyLoadBalancingMethod, ProxySet_IsProxyHotSwap, ProxySet_SRD, ProxySet_ClassificationInput, ProxySet_ProxyRedundancyMode, ProxySet_KeepAliveFailureResp, ProxySet_HomingSuccessDetectionRetries;
ProxySet 0 = 0, 60, 0, 0, 0, 0, -1, "", 1;
[ \ProxySet ]
[ CodersGroup0 ]
FORMAT CodersGroup0_Index = CodersGroup0_Name, CodersGroup0_pTime, CodersGroup0_rate, CodersGroup0_PayloadType, CodersGroup0_Sce;
CodersGroup0 0 = "g711Alaw64k", 20, 0, -1, 1;
CodersGroup0 1 = "g711Ulaw64k", 20, 0, -1, 1;
[ \CodersGroup0 ]
[ CodersGroup1 ]
FORMAT CodersGroup1_Index = CodersGroup1_Name, CodersGroup1_pTime, CodersGroup1_rate, CodersGroup1_PayloadType, CodersGroup1_Sce;
CodersGroup1 0 = "g711Alaw64k", 20, 0, -1, 0;
CodersGroup1 1 = "g711Ulaw64k", 20, 0, -1, 0;
[ \CodersGroup1 ]
[ RoutingRuleGroups ]
FORMAT RoutingRuleGroups_Index = RoutingRuleGroups_LCREnable, RoutingRuleGroups_LCRAverageCallLength, RoutingRuleGroups_LCRDefaultCost;
RoutingRuleGroups 0 = 0, 0, 1;
[ \RoutingRuleGroups ]
[ ResourcePriorityNetworkDomains ]
FORMAT ResourcePriorityNetworkDomains_Index = ResourcePriorityNetworkDomains_Name, ResourcePriorityNetworkDomains_Ip2TelInterworking;
ResourcePriorityNetworkDomains 1 = "dsn", 0;
ResourcePriorityNetworkDomains 2 = "dod", 0;
ResourcePriorityNetworkDomains 3 = "drsn", 0;
ResourcePriorityNetworkDomains 5 = "uc", 1;
ResourcePriorityNetworkDomains 7 = "cuc", 0;
[ \ResourcePriorityNetworkDomains ]
Code Tag hinzugefügt, unnötige Leerzeilen entfernt - HabNeFritzbox
 

Anhänge

  • Syslog1.JPG
    Syslog1.JPG
    390.4 KB · Aufrufe: 13
Zuletzt bearbeitet von einem Moderator:
Moinsen


Hallo, ich habe nun die Einstellungen verändert, so dass nun das Login "Audiocodes", das steht nun anstelle der Rufnummer, anbei ein Syslog.
Kann es sein, dass hier das Login zum Webinterface (bzw. Zugangsdaten ) mit den Zugangsdaten eines LAN/WLAN IP-Telefoniegerätes verwechselt wird?
 
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.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.