Willkommen in der Business Community

Die Telekom Community für Geschäftskunden

Aktueller Hinweis

SIP Konten Registrierung in TK-Anlage Aastra Intelligate 300

Gelöst

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

1 AKZEPTIERTE LÖSUNG

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:

 

Aastra300.jpg

 

Ich hoffe, es bleibt nun funktionsfähig!

 

Viele Grüße

 

Lösung in ursprünglichem Beitrag anzeigen  

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???

Telekom hilft Team
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.

Die Telekom SIP-Plattform weist den Via-Header der REGISTER-Meldung zurück:

SIP/2.0 400 Invalid Via Header
Via: SIP/2.0/UDP 192.168.1.221:5060;rport;branch=z9hG4bK2015May132917922 02xxxxxx

 

Könnte an diesem Leerzeichen vor 02xxxxxx liegen. Sie müssten diesbezüglich den Aastra-Support zur Klärung bemühen.

 

Den Traces kann ich entnehmen, dass Sie STUN deaktiviert haben.

Das ist erstmal ok so. Die SIP-Plattform der Telekom kann das handhaben.

 

Es ist immer schlecht, mit festen IP-Adressen für die Telekom SIP-Plattform zu arbeiten. Mir ist klar, dass Sie damit ausprobieren, den VoIP-Anschluss zum Laufen zu bringen.

Ist Ihnen ein Parameter DNS SRV aufgefallen? Wenn ja, wie ist der konfiguriert?

 

Welchen Router setzen Sie ein?

 

Grüße

spi

 

 

@Yalcin A.,

 

haben Sie vielen Dank für Ihr Angebot. Aktuell stehe ich mit einem Kollegen von Ihnen aus der Technik in Kontakt, der sich der Sache mit großem Eifer angenommen hat, wofür ich ihm sehr dankbar bin. Wir sind dabei, den Fehler einzukreisen. Einige Inkonsistenzen auf Ihrer Plattform sind bisweilen behoben worden. Zwar laufen die Konten immer noch nicht, ich bin aber zuversichtlich, dass wir das auch noch hinkriegen.

 

Da ich nun wohl in Ihrer Technik an der richtigen Stelle gelandet bin, möchte ich für den Moment auf Ihr Hilfeangebot verzichten. Ich will nicht hoffen, dass ich im Nachhinein doch darauf zurückkommen muss Fröhlich

 

@spi: Zunächst auch an Sie vielen Dank, dass Sie sich der Sache annehmen. 

 

Den Leerschritt habe ich testweise verwendet. Der Trace ändert aber sich m.E. im Ergebnis aber nicht. Ich kann aber bei Zeiten auch einen ohne Leerschritt posten. Der Aastra Support wurde bereits eingeschaltet und hat die Konfiguration der Anlage geprüft.

 

STUN ist in der Tat deaktiviert.

 

Wähle ich als Registrar tel.t-online.de, so erhalte ich ein MT 403: FORBIDDEN bei egal welcher Kombination von Rufnummer, angezeigter Rufnummer, SIP-ID, Benutzername, Passwort. Ebenfalls keine Abhilfe schafft hier, das automatische LogIn zu aktivieren bzw. zu deaktivieren.

 

Den Parameter "DNS_SRV verwenden (RFC3263)" habe ich gesehen. Er ist - wie bei dem SIPGATE-Account - auf "ja" gesetzt.

 

Als Router wird ein Zyxel vmg1312-b30a verwendet. Das DMC ist auf die TK-Anlage eingelastet. Ein (alternatives) port-forwarding schafft auch keine Abhilfe

 

Darüberhinaus ist auch interessant, dass die Registrierung der SIP-Konten auch in einer Soft-Phone Anwendung (Phoner Lite) nicht lange hält. Nach 1-3 Minuten oder nach 4-6 Anrufversuchen wird jeder weitere abgehende Ruf mit einem forbidden abgelehnt. Registriert man die Konten an einem anderen AS, so tritt dieses Problem nicht auf.

 

