Picture of Muschelpuster
Registered 7 years 344 days
Muschelpuster Wednesday, 26 August 2020, 07:45 AM
E.164-Szenario und unvollständige DuWa-Blöcke usw.
Moin zusammen,

ich habe da mal wieder ein interessantes Problem und die Hoffnung, dass ich nicht der Erste damit bin wink
Ein Standort in meinem E.164-Szenarion hat die Rufnummern 49.123.456.7-9
Wenn man nun (egal von welchem Standort) die Rufnummer +49(123)456-123 wählt, um den Inhaber des anderen Blocks zu erreichen, dann hat man schlechte Karten, denn das System meint natürlich, dass die Rufnummer zur eigenen Anlage gehört und findet die 123 nicht.
Zwar wird das Amt der Node belegt, nur kommt da großer Müll raus. Aus der Node 49.123.456 sieht das dann so aus:
ROUTE 15 INTERFACE MAP if=GW10:'Amt_456' CGPN-In 890->49123456890, CDPN-In 123->49123456123, DGPN-In ->49123456
Die Manipulationen basieren auf den Einstellungen des GW, aber man sieht, dass nur die Nebenstelle gewählt wird. Damit kann ich natürlich wenig anfangen.

Ganz spannend wird es vermutlich noch, wenn der externe Teilnehmer unsere Anlage anruft, denn auch dann wird seine externe Nummer eingekürzt und nur die Nebenstelle angezeigt.

Und wo ich gerade von solch schönen Problemen schreibe - da gibt es noch Eines was ich nur mit Klimmzügen gelöst bekommen habe: Ein User aus einer Node will die Zentrale (DuWa 0) in einer anderen Node anrufen. Dann wird ganz locker dort mal das Amts-Objekt genommen (es hat ja die 0 und die Nodes haben keine Loopback-Adresse) und im Gateway kommt ein Ruf ohne Rufnummerninformationen an. Da muss doch auch schon mal jemand drüber gestolpert sein, oder?

standortübergreifende Grüße
Niels
Picture of Michel 2733
Registered 8 years 255 days
Michel 2733 Wednesday, 26 August 2020, 08:20 AM
Re: E.164-Szenario und unvollständige DuWa-Blöcke usw.
Hast Du ein Master / Slave(s) Konzept aufgebaut oder wie ist das gelöst ? Da wird ja alles, was der Slave nicht kennt, weiter zum Master geschickt.
Ich frage mich aber, wie der Ruf für die 123 dort überhaupt am Standort rein kommen kann, wenn der RN-Block doch nur die 7xx - 9xx hat ?

Beste Grüße, Michèl
Picture of Muschelpuster
Registered 7 years 344 days
Muschelpuster Wednesday, 26 August 2020, 09:29 AM
Re: E.164-Szenario und unvollständige DuWa-Blöcke usw.
Moin Michèl,

es ist alles eine PBX bzw. Master/Slave. Die Rufe sollen erst einmal raus gehen und kommen aus der betroffenen Node oder einer anderen Node.
Die Rufe kommen rein, weil die PBX bzw. die Nodes nichts von dem eingeschränktem Block wissen - das kann man ja leider nicht einstellen.

eingeschränkte Grüße
Niels

Picture of Danny 2274
Registered 9 years 160 days
Danny 2274 Wednesday, 26 August 2020, 08:23 AM in response to Muschelpuster
1 of 1 users consider this post helpful
Re: E.164-Szenario und unvollständige DuWa-Blöcke usw.
Hi Niels,

zumindest für deine letzte Frage hat das Trunk-Objekt der Innovaphone die Lösung schon an Bord:

