Weil hier immer mal wieder Probleme mit NAT und Asterisk hochgekommen sind (beim einen gehts - beim anderen nicht), wollte ich der Problematik mal auf den Grund gehen.
Das Thema "beim einen gehts, beim anderen nicht" wird ja gerne oberflächlich am VoIP-Provider festgemacht, weil es "gute" VoIP-Provider gibt, wo es eben "geht" und scheinbar schlechte VoIP-Provider gibt, wo es eben nicht geht. Ziel meiner Untersuchungen war nun, im Detail zu analysieren, warum das so ist, was oberflächlich festgestellt wird und dann fälschlicherweise zur VoIP-Providerschelte hochstilisiert wird - was aber natürlich falsch ist - soviel kann ich schon vorab sagen.
Ich selbst konnte bei meinen Untersuchungen beide oben beschriebenen Beobachtungen nachstellen. Ohne zunächst in deep zu gehen, konnte ich oberflächlich folgendes feststellen:
Mit easybell praktisch keine feststellbaren Probleme (im Schnelltest) - mit Telekom All-IP -> nichts geht.
Weitere festgestellte Abhängigkeiten: Es kommt auf die Komplexität des eigenen Systems an (multihomed (= mehrere Devices / IP-Adressen auf dem System, auf dem Asterisk läuft) oder nicht) und es kommt auf das NAT-Gateway selbst an und es kommt auf die jeweilige transport-Konfiguration an (was nicht heißt, dass es noch mehr Abhängigkeiten geben könnte, auf die ich eben nicht gestoßen bin).
Also, let's go in deep.
SIP ist bereits abseits von NAT ein komplexes Protokoll, weil es im Protokoll selbst u.a. die Verbindungsdaten für verschiedene Netzwerkverbindungen definiert: einmal die SIP-Ebene und einmal die RTP-Ebene. Wenn Asterisk kein NAT machen muss, weil es die globale IP direkt verwenden kann (weil sie auf dem System verfügbar ist), ist das die sicherste und sauberste Variante und die Wahrscheinlichkeit, dass es hier zu Problemen kommt ist fast 0 (fast deshalb, weil man sich mit einem Portfilter immer noch ins Knie schießen kann - aber das ist dann nicht mehr das Problem von Asterisk).
SIP + NAT wird nun allerdings extrem komplex, weil Asterisk ja die globale Netzwerkverbindung (IP-Adresse und Port), die für ein ordentliches SIP-Protokoll zwingend benötigt wird, nicht kennt. Jetzt gibt es für dieses recht komplexe Problem diverse Lösungsansätze (aus meiner Sicht sind das alles üble Workarounds, die mal funktionieren oder auch nicht und im Einzelnen ziemlich stark vom Zusammenspiel SIP-Client und VoIP-Provider abhängen und was eben jeweils wie im Detail unterstützt wird). Ich werde auf die sämtlichen Möglichkeiten, die es da gibt, nicht eingehen, sondern nur die Variante beleuchten, die ohne all diese Workarounds auskommt und mit (weitgehend zumindest) Asterisk Boardmitteln nachgewiesenermaßen stabil funktioniert (habe ich seit geraumer Zeit nun selbst am Laufen in einem vergleichsweise hochkomplexen System).
Alle detaillierten Aussagen beziehen sich auf eine Asterisk 18.4 / pjsip und SIP over TLS - Konfiguration, auf Basis der Konfiguration hier.
Zusätzlich werden nun die folgenden Parameter verwendet (in der Transportkonfiguration):
Außerdem den dnsmgr einschalten (in der /etc/asterisk/dnsmgr.conf)
Strategie für die beiden Parameter: das ist ein Hostname, der per DNS zur korrekten IP führt. Beim IP-Adresswechsel muss dann natürlich auch die Auflösung im DNS angepasst werden - sonst wird das nichts.
Das ganze kann man beschleunigen im Rahmen eines Adresswechsels mit
Verändert wurde der Parameter
Das ist nötig, damit Asterisk schneller den zugehörigen Transport durchstartet - anders bekommt er die Umsetzung der geänderten globalen IP-Adresse nicht auf die Reihe.
Normalerweise werden Antworten an die Source-IP-Adresse und den Source port zurückgeschickt (force_rport=yes)
Falls an den im Via-Header definierten Port geschickt werden soll, muss force_rport=no sein.
Aus Sicht von Asterik: ausgehender RTP-Strom geht an die gleiche Adresse, von der Asterisk RTP empfängt. c= und m= im eingegangenen SDP werden ignoriert. Hier kann im beschriebenen Fall auch rtp_symmetric=no verwendet werden, da die nun enthaltenen Ports im SDP ja korrekt sind.
Neuer Parameter auf Grund Patch nobind.diff - siehe angehängtes zip-File in der Transport-Konfiguration
Bewirkt, dass die für externe Registrierung zum VoIP-Provider verwendete Transports keine Listener anlegen - ist in pjsip so vorgesehen - in Asterisk aber nicht durchgeschleift. Der Patch bewirkt also nichts anderes, als dass eine vorgesehene sehr sinnvolle Funktionalität aus pjsip auch tatsächlich genutzt werden kann in Asterisk: nämlich einen Transport zu definieren, der keinen zugehörigen Listener hat.
Ein ausgehender Register zu einem VoIP-Provider sollte auf jeden Fall immer einen eigenen Transport bekommen, weil im Rahmen des globalen IP-Adresswechsels (als Folge eines Routerrestarts z.B.) immer der Transport durchgestartet werden muss, was auch zu einem Verlust der von intern registrierten Telefonen führt / führen kann - welche dann so lange nicht erreichbar sind bzw. auch für ausgehende Calls nicht geutzt werden können, bis sie sich wieder von selbst irgendwann nach Ablauf der ReRegister-Zeit neu registriert haben. Das will man nicht unbedingt haben. Daher Transport Client und Transport Server grundsätzlich trennen!
Warum funktioniert es nun eigentlich im Detail zum VoIP-Provider A scheinbar out of the box - zum VoIP-Provider b aber nicht? Das liegt daran, dass Asterisk in Sachen NAT ziemlich buggy ist. Asterisk nimmt es mit der Anwendung der für NAT relevanten Anpassungen nicht so genau (= inkonsistent), was dazu führt, dass in den einzelnen Request / Responses teilweise ziemlicher Müll drin steht, was bei den VoIP-Providern, bei denen es "funktioniert" schlicht und ergreifend ignoriert wird, während es bei anderen VoIP-Providern eben nicht ignoriert wird und die daher abbrechen (gut so). Wie soll man denn z.B. einen abweichenden Mediaserver definieren können, wenn der VoIP-Provider einfach die Pakete an den SIP-Server zurückschickt (weil er eben einfach die Verbindungsdaten nimmt, die er von der Netzwerkschicht bekommen hat im Rahmen des SIP-Verkehrs)? Woher soll der VoIP-Provider wissen, was nun richtig und falsch ist, wenn's mal so, mal so geschickt wird? Rate mal mit Rosenthal ist nie gut.
Wo sind die Probleme im Detail ohne die NAT-Patches?
Im SDP während SIP-Handshake / im ersten INVITE des Handshakes ist noch alles ok - im Zweiten INVITE (als Folge des 407 Proxy Auth required) ist es dann kaputt (=> inkonsistent - mal so, mal so - man beachte die lokale IP!):
Im VIA - Header als ACK auf den 407 im SIP-Handshake wird die falsche IP verwendet (die lokale statt globale - im initialen Invite wurde noch die korrekte gloable IP verwendet => inkonsistent).
Die rport-Einstellung hat bei mir im Übrigen nie gezogen - egal was parametrisiert wurde - die Antwort vom VoIP-Provider wurde nie weiter verwendet in den Folge-Requests / Responses (ich habe das auch nicht weiter analysiert - war mir zu blöd. Mein Ziel war und ist immer, dass im SIP und RTP-Protokoll konsistent die für den VoIP-Provider durchgängig korrekten Werte drin stehen, weil das die umfassendste und sicherste und sauberste Methode ist).
Ein weiteres essentielles Thema bei NAT ist, dass die vom NAT-Gateway nach außen verwendeten Ports für die gloable IP nicht zwangsweise die gleichen sein müssen, wie die von Asterisk verwendeten lokalen Ports und daher der von Asterisk im SIP- bzw. RTP-Protokoll hinterlegte Port vom real nach außen verwendeten Port abweichen kann. Das führt beim einen oder anderen VoIP-Provider auch zu Problemen, wenn sie es genauer nehmen (wie die Telekom All-IP z.B.).
Man muss daher darauf achten, dass das NAT-Gateway nicht die Ports verändert, die Asterisk ursprünglich verwendet hat, d.h., dass für die genattete IP der selbe Port verwendet wird wie für die interne IP verwendet wurde, so dass keine Differenzen zwischen SIP- / RTP-Protokoll und Netzwerkstack auftreten. Dies kann man mit einem Linuxrouter wie folgt erzwingen:
Weiterer wichtiger Punkt für das NAT-Gateway: Die "Übersetzung" lokale IP <-> globale IP muss während der ganzen Verbindungszeit offengehalten werden - d.h., das Gateway darf die Verbindung nicht nach geraumer Zeit (timeout) kappen. Dies wird bei der vorgestellten Lösung out of the box erreicht, ohne weitere Einstellungen, da pjsip einen default TLS-Ping (PJSIP_TLS_KEEP_ALIVE_INTERVAL) mitbringt.
Wie funktioniert die genannte Konfiguration nun im Detail?
Das ist auf Basis der oben beschrieben Vorgehensweise jetzt eigentlich ganz einfach: es gibt keine Differenzen zwischen SIP und RTP-Protokoll und dem Netzwerkstack mehr - auch über das NAT-Gateway hinweg. Damit sieht für den VoIP-Provider alles so aus, wie wenn gar kein NAT vorliegen würde - also alles gut.
Die relevanten Patches habe ich angehängt. Wichtig ist, dass für den Patch nobind.diff das gesamte Asterisk / pjsip-Paket zwingend mit dem Compileschalter PJSIP_TLS_TRANSPORT_DONT_CREATE_LISTENER bzw. PJSIP_TCP_TRANSPORT_DONT_CREATE_LISTENER übersetzt werden muss - sonst wird das nichts (ist von pjsip so vorgesehen)! Ich gehe davon aus, dass das pjsip - Bundle verwendet wird (und nicht ein auf dem System vorhandenes pjsip unabhängig von Asterisk verwendet wird).
Erreicht wird dies praktisch, indem man die Umgebungsvariable CFLAGS vor der Konfiguration im Rahmen des Übersetzungsvorgangs bereits mit den entsprechenden Werten belegt - Achtung - sicherstellen, dass man nicht evtl. andere schon vorhandene CFLAGS überschreibt! Ich verwende das Sangoma spec-Paket und habe daher die Definition im spec-File wie folgt angepasst:
Weitre Inforamtionen zu den beiden NAT-Patches gibt es hier.
Ein weiterer derzeit noch wichtiger Patch. Betrifft die Asterik Versionen 18.4 und 16.18. Sollte dann mit den Folgeversionen gefixt sein.
Zudem - mittlerweile sind Asterisk-Kollegen wohl dazu übergegangen, dass Patches, welche von Personen eingereicht werden, die ihnen nicht vollständig bekannt sind (Name, Adresse, Telefonnummer, ...), einfach wieder entfernt werden. 73433a5.diff war mal in ASTERISK-29241 enthalten und von Florian Floimair eingereicht worden. Aber selber darum kümmern tun sie sich auch nicht. Da gibt es leider eine ganze Menge davon. Irgendwie haben die ein gespanntes Verhältnis zur Community bzw. überhaupt zum Thema Anerkennen von Problemen überhaupt und Fixen in Folge (sie müssen ja nicht die vorgeschlagenen übernehmen, wenn sie bessere haben - dagegen spricht nichts - aber es sollte wenigstens bereinigt werden). Wie es aussieht zu wenig Personal. Daher kommt es zu derartigen dezentralen Patchorgien, was für niemand witzig ist.
Ich hoffe, dass es dem einen oder anderen (bei der Analyse und Lösung) hilft, wenn er im Zusammenhang mit NAT auf Probleme stößt.
Update 22.06.2021: Formatierungsfix, Gatewaytimeout ergänzt, Eindeutigkeit VoIP-Provider gesetzt.
Das Thema "beim einen gehts, beim anderen nicht" wird ja gerne oberflächlich am VoIP-Provider festgemacht, weil es "gute" VoIP-Provider gibt, wo es eben "geht" und scheinbar schlechte VoIP-Provider gibt, wo es eben nicht geht. Ziel meiner Untersuchungen war nun, im Detail zu analysieren, warum das so ist, was oberflächlich festgestellt wird und dann fälschlicherweise zur VoIP-Providerschelte hochstilisiert wird - was aber natürlich falsch ist - soviel kann ich schon vorab sagen.
Ich selbst konnte bei meinen Untersuchungen beide oben beschriebenen Beobachtungen nachstellen. Ohne zunächst in deep zu gehen, konnte ich oberflächlich folgendes feststellen:
Mit easybell praktisch keine feststellbaren Probleme (im Schnelltest) - mit Telekom All-IP -> nichts geht.
Weitere festgestellte Abhängigkeiten: Es kommt auf die Komplexität des eigenen Systems an (multihomed (= mehrere Devices / IP-Adressen auf dem System, auf dem Asterisk läuft) oder nicht) und es kommt auf das NAT-Gateway selbst an und es kommt auf die jeweilige transport-Konfiguration an (was nicht heißt, dass es noch mehr Abhängigkeiten geben könnte, auf die ich eben nicht gestoßen bin).
Also, let's go in deep.
SIP ist bereits abseits von NAT ein komplexes Protokoll, weil es im Protokoll selbst u.a. die Verbindungsdaten für verschiedene Netzwerkverbindungen definiert: einmal die SIP-Ebene und einmal die RTP-Ebene. Wenn Asterisk kein NAT machen muss, weil es die globale IP direkt verwenden kann (weil sie auf dem System verfügbar ist), ist das die sicherste und sauberste Variante und die Wahrscheinlichkeit, dass es hier zu Problemen kommt ist fast 0 (fast deshalb, weil man sich mit einem Portfilter immer noch ins Knie schießen kann - aber das ist dann nicht mehr das Problem von Asterisk).
SIP + NAT wird nun allerdings extrem komplex, weil Asterisk ja die globale Netzwerkverbindung (IP-Adresse und Port), die für ein ordentliches SIP-Protokoll zwingend benötigt wird, nicht kennt. Jetzt gibt es für dieses recht komplexe Problem diverse Lösungsansätze (aus meiner Sicht sind das alles üble Workarounds, die mal funktionieren oder auch nicht und im Einzelnen ziemlich stark vom Zusammenspiel SIP-Client und VoIP-Provider abhängen und was eben jeweils wie im Detail unterstützt wird). Ich werde auf die sämtlichen Möglichkeiten, die es da gibt, nicht eingehen, sondern nur die Variante beleuchten, die ohne all diese Workarounds auskommt und mit (weitgehend zumindest) Asterisk Boardmitteln nachgewiesenermaßen stabil funktioniert (habe ich seit geraumer Zeit nun selbst am Laufen in einem vergleichsweise hochkomplexen System).
Alle detaillierten Aussagen beziehen sich auf eine Asterisk 18.4 / pjsip und SIP over TLS - Konfiguration, auf Basis der Konfiguration hier.
Zusätzlich werden nun die folgenden Parameter verwendet (in der Transportkonfiguration):
Code:
external_media_address=[externalhostname] oder wo man es auch immer haben mag
external_signaling_address=[externalhostname]
local_net=192.168.0.0/16 ; (wenn man nur 192.168.0.0 verwendet, anosnten eben mit einer weiteren Zeile auch noch das 10.er Netz hinterlegen oder was man eben sonst noch alles nicht Natten will).Außerdem den dnsmgr einschalten (in der /etc/asterisk/dnsmgr.conf)
Code:
[general]
enable=yes
refreshinterval=600 ; (ich habe den Wert hier so hoch gewählt, weil ich weiter unten im Falle eines Adresswechsels das sowieso selbst mitbekomme und dann direkt steuere)Strategie für die beiden Parameter: das ist ein Hostname, der per DNS zur korrekten IP führt. Beim IP-Adresswechsel muss dann natürlich auch die Auflösung im DNS angepasst werden - sonst wird das nichts.
Das ganze kann man beschleunigen im Rahmen eines Adresswechsels mit
Code:
/usr/sbin/asterisk -x "dnsmgr refresh"
sleep 1
/usr/sbin/asterisk -x "pjsip send register *all"Verändert wurde der Parameter
Code:
retry_interval=20 ; (im type=registration) - oder auch kürzer
Code:
force_rport=no ; (im type=endpoint)Falls an den im Via-Header definierten Port geschickt werden soll, muss force_rport=no sein.
Code:
rtp_symmetric=yes ; (im type=endpoint)Neuer Parameter auf Grund Patch nobind.diff - siehe angehängtes zip-File in der Transport-Konfiguration
Code:
nobind=1Ein ausgehender Register zu einem VoIP-Provider sollte auf jeden Fall immer einen eigenen Transport bekommen, weil im Rahmen des globalen IP-Adresswechsels (als Folge eines Routerrestarts z.B.) immer der Transport durchgestartet werden muss, was auch zu einem Verlust der von intern registrierten Telefonen führt / führen kann - welche dann so lange nicht erreichbar sind bzw. auch für ausgehende Calls nicht geutzt werden können, bis sie sich wieder von selbst irgendwann nach Ablauf der ReRegister-Zeit neu registriert haben. Das will man nicht unbedingt haben. Daher Transport Client und Transport Server grundsätzlich trennen!
Warum funktioniert es nun eigentlich im Detail zum VoIP-Provider A scheinbar out of the box - zum VoIP-Provider b aber nicht? Das liegt daran, dass Asterisk in Sachen NAT ziemlich buggy ist. Asterisk nimmt es mit der Anwendung der für NAT relevanten Anpassungen nicht so genau (= inkonsistent), was dazu führt, dass in den einzelnen Request / Responses teilweise ziemlicher Müll drin steht, was bei den VoIP-Providern, bei denen es "funktioniert" schlicht und ergreifend ignoriert wird, während es bei anderen VoIP-Providern eben nicht ignoriert wird und die daher abbrechen (gut so). Wie soll man denn z.B. einen abweichenden Mediaserver definieren können, wenn der VoIP-Provider einfach die Pakete an den SIP-Server zurückschickt (weil er eben einfach die Verbindungsdaten nimmt, die er von der Netzwerkschicht bekommen hat im Rahmen des SIP-Verkehrs)? Woher soll der VoIP-Provider wissen, was nun richtig und falsch ist, wenn's mal so, mal so geschickt wird? Rate mal mit Rosenthal ist nie gut.
Wo sind die Probleme im Detail ohne die NAT-Patches?
Im SDP während SIP-Handshake / im ersten INVITE des Handshakes ist noch alles ok - im Zweiten INVITE (als Folge des 407 Proxy Auth required) ist es dann kaputt (=> inkonsistent - mal so, mal so - man beachte die lokale IP!):
Code:
o=- 1629177632 1629177632 IN IP4 192.168.25.170
s=Asterisk
c=IN IP4 192.168.25.170
t=0 0
m=audio 10076 RTP/SAVP 9 8 0 98 113 114 101Im VIA - Header als ACK auf den 407 im SIP-Handshake wird die falsche IP verwendet (die lokale statt globale - im initialen Invite wurde noch die korrekte gloable IP verwendet => inkonsistent).
Code:
Via: SIP/2.0/TLS 192.168.25.170:58045;rport;branch=z9hG4bKPjeff8d207-8d6e-442e-8f3a-39c6d96852eb;aliasDie rport-Einstellung hat bei mir im Übrigen nie gezogen - egal was parametrisiert wurde - die Antwort vom VoIP-Provider wurde nie weiter verwendet in den Folge-Requests / Responses (ich habe das auch nicht weiter analysiert - war mir zu blöd. Mein Ziel war und ist immer, dass im SIP und RTP-Protokoll konsistent die für den VoIP-Provider durchgängig korrekten Werte drin stehen, weil das die umfassendste und sicherste und sauberste Methode ist).
Ein weiteres essentielles Thema bei NAT ist, dass die vom NAT-Gateway nach außen verwendeten Ports für die gloable IP nicht zwangsweise die gleichen sein müssen, wie die von Asterisk verwendeten lokalen Ports und daher der von Asterisk im SIP- bzw. RTP-Protokoll hinterlegte Port vom real nach außen verwendeten Port abweichen kann. Das führt beim einen oder anderen VoIP-Provider auch zu Problemen, wenn sie es genauer nehmen (wie die Telekom All-IP z.B.).
Man muss daher darauf achten, dass das NAT-Gateway nicht die Ports verändert, die Asterisk ursprünglich verwendet hat, d.h., dass für die genattete IP der selbe Port verwendet wird wie für die interne IP verwendet wurde, so dass keine Differenzen zwischen SIP- / RTP-Protokoll und Netzwerkstack auftreten. Dies kann man mit einem Linuxrouter wie folgt erzwingen:
- Der Asterisk-Server bekommt eine dedizierte lokale IP, mit der er arbeiten muss, die ansonsten nicht nach außen verwendet wird. Dies stellt sicher, dass Asterisk exklusiv die für ihn vorgesehenen RTP-Ports garantiert immer zur Verfügung hat (weil kein anderes Programm diese IP verwendet und damit Ports "klauen" könnte).
Diese wird im Transport wie folgt definiert (z.B.):
Code:bind=192.168.25.170:0
- Man definiert einen nicht zu großen RTP-Portrange in Asterisk (rtp.conf) - je nachdem, wie viele outbound calls eben parallel nötig sind. Pro outbound call werden 3 Ports benötigt - 2x rtp und 1x rtcp.
Code:rtpstart=11000 rtpend=11030 rtpchecksums=yes strictrtp=yes
- Mit iptables wird nun das NAT wie folgt definiert (bis 11031 wg rtcp!):
Code:rtpportsAsterisk2='11000-11031' wan=[eigene gloable IP] tonlineRTP='217.0.0.0/13' iptables -w -t nat -I POSTROUTE -p udp -s 192.168.25.170 --sport $rtpportsAsterisk -d $tonlineRTP -j SNAT --to-source $wan:$rtpportsAsterisk2
Warum nicht MASQUERADE als Ziel? Weil MASQUERADE das 1:1 Portmapping zumindest hier nicht garantieren wollte. Wichtig ist auch bei SNAT, dass man den zu verwendenden Portbereich für die globale IP erzwingt (--to-source $wan:$rtpportsAsterisk2)! Falls das auch nicht zum Ziel führen sollte, muss man die Regel wirklich dediziert pro Port einstellen:
Code:iptables -w -t nat -I postroute-tkom -p udp -s $natnet --sport $ersterRTPPort -d $tonlineRTP -j SNAT --to-source $wan:$ersterRTPPort iptables -w -t nat -I postroute-tkom -p udp -s $natnet --sport $zweiterRTPPort -d $tonlineRTP -j SNAT --to-source $wan:$zweiterRTPPort ...
Weiterer wichtiger Punkt für das NAT-Gateway: Die "Übersetzung" lokale IP <-> globale IP muss während der ganzen Verbindungszeit offengehalten werden - d.h., das Gateway darf die Verbindung nicht nach geraumer Zeit (timeout) kappen. Dies wird bei der vorgestellten Lösung out of the box erreicht, ohne weitere Einstellungen, da pjsip einen default TLS-Ping (PJSIP_TLS_KEEP_ALIVE_INTERVAL) mitbringt.
Wie funktioniert die genannte Konfiguration nun im Detail?
Das ist auf Basis der oben beschrieben Vorgehensweise jetzt eigentlich ganz einfach: es gibt keine Differenzen zwischen SIP und RTP-Protokoll und dem Netzwerkstack mehr - auch über das NAT-Gateway hinweg. Damit sieht für den VoIP-Provider alles so aus, wie wenn gar kein NAT vorliegen würde - also alles gut.
Die relevanten Patches habe ich angehängt. Wichtig ist, dass für den Patch nobind.diff das gesamte Asterisk / pjsip-Paket zwingend mit dem Compileschalter PJSIP_TLS_TRANSPORT_DONT_CREATE_LISTENER bzw. PJSIP_TCP_TRANSPORT_DONT_CREATE_LISTENER übersetzt werden muss - sonst wird das nichts (ist von pjsip so vorgesehen)! Ich gehe davon aus, dass das pjsip - Bundle verwendet wird (und nicht ein auf dem System vorhandenes pjsip unabhängig von Asterisk verwendet wird).
Erreicht wird dies praktisch, indem man die Umgebungsvariable CFLAGS vor der Konfiguration im Rahmen des Übersetzungsvorgangs bereits mit den entsprechenden Werten belegt - Achtung - sicherstellen, dass man nicht evtl. andere schon vorhandene CFLAGS überschreibt! Ich verwende das Sangoma spec-Paket und habe daher die Definition im spec-File wie folgt angepasst:
Code:
%build
%ifarch x86_64
%define makeflags OPT=-fPIC
%else
%define makeflags OPT=
%endif
echo %{version}%{?_without_optimizations:-debug} > .version
./bootstrap.sh
CFLAGS='-DENABLE_SRTP_AES_256 -DPJSIP_TLS_TRANSPORT_DONT_CREATE_LISTENER -DPJSIP_TCP_TRANSPORT_DONT_CREATE_LISTENER' ./configure --libdir=%{_libdir} --with-jansson-bundled
....Ein weiterer derzeit noch wichtiger Patch. Betrifft die Asterik Versionen 18.4 und 16.18. Sollte dann mit den Folgeversionen gefixt sein.
Zudem - mittlerweile sind Asterisk-Kollegen wohl dazu übergegangen, dass Patches, welche von Personen eingereicht werden, die ihnen nicht vollständig bekannt sind (Name, Adresse, Telefonnummer, ...), einfach wieder entfernt werden. 73433a5.diff war mal in ASTERISK-29241 enthalten und von Florian Floimair eingereicht worden. Aber selber darum kümmern tun sie sich auch nicht. Da gibt es leider eine ganze Menge davon. Irgendwie haben die ein gespanntes Verhältnis zur Community bzw. überhaupt zum Thema Anerkennen von Problemen überhaupt und Fixen in Folge (sie müssen ja nicht die vorgeschlagenen übernehmen, wenn sie bessere haben - dagegen spricht nichts - aber es sollte wenigstens bereinigt werden). Wie es aussieht zu wenig Personal. Daher kommt es zu derartigen dezentralen Patchorgien, was für niemand witzig ist.
Ich hoffe, dass es dem einen oder anderen (bei der Analyse und Lösung) hilft, wenn er im Zusammenhang mit NAT auf Probleme stößt.
Update 22.06.2021: Formatierungsfix, Gatewaytimeout ergänzt, Eindeutigkeit VoIP-Provider gesetzt.
Zuletzt bearbeitet:
