[Problem] Asterisk und Fonial, nur kurzzeitige Verbindung

franky69

Neuer User
Mitglied seit
20 Aug 2008
Beiträge
20
Punkte für Reaktionen
0
Punkte
1
Hallo,

ich habe einen Asterisk Server (Asterisk 16.28.0) auf einem Debian GNU/Linux 10 (buster) am Laufen. Ich habe mehrere SipGate Konten eingerichtet. Da gibt es keine Probleme.

Jetzt habe ich auch ein Fonial eingerichtet, wo der Asterisk Server als Ziel eingerichtet ist. Die Verbindung funktioniert auch. Aber leider immer nur sehr kurz. Wenn ich für den Asterisk Service ein Reload mache, wird in Fonial der Asterisk Server kurz online angezeigt, aber geht dann wieder offline. In Asterisk, wird die ganze Zeit angezeigt, dass die peers alle online sind.

Der Asterisk Server hat eine ganz einfache Standard-Konfiguration. Kann mir jemand einen Tip geben woran es liegen könnte? Wie gesagt, mit Sipgate funktioniert es.

Ich habe die Einrichtung für fonial wie in deren Tutorial eingerichtet:
https://www.fonial.de/hilfe/trunking/konfiguration-der-telefonanlagen/asterisk

VG Frank
 
Hallo Frank,

zunächst ein Hinweis: Fonial beschreibt die Konfiguration hier mittels chan_sip. Dieser Treiber ist abgekündigt und sollte schon aus Asterisk entfernt worden sein. Aktuell wird es mit der nächsten Version 21 entfernt werden:

Insofern würde sich ein Umstieg auf pjsip schon lohnen.

Aber so viel zum Vorgeplänkel, nun zu dem akuten Problem:

Der Klassiker bei auslaufenden Registrierungen sind NAT- bzw. Firewall-Probleme.
Dazu wäre es hilfreich, du beschreibst kurz, was an Systemen zwischen dem Asterisk und dem Router sitzt und was du als Router einsetzt.

Als allerersten Schritt kannst du dir mal die SIP-Pakete auf der Konsole anschauen (sip set debug on), und was mit den qualify-Paketen dann passiert.
Der nächste Schritt wäre dann, auf dem WAN-Interface deines Routers zu tracen, das würde helfen, herauszufinden, ob ggf. die Firewall des Routers Pakete verwirft.

... und theroetisch könntest du auch einfach mal beim Support von Fonial nachfragen, die sollten ja auch Logging haben und dir sagen können, wie sich dein Asterisk aus deren Sicht verhält.
 
Hallo Sunnymann,
danke für die Infos. Das mit dem chan_sip hatte ich gelesen und schon überlegt, ob es daran liegen könnte. Ich hoffe nicht. Der Server liegt auf einem Dedicated Server, auf dem läuft Debian und Asterisk läuft dort auf einer virtuellen Maschine. Das hat ein Kollege damals eingerichtet. Deswegen bin ich da nicht so ganz im Thema drinnen.

Bei Fonial hatte ich gestern Morgen nachgefragt und warte noch auf eine Antwort.

Ich weiß jetzt leider gar nicht, was ich von dem Log am besten poste. Durch sip set debug on ist das sehr lang und da sind sehr viele Sipgate Anschlüsse konfiguriert. Ich stelle gerne mehr Infos bereit.
Code:
<--- SIP read from UDP:92.197.182.19:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.122.30:5060;branch=z9hG4bK0e395fbb;rport=5060;received=85.25.xxx.xxx
From: "asterisk" <sip:[email protected]>;tag=as72b27f88
To: <sip:sip.plusnet.de>;tag=atB7NpBHQyBcg
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
Contact: <sip:92.197.182.19>
User-Agent: FreeSWITCH-mod_sofia/1.10.7-release+git~20220701T135949Z~43de83d994~64bit
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Length: 0

...

