Anleitung: Interne Asterisk Anlage auf Openwrt für SIP-URI Anrufe und Rufnummernübermittlung

gaebler

Neuer User
Mitglied seit
8 Jun 2020
Beiträge
15
Punkte für Reaktionen
0
Punkte
1
Situation: Alternativer VDSL Anbieter hat Vectoring ausgebaut und recht teure Verträge ohne Telefonie oder gegen zusätzliche monatliche Gebühr ohne Flatratemöglichkeit

Idee: DSL Router mit DECT für SIP-URI Anrufe verwenden (sip:<SIP-Benutzername>@<ip oder dyndns name> vom Angerufenen erforderlich)

Probleme: Bei SIP-URI Calls übermittelt der DSL Router wegen TKG Anforderungen nur unbekannt oder anonymous (einige Empfänger gehen nicht ran oder leiten auf Anrufbeantworter um), Manche DSL Router lassen keine direkten SIP-URI Anrufe zu (Firewallregeln - z.B. O2 Homebox 2), was sich ggf. durch Routerwechsel beim Empfänger lösen läßt, falls der das macht ;-)

Lösungsansatz: DSL Router meldet sich auf eigenen Asterisk Server an, der auf einem alten TP-Link TD-W9980 Router (Alternative, andere Hardware z.B. Raspi mit OpenWrt oder System mit Möglichkeit Asterisk zu installieren) mit installiertem Asterisk läuft und dieser übernimmt alles, was der DSL Router bei SIP nicht kann/unterstützt. Anrufregeln im DSL Router leiten bestimmte Rufnummern auf Asterisk um, für SIP-URI Direktanrufe.
Ausgewählte Telefonnummern werden also über Asterisk umgeleitet, um Anrufkosten und die Gebühren für Telefonie beim DSL Anbieter zu sparen.
Für ankommende Anrufe habe ich einen kostenlosen SIP Account mit Festnetznummer.

Gelöste Themen: Asterisk als SIP-URI Anrufer hinter NAT (wichtig sind die externhost oder external_... Definitionen), TP-Link Router mit nur 8MB Flash Speicher, Welche Asterisk Pakete müssen minimal installiert werden

Als Asterisk Anfänger habe ich zuerst pjsip probiert, es damit aber nicht zum Laufen bekommen, RTP Pakete wurden nicht übertragen/kein Audio beim telefonieren. Nach Umschwenken auf chan_sip mit dem gleichen Problem habe ich dann tcpdump installiert und beim Trace festgestellt, daß die interne IP vom OpenWrt/Asterisk übertragen wird, was natürlich nicht funktioniert. Daher ist die für chan_sip notwendige Konfiguration angehängt. Den Port vom Asterisk für die SIP Anmeldung im internen Netz habe ich auf 50xx geändert, weil bei 5060 das Auflegen der Gegenstelle nicht beim Asterisk ankam (vermutlich vom DSL Router geschluckt, im tcpip trace hat man gesehen, daß die SIP Pakete vom Asterisk zur Gegenstelle vom Port 5060 kamen).

Voraussetzungen: DSL-Router mit DECT, aktivem Dyndns, bestehender SIP Rufnummer, UDP Portforwarding Möglichkeit, Connection Tracking für UDP, offener SIP Konfiguration und Wahlregeln Rufnummern auf bestimmte SIP Anschlüsse zu leiten und Asterisk auf irgendeiner Hardware mit interner IP Adresse

Aufbau: <Anderer VOIP Anschluss, der SIP-URI Anrufe erlaubt> - <Internet> - <DSL-Router> - <Internes Netz> - <OpenWrt mit Asterisk>
DSL-Router und OpenWrt mit Asterisk sind bei mir mit Kabel verbunden.
Wichtig, ich möchte den anderen VOIP Anschluß anrufen, nicht über den anderen Anschluß telefonieren! Und natürlich gehen mehrere/verschiedene Anschlüsse.

Die Möglichkeit SIP-URI (also Direktanrufe ohne Provider) von DSL-Router zu DSL-Router zu machen, kenne ich schon länger wegen HD-Telefonieversuchen vor etlichen Jahren. Fritz-Boxen unterstützen diese Möglichkeit auch, man muß die SIP-URI ohne "sip:" als Rufnummer eintragen, benötigt dann aber zwingend eine Kurzwahl, z.B. **707 zur Anwahl vom DECT Mobilteil aus.
Wichtig bei z.B. der Fritzbox ist, den SIP Benutzernamen, der im DSL Router konfiguriert ist, in der SIP-URI zu verwenden, der nicht notwendigerweise die Telefonnummer ist, also:
<sip-benutzername>@<ip adresse oder dyndns hostname des Empfänger DSL Routers>, bei anderen Routern muß manchmal noch "sip:" davorgesetzt werden.

