Seit V20 neuerstelle und zugewiesene DIDs sind beim Anrufen "nicht vergeben/kein Anschluss unter dieser Nummer"

[dbmuc]

Servus Gemeinde,

anbei seht ihr zwei Screenshots von zwei 3CX Instanzen, beide sind Upgrades von V18.

Im Ausgang seht ihr meine versuchten Anrufe an verschiedene Durchwahlen der anderen Anlage, die dort angelegten DIDs mit den damals (V18) eingerichteten eingehenden Regeln funktionieren soweit, bis auf die Nebenstelle 2992.

Die seit der V20 eingerichteten und zugewiesenen DIDs 2973, 285, 297 sind weder von der ausgehenden Anlage noch vom Mobilfunk erreichbar ("die Nummer ist nicht vergeben/kein Anschluss unter dieser Nummer")

Im Eingang seht ihr die Reaktion auf die ankommenden Anrufe, von denen alle anscheinend zumindest registriert wurden, es aber tatsächlich nur bei denen mit einer Gesamtdauer von über einer Sekunde überhaupt geklingelt hat.

Nachdem ich schon etliche V18 sowie V20 Anlagen eingerichtet und konfiguriert habe, stehe ich nun doch etwas auf dem Schlauch, hat jemand eine Idee?

Die DIDs sind alle im Format +49123123-2973 eingerichtet, damit ausgehende Anrufe werden auch korrekt angezeigt.

Wenn ich intern von der eingehenden 3CX (beispielsweise die -2992) versuche die (ja intern vorhandene) DID +49123123-2973 zu erreichen kommt ebenfalls "kein Anschluss unter dieser Nummer"

 

[fxbastler]

Ich nehme ja mal an, dass du bei der Angabe der DID das - nicht benutzt. Das sollte man nie.

Aber wegen der anderen Durchwahlen - schau dir bitte deine eingehenden Regeln und speziell deren Reihenfolge an:
Admin / Berichte / eingehende Regeln.

In einer 3CX v20 ist die Reihenfolge nicht änderbar, es wird immer automatisch sortiert, siehe hier
https://www.3cx.de/forum/threads/checkliste-upgrade-auf-v20.121058/post-436540

unter Punkt 6:

durch den Wegfall eingehender Regeln kann die Reihenfolge der Abarbeitung der DID nicht festgelegt werden, daher sind nicht mehr alle durchwahlfähigen Nummern nutzbar (z.B. -20 nicht nutzbar wenn -20x genutzt wird)

Kann es sein, dass das bei dir zutrifft? Eben weil du die DID 297 und 2973 beschreibst.

Grundsätzlich sind bei vielen Providern 15-stellige Nummern wählbar - aber eben nicht bei allen. Auch dann gibt es noch Ausnahmen und Kürzungen.

Letzten Endes hilft bei so etwas - der Verfolgung eingehender Anrufe und der Abarbeitung der eingehenden Regeln - immer das ausführliche Protokoll der 3CX oder der Binlog Viewer.
Hier ein Beispiel des BLV wg. inbound rule und Reihenfolge:

 

[dbmuc]

Ja richtig, das - in der DID habe ich es hier nur visuell genutzt.

Der Wegfall der eingehenden Regeln seit dem Upgrade ist ein Irrsinn, lassen die sich bearbeiten?

Die Reihenfolge der alten V18 Rules machen in diesem Fall alle zukünftigen DIDs unbrauchbar wegen der alten *-Regel:

 

[fxbastler]

Der Wegfall der eingehenden Regeln seit dem Upgrade ist ein Irrsinn, lassen die sich bearbeiten?

Was genau meinst du damit?

Eingehende Regeln gibt es nicht mehr (zumindest nicht vordergründig in einer 3CX und auch nicht bearbeitbar wie früher bis v20). Das alles klärt sich über das Anlegen von DID, zuweisen von DID zu irgendwelchen 3CX Entitäten und evtl. einem Ändern des Namen nach der Zuweisung. Die Sortierung erfolgt dabei eben automatisch, das konnte man früher™ steuern.

Die Reihenfolge der alten V18 Rules machen in diesem Fall alle zukünftigen DIDs unbrauchbar wegen der alten *-Regel:

Ja, das kann durchaus sein. Das hatte ich schon geschrieben.

Das was dein Bildschirmfoto zeigt - ein * am Ende der DID - ist ohnehin unnütz. 'Das hat noch nie funktioniert'™

Ein * bei DID wird einmal und nur am Anfang verarbeitet. Vielleicht ist das auch der Grund, weshalb diese DID in der Liste unterhalb der DID ...9299x stehen.

 

[dbmuc]

ja ganz richtig, früher™ war alles besser
Das man früher die Regeln noch steuern konnte und heute nicht mehr ist.. irrsinnig bis strategischer Abbau eines Features.

Die DIDs mit * am Ende hatten schon funktioniert und tuhen es anscheinend ja immer noch -.- / edit: bzw. die Regel (auch ohne *) greift der Reihenfolge nach die DIDs darunter ab
Dann bleibt rein logisch betrachtet nichts anderes übrig als diese zu löschen damit die nicht mehr in den eigehenden Regeln stören..