---
[Nov 23 10:53:19] VERBOSE[24290] chan_sip.c: 
<--- SIP read from UDP:92.197.176.19:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.122.30:5060;branch=z9hG4bK5012129d;rport=5060;received=85.25.xxx.xxx
From: <sip:[email protected]>;tag=as51d12592
To: <sip:[email protected]>;tag=KQX081rX1r1je
Call-ID: [email protected]
CSeq: 104 REGISTER
User-Agent: FreeSWITCH-mod_sofia/1.10.7-release+git~20220701T135949Z~43de83d994~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
WWW-Authenticate: Digest realm="sip.plusnet.de", nonce="c81cd7ff-3274-455b-a4a8-f2cfd9b0d6eb", stale=true, algorithm=MD5, qop="auth"
Content-Length: 0

<------------->
[Nov 23 10:53:19] VERBOSE[24290] chan_sip.c: --- (11 headers 0 lines) ---
[Nov 23 10:53:19] VERBOSE[24290] chan_sip.c: Responding to challenge, registration to domain/host name sip.plusnet.de
[Nov 23 10:53:19] VERBOSE[24290] chan_sip.c: REGISTER 12 headers, 0 lines
[Nov 23 10:53:19] VERBOSE[24290] chan_sip.c: Reliably Transmitting (NAT) to 92.197.176.19:5060:
REGISTER sip:sip.plusnet.de SIP/2.0
Via: SIP/2.0/UDP 192.168.122.30:5060;branch=z9hG4bK234d0ff7;rport
Max-Forwards: 70
From: <sip:[email protected]>;tag=as51d12592
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 105 REGISTER
Supported: replaces, timer
User-Agent: Asterisk PBX 16.28.0~dfsg-0+deb10u1
Authorization: Digest username="fo34XX96ipXX5800_00", realm="sip.plusnet.de", algorithm=MD5, uri="sip:sip.plusnet.de", nonce="c81cd7ff-3274-455b-a4a8-f2cfd9b0d6eb", response="a547ad522b349b033b7c8035a8b9ab65", qop=auth, cnonce="18698ee6", nc=00000001
Expires: 120
Contact: <sip:[email protected]:5060>
Content-Length: 0


---
[Nov 23 10:53:19] VERBOSE[24290] chan_sip.c: 
<--- SIP read from UDP:92.197.176.19:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.122.30:5060;branch=z9hG4bK5012129d;rport=5060;received=85.25.xxx.xxx
From: <sip:[email protected]>;tag=as51d12592
To: <sip:[email protected]>;tag=KQX081rX1r1je
Call-ID: [email protected]
CSeq: 104 REGISTER
User-Agent: FreeSWITCH-mod_sofia/1.10.7-release+git~20220701T135949Z~43de83d994~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
WWW-Authenticate: Digest realm="sip.plusnet.de", nonce="c81cd7ff-3274-455b-a4a8-f2cfd9b0d6eb", stale=true, algorithm=MD5, qop="auth"
Content-Length: 0

...

<------------->
[Nov 23 10:53:20] VERBOSE[24290] chan_sip.c: --- (8 headers 0 lines) ---
[Nov 23 10:53:20] NOTICE[24290] chan_sip.c: Outbound Registration: Expiry for sipgate.de is 120 sec (Scheduling reregistration in 105 s)
[Nov 23 10:53:20] VERBOSE[24290] chan_sip.c: Really destroying SIP dialog '[email protected]' Method: REGISTER
[Nov 23 10:53:20] VERBOSE[24290] chan_sip.c: 
<--- SIP read from UDP:92.197.176.19:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.122.30:5060;branch=z9hG4bK234d0ff7;rport=5060;received=85.25.xxx.xxx
From: <sip:[email protected]>;tag=as51d12592
To: <sip:[email protected]>;tag=8QBNrZBtFBgyS
Call-ID: [email protected]
CSeq: 105 REGISTER
Contact: <sip:[email protected]:5060>;expires=2060
Date: Wed, 23 Nov 2022 09:53:20 GMT
User-Agent: FreeSWITCH-mod_sofia/1.10.7-release+git~20220701T135949Z~43de83d994~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Content-Length: 0