Durchführung:
  1. OpenWrt auf TP-W9980 initial installieren, festgestellt, daß keine 3MB für die Asterisk Installation frei sind, Linux Rechner und OpenWrt Image Builder verwendet, um passende OpenWrt Firmware (<7,5MB Größe) zu erstellen und installiert, folgende Asterisk Module habe ich verwendet/waren nötig (chan_sip):

    asterisk16
    asterisk16-bridge-builtin-features
    asterisk16-bridge-simple
    asterisk16-bridge-softmix
    asterisk16-chan-sip
    asterisk16-codec-a-mu
    asterisk16-codec-alaw
    asterisk16-codec-g722
    asterisk16-res-pjproject
    asterisk16-res-rtp-asterisk
    asterisk16-res-sorcery

  2. OpenWrt konfigurieren, so daß eine interne IP Adresse da ist und DNS auf dem Gerät funktioniert (der Einfachheit habe ich den OpenWrt Router als DHCP Client konfiguriert und im DSL Router ein statisches DHCP lease zugewiesen, also daß immer die gleiche IP Adresse vergeben wird)

  3. Den OpenWrt Hostnamen auf den DynDns Namen vom DSL-Router geändert (in einem Trace wurde vor jedem SIP-URI Anruf vom Asterisk ein NSLookup mit dem eigenen Gerätehostnamen gemacht), ist unnötig, wenn man den dyndns hostnamen in der sip.conf bei externhost= einträgt.

  4. Eine Gegenstelle und globale Einstellungen in der sip.conf konfigurieren:
    Code:
    [general]
    disallow=all ;konfig der codecs
    allow=g722 ;hd-voice
    allow=alaw ;G711
    qualify=yes
    canreinvite=no
    directmedia=nonat ;Directmedia nicht bei NAT
    rtp_keepalive=1 ;Keepalive für RTP
    externhost=hostname.dyndnsanbieter.domain ;externe IP DSL Router für RTP Funktion
    externrefresh=1200 ;externhost DNS refresh interval
    localnet=192.168.1.0/255.255.255.0
    language=de
    bindport=50xx ;Antworten gingen sonst an DSL Router
    allowguest=no ;keine Gastanmeldungen
    tos_sip=cs3 ;QoS Tag kann nicht schaden
    tos_audio=ef ;dito
    
    [Telefon] ;nur für abgehende SIP Anrufe genutzt
    type=friend
    context=from-internal
    host=dynamic
    defaultuser=Telefon ;username für SIP config
    secret=mypass ;passwort für SIP config
    nat=no ;kein NAT im internen Netz
    canreinvite=no
    callerid=MeinName <0xxxxxxxxxxxxx> ; anzuzeigender Name und Rufnummer

  5. extensions.conf (jede Rufnummer, die auf eine SIP-URI umgeleitet werden soll, braucht eine eigene Regel):
    Code:
    [from-internal]
    ;Gegenstelle1
    exten => 0xxxxxxxxxxx,1,Dial(SIP/sip:<benutzer/telefonnummer>@<ip oder hostname>,60,r)
    exten => 0xxxxxxxxxxx,2,Hangup
    ;Gegenstelle2
    exten => 0yyyyyyyyyyy,1,Dial(SIP/sip:<benutzer/telefonnummer>@<ip oder hostname>,60,r)
    exten => 0yyyyyyyyyyy,2,Hangup

  6. Asterisk mit der neuen Konfiguration starten und ggf. mit Trace Option starten


    [*]Im DSL-Router Port-Forward einrichten, Port 50xx mit Protokoll UDP und der internen IP vom OpenWrt/Asterisk.

  7. Im DSL-Router die SIP Daten konfigurieren (Benutzer aus sip.conf ist Telefon und Passwort ist mypass, Rufnummer für die Anmeldung auch Telefon, interne Rufnummer z.B. 6000, Registrar Openwrt IP Adresse mit Port, z.B. 192.168.1.5:50xx) und die erfolgreiche Anmeldung abwarten.

  8. Entweder Telefonnummerneintrag von 0xxxxxxxxxxx ändern, daß über 6000/Telefon SIP Nutzer angerufen wird oder Anrufregel definieren (je nach Gerät, in der Webschnittstelle oder auch mit Tastencode wie *188#...), um über Asterisk zu telefonieren.

  9. Testanrufe machen

Viel Erfolg.

Update1: Das Portmapping ist unnötig, siehe nächsten Post. Entfernt.
Update2: allowexternaldomains=no ohne konfigurierte Domains ist nutzlos. Entfernt.
 
Zuletzt bearbeitet:

gaebler

Neuer User
Mitglied seit
8 Jun 2020
Beiträge
15
Punkte für Reaktionen
0
Punkte
1
Ich habe im Log von Asterisk folgende Einträge gefunden:
[Jun 9 00:20:21] NOTICE[1445] chan_sip.c: Registration from '<sip:[email protected]>' failed for '185.53.88.15:4359' - Wrong password
[Jun 9 00:20:21] NOTICE[1445] chan_sip.c: Registration from '<sip:[email protected]>' failed for '185.53.88.15:5699' - Wrong password
[Jun 9 00:20:21] NOTICE[1445] chan_sip.c: Registration from '<sip:[email protected]>' failed for '185.53.88.15:5699' - Wrong password
Die auf Angriffsversuche von außen über den offenen UDP Port hindeuten.

[Jun 9 13:10:33] WARNING[1445] chan_sip.c: Timeout on 1514422348-1095737217-498604694 on non-critical invite transaction.
[Jun 9 13:23:03] WARNING[1445] chan_sip.c: Timeout on 1583786088-370367934-1921201293 on non-critical invite transaction.
Dafür habe ich einen Packettrace gemacht und herausgefunden, daß diese WARNINGs unberechtigte Telefonierversuche sind:
Code:
19:54:37.339049 IP 103.253.42.59.61659 > 192.168.x.x.50xx: UDP, length 695
        0x0000:  4500 02d3 2272 0000 7411 1d97 67fd 2a3b  E..."r..t...g.*;
        0x0010:  c0a8 b130 f0db 13e2 02bf ff06 494e 5649  ...0........INVI
        0x0020:  5445 2073 6970 3a30 3038 3436 3432 3331  TE.sip:008464231
        0x0030:  3132 3931 3040 3138 352e 3338 2e34 392e  [email protected]
        0x0040:  3132 3320 5349 502f 322e 300d 0a56 6961  123.SIP/2.0..Via
        0x0050:  3a20 5349 502f 322e 302f 5544 5020 3130  :.SIP/2.0/UDP.10
        0x0060:  332e 3235 332e 3432 2e35 393a 3631 3635  3.253.42.59:6165
        0x0070:  393b 6272 616e 6368 3d7a 3968 4734 624b  9;branch=z9hG4bK
        0x0080:  3230 3931 3334 3637 3034 0d0a 4d61 782d  2091346704..Max-
        0x0090:  466f 7277 6172 6473 3a20 3730 0d0a 4672  Forwards:.70..Fr
        0x00a0:  6f6d 3a20 3c73 6970 3a32 3030 3040 3138  om:.<sip:[email protected]
        0x00b0:  352e 3338 2e34 392e 3132 333e 3b74 6167  5.38.49.123>;tag
        0x00c0:  3d31 3330 3233 3633 3133 380d 0a54 6f3a  =1302363138..To:
        0x00d0:  203c 7369 703a 3030 3834 3634 3233 3131  .<sip:0084642311
        0x00e0:  3239 3130 4031 3835 2e33 382e 3439 2e31  [email protected]
        0x00f0:  3233 3e0d 0a43 616c 6c2d 4944 3a20 3139  23>..Call-ID:.19
        0x0100:  3132 3030 3435 3239 2d35 3530 3338 3537  12004529-5503857
        0x0110:  3535 2d31 3838 3335 3836 3130 390d 0a43  55-1883586109..C
        0x0120:  5365 713a 2031 2049 4e56 4954 450d 0a43  Seq:.1.INVITE..C
        0x0130:  6f6e 7461 6374 3a20 3c73 6970 3a32 3030  ontact:.<sip:200
        0x0140:  3040 3130 332e 3235 332e 3432 2e35 393a  [email protected]:
        0x0150:  3631 3635 393e 0d0a 436f 6e74 656e 742d  61659>..Content-
        0x0160:  5479 7065 3a20 6170 706c 6963 6174 696f  Type:.applicatio
...

Daraufhin habe ich das Portforwarding im DSL-Router wieder deaktiviert und nochmal probiert und zumindest bei kurzen Telefonaten wurde das Auflegen der Gegenstelle erkannt.
 
Zuletzt bearbeitet:

gaebler

Neuer User
Mitglied seit
8 Jun 2020
Beiträge
15
Punkte für Reaktionen
0
Punkte
1
Hallo,

ja, da ich die Asterisk in meinem Anwendungsfall nur für ausgehende Anrufe verwende/brauche und schonmal angefangen habe, wegen Firewall Konfigurationen zu schauen und zu testen, analog hier:
https://wiki.freepbx.org/pages/viewpage.action?pageId=33882179
oder hier:
https://www.cyber-cottage.eu/?p=1028

bin ich aber nochmal auf die Idee gekommen, ohne UDP Port Forward auf 50xx (also den internen Port der Asterisk) zu testen.
Und da das funktioniert hat, ist für mich jetzt die Lösung den UDP Port im DSL-Router einfach wieder zuzumachen.

Das IP Paket habe ich nur in den Thread gemacht, weil es nicht so leicht für mich war, wenn alles soweit funktioniert, auf die Ursache SIP Attacke zu kommen mit den Suchbegriffen:
WARNING[1445] chan_sip.c Timeout on non-critical invite transaction
 

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
13,339
Punkte für Reaktionen
457
Punkte
83
Das (Admin) Tool, mit dem du Asterisk auf Eindringlichkeit testen kannst...
https://github.com/EnableSecurity/sipvicious
...wird auch gerne für Angriffe benutzt.
Für einfachen Test wie Asterisk auf OPTIONS antwortet reicht: sipsak

Pass auf deine Wahlpläne auf.
Ein SIP URI Call, wie obiges INVITE, sollte in einem Kontext ( [default] ) landen, der das in ein Log schreibt und sogleich wieder auflegt ( Hangup(17) ).
Für sowas eignet sich auch die AstDB.
 

sonyKatze

Aktives Mitglied
Mitglied seit
6 Aug 2009
Beiträge
2,534
Punkte für Reaktionen
225
Punkte
63
Schöne kompakte Anleitung. Ja, solche automatischen Scans sind normal, denn Dein Internet-Provider macht (leider) nichts dagegen. Du kannst noch das Paket fail2ban installieren. Dann reicht ein ordentliches Passwort ab und zu geändert. Aber wenn Du Deinen Digium Asterisk nur abgehend nutzen willst, dann brauchst Du tatsächlich kein Port-Forwarding.

Allerdings musst Du dann den NAT-Session-Timeout Deines Routers im Griff haben. Sonst kommen die SIP-Nachrichten nicht mehr zu Deinem Digium Asterisk durch. Du hast während einem Anruf eine SIP-Verbindung (INVITE). Auf der baut Dein Digium Asterisk den Anruf auf. Dein VoIP/SIP-Provider möchte Dir auf genau dieser Verbindung SIP-Nachrichten schicken (BYE oder re-INVITE). Aber ist der NAT-Session-Timeout abgelaufen, verwirft Dein Router alle eingehende Pakete auf diesem Port. Die SIP-Nachricht Deines VoIP/SIP-Anbieters kommt bei Deinem Digium Asterisk nicht mehr an. Daher klappt Auflegen (BYE) bei langen Telefonaten nicht. Bei anderen Anbietern klappen längere Telefone nicht (~15 Minuten) bzw. auf einmal hast Du keine Medien mehr (Mobilfunk-Anrufe), weil re-INVITEs nicht mehr ankommen.

Ein Lösungsansatz ist, anstatt UDP auf TCP (oder TLS) zu wechseln. Dann schaffst Du mit einer FRITZ!Box bereits 15 Minuten. Bei einigen Routern wie DrayTek sind die Standard-Werte besser. Bei DrayTek, LANCOM und OpenWRT können diese Werte manuell eingestellt werden. Beispielsweise bei OpenWRT bist Du bei Verwendung von UDP quasi gezwungen das anzupassen. AVM und LANCOM sind bei TCP zu kurz. OpenWRT ist bei UDP zu kurz. Viele VoIP/SIP-Anbieter wie Sipgate frischen von sich aus die SIP-Verbindung auf. Daher hast Du das Problem nicht mit allen sondern nur mit einigen Anbietern.

Ein anderer Lösungsansatz ist, dass Dein Digium Asterisk selbst die SIP-Verbindung auffrischt:
a) über SIP-Nachrichten; für chan_sip: qualifyfreq=60 (mittels OPTIONS) oder session-expires=90 (mittels re-INVITE)​
b) über CRLFCRLF; für chan_sip: keepalive=yes
c) über TCP-Keepalive: sudo sysctl -w net.ipv4.tcp_keepalive_time=295
Letzteres (mein Favorit) schreibst Du nicht in die Datei sip.conf, sondern das gibst Du in der Kommandozeile Deines Betriebssystems ein. Ersteres ist gefährlich, weil nicht alle VoIP/SIP-Anbieter SIP-OPTIONS und/oder SIP-Session-Timers unterstützen bzw. manche verlangen höhere Timeouts. Daher habe ich das bei mir in der Datei sip.conf sogar ausgeschaltet: session-timers=refuse.

