Rufnummern - ÖNORM

[Peter Oskar Miller]

Entsprechend ÖNORM 1080, Punkt 2.5 sind Rufnummern mit Klammern nicht nur zulässig sondern auch korrekt:
Auch entsprechend des Microsoft Formats (kanonische Form) ist hier die Variante mit den Klammern üblich.
Und auch wenn die Klammern in Deutschland nicht standardkonform sind, so sind diese dennoch weiterhin gebräuchlich.

So ist der Wortlaut der ÖNORM 1080:
Telefon- und Faxnummern: Vorwahlnummern (auch von Mobiltelefonen) sind in Klammern zu setzen. Die Gliederung der Ruf- und Faxnummern erfolgt nach den Angaben des Amtlichen Telefonbuches. Nebenstellennummern werden mit Bindestrich an die Rufnummer oder mit dem Vermerk DW (Durchwahl) angeschlossen. Meine Telefonnummer lautet: (01) 12 13 14 oder (0676) 11 12 13 14. Rufen Sie bitte die Telefonnummer (07413) 11 12-2.

Wir haben daher sowohl bei uns als auch bei allen Kunden dies bei Microsoft 365 in dieser Form hinterlegt - sogar in internationaler Schreibweise: +43 (1) 123 4567-89

Nun ist aber das Problem, dass Rufnummernfilter in 3CX nicht mit einer RegEx bearbeitet werden können. Wir importieren mit dem Microsoft 365 Importer die Rufnummern der Mitarbeiter und diese sind nun mal mit +43 (664) 1234 567 festgelegt. Wenn nun - beispielsweise in der Abwesenheit Einstellung - hinterlegt wird, dass auf die Mobilrufnummer umgeleitet werden soll so kommt nur die Ansage, dass dies nicht erlaubt wäre.

Ich hatte die Diskussion bereits mit dem Support und dieser hat mich auf Version 18 vertröstet. Nun - bei der aktuellen 18b2 ist dies aber leider unverändert!

Ich plädiere hiermit entweder für eine RegEx Implementation oder zumindest (als quick-solution) für ein Filtern der Klammern.

mfg
Peter Miller

 

[bitn2]

Die ÖNORM 1080 ist seit 2018 nicht mehr gültig.

 

[Peter Oskar Miller]

ok - akzeptiert - ungeachtet dessen haben dies aber noch unglaublich viele in Ihren Nummernformaten - wird sich wohl mindestens so lange halten bis IPv6 IPv4 abgelöst hat. ;-)

Aber wie sieht es mit der Microsoft Schreibweise aus - ist die auch nicht mehr gültig?

LG
Peter Miller

 

[bitn2]

Ich habs grad nur mal in der V18 Windows App getestet, da ignoriert er die Klammern und wählt ganz normal die Nummer. Ob das beim weiterleiten auch geht kann ich grad nicht testen. Ich kenne jetzt keine Microsoft Norm was Telefonnummern angeht, aber da lass ich mich gern eines Besseren belehren.

 

[Peter Oskar Miller]

