Gelöst
SIP Konten Registrierung in TK-Anlage Aastra Intelligate 300
vor 10 Jahren
Sehr geehrtes Telekom-Team,
nach nunmehr fast einer Woche ohne aktive SIP-Konten und mehreren bislang nicht erfolgreich verlaufenen Störungstickets suche ich nun parallel - ein weiteres Ticket wurde soeben eröffnet - auf diesem Wege um kompetenten Rat.
Einer unserer ISDN-Geschäftskunden-Anschlüsse ist am 9.5. auf einen IP umgestellt worden. Aus diesem Anlass wurde die o.g. TK-Anlage neubeschafft. Leider ist eine Registrierung unserer SIP-Konten aber bis heute nicht möglich, was selbstverständlich dem Geschäftsbetrieb nicht gerade zuträglich ist. Auch der Wartungsdienst der Anlage konnte hier keine Abhilfe schaffen.
Das Fehlerbild ist differenziert: Wähle ich als Registrar tel.t-online.de, so erhalte ich im Logfile ein "MT 403: forbidden". Wähle ich hingegen eine IP, hinter der vermeintlich Ihr TAS-System liegt (bspw. 217.0.17.26) oder tas.voip.t-ipnet.de, so erhalte ich zwar ein "MT 200: ok", die Anlage registriert sich gleichwohl nicht endgültig. An der Kombination von Rufnummer, angezeigtem Namen, SIP-ID, BN und PW kann es m.E. nicht liegen. Insoweit habe ich wohl alle möglichen Varianten durchprobiert. Das automatische Log-In des AS ist übrigens aktiviert. Ein SIPGATE und ein QSC Konto funktionieren übrigens einwandfrei.
Auch auf mehrere Bitten hin hat sich bei mir bislang niemand aus der dafür zuständigen Fachabteilung bei mir gemeldet. Angesichts der Entstörungsfrist von nur 8 Stunden und der bereits vergangenen Zeit ein sehr ärgerlicher Zustand. Bislang ist mir nur gesagt worden, dass irgendwas mit der Provisionierung nicht richtig sei.
Vielleicht könnten Sie parallel zu der aktuell aktiven Störung auf die Technik einwirken oder mir gerne auch direkt weiterhelfen.
Mit den besten Grüßen
3526
29
Das könnte Ihnen auch weiterhelfen
vor 8 Jahren
12983
0
1
vor 2 Jahren
501
0
2
vor 10 Jahren
Noch ein Nachtrag meinerseits:
auch die zuletzt aufgegebene Störung ist ohne einen Rückruf geschlossen worden. Angeblich soll die Registrierung nun funktionieren (was sie allerdings de facto nicht tun).
Hier auch noch ein Auszug aus dem log der Anlage (als Registrar ist dort NICHT tel.t-online.de eingetragen gewesen; dann erhalte ich nämlich "sofort" ein forbidden):
17:29:16:581 SIP: Remote Addr: 217.0.17.26:5060 MT: OPTIONS sip:217.0.17.26
OPTIONS sip:217.0.17.26 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.221:5060;rport;branch=z9hG4bK2015May132916563
To: <sip:217.0.17.26>
From: <sip:217.0.17.26>;tag=AID50CEF19FCA27DF7
Call-ID: AI29C5CD02E3FB8A00@192.168.1.221
CSeq: 10407 OPTIONS
Max-Forwards: 70
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,UPDATE
Allow-Events: dialog,message-summary,refer
User-Agent: Aastra Intelligate
Content-Length: 0
<< 17:29:16:635 SIP: Remote Addr: 217.0.17.26:5060 MT: 200 OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.221:5060;rport=5060;received=217.94.229.125;branch=z9hG4bK2015May132916563
To: <sip:217.0.17.26>;tag=dd1d4105
From: <sip:217.0.17.26>;tag=AID50CEF19FCA27DF7
Call-ID: AI29C5CD02E3FB8A00@192.168.1.221
Supported: 100rel,path
CSeq: 10407 OPTIONS
Accept: application/sdp
Accept-Encoding: identity
Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, PUBLISH, REFER, REGISTER, SUBSCRIBE, UPDATE
Content-Length: 0
>> 17:29:17:946 SIP: Remote Addr: 217.0.17.26:5060 MT: REGISTER sip:217.0.17.26
REGISTER sip:217.0.17.26 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.221:5060;rport;branch=z9hG4bK2015May132917922 02xxxxxxxxx
To: <sip:02xxxxxxxxxx@217.0.17.26>
From: <sip:02xxxxxxxxxxx@217.0.17.26>;tag=AI40331F50F4A9E98E
Call-ID: AIA3674B60AE655D86@192.168.1.221
CSeq: 10408 REGISTER
Max-Forwards: 70
Expires: 3600
Contact: <sip:02xxxxxxxxxxxxxx@192.168.1.221;line=AI80DA8B232A384C29>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,UPDATE
Allow-Events: dialog,message-summary,refer
User-Agent: Aastra Intelligate
Content-Length: 0
<< 17:29:18:002 SIP: Remote Addr: 217.0.17.26:5060 MT: 400 Invalid Via Header
SIP/2.0 400 Invalid Via Header
Via: SIP/2.0/UDP 192.168.1.221:5060;rport;branch=z9hG4bK2015May132917922 02xxxxxx
To: <sip:02xxxxxxxxxx@217.0.17.26>
From: <sip:02xxxxxxxxxxxxxx@217.0.17.26>;tag=AI40331F50F4A9E98E
Call-ID: AIA3674B60AE655D86@192.168.1.221
CSeq: 10408 REGISTER
Max-Forwards: 70
Expires: 3600
Contact: <sip:02xxxxxxxxxxxxxxxxx@192.168.1.221;line=AI80DA8B232A384C29>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,UPDATE
Allow-Events: dialog,message-summary,refer
User-Agent: Aastra Intelligate
Content-Length: 0
Bei dem Versuch, einen Anruf zu tätigen kommt noch hinzu:
17:29:05:780 Log: Warning
Equipment Info: mba
Location:
Software Version: c938 DE 141121 pbx7938c1
Workspace: /home/rel/ PBX /i79/pbx7938c1/pbx
Id-Nr.: 38145
Parameter: 00000002 00000000 00000000
@00000c78@@
@01753fa0@@
@022f37bc@@
@021710a8@@
@021735ec@@
@02162f74@@
@0166e1ac@@
@0166e494@@
17:29:15:148 Log: Warning
Equipment Info: mba
Location:
Software Version: c938 DE 141121 pbx7938c1
Workspace: /home/rel/ PBX /i79/pbx7938c1/pbx
Id-Nr.: 38145
Parameter: 00000002 00000000 00000000
@00000c78@@
@01753fa0@@
@022f37bc@@
@021710a8@@
@021735ec@@
@02162f74@@
@0166e1ac@@
@0166e494@@
Hat hierzu irgendjemand eine Lösung oder eventuell einen Lösungsansatz???
0
vor 10 Jahren
vielen Dank, dass Sie sich an uns wenden.
Aktuell kann ich nur Vermuten anstellen. Aus meiner Erfahrung her deutet ein Provisionierungsfehler daraufhin, dass die IP-Rufnummern nicht ordnungsgemäß ins System eingepflegt werden konnten. Der Fehler ist bekannt, aber bei jedem betroffenen Kunden individuell zu beheben. Die Kollegen aus der technischen Fachabteilung sind hier die richtigen Ansprechpartner.
Gern hake ich für Sie bei den Kollegen nach. Daher bitte ich Sie, unser Kontaktformular http://bit.ly/1jDZpzy auszufüllen. Sobald mir Ihre Daten vorliegen, melde ich mich zurück.
Ich bin gerne für Sie da.
Viele Grüße
Yalcin A.
26
Antwort
von
vor 10 Jahren
Hallo Spi,
ich habe in der Anlage mit verschiedenen Kombinationen gearbeitet, um herauszufinden, ob es daran lag. Ich habe bspw. auch SIP-ID und Benutzername absichtlich vertauscht. In letzter Zeit habe ich allerdings stets mit anonymous@t-online.de gearbeitet.
Deinen Link habe ich aufmerksam gelesen. Auch ich erachte es übrigens für nötig, dass eine nutzerseitige Authentifizierung auch am eigenen AS auf Kundenwunsch hin aktivierbar sein sollte. Davon abgesehen habe ich nach Lektüre des Artikels einen Inklusivnutzer angelegt, um die Abfrage von BN und PW zwangsweise herbeizuführen. Leider ist der Inklusivnutzer im Telefoniecenter (noch) nicht sichtbar. Dieses Problem wurde und wird auch bereits hier im Form erörtert.
Ich habe heute auch noch mit einer Digitalisierungsbox Premium testen können. Da Binteq Elmec-Gerät bietet eine - wie ich finde - sehr gute Benutzeroberfläche, die sich nach verschiedenen Kenntnisstufen (Anfänger, Experte, Vollzugang) hin ausführen lässt. Im Ergebnis hat der Gerätetausch vom Zyxel VMG 1312 hin zu der DigiBoxPremium aber auch keine Besserung gebracht. Das Fehlerbild blieb.
Ich habe mich daher nochmal daran gesetzt, dem "doppelten LogIn" nachzugehen. Mir ist ja neulich im PhonerLite Debug aufgefallen, dass ein solches stattfindet und ich danach bei abgehenden Anrufversuchen abgewiesen werde. Ich habe das sowohl mit dem Telekom-SIP-Konto, als auch mit meinem Sipgate-Konto durchgespielt und bin dabei zu einem - womöglich - hoffnungsvollen Gedanken gekommen. Eines noch(mal) kurz vorweggeschickt werden. Das SIPGATE-Konto läuft sowohl aus der Anlage als auch aus dem Phonerlite einwandfrei.
Das Log für das Telekom Konto sieht wie folgt aus:
20:55:35,374: T: 217.0.18.168:5060 (UDP)
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 192.168.1.152:5060;branch=z9hG4bK80ed81cad803e5119ff7b6d5edca32f7;rport
From: <sip:02xxxxxxxxx@tel.t-online.de>;tag=892931226
To: <sip:02xxxxxxxxx@tel.t-online.de>
Call-ID: 8066EEC6-D803-E511-9FF2-B6D5EDCA32F7@192.168.1.152
CSeq: 3 REGISTER
Contact: <sip:02xxxxxxxxx@192.168.1.152:5060>;+sip.instance="<urn:uuid:80A8FECE-1602-E511-B0D5-541D47E8EEAC>"
Authorization: Digest username="anonymous@t-online.de", realm="tel.t-online.de", nonce="B2F9A9E6AC646755000000005C467544", uri="sip:tel.t-online.de", response="70f0c402929ee5605e764f106425d393", algorithm=MD5, cnonce="80ed81cad803e5119ff6b6d5edca32f7", qop=auth, nc=00000001
Allow: INVITE, OPTIONS, ACK, BYE, CANCEL, INFO, NOTIFY, MESSAGE, UPDATE
Max-Forwards: 70
Allow-Events: org.3gpp.nwinitdereg
User-Agent: SIPPER for PhonerLite
Expires: 900
Content-Length: 0
-------------------------------------------
20:55:35,469: R: 217.0.18.168:5060 (UDP)
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.152:5060;received=84.174.xxx.xxx;rport=5060;branch=z9hG4bK80ed81cad803e5119ff7b6d5edca32f7
To: <sip:+492xxxxxxxxx@tel.t-online.de>;tag=h7g4Esbg_27074b6905dccfa0c0baa84a07299530
From: <sip:+492xxxxxxxxx@tel.t-online.de>;tag=892931226
Call-ID: 8066EEC6-D803-E511-9FF2-B6D5EDCA32F7@192.168.1.152
CSeq: 3 REGISTER
Contact: <sip:02xxxxxxxxx@192.168.1.152:5060>;expires=660;+sip.instance="<urn:uuid:80A8FECE-1602-E511-B0D5-541D47E8EEAC>"
Contact: <sip:02xxxxxxxxx@192.168.1.152:5060;eribindingid=702779295>;expires=2974;+sip.instance="<urn:uuid:80A8FECE-1602-E511-B0D5-541D47E8EEAC>"
P-Associated-Uri: <sip:+492xxxxxxxxx@tel.t-online.de>
P-Associated-Uri: <sip:02xxxxxxxxx@tel.t-online.de>
P-Associated-Uri: <sip:00492xxxxxxxxx@tel.t-online.de>
P-Associated-Uri: <tel:+492xxxxxxxxx>
Service-Route: <sip:217.0.18.168:5060;transport=udp;lr>
Content-Length: 0
-------------------------------------------
20:56:04,493: T: 217.0.18.168:5060
STUN over SIP
public ip: 84.174.xxx.xxx:5060
-------------------------------------------
20:56:04,493: T: 217.0.18.168:5060 (UDP)
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 84.174.xxx.xxx:5060;branch=z9hG4bK00facadbd803e5119ff9b6d5edca32f7;rport
From: <sip:02xxxxxxxxx@tel.t-online.de>;tag=3681532696
To: <sip:02xxxxxxxxx@tel.t-online.de>
Call-ID: 00FACADB-D803-E511-9FF7-B6D5EDCA32F7@84.174.xxx.xxx
CSeq: 4 REGISTER
Contact: <sip:02xxxxxxxxx@84.174.xxx.xxx:5060>;+sip.instance="<urn:uuid:80A8FECE-1602-E511-B0D5-541D47E8EEAC>"
Authorization: Digest username="anonymous@t-online.de", realm="tel.t-online.de", nonce="B2F9A9E6AC646755000000005C467544", uri="sip:tel.t-online.de", response="fefc8e98d1f62b98bc62ba8c9f849901", algorithm=MD5, cnonce="00facadbd803e5119ff8b6d5edca32f7", qop=auth, nc=00000002
Allow: INVITE, OPTIONS, ACK, BYE, CANCEL, INFO, NOTIFY, MESSAGE, UPDATE
Max-Forwards: 70
Allow-Events: org.3gpp.nwinitdereg
User-Agent: SIPPER for PhonerLite
Expires: 660
Content-Length: 0
-------------------------------------------
20:56:04,682: R: 217.0.18.168:5060 (UDP)
SIP/2.0 401 Unauthorized 010350300
Via: SIP/2.0/UDP 84.174.xxx.xxx:5060;received=84.174.xxx.xxx;rport=5060;branch=z9hG4bK00facadbd803e5119ff9b6d5edca32f7
To: <sip:+492xxxxxxxxx@tel.t-online.de>;tag=h7g4Esbg_fcca0a8805df3b1290baa84a794a678a
From: <sip:+492xxxxxxxxx@tel.t-online.de>;tag=3681532696
Call-ID: 00FACADB-D803-E511-9FF7-B6D5EDCA32F7@84.174.xxx.xxx
CSeq: 4 REGISTER
Service-Route: <sip:217.0.18.168:5060;transport=udp;lr>
WWW-Authenticate: Digest realm="tel.t-online.de",nonce="F7E74D5DCA646755000000008221302B",stale=true,algorithm=MD5,qop="auth"
Content-Length: 0
-------------------------------------------
20:56:04,682: T: 217.0.18.168:5060 (UDP)
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 84.174.xxx.xxx:5060;branch=z9hG4bK00facadbd803e5119ffcb6d5edca32f7;rport
From: <sip:02xxxxxxxxx@tel.t-online.de>;tag=3681532696
To: <sip:02xxxxxxxxx@tel.t-online.de>
Call-ID: 00FACADB-D803-E511-9FF7-B6D5EDCA32F7@84.174.xxx.xxx
CSeq: 5 REGISTER
Contact: <sip:02xxxxxxxxx@84.174.xxx.xxx:5060>;+sip.instance="<urn:uuid:80A8FECE-1602-E511-B0D5-541D47E8EEAC>"
Authorization: Digest username="anonymous@t-online.de", realm="tel.t-online.de", nonce="F7E74D5DCA646755000000008221302B", uri="sip:tel.t-online.de", response="861bf24447b7742ea9fb342828156e65", algorithm=MD5, cnonce="00facadbd803e5119ffbb6d5edca32f7", qop=auth, nc=00000001
Allow: INVITE, OPTIONS, ACK, BYE, CANCEL, INFO, NOTIFY, MESSAGE, UPDATE
Max-Forwards: 70
Allow-Events: org.3gpp.nwinitdereg
User-Agent: SIPPER for PhonerLite
Expires: 660
Content-Length: 0
-------------------------------------------
20:56:04,753: R: 217.0.18.168:5060 (UDP)
SIP/2.0 200 OK
Via: SIP/2.0/UDP 84.174.xxx.xxx:5060;received=84.174.xxx.xxx;rport=5060;branch=z9hG4bK00facadbd803e5119ffcb6d5edca32f7
To: <sip:+492xxxxxxxxx@tel.t-online.de>;tag=h7g4Esbg_fcca0a8805df3b53a0baa84a798dba1a
From: <sip:+492xxxxxxxxx@tel.t-online.de>;tag=3681532696
Call-ID: 00FACADB-D803-E511-9FF7-B6D5EDCA32F7@84.174.xxx.xxx
CSeq: 5 REGISTER
Contact: <sip:02xxxxxxxxx@84.174.xxx.xxx:5060>;expires=660;+sip.instance="<urn:uuid:80A8FECE-1602-E511-B0D5-541D47E8EEAC>"
Contact: <sip:02xxxxxxxxx@192.168.1.152:5060>;expires=631;+sip.instance="<urn:uuid:80A8FECE-1602-E511-B0D5-541D47E8EEAC>"
Contact: <sip:02xxxxxxxxx@192.168.1.152:5060;eribindingid=702779295>;expires=2945;+sip.instance="<urn:uuid:80A8FECE-1602-E511-B0D5-541D47E8EEAC>"
P-Associated-Uri: <sip:+492xxxxxxxxx@tel.t-online.de>
P-Associated-Uri: <sip:02xxxxxxxxx@tel.t-online.de>
P-Associated-Uri: <sip:00492xxxxxxxxx@tel.t-online.de>
P-Associated-Uri: <tel:+492xxxxxxxxx>
Service-Route: <sip:217.0.18.168:5060;transport=udp;lr>
Content-Length: 0
Das Log für das SIPGate-Konto:
20:59:37,213: T: 217.10.79.9:5060 (UDP)
REGISTER sip:sipgate.de SIP/2.0
Via: SIP/2.0/UDP 192.168.1.152:5060;branch=z9hG4bK8032c05ad903e51192b21769e0318dfb;rport
From: "PhonerLite" <sip:2xxxxxx@sipgate.de>;tag=2687792448
To: "PhonerLite" <sip:2xxxxxx@sipgate.de>
Call-ID: 80AB2C57-D903-E511-92AF-1769E0318DFB@192.168.1.152
CSeq: 3 REGISTER
Contact: <sip:2xxxxxx@192.168.1.152:5060>;+sip.instance="<urn:uuid:80A8FECE-1602-E511-B0D5-541D47E8EEAC>"
Authorization: Digest username="2xxxxxx", realm="sipgate.de", nonce="556767eb34497b62242bd685207e5c836bb68b95", uri="sip:sipgate.de", response="0aa1e5e3e0dccf0835fb2e1ed9cbe7b3", algorithm=MD5
Allow: INVITE, OPTIONS, ACK, BYE, CANCEL, INFO, NOTIFY, MESSAGE, UPDATE
Max-Forwards: 70
Allow-Events: org.3gpp.nwinitdereg
User-Agent: SIPPER for PhonerLite
Expires: 900
Content-Length: 0
-------------------------------------------
20:59:37,223: R: 217.10.79.9:5060 (UDP)
SIP/2.0 501 Not Implemented
Via: SIP/2.0/UDP 192.168.1.152:5060;branch=z9hG4bK8032c05ad903e51192b11769e0318dfb;rport=1024;received=84.174.xxx.xxx
From: "PhonerLite" <sip:2xxxxxx@sipgate.de>;tag=2991036458
To: <sip:2xxxxxx@sipgate.de>;tag=76c3a965ce64047cf0e7a6bf6ca0b916.8ed8
Call-ID: 80AB2C57-D903-E511-92B0-1769E0318DFB@192.168.1.152
CSeq: 2 SUBSCRIBE
Content-Length: 0
-------------------------------------------
20:59:37,231: R: 217.10.79.9:5060 (UDP)
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.152:5060;received=84.174.xxx.xxx;branch=z9hG4bK8032c05ad903e51192b21769e0318dfb;rport=1024
From: "PhonerLite" <sip:2xxxxxx@sipgate.de>;tag=2687792448
To: "PhonerLite" <sip:2xxxxxx@sipgate.de>;tag=c3e497ecaece77a8e244e564b4212178.2c0f
Call-ID: 80AB2C57-D903-E511-92AF-1769E0318DFB@192.168.1.152
CSeq: 3 REGISTER
Contact: <sip:2xxxxxx@192.168.1.152;line=AI2470739DDFC66B3B>;expires=63;received="sip:84.174.xxx.xxx:33158", <sip:2xxxxxx@192.168.1.152:5060>;expires=600;received="sip:84.174.xxx.xxx:1024"
Content-Length: 0
Könnte es sein, dass sipgate die lokale IP mit dem Befehl "received="sip:WAN-IP" der WAN-IP zuordnet und es damit nicht zu einer doppelten, sondern lediglich zu einer einfachen Registrierung kommt. Demgegenüber registriert der Telekom-Server die WAN-IP und die lokale IP als jeweils einen separaten Registrierungsversuch und verweigert diesen?
Ich bin für Deine/Eure Antworten sehr dankbar!
Viele Grüße
ml-kanzlei
Antwort
von
vor 10 Jahren
Hallo ml-kanzlei,
die Tatsache, dass sich das Fehlverhalten nach Austausch des Routers nicht abgestellt hat, könnte ein Indiz dafür sein, dass es nicht am Router liegt.
Das Fehlschlagen der Authentifizierung der Aastra-Anlage an der Telekom-SIP-Plattform lässt mich eigentlich vermuten, dass das Problem in der Aastra zu suchen ist.
Benutzt Du ein Kennwort bei anonymous@t-online.de? Vielleicht ist es so trivial, dass die Aastra keine Authentifizierungsheader ausfüllt, wenn das Kennwort fehlt.
Einfach ein paar Zeichen als Kennwort eintragen.
Für das Einrichten eines Inklusivnutzer hat die Telekom für mich als PK fast eine Woche gebraucht. Das wurde aber im Bestellprozess eindeutig herausgestellt. Trotzdem macht es mich fassungslos.
Was die multiplen Registrierungs-Bindings angeht, muss ich ehrlich zugeben, dass mein Know-How an der Stelle eine Grenze erreicht hat. Normalerweise hätte ich mir sie dadurch erklärt, dass beim Herumspielen an Einstellungen die SIP-Clients sich evtl. nicht de-registrieren. Dann verbleiben die alten Registrierungen solange auf dem SIP-Proxy, bis sie verfallen (siehe expires-Wert in Sek.).
Ob das bei Dir der Hintergrund sein kann, weiß ich leider nicht.
Auch sollte der "rport"-Ablauf nicht zu zwei Registrierungs-Bindings (einmal auf privater, einmal auf öffentlicher IP-Adresse) führen. Aber wer weiß schon, welche Bugs in der Telekom-SIP-Plattform schlummern.
Viele Grüße
spi
Antwort
von
vor 10 Jahren
Hallo Spi,
liebe Gemeinde,
zunächst möchte ich mich bei Dir, Spi, für die reichhaltige und wertvolle Unterstützung bedanken!
Sodann kann ich verkünden, dass nunmehr sowohl die Registrierung läuft, als auch eingehende, wie abgehende Telefonate. Auch das Fax funktioniert ohne Probleme. Bislang habe ich es knappe 24 Stunden testen können.
Nachdem ich gestern vormittag testweise eine DigiBox-Premium angeschlossen hatte und dort direkt die Konten störungsfrei registrieren konnte, war eine netzseitiges Problen wohl zumindest dem Grunde nach ausgeschlossen. Aus der dortigen Konfig konnte ich erkennen, dass die Registrierung nicht in dem Format 02xxxxxxx, sondern in +492xxxxxx. Das gilt sowohl für die Rufnummer, wie auch den anzezeigten Namen und die SIP ID. Als BN habe ich mit anonymous@t-online.de und einem fiktiven Passwort gearbeitet. Als ich in diesem Format die Registrierung in der Aastra 300 versucht habe hat es, ein Glücksmoment, auch dort funktioniert.
Leider (oder womöglich glücklicherweise) hat sich in genau diesem zeitlichen Ramen die tel.t-online.de anders aufgelöst. Ich werde aktuell über 217.0.23.102 geroutet. Wegen dieses Wechsels kann ich nun nicht mit Sicherheit sagen, ob die andere Konfig ursächlich war oder der andere RegistrarServer.
Ich bin mir indes sicher, dass ich zu Anfang meiner Tests auch bereits einmal in dem +49-Format gearbeitet habe. In dem Moment mögen aber andere Einstellungen anders gesetzt gewesen sein. Ich will aber nun hoffen, dass es an der Konfig und nicht am T-Server liegt. Gewissheit bekomme ich allerdings erst, wenn - was ich nicht hoffe - ich abermals über einen anderern Server gerouted werde.
Hier auch ein Auszug aus der Konfig der Anlage, die nicht die bereits o.g. Registrierungsdaten anbelangt:
Ich hoffe, es bleibt nun funktionsfähig!
Viele Grüße
Uneingeloggter Nutzer
Antwort
von
Akzeptierte Lösung
akzeptiert von
vor 10 Jahren
Hallo Spi,
liebe Gemeinde,
zunächst möchte ich mich bei Dir, Spi, für die reichhaltige und wertvolle Unterstützung bedanken!
Sodann kann ich verkünden, dass nunmehr sowohl die Registrierung läuft, als auch eingehende, wie abgehende Telefonate. Auch das Fax funktioniert ohne Probleme. Bislang habe ich es knappe 24 Stunden testen können.
Nachdem ich gestern vormittag testweise eine DigiBox-Premium angeschlossen hatte und dort direkt die Konten störungsfrei registrieren konnte, war eine netzseitiges Problen wohl zumindest dem Grunde nach ausgeschlossen. Aus der dortigen Konfig konnte ich erkennen, dass die Registrierung nicht in dem Format 02xxxxxxx, sondern in +492xxxxxx. Das gilt sowohl für die Rufnummer, wie auch den anzezeigten Namen und die SIP ID. Als BN habe ich mit anonymous@t-online.de und einem fiktiven Passwort gearbeitet. Als ich in diesem Format die Registrierung in der Aastra 300 versucht habe hat es, ein Glücksmoment, auch dort funktioniert.
Leider (oder womöglich glücklicherweise) hat sich in genau diesem zeitlichen Ramen die tel.t-online.de anders aufgelöst. Ich werde aktuell über 217.0.23.102 geroutet. Wegen dieses Wechsels kann ich nun nicht mit Sicherheit sagen, ob die andere Konfig ursächlich war oder der andere RegistrarServer.
Ich bin mir indes sicher, dass ich zu Anfang meiner Tests auch bereits einmal in dem +49-Format gearbeitet habe. In dem Moment mögen aber andere Einstellungen anders gesetzt gewesen sein. Ich will aber nun hoffen, dass es an der Konfig und nicht am T-Server liegt. Gewissheit bekomme ich allerdings erst, wenn - was ich nicht hoffe - ich abermals über einen anderern Server gerouted werde.
Hier auch ein Auszug aus der Konfig der Anlage, die nicht die bereits o.g. Registrierungsdaten anbelangt:
Ich hoffe, es bleibt nun funktionsfähig!
Viele Grüße
0
Uneingeloggter Nutzer
Frage
von