‎Per Telekom-DNS-Server aufgelöster SIP-Reg-Server lehnt Login ab

Telekom hilft Community

Telekom Business Community

Privatkunden

Telekom Shops

Kontakt

Per Telekom-DNS-Server aufgelöster SIP-Reg-Server lehnt Login ab

vor 7 Jahren

Hallo zusammen,

ich kämpfe seit längerem mit Verbindungsabbrüchen und Nichterreichbarkeit. Ich verwende eine Asterisk TK-Anlage, die mit Geschäftskunden-Anschlüssen (SIP-Trunk) sehr gut funktioniert, bei mir mit einem stinknormalem AllIP-Anschluss aber unzuverlässig ist.

Nach Fehlerbereinigungen im Netzwerk und Ausprobieren mehrere Internet-Router (Lancom 1781VA, MiktroTik RB2011) ist jetzt noch aufgefallen, dass die Ausfälle immer mit einer bestimmten IP für tel.t-online.de auftreten. Standardmäßig löst meine TK-Anlage tel.t-online.de auf 217.0.27.52. Damit funktioniert alles. Teilweise wurde aber als IP die 217.0.128.132 zurückgeliefert. Das Kuriose daran ist, dass diese (falsche) IP-Adresse NUR von Telekom-DNS-Servern über die VDSL-Einwahl geliefert wird (geloggt über einen Zeitraum von 3 Wochen). Und da ich die TK-Anlage unabhängig von meinen internen Geräte betreiben will, verwendet sie nur den Router als DNS-Server.

Ich bin bisher auch davon ausgegegangen, dass die Telekom, die mir den SIP-Anschluss zur Verfügung stellt auch am besten sagen kann, welche Server sie für diesen Dienst anbietet.

Hier ein Auszug aus dem DNS-Monitoring:

Datum    Uhrzeit DNS-Name                                       IP-Adresse    DNS-Server
20180305 084501 h2-epp-801.isp.t-ipnet.de. 191	IN	A	217.0.128.132 TK-Anlage
20180305 084501 h2-epp-801.isp.t-ipnet.de. 191	IN	A	217.0.128.132 Router
20180305 084501 do-epp-801.isp.t-ipnet.de. 279	IN	A	217.0.27.52   Domänen-Controller 
20180305 084501 do-epp-801.isp.t-ipnet.de. 339	IN	A	217.0.27.52   Google 
20180305 084501 do-epp-801.isp.t-ipnet.de. 278	IN	A	217.0.27.52   OpenDNS 
20180305 084601 do-epp-801.isp.t-ipnet.de. 219	IN	A	217.0.27.52   TK-Anlage 
20180305 084601 h2-epp-801.isp.t-ipnet.de. 131	IN	A	217.0.128.132 Router
20180305 084601 do-epp-801.isp.t-ipnet.de. 219	IN	A	217.0.27.52   Domänen-Controller 
20180305 084601 do-epp-801.isp.t-ipnet.de. 297	IN	A	217.0.27.52   Google

Und genau, nachdem die TK-Anlage die "falsche" IP von Router übernommen hatte, war ich nicht mehr erreichbar bzw. konnte ich nicht mehr telefonieren:

INVITE sip:{angerufeneNummer}@tel.t-online.de SIP/2.0
Via: SIP/2.0/TCP {IP-TK-Anlage}:5060;branch=z9hG4bK2c9146ae;rport
Max-Forwards: 70
From: "Privat" <sip:{meineVorwahl+Nummer}@tel.t-online.de>;tag=as7ad2841e
To: <sip:{angerufeneNummer}@tel.t-online.de>
Contact: <sip:{meineVorwahl+Nummer}@{IP-TK-Anlage}:5060;transport=TCP>
Call-ID: 51cd7fc702dc2060758ff3633b8bb0ac@tel.t-online.de
CSeq: 102 INVITE
User-Agent: Asterisk  PBX  certified/XX.X-XXXXX
Date: Mon, 05 Mar 2018 07:46:18 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces
P-Asserted-Identity: <sip:{meineVorwahl+Nummer}@tel.t-online.de>
P-Preferred-Identity: <sip:{meineVorwahl+Nummer}@tel.t-online.de>
P-cs-cid: 0_1140748543@10.0.6.14
Alert-Info: <http://www.notused.de>;info=alert-internal;x-line-id=0
Content-Type: application/sdp
Content-Length: 242