also in der App ja (da hat er es auch schon bei v16 gemacht. Es funktioniert nur dann nicht, wenn die Mobilrufnummer bei der Durchwahl hinterlegt ist und in den Weiterleitungsregeln auf die Mobilrufnummer umgeleitet werden soll. Bessert man die Rufnummer aus (also entfernt man die Klammern), dann klappt das problemlos - nur werden die Klammern beim nächsten Import von Microsoft 365 wieder reingenommen.

 

[bitn2]

So habs grad mal getestet, klappt ohne Problem mit der aktuellen V18.

 

[Peter Oskar Miller]

ok - spannend. Ich hab bei mir die 18.0 build 1865 laufen.
Rufnummer sieht bei mir so aus: +43 (664) 88xxxxxx und ist bei der Durchwahl unter "Allgemein" bei "Mobilnummer" hinterlegt.
In der Weiterleitungsregel hab ich drinnen, dass er auf das Mobiltelefon umleiten soll.
Er macht dann ein reformat auf 0 (664) 8888xxxxxx und ich bekomm dann nur die Ansage "dieser Anruf ist leider nicht erlaubt".
Und leider finde ich weder etwas im Aktivitätenprotokoll noch unter den Ereignissen.

Ändere ich es auf +43 664 88xxxxxx so bekomme ich die gleiche Fehlermeldung.

Nur wenn ich den Nummernblock in einem habe (also +4366488xxxxxx) dann funktioniert es.

 

[bitn2]

Wie sehen denn deine ausgehenden Regeln aus?

 

[Peter Oskar Miller]

 

[bitn2]

Formatierst Du da noch irgendwas um? Die Details der Regeln interessieren mich.

 

[Peter Oskar Miller]

 

[bitn2]

Deine ausgehende Rufnummer ist falsch, da muss entweder das + oder 00 davor. Warum formatierst Du die Nummern unten noch um?

 

[Peter Oskar Miller]

Mit der ausgehenden Rufnummer hast natürlich recht - aber da bei jeder Durchwahl ohnehin die volle Rufnummer +431344...DW hinterlegt ist, ist das noch nie aufgefallen.

der SIP Provider kann mit dem + nicht umgehen - daher wird das + von uns noch in ein 00 umgewandelt

 

[bitn2]

Das sind aber die eingehenden Nummern die Du formatierst und nicht die ausgehenden. Das kannst Du auch ganz entspannt mit den ausgehenden Regeln machen. In welchem Format ist denn die Handynummer hinterlegt?

 

[bitn2]

Füge mal bei der ausgehenden Regel die Nebenstellengruppe hinzu. Das fällt mir grad noch auf, das funktioniert nicht mehr ohne Nebenstelle oder Nebenstellengruppe.

 

[Peter Oskar Miller]

Hab ich gemacht - hat allerdings nichts verändert.

 

[bitn2]

Was sagen denn die Logfiles wenn Du so einen Anruf machst? Stell mal untern Aktivitätenprotokoll in den Einstellungen auf Mittel und mach mal so einen Anruf. Was zeigt er Dir da dann an?

 

[Peter Oskar Miller]

DW 500 ruft DW 200 - diese ist so eingestellt, dass diese an das Mobiltelefon +43 66488xxxxxx umleiten soll.

Wenn ich das Leerzeichen rausnehm klappt es.

02.08.2021 16:44:16 - Currently active calls - 1: [91]

02.08.2021 16:44:14 - [CM505003]: Provider:[fonira] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:[email protected]:5060]

02.08.2021 16:44:14 - [CM503002]: Call(C:91): Alerting Line:10000>>0 66488xxxxxx by contact <sip:[email protected]:5060/UDP>

02.08.2021 16:44:14 - [CM503025]: Call(C:91): Calling T:Line:10000>>0 66488xxxxxx@[Dev:sip:[email protected]:5060] for L:91.1[Extn:500]

02.08.2021 16:44:14 - [CM503027]: Call(C:91): From: Extn:500 ("Miller, Peter" <sip:[email protected]:0>) to T:Line:10000>>0 66488385200@[Dev:sip:[email protected]:5060]

02.08.2021 16:44:14 - [CM503004]: Call(C:91): Route 1: from L:91.1[Extn:500] to T:Line:10000>>0 66488xxxxxx@[Dev:sip:[email protected]:5060]

02.08.2021 16:44:14 - Line limit check: Current # of calls for line Lc:10000(@fonira[<sip:[email protected]:5060/UDP>]) is 0; limit is 8

02.08.2021 16:44:14 - [Flow] Call(C:91): applied forwarding rule (Fwd[Away/AllCalls]) Extn:200 -> Out#:>>Rule{fonira}>>0 66488385200

