Probleme mit Authorization und ParseExeptions

[rtplru]

Hallo

Wir benutzen neu 3CX, da unser bisheriger Anbieter von 3CX übernommen wurde. Wir haben das System erstmals am letzten Freitag aufgeschaltet und erfolgreich getestet. Am Wochenende ging plötzlich nichts mehr. Nach einer Neuinstallation gestern ging wieder alles korrekt, bis heute der Strom ausfiel und die Anlage neu startete. Nun haben wir wieder dasselbe Problem wie am Wochenende:
- Die Anlage läuft und zeigt alles 'grün' an: Die Trunks und die Telefone bzw. Nebenstellen sind registriert
- Anrufe von extern werden registriert, können aber nicht auf eine Nebenstelle durchgestellt werden.
- Interne Anrufe funktionieren ebenfalls nicht mehr.

Im Aktivitäten-Log finden wir lauter solche Einträge:

--------------------------------------------------------------------------------
06.12.2017 14:17:22 - Exception: ParseException ../../rutil/ParseBuffer.hxx:230, Parse failed unexpected eof in context:
5031
^
@ ../../rutil/ParseBuffer.hxx:230
--------------------------------------------------------------------------------
06.12.2017 14:17:18 - Exception: ParseException ../../rutil/ParseBuffer.hxx:230, Parse failed unexpected eof in context:
5021
^
@ ../../rutil/ParseBuffer.hxx:230
--------------------------------------------------------------------------------
06.12.2017 14:17:09 - [CM302001]: Authorization system can not identify source of: UnkSrc Recv Req SUBSCRIBE from 192.168.1.156:5060 tid=d711e8bdb398c009b Call-ID=66226ccaa55b743e:
SUBSCRIBE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.156:5060;branch=z9hG4bKd711e8bdb398c009b
Max-Forwards: 70
Contact: "SHA"<sip:[email protected]:5060>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D35D060>"
To: <sip:[email protected]:5060>
From: "SHA" <sip:[email protected]:5060>;tag=229a9f61bc
Call-ID: 66226ccaa55b743e
CSeq: 22977 SUBSCRIBE
Expires: 3592
Accept: application/dialog-info+xml
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO
Supported: path, gruu
User-Agent: Aastra 57i/3.3.1.4305
Event: dialog
Allow-Events: aastra-xml, talk, hold, conference, LocalModeStatus
Content-Length: 0
--------------------------------------------------------------------------------

Ein Restart aller Komponenten hilft auch nichts mehr.

Wir haben keine Ahnung, wo das Problem liegen könnte. Wir benutzen eine 3CX Professional, v15.5.0.

Kann uns da jemand helfen?

Danke.

 

[rtplru]

Wir konnten unterdessen das Problem mit den internen Calls lösen: Es lag daran, dass die Voip-Clients auf die IP-Adresse der PBX zugriffen und dies offenbar nicht erlaubt war.

Was weiterhin nicht geht, sind eingehende Anrufe von externen Nummern.

Interessanterweise funktioniert es nach dem Wiederherstellen eines Backups jeweils bis zum Reboot der PBX.

Hat jemand eine Idee, was das sein könnte?

 

[ilias_3CX]

Hallo rtplru,

hierfür konnte Ihnen ein Wireshark pcap von einen betroffenen Anruf weiterbringen. Nur dort können Sie sehen, wo der Fehler liegt und wieso die Anrufe nicht ankommen.

Gruß
Ilias

 

[rtplru]

Hallo 3cxilias

Danke für die Info. Wir sind mit der Auswertung von Wireshark-Protokollen nicht sehr vertraut. Wir werden das anschauen und bei Erfolg die Lösung hier publizieren.

 

[ilias_3CX]

Ok Super,

Kann ich aber kurz erfahren, ob du auch eine Fehlermeldung hierfür bekommst?
Werden die Anrufe eventuell nicht richtig geroutet? Was für ein Provider wird hier verwendet?

Gruß
ilias

 

[rtplru]

Hallo Ilias

Ich verstehe die Fehlermeldungen nicht wirklich, aber ja, ich vermute, es ist ein Routing-Problem.

Hier ein Auszug aus der SystemServiceLog:
-----
2017/12/18 20:44:23.699|592|0007|Trac|[CHR] Adding event: 2017-12-18 20:44:23.635|IncomingCall|000001606B27E04E_1|08ce645b8f2a/Participant DN.10000/Line dn-name='' epname='079@(Ln.10000@iWay SIP Trunk)'
>08ce645b8f2a/Participant DN.10000/Line dn-name='' epname='079@(Ln.10000@iWay SIP Trunk)'
disp_name=
number=079
sip.contact=<sip:[email protected]:5060>
sip.from=<sip:[email protected]>;tag=sc2nxp1-80c40af76fd56dcd
sip.rl_uri=sip:[email protected]:35325;rinstance=ad8b2ed9f66e728d
sip.src_addr=212.25.x.yy:5060
sip.to=<sip:[email protected]>
sip.user_ag=AareSwitch/6.4.10447
target=5011

2017/12/18 20:44:23.710|592|0007|Trac|[CHR] Adding event: 2017-12-18 20:44:23.647|TargetFailed|000001606B27E04E_1|8e39ac4c7e06/Target [TargetNotFound]
>8e39ac4c7e06/Target [TargetNotFound]

2017/12/18 20:44:23.710|592|0007|Trac|[CHR] Adding event: 2017-12-18 20:44:23.681|PartyRemoved|000001606B27E04E_1|08ce645b8f2a/None
>08ce645b8f2a/None

