Wenn Du ausschließlich chan_pjsip verwenden willst, dann erhältst Du genau einen offnen Port. Du machst einfach ein noload auf chan_sip. Aber soweit ich sehe, möchtest Du chan_sip weiterverwenden. Und in dem Fall muss ich Dir leider sagen, dass auch ich es nicht hinbekommen habe. Wenn chan_sip läuft (und man ICE oder DTLS haben möchte), dann muss res_pjsip laufen. Und wenn res_pjsip lief, dann hat es Ports aufgemacht, obwohl ich chan_pjsip nicht geladen hatte. Meine Lösung ist, in pjsip.conf den Port zu verbiegen. In Deinem Fall würdest Du also sowohl in pjsip.conf als auch sip.conf den Port verbiegen.
Wenn Du die Ursache dafür unbedingt finden willst – und ich vermute dass das kein Konfigurationsfehler Deinerseits sondern ein Softwarefehler in Asterisk ist – dann wäre mein Vorschlag den Quellcode mit Hilfe eines Debuggers wie
gdb durchzusteppen. Also die Stelle(n) finden, an denen die UDP-Ports im Quellcode aufgemacht werden und dort einen Breakpoint setzen. Mittels
backtrace schaust Du dann, wer die Port-Öffnung auslöst. Wenn Du diesen Weg gehen willst und Fragen hast, einfach fragen. Dann schaue ich mal parallel bei meiner Installation mit.
Thread oder Prozeß? Wenn es ein zweiter Prozeß ist, dann hast Du zwei Asterisk im System installiert. In dem Fall können wir kaum helfen. Ich vermute eher, dass es ein zweiter Thread innerhalb Deines Asterisk ist und Du entweder die Thread-ID oder die File-ID (des Deskriptors für den UDP-Port) siehst. Welches Tool ist das genau: Ein
netstat -tulpen direkt aus Debian 10 Repository?
Ihr hättet lieber diese zwei unterschiedlichen Sachen zur Diskussion nicht zusammen packen sollen.
Einfach ignorieren, wenn Sie Dich nicht interessieren. Wenn Du uns allerdings zeigst, dass Du es immer noch nicht verstanden hast, „müssen“ wir nachhaken. Zwar ist das hier Dein Thread. Aber in Zukunft kommen auch passive Leser vorbei. Und für Jene können wir irgendwelche obskuren Gründe für eine Port-Verdrehung und die nicht-Benutzung von
fail2ban nicht einfach so stehen lassen.
