Openstage WL3 regelmäßig unreachable

Johnsonhdw2

Neuer User
Mitglied seit
12 Dez 2010
Beiträge
5
Punkte für Reaktionen
1
Punkte
3
Hallo zusammen,

wir nutzen eine FreePBX zusammen mit mehreren Kabel Snom Telefonen und einem VOIP WLAN Openstage WL3.
Biser hat es auch sehr gut funktioniert nur seit mehreren Tagen haben wir das Problem, dass das WL3 teilweise nicht klingelt, die Snom Telefone schon.

In den Logfiles sieht man dieses Verhalten sehr häufig:

Code:
[2020-07-20 07:52:11] VERBOSE[16885] res_pjsip/pjsip_configuration.c: Endpoint 13 is now Unreachable

[2020-07-20 07:52:11] VERBOSE[16885] res_pjsip/pjsip_options.c: Contact 13/sip:[email protected]:5360 is now Unreachable.  RTT: 0.000 msec

[2020-07-20 07:53:08] VERBOSE[16111] res_pjsip/pjsip_configuration.c: Endpoint 13 is now Reachable

[2020-07-20 07:53:08] VERBOSE[16111] res_pjsip/pjsip_options.c: Contact 13/sip:[email protected]:5360 is now Reachable.  RTT: 137.176 msec


[2020-07-20 08:02:11] VERBOSE[21498] res_pjsip/pjsip_configuration.c: Endpoint 13 is now Unreachable

[2020-07-20 08:02:11] VERBOSE[21498] res_pjsip/pjsip_options.c: Contact 13/sip:[email protected]:5360 is now Unreachable.  RTT: 0.000 msec

[2020-07-20 08:04:08] VERBOSE[4984] res_pjsip/pjsip_configuration.c: Endpoint 13 is now Reachable

[2020-07-20 08:04:08] VERBOSE[4984] res_pjsip/pjsip_options.c: Contact 13/sip:[email protected]:5360 is now Reachable.  RTT: 198.286 msec


[2020-07-20 08:28:11] VERBOSE[16111] res_pjsip/pjsip_configuration.c: Endpoint 13 is now Unreachable

[2020-07-20 08:28:11] VERBOSE[16111] res_pjsip/pjsip_options.c: Contact 13/sip:[email protected]:5360 is now Unreachable.  RTT: 0.000 msec

[2020-07-20 08:29:08] VERBOSE[16885] res_pjsip/pjsip_configuration.c: Endpoint 13 is now Reachable

[2020-07-20 08:29:08] VERBOSE[16885] res_pjsip/pjsip_options.c: Contact 13/sip:[email protected]:5360 is now Reachable.  RTT: 148.736 msec




[2020-07-22 11:57:45] VERBOSE[13656] res_pjsip/pjsip_configuration.c: Endpoint 13 is now Unreachable

[2020-07-22 11:57:45] VERBOSE[13656] res_pjsip/pjsip_options.c: Contact 13/sip:[email protected]:5360 is now Unreachable.  RTT: 0.000 msec

[2020-07-22 11:58:42] VERBOSE[16885] res_pjsip/pjsip_configuration.c: Endpoint 13 is now Reachable

[2020-07-22 11:58:42] VERBOSE[16885] res_pjsip/pjsip_options.c: Contact 13/sip:[email protected]:5360 is now Reachable.  RTT: 113.681 msec



[2020-07-22 12:43:45] VERBOSE[21498] res_pjsip/pjsip_configuration.c: Endpoint 13 is now Unreachable

[2020-07-22 12:43:45] VERBOSE[21498] res_pjsip/pjsip_options.c: Contact 13/sip:[email protected]:5360 is now Unreachable.  RTT: 0.000 msec

[2020-07-22 12:44:42] VERBOSE[16111] res_pjsip/pjsip_configuration.c: Endpoint 13 is now Reachable

[2020-07-22 12:44:42] VERBOSE[16111] res_pjsip/pjsip_options.c: Contact 13/sip:[email protected]:5360 is now Reachable.  RTT: 301.598 msec


[2020-07-22 16:08:45] VERBOSE[21498] res_pjsip/pjsip_configuration.c: Endpoint 13 is now Unreachable

[2020-07-22 16:08:45] VERBOSE[21498] res_pjsip/pjsip_options.c: Contact 13/sip:[email protected]:5360 is now Unreachable.  RTT: 0.000 msec

[2020-07-22 16:09:42] VERBOSE[13656] res_pjsip/pjsip_configuration.c: Endpoint 13 is now Reachable

IDNUM=13072 16:09:42] VERBOSE[13656] res_pjsip/pjsip_options.c: Contact 13/sip:[email protected]:5360 is now Reachable.  RTT: 259.485 msec



[2020-07-22 16:10:45] VERBOSE[16885] res_pjsip/pjsip_configuration.c: Endpoint 13 is now Unreachable

[2020-07-22 16:10:45] VERBOSE[16885] res_pjsip/pjsip_options.c: Contact 13/sip:[email protected]:5360 is now Unreachable.  RTT: 0.000 msec

[2020-07-22 16:11:42] VERBOSE[16111] res_pjsip/pjsip_configuration.c: Endpoint 13 is now Reachable

[2020-07-22 16:11:42] VERBOSE[16111] res_pjsip/pjsip_options.c: Contact 13/sip:[email protected]:5360 is now Reachable.  RTT: 181.126 msec


Auffällig ist, dass es innerhalb des Tages immer zur selben Sekunde "unreachable" und zur selben Sekunde wieder "reachable" ist.
SIP Register Expiration ist am WL3 auf 600 Sekunden eingestellt, UAPSD sowohl am WL3 als auch an den Unifi APs deaktiviert.

