Asterisk SIP-Trunk Registrierung weg bei eingehenden Anrufen peer unreachable

[#1]

Wir testen einen SIP-Trunk-Pooling im Fallback-Fall über unsere normale Internet-Anbindung, nicht die exta Anbindung über die Digibox! Bei einem eingehende Anruf entfällt die Registrierung und das Peer wird "unreachable". Anschließend braucht 46 Registrierungsversuche bis der Trunk wieder nutzbar ist. Das ist reproduzierbar, also beim nächsten eingehenden Anruf von meinem Telefonica-Handy passiert es wieder.

Was können wir tun? Wie machen andere das? An der Firewall bleibt nichts hängen.

Hier noch einige Zeilen aus dem Asterisk-Log:

[2019-08-02 16:24:42] NOTICE[2061]: chan_sip.c:29381 sip_poke_noanswer: Peer 'FOOBAR-out' is now UNREACHABLE! Last qualify: 11

[2019-08-02 16:25:40] NOTICE[2061]: chan_sip.c:15379 sip_reg_timeout: -- Registration for '+49XXYYZZ@reg.sip-trunk.telekom.de' timed out, trying again (Attempt #2)

...

[2019-08-02 16:40:20] NOTICE[2061]: chan_sip.c:15379 sip_reg_timeout: -- Registration for '+49XXYYZZ@reg.sip-trunk.telekom.de' timed out, trying again (Attempt #46)
[2019-08-02 16:40:30] NOTICE[16679]: chan_sip.c:23945 handle_response_peerpoke: Peer 'FOOBAR-out' is now Reachable. (22ms / 2000ms)
[2019-08-02 16:40:31] NOTICE[16679]: chan_sip.c:23945 handle_response_peerpoke: Peer 'FOOBAR-in' is now Reachable. (11ms / 2000ms)

Anschließend Asterisk CLI:

*CLI> sip show registry
Host dnsmgr Username Refresh State Reg.Time
reg.sip-trunk.telekom.de:5060 Y +49XXYYZZ 105 Registered Fri, 02 Aug 2019 16:42:25

[#2 · Accepted solution]

Hallo @Tanja R. ,

mittlerweile konnte der technische Support meine Beobachtungen analysieren und bestätigen. Leider ohne einen Hinweis wie wir das "kundenseitige" Problem beheben. Außerdem konnten die Kollegen des Supports leider keine Einsicht in die hier bereits beschriebenen Fakten nehmen und ich durfte alles noch ein Mal schildern.

Ich werde nun, wie von @Meester Proper vorgeschlagen, die Telefonanlage wie folgt anbinden:

Telefonanlage <-> Digibox <-> Deutschland LAN IP (Haupt-Internet-Zugang, also nicht der VDSL-Anschluss speziell für den SIP-Trunk)

zuvor:

Telefonanlage <-> Firewall <-> Deutschland LAN IP (Haupt-Internet-Zugang, also nicht der VDSL-Anschluss speziell für den SIP-Trunk)

Damit wird sichergestellt, dass es an unserer Firewall liegt, die dann in Absprache mit dem Hersteller hoffentlich angepasst werden kann, so dass diese mit dem größeren SIP/SDP Paket umgehen kann.

Liebe Grüße

[#3 · Accepted solution]

---

@muAdmDev  schrieb:

---

Der INVITE ist bei einem eingehenden Telefonica-Anruf tatsächlich 280 Bytes größer und enthält mehr Media Attribute (a-lines).Es sieht ganz nach einem TCP-Stack hänger aus. Nach dem initialen INVITE (TCP lenght 1509) erfolgen 6 Retransmissions der gleichen Sequenz-Nummer, jedoch mit reduzierter lenght von 1448. Was kann ich tun?

---

---

Die Retransmissions deuten darauf hin, dass das TCP ACK fehlt. Die "TCP length 1509" muss aber ein zusammengesetzte Länge aus mindestens zwei TCP-Paketen sein, da bei einer MTU von 1.500 Bytes nur eine TCP-MSS von 1.460 Bytes vorliegt. Kann es sein, dass hier nur eines von beiden TCP-Segmenten per ACK bestätigt wird, aber für beide ein ACK gefordert ist?

Wenn du das Problem nicht lösen kannst, könntest du einen Session Border Controller (SBC) einsetzen. Mit etwas Konfigurationsarbeit lässt sich sogar eine Digibox als SBC konfigurieren: https://digitalisierungsbox.bintec-elmeg.com/archiv-sbc-zu-unify-osbiz/

---

@muAdmDev  schrieb:

---

Spanned ist zudem ein Unterschied im SIP-Header im "SIP to adress Host Part":

Beim funktionierenden Anruf von Telekom-ISDN: "anonymous.invalid"

Beim fehlerhaften Anrufe von Telefonica: "telekom.de"

---

---

Der to-Header ist nur wenig interessant. Für das korrekte SIP-Routing ist bei Registrierung nach RFC3261 der P-Called-Party-ID und bei Registrierung nach RFC6140 die Request-URI zu verwenden. Der to-Header wird nicht normalisiert und stellt nach RFC3261 auch nicht immer das letztendlich Anrufziel dar:

RFC3261, 8.1.1.2 To

 The To header field first and foremost specifies the desired
"logical" recipient of the request, or the address-of-record of the
user or resource that is the target of this request. This may or may
not be the ultimate recipient of the request.

[#4]

Hallo @muAdmDev,

herzlich willkommen in unserer Community.

Ich habe diese Frage an meine Kollegen aus dem Fachteam weiter gegeben und melde mich am Mittwoch erneut bei Ihnen.

Viele Grüße Heike Ha.

[#5]

Sicher, dass das nicht ein Firewall- oder Problem mit Dual-Stack Lite / Carrier Grade NAT oder ähnlichen Middelboxes ist?

Anrufe aus Mobilfunknetzen nutzen oftmals eine große Anzahl von Codecs, daher werden die INVITE-Pakete sehr groß, wenn nun die Fragmentierung bspw. nicht möglich ist und dies nicht korrekt per ICMP zurückgemeldet wird, kann es sein, dass der TCP-Stack hier hängenbleibt.

Tritt das Problem auch auf, wenn der separate Internet-Zugang mit der Digibox genutzt wird?

Was ist der "Haupt-Internetzugang"? Wurde schon einmal ein WAN-Trace vorgenommen und geschaut, ob die INVITE der Telefonica-Anrufe komplett ankommen (inkl. allen Codecs / SDP a-lines)?

P.S: Der chansip-Stack sollte nicht mehr genutzt werden, da dieser nicht mehr weiterentwickelt wird. Stattdessen sollte der pjsip-Stack genutzt werden.

[#6]

Vielen Dank für die Hinweise. Ich werde zunächst einen Trace machen.

Anschließend ließe sich auch die Digibox über die Haupt-Internet-Anbindung prüfen.

Ein Umstieg auf PJSIP ist momentan leider noch nicht ohne Weiteres möglich.

[#7]

---

Sicher, dass das nicht ein Firewall- oder Problem mit Dual-Stack Lite / Carrier Grade NAT oder ähnlichen Middelboxes ist?

---

An der Firewall bleibt nichts hängen. Dual-Stack Lite sagt mir erstmal nichts. SIP-Trunk sowie Haupt-Internet-Anbindung (Deutschland LAN Connect IP) sind von der Telekom. Da Anrufe von einem Telekom-ISDN-Anschluss durchkommen, kann obiges überhaupt eine Ursache sein?

---

Anrufe aus Mobilfunknetzen nutzen oftmals eine große Anzahl von Codecs, daher werden die INVITE-Pakete sehr groß, wenn nun die Fragmentierung bspw. nicht möglich ist und dies nicht korrekt per ICMP zurückgemeldet wird, kann es sein, dass der TCP-Stack hier hängenbleibt.

---

Der INVITE ist bei einem eingehenden Telefonica-Anruf tatsächlich 280 Bytes größer und enthält mehr Media Attribute (a-lines).Es sieht ganz nach einem TCP-Stack hänger aus. Nach dem initialen INVITE (TCP lenght 1509) erfolgen 6 Retransmissions der gleichen Sequenz-Nummer, jedoch mit reduzierter lenght von 1448. Was kann ich tun?

Spanned ist zudem ein Unterschied im SIP-Header im "SIP to adress Host Part":

Beim funktionierenden Anruf von Telekom-ISDN: "anonymous.invalid"

Beim fehlerhaften Anrufe von Telefonica: "telekom.de"

---

[#8 · Accepted solution]

---

@muAdmDev  schrieb:

---

Der INVITE ist bei einem eingehenden Telefonica-Anruf tatsächlich 280 Bytes größer und enthält mehr Media Attribute (a-lines).Es sieht ganz nach einem TCP-Stack hänger aus. Nach dem initialen INVITE (TCP lenght 1509) erfolgen 6 Retransmissions der gleichen Sequenz-Nummer, jedoch mit reduzierter lenght von 1448. Was kann ich tun?

---

---

Die Retransmissions deuten darauf hin, dass das TCP ACK fehlt. Die "TCP length 1509" muss aber ein zusammengesetzte Länge aus mindestens zwei TCP-Paketen sein, da bei einer MTU von 1.500 Bytes nur eine TCP-MSS von 1.460 Bytes vorliegt. Kann es sein, dass hier nur eines von beiden TCP-Segmenten per ACK bestätigt wird, aber für beide ein ACK gefordert ist?

Wenn du das Problem nicht lösen kannst, könntest du einen Session Border Controller (SBC) einsetzen. Mit etwas Konfigurationsarbeit lässt sich sogar eine Digibox als SBC konfigurieren: https://digitalisierungsbox.bintec-elmeg.com/archiv-sbc-zu-unify-osbiz/

---

@muAdmDev  schrieb:

---

Spanned ist zudem ein Unterschied im SIP-Header im "SIP to adress Host Part":

Beim funktionierenden Anruf von Telekom-ISDN: "anonymous.invalid"

Beim fehlerhaften Anrufe von Telefonica: "telekom.de"

---

---

Der to-Header ist nur wenig interessant. Für das korrekte SIP-Routing ist bei Registrierung nach RFC3261 der P-Called-Party-ID und bei Registrierung nach RFC6140 die Request-URI zu verwenden. Der to-Header wird nicht normalisiert und stellt nach RFC3261 auch nicht immer das letztendlich Anrufziel dar:

RFC3261, 8.1.1.2 To

   The To header field first and foremost specifies the desired
   "logical" recipient of the request, or the address-of-record of the
   user or resource that is the target of this request.  This may or may
   not be the ultimate recipient of the request.

[#9]

Hallo @muAdmDev,

wie versprochen melde ich mich heute zurück.

Leider habe ich noch keine Antwort erhalten, bitte noch etwas Geduld.
Erneute Rückmeldung erfolgt am Dienstag.

Viele Grüße Heike Ha.

[#10]

Hallo @muAdmDev,

ich springe hier einmal für meine Kollegin Heike mit ein, wir habe eine Rückmeldung für Ihren Anschluss erhalten.

Es wird geraten , dass der Anschluss einer Analyse des Netzwerk Verkehrs durchlaufen soll um weiter zu prüfen.

Damit ich schnell weiterhelfen kann, füllen Sie bitte in Ihren Benutzerdaten die Felder „Kundennummer“ und/oder „Telefonnummer“ aus. Über folgenden Link gelangen Sie sofort zur richtigen Stelle in Ihrem Profil http://bit.ly/Kundeninfos Im Anschluss freue ich mich über eine kurze Rückmeldung.

Liebe Grüße
Sandra Ha.

[#11]

Ich habe die geforderten Daten im Profil vermerkt. Ein Wireshark-kompatibler TCP-Dump liegt vor, ich stelle den im Beitrag genannten Dump gerne zur Verfügung, jedoch nicht als öffentlichen Anhang.

[#12]

Hallo @muAdmDev,

leider habe ich Sie eben nicht erreicht. Bitte teilen Sie mir doch mit, wann dies der Fall ist.

Viele Grüße
Kerstin Si.

[#13]

Ich bin ab jetzt und heute noch bis 18 Uhr erreichbar. Ist ein Rückruf auf der mir angezeigten Rufnummer meinerseits möglich?

[#14]

Hallo @muAdmDev,

vielen Dank für das sehr freundliche Gespräch. Ich hoffe, der Kollege konnte Ihnen in sofern erst einmal weiterhelfen, dass er das Ticket zur weiteren Analyse aufnehmen konnte.

Bei weiteren Fragen melden Sie sich gern wieder hier bei uns.

Herzliche Grüße
Tanja R.

[#15 · Accepted solution]

Hallo @Tanja R. ,

mittlerweile konnte der technische Support meine Beobachtungen analysieren und bestätigen. Leider ohne einen Hinweis wie wir das "kundenseitige" Problem beheben. Außerdem konnten die Kollegen des Supports leider keine Einsicht in die hier bereits beschriebenen Fakten nehmen und ich durfte alles noch ein Mal schildern.

Ich werde nun, wie von @Meester Proper vorgeschlagen, die Telefonanlage wie folgt anbinden:

Telefonanlage <-> Digibox <-> Deutschland LAN IP (Haupt-Internet-Zugang, also nicht der VDSL-Anschluss speziell für den SIP-Trunk)

zuvor:

Telefonanlage <-> Firewall <-> Deutschland LAN IP (Haupt-Internet-Zugang, also nicht der VDSL-Anschluss speziell für den SIP-Trunk)

Damit wird sichergestellt, dass es an unserer Firewall liegt, die dann in Absprache mit dem Hersteller hoffentlich angepasst werden kann, so dass diese mit dem größeren SIP/SDP Paket umgehen kann.

Liebe Grüße

[#16]

Hallo @muAdmDev,

danke für deine Informationen und hoffe, dass es nun klappt! Danke für deine Geduld, noch mal alles zu wiederholen....
Ich werde Tanja R. dies weiterleiten.

LG Anna Lena L.

[#17]

Das Problem ist weiterhin nicht gelöst. Wir sind mit dem Firewall-Hersteller im Kontakt. Dabei kamen Fragen wie:

• kommt Carrier Grade NAT (CG-NAT) zum Einsatz?
  
• DF Bit (Don't Fragment) gesetzt?

auf. Wir haben wie gesagt einen Deutschland LAN Connect IP.

Nach Tests mit der Digibox direkt am genannten Anschluss, treten die Probleme nicht auf. Somit sieht es nach einem internen Firewall/Routing-Problem aus. Hilfe ist weiterhin wilkommen.

[#18]

Hallo @muAdmDev,

es tut mir wirklich leid, aber die Fragen kann ich Ihnen so ad hoc noch nicht beantworten. Ich habe zur Unterstützung den Fachbereich kontaktiert. Sobald ich neue Infos habe, melde ich mich wieder bei Ihnen. Ggf. erhalten Sie Montag eine Zwischeninfo von mir.

Herzliche Grüße
Tanja R.

[#19]

Hallo @muAdmDev,

da bin ich wieder mit einer Antwort der Kollegen aus dem Fachbereich.

Mit einem DeutschlandLAN Connect IP Anschluss erhalten Sie einen Internetzugang über das IP2-BB der Telekom (AS3320). Dazu werden dem Kunden "Öffentliche" IP-Adressen (Dual-Stack; IPv4/IPv6) zur Verfügung gestellt. Es kommt weder Carrier Grate NAT (CG-NAT) zum Einsatz noch ist DF Bit (Don't Fragment) gesetzt. Bei dem DeutschlandLAN Connect IP Anschluss handelt es sich um einen transparenten Internetanschluss.

Beste Grüße
Tanja R.

[#20]

Vielen Dank, ich werde diese Informationen weiterleiten. Ließe sich das DF-Bit setzen?

[#21]

@muAdmDev 

Ist Dir eigentlich klar, dass mit gesetztem DF Bit jedes Datenpaket, was größer als die MTU/MRU ist, verworfen wird?

[#22]

Jetzt ja, danke, somit keine potentielle Lösung. Warum schlägt der Firewall-Hersteller uns sowas vor...

[#23]

Hallo,

ich hänge mich hier einfach mal ran. Bei uns ist das Problem das wir in unregelmäßigen abständen ein "unreachable" bekommen und es dann ~20min dauert bis sich die Telekom Nummern (10 MSN) wieder registrieren. Mal läuft es einen Monat oder mehr ohne Probleme dann gibt es täglich das Problem, ja ohne das wir am setup etwas verändern! Bei gesprächen gibt es keinerlei Probleme, wenn die nummern erstmal "drin sind". Nummern eines Drittanbierters funktioniert einwandfrei im selben System. Das verhalten ist nicht reproduzierbar...

DrayTec Vigor 130 (Modem Bridge) -> Firewall -> Asterisk in einer VM. 

nach einem "sip reload" bekomme ich auch stehts immer die selbe IP für die Nummern. Auch der DNS für tel.t-online.de sollte passen, da ich über die 8.8.8.8 eine andere IP bekomme wie über den Anschluß. Die IP Ändert sich auch nicht und nach einigen Versuchen sind die Nummern auf der "immer gleichen" IP registriert. 

Das einzige was ich in  dem Zuge noch gefunden habe war, das MTU auf 1500 und nicht auf 1492 Konfiguriert war. Abweichend haben wir nen ALL IP anschluß.