crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
19.09.2017 16:28
Hallo Community,
ich habe gerade wieder eine seltsame Entdeckung beim konfigurieren meiner Asterisk-Anlage gemacht.
Der VOIP SIP-Server 217.0.27.104 (do-epp-105.isp.t-ipnet.de) meldet bei ausgehenden Telefonaten immer "FORBIDDEN", trotz erfolgreichem REGISTRY und Invite-Proxy-Auth.
Wenn ich den DNS Eintrag auf 217.0.23.100 umbiege, funktionieren ausgehende Gesprche.
Ich vermute einen BUG. Es betrifft mehrere VOIP-Kunden.
Vieleicht kann sich das mal ein Fachkundiger anschauen. LOGs kann ich liefern falls nötig.
Gruß, Christian
Gelöst! Gehe zu Lösung.
So, kurz zur Rückmeldung. Wir haben das Problem gefunden.
Es handelt sich um ein DNS Problem in kombination der Telekom DNS Server und unserem DNSMASQ (auf OpenWRT).
Um es kurz zu machen, die Telekom DNS Server lösen den SIP Server anders auf als die öffentlichen SIP Server. Auch verschiedene Telekom DNS Server lösen die Adressen (tel.t-online.de) verschieden auf.
Scheint was mit dem Loadbalancing zu tun zu haben, ich kann schlecht nachvollziehen ob es sich um einen Bug oder ein Feature handelt.
Schlussendlich habe ich auf den Asterisk Servern einen bind-server installiert. Alternativ kann man auch einen externen DNS anstelle dem Router-DNS eintragen.
Läuft erstmal. Bei Interesse schick ich gern weitere Infos.
Danke für die Mühe.
MFG Christian
19.09.2017 17:58
Registrierst Du nicht an tel.t-online.de ?
19.09.2017 18:10 Zuletzt bearbeitet: 19.09.2017 18:16 durch den Autor
Schon, aber scheinbar löst der nicht überall gleich auf . DNS Loadbalancing?
# ping tel.t-online.de
PING hh-epp-001.isp.t-ipnet.de (217.0.23.132) 56(84) bytes of data.
19.09.2017 18:21
Natürlich löst der nicht überall gleich auf.
Forbidden ist eigentlich ein Indiz für schlechte Auth oder falscher Rufnummer zum Anschluss....
kannst du einen SIP Log anonymisiert posten?
19.09.2017 22:02
19.09.2017 23:46
Nutze mal für die Anmeldung die E-Mail-Adresse und das zugehörige Passwort (wie Login kundencenter) und schau ob sich das Verhalten ändert.
20.09.2017 00:03
Hatte ich schon probiert, keine Änderung. Im Kunden-Telefoniecenter ist "Telekom Login" auch deaktiviert, also existieren keine Zugangsdaten. Ich hatte gehofft, das eine Umstellung ggf. den "bug" behebt weil evtl. irgenwelche Configs neu geschrieben werden. Leider ohne Erfolg.
20.09.2017 00:47
Es sind die Zugangsdaten für das Kundencenter. Separate Zugangsdaten existieren nicht bei Privatkundentarifen. Meinst Du mit Telekom Login das Easylogin ?
20.09.2017 07:18
Na du musst bei einem Neu-Anschluss wie diesem dich erstmalig mit deinen DSL-Logindaten einloggen, dann ins Telefoniecenter wechseln. Dort kannst du bei den Rufnummern "Telekom-Login" aktivieren. Danach muss man erstmal eine E-Mail Addresse anlegen und ein Passwort vergeben. Dann lässt sich Telefonie per "Telekom-Login" aktivieren.
Danach klappt die Auth per anonymous... nicht mehr, mit den Login-Daten (der neu vergebenen E-Mail u. Passwort) hat das REGISTER dann geklappt. Trotzdem kommt FORBIDDEN beim absetzen eines calls.
Wie gesagt, ich denke nicht das es ein AUTH problem ist. Immerhin klappt das absetzen des Calls auf anderen Telekom-SIP Servern. Das wird was internes sein. Evtl. eine andere Software als z.B. auf der 217.0.23.100 (dorthin lösen alle anderen Anschlüsse die ich betreibe auf.)
Es wäre super wenn ich die Telekom mal die Sache annimmt.
Gruß, Christian
20.09.2017 07:25 Zuletzt bearbeitet: 20.09.2017 07:38 durch den Autor
Nein, Du kannst am Anschluss für die Telefonie mit dem Hauptnutzer immer anonymous verwenden.
Das gilt natürlich nur bei erfolgreicher Access-Authentifizierung, also bei korrekter Einwahl am eigenen Anschluss...
Sind die Rufnummern sind einem Inklusivnutzer zugeordnet, dann müssen zwingend die Daten des Nutzers verwendet werden.
20.09.2017 08:17
Soweit ist das klar. DSL Daten sind eindeutig, Einwahl und Verbindung funktionieren ja auch. Auch das REGISTRY funktioniert. Wären die Daten falsch, würde sich die VOIP Anlage ja nicht registrieren können. Das Problem tritt auch mit anderen Nummern an anderen Anschlüssen auf. Problem sind mmn. der Telekom-SIP Server in kombination mit der Asterisk. Ich habe beim selben Kunden noch ein IP-Gigaset stehen, dort funktioniert die Telefonie. Ich werde mir dort mal das Log anschauen sofern möglich.
20.09.2017 17:44
Hallo Telekom, könnte sich mal bitte einer dem Problem annehmen?
20.09.2017 17:55
Wenn das Gigaset läuft, die Asterisk aber nicht ist doch aber naheliegend, dass die Konfiguration der Asterisk nicht ganz sauber ist...
20.09.2017 18:20
Der Asterisk läuft mit der gleichen Konfiguration bei ca. 10 Kunden (auch größere) seit mehreren jahren.
Außerdem läuft er mit dem .100er SIP Server auch fehlerfrei. Die Forbidden Meldung ist auch nicht aussagekräftig da kein Grund genannt wird.
Das Protokoll sieht auch sauber aus. Warum sich die anderen Server verschlucken kann aber nur die Telekom in ihren LOGs nachlesen.
Asterisk ist meiner Meinung nach auch ein marktrelevantes Produkt und läuft mit beinahe allen anderen Anbietern und Geräten fehlerfrei. Nur bei der Telekom kommt es immer wieder zu Problemen. Das sind nicht die ersten bugs auf die ich hinweise, siehe meinen Beitrag zur Thema Primacom.
Nun kann man sich aber den schwarzen Peter immer hin und her schieben, das bringt uns aber auch nicht weiter. Zielführender wäre es, wenn sich ein Telekom-Techniker mal das LOG anschaut.
20.09.2017 19:32
Ich hab das Problem eingrenzen können.
Das Ursprüngliche INVITE wird an die .104 gesendet, zurück kommt die AUTH anforderung. Daraufhin Parst Asterisk die destination neu und löst tel.t-online.de neu auf. Der DNS Record zeigt auf die .132
Die .132 weiß allerdings noch nix von der Session.
Das kann auch ein DNS Problem sein. Ich schau mir mal die SIP-Specs dazu an.
So, kurz zur Rückmeldung. Wir haben das Problem gefunden.
Es handelt sich um ein DNS Problem in kombination der Telekom DNS Server und unserem DNSMASQ (auf OpenWRT).
Um es kurz zu machen, die Telekom DNS Server lösen den SIP Server anders auf als die öffentlichen SIP Server. Auch verschiedene Telekom DNS Server lösen die Adressen (tel.t-online.de) verschieden auf.
Scheint was mit dem Loadbalancing zu tun zu haben, ich kann schlecht nachvollziehen ob es sich um einen Bug oder ein Feature handelt.
Schlussendlich habe ich auf den Asterisk Servern einen bind-server installiert. Alternativ kann man auch einen externen DNS anstelle dem Router-DNS eintragen.
Läuft erstmal. Bei Interesse schick ich gern weitere Infos.
Danke für die Mühe.
MFG Christian
20.09.2017 23:08
Ok, genausowas hatte ich vermutet. Danke für die Rückmeldung .
02.02.2018 13:18
Hallo Christian,
danke für dein bereits umfangreiches Troubleshooting. Ich habe mit ziemlicher Sicherheit das gleiche Problem mit meiner auf Linux basierenden 3cx Appliance. Es läuft stundenlang und irgendwann bekomme ich einen 403 (forbidden) zurück. Manchmal erholt sich der Trunk alleine, manchmal nicht. Sieht für mich auch nach DNS und deinem beschriebenen Phänomen aus. Ich nehme an, ihr habt auf dem besagten BIND die IP statisch dem Namen tel.t-online.de zugeornet. Wenn ja, würde mich interessieren, welche IP ihr nehmt und ob ihr noch weitere Änderungen vorgenommen habt. Ich würde sonst die IP einfach in der hosts eintragen.
Danke Matthias
02.02.2018 14:01
Hallo Matthias,
ich versuchs mal zusammen zu bekommen, ist ja schon eine Weile her. Leider nervt das Loadbalancing der Telekom extrem.
tel.t-online.de löst bei mir über die externen Rootserver auf 217.0.23.100 auf.
Wir haben auf jeder Anlage einen eigenen BIND in Standardkonfiguration laufen.
Als das Problem bestand, hatten wir einen Router mit einem DNSMASQ am laufen. Dieser hat die DNS Anfragen an die Telekom-DNS Server geFORWARDed.
Im Asterisk lief das dann folgendermaßen:
REGISTER/INVITE an den Server welcher unter "_sip._udp.tel.t-online.de" aufgelöst wurde
Asterisk löst danach neu auf, auf "tel.t-online.de"
"_sip._udp.tel.t-online.de" entsprach nicht "tel.t-online.de"
Das Gespräch kommt nicht zu stande, da dieser Server nichts von dem REGISTER weiß, daher meldet dieser FORBIDDEN.
bei der Auflösung über BIND/Rootserver löste "_sip._udp.tel.t-online.de" auf die selbe Adresse auf wie "tel.t-online.de".
Daher reichte die Installation vom BIND und das umlegen der resolv.conf auf 127.0.0.1
Man konnte das sehr schön im SIPLOG vom Asterisk sehen (sip set debug on).
Ich hoffe ich konnte helfen.
MFG Christian
Anbei noch die sip-conf für den telekom peer (verhindert auch andere BUGs):
[Telekom]
type=peer
insecure=invite
username=anonymous@t-online.de
secret=nopass
host=tel.t-online.de
fromdomain=tel.t-online.de
canreinvite=no
realm=tel.t-online.de
canreinvite=no
directmedia=no
nat=no
qualify=yes
context=default
insecure=port,invite
session-timers=refuse
dtmfmode=inband
videosupport=no
ignoresdpversion=yes
04.02.2018 09:15
Hallo Christian,
danke für deine schnelle Antwort. Ich denke, ich habe es jetzt hinbekommen. Der Trunk steht jetzt seit seit mehr als 48h stabil ohne Abbrüche.
Am Ende hast du mich auf den richtigen Weg gebracht. Das Problem ist, dass wenn die 3cx den Service Locator Record "_sip._udp.tel.t-online.de" anfragt, gibt es 2 Namen zurück. Der erste wird zwar präfertiert aber es kommt dennoch ab und zu vor, dass der 2. Server gefragt wird. Dieser weiß dann offensichtlich nichts von der Sitzung und gibt "403 forbidden" zurück.
nslookup
> set type=srv
> _sip._udp.tel.t-online.de
Server: 172.19.xxx.xxx (mein Nameserver)
Address: 172.19.xxx.xxx#53
Abfrage des SRV Records ergibt 2 Hosts
Non-authoritative answer:
_sip._udp.tel.t-online.de service = 0 5 5060 ims001.voip.t-ipnet.de.
_sip._udp.tel.t-online.de service = 1 5 5060 ims002.voip.t-ipnet.de.
Kurz die IP checken
Non-authoritative answer:
ims001.voip.t-ipnet.de canonical name = b-epp-001.isp.t-ipnet.de.
Name: b-epp-001.isp.t-ipnet.de
Address: 217.0.23.100
> ims002.voip.t-ipnet.de
Server: 172.19.xxx.xxx
Address: 172.19.xxx.xxx#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
> ims002.voip.t-ipnet.de
Server: 172.19.xxx.xxx
Address: 172.19.xxx.xxx#53
Ich habe mir jetzt so geholfen, dass ich
ims001.voip.t-ipnet.de.
ims002.voip.t-ipnet.de.
in meine /etc/hosts (unter Windows einfach im "windows/system32/drivers/etc/hosts") die beiden Server eingetragen habe und auf die selbe IP verweise (217.0.23.100).
Man kann natürlich auch auf seinem DNS Server eine Zone voip.t-ipnet.de anlegen und dort die beiden A-records pflegen.
Ich hoffe, die T-kom ändert nicht demnächst die IP Adressen
Viele Grüße
Matthias
02.02.2020 13:53
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Informieren Sie sich über unsere aktuellen Internet-Angebote.