Viele Grüße

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

SIP-ALG

 

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: SIP_ALG.JPG

 

und

Port_Forwarding.JPG

 

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

 

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

Hallo Spi,

 

danke für Deine Vorschläge. Ich habe bis auf einen alle ausprobieren können: leider ohne Erfolg.

 

Die TK-Anlage unterstützt kein STUN. Vermutlich wird hier aber "der Hase im Pfeffer" liegen. Es ist nämlich - unter kompetenter Mithilfe der Telekom - noch folgendes zu Tage getreten:

 

Registriere ich mich im PhonerLite ohne Stun, so geht auf den T-Kom-Servern zunächst die Registrierung von der LocalIP (192.168.X.X) ein. Kurz darauf folgt eine zweite Registrierung, die von der WAN-IP ausgeht. Im Router sind aber keine Konten hinterlegt, er verfügt auch garnicht über diese Option. Ich konnte diesen "Fehler" reproduzieren und auch im DEBUG des PhonerLite einsehen. Aktiviere ich hingegen im PhonerLite STUN, so geht die Anwendung allein über die WAN-IP raus (ist das eigentlich so ok?).

 

Hier das log dazu:

16:14:46,475: T: 217.0.21.169:5060 (UDP)
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 217.94.xxx.xx:5060;branch=z9hG4bK000fe53a1f02e5118a05ef56db290def;rport
From: <sip:02xxxxxxxxx@tel.t-online.de>;tag=2847485046
To: <sip:02xxxxxxxxx@tel.t-online.de>
Call-ID: 000FE53A-1F02-E511-8A03-EF56DB290DEF@217.94.xxx.xx
CSeq: 1 REGISTER
Contact: <sip:02xxxxxxxxx@217.94.xxx.xx:5060>;+sip.instance="<urn:uuid:80A8FECE-1602-E511-B0D5-541D47E8EEAC>"
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


16:14:46,498: Facility Confirm: 16 00 01 00 80 81 05 00 01 00 00 00 00 00 03 00 05 01 00 02 00 00
16:14:46,498: Facility Confirm (Supplementary Services)
16:14:46,498: Listen: success
-------------------------------------------
16:14:46,497: T: 217.0.21.169:5060 (UDP)
SUBSCRIBE sip:02xxxxxxxxx@tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 217.94.xxx.xx:5060;branch=z9hG4bK000fe53a1f02e5118a06ef56db290def;rport
From: <sip:02xxxxxxxxx@tel.t-online.de>;tag=2969159606
To: <sip:02xxxxxxxxx@tel.t-online.de>
Call-ID: 000FE53A-1F02-E511-8A04-EF56DB290DEF@217.94.xxx.xx
CSeq: 2 SUBSCRIBE
Contact: <sip:02xxxxxxxxx@217.94.xxx.xx:5060>;+sip.instance="<urn:uuid:80A8FECE-1602-E511-B0D5-541D47E8EEAC>"
Max-Forwards: 70
User-Agent: SIPPER for PhonerLite
Expires: 1800
Event: message-summary
Accept: application/simple-message-summary
Content-Length: 0


-------------------------------------------
16:14:46,519: R: 217.0.21.169:5060 (UDP)
SIP/2.0 489 Bad event - no network services to SUBSCRIBE to!
Via: SIP/2.0/UDP 217.94.xxx.xx:5060;rport;branch=z9hG4bK000fe53a1f02e5118a06ef56db290def
To: <sip:02xxxxxxxxx@tel.t-online.de>;tag=huag3jrddx5
From: <sip:02xxxxxxxxx@tel.t-online.de>;tag=2969159606
Call-ID: 000FE53A-1F02-E511-8A04-EF56DB290DEF@217.94.xxx.xx
CSeq: 2 SUBSCRIBE
Content-Length: 0


