Netzseitiger Abbruch (cause=41) bei Rufumleitung im Amt von PŸUR zu Telekom
vor 2 Monaten
Hallo zusammen,
ich habe ein sehr hartnäckiges, reproduzierbares Routing-Problem bei netzübergreifenden Rufumleitungen und hoffe auf die Unterstützung der Telekom-Netztechnik.
Ich habe im Büro einen Kabelanschluss von PŸUR, da dort leider keine schnelle Leitung der Telekom verfügbar ist. PŸUR ist leider total unkooperativ. Nach dem Motto: "können wir leider nichts machen". Ich hoffe daher, dass mir hier jemand weiterhelfen kann:
Das Fehlerbild: Eingehende Anrufe auf meinem PŸUR-Festnetzanschluss (HLKomm / Primacom) werden per "Umleitung im Amt (AWS sofort)" an meinen Telekom Anschluss zuhause weitergeleitet. Das Zielgerät klingelt ganz normal. Exakt in der Millisekunde, in der ich den Anruf annehme, bricht die Verbindung netzseitig ab. Der Anrufer erhält sofort ein Besetztzeichen.
Fehlereingrenzung & Setup:
Ich habe den Traffic zuhause mit FreePBX mitgeschnitten (Trace siehe Anhang). Das FreePBX diente nur zur Diagnose. Ist mein Gigaset-Telefon direkt am Telekom SIP-Trunk registriert, bricht es exakt genauso ab. Mein lokales Netz ist also unschuldig.
Eine Weiterleitung von der PŸUR-Nummer auf mein Telekom-Mobilfunktelefon liefert exakt den gleichen Fehler (Abbruch bei Rufannahme).
Eine Weiterleitung auf einen alten Telekom-Privatkunden-Festnetzanschluss (Eltern) funktioniert fehlerfrei! Das Problem tritt also nur bei strenger gerouteten Plattformen (Mobilfunk-Core & SIP-Trunk) auf.
Die betroffene PŸUR-Nummer gehörte vor Kurzem einem anderen Inhaber (ebenfalls bei PŸUR), vor dieser internen Umschreibung funktionierte die Umleitung noch.
Was der SIP-Trace am Telekom-SIP-Trunk zeigt:
Der Call wird sauber vom Telekom-SBC (
217.0.146.69) zugestellt, inklusive korrekter Signalisierung der Umleitung (History-Info: cause=302).Meine Anlage nimmt an und quittiert vorschriftsmäßig mit einem
200 OK(inkl. SDP / Audio-Codecs).Unmittelbar danach wirft der Telekom-SBC die Verbindung weg und sendet ein
BYEmit dem Fehler:Reason: Q.850;cause=41;text="Temporary failure"
Meine Vermutung: Da der Abbruch exakt beim 200 OK (Start Interconnect-Billing / Mediendurchschaltung) passiert, sendet PŸUR/HLKomm eventuell SIP-Header, die von der Telekom-Firewall bei SIP-Trunks und im Mobilfunk als fehlerhaft oder unautorisiert abgewiesen werden. Möglicherweise fehlt aufgrund der internen Vertragsübernahme bei PŸUR ein Routing-Tag, oder ein Anti-Spoofing-Filter der Telekom lehnt das Durchreichen der Anrufernummer bei der AWS durch das Fremdnetz ab.
Könnte sich jemand vom "Telekom hilft"-Team anhand der Call-ID im untenstehenden Log den Traffic am Session Border Controller anschauen, um zu prüfen, warum das Telekom-Netz nach dem 200 OK den cause=41 wirft?
Vielen Dank im Voraus!
Jens
testanruf-anon.txt
109
0
10
Das könnte Ihnen auch weiterhelfen
vor 6 Jahren
1086
0
4
vor 4 Jahren
3498
0
4
in
189
0
3
Beliebte Tags letzte 7 Tage
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.
vor 2 Monaten
Ich habe den Traffic zuhause mit FreePBX mitgeschnitten (Trace siehe Anhang). Das FreePBX diente nur zur Diagnose. Ist mein Gigaset-Telefon direkt am Telekom SIP-Trunk registriert, bricht es exakt genauso ab. Mein lokales Netz ist also unschuldig.
Eine Weiterleitung von der PŸUR-Nummer auf mein Telekom-Mobilfunktelefon liefert exakt den gleichen Fehler (Abbruch bei Rufannahme).
Hallo zusammen,
ich habe ein sehr hartnäckiges, reproduzierbares Routing-Problem bei netzübergreifenden Rufumleitungen und hoffe auf die Unterstützung der Telekom-Netztechnik.
Ich habe im Büro einen Kabelanschluss von PŸUR, da dort leider keine schnelle Leitung der Telekom verfügbar ist. PŸUR ist leider total unkooperativ. Nach dem Motto: "können wir leider nichts machen". Ich hoffe daher, dass mir hier jemand weiterhelfen kann:
Das Fehlerbild: Eingehende Anrufe auf meinem PŸUR-Festnetzanschluss (HLKomm / Primacom) werden per "Umleitung im Amt (AWS sofort)" an meinen Telekom Anschluss zuhause weitergeleitet. Das Zielgerät klingelt ganz normal. Exakt in der Millisekunde, in der ich den Anruf annehme, bricht die Verbindung netzseitig ab. Der Anrufer erhält sofort ein Besetztzeichen.
Fehlereingrenzung & Setup:
Ich habe den Traffic zuhause mit FreePBX mitgeschnitten (Trace siehe Anhang). Das FreePBX diente nur zur Diagnose. Ist mein Gigaset-Telefon direkt am Telekom SIP-Trunk registriert, bricht es exakt genauso ab. Mein lokales Netz ist also unschuldig.
Eine Weiterleitung von der PŸUR-Nummer auf mein Telekom-Mobilfunktelefon liefert exakt den gleichen Fehler (Abbruch bei Rufannahme).
Eine Weiterleitung auf einen alten Telekom-Privatkunden-Festnetzanschluss (Eltern) funktioniert fehlerfrei! Das Problem tritt also nur bei strenger gerouteten Plattformen (Mobilfunk-Core & SIP-Trunk) auf.
Die betroffene PŸUR-Nummer gehörte vor Kurzem einem anderen Inhaber (ebenfalls bei PŸUR), vor dieser internen Umschreibung funktionierte die Umleitung noch.
Was der SIP-Trace am Telekom-SIP-Trunk zeigt:
Der Call wird sauber vom Telekom-SBC (
217.0.146.69) zugestellt, inklusive korrekter Signalisierung der Umleitung (History-Info: cause=302).Meine Anlage nimmt an und quittiert vorschriftsmäßig mit einem
200 OK(inkl. SDP / Audio-Codecs).Unmittelbar danach wirft der Telekom-SBC die Verbindung weg und sendet ein
BYEmit dem Fehler:Reason: Q.850;cause=41;text="Temporary failure"Meine Vermutung: Da der Abbruch exakt beim
200 OK(Start Interconnect-Billing / Mediendurchschaltung) passiert, sendet PŸUR/HLKomm eventuell SIP-Header, die von der Telekom-Firewall bei SIP-Trunks und im Mobilfunk als fehlerhaft oder unautorisiert abgewiesen werden. Möglicherweise fehlt aufgrund der internen Vertragsübernahme bei PŸUR ein Routing-Tag, oder ein Anti-Spoofing-Filter der Telekom lehnt das Durchreichen der Anrufernummer bei der AWS durch das Fremdnetz ab.Könnte sich jemand vom "Telekom hilft"-Team anhand der Call-ID im untenstehenden Log den Traffic am Session Border Controller anschauen, um zu prüfen, warum das Telekom-Netz nach dem
200 OKdencause=41wirft?Vielen Dank im Voraus!
Jens
Bei dem Fehlerbilld bezweilfe ich dass die Telekom dir helfen kann wenn das sowohl auf Festnetz als auch Mobilfunk passiert. Ich fürchte da muss dein anderer Anbieter ran.
0
vor 2 Monaten
Ich glaube auch, dass letztendlich nur PYUR des Problem lösen kann. Ich hoffe aber, dass seitens der Telekom geprüft werden kann, warum der Anruf mit "cause=41" abgeworfen wird.
0
3
von
vor 2 Monaten
Ich hoffe aber, dass seitens der Telekom geprüft werden kann, warum der Anruf mit "cause=41" abgeworfen wird.
Ich glaube auch, dass letztendlich nur PYUR des Problem lösen kann. Ich hoffe aber, dass seitens der Telekom geprüft werden kann, warum der Anruf mit "cause=41" abgeworfen wird.
Das sollte klappen, halte uns gerne auf dem laufenden
0
von
vor 2 Monaten
Hallo @jenlau,
vielen Dank für die Nachricht auf unserer Community. Ich bedauere, leider kann ich dir an dieser Stelle nicht weiterhelfen und möchte dich bitten, dich an den zuständigen Anbieter zu wenden. Bei weiteren, vertragsbezogenen Fragen stehe ich dir gerne jederzeit zur Verfügung.
Viele Grüße,
Damra S.
0
von
vor 2 Monaten
Hallo @Damra S.
das mit dem "zuständigen Anbieter" ist wie immer so eine Sache. Ich bin sicher kein Profi in dem Bereich und lasse mich gerne eines Besseren beleren aber ich vermute schon, dass Seitens der Telekom hier unterstützt werden kann. Dieses
BYEmit dem Fehler:Reason: Q.850;cause=41;text="Temporary failure"scheint ja vom Telekom Server zu kommen. Demnach müsstet ihr ja herausbekommen können, warum genau dieser Fehler geworfen wird.Ich wäre wirklich extrem Dankbar, wenn sich das mal jemand im Detail anschauen kann. Ich habe wirklich mein möglichstes getan um bei der Fehlersuche zu unterstützen und bin mit meinem Latain am Ende. Ich müsste PYUR einfach ganz konkret mitteilen können, was da schief läuft. Sowas wie "Die Telekom beendet den Anruf mit cause=41 weil ihr dies oder jenes falsch macht, bitte korrigiert das". Ich kann auch gerne noch die pcap-Datei schicken wenn das die Analyse einfacher macht.
Viele Grüße
Jens
0
Uneingeloggter Nutzer
von
vor 2 Monaten
Hallo @jenlau,
vielen Dank für das sehr freundliche Telefonat.
Schick mir gern das Protokoll per privater Nachricht.
Dann stelle ich eine Störung ein und wir überprüfen es.
Lieben Gruß, Melanie
0
0
vor einem Monat
Hallo Zusammen
Leider konnte mir man seitens Telekom auch nicht sagen, was
Reason: Q.850;cause=41;text="Temporary failure"bedeutet :(Ich bin echt ratlos und möchte mich mit einem "da können wir auch nichts machen" von PYUR nicht abfinden.
Hat sonst noch jemand eine Idee?
Viele Grüße
Jens
0
1
von
vor einem Monat
@jenlau
Den Testanruf würde ich testweise mal von einem Festnetzanschluss der Telekom starten, aber nicht von Deinem aus.
Dann würde ich mal dafür sorgen, dass keine privaten IP-Adressen im SIP-Header auftauchen.
Und als Test wäre das Ganze auch mit aktiver Verschlüsselung interessant, kann man dann zwar nichts sinnvolles tracen aber trotzdem sinnvoll.
0
Uneingeloggter Nutzer
von
vor einem Monat
Nachtrag: Mein Hauptproblem ist ja eigentlich, dass mein Anliegen von der Pyur- Geschätskunden-Hotline nicht ernst genommen wird. Ich glaube noch nicht mal, dass es überhaupt an irgend jemanden weitergeleitet wurde, der da wirklich etwas herausfinden könnte. Vllt. hat dazu noch jemand nen Tipp, wie ich das bei Pyur eskalieren könnte?
0
1
von
vor einem Monat
Vllt. hat dazu noch jemand nen Tipp, wie ich das bei Pyur eskalieren könnte?
Nachtrag: Mein Hauptproblem ist ja eigentlich, dass mein Anliegen von der Pyur- Geschätskunden-Hotline nicht ernst genommen wird. Ich glaube noch nicht mal, dass es überhaupt an irgend jemanden weitergeleitet wurde, der da wirklich etwas herausfinden könnte. Vllt. hat dazu noch jemand nen Tipp, wie ich das bei Pyur eskalieren könnte?
Beschwerde inkl. Kündigung, dann wird dein Anliegen ggfs ernst genommen
0
Uneingeloggter Nutzer
von
Uneingeloggter Nutzer
von