AW: Abgehende Anrufe an andere Telekom Sip-Trunks funktionieren nicht

[#1]

Hallo,
wir haben folgendes Problem:
- Abgehende Anrufe an einige Anschlüsse funktionieren nicht.
Die Konfiguration ist folgende:
AVM Fritzbox nur als Router ohne Telefonie, alle Telefoniefunktionen deaktiviert bzw. auf das nicht mehr vorhandene Festnetz umgestellt
Yeastar S20 Telefonanlage (im Prinzip eine Asterisk als Hardware-Box mit Yeastar GUI)
Diverse VOIP Clients von HTEK, Grandstream und Gigaset

Bei manchen Anschlüssen kommt keine Verbindung zustande. Die Anlage schreibt einfach einen "Outgoing Call Failed" ins Event Log.
Eine Netzwerkanalyse mit Wireshark zeigt folgende Zeilen (Endnummern ausgeixt - das ist die komplette angerufene Rufnummer zu der die Verbindung nicht zustande kommt):
278    6.679652    174.16.48.151    217.0.26.37    SIP/SDP    1202    Request: INVITE sip:09116xxxxx@sip-trunk.telekom.de;transport=tcp |

279    6.689984    217.0.26.37    174.16.48.151    TCP    66    5060 → 51096 [ACK] Seq=1 Ack=1137 Win=355 Len=0 TSval=1536883902 TSecr=20307514

280    6.690738    217.0.26.37    174.16.48.151    SIP    420    Status: 100 Trying |

281    6.716997    217.0.26.37    174.16.48.151    SIP    795    Status: 401 Unauthorized |

282    6.717093    174.16.48.151    217.0.26.37    TCP    66    51096 → 5060 [ACK] Seq=1137 Ack=1084 Win=2608 Len=0 TSval=20307551 TSecr=1536883902

283    6.719007    174.16.48.151    217.0.26.37    SIP    586    Request: ACK sip:09116xxxxx@sip-trunk.telekom.de;transport=tcp |

284    6.767583    217.0.26.37    174.16.48.151    TCP    66    5060 → 51096 [ACK] Seq=1084 Ack=1657 Win=355 Len=0 TSval=1536883922 TSecr=20307553

285    6.767687    174.16.48.151    217.0.26.37    SIP/SDP    1470    Request: INVITE sip:09116xxxxx@sip-trunk.telekom.de;transport=tcp |
286    6.778292    217.0.26.37    174.16.48.151    TCP    66    5060 → 51096 [ACK] Seq=1084 Ack=3061 Win=355 Len=0 TSval=1536883924 TSecr=20307602

287    6.778584    217.0.26.37    174.16.48.151    SIP    420    Status: 100 Trying |

288    6.818339    174.16.48.151    217.0.26.37    TCP    66    51096 → 5060 [ACK] Seq=3061 Ack=1438 Win=2608 Len=0 TSval=20307653 TSecr=1536883924

289    6.974114    Giga-Byt_57:a3:c1    Broadcast    ARP    60    Who has 174.16.48.224? Tell 174.16.48.205

Das sollten die entscheidenden Zeilen sein, das 174.16.48.x Netz ist das Interne LAN

Jemand irgendeine Idee?

[#2 · Accepted solution]

Vielen Dank an das Forum

Das Problem ist inzwischen mit Hilfe des Telekom Telefon Supports gelöst worden.

Die nicht funktionierenden Anrufe waren alle zu Vodafone SIP-Trunks. Die Standardeinstellung war als für die Reihenfolge der Codecs war auf unserer Seite u-law dann a-law dann die weiteren möglichen Codecs. Die Telekom hat nun die Verbindung unter Verwendung des u-law Codecs angenommen und der Vodafone Server hat die Verbindung zurückgewiesen. Durch Umstellung der Reihenfolge mit a-law an erste Stelle funktionerien nun auch die Verbindungen, die bisher abgewiesen wurden.

[#3]

---

@JoergLucinski  schrieb:

Das sollten die entscheidenden Zeilen sein, das 174.16.48.x Netz ist das Interne LAN

Jemand irgendeine Idee?

---

Öffentliche IP Adressen im LAN? Soll das ein Scherz sein?

[#4]

Hallo,

der von Dir gepostete Wireshark-Auszug zeigt meiner Erachtens im wesentlichen folgendes:

1.) Der anrufende Client schickt an das Telekom-Netz ein SIP-Invite, um eine Rufnummer in Nürnberg anzurufen.

2.) Der Telekom-Server schickt zunächst eine Antwort "100 Trying" und direkt daraufhin eine weitere Antwort "401 Unauthorized". Daß eine Invite-Anfrage zunächst mit einer Fehlermeldung abgewiesen wird, kann erstmal verwirrend sein, hat aber oftmals einen einfachen Grund: Der Client muß sich üblicherweise am SIP-Server identifizieren - um dies zu erreichen, lehnt der Server die erste Invite-Anfrage ab und gibt dem Client eine Fehlermeldung zurück, in der auch drin steht, wie der Client sich identifizieren soll. Diese Infos müßten in der Fehlermeldung als "Proxy-Authenticate" oder "WWW-Authenticate" erkennbar sein.

3.) Daraufhin schickt der Client eine neue SIP-Invite-Anfrage, die auch die Informationen zur Identifizierung enthalten müßte. Die zweite Invite-Anfrage müßte daher in der Wireshark-Analyse größer sein und (zumindest ist das bei meiner Technik so) zwischen "Contact" und "P-Preferred-Identity" die zusätzlichen Authorization-Daten enthalten.

4.) Die zweite Invite-Anfrage wird wiederum mit einem "100 Trying" beantwortet. Der Log-Ausschnitt zeigt dann nur noch das TCP-ACK (bei SIP-Trunk erfolgt der Signalisierungsverkehr nicht über UDP, sondern über TCP und wird daher entsprechend bestätigt) und eine lokale ARP-Anfrage innerhalb Deines Netzwerkes. Danach hört der Log-Ausschnitt auf - obwohl es hier erst richtig interessant werden würde. Wie geht es denn nach diesem erneuten "100 Trying" weiter? Eigentlich müßte danach relativ schnell ein "180 Ringing" oder "183 Session Progress" kommen - oder eine Fehlermeldung aus dem Bereich 4xx, 5xx oder 6xx, wenn der Verbindungsaufbau abgeblockt wird oder fehlschlägt.