Was soll man machen mit unkonfigurierten DIDs? Die landen dann auf der Standardroute des Trunks richtig? Kann man das Blockieren nicht vergebener DIDs dann anders lösen unter V20? Nicht weil ich es will, aber der Kunde..

 

[fxbastler]

bzw. die Regel (auch ohne *) greift der Reihenfolge nach die DIDs darunter ab

s.o.: das * am Ende ist unnütz, war es schon immer

Dann bleibt rein logisch betrachtet nichts anderes übrig als diese zu löschen damit die nicht mehr in den eigehenden Regeln stören..

richtig

Was soll man machen mit unkonfigurierten DIDs?

nichts; warum auch, sonst wären die ja konfiguriert

Die landen dann auf der Standardroute des Trunks richtig?

richtig

Kann man das Blockieren nicht vergebener DIDs dann anders lösen unter V20?

Die Standardroute gefällt dir bzw. dem Kunden nicht?
Dann einmal alle einrichten und irgendwohin verweisen lassen - viel Spaß dabei. Immerhin kann man die importieren.

 

[dbmuc]

Die Standardroute gefällt dir bzw. dem Kunden nicht?
Dann einmal alle einrichten und irgendwohin verweisen lassen - viel Spaß dabei. Immerhin kann man die importieren.

Haha! Noch so ein Feature bei dem 3CX nach bzw. etwas ausgelassen hat, schön das man die DIDs importieren aber nicht expotieren/backuppen kann..

Anyway ich weiß Bescheid, Danke!

 

[fxbastler]

aber nicht expotieren/backuppen kann.

Reportttt...
plus copy + paste

die CSV hat pro Zeile das Format:
+4930123456789,1234,Bezeichnung

 

[dbmuc]

Oder gleich bei den eingehenden Regeln als CSV exportieren und entsprechend umformattieren.. wie praktisch..
Aber wir basteln doch gern oder? =)

 

[Josef L]

ich sehe gerade das Thema. Wenn ich das richtig sehe gibt es 3 und 4 stellige Durchwahlen...geht das überhaubt?

 

[fxbastler]

Wenn ich das richtig sehe gibt es 3 und 4 stellige Durchwahlen...geht das überhaubt?

Es geht beim TO um den letzten Teil der DID eines Rufnummernblock und ja, das geht. Meist auch mit mehr Nummern als der RNB das vorgibt so lange diese so durchwahlfähigen Rufnummern innerhalb des RNB liegen. Sofern der Provider das zulässt kann man auf diese Art und in Grenzen den zugewiesenen Rufnummernblock erweitern, auch wenn es i.d.R. nicht dokumentiert ist und kein Anspruch auf diese Funktion besteht, s.u..
Wir haben z.B. einen sehr kleinen Kunden mit normaler / kurzer Stammnummer und 1000er RNB. Auch da kann man noch weiter durchwählen und einen 10000er Block draus machen. Der Witz dort: der Kunde hat weniger 10 NSt. und Endgeräte.

Das mit dem weiteren Durchwählen ist ein Merkmal einer klassischen TK Anlage mit RNB, noch vor VOIP. Irgendwann (schon sehr viele Jahre her) 'reichten die ext. Nummern nicht' und einen vorh. RNB um weiteren nebenliegende Nummern zu erweitern war i.d.R. nicht möglich. Aber die Nummer (Stammnummer) samt allen weitergehenden längeren Nummern innerhalb des vergebenen RNB 'gehört' ja dem Teilnehmer und wird nicht anderweitig zugewiesen / kann nicht zugewiesen werden. Die RNB wurden weiter durchwahlfähig 'gestaltet'. Es besteht nur kein Anspruch darauf das nutzen zu können.

Man sollte auch die Gesamtlänge von routingfähigen wählbaren Nummern bei VOIP beachten. Die Grenze überhaupt ist spätestens bei 15 mit Präfix (LKZ) erreicht, siehe Festlegung BNetzA auf Grund der Empfehlung der internat. Fernmeldeunion zu E.164.

Was von beidem eher da war weiss ich gar nicht, vmtl. ersteres.

 

[fxbastler]

Aber ich muss mich inzwischen korrigieren was das

s.o.: das * am Ende ist unnütz, war es schon immer

betrifft. Da gab es wohl eine Änderung in der u7 und das hat Auswirkungen. Ein * am Ende ist nun erstmals nicht mehr unnütz. Ich widerspreche mir nachträglich und behaupte nun das Gegenteil

bzw. die Regel (auch ohne *) greift der Reihenfolge nach die DIDs darunter ab

Das war bisher richtig, nun nicht mehr. Nun wird das * am Ende für diese Funktion zwingend benötigt.

Ich hatte das anderswo schon thematisiert:
https://www.3cx.com/community/threads/inbound-calls-routing.135047/post-648277
Die Reaktion darauf dort und insgesamt war doch - gelinde gesagt - sehr verhalten.

 

[Josef L]

ich meinte eigentlich die 3CX ich muss doch bei der Installation festelegen ob dreistellig oder vierstellig.

 

[matictec]

ich meinte eigentlich die 3CX ich muss doch bei der Installation festelegen ob dreistellig oder vierstellig.

Aber die DIDs haben ja erstmal nichts mit den internen Nebenstellen zu tun. Das ist eine reine Mapping-Frage.