Telekom SBC lehnt ausgehende Calls zeitweise mit 403 Forbidden ab
vor 8 Tagen
Hallo liebes Telekom-Hilft-Team, liebe Community,
ich brauche mal technische Hilfe bei einem Problem, welches mich beschäftigt. Ich habe das Telefon meiner 83-jährigen-Mutter nun auch über meinen SIP-Server (FreePBX / Asterisk 22.8.2) geroutet, um auch ihr meine ganzen "Abwehrmechanismen" (SPAM-Check via Tellows, Blacklists, CNAM-Lookup etc.) zu bieten. Das mit den Spam/Betrugsanrufen nimmt leider immer mehr Überhand.
Also terminiere ich auch ihren Amtanschluss (Telekom Maganta Zuhause) nun auf meinem Server, ihr Telefon ist dahingehend nun als Extension via TLS angebunden. Funktioniert so weit prima.
An meiner FreePBX habe ich noch meinen Telekom-SIP-Trunk (CompanyFlex) sowie einen Easybell-SIP-Trunk für meine Zwecke in Betrieb. Die laufen 100% problemfrei.
Nur der Magenta-Zuhause zickt gerne mal. Meine Mutter beschwert sich, dass sie zeitweise (!) nicht abgehend telefonieren kann. Sie bekommt von meiner FreePBX die Ansage, dass keine Leitungen frei seien. Eine Viertelstunde später funktioniert es oft wieder.
Die SIP-Traces beweisen, dass meinerseits eigentlich alles gut ist - manchmal lehnt der Telekom-SBC aber den ausgehenden Ruf mit "403 Forbidden" ab. Weiterer Fakt ist: Der Anschluss ist durchgehend registriert, alle REGISTER und OPTIONS laufen einwandfrei und ankommende Anrufe funktionieren auch in den Perioden, wo abgehende Anrufe abgewiesen werden.
Ich poste hier mal den SIP-Austausch eines fehlgeschlagenen Testanrufs gestern. Das Telekom-Team findet diesen vielleicht auf Grund der Call-ID ( Timestamp des Invite: 2026-05-06 14:32:10.451 UTC). Alle sensiblen Daten sind anonymisiert:
+492171AAAAA: Eigene Nummer des Telekom-Anschlusses
+492275DDDDD: Angerufene Nummer
mm.mm.mm.mm: (Feste Telekom-) IP meines FreePBX-Servers
Anmerkung: Da es hier keine wirkliche "Codebox" gibt und diese Forensoftware konsequent die Daten in den spitzen Klammern in den Sip-Messages wegwirft, habe ich die kleiner-größer-Zeichen durch [...] in den Traces ersetzt!
Logischerweise schickt meine FreePBX das Invite an die Telekom:
INVITE sip:+492275DDDDD@tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP mm.mm.mm.mm:6050;rport;branch=z9hG4bKPj46b9bcb5-8809-45e5-b9ab-b3a8a66753a8
From: [sip:+492171AAAAA@tel.t-online.de];tag=2d5ad287-d602-4b29-8d8f-f6918108eef6
To: [sip:+492275DDDDD@tel.t-online.de]
Contact: [sip:+492171AAAAA@mm.mm.mm.mm:6050]
Call-ID: 896542b0-219e-4029-bc89-d2d05b7a3d68
CSeq: 96 INVITE
Allow: OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, INFO, REFER
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800
Min-SE: 90
P-Asserted-Identity: [sip:+492171AAAAA@tel.t-online.de]
Max-Forwards: 70
User-Agent: FPBX-17.0.28(22.8.2)
Content-Type: application/sdp
Content-Length: 287
v=0
o=- 745733922 745733922 IN IP4 mm.mm.mm.mm
s=Asterisk
c=IN IP4 mm.mm.mm.mm
t=0 0
m=audio 10250 RTP/AVP 9 8 0 101
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:140
a=sendrecv
Dann kommt erwartungsgemäß ein "Trying":
SIP/2.0 100 Trying
Via: SIP/2.0/UDP mm.mm.mm.mm:6050;rport;branch=z9hG4bKPj46b9bcb5-8809-45e5-b9ab-b3a8a66753a8
From: [sip:+492171AAAAA@tel.t-online.de];tag=2d5ad287-d602-4b29-8d8f-f6918108eef6
To: [sip:+492275DDDDD@tel.t-online.de]
Call-ID: 896542b0-219e-4029-bc89-d2d05b7a3d68
CSeq: 96 INVITE
Content-Length: 0
... dem sofort das 403 Forbidden folgt:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP mm.mm.mm.mm:6050;received=mm.mm.mm.mm;rport=6050;branch=z9hG4bKPj46b9bcb5-8809-45e5-b9ab-b3a8a66753a8
From: [sip:+492171AAAAA@tel.t-online.de];tag=2d5ad287-d602-4b29-8d8f-f6918108eef6
To: [sip:+492275DDDDD@tel.t-online.de];tag=mavodi-0-264-bf1-1-0-_02A6A2F14EEC-2bf9-5405a700-68b7e13-69fb50ea-7a986
Call-ID: 896542b0-219e-4029-bc89-d2d05b7a3d68
CSeq: 96 INVITE
Content-Length: 0
Ich komme hier nun nicht weiter. Von meiner Seite her ist alles prima, warum aber hat der Telekom-SBC manchmal Phasen und rejected mit 403, während meistens einwandfrei funktioniert. Hier fehlt mir die Glaskugel, welche nur das Telekom-Team hat ;-)
Vielen Dank für eure Hilfe!
Marco
107
0
15
Das könnte Ihnen auch weiterhelfen
vor 2 Jahren
826
0
6
vor 13 Jahren
16840
0
7
vor 2 Jahren
265
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 8 Tagen
@jacotec1 : Ich habe keinerlei Ahnung von SIP und kann daher zu Deinen Protokolleinträgen nix sagen. Mir ist aber durch den Kopf geschossen, dass die Telekom ja SIP-TLS 1 und 2 anbietet. TLS funktioniert aber nicht immer, dann gibt es kein automatisches Fallback, nur wenn TLS 1 nicht funktioniert wird auf unverschlüsselt umgeschaltet. Könnte das der Grund sein?
Gruß Ulrich
0
6
von
vor 8 Tagen
@Micknik Hmmm, guter Punkt. Ich schaue morgen mal in mein SIP-Log (Homer), wie das letzte REGISTER vor dem Problem aussah. Zumindest auf der Debian-Ebene der FreePBX-VM funktionieren die SRV-Lookups, das hatte ich schon vorher getestet. Ob Asterisk jetzt hier einen komplett eigenen Lookup macht und sich nicht am OS bedient, kann ich aktuell nicht sagen.
Ich habe auch inzwischen einige Stimmen gelesen, dass das PAI-Feld bei den "Consumer-SBC" wohl gerne auch zu Problemen führt. Ist aber bis zum Gegenbeweis auch Hörensagen.
@UlrichZ Dein Screenshot könnte auch nur auf SRTP hinweisen, aber in der Regel macht SRTP ohne TLS auch wenig Sinn. Vor einem halben Jahr war TLS hier jedenfalls nicht sehr stabil. Ich werde aber mal eine der nicht verwendeten Nummern noch mal testweise auf TLS/SRTP umstellen, vielleicht hat sich das ja inzwischen gebessert. Die gängigen Provider-Templates (z.B. für die Auerswald-Anlagen) für Magenta Zuhause geben immer noch alle UDP ohne SRTP vor.
Danke erstmal für eure Anregungen! 🙏
0
von
vor 8 Tagen
Vor einem halben Jahr war TLS hier jedenfalls nicht sehr stabil.
@Micknik Hmmm, guter Punkt. Ich schaue morgen mal in mein SIP-Log (Homer), wie das letzte REGISTER vor dem Problem aussah. Zumindest auf der Debian-Ebene der FreePBX-VM funktionieren die SRV-Lookups, das hatte ich schon vorher getestet. Ob Asterisk jetzt hier einen komplett eigenen Lookup macht und sich nicht am OS bedient, kann ich aktuell nicht sagen.
Ich habe auch inzwischen einige Stimmen gelesen, dass das PAI-Feld bei den "Consumer-SBC" wohl gerne auch zu Problemen führt. Ist aber bis zum Gegenbeweis auch Hörensagen.
@UlrichZ Dein Screenshot könnte auch nur auf SRTP hinweisen, aber in der Regel macht SRTP ohne TLS auch wenig Sinn. Vor einem halben Jahr war TLS hier jedenfalls nicht sehr stabil. Ich werde aber mal eine der nicht verwendeten Nummern noch mal testweise auf TLS/SRTP umstellen, vielleicht hat sich das ja inzwischen gebessert. Die gängigen Provider-Templates (z.B. für die Auerswald-Anlagen) für Magenta Zuhause geben immer noch alle UDP ohne SRTP vor.
Danke erstmal für eure Anregungen! 🙏
@jacotec1
Was soll das denn heißen? Funktioniert bei mir in einem Yealink Telefon seit der Deaktivierung der MediaSec Notwendigkeit seit langem absolut stabil.
0
von
vor 8 Tagen
@Micknik Das soll heißen: Es war mein erster Approach, weil es ja auch bei meinem Company Flex und dem Easybell absolut State Of The Art ist. Beim MagentaZuhause war der Anschluss nach einem Tag nicht mehr anrufbar, kam gar nicht mehr bis zur Asterisk durch. Registrierung lief auch auf Offline - aber erst nach längerer Zeit.
Was nicht heißen soll, dass meine Konfig damals perfekt war. Deshalb hab ich gerade eine unbenutze (Test)Nummer wieder auf TLS/SRTP umgestellt, funktioniert erstmal einwandfrei- hatte es aber seinerzeit auch über eine gewisse Zeit. Mal sehen, was es über die nächsten 2-3 Tage macht. Ich werde berichten.
0
Uneingeloggter Nutzer
von
vor 5 Tagen
Bei mir klappen derzeit nur eingehende Anrufe mit Linphone, ausgehend immer 403 (baresip) oder inkompatible Medienparameter (Linphone).
Beides Android. Mein Handy ist entweder im heimischen WLAN oder per VPN (klappt auch per VPN , bekomme Anrufe).
Was evtl. das Problem ist: Ich habe 2 Nummern zum SIP-Trunk zugeordnet, ich weiss daher nicht wie Linphone/Baresip eine ausgehende Nummer sendet. Gemini meint ich soll from_header setzen.
Ich habe noch einen SIP-Arbeitsplatz eingerichtet mit nur einer Nummer, den bekomme ich aber nichmal angemeldet.
Anmeldung klappt mit den SIP-Trunk Daten von Companyflex, Proxy, kein STUN.
Ich wäre für Unterstützung zu Codecs die passen und dem 403 Fehler sehr dankbar, es gibt absolut 0 Tutorials wie man einfach mit einem Android-Telefon den Anschluss nutzen kann was ich sehr verwirrend finde. Nicht jeder braucht eine Telefonanlage - ich und Kunden haben einfach ein Android Phone und gut, keine Fritzbox, keinen Speedport oder Ähnliches da Firewall und Modem alles selbst gebaut / genutzt wird.
Die üblichen Tipps ich soll doch einfach irgendeiner 3CX, Fritzbox oder sonstwas nehmen bringen mir absolut NICHTS - ich will einfach nur wissen wie man es selbst richtig macht und es gibt hier leider null Infos zu.
0
7
von
vor 5 Tagen
Wenn Du nix zum Problemlösen beitragen kannst würde ich Dich bitten den Thread einfach zu ignorieren.
Warum so zickig? Dein Problem hat einfach nichts mit dem des TE zu tun, daher ist es hier Off-Topic
0
von
vor 5 Tagen
@Richard Wachler
https://www.telekom.de/hilfe/downloads/1tr119
Baresip scheint schon gar nicht den SIP RFC Standard der Telekom zu unterstützen
0
von
vor 5 Tagen
Ich fände einen eigenen Thread hier auch passender, aber:
Aber bitte das jetzt in einem eigenen Thread diskutieren 😎
Uneingeloggter Nutzer
von
Uneingeloggter Nutzer
von