02.08.2021 16:44:14 - [Flow] Target endpoint for +43 66488385200 is Out#:>>Rule{fonira}>>0 66488385200

02.08.2021 16:44:14 - [Flow] Target endpoint for +43 66488385200 is Out#:>>Rule{fonira}>>0 66488385200

02.08.2021 16:44:14 - [Flow] Call(C:91): has built target endpoint: Extn:200 for call from L:91.1[Extn:500]

02.08.2021 16:44:14 - [Flow] Target endpoint for 200 is Extn:200

02.08.2021 16:44:14 - [CM503010]: Call(C:91): Making route(s) from Extn:500 to <sip:[email protected]:5060/UDP>

02.08.2021 16:44:14 - [CM505001]: Endpoint Extn:500: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX WebRTC proxy] PBX contact: [sip:[email protected]:5060]

02.08.2021 16:44:14 - [CM500002]: Call(C:91): Info on incoming INVITE from Extn:500: Invite-IN Recv Req INVITE from 127.0.0.1:5063 tid=8f471d155050ca52 Call-ID=A_lEPNDPqyRExEXObNKP6w..: INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5063;branch=z9hG4bK-524287-1---8f471d155050ca52;rport=5063 Max-Forwards: 70 Contact: <sip:[email protected]:5063;rinstance=e7663ad57176db9b> To: <sip:[email protected]:5060> From: "Miller, Peter"<sip:[email protected]>;tag=a7058519 Call-ID: A_lEPNDPqyRExEXObNKP6w.. CSeq: 2 INVITE Subject: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE Content-Type: application/sdp Proxy-Authorization: Digest username="xqI93gjqxi",realm="3CXPhoneSystem",nonce="414d5359610804be04:d26f5cb6811b14a84ae10fe78950f1f1",uri="sip:[email protected]:5060",response="eea8c00f73b1f4cd609f9a23f392154f",algorithm=MD5 Supported: replaces User-Agent: 3CX WebRTC proxy Content-Length: 595

 

[Peter Oskar Miller]

Somit landet die Nummer inkl. Leerzeichen beim SIP Provider - und der kann damit nicht umgehen - und ich kann sie nicht umformatieren weil 3CX kein RegEx kann.

 

[fxbastler]

Hallo,

ihr seid bereits voll in Fahrt und ich will nicht weiter mitmischen, viele Köche und der Brei ...

Ich habe aber dennoch Bedenken bzgl. deiner fonira Umformatiererei der Nummern eingehender Anrufe. Wenn ich das irgendwo so machen würde wäre es generell immer falsch.

Regel 1: source '(anonymous)' replace '\1' nehme ich so hin wie sie ist. Das ist vmtl. eine Notwendigkeit wegen Regel 3.

Regel 2: source '43(.*)' replace '0\1' wäre (für uns und vmtl. auch für Österreich) falsch. Kommen denn da von fonira Anrufe ohne 0, 00 oder + sondern nur mit der Länderkennung 43 rein? Das ist dann viel zu allgemein gehalten und triggert auf alles mit einer 43 am Anfang der Nummer. Auch auf Anrufe aus Prebl u.a., ausser die kommen mit einer weiteren 43 vorn dran rein. Ich denke da sollte stehen source '+43(.*)' replace '0\1' und vmtl. eine weitere Regel source '0043(.*)' replace '0\1'

Regel 3: source '(.*)' replace '00\1' macht keinen Sinn. Da wird einfach jedem eingehenden Anruf der nicht schon auf Regel 1 oder 2 passt eine '00' vorangestellt. Das kann irgendwie nicht stimmen. Evtl. ändern auf source '(.*)' replace '0\1'?

Das alles mal unter der Annahme ihr wollt generell eine 0 für alle ausgehenden (Amts-) Gespräche vorn dran weil die eingehenden Nummern dann so formatiert abgelegt werden, mit extra Null. Würde ich aber dennoch so nicht machen.