Puh. Ich hoffe, ich habe jetzt nicht zu viele Fehler drin (Anmerkungen gerne via privater Nachricht, dann korrigiere ich das hier). Jetzt wirst Du denken: „Dann mache ich stattdessen IPv6!“ Ja, bei IPv6 hat Du kein NAT – die IP-Adressen in SIP bzw. SDP sind immer richtig. Aber bei IPv6 hast Du immer noch eine Firewall. Und auch die hat Session-Timeouts. Daher gilt das eben Geschriebene auch für IPv6.
 
Zuletzt bearbeitet:

gaebler

Neuer User
Mitglied seit
8 Jun 2020
Beiträge
15
Punkte für Reaktionen
0
Punkte
1
Ja, vielen Dank für die Tips, zum Glück hat der Asterisk bei mir und meinen Wählplänen (die ja nur konkrete Nummern, für die ich SIP Ziele kenne, enthalten) einfach ein Unauthorized zurückgeschickt, das sah dann so aus:
Code:
19:34:20.516704 IP 192.168.x.x.50xx > 103.253.42.59.52943: UDP, length 518
        0x0000:  4560 0222 ccaa 0000 4011 a7af c0a8 b130  E`."[email protected]
        0x0010:  67fd 2a3b 13e2 cecf 020e 0631 5349 502f  g.*;.......1SIP/
        0x0020:  322e 3020 3430 3120 556e 6175 7468 6f72  2.0.401.Unauthor
        0x0030:  697a 6564 0d0a 5669 613a 2053 4950 2f32  ized..Via:.SIP/2
        0x0040:  2e30 2f55 4450 2031 3033 2e32 3533 2e34  .0/UDP.103.253.4
        0x0050:  322e 3539 3a35 3239 3433 3b62 7261 6e63  2.59:52943;branc
        0x0060:  683d 7a39 6847 3462 4b31 3237 3932 3437  h=z9hG4bK1279247
        0x0070:  3730 363b 7265 6365 6976 6564 3d31 3033  706;received=103
        0x0080:  2e32 3533 2e34 322e 3539 0d0a 4672 6f6d  .253.42.59..From
        0x0090:  3a20 3c73 6970 3a32 3030 3040 3138 352e  :.<sip:[email protected]
        0x00a0:  3338 2e34 392e 3132 333e 3b74 6167 3d31  38.49.123>;tag=1
        0x00b0:  3137 3433 3634 3036 310d 0a54 6f3a 203c  174364061..To:.<
        0x00c0:  7369 703a 3030 3234 3634 3233 3131 3239  sip:002464231129
        0x00d0:  3130 4031 3835 2e33 382e 3439 2e31 3233  [email protected]
        0x00e0:  3e3b 7461 673d 6173 3237 3436 6138 3739  >;tag=as2746a879
        0x00f0:  0d0a 4361 6c6c 2d49 443a 2039 3630 3135  ..Call-ID:.96015
        0x0100:  3334 3238 2d31 3933 3333 3831 3734 362d  3428-1933381746-
        0x0110:  3139 3136 3939 3636 3137 0d0a 4353 6571  1916996617..CSeq
        0x0120:  3a20 3120 494e 5649 5445 0d0a 5365 7276  :.1.INVITE..Serv
        0x0130:  6572 3a20 4173 7465 7269 736b 2050 4258  er:.Asterisk.PBX
        0x0140:  2031 362e 332e 300d 0a41 6c6c 6f77 3a20  .16.3.0..Allow:.
...
Die NAT Timeout Lösung schaue ich mir mal an, Danke.
 

gehtdoch

Mitglied
Mitglied seit
3 Feb 2019
Beiträge
233
Punkte für Reaktionen
16
Punkte
18
Ein paar Anmerkungen / Fragen:
  • chan_sip ist legacy (freundlich formuliert) - faktisch: tot. pjsip ist heute der korrekte Weg.
  • Du verwendest für eingehende Calls den SIP-Account Deines DSL-Providers
  • Du verwendest für ausgehende Calls sowohl Deinen DSL-Provider als Telko als auch für manche Nummern den direkten Weg via SIP URI calls (die eben so erreichbar sind - wäre ich als Telekom Telefoniekunde z.B. so erreichbar? Habe mich mit der Thematik noch nicht beschäftigt).
Die Folgen:
  • Reduzierte Gesprächsqualität (kein QoS)
  • Sicherheitsprobleme auf Deiner Seite (weitestgehend offener SIP-Server - leicht angreifbar - Du musst ständig auf alle sicherheitsrelevanten Details achten).
  • Erhebliche zusätzliche Komplexität - grausiges NAT-Geraffel. Warum eigentlich nicht gleich richtig machen ohne NAT?
Warum nicht einen freien Provider für die Telefonie als Ganzes verwenden? easybell z.B. ist nicht gerade teuer. Gut, löst das QoS-Problem zwar nicht - aber alle anderen Probleme wären vom Tisch.

Der unbestreitbare Vorteil der Lösung: Know-how Gewinn.
 

sonyKatze

Aktives Mitglied
Mitglied seit
6 Aug 2009
Beiträge
2,534
Punkte für Reaktionen
225
Punkte
63
So versteht das kein Mensch. Jedenfalls ich verstehe nix. Und bevor ich auf chan_pjsip wechsele, ginge ich eher ganz zu FreeSWITCH.
 

gaebler

Neuer User
Mitglied seit
8 Jun 2020
Beiträge
15
Punkte für Reaktionen
0
Punkte
1
Vollzitat gemäß Boardregeln entfernt by stoney
Ich hab mit pjsip angefangen, NAT hat nicht funktioniert, daher schauen ob der Fehler wandert. Es hat mich recht viel Zeit gekostet und es läuft jetzt alles, wenn ich die Zeit finde auf pjsip zu wechseln mache ich das, das Aufwendigste ist das Paketierungsproblem, da man vorher nicht weiß, welche Softwarepakete gebraucht werden, aber das ist eher ein Problem von OpenWrt und daß ich für jeden Versuch ein neues Firmwareimage bauen muß und neu flashen.

Es gibt keinen SIP-Account vom Provider, der würde 5 EUR extra im Monat kosten, ohne Flatrate + Verbindungsgebühren. Wenn ich Verbindungskosten mit einbeziehe, spare ich dadurch 100 EUR im Jahr gegenüber einer bezahlten Lösung, auch wenn die nicht teuer ist.

Ich hab bisher mit Mobiltelefon zurückgerufen, jetzt benutze ich bei ausgewählten Anschlüssen eben SIP-URI mit dem DECT Mobilteil. Die Lösung ist eher ein Komfortgewinn bei weiterhin 0 Kosten und unter Verwendung alter Hardware, die sowieso gebraucht wird.

QoS ist auch da mit anderen Provider oder Bezahllösung, wie du auch selbst schriebst, nicht lösbar.

In der jetzigen Konfiguration ist kein Port mehr nach außen geöffnet und der SIP Server nur intern erreichbar, ich sehe darin kein großes Problem. Mal abgesehen davon, daß die Wahlregeln nur für die SIP-URI Telefonnummern funktionieren und alles andere nicht. Ich habe keinerlei generische Wahlregeln.

Die NAT Lösung funktioniert bisher zuverlässig (man darf halt intern der Asterisk nicht den Port 5060 geben), hatte bisher keine Gesprächsabbrüche oder seltsames Verhalten. Die Familienlans sind mit VPN verbunden, neue Hardware kostet Geld und bedeutet zusätzlichen Konfigurationsaufwand in deutlich mehr Bereichen (VPN, Firewall, Asterisk) als mit der jetzigen Lösung (nur Asterisk). Und bevor du fragst, die Anrufsignalisierung über VPN funktioniert nicht generell, weil ich auch Anschlüsse über SIP-URI anrufe, mit denen ich nicht über VPN verbunden bin.
 
Zuletzt bearbeitet von einem Moderator:

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
oder via