v=0
o=root 1862462987 1862462987 IN IP4 {IP-TK-Anlage}
s=Asterisk  PBX  certified/XX.X-XXXXX
c=IN IP4 {IP-TK-Anlage}
t=0 0
m=audio 10998 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

SIP/2.0 403 Forbidden
Via: SIP/2.0/TCP {IP-TK-Anlage}:5060;received=217.248.29.83;rport=32801;branch=z9hG4bK2c9146ae
To: <sip:{angerufeneNummer}@tel.t-online.de>;tag=h7g4Esbg_evucdqp686zwq457oyx1m35o6vwtrtzu
From: "Privat" <sip:{meineVorwahl+Nummer}@tel.t-online.de>;tag=as7ad2841e
Call-ID: 51cd7fc702dc2060758ff3633b8bb0ac@tel.t-online.de
CSeq: 102 INVITE
Content-Length: 0

CK sip:{angerufeneNummer}@tel.t-online.de SIP/2.0
Via: SIP/2.0/TCP {IP-TK-Anlage}:5060;branch=z9hG4bK2c9146ae;rport
Max-Forwards: 70
From: "Privat" <sip:{meineVorwahl+Nummer}@tel.t-online.de>;tag=as7ad2841e
To: <sip:{angerufeneNummer}@tel.t-online.de>;tag=h7g4Esbg_evucdqp686zwq457oyx1m35o6vwtrtzu
Contact: <sip:{meineVorwahl+Nummer}@{IP-TK-Anlage}:5060;transport=TCP>
Call-ID: 51cd7fc702dc2060758ff3633b8bb0ac@tel.t-online.de
CSeq: 102 ACK
User-Agent: Asterisk  PBX  certified/XX.X-XXXXX
Content-Length: 0

Wie kommt es von der Telekom-Seite zu diesem nicht funktionierenden Server?

Danke

Ulf Kosack

Hinweis:

Dieser Beitrag wurde geschlossen.

Hinweis:

Dieser Beitrag ist nicht mehr für Antworten oder Kommentare geöffnet und ist nicht mehr für die Mitglieder der Community sichtbar.

1972

vor 7 Jahren

NAPTR tel.t-online.de verwenden, dann tut es - A-Auflösung ist falsch!

Antwort

von

vor 7 Jahren

Hallo NPS011172,

danke. Gilt Deine Aussage nur für TK-Anlagen? Ich kann in der Telekom-Hilfe (https://www.telekom.de/hilfe/festnetz-internet-tv/ip-basierter-anschluss/einstellungen-fuer-die-ip-telefonie-mit-anderen-clients) dazu gar nichts finden.

Wenn es falsch ist, müsste die Telekom es doch irgendwo beschrieben haben, oder? Kannst Du mir damit auch aushelfen?

Und warum soll es damit besser funktionieren, wenn es die selben Server zurückliefert?

# nslookup -querytype=SRV _sip._udp.tel.t-online.de
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
_sip._udp.tel.t-online.de       service = 1 5 5060 ims002.voip.t-ipnet.de.
_sip._udp.tel.t-online.de       service = 0 5 5060 ims001.voip.t-ipnet.de.

# nslookup ims002.voip.t-ipnet.de.
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
ims002.voip.t-ipnet.de  canonical name = h2-epp-801.isp.t-ipnet.de.
Name:   h2-epp-801.isp.t-ipnet.de
Address: 217.0.128.132                  <------- Server lässt Login nicht zu

# nslookup ims001.voip.t-ipnet.de.
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
ims001.voip.t-ipnet.de  canonical name = do-epp-801.isp.t-ipnet.de.
Name:   do-epp-801.isp.t-ipnet.de
Address: 217.0.27.52

Auch hier wird der .132 zurück geliefert, der bei mir eine Anmeldung verweigert?

Danke

Ulf

Das könnte Ihnen auch weiterhelfen

Gelöst