SIP/2.0 503 unsupported user equipment, firmware update required

4 years ago

Hallo Telekom Team,

 

gibt es aktuell eine Störung bei den Sip Servern? Oder wurde vielleicht etwas im Umgang mit kundeneigenen Telefonanlagen geändert? Bin gerade am schauen wo es klemmen könnte.

 

Seit 2021-10-12 01:30 geben die Telekom SIP Server mir die Meldung "SIP/2.0 503 unsupported user equipment, firmware update required" zurück. Die 500er Codes sind ja eigentlich servseitige Probleme, werde aber das Gefühl nicht los, dass die Meldung auf die Client Seite abziehlt.

 

[Oct 13 19:08:07] NOTICE[590] chan_sip.c: -- Registration for '06.....1234567890@tel.t-online.de' timed out, trying again (Attempt #7)
[Oct 13 19:08:07] NOTICE[590] chan_sip.c: -- Registration for '06.....1234567890@tel.t-online.de' timed out, trying again (Attempt #7)
[Oct 13 19:08:07] VERBOSE[590] chan_sip.c: Got SIP response 503 "unsupported user equipment, firmware update required" back from 217.0.146.5:5060
[Oct 13 19:08:07] VERBOSE[590] chan_sip.c: Got SIP response 503 "unsupported user equipment, firmware update required" back from 217.0.146.5:5060

 

Die Anlage ist eine Asterisk auf aktuellem Patchstand (LTS v16). Betreibe die bestehende Konfiguration schon eine ganze Weile, da wurde auch kürzlich nichts geändert.

Habe jetzt seit den Problemen sicherheitshalber nochmal die aktuellste Version (v16.22) gebaut. Keine Änderungen.

Grunsätzliche Fehlfunktionen kann ich auch ausschließen, da der Sipgate Anschluss auf der Anlage fehlerfrei funktioniert.

 

Wäre über einen hilfreichen Tipp oder Hinweis auf eine bestehende Störung dankbar.

 

Freundliche Grüße

3970

29

    • 4 years ago

      Hallo @username_michael 

       

      Schau Mal hier:

      https://www.telekom.de/hilfe/festnetz-internet-tv/ip-basierter-anschluss/einstellungen-fuer-die-ip-telefonie-mit-anderen-clients?samChecked=true 

       

      Vor allem den ersten Punkt bei den Hinweisen beachten, dass die DNS-Anfrage über SRV-Records erfolgt.

      4

      Answer

      from

      4 years ago

      UPDATE:

       

      Strange, also wenn ich statt dem ersten Prio 10 Server aus der SRV Antwort den zweiten Prio 20 oder dritten (30) erzwinge geht es problemlos...

       

      SRV _sip._udp.tel.t-online.de.
      30 0 5060 d-epp-110.edns.t-ipnet.de.  -> funktioniert     
      20 0 5060 h2-epp-110.edns.t-ipnet.de.  -> funktioniert
      10 0 5060 ffm021-l01-mav-pc-rt-001.edns.t-ipnet.de. -> SIP 503 Error

       

       Manipuliere dann wohl erstmal die DNS Einträge, solange bis der ffm021-l01-mav-pc-rt-001.edns.t-ipnet.de mit der 217.0.146.5 wieder normal tut. Scheint dann ja nicht auf meiner Seite zu liegen, wenn die zweite und dritte IP im Verbund funktionieren.

      Answer

      from

      4 years ago

      Hi, ich würde das gerne nochmal hochschieben. Das Problem mit dem einen Server in der Verteilung besteht immer noch. Bin aktuell fix auf Pos. 20 eingestellt. Das ist aber natürlich blöd, wenn sich hier etwas ändert.

       

      Ich denke irgendetwas gefällt speziell dem ffm021-l01-mav-pc-rt-001.edns.t-ipnet.de an der Kommunikation mit unserer Anlage nicht, aber eben nur dieser Server. Die anderen lassen uns ganz normal registrieren.

       

      Habt ihr vielleicht die Möglichkeit in Erfahrung zu bringen welche Ursache diese 503 Antwort hat, bzw. was ich tun kann um dies zu verhindern? Scheint ja jetzt erst seit 2-3 Wochen aufzutreten. Finde in Error Code Listen wie Wikipedia oder RFC auch das "unsupported user equipment, firmware update required" nirgends beschrieben.

      Answer

      from

      4 years ago

      Hi,

       

      ich habe seit 14. / 15. Oktober genau das gleiche Problem...

       

       

      3.006 _sip._tcp.tel. SRV query_job for _sip._tcp.tel.t-online.de completed, 3 of 3 total entries selected:
      14:36:43.006 _sip._tcp.tel. 0: SRV 10 0 5060 ffm021-l01-mav-pc-rt-001.edns.t-ipnet.de (-)
      14:36:43.006 _sip._tcp.tel. 1: SRV 20 0 5060 d-epp-110.edns.t-ipnet.de (-)
      14:36:43.006 _sip._tcp.tel. 2: SRV 30 0 5060 h2-epp-110.edns.t-ipnet.de (-

       

      14:40:31.006 pjsua_core.c .RX 447 bytes Response msg 503/REGISTER/cseq=22853 (rdata097E8234) from TCP 217.0.146.5:5060:
      SIP/2.0 503 NAT scenario temporarily not supported

      Unlogged in user

      Answer

      from

    • 3 years ago

      Hallo @username_michael und SnapStef,

      wir fragen gerne für euch intern einmal nach. Sobald wir eine Antwort haben, melden wir uns wieder hier im Thread. Bis dahin wäre es super, den Workaround von @username_michael zu nutzen.

      Gruß
      Sören M.

      7

      Answer

      from

      3 years ago

      SnapStef

      Nur TCP geht nicht..

      Nur TCP geht nicht..
      SnapStef
      Nur TCP geht nicht..

      Wobei der Hostname vom SRV 0 auch irgendwie merkwürdig ist.

      Answer

      from

      3 years ago

      Super vielen Dank für die Unterstützung. Werde ich auf jeden Fall ausprobieren.

      Muss gestehen, dass ich TLS seit der initialen Einrichtung nicht mehr ausprobiert habe. Damals ging es noch nicht. Cool zu sehen, dass sich hier etwas getan hat!

      Wäre jetzt auch gar nicht von allein auf die Idee gekommen nochmal auszuprobieren, ob es inzwischen funktioniert...

      Melde mich dann nochmal zurück.

      Answer

      from

      3 years ago

      @username_michael 

      Welchen DNS-Server nutzt du?

       

      Unlogged in user

      Answer

      from

    • 3 years ago

      Wow, echt super, wie ihr euch gegenseitig unterstützt. Es scheint ja auch die ein oder andere Lösung dabei gewesen zu sein. Meine Anfrage läuft noch. Wie versprochen, sobald ich da eine Rückmeldung habe, melde ich mich.

      Gruß
      Sören M.

      0

    • Accepted Solution

      accepted by

      3 years ago

      Hi in die Runde,

      ich habe in der Zwischenzeit eine Rückmeldung bekommen, dass in unserem Netz keine Umstellung der SIP Registration stattgefunden hat. Hier müsste ansonsten individuell auf den Anschluss geschaut werden, sprich eine Störungsmeldung erstellt werden.

      So wie ich es aber lese, haben @username_michael und @SnapStef nun eine Lösung gefunden und ihr könnt die IP-Telefonie über eure Geräte wieder nutzen.

      Gruß
      Sören M.

      0

    • 3 years ago

      Dieser Server verlangt den SIP-Header User-Agent.

       

      Lasse ich diesen Header weg, erhalte ich noch heute ebenfalls „503 unsupported user equipment, firmware update required“. Anbei zwei XML-Dateien mit denen man das nachstellen kann, z. B. in Debian bzw. Ubuntu über

      sipp $(dig +short ffm021-l01-mav-pc-rt-001.edns.t-ipnet.de. A) -m 1 -sf "./bindings-remove-all.txt" -s "+49 + Ortsvorwahl + Rufnummer" -ap "Dein Passwort"

       

      Leider erlaubt die Foren-Software hier kein „>“ in angehängten Text-Dateien. Aber jenes Zeichen ist nötig, um ein XML-Element zu schließen. Ich habe das Zeichen entfernt und durch „Y“ ersetzt. Wer also das nachstellen will, muss die Text-Datei vorher noch bearbeiten und alle „Y“ wieder durch „>“ ersetzen. Oder hätte es einen schöneren Weg gegeben?

       

      username_michael

      Digium Asterisk

      Digium Asterisk
      username_michael
      Digium Asterisk

      Bitte schau in Deine Konfigurationsdatei „sip.conf“. Dort dürftest Du den Parameter „useragent=“ setzen. Weil das ein leerer Wert ist, schickt der alte Channel-Driver „chan_sip“ gar keinen User-Agent. Mein Tipp: Setz es auf irgendwas, z. B. „useragent=yes“ oder wie ich auf „useragent = siehe Thread 5375212 auf Telekom hilft“.

       

      Sören M.

      Hier müsste […] individuell auf den Anschluss geschaut werden, sprich eine Störungsmeldung erstellt werden.

      Hier müsste […] individuell auf den Anschluss geschaut werden, sprich eine Störungsmeldung erstellt werden.
      Sören M.
      Hier müsste […] individuell auf den Anschluss geschaut werden, sprich eine Störungsmeldung erstellt werden.

      Der Fehler ist nicht mein Anschluss sondern generell dieser eine Server (bei mir IP-Adresse 217.0.146.5; nur innerhalb der Telekom Deutschland, nicht öffentlich erreichbar). Wenn man sich wie die Telekom Deutschland für ein „non-transparent load balancing“ entscheidet, haben sich alle Server gleich zu verhalten. Folglich müssten entweder alle Server dieses Feld verlangen oder keiner. Folglich müsste die Telekom Deutschland schauen, wie es passieren konnte, dass ein Server mit einer anderen Konfiguration live gehen konnte (und warum dies über Monate hinweg nicht korrigiert wurde).

       

      Kümmert Ihr Euch darum? Wenn nicht und ich es machen muss, wisst Ihr irgendein Kennwort/Zauberwort, damit ich nicht erst wochenlang meine DSL-Leitung durchgemessen bekomme, sondern dass das gleich als Software-Bug auf der Abstraktionsebene „VoIP/SIP“ bzw. „VoIP/Load-Balancing“ verbucht wird?

      bindings-remove-all-works.txt

      bindings-remove-all.txt

      13

      Answer

      from

      3 years ago

      Zwei Wochen später … irgendwas Neues, fehlt noch etwas, müsste ich noch irgendwas nachreichen?

       

      username_michael

      Ist mir überhaupt nicht aufgefallen

      Ist mir überhaupt nicht aufgefallen
      username_michael
      Ist mir überhaupt nicht aufgefallen

      Das ist der Nachteil mit Menschen-lesbaren Protokollen wie HTTP oder SIP. Wir Menschen bügeln das schon bei der Wahrnehmung aus. Ein Computer-Programm beleibt stur bei seiner Programmierung. Daher habe ich mir angewöhnt, bei solchen Protokollen die Augen zu zu machen, einfach alles blind in einen Protokoll-Analyzer bzw. Test-Aufbau rüber zu kopieren. Und dann Zeile für Zeile auszutauschen / zu ändern. Ich hätte die Anführungszeichen nämlich auch nie gesehen, nie im Leben.

       

      Freut mich, dass ich helfen konnte bzw. dass Du es bestätigen konntest (hätte ja auch noch was Drittes sein können). Für Dich dürfte es gelöst sein. Ist auch keine übliche Asterisk-Konfiguration.

       

      Aber angeblich soll die Tage das Landesweit ausgerollt werden. Wäre schön, wenn vorher geklärt wäre:

      1. Ist das mit der Pflicht zum User-Agent absichtlich geschehen und wenn ja auf welche Telekom externe Spezifikation beruft sich das?
      2. Sind die alternativen IP-Adressen für Load-Balancing (also müsste alle gleich konfiguriert sein) oder für Fail-Over (also als Spielweise für die Telekom, um unterschiedliche Konfigurationen zu testen) gedacht? Falls Letzteres, müsste die Telekom Deutschland das Verhalten nach einem SIP-Status 5xx irgendwo genauer dokumentieren.
      3. Warum lief der Thread hier (falls Fail-Over) bzw. die Konfiguration (falls Load-Balancing) über sechs Monate lang?
      4. Warum konnte das Telekom-Hilft-Team nicht selbst leisten, was die Ursache war?

      Ich habe wirklich gerne geholfen und das zu ergründen hat ja auch Spaß gemacht. Aber auch mich hat das Zeit gekostet und damit mir Arbeit bereitet. Aus solchen Dingen sollte man wenigstens lernen (Fehler-Kultur), damit das beim nächsten Mal besser läuft oder vielleicht sogar ganz vermieden werden kann.

      Answer

      from

      3 years ago

      @kimLui 

       

      Vielen Dank für dein ausführliches Feedback.

      Wir haben bisher leider noch keine neuen Infos erhalten. Die von dir gestellten Fragen, kann ich leider nicht beantworten, habe ich aber noch mal weitergegeben. Hab bitte noch ein wenig Geduld. 

       

      Viele Grüße 

      Timur K. 

      Answer

      from

      3 years ago

      @kimLui 

       

      Wir haben nun noch mal eine Rückmeldung erhalten. 

      Leider keine allzu erfreuliche 😕 Es gibt dazu tatsächlich keine Infos. Die einzigen Änderungen in der letzten Zeit, was die Telefonie betrifft ist, dass die Telefonie mit einer veralteten Firmware auf der Fritzbox nicht mehr funktioniert 🙏 Weitere Infos kann ich dir da leider nicht geben. Ich weiß, dass ist wahrscheinlich nicht die gewünschte Antwort 😓

       

      Viele Grüße 

      Timur K. 

      Unlogged in user

      Answer

      from

      Unlogged in user

      Ask

      from

      This could help you too

      Solved

      in  

      479

      4

      2

      1 year ago

      296

      0

      4

      Solved

      in  

      192

      0

      1

      Solved

      in  

      1016

      0

      2