… also, meistens.
Ich hab’ derzeit ein sonderbares Problem. Kabel-Internet (Businessvariante: 1x IPv4 (MTU 1500), kein IPv6), daran eine FritzBox 6360.
Im LAN steht ein Asterisk 13, der über einen SIP-Provider, nennen wir ihn E, ausgehende Telefonie inkl. CLIP (no screening) macht. Am Asterisk »angeschlossen« sind u. a. Snom 3xx und Cisco 99×1.
Bislang war alles schick, die Telefone telefonierten – dank CLIP (no screening) – mit der alten Nummer raus, und es waren somit ausgehend schon mal mehr parallele Gespräche möglich als die beiden ISDN-B-Kanäle (jetzt nur noch inbound genutzt) hergaben.
(ISDN kam über eine FritzBox 7272 in den Asterisk, da ISDN und Asterisk heute keinen Spaß mehr machen.)
Seit dieser Woche habe ich das Phänomen, daß ausgehende Telefonate über Anbieter E keinen inbound audio channel haben. Sprich: ich wähle raus und … höre nix. Werde ich angerufen (über SIP, d. h. eben jenen Asterisk), ist alles schick.
Ich habe es soweit nun verifiziert, daß tatsächlich kein RTP-Stream vom Anbieter zu meinem Asterisk aufgebaut wird. Wieso, weshalb, warum: äh, nächste Frage?
Nun hatte ich NAT im Verdacht und die – wie gesagt bislang funktionalen – Einstellungen des Asterisk in dieser Hinsicht von links auf rechts auf oben und wieder auf links gezogen, denn ich glaube nicht mehr, daß es eine NAT-Einstellung im Asterisk ist:
- Nutze ich einen anderen Asterisk zum rauswählen (also mein Asterisk wählt über einen anderen raus, dessen Context dann über Anbieter E geht), gibt es kein Problem.
- Konfiguriere ich Anbieter E als SIP-Trunk auf einer 7490 im LAN (LAN-Client-Modus), und verbinde den Asterisk über einen SIP-Account mit der 7490 und nutze dies zum rauswählen, gibt es kein Problem (bis auf den Verlust von CLIP (no screening)).
- Nutze ich einen anderen Anbieter, nennen wir ihn P, mit den gleichen NAT-Einstellungen, gibt es kein Problem.
Für ›NAT ist Dein Problem‹ spricht sicher einiges; dagegen aber die Funktion mit anderem Anbieter/Asterisk (jene Verbindungen von diesem Asterisk müssen genauso durch das NAT der 6360) und irgendwie auch die Funktion über die 7490. Für Einstellungsprobleme auf Asterisk-Ebene – ggf. in Verbindung mit NAT – wiederum spricht die Funktion des SIP-Zugangs bei E via 7490; dagegen aber die Funktion mit P oder einem anderen Asterisk.
*kopfkratz* Irgendwer ‘ne Idee?
Wenn sich zu Hause nichts geändert hat würde ich auf die MTU tippen. Das evtl. ein Router dazwischen geändert wurde.
Hatte so ein Problem bisher allerdings nur im V6 Bereich, wo früher ja sehr viele Tunnel eingesetzt wurden.
Wobei, vor vier Wochen hatte ich das MTU Problem im zusammenspiel mit einem Windows Rechner (IPSec auf einem Raspberry als Router). Das interessante dabei Android Handys kamen damit klar. Bei Windows musste ich die MTU erst runter setzen damit da was ging. Der Fehler lag letzt endlich in dem falsch konfigurierten Linux.
Evtl. hilft dir der gedanken Anstoß
Ich glaube nicht, daß der *Nichtaufbau* einer RTP-Verbindung E->mein Asterisk was mit der MTU zu tun hat, die, wie ich auch erwähnte, lt. tracepath bei 1500 liegt ;).
Beim (Überraschung!) gleichen Anbieter, aber Privatkundentarif (DS-Lite), sieht das mit der MTU in der Tat schlecht aus:
wusel@ysabell:~$ tracepath 148.251.168.166 1?: [LOCALHOST] pmtu 1500 1: 192.168.5.33 3.251ms 1: 192.168.5.33 4.410ms 2: 192.168.175.1 3.205ms 3: 192.0.0.2 3.148ms pmtu 1460 3: no reply 4: 84.116.197.141 20.633ms 5: 84.116.196.194 25.529ms asymm 10 6: de-fra01b-rc1-ae17-0.aorta.net 26.589ms asymm 9 7: de-fra01b-ri1-ae0-0.aorta.net 26.387ms 8: ae9-0.fra10.core-backbone.com 24.502ms 9: ae6-2011.nbg40.core-backbone.com 26.464ms asymm 10 10: core-backbone-100g-nbg.hetzner.de 29.797ms 11: core11.nbg1.hetzner.com 25.996ms 12: core24.fsn1.hetzner.com 30.493ms 13: ex9k2.rz19.hetzner.de 25.575ms 14: dorfl.uu.org 28.912ms 15: mail.guetersloh.freifunk.net 27.021ms reached Resume: pmtu 1460 hops 15 back 15E = 1&1?
Nope. E ist (u. a). ein SIP (-Trunking) -Anbieter; ich gehe auch davon aus, daß der Name nichts zur Sache beiträgt, sonst würde ich Roß und Reiter nennen.
moin
codec?
klappt die Aushandlung?
selbst o2-dtag und Vodafone-o2 haben sporad. Probleme.
oder Ports
welche Ports werden für die rtp streams genutzt?
jeweils beim fehlerhaften E und beim funktionierenden P
sip trace?
was sagt wireshark?
was ist, wenn du den sipaccount direkt anrufst?
also nicht die rufnummer, sondern direkt sip account zu sipaccount?
zb bei einer Fritzbox sind im Router Modus und im IP Client Modus die Ports für rtp unterschiedlich,
musste ich auch etwas suchen, als ich die o2 fritze hinter der sophos utm hatte.
Verbindungsaufbau war immer ok, aber immer wieder mal einseitige Verständigung.
Gruß Ingo
Des Rätsels Lösung: ICE/STUN. Zu E wurde STUN benutzt (in [general] per icesupport=yes aktiviert), zu P nicht — warum auch immer. Nach dem auskommentieren von icesupport=yes klappt’s nun auch wieder mit E und ich kann mit den Umweg über die Fritte sparen ;)
Faktisch also doch in NAT-Thema. Vielleicht sind NATs doch nicht so gut ;)