‎SIP Konten Registrierung in TK-Anlage Aastra Intelligate 300

Telekom Business Community

Telekom hilft Community

Geschäftskunden

Telekom Shops

Kontakt

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

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
Guten Tag ml-kanzlei,

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,

den Parameter DNS_SRV sollten Sie eingeschaltet lassen.

STUN erstmal aus.

Den SIP-Registrar, -Proxy und die Domain/den Realm sollten Sie wieder auf "tel.t-online.de" setzen.

Mit diesen Einstellungen die Fehlerklärung mit der Telekom fortsetzen.

Ist das SIP-ALG ein- oder ausgeschaltet (s.u.)?

Grüße

spi

Antwort
von
vor 10 Jahren
Hallo Spi,

ich habe gerade nochmal etwas herumprobiert. Dabei ist mir folgendes aufgefallen: Trage ich in meinen phonerlite als STUN stun.t-online.de ein, so werde ich nicht nach ein paar Minuten / einigen ausgehenden Anrufen bei einem weiteren Anrufversuch mit einem forbidden quittiert. Nehme ich den STUN wieder heraus, tritt der Fehler wieder auf. Er bleibt auch bestehen, wenn ich das port-forwarding (s. noch unten) auf den entsprechenden client einrichte.

Hinsichtlich des Routers habe ich nun mit den folgenden Einstellungen gearbeitet:

und

Erfolg hatte ich damit nicht. Nach wie vor registriert sich die Anlage nicht. Als Registrat/Proxy habe ich wieder tel.t-online.de gewählt. Einen SIP-Trace-Log kann ich gerade nicht beifügen, da ich mir meine Putty-Konfig zerschossen habe und leider nicht selbst in der Lage bin, diese wieder herzustellen (Hast Du hierzu womöglich auch eine Idee?)

Der Leerschrift in dem VIA Header ist aber jedenfalls beseitigt. Mir ist in dem Log ferner aufgefallen, dass dort der Wert "rport" auf 1024 gesetzt ist. In der Anlage taucht dieser nirgendwo auf. Hast Du hierfür evtl. eine Erklärung?

Da die Registrierung über phonerlite MIT STUN stabil ist, ist in diesem Zusammenhang wohl zumindest eines der Probleme zu suchen. STUN ist nach meinen Recherchen wohl - einfach ausgedrückt - dafür zuständig, die Pakete aus dem Netz an den richtigen Client im LAN durchzuschleusen. Müsste das nicht aber durch die Port-Forwarding Rules sichergestellt sein? Ich frage mich auch, wieso bei alledam die Registrierung des SIPGATE-Accounts läuft.

Vielen Dank für Deinen Rat!

Beste Grüße

Antwort
von
vor 10 Jahren
Hallo ml-kanzlei,

ich würde das SIP-ALG ausschalten. Es dient eigentlich dazu, VoIP über NAT und die Firewall des Routers zu ermöglichen, ohne dass weitere Eingriffe (Port-Forwardings, Firewall-Konfiguration) im Router dafür erforderlich sind. Auch STUN oder andere NAT-Traversalmethoden in den VoIP-Clients sollten dadurch nicht notwendig sein. Vielleicht bereitet aber gerade das SIP-ALG die Schwierigkeiten im Zusammenhang mit der Telekom und/oder der TK-Anlage.

Die Port-Forwardings würde ich ebenfalls deaktivieren bzw. löschen.
Da die Telekom SIP nur über UDP unterstützt, sind Port-Forwardings auf TCP nicht notwendig. Port 5070, 5080 und 1024 machen keinen Sinn, Port 40000 bis 41000 nur, wenn es sich wirklich um die RTP-Ports handelt, die die TK-Anlage benutzt. Port 3478 und 3479 halte ich für kontraproduktiv (bin mir in dem Punkt aber unsicher), da STUN auch den NAT-Typ ermittlen will, wobei die Port-Forwardings dann hinderlich wären.

Das NAT-Traversal würde ich der TK-Anlage übertragen, indem dort STUN aktiviert wird. STUN ermittelt öffentliche IP-Adresse und Port-Nummern für die SIP-Signalisierung und RTP-Streams, sodass diese in den SIP-Nachrichten korrekt eingetragen werden können. Wenn die NAT-Bindings nicht offen bleiben sollten, d.h. nach Zeit ist die TK-Anlage vom Internet nicht mehr erreichbar oder Gesprächsverbindungen werden einseitig, müsste man schauen, welche Konfigurationsmöglichkeit da noch in der TK-Anlage existiert.

Port 1024 kommt entweder durch das aktivierte SIP-ALG oder NAT zustande, ist aber nicht weiter tragisch, da der Source-Port nicht unbedingt 5060 sein muss.

Zum Thema Putty kann ich leider nichts beitragen, hoffe aber, dass meine obigen Ratschläge weiterhelfen werden.

Viele Grüße
spi
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