-------------------------------------------
16:14:46,635: R: 217.0.21.169:5060 (UDP)
SIP/2.0 401 Unauthorized 010350300
Via: SIP/2.0/UDP 217.94.xxx.xx:5060;received=217.94.xxx.xx;rport=5060;branch=z9hG4bK000fe53a1f02e5118a05ef56db290def
To: <sip:+492xxxxxxxxx@tel.t-online.de>;tag=h7g4Esbg_adf4d89403d5ffdd60ba9cfc3ee6ea08
From: <sip:+492xxxxxxxxx@tel.t-online.de>;tag=2847485046
Call-ID: 000FE53A-1F02-E511-8A03-EF56DB290DEF@217.94.xxx.xx
CSeq: 1 REGISTER
Service-Route: <sip:217.0.21.169:5060;transport=udp;lr>
WWW-Authenticate: Digest realm="tel.t-online.de",nonce="ADFDA861DD7F645500000000CA45F91A",stale=true,algorithm=MD5,qop="auth"
Content-Length: 0


-------------------------------------------
16:14:46,636: T: 217.0.21.169:5060 (UDP)
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 217.94.xxx.xx:5060;branch=z9hG4bK000fe53a1f02e5118a09ef56db290def;rport
From: <sip:02xxxxxxxxx@tel.t-online.de>;tag=2847485046
To: <sip:02xxxxxxxxx@tel.t-online.de>
Call-ID: 000FE53A-1F02-E511-8A03-EF56DB290DEF@217.94.xxx.xx
CSeq: 3 REGISTER
Contact: <sip:02xxxxxxxxx@217.94.xxx.xx:5060>;+sip.instance="<urn:uuid:80A8FECE-1602-E511-B0D5-541D47E8EEAC>"
Authorization: Digest username="anonymous@t-online.de", realm="tel.t-online.de", nonce="ADFDA861DD7F645500000000CA45F91A", uri="sip:tel.t-online.de", response="bbf2cb0418c2c97521d0551169f5adfb", algorithm=MD5, cnonce="000fe53a1f02e5118a08ef56db290def", 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


-------------------------------------------
16:14:46,754: R: 217.0.21.169:5060 (UDP)
SIP/2.0 200 OK
Via: SIP/2.0/UDP 217.94.xxx.xx:5060;received=217.94.xxx.xx;rport=5060;branch=z9hG4bK000fe53a1f02e5118a09ef56db290def
To: <sip:+492xxxxxxxxx@tel.t-online.de>;tag=h7g4Esbg_adf4d89403d60c3c50ba9cfc3f566426
From: <sip:+492xxxxxxxxx@tel.t-online.de>;tag=2847485046
Call-ID: 000FE53A-1F02-E511-8A03-EF56DB290DEF@217.94.xxx.xx
CSeq: 3 REGISTER
Contact: <sip:02xxxxxxxxx@217.94.xxx.xx:5060>;expires=660;+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.21.169:5060;transport=udp;lr>
Content-Length: 0


-------------------------------------------
16:15:36,448: T: 217.0.0.193:3478
STUN
public ip: 217.94.xxx.xx:1024

 

 

Ein- und ausgehende Gespräche funktionieren dann auch einwandfrei. Komisch finde ich gleichwohl, dass die Registrierung nicht "sauber" ist, da mindestens ein "unauthorized" herausgegeben wird.

 

Ich bekomme in dieser Woche noch eine Digitalisierungsbox, mit der ich auch nochmal testen werden. Mehr und mehr macht sich bei mir die Befürchtung breit, dass der Router die IP-Adressen teilweise verändert.

Ich habe über den von der Anlage vorgesehenen "ALG-Support" auch einen Registerstring mit der WAN-IP herausgeschickt. Leider auch ohne Erfolg. Hier noch das Log aus der Anlage, einmal nit WAN-IP und einmal mit Local-IP:

 