Wenn du im e164 Szenario von einer PBX zur -0 einer anderen PBX anrufst, musst du auf der Ziel-PBX dort im Trunk-Objekt beim Loopback-Ziel das "Internal"-Flag setzen (https://wiki.innovaphone.com/index.php?title=Reference13r1:PBX/Objects/Trunk_Line -> Loopback).

Dadurch verbindet das Trunk-Objekt den Anruf wieder zurück in die PBX, anstatt den Ruf ins Amt zuschicken, weil die eigentlich gewählte Ziffer die -0 ist.

mit freundlichen Grüßen

Danny
Picture of Muschelpuster
Registered 7 years 344 days
Muschelpuster Wednesday, 26 August 2020, 09:33 AM
Re: E.164-Szenario und unvollständige DuWa-Blöcke usw.
Moin Danny,

ok, das war zu einfach. Ich habe das jetzt im Routing abgefangen, da ich momentan für das Amt auch GW-Objekte benutze. Das ist aber nur, weil ich auch auf dem Gateway mit GW-Objekten arbeiten muss, da ich nur einen zentralen Trunk mit allen Rufnummern drauf von der Vodafone habe. Es spricht ja nichts dagegen, die Gateways gegen ein Trunk-Objekt in der PBX zu registrieren. Das werde ich testen.

zentralisierte Grüße
Niels
Picture of Muschelpuster
Registered 7 years 344 days
Muschelpuster Thursday, 27 August 2020, 10:04 AM
Re: E.164-Szenario und unvollständige DuWa-Blöcke usw.
Oh doch - da sprich was gegen: Es soll je ein Trunk priorisiert genutzt werden und ein Anderer im Backup. Trunk-Objekte belegen ihre Devices jedoch Round Robin, nur Gateway-Devices in der Reihenfolge der Devices-List.

sortierte Grüße
Niels
Picture of Olaf 1639
Registered 10 years 250 days
Olaf 1639 Thursday, 27 August 2020, 10:15 AM
1 of 1 users consider this post helpful
Re: E.164-Szenario und unvollständige DuWa-Blöcke usw.
Hallo Niels

Die Trunk Objekte machen kein Round Robin mehr zwischen den Devices. Das steht vermutlich immer noch so in der Doku aber dem ist definitiv nicht so.

Gruß Olaf
Picture of Muschelpuster
Registered 7 years 344 days
Muschelpuster Thursday, 27 August 2020, 10:25 AM
Re: E.164-Szenario und unvollständige DuWa-Blöcke usw.
Danke Olaf für die Info,

ich habe in der Tat da nochmal genau das Wiki studiert um mir sicher zu sein. Das bedarf in diesem Punkt also wirklich einer Korrektur.

nachgeschlagene Grüße
Niels
Picture of Peter 627
Registered 13 years 122 days
Peter 627 Wednesday, 26 August 2020, 08:36 AM in response to Muschelpuster
1 of 1 users consider this post helpful
Re: E.164-Szenario und unvollständige DuWa-Blöcke usw.
Das Thema mit den nicht Vollständigen Blöcken habe ich damals schon bei meiner ersten E164 PBX Umgebung probiert zu Adressieren. So richtig schön sind die Lösungen alle nicht.

Um das zu Lösen gibt es aktuell eigentlich nur eine Möglichkeit:
1. Zweites Trunkobjekt für die betroffene Lokation mit einen anderen Präfix als "0". --> z.B. -"*0".
2. Numbermap Objekte für alle Präfixe, die nicht zum Block gehören mit dem Präfixes des zweiten Trunkobjektes aus der PBX zum PSTN Leiten.

Beispiel: Anschluss : + 49 271 7095 [0-69]

Dann macht man für die Nummern 7 , 8 , 9 NumberMap objekte und leitet diese dann wie folgt weiter
7 --> *0027170957
8 --> *0027170958
9 --> *0027170959

So funktionieren die Calls zu mindest, aber es wird auch immer die Trunkline des Zielstandortes genutzt.

-------------------------------------------
Vor Jahren habe ich mal folgendes dazu bei innovaphone angefragt:

Am sauberesten wäre meiner Meinung nach, wenn es eine Range Angabe auf den Node / PBX Objekten geben würde, wo definiert werden kann, in welchem Bereich Rufnummern innerhalb der Nodes liegen können und ansonsten sollte die Node / PBX das direkt abweisen und somit an den normalen Trunkbreakout des Anrufenden Standortes schicken. --> GIBT's aber leider nicht.

Gruß

Peter
Picture of Muschelpuster
Registered 7 years 344 days
Muschelpuster Wednesday, 26 August 2020, 09:37 AM
Re: E.164-Szenario und unvollständige DuWa-Blöcke usw.
Peter, wir sind genau am selben Punkt wink
Damit ich beim Mapping aber nicht die 2. AKZ anzeige, muss ich 'hide connected endpoint' aktivieren, was natürlich auch die Connected Number des Angerufenen unterdrückt. Unschön, aber ist so...

übereinstimmende Grüße
Niels
Picture of Muschelpuster
Registered 7 years 344 days
Muschelpuster Thursday, 27 August 2020, 10:12 AM in response to Peter 627
Re: E.164-Szenario und unvollständige DuWa-Blöcke usw.
Mhh, das war jetzt aber ein langer Weg. Damit ich nicht für jede Node eine neue Trunk- oder GW-Registrierung brauche, mappe ich die Calls jetzt auf 00038449XYZ. Die 384 ist eine unbenutzte Landeskennzahl und in der Root-Node entspr. als Gateway eingerichtet. Auf dem GW kürze ich die 384 wieder weg und habe eine E.164 im Routing.
Das Ganze klappt natürlich wieder nicht, wenn man selber nicht die 0 hat und die Zentrale des anderen Anschlusses anrufen will. Da musste dann noch ein längerer Hebel her wink
Bis auf die fehlerhafte Anzeige bei einem eingehenden Anruf scheint es mir jetzt aber gelöst - nur schön ist etwas Anderes sad

verbogene Grüße
Niels
← You can define your color theme preference here