<------------->
[Nov 23 10:53:20] VERBOSE[24290] chan_sip.c: --- (12 headers 0 lines) ---
[Nov 23 10:53:20] NOTICE[24290] chan_sip.c: Outbound Registration: Expiry for sip.plusnet.de is 2060 sec (Scheduling reregistration in 2045 s)
[Nov 23 10:53:20] VERBOSE[24290] chan_sip.c: Really destroying SIP dialog '[email protected]' Method: REGISTER

Hat das was vielleicht was damit zu tun, dass die IP von fonial sich ändern?

<--- SIP read from UDP:92.197.182.19:5060 --->
SIP/2.0 200 OK

<--- SIP read from UDP:92.197.176.19:5060 --->
SIP/2.0 401 Unauthorized
 
Ich bin gerade mal das hier durchgegangen, Punkt 11:

Wenn die unterschiedlichen Server nicht auf dieselben Registrierungsinformationen zugreifen können, wird's mit Asterisk (PJSIP) schwierig.
Asterisk kann zwar DNS SRV, schickt die OPTIONS-Pakete für das qualify aber *immer* an den ersten Eintrag aus der Liste:


chan_sip muss grundsätzlich nicht das Problem sein, aber es könnte die Lösung sein. "Dedicated Server" heißt, wir reden von einer Maschine in einem Rechenzentrum? Hast du vielleicht mehrere IPv4-Adressen und könntest dem Asterisk eine geben? Dann könntest du dir NAT-Probleme komplett sparen.

NAT/Firewall-Themen hast du ja nunmal. Das Asterisk hat eine RFC1918-IP-Adresse, das bedeutet dass es irgendwo noch einen Router geben muss, der zwischen dem Internet und dem Asterisk ist -- und wenn das in Software auf dem Hostsystem stattfindet.

Wichtig ist, dass du mal verfolgst, was im zeitlichen Verlauf passiert. Die letzte SIP-Nachricht in deinem Log ist ja ein OK als Antwort auf dein Register. Also grundsätzlich scheint die Authentifizierung zu klappen.

Interessant ist, wann wer OPTIONS-Nachrichten schickt und wie die Reaktion darauf ausfällt.

Wenn das reine loggen im CLI zu schwierig ist, wirst du wohl einen richtigen Trace (PCAP) schreiben müssen und den dann mit Analysewerkzeugen wie Wireshark, sngrep anschauen.
 
In Verwendung mit chan_pjsip wird in der extensions.conf folgendes benötigt:

Code:
[context]
exten => s,1,Answer()

Wenn der Anbieter nur einen Domainnamen ohne Benutzerteil sendet, solltest du die Extension s verwenden. Der Benutzerteil wird normalerweise für spezifische Erweiterungen verwendet, und „s“ ist eine Standarderweiterung für allgemeine, nicht benutzerbezogene Anfragen.

_X. oder _+X. sind also bei Fonial nicht möglich! In diesem Szenario bestand bei mir das gleiche Problem, dass die Verbindung nur kurzzeitig funktionierte. Asterisk zeigte über pjsip show registrations zwar ein "registered" an, aber Fonial zeigte die Extension im Kundenportal als offline an.

Ich hätte an dieser Stelle eine Frage, da es wenige Themen zu Fonial in diesem Forum gibt. Ich hoffe es ist in Ordnung diese Frage hier anzuhängen. Fonial sendet ein Freizeichen, bevor der Anruf in Asterisk "reinkommt" Das klingt ein bisschen ungeschickt, wenn Asterisk ein Busy senden soll oder wenn eine MOH abgespielt werden soll. Nun stelle ich mir die Frage: Liegt das an Asterisk und muss konfiguriert werden oder liegt das an Fonial ist nicht daher nicht zu lösen?
 