>> 16:49:30:229 SIP: Remote Addr: 217.0.23.36:5060 MT: REGISTER sip:tel.t-online.de
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 192.168.1.221:5060;rport;branch=z9hG4bK2015May2649302020xxxxxxxxx
To: <sip:0xxxxxxxxx@tel.t-online.de>
From: <sip:0xxxxxxxxx@tel.t-online.de>;tag=AI4DD99D2E4A5FF63C
Call-ID: AIA96FE24C6E65B30A@192.168.1.221
CSeq: 10023 REGISTER
Max-Forwards: 70
Expires: 1200
Contact: <sip:0xxxxxxxxx@192.168.1.221;line=AI370A2B7773E04695>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,UPDATE
Allow-Events: dialog,message-summary,refer
User-Agent: Aastra Intelligate
Content-Length: 0

<< 16:49:30:334 SIP: Remote Addr: 217.0.23.36:5060 MT: 401 Unauthorized 010350300
SIP/2.0 401 Unauthorized 010350300
Via: SIP/2.0/UDP 192.168.1.221:5060;received=217.94.xxx.xx;rport=5060;branch=z9hG4bK2015May2649302020xxxxxxxxx
To: <sip:+49xxxxxxxxx@tel.t-online.de>;tag=h7g4Esbg_f555090403d5b34b10ba9d1b8ebab5f0
From: <sip:+49xxxxxxxxx@tel.t-online.de>;tag=AI4DD99D2E4A5FF63C
Call-ID: AIA96FE24C6E65B30A@192.168.1.221
CSeq: 10023 REGISTER
Service-Route: <sip:217.0.23.36:5060;transport=udp;lr>
WWW-Authenticate: Digest realm="tel.t-online.de",nonce="5D893A59E1876455000000008B62617D",stale=true,algorithm=MD5,qop="auth"
Content-Length: 0

 

>> 16:49:23:666 SIP: Remote Addr: 217.0.23.36:5060 MT: REGISTER sip:tel.t-online.de
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 217.94.xxx.xx:5060;rport;branch=z9hG4bK2015May2649236300xxxxxxxxx
To: <sip:0xxxxxxxxx@tel.t-online.de>
From: <sip:0xxxxxxxxx@tel.t-online.de>;tag=AI885BE120B3019DCE
Call-ID: AIA96FE24C6E65B30A@192.168.1.221
CSeq: 10022 REGISTER
Max-Forwards: 70
Expires: 1200
Contact: <sip:0xxxxxxxxx@217.94.xxx.xx;line=AI370A2B7773E04695>
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,UPDATE
Allow-Events: dialog,message-summary,refer
User-Agent: Aastra Intelligate
Content-Length: 0

<< 16:49:23:760 SIP: Remote Addr: 217.0.23.36:5060 MT: 401 Unauthorized 010350300
SIP/2.0 401 Unauthorized 010350300
Via: SIP/2.0/UDP 217.94.xxx.xx:5060;received=217.94.xxx.xx;rport=5060;branch=z9hG4bK2015May2649236300xxxxxxxxx
To: <sip:+49xxxxxxxxx@tel.t-online.de>;tag=h7g4Esbg_f555090403d580df70ba9d1b7511c504
From: <sip:+49xxxxxxxxx@tel.t-online.de>;tag=AI885BE120B3019DCE
Call-ID: AIA96FE24C6E65B30A@192.168.1.221
CSeq: 10022 REGISTER
Service-Route: <sip:217.0.23.36:5060;transport=udp;lr>
WWW-Authenticate: Digest realm="tel.t-online.de",nonce="74807194DB876455000000001523850C",stale=true,algorithm=MD5,qop="auth"
Content-Length: 0

 

 

Hallo ml-kanzlei,

 

das Authentifizierungsverfahren bei der Registrierung und bei jedem gehenden Verbindungsaufbau über Challenge-Response ist im SIP völlig normal. Der SIP-Proxy antwortet auf die REGISTER oder INVITE entweder mit einer 401 oder 407. Nur bei Re-Registrierungen läuft es zwischendurch etwas anders ab.

