Die Telekom hilft Community zieht um und ist bis zum 8. Januar 2025 nur eingeschränkt zugänglich.
Gelöst
Asterisk pjsip.conf für tel.t-online.de hinter NAT
vor 7 Jahren
Weil ich nirgends eine funktionierende Konfiguration gefunden habe, nach Stunden probieren und recherchieren jetzt hier ein Memorium.
Der Asterisk läuft auf der IP 10.0.0.2 hinter einer Fritz!Box an einem AllIP Magenta-Anschluss.
Auf der Fritz!Box folgende Portfreigaben anlegen:
5061/udp -> 10.0.0.2:5061
30000-30099/udp -> 10.0.0.2:30000
5061 wird ersatzweise verwendet, weil auf 5060 unumgänglich auf Home-Routern schon ein eigener Sipproxy lauscht.
Diesen wollen wir nicht haben, können den Schrott aber leider auch nicht abschalten.
Die pjsip.conf für Asterisk mit der Telekom incl. outbound_proxy:
[global] type = global language = de endpoint_identifier_order = ip,username [transport-udp] type = transport protocol = udp bind = 10.0.0.2:5061 local_net = 10.0.0.0/16 domain = my.dyndns.org external_media_address = $ExterneIP external_signaling_address = $ExterneIP external_signaling_port = 5061 [telekom_9931234567_reg] type = registration transport = transport-udp outbound_auth = telekom_9931234567_auth outbound_proxy = sip:+499931234567@tel.t-online.de:5060\;lr server_uri = sip:tel.t-online.de:5060 client_uri = sip:+499931234567@tel.t-online.de:5060 contact_user = 09931234567 retry_interval = 60 forbidden_retry_interval = 60 expiration = 480 auth_rejection_permanent = false [telekom_9931234567_auth] type = auth auth_type = userpass password = $Password:$TOnlineNummer-0001@tel.t-online.de username = 09931234567 realm = tel.t-online.de [telekom_9931234567] type = endpoint transport = transport-udp context = incoming disallow = all allow = alaw,g722 outbound_auth = telekom_9931234567_auth outbound_proxy = sip:+499931234567@tel.t-online.de:5060\;lr aors = telekom_9931234567_aor callerid = 09931234567 from_user = 09931234567 from_domain = tel.t-online.de timers = no rtp_symmetric = yes force_rport = yes ice_support = yes rewrite_contact = yes direct_media = no [telekom_9931234567_aor] type = aor contact = sip:+499931234567@tel.t-online.de [telekom_9931234567_identify] type = identify endpoint = telekom_9931234567 match = 217.0.0.0/13
Die fiktive Telefonnummer 9931234567 durch die eigene ersetzen. Dabei darauf achten, wo die Nummer mit 0 oder +49 beginnt. (Wichtig)
Darüber hinaus noch die Variablen
- $TOnlineNummer
- $Password
- $ExterneIP
sinngemäß anpassen.
Außer [global] und [transport-udp] muss alles für jede Telefonnummer wiederholt werden.
outbound_proxy= <vollständige-sip-url>\;lr
\;lr am Schluss ist wichtig. Steht für loose-routing. Gibt man das nicht mit an, ruft man sich beim abgehenden Anruf immer selbst an.
Das hat mich Stunden gekostet, denn es ist in dem Zusammenhang nirgends vernünftig dokumentiert.
Dann noch die rtp.conf anpassen:
rtpstart = 30000 rtpend = 30099
Damit eingehende RTP-Daten auch auf die richtigen am Router forwardeten Ports der external_media_address bestellt werden.
Warum die $ExterneIP in die pjsip.conf schreiben?
Das aktuelle res_pjsip.so Modul, welches in den meisten Distros verteilt wird macht keinen automatischen Lookup, wenn man einen DNS-Namen als external_media_address verwendet. Asterisk sendet dann im INVITE den DNS-Namen statt der IP. Prinziepiell sollte das gehen, jedoch machen die SIP-Gateways bei fast allen Providern entgegen der Spezifikation kein DNS-Lookup für uns.
Ich habe das unschön gelöst, indem ich ein kleines python-Script per Cron regelmäßig die IP von meiner DynDNS-Domain abfragen lasse.
Bei Bedarf ersetzt das Script dann die IP in der pjsip.conf und reloaded per AMI pjsip.
extensions.conf
[incoming]
exten => 09931234567,1,Verbose(${CALLERID(num)} ruft an)
[out]
exten => _X.,1,Dial(PJSIP/${EXTEN}@telekom_9931234567)
10265
4
Das könnte Ihnen auch weiterhelfen
356
0
7
310
0
2
vor 5 Jahren
545
0
1
vor 4 Jahren
16786
0
2
3784
0
2
Akzeptierte Lösung
Community Guide
akzeptiert von
vor 7 Jahren
Definitiv ist für Asterisk KEINE eingehende Portweiterleitung - weder von 5060 noch 5061- notwendig noch in irgend einer Weise sinnvoll.
Daher macht der Router auch keinen Schrott.
Es muss lediglich sicher gestellt werden, dass der Keep-Alive Retry der SIP-Registrierung kleiner ist, als der Timeout für UDP Verbindungen auf dem Router, damit der keinen aktiven State einer SIP-Registrierung aus der Sessiontabelle wirft.
Offen SIP-Server Ports aus dem Internet sind eine ernstzunehmende Sicherheitslücke - die viele Menschen schon Tausende € gekostet haben.
Es besteht die Gefahr, dass ein Gerät aus dem Internet sich auf einem durch schwachem/keinem Passwort gesicherten Endpunkt auf der Asterisk anmeldet und somit kostenpflichtige Telefonate führen kann. Es bedarf zwar noch weiterer Konfigurationsfehler um dies zu ermöglichen, aber wer den Port im Router freischaltet, macht auch diese.
Alle SIP-Verbindungen am VOIP Anschluss werden ausschliesslich vom LAN ins WAN augebaut
2
Antwort
von
vor 7 Jahren
Natürlich benötigt jedes System eine Firewall, dass beim einen zusätzlich NAT zum Einsatz kommt, ist ein völlig unabhängiges Thema
Provider Router sind mehr IADs als Router. Sie disqualifizieren sich per se für alle die keine Dienste nutzen wollen die IADs bereitstellen.
es ist keinem Kunden zuzumuten einen Router zu konfigurieren der es kaum schafft ein Kabel in die TAE zu stecken.
Können wir uns auf RFC1918 anstelle RFC1819 einigen
ich wüsste jetzt keinen Fall auf dem ein zweiter RFC1918 Adressraum Sinn macht und der relevanten Zielgruppe nützlich wäre.
Welches NETZ aus RFC1918 der Speedport primär nutzt ist aber ja einzustellen - also wenn du lieber 192.168.55.0/24 nutzt, dann kannst du dies ohne hacken der Firmware.