Zuletzt bearbeitet:
_X. oder _+X. sind also bei Fonial nicht möglich!
Wenn man das habe möchte und Fonial tatsächlich im SIP TO nichts stehen haben sollte, wird es vermutlich in anderen Headern stehen (sonst gäbe es kein Unterscheidungsmerkmal, für welche Rufnummer der Ruf kommt), dann kann man es zur not von dort auslesen und die Extension per Hand setzen.
In diesem Szenario bestand bei mir das gleiche Problem, dass die Verbindung nur kurzzeitig funktionierte. Asterisk zeigte über pjsip show registrations zwar ein "registered" an, aber Fonial zeigte die Extension im Kundenportal als offline an.
Das kann vielleicht so gewirkt haben, aber Fonial hat keine Möglichkeit, deine Extensions.conf zu lesen :)
Über "registered" oder nicht entscheidet rein, ob die Registrierung sauber läuft, und nicht, wie dein Asterisk bei ankommenden Anrufen *reagiert*.
Ich hätte an dieser Stelle eine Frage, da es wenige Themen zu Fonial in diesem Forum gibt. Ich hoffe es ist in Ordnung diese Frage hier anzuhängen. Fonial sendet ein Freizeichen, bevor der Anruf in Asterisk "reinkommt" Das klingt ein bisschen ungeschickt, wenn Asterisk ein Busy senden soll oder wenn eine MOH abgespielt werden soll. Nun stelle ich mir die Frage: Liegt das an Asterisk und muss konfiguriert werden oder liegt das an Fonial ist nicht daher nicht zu lösen?
Da gehen jetzt aber mehrere Sachen durcheinander.
Welche exten Asterisk "wählt" bei ankommenden Anrufen, lässt sich in PJSIP konfigurieren über die endpoint identification. Zusätzlich kann man hier über "line=yes" auch ermöglichen, dass PJSIP mehrere Registrierungen beim gleichen Provider handeln kann.
Dass der Provider den Freiton einspielt, ist gängige Praxis.
Was vermieden werden sollte, ist ein explizites Answer(), denn das führt dazu, dass der Ruf sofort und bedingungslos angenommen wird und dem Anrufer das auch so signalisiert wird.
Dass der Provider einen Freiton einspielt, bevor Asterisk ein Trying, Ringing, o.ä. geschickt hat, wäre ziemlich unüblich.
Wenn du das mit dem Answer gemacht hast, um ein anderes Problem zu lösen, hast du damit vermutlich nur das Symptom überdeckt. Fehlende/Kaputte Freitöne können auch auf NAT-Probleme deuten.
Ansonsten hilft auch hier, zu tracen bzw. es mit unterschiedlichen Geräten aus unterschiedlichen Netzen zu probieren, um das Problem einzugrenzen.
 
Es ist schon immer so konfiguriert, wie du sagst und dennoch ist der Freiton zu hören.
Jacolp sagt, dass ich mich an den Anbieter wenden soll, wenn ein Freiton ertönt, bevor der Anruf in Asterisk eintrifft.
Wenn du die Context-Variable in pjsip.conf im Abschnitt "entpoint" meinst, dann ist dort festgelegt, wo der Anruf hin soll und trotzdem fliegt die Registrierung beim Anbieter aus, wenn ich _X. oder _+X. verwende. Das einzige was funktioniert ist "s"
Ich muss erreichbar sein, was der Hintergrund für den Unterschied ist, interessiert mich und andere Betroffene denke ich weniger.

Nach deiner Aussage sollte _X. auch funktionieren? Dann würde ich gern mal eine pjsip.conf sehen in der das funktionieren soll ohne ständige Verbindungsabbrüche zum Trunk.
 
Kostenlos!

Statistik des Forums

Themen
247,015
Beiträge
2,260,725
Mitglieder
375,279
Neuestes Mitglied
sperl42