Habt ihr eine Idee woran es liegen könnte?
Besten Dank vorab für Hilfe :)
 
Schau dir mal das Log vom WL3 selbst an. Da sieht man wohl eher, warum es sich de-registert. Ansonsten würde ein Wireshark Trace (am Asterisk Server tshark -R "sip") das Geheimnis sicher lüften.
 
Danke für Deine Antwort.

Was ich noch erwähnen muss: Das VOIP Telefon befindet sich in einem anderen VLAN, also anderers Subnetz/IP-Adressbereich und es wird alles lokal über eine pfSense geroutet.

Ich habe nun sowohl am Asterisk als auch am Gatway ein Packet Capture gemacht und es zeigt sich an beiden Punkten folgendes Verhalten:

freepbx-unreachable.JPG

Log von der PBX zu dieser Zeit:

Code:
[2020-07-28 11:52:45] VERBOSE[16885] res_pjsip/pjsip_configuration.c: Endpoint 13 is now Unreachable
[2020-07-28 11:52:45] VERBOSE[16885] res_pjsip/pjsip_options.c: Contact 13/sip:[email protected]:5360 is now Unreachable.  RTT: 0.000 msecontext 'from-internal' or has no associated hint
[2020-07-28 11:53:42] VERBOSE[16885] res_pjsip/pjsip_configuration.c: Endpoint 13 is now Reachable
[2020-07-28 11:53:42] VERBOSE[16885] res_pjsip/pjsip_options.c: Contact 13/sip:[email protected]:5360 is now Reachable.  RTT: 190.227 msec

10.0.130.250 ist die PBX und 192.168.2.46 das VOIP Telefon. Die PBX fragt also öfter beim Telefon an, bekommt aber keine Rückantwort und meldet in den Logs dann "unreachable".
Das Telefon schickt nach wenigen Sekunden ein "200 OK", dieses erste OK wird aber von der PBX ignoriert und erst auf das zweite OK nach über einer Minute wird reagiert.
Wenn in dieser Zeit jemand anruft, klingelt das Telefon nicht.

Das komische ist, dass es vor einigen Wochen problemlos funktioniert hat, und auch kein Update auf dem Router gemacht wurde.
Das Log am WL3 kann ich erst morgen inspizieren.
 
Ich würde an Deiner Stelle auch noch prüfen, welches OK zu welchem OPTIONS gehört: Header CSeq. Nicht dass die zeitliche Reihenfolge nicht zur logischen Abfolge passt. Und: Was genau passiert mit den INVITE, wenn jemand anruft aber das Telefon nicht klingelt.

Aber ganz anders gefragt (abgesehen davon, warum man in einem 10er-Netz ein 192er-Subnetz aufspannt) und vielleicht Off-Topic: Wie hoch sind die NAT-Session-Timeouts für UDP in Deiner pfSense? Wenn Du die höher als das Expiry des SIP-REGISTER machen würdest, dann bräuchtest Du die SIP-OPTIONS gar nicht; also in der Datei pjsip.conf den Parameter qualify_frequency weglassen (oder auf Null setzen). So vergeudest Du wahnsinnig viel Strom und damit Akku. Ich nutze hier mit meinem Telefon (ebenfalls Openstage WL3) und meiner Telefonanlage (Digium Asterisk 13, chan_sip) sogar SIP-over-TLS, also statt UDP mache ich TCP. Dadurch muss ich die SIP-Verbindung über mein NAT hinweg gar nicht weiter am Leben erhalten.
 
Danke für die schnelle, nette und ausführliche Antwort!
Das erste OK gehört zu den ersten OPTIONS und das zweite zu dem direkt davor, passt also sowohl zeitlich als auch logisch, nur dass das erste OK nicht bei der PBX ankommt.

Das mit den Netzen dort ist historisch gewachsen, sind aber alles nur /24er Netze, das ist also kein Problem.
Ich habe jetzt nachgesehen: die PFsense steht in den Advanced NAT Einstellungen auf "conservative" was folgende NAT-Session-Timeouts zur Folge hat:

Code:
tcp.first                  3600s
tcp.opening                 900s
tcp.established          432000s
tcp.closing                3600s
tcp.finwait                 600s
tcp.closed                  180s
tcp.tsdiff                   60s
udp.first                   300s
udp.single                  150s
udp.multiple                900s
icmp.first                   20s
icmp.error                   10s
other.first                  60s
other.single                 30s
other.multiple               60s
frag                         30s
interval                     10s

In unserer FreePBX steht die "SIP qualifyfreq" unter Settings --> Advanced Settings --> Device Settings auf 60s.

Ich bin mir jetzt nur unsicher was im am besten umstelle und beobachte um das ganze besser verstehen zu können.
 
Idealerweise löst Du dieses Subnetz und damit das NAT auf. Du kannst in einem 10er- (oder 172er-) Netz wunderbar alles in ein Netz packen und direkt ohne NAT separieren. NAT bzw. Firewall ist für VoIP/SIP einfach nur Gift. Für WLAN-Telefone kostet das auch noch Akku, also tatsächlich richtig Geld.

Aber ja, bevor Du etwas umstellt, erstmal mal schauen was das OpenStage WL3 versendet/empfängt. Das einfachste wäre ein Switch mit Port-Mirroring direkt hinter dem WLAN-Access-Point. Dann kannst Du live und relative unverfälscht mitlesen.

Klingt irgendwie als hättest Du einen Software-Bug in Digium Asterisk gefunden, also dass das OK nicht mehr dem OPTIONS zugeordnet wird. Aber die Frage bleibt im Raum, warum so viele OPTIONS überhaupt verloren gehen … das solltest Du herausbekommen.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,827
Beiträge
2,219,005
Mitglieder
371,520
Neuestes Mitglied
fredl_2
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

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.