In der 401 bzw. 407 fordert der SIP-Proxy einen MD5-Hash-Wert vom Client an, in den auch der vom Proxy gelieferte Nonce-Wert eingeht. Das ist aber in Wirklichkeit noch um Einiges komplizierter.

 

SIP-Clients können aufgrund des rport-Algorithmus die öffentliche IP-Adresse und Port-Nummer der SIP-Signalisierungsverbindung vom Proxy erfahren und füllen dann in der Wiederholungsmeldung die korrekte Transportadresse in den SIP-Headern aus.

 

Im Aastra-Registrierungs-Trace sieht man, dass die Aastra die Authentifizierung, die der Proxy angefordert hat, nicht durchführt (siehe die zweite REGISTER, die dann prompt wieder mit 401 beantwortet wird). Die Frage ist, warum? Software-Fehler? Was hast Du da an Credentials hinterlegt? Auch anonymous@t-online.de wie beim SIP-Client? Oder die eMail-Adresse? Ist das Passwort ausgefüllt?

 

Hier noch ein Link über die Telekom-Authentifizierungsvariante:

https://telekomhilft.telekom.de/t5/Telefonie/VoIP-Authentifizierung-nur-noch-ein-Fake/td-p/1379200

 

Viele Grüße

spi

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

 

 

 

 

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

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:

 

Aastra300.jpg

 

Ich hoffe, es bleibt nun funktionsfähig!

 

Viele Grüße

 

Hallo ml-kanzlei,

 

schön, dass es jetzt funktioniert!

 

Falls sich noch Probleme einstellen sollten, wie:

  • nach Zeit ist ankommende Telefonie nicht mehr möglich,
  • die Sprachverbindung reißt während des Gespräches ab,

könnte die Einstellung "NAT - keep alive aktivieren" weiterhelfen.

 

Viele Grüße

spi

Hey Spi,

 

als ob Du es geahnt hättest Fröhlich Die Anlage verliert nach gewisser Zeit das NAT-Binding im Router. Ich habe insoweit mal eine Anfrage an den Zyxel Support gestellt mit der Frage, wie sich das NAT-Binding-Timeout verlängern lässt. Vielleicht hat hierzu ja auch jemand vom Telekom-Team einen Tipp. Soweit ich weiß, unterhält die TKom nämlich eine Abteilung, die sich speziell um den VMG 1312 kümmert.

 

Vorher habe ich Deinen Rat befolgt und die Option NAT Keep Alive aktiviert. Damit hat die Anlage in kurzen Abfolgen SIP OPTIONS herausgeschickt, die allesamt mit einem FORBIDDEN MT 403 vom Telekom-Server quittiert worden sind. Das wird doch wohl nicht die "normale" Reaktion sein, oder?

 

Viele Grüße

Hallo ml-kanzlei,

 

betrifft es nur den SIP-Port 5060 und/oder auch die RTP-Ports für die Audio-Streams?

 

Grüße

spi

Hallo zusammen,

vielen Dank für Ihre Anfrage, ml-kanzlei. An dieser Stelle auch einen Dank an spi für die hilfreichen Beiträge. Ich habe Ihre Frage an unsere Fachabteilung gemeldet und warte auf eine Rückmeldung. Sobald mir hier eine Antwort vorliegt, melde ich mich erneut.

Ich bin gerne für Sie da und freue mich über weitere Konversationen.

Herzliche Grüße
Yalcin A.

Hey Spi,

 

ich vermute, es betrifft nur den SIP-Port, kann es aber nicht genau nachvollziehen, da die NAT-Tabelle das nicht hergibt. Da aber auch längere Gespräche "halten", müsste das stimmen.

 

BG

Hallo ml-kanzlei,

 