Laut den von Dir aufgeführten IP-Adressen erfolgt die Nutzung des Telekom-SIP-Trunks von einem CenturyLink-Anschluß in den USA aus, ist das so korrekt? Eine solche nomadische Nutzung müßte bei diesem Produkt eigentich möglich sein (im Vergleich zu normalen Telekom-VoIP-Accounts für Privatkunden).

Weitere Infos zu den oben diskutierten Punkten gibt es z.B. unter folgenden Links:

- https://tools.ietf.org/html/rfc3261 (insbesondere die Punkte 8.1.3.5, 21.4.x und 22)

- https://www.msxfaq.de/skype_for_business/trace/siptrace-siplogon.htm

- https://www.voip-info.org/sip-authentication/

cu talk

[#5]

Hallo letztlich folgt dann nach mehreren erfolglosen Versuchen ein Serverfehler 500
Der Anschluß ist ein Telekom Sip-Trunk an einer Telekom VDSL 100 Leitung im Vorwahlbereich 09122

[#6]

Leider kein Scherz, das ist eigentlich nicht meine Baustelle, da das nunmal das vorhanden interne IP-Netz war. Ich denke auch nicht, dass dies wirklich die Ursache des Problems ist, aber du hast natürlich recht. Man sollte da mal darauf drängen, dass dies in ein 192.168.x.x umgestellt wird.

[#7]

Moin @JoergLucinski,

vielen Dank für Deine Nachricht.

Ich prüfe Deine Anschlüsse, zusätzlich zur Hilfestellung der anderen User, gerne auf Störungen. Lass' mir hierzu doch einmal eine Direktnachricht mit den betreffenden Anschlussrufnummern zukommen. Die Kundennummer hast Du ja bereits hinterlegt, danke dafür.

Über eine kurze Rückmeldung freue ich mich.

Viele Grüße,
Lin J.

[#8]

Ich befürchte, das Problem liegt an Inkompatibilitäten zw. den beteiligten Komponenten. Die IP - Telefonie ist komplexer und nicht so weit standardisiert wie man es bei ISDN - Anschlüssen gewohnt ist.
Ich würde es mal testweise mit einer Digitalisierungsbox Premium versuchen.

[#9]

Hallo,

---

@JoergLucinski  schrieb:

Hallo letztlich folgt dann nach mehreren erfolglosen Versuchen ein Serverfehler 500

---

Sind mit Wireshark in dem Datenpaket, welches den Fehler 500 übermittelt, Angaben für "Reason", "Reason protocols" und "Cause" erkennbar? Falls ja, welche?

cu talk

[#10]

Wie geht das mit der Direktnachricht hier? - Finde die Funktion nicht

[#11]

Guten Abend @JoergLucinski,

eine DN funktioniert über den Briefumschlag oben rechts.

Freundliche Grüße
Kerstin Si.

[#12]

---

@JoergLucinski  schrieb:

Leider kein Scherz, das ist eigentlich nicht meine Baustelle, da das nunmal das vorhanden interne IP-Netz war. Ich denke auch nicht, dass dies wirklich die Ursache des Problems ist,

---

Wenn Du dem Proxy mitteilst, das er die RTP Pakete für die Sprache an diese öffentliche IP Adresse schicken soll, du aber in Wirklichkeit eine andere öffentliche IP Adresse hast, dann hast du eine Baustelle...

[#13]

Kann das irgendjemand verifzieren, ob das wirklich das Problem sein könnte, bzw. wahrscheinlich ist?
Mir ist das schon klar, dass es ein Problem ist mit der Verwendung der öffentlichen IPs im internen LAN, und ein kleiner IP-Bereich damit nicht erreichbar ist. Die Wahrscheinlichkeit dass dieser tatsächlich benötigt wird ist nur geringer als ein 6er im Lotto. Ich bin glücklicherweise dafür nicht verantwortlich, insofern nicht meine Baustelle, wenn ich jetzt allerdings das als Grund angebe und im Betrieb mit großem Aufwand (Da hängen auch Produktions-Maschinen in dem Subnetz wo man nicht mal schnell einfach ne IP-Adresse umstellt) der IP-Bereich auf ein 192.168.x Netz umgestellt wird und danach geht es immer noch nicht, dann hab ich ein ernsthaftes Problem.

[#14]

Hallo,

---

@JoergLucinski  schrieb:

Kann das irgendjemand verifzieren, ob das wirklich das Problem sein könnte, bzw. wahrscheinlich ist?
Mir ist das schon klar, dass es ein Problem ist mit der Verwendung der öffentlichen IPs im internen LAN, und ein kleiner IP-Bereich damit nicht erreichbar ist.

---

Daß man fremde öffentliche IP-Adressen nicht für ein eigenes lokales Netz nutzen sollte ist klar. Ich glaube aber nicht, daß das vorliegende Problem hiermit zu tun hat.

Die "fremden" IP-Adressen werden ja wohl nur intern genutzt und nicht nach außen

- das würde auch gar nicht funktionieren.

Andere Telefonie-Verbindungen funktionieren offenbar - und die Fehlermeldungen des Telekom-Servers erreichen Dein Netz ebenfalls. Demnach dürfte das Routing auf IP-Ebene funktionieren.

Gibt es denn bei der Fehlermeldung 500 noch weitere Angaben im Datenpaket? Siehe hierzu auch mein letztes Posting in diesem Thread.

cu talk

[#15 · Accepted solution]

Vielen Dank an das Forum

Das Problem ist inzwischen mit Hilfe des Telekom Telefon Supports gelöst worden.

Die nicht funktionierenden Anrufe waren alle zu Vodafone SIP-Trunks. Die Standardeinstellung war als für die Reihenfolge der Codecs war auf unserer Seite u-law dann a-law dann die weiteren möglichen Codecs. Die Telekom hat nun die Verbindung unter Verwendung des u-law Codecs angenommen und der Vodafone Server hat die Verbindung zurückgewiesen. Durch Umstellung der Reihenfolge mit a-law an erste Stelle funktionerien nun auch die Verbindungen, die bisher abgewiesen wurden.

[#16]

Hallo,

derzeit ereilt mich seit letztem ein scheinbar älteres Problem. 

Beschreibung:

Beim Anruf von ~50% der von mir per SIP angerufenen Nummern wird an meinem Endgerät kein 'Läuten' signalisiert, wohl aber bei der der Gegenstelle. Nimmt die/der Angerufene ab, kann ich dies an der Anzeige der Gesprächsdauer erkennen aber die Leitung bleibt in beiden Richtungen stumm.

Anfangs (Mai/Juni 2021) ist es mir bei einigen Verbindungen aufgefallen. Inzwischen scheinen über die Hälfte der Verbindungen betroffen. (Bei der Anzahl kann es sich aber um ein Wahrnehmungsproblem handeln.)

Da ich weder an meinem Endgerät Snom821 noch an meinem Speedport Hybrid etwas geändert habe, vermute ich eine ähnliches Problem wie bei https://telekomhilft.telekom.de/t5/All-IP-das-digitale-Netz/Abgehende-Anrufe-an-andere-Telekom-Sip-T...

Kann ich selbst etwas machen, oder gibt es ein Buzzwort bei dem die Mittarbeiter*nnen im Support sofort erkennen, um welches Problem es sich handelt.

[#17]

@paedagogische-praxis 

Willst Du wirklich einen SIP-Trunk Tarif über eine Hybrid-Anschluss nutzen oder geht es einfach nur um einen ALL IP über Hybrid?

[#18]

Eventuell ist das ein Missverständnis.

Ich hab einen 'normalen' Tarif warscheinlich "ALL IP "und nutze nach anfänglichen Problemen sei Jahren  neben den Analogen Geräten ein SIP-Telefon.

Uwe

[#19]

@paedagogische-praxis 

Warum machst Du dann nicht einfach ein neues Thema auf sondern hijackst diesen alten Thread?

[#20]

Weil die *** Nutzungsführung mich immer wieder auf das Formular Antworten gelenkt hat. Eigentlich bin ich gerade dabei einen neuen Thread zu öffnen.