2017/12/18 20:44:23.710|592|0007|Trac|[CHR] Adding event: 2017-12-18 20:44:23.681|Disconnected|000001606B27E04E_1|Party.???
>Party.???
replaced_by.chid=
------


Was mich aber irritiert, sind die Einträge in der ManagementLogConsole:

-------
2017/12/18 20:44:23.659|591|0007|Trc|EventConnector.Root_Inserted(CONNECTION ActiveConnection:
CallID=1
DN=iWay SIP Trunk
InternalParty=iWay SIP Trunk
ExternalParty=079667xxyy
inbound/outbound=False/True
time=12/18/17 7:44:23 PM
Status=Dialing
RefferedBy=0
OriginatedBy=None
AttachedData:
sip_displayname=
lookup_displayname=
inbound_did=044440xxyy
inbound_did_rule=
chid=000001606B27E04E_1
prevCall=0
prevLeg=0
extnumber=079667xxyy
devcontact=sip:[email protected]:5060
)
2017/12/18 20:44:23.660|591|0007|Trc|EventConnector.EventRoutePoint.OnEvent(Inserted CONNECTION:ActiveConnection:
CallID=1
DN=iWay SIP Trunk
InternalParty=iWay SIP Trunk
ExternalParty=079667xxyy
inbound/outbound=False/True
time=12/18/17 7:44:23 PM
Status=Dialing
RefferedBy=0
OriginatedBy=None
AttachedData:
sip_displayname=
lookup_displayname=
inbound_did=044440xxyy
inbound_did_rule=
chid=000001606B27E04E_1
prevCall=0
prevLeg=0
extnumber=079667xxyy
devcontact=sip:[email protected]:5060
)
2017/12/18 20:44:23.660|591|0007|Trc|PipelineTransformer.OnEvent(Inserted CONNECTION:ActiveConnection:
CallID=1
DN=iWay SIP Trunk
InternalParty=iWay SIP Trunk
ExternalParty=079667xxyy
inbound/outbound=False/True
time=12/18/17 7:44:23 PM
Status=Dialing
RefferedBy=0
OriginatedBy=None
AttachedData:
sip_displayname=
lookup_displayname=
inbound_did=044440xxyy
inbound_did_rule=
chid=000001606B27E04E_1
prevCall=0
prevLeg=0
extnumber=079667xxyy
devcontact=sip:[email protected]:5060
)


------

Da steht überall, dass das ein Outbound-Call ist, wenn ich das richtig interpretiere, das waren aber Inbound-Calls.

Irgendwie scheint bei einem Reboot da was Kaputt zu gehen.

Wir verwenden iWay als Provider, der leider nicht offiziell unterstützt ist. Grundsätzlich geht es ja auch, bis die PBX neu startet.

Danke und Gruss
Lukas.

 

[ilias_3CX]

Sind die Durchwahlen auch als DIDs angelegt?

Kannst du mir bitte schreiben wie du deine DIDs eingerichtet hast? Wurden die mit *12345 (* und die letzte 5 Ziffern der Rufnummer) eingetragen?

 

[rtplru]

Hallo Ilias
Nein, ich habe die DIDs als komplette Rufnummern eingetragen. Ist das wohl der Fehler?
Da wir zwei Nummernblöcke haben, die sich nur vorne unterscheiden, müssten wir jedoch mehr als 5 Ziffern der Rufnummern definieren (mindestens 6).
Könnten wir das dann so definieren: *1234567 ?
Danke und Gruss

 

[ilias_3CX]

Ja dann wäre es besser so einzutragen, wie du es geschrieben hast.

Das könnte auch das Problem beheben. Wenn die Rufnummer die der Provider an der PBX sendet nicht exakt mit den DIDs gemappt wird wird die nicht korrekt geroutet. Dazu wenn der Provider kein rinstance mitsendet, dann wird der Anruf nicht an die Zentale Nummer weitergeleitet.

Gruß
Ilias

 

[rtplru]

Leider löst das das Problem auch nicht. Es besteht nachwievor das Problem, dass nach einem Restore alles funktioniert, bis die PBX einmal gebootet hat.

 

[ilias_3CX]

Hmmm. Komisches verhalten.

Wenn du die Möglichkeit hast, wäre es Hilfreicher wenn du ein Ticket an den Support öffnest.
Dort Sendest du die Support Daten der Anlage und Wireshark pcap. So kann man das verhalten besser Analysieren.

Gruß
Ilias

 

[rtplru]

Ja, ein Supportticket würde ich sofort eröffnen. Aber laut den Bedingungen von 3CX werden Kunden, die einen nicht supporteten SIP-Trunk-Anbieter verwenden, nicht supported... Da wären die ca. €500 natürlich zum Fenster hinausgeschmissen.

 

[ilias_3CX]

Hi rtplru,

Ja tatsächlich wird der Provider denn du verwendust von der 3CX nicht unterstützt.
Vielleicht liegt das Problem in diesem Fall aber nicht an dem Provider, sondern am PC, Netzwerk, Firewall etc.

Gruß
Ilias

 

[rtplru]

Es muss an der 3CX liegen. Sonst würde es ja nicht nach einem Restore des Backups funktionieren bis zu einem Reboot...

Ich kann es offen sagen: Wir sind nicht freiwillig 3CX-Kunde geworden, sondern weil Askozia von 3CX aufgekauft wurde. Eine derart eingeschränkte Supportpolicy kennt man nur von solch proprietären Softwareherstellern mit klassischem Reseller-System. Da fallen wir nun komplett durch, weil wir die Software nicht über einen Reseller gekauft haben und nun nicht einmal kostenpflichtigen Support einkaufen können... Sehr unsympathisch.