die RTP-Ports werden im NAT des Routers bei normalen Gesprächen durch die Sende-Audio-Streams offen gehalten. Evtl. könnte ein Feature namens VAD - Voice Activity Detection - für Probleme sorgen; VAD sollte nicht aktiviert sein, damit bei Sprechpausen nicht auch der Sende-Audio-Stream pausiert (obwohl da meiner Erinnerung nach trotzdem noch periodisch Pakete gesendet werden). Interessant wären auch gehaltenen Verbindungen über eine Länge, die über das Timeout der NAT-Bindings hinaus geht, außer die Aastra spielt selbst MOH ein (ist wahrscheinlich so).

 

Zum SIP-Signalisierungsport fällt mir noch ein, dass man momentan den Reregistrierungsintervall anstelle der von der Telekom gewünschten 600 Sek. auf minimal 480 Sek. herunterschrauben kann. Wenn man das so konfiguriert, muss man das aber immer im Hinterkopf behalten und überprüfen, sobald Registrierungsprobleme auftauchen. Offiziell schreibt die Telekom 600 Sek. vor.

 

480 Sek. helfen aber auch nicht weiter, wenn NAT-Bindings im Bereich von beispielsweise 30 Sek. verfallen.

 

Hier bei Telekom-hilft war schon so lesen, dass die Telekom-SIP-Plattform auch Rufnummern bei gewissem Fehlverhalten im SIP-Protokoll "black-listen" würde. Ich habe dazu keine Erfahrungswerte. Hast Du es versuchsweise mal ohne die Option "NAT- keep alive" probiert. Vielleicht mag die SIP-Plattform die vielen OPTION-Requests nicht, die sie ja auch zurückweist.

 

Ansonsten bin ich gespannt, was die Telekom herausfindet.

 

Viele Grüße

spi

Hallo zusammen,

 

@spi: in der Tat, das Reg-Intervall lässt sich auf minimal 480 Sekunden herunterschrauben. Gibt man bspw. 300 Sekunden ein, so ersetzt die Anlage diesen Wert durch den von der TKom vorgegebenen.

 

Das NAT-Binding liegt jedenfalls knapp 120 Sekungen darunter.

 

Ich habe gerade auch eine Antwort vom Zyxel Support bekommen, dass eine Verlängerung des NAT TimeOut nicht möglich sei. Auf meine NAchfrage, ob dies ggf. über einen TelnetBefehl möglich sei, die das Gerät grds. verarbeiten kann, wurde nicht eingegangen.

 

 

Insofern nun meine Frage an Dich, @Yalcin A.:

 

Was hat Deine Anfrage bei den Herrschaften vom Zyxel-Support ergeben?

 

Es würde mich auch - sicherliche denken viele ebenso - interessieren, weshalb die OPTION-Anfrage, die man über das NAT Keep Alive an den T-KOM-Sip-Server sendet, mit einem Forbidden zurückgegeben werden.

 

Viele Grüße

Hallo, das Verlieren der Registrierung kommt mir als Bug des VMG1312 bekannt vor und sollte mit der Firmware unter diesem Link gefixt sein:

 

http://hilfe.telekom.de/dlp/eki/downloads/Zyxel/Firmware_Zyxel_VMG1312_B30A_100AAEB5D0.bin

 

Bitte mal dieses FW auf das Gerät aufbringen.

 

 

VG

NPS011172

Hallo,

vielen Dank für den Hinweis! Aktuell läuft allerdings bereits die von Dir genannte Firmware auf dem Gerät.

Viele Grüße
Guten Tag zusammen,

vielen Dank für Ihre Nachfrage, ml-kanzlei.

Laut meinem System liegt noch keine Antwort der Fachabteilung vor. Ihr Anliegen ist noch in Bearbeitung. Sobald ich eine Nachricht erhalten habe, komme ich erneut auf Sie zu.

Herzliche Grüße
Yalcin A.
Hallo Yalcin,

hast Du mittlerweile etwas in Erfahrung bringen können? Nach knapp einer Woche dachte ich, ich kann mal nachfragen Fröhlich

Viele Grüße