AW: SIP/2.0 503 unsupported user equipment, firmware update required

[#1]

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

[#2 · Accepted solution]

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.

[#3]

Hallo @username_michael 

Schau Mal hier:

https://www.telekom.de/hilfe/festnetz-internet-tv/ip-basierter-anschluss/einstellungen-fuer-die-ip-t... 

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

[#4]

Danke @Patti Müller  für den Hinweis.

Hm ich behaupte mal vorsichtig, dass dies nicht das Problem sein dürfte. Haben eben nochmal geprüft.

Die Anlage fragt den SRV Rekord ab und kommt dadurch auf den Server, welcher oben in den Logs kontaktiert wird.

[1au] SRV? _sip._udp.tel.t-online.de. (54)
3/0/1 SRV ffm021-l01-mav-pc-rt-001.edns.t-ipnet.de.:5060 10 0, SRV h2-epp-110.edns.t-ipnet.de.:5060 20 0, SRV d-epp-110.edns.t-ipnet.de.:5060 30 0 (205)

+ [1au] A? ffm021-l01-mav-pc-rt-001.edns.t-ipnet.de. (69)
1/0/1 A 217.0.146.5 (85)

Der tel.t-online.de liefert auch gar nichts mehr zurück auf eine A Abfrage.

Glaube da klemmt es aktuell nicht.

[#5]

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.

[#6]

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.

[#7]

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

[#8]

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.

[#9]

Vielen Dank Sören. Mit meiner Software MicroSIP funktioniert der Workaround leider nicht.

Insofern wäre ich für eine Lösung auf Eurer Seite dankbar

[#10]

@SnapStef 

Schon mal mit aktiviertem STUN-Server in MicroSIP versucht?

Als Transport schon mal TLS versucht?

[#11]

@SnapStef 

Ich habe noch einen.

Welchen DNS-Server hast du in MicroSIP eingetragen?

[#12]

Vielen Dank. Mit TLS hat es funktioniert. Anscheinend geht auch UDP. Nur TCP geht nicht...was eingestellt war

[#13]

---

@SnapStef  schrieb:
Nur TCP geht nicht..

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

[#14]

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.

[#15]

@username_michael 

Welchen DNS-Server nutzt du?

[#16]

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.

[#17 · Accepted solution]

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.

[#18]

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  schrieb:
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.   schrieb:
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?

[#19]

Guten Morgen @kimLui!

---

@kimLui  schrieb:

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?

---

Gut aufgearbeitet & du bist bei dem Thema besser am Puls, als ich es je sein könnte. Daher hake ich auch direkt intern nach und schreibe dir, wenn ich mehr weiß. Hab' schöne Ostertage.

Greetz

Stefan D.

[#20]

Hallo zusammen,

danke für Eure Antworten. Dass der Server sich anders verhält geht mir genauso. Gleiche IP (217.0.146.5) wie auch zu Beginn des Tickets.

Hatte aber bisher nicht im Detail geschaut und mich mit dem umstellen der DNS Einträge begnügt. Am 24.03. war er wieder für einen Zeitraum in die Verteilung gerutscht, ist aber inzwischen wieder draußen.

Ich kann den Fix mit dem UserAgent Feld aber nicht bestätigen. Schicke den bereits mit seit ich mein System aufgesetzt habe.

Habe parallel ein zusätzliches, temporäres Register mit pjsip (andere=chan_sip) aktiviert, hier klappt die Registrierung an dem Server. Habe darüber hinaus aber noch keine Anrufe o.ä. probiert.

Soweit ich es sortieren kann, scheint der einzige Unterschied in meinem REGISTER Request das Feld "Supported: replaces, timer" (chan_sip) und das Feld "Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER" (pjsip) zu sein. Feld "User-Agent: Asterisk..." ist bei beiden gesetzt.

Register Request an 217.0.146.5 mit "Allow:..." geht durch, mit "Supported:" wird abgelehnt: SIP/2.0 503 unsupported user equipment, firmware update required

Beide Varianten funktionieren problemlos bei den anderen Servern, beispielsweise 217.0.28.33. Habe auch einen anderen SIP Provider angebungen (sipgate), bei dem die gleichen Anfragen ebenfalls problemlos funktionieren.

Soweit ich es verstehe ist aber nach RFC 3261 beides valide in Requests (R), bzw. optional.

			  Header field       		   where	proxy ACK BYE CAN INV OPT REG
				  ___________________________________________________________
					......
					  Alert-Info             180     ar    -   -   -   o   -   -
					  Allow                   R            -   o   -   o   o   o
					  Allow                  2xx           -   o   -   m*  m*  o
					  Allow                   r            -   o   -   o   o   o
					  Allow                  405           -   m   -   m   m   m
					....
			   Supported                   R                -   o   o   m*  o   o
			   Supported                  2xx               -   o   o   m*  m*  o
			   Timestamp                                    o   o   o   o   o   o
				...

[#21]

@kimLui 

Die lieben Menschen aus dem Fachbereich möchten es sich detailliert anschauen. Magst du mir dazu deine Rufnummer ins Profil ergänzen & dann eben hier was schreiben, damit ich es auch sehe? Wäre toll, danke dir.

Greetz

Stefan D.

[#22]

@Stefan D.  schrieb:
Magst du mir dazu deine Rufnummer ins Profil ergänzen & dann eben hier was schreiben, damit ich es auch sehe?

Upps, ja meine E-Mail-Benachrichtigung hat geklemmt. Ja, das Verhalten ist Stand heute immer noch so. Weiß zwar nicht, warum ein Telefon-Anschluss dafür nötig ist – müsste eigentlich alle in Rhein-Main betreffen – aber habe die betroffene Rufnummer eben unter Kundendaten, Weitere Informationen hinzugefügt. Aber unter der Nummer wird niemand ran gehen. Wenn auch das nötig ist, bitte sagen.

@username_michael  schrieb:
Supported: replaces, timer (chan_sip)

OK. Welche Asterisk-Version nutzt Du aktuell genau bzw. was steht im SIP? Immer noch Digium Asterisk 16.22? Version 13 mit chan_sip klappt hier bei mir. Vielleicht erkennt der Server, dass Du chan_sip benutzt, mag aber Deine Version nicht. Hast Du bereits probiert, den useragent=Asterisk PBX zu setzen, also die Version nicht mitzuliefern? Oder es ist bei Dir der nicht ein Parameter sondern der Wert innerhalb eines Parameters. Kannst Du mir das komplette REGISTER über eine private Nachricht schicken?

[#23]

Aktuell noch auf 16.22 ja, kann mal einen Versuch machen die 13 zu bauen. Normal betreiben wollte ich die aber nicht unbedingt. Bekommt ja keine Updates mehr. Muss sicherlich auch in der Config etwas angepasst werden dann.

Schicke das Field useragent als "Asterisk PBX" raus. Eine Versionsnummer hatte ich ebenfalls probiert im Zuge von Tests (Asterisk PBX 16.22.0), gab aber keine Änderung im Verhalten. Genau so wenig wie anderer Sourceport (5060), Expire (480) oder +49 Nummer. Ich erwähne das extra, weil der pjsip REGISTER diese Werte verwendet und es scheinbar den Unterschied macht. Ist aber nicht der Fall, hatte das gegen geprüft.

Übrig bleibt damit n.m.E. nur der Supported/Allow Header. An den Unique Numbers in den Kopfdaten wird es ja nicht liegen (branch/tag/Call-id).

Der Request sieht so aus:

REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5066;branch=z9hG4bK031669f3
Max-Forwards: 70
From: <sip:012345689@tel.t-online.de>;tag=as435de6a2
To: <sip:012345689@tel.t-online.de>
Call-ID: 54da93f20602bc9904cd8b213c3e5af5@127.0.1.1
CSeq: 102 REGISTER
Supported: replaces, timer
User-Agent: "Asterisk PBX"
Expires: 500
Contact: <sip:012345689@1.2.3.4:5066>
Content-Length: 0

Danach dann die Ablehnung (nur bei diesem einen Server, alle anderen nehmen das Register Request an)

SIP/2.0 503 unsupported user equipment, firmware update required
Via: SIP/2.0/UDP 1.2.3.4:5066;branch=z9hG4bK031669f3
From: <sip:012345689@tel.t-online.de>;tag=as435de6a2
To: <sip:012345689@tel.t-online.de>;tag=SipLib_02184918A4A8-1623-0-2b0491-6256fe95-cbf5a
Call-ID: 54da93f20602bc9904cd8b213c3e5af5@127.0.1.1
CSeq: 102 REGISTER
Content-Length: 0

Auffällig ist, das bei diesen Ablehnungen immer Tag= mit einem "SipLib_" Prefix beginnt. Scheint wohl eine relativ veraltete SIP und Capture Bibliothek zu sein, die seit Jahren nicht mehr weiter entwickelt wird. Vielleicht ist da der Haken.

Habe bei den erfolgreich angenommenen Registers diese "SipLib_" Prefix im Tag bisher nicht gesehen.

Das REGISTER mit der temporären pjsip Testconfig sieht so aus (gegen gleichen Server), 

REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5060;rport;branch=z9hG4bKPjd0081158-85c3-415b-b64a-28cc1bdca9da
From: <sip:+49123456789@tel.t-online.de>;tag=dd3ac72c-3393-4709-a4f2-b32981a7c68c
To: <sip:+49123456789@tel.t-online.de>
Call-ID: 66d34898-07ff-4c91-a525-58895964617a
CSeq: 17982 REGISTER
Contact: <sip:0123456789@1.2.3.4:5060>
Expires: 480
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Max-Forwards: 70
User-Agent: Asterisk PBX 16.22.0
Content-Length: 0

Danach geht es dann mit der Authentication weiter, wie es sein sollte. Übrigens die Antwortpakete bei erfolgreichem REGISTER Verlauf (gleiche Ziel IP 217.0.146.5) haben nicht diese "SipLib_" Tags.

[#24]

@kimLui 

Vielen Dank für deine Antwort hier in dem Thread 🤗

@username_michael hatte ja noch mal dir eine ausführliche Antwort gegeben 😇 Konnte diese dir weiterhelfen? 🤔

Viele Grüße 

Timur K. 

[#25]

@Timur K.  schrieb:
hatte ja noch mal dir eine ausführliche Antwort gegeben 😇 Konnte diese dir weiterhelfen

Michael und ich diskutieren hier im Thread zwei unterschiedliche Probleme mit dem selben Symptom (= Fehlermeldung) auf dem selben Server (genauer: IP-Adresse). Ich mache hier quasi die Arbeit für Euch, indem ich versuche die Ursache auch bei Michael zu finden. Und Michael ist so nett und spielt mit; zusammen finden wir vielleicht auch seine Ursache. Anders formuliert: Mir kann allein die Telekom Deutschland weiter helfen. Micheal vermutlich genauso.

@username_michael ich schaue mir das die Tage mal an.

Allerdings befürchte ich inzwischen, dass hinter dieser IP-Adresse nicht nur ein anders konfigurierter Server sondern viele Server stehen. Einige davon sind definitiv völlig anders konfiguriert als der Rest, einige aber auch noch völlig anders konfiguriert als unter dieser IP-Adresse üblich. Ich sah nämlich inzwischen schon andere Antworten von dieser IP-Adresse. Vielleicht erwische ich immer die Server (Zufall oder Geo-Lokation), die einen User-Agent wollen. Und vielleicht erwischst Du immer jene Server, die einen Header Allow bei Supported fordern.

[#26]

@username_michael  schrieb:
Der Request sieht so aus:
User-Agent: "Asterisk PBX"

Gute Nachrichten! Ich konnte Deinen Fehler nachstellen. Auch bei Dir ist die Ursache der User-Agent, allerdings sind es bei Dir die (geraden) Anführungszeichen. Die Telekom verlangt auf diesem Server nicht nur User-Agent, dieser SIP-Header darf auch keine Anführungszeichen enthalten. Das müsstest Du umgehen können, indem Du in Deiner Konfigurationsdatei sip.conf einfach die Anführungszeichen bei useragent= entfernst. Jedenfalls habe ich dort keine und auch keine Probleme.

Liebe Telekom, fragt bitte auch Michael nach seiner Rufnummer, damit das interne Team sieht, dass nicht nur ich davon betroffen bin. Auch vermute ich inzwischen, dass diese Server-Konfiguration in den nächsten Wochen landesweit ausgerollt wird. Wenn das bis dahin nicht behoben wird, können auf einmal richtig, richtig viele Kunden nicht mehr telefonieren.