Dialplan: Ortsvorwahl bei Bedarf hinzufügen funktioniert nicht

[ltrotzki]

Wir haben den Usecase, dass manchmal die Vorwahl gewählt wird, um jemanden im gleichen Ort zu erreichen und manchmal wird die Vorwahl eben gewählt. Ich wollte es so lösen:

[phones]
exten => 202,1,NoOp(call for phn02)
same =>  n,Dial(SIP/phn02)
same =>  n,HangUp

exten => _0X.,1,NoOp(call for ${EXTEN})
same => n,Goto(outgoing,${EXTEN},1)

exten => _[1-9]XXX.,1,NoOp(call for ${EXTEN})
same => n,Goto(outgoing,07253${EXTEN},1)

[outgoing]
exten => _0X.,1,NoOp(outgoing call via t-com)
...

Leider funktioniert das Voranstellen der Ortsvorwahl nicht. Nach meiner Logik: Alle Nummern, die mit 0 beginnen, gehen direkt raus. Das funktioniert auch! Die Nummern, die mit 1 bis 9 beginnen und mindestens 4 Stellen haben (so lange sollte eine Nummer mindestens sein), sollen die Vorwahl 07253 bekommen. Durch Goto erfolgt der Kontext-Switch nach outgoing. Trotzdem meint Asterisk:

Call from 'phn02' (192.168.1.55:5060) to extension '1012' rejected because extension not found in context 'phones'.

System: Asterisk 13.1 LTS Cert2

 

[abw1oim]

Lösung ist ganz einfach:

exten => _[1-9]XXX.

verlangt 5 oder mehr Zeichen (wegen des Punkt am Ende). Wenn 4 Ziffern hinreichend sind, würde

exten => _[1-9]XXX!

funktionieren. Das verlangt nämlich 4 oder mehr Zeichen.

 

[ltrotzki]

*Batsch* das war wirklich einfach, Danke! Zumal ich das sogar gestern gelesen habe (Unterschied zwischen . und !). merci bocu

 

[eisbaerin]

exten => _[1-9]XXX!

Könnte man dafür auch das nehmen:

exten => _[1-9]XX.

Gibt es einen Unterschied?

 

[Andre]

Ja. Bei der ersten Variante muss das vierte Zeichen auch eine Ziffer sein, bei der zweiten kann es auch ein anderes Zeichen sein.
Praktisch hat das meist keine Bedeutung, weil vom Telefon als Ziel nichts anderes als Ziffern gewählt wird, Asterisk und Raute haben i.d.R. besondere Funktionen.

 

[abw1oim]

Nun ja, es gibt einen Unterschied, auch wenn der - bei rein intern betriebenen Anlagen und reiner Ziffernwahl - nicht weiter ins Gewicht fällt:

_[1-9]XXX! oder _ZXXX! verlangt eine Zeichenfolge beginnend mit der Ziffer 1-9 gefolgt von genau drei Ziffern und wiederum potentiell gefolgt von beliebig vielen Zeichen

_[1-9]XX. oder _ZXX. verlangt eine Zeichenfolge beginnend mit der Ziffer 1-9 gefolgt von genau zwei Ziffern und wiederum mindestens von einem beliebigen Zeichen gefolgt.

Mihin gilt:

_ZXXX! matcht etwa bei 1234, 12345, 1234A aber nicht bei 123A
_ZXX. matcht bei 1234, 12345,1234A aber auch bei 123A

Deshalb verwenden Amerikaner in Ihren Dialplänen (dank eines geschlossenen Rufnummernplanes geht das auch einfach) z.B. explizit:

_NXXNXXXXXX für eine Nummer im 10-Digit-Format bzw.
_NXXXXXX für eine Nummer im 7-Digit-Formart (im eigenen Area-Code)

Alternativ etwa die Schweizer (auch mit geschlossenem Nummernplan):

_0NXXXXXXXX für eine beliebige inländische Rufnummer (außer Kurzwahlen).

zu Pattern siehe auch Dialplan Pattern

 

[eisbaerin]

Ich danke euch. Also für die heutige normale Telefonie wäre es egal, aber im speziellen Fall gibt es schon einen Unterschied.
Wer kann heute schon ein "A" wählen.

 

[abw1oim]

Wenn nicht explizit per Konfiguration ausgeschlossen: Jedes Softphone.

Daher empfiehlt sich allenfalls noch die Nutzung von FILTER, wenn man ganz sicher sein will und URI-Dialing nicht erlauben will / einschränken will.

Ansonsten natürlich bei "offenen" Anlagen, also allowguest nicht explizit auf no steht (vielleicht, weil man ENUM nutzt, oder aber einen Telekomanschluss hat und die Loadbalancer nicht pflegen mag, oder oder oder): Jeder "böse Bube" von außen könnte URI-Dialing nutzen ...

 

[eisbaerin]

Ja, OK. Aber dem TO hätte es schon geholfen, wenn er ein X entfernt hätte.

BTW:
Es gibt aber kein Pattern, der sagt: jetzt noch beliebig viele Ziffern.
IMO fehlt der noch. Denn den müßte man eigentlich z.Z. fast immer einsetzen.
Oder gibt es da eine andere Möglichkeit? Mir fällt keine ein.

 

[abw1oim]

Es gibt aber kein Pattern, der sagt: jetzt noch beliebig viele Ziffern.

Nein, das ist noch nie implementiert worden. Im Ergebnis hat man bei offenen Wähplänen wie in DE bzw. wenn man sich nicht die Mühe machen will, geschlossene Pläne immer exakt auszuspezifizieren, dann nur die Variante, in der eigentlichen extension mit FILTER zu arbeiten, um alle Nicht-Ziffern aus der extension rauszuwerfen, bevor man weitermacht.

 

[xrated]

Asterisk schneidet doch ausgehend sowieso alles hinter @ ab weil es denkt es sei der context oder nicht?
Und eingehend, wo liegt die Gefahr?

 

[abw1oim]

Asterisk schneidet doch ausgehend sowieso alles hinter @ ab

Das ist so nicht richtig. Wenn Du etwa folgendes machst:

Dial(SIP/[email protected])

wird Asterisk eine Verbindung zu dem Ziel [email protected] aufbauen, auch wenn sipgate.de nicht in sip.conf definiert ist.

Insoweit würde also bei

exten => _[1-9]XXX. ,1,Dial(SIP/${EXTEN})

auch eine Verbindung zu [email protected] aufbaubar sein, da der String auf das Pattern passt. Will man das verhindern, muss man

exten => _[1-9]XXX. ,1,Set(ToDial=${FILTER(0-9,${EXTEN})}) 
exten => _[1-9]XXX. ,n,Dial(SIP/${ToDial})

benutzen, dann würde bei dem String 10000 gewählt (@sipgate.de würde über FILTER entfernt)