FritzBox als Gateway für Gemeinschaft 5.1 verwenden
d.me...@gmail.com
Hallo,
Da aber eben auch eingehende Gespräche über die Fritzbox an Gemeinschaft möglich sein sollen bin ich gerade ein wenig am probieren.. Das Problem ist eigentlich, das soweit ich das sehe keine Rufnummer übergeben wird von der Fritzbox welche Rufnummer angerufen wurde (siehe Log).
2013-03-07 08:40:33.034483 [NOTICE] switch_channel.c:968 New Channel sofia/gemeinschaft/0160X...@fritz.fonwlan.box [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda]
2013-03-07 08:40:33.114683 [INFO] mod_dialplan_xml.c:557 Processing 0160XXXXXXX <0160XXXXXXX>->gateway3 in context default
2013-03-07 08:40:33.114683 [INFO] switch_cpp.cpp:1274 #E# [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda] PRESENCE_INBOUND: account: 0160XXXXXXX, state: alerting
2013-03-07 08:40:33.194575 [NOTICE] switch_cpp.cpp:1274 ### [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda] DIALPLAN_DOMAIN - setting default domain: 192.168.3.1
2013-03-07 08:40:33.214491 [NOTICE] mod_dptools.c:1534 CHANNEL_DATA:
Channel-State: [CS_EXECUTE]
Channel-Call-State: [RINGING]
Channel-State-Number: [4]
Channel-Name: [sofia/gemeinschaft/0160X...@fritz.fonwlan.box]
Unique-ID: [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda]
Call-Direction: [inbound]
Presence-Call-Direction: [inbound]
Channel-HIT-Dialplan: [true]
Channel-Presence-ID: [0160X...@fritz.fonwlan.box]
Channel-Call-UUID: [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda]
Answer-State: [ringing]
Channel-Read-Codec-Name: [PCMA]
Channel-Read-Codec-Rate: [8000]
Channel-Read-Codec-Bit-Rate: [64000]
Channel-Write-Codec-Name: [PCMA]
Channel-Write-Codec-Rate: [8000]
Channel-Write-Codec-Bit-Rate: [64000]
Caller-Direction: [inbound]
Caller-Username: [0160XXXXXXX]
Caller-Dialplan: [XML]
Caller-Caller-ID-Name: [0160XXXXXXX]
Caller-Caller-ID-Number: [0160XXXXXXX]
Caller-Network-Addr: [192.168.1.1]
Caller-ANI: [0160XXXXXXX]
Caller-Destination-Number: [gateway3]
Caller-Unique-ID: [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda]
Caller-Source: [mod_sofia]
Caller-Context: [default]
Caller-Channel-Name: [sofia/gemeinschaft/0160X...@fritz.fonwlan.box]
Caller-Profile-Index: [1]
Caller-Profile-Created-Time: [1362642033074988]
Caller-Channel-Created-Time: [1362642033074988]
Caller-Channel-Answered-Time: [0]
Caller-Channel-Progress-Time: [0]
Caller-Channel-Progress-Media-Time: [0]
Caller-Channel-Hangup-Time: [0]
Caller-Channel-Transfer-Time: [0]
Caller-Channel-Resurrect-Time: [0]
Caller-Channel-Bridged-Time: [0]
Caller-Channel-Last-Hold: [0]
Caller-Channel-Hold-Accum: [0]
Caller-Screen-Bit: [true]
Caller-Privacy-Hide-Name: [false]
Caller-Privacy-Hide-Number: [false]
variable_direction: [inbound]
variable_uuid: [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda]
variable_session_id: [1]
variable_sip_from_user: [0160XXXXXXX]
variable_sip_from_uri: [0160X...@fritz.fonwlan.box]
variable_sip_from_host: [fritz.fonwlan.box]
variable_channel_name: [sofia/gemeinschaft/0160X...@fritz.fonwlan.box]
variable_sip_call_id: [0CD89F43...@192.168.1.1]
variable_sip_local_network_addr: [37.5.246.34]
variable_sip_network_ip: [192.168.1.1]
variable_sip_network_port: [5060]
variable_sip_received_ip: [192.168.1.1]
variable_sip_received_port: [5060]
variable_sip_via_protocol: [udp]
variable_sip_from_user_stripped: [0160XXXXXXX]
variable_sip_from_tag: [FD02A2F98536565E]
variable_sofia_profile_name: [gemeinschaft]
variable_recovery_profile_name: [gemeinschaft]
variable_sip_full_via: [SIP/2.0/UDP 192.168.1.1:5060;branch=z9hG4bK51B06D6374E0C467]
variable_sip_full_from: [<sip:0160X...@fritz.fonwlan.box>;tag=FD02A2F98536565E]
variable_sip_full_to: [<sip:gate...@192.168.3.1:5060;gw=gateway3>]
variable_sip_req_params: [gw=gateway3]
variable_sip_req_user: [gateway3]
variable_sip_req_port: [5060]
variable_sip_req_uri: [gate...@192.168.3.1:5060]
variable_sip_req_host: [192.168.3.1]
variable_sip_to_params: [gw=gateway3]
variable_sip_to_user: [gateway3]
variable_sip_to_port: [5060]
variable_sip_to_uri: [gate...@192.168.3.1:5060]
variable_sip_to_host: [192.168.3.1]
variable_sip_contact_user: [DE6C718B011455013B498CC85B5AB]
variable_sip_contact_uri: [DE6C718B011455...@192.168.1.1]
variable_sip_contact_host: [192.168.1.1]
variable_sip_user_agent: [AVM FRITZ!Box Fon WLAN 7270 v2 54.05.05 (Jul 1 2011)]
variable_sip_via_host: [192.168.1.1]
variable_sip_via_port: [5060]
variable_max_forwards: [70]
variable_presence_id: [0160X...@fritz.fonwlan.box]
variable_sip_gateway: [gateway3]
variable_switch_r_sdp: [v=0
o=user 380011 380011 IN IP4 192.168.1.1
s=call
c=IN IP4 192.168.1.1
t=0 0
m=audio 7086 RTP/AVP 8 0 102 100 99 97 101
a=rtpmap:102 G726-32/8000
a=rtpmap:100 G726-40/8000
a=rtpmap:99 G726-24/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtcp:7087
]
variable_sip_remote_audio_rtcp_port: [7087]
variable_remote_media_ip: [192.168.1.1]
variable_remote_media_port: [7086]
variable_sip_audio_recv_pt: [8]
variable_sip_use_codec_name: [PCMA]
variable_sip_use_codec_rate: [8000]
variable_sip_use_codec_ptime: [20]
variable_read_codec: [PCMA]
variable_read_rate: [8000]
variable_write_codec: [PCMA]
variable_write_rate: [8000]
variable_endpoint_disposition: [RECEIVED]
variable_call_uuid: [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda]
variable_gs_account_node_local: [true]
variable_current_application_data: [notice]
variable_current_application: [info]
2013-03-07 08:40:33.214491 [INFO] switch_cpp.cpp:1274 ### [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda] AUTH_GATEWAY - sip_req_user ~ ^gateway3, gateway=3, name: kabel_deutschland_fritzbox, ip: 192.168.1.1
2013-03-07 08:40:33.234963 [INFO] switch_cpp.cpp:1274 ### [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda] CALLER_DATA - no data - unauthenticated call: /
2013-03-07 08:40:33.254555 [NOTICE] switch_cpp.cpp:1274 ### [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda] INBOUND - no route
2013-03-07 08:40:33.254555 [INFO] switch_cpp.cpp:1274 ### [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda] DESTINATION_NEW - unknown=0/@1, number: gateway3
2013-03-07 08:40:33.254555 [INFO] switch_cpp.cpp:1274 ### [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda] DIALPLAN start - caller_id: 0160XXXXXXX "0160XXXXXXX" , number: gateway3, language: de
2013-03-07 08:40:33.254555 [INFO] switch_cpp.cpp:1274 ### [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda] LOOP 1 - destination: unknown=0/@1, number: gateway3
2013-03-07 08:40:33.254555 [INFO] switch_cpp.cpp:1274 ### [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda] CALLER_ID_NUMBERS - clir: false, numbers: 0160XXXXXXX
2013-03-07 08:40:33.274547 [NOTICE] switch_cpp.cpp:1274 ### [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda] SWITCH - no route - number: gateway3
2013-03-07 08:40:33.274547 [INFO] switch_cpp.cpp:1274 ### [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda] DIALPLAN end - caller_id: 0160XXXXXXX "0160XXXXXXX", destination: unknown=0/@1, number: gateway3, result: 404 No route
2013-03-07 08:40:33.274547 [NOTICE] mod_sofia.c:2690 Hangup sofia/gemeinschaft/0160X...@fritz.fonwlan.box [CS_EXECUTE] [UNALLOCATED_NUMBER]
2013-03-07 08:40:33.274547 [INFO] switch_cpp.cpp:1274 ### [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda] HANGUP_HOOK: hangup
2013-03-07 08:40:33.296188 [NOTICE] switch_core_session.c:1517 Session 1 (sofia/gemeinschaft/0160X...@fritz.fonwlan.box) Ended
2013-03-07 08:40:33.296188 [NOTICE] switch_core_session.c:1521 Close Channel sofia/gemeinschaft/0160X...@fritz.fonwlan.box [CS_DESTROY]
2013-03-07 08:40:33.314517 [INFO] switch_cpp.cpp:1274 #E# [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda] PRESENCE_INBOUND: account: 0160XXXXXXX, state: idle
2013-03-07 08:40:33.314517 [INFO] switch_cpp.cpp:1274 #E# [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda] CDR_SAVE - account: NULL=NULL, caller: NULL NULL, callee: NULL NULL, cause: "UNALLOCATED_NUMBER"
2013-03-07 08:40:33.334738 [INFO] switch_cpp.cpp:1274 #E# [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda] CALL_HISTORY_SAVE - ignore caller entry - account: =0, local: true
2013-03-07 08:40:33.334738 [INFO] switch_cpp.cpp:1274 #E# [008f7ba0-f6d4-4a61-8fcb-a186ad86bbda] CALL_HISTORY_SAVE - ignore callee entry - account: unknown=0, local: true
Ich habe dann versucht die Variable sip_to_user über die Inbound Regel eben auf eine gültige Rufnummer zu setzen, damit ich diese ganz normal in Gemeinschaft verwenden kann. Hier muss ich dann eben einen Gateway für jede eingehende Rufnummer der Fritzbox anlegen..
Jemand eine Idee?
<?xml version="1.0" encoding="UTF-8"?>
<call_route name="kabel_deutschland_fritzbox" routing_table="inbound" position="3" endpoint_type="phonenumber">
<route_elements count="2">
<route_element position="1" var_out="sip_to_user" var_in="sip_to_user" replacement="00496021YYYYYYY" pattern="^gateway3$" mandatory="true" action="match"/>
<route_element position="2" var_out="sip_to_user" var_in="sip_to_user" replacement="00496021YYYYYYY" pattern="^gateway3$" mandatory="false" action="set"/>
</route_elements>
</call_route>
Brachte Brachte leider keinen Erfolg.. :(
Vielen Danke und Gruß.
Dennis Meyer
Peter Kozak
contact = +496021YYYYYYY
in Gateway-Settings eintraegst?
Ein FreeSWITCH restart wird danach noetig sein.
Mit freundlichen Gr��en
Peter Kozak
--
AMOOMA GmbH - Bachstr. 124 - 56566 Neuwied --> http://www.amooma.de
Gesch�ftsf�hrer: Stefan Wintermeyer, Handelsregister Montabaur B14998
B�cher: http://das-asterisk-buch.de - http://ruby-auf-schienen.de
Peter Kozak
> On 03/07/2013 09:24 AM, d.me...@gmail.com wrote:
>> Brachte Brachte leider keinen Erfolg.. :(
>
> Was passiert, wenn Du einfach
>
> contact = +496021YYYYYYY
+496021YYYYYYY umwandelt.
<route_element position="1" var_out="sip_to_user" var_in="sip_to_user"
replacement="00496021YYYYYYY" pattern="^gateway3$" mandatory="true"
action="match"/>
element wohl nur statt var_out="sip_to_user" einfach
var_out="destination_number" verwenden muessen.
Weiterhin wuerde ich bei sowas empfehlen, als Replacement nicht
"00496021YYYYYYY" sondern immer das e164 Format "+496021YYYYYYY" zu
benutzen.
Das spart ein Zeichen ;)
Der Hintergrund ist aber, dass man das moeglichst einheitlich haben
sollte. Das "prerouting" wandelt z.B. eine gewaehlte Nummer auch immer
zunaechst in dieses Format.
Die folgende Route dient dann noch um die Caller-ID anzupassen:
<call_route endpoint_type="phonenumber" name="strip international
prefix" position="1" routing_table="inbound">
<route_elements count="3">
<route_element position="1" var_out="" var_in="destination_number"
replacement="" pattern="^%+496021YYYYYYY$" mandatory="true" action="match"/>
<route_element action="set" mandatory="false" pattern="^00([1-9]%d+)$"
position="2" replacement="+%1" var_in="caller_id_number"
var_out="caller_id_number"/>
<route_element action="set" mandatory="false" pattern="^0([1-9]%d+)$"
position="3" replacement="+49%1" var_in="caller_id_number"
var_out="caller_id_number"/>
</route_elements>
</call_route>
d.me...@gmail.com
Am Donnerstag, 7. März 2013 10:07:09 UTC+1 schrieb Peter Kozak:
On 03/07/2013 09:54 AM, Peter Kozak wrote:
> On 03/07/2013 09:24 AM, d.me...@gmail.com wrote:
>> Brachte Brachte leider keinen Erfolg.. :(
>
> Was passiert, wenn Du einfach
>
> contact = +496021YYYYYYY
Es waere dann keine eingehende Route noetig, die gateway3 in
+496021YYYYYYY umwandelt.
Werd ich morgen ausprobieren und mich wieder dazu melden. Danke.
<route_element position="1" var_out="sip_to_user" var_in="sip_to_user"
replacement="00496021YYYYYYY" pattern="^gateway3$" mandatory="true"
action="match"/>
Dies haette wahrscheinlch sogar fast funktioniert. Du haettest in dem
element wohl nur statt var_out="sip_to_user" einfach
var_out="destination_number" verwenden muessen.
Also wertet Freeswitch als angerufene Nummer das aus was in destination_number steht, sprich wenn ich als Nummern Source sip_to_user setze macht GS bzw. Freeswitch intern quasie ein destination_number = sip_to_user?
Weiterhin wuerde ich bei sowas empfehlen, als Replacement nicht
"00496021YYYYYYY" sondern immer das e164 Format "+496021YYYYYYY" zu
benutzen.
Das spart ein Zeichen ;)
Der Hintergrund ist aber, dass man das moeglichst einheitlich haben
sollte. Das "prerouting" wandelt z.B. eine gewaehlte Nummer auch immer
zunaechst in dieses Format.
Hatte das so versucht, das der Sipgate-Team Account auch so ankommt ;) Aber stimmt, wenn ich es eh schon ersetze kann ich es auch gleich ins einheitliche Format bringen.
Die folgende Route dient dann noch um die Caller-ID anzupassen:
<call_route endpoint_type="phonenumber" name="strip international
prefix" position="1" routing_table="inbound">
<route_elements count="3">
<route_element position="1" var_out="" var_in="destination_number"
replacement="" pattern="^%+496021YYYYYYY$" mandatory="true" action="match"/>
<route_element action="set" mandatory="false" pattern="^00([1-9]%d+)$"
position="2" replacement="+%1" var_in="caller_id_number"
var_out="caller_id_number"/>
<route_element action="set" mandatory="false" pattern="^0([1-9]%d+)$"
position="3" replacement="+49%1" var_in="caller_id_number"
var_out="caller_id_number"/>
</route_elements>
</call_route>
Okay, hier nochmal eine Verständnissfrage. Die Inbound-Einträge greifen für jedes Gateway, man braucht also das ganze nur einmal machen, bzw. ergänzen wenn man Gateways hat die die Rufnummer in einem anderen Format liefern sollten? Weil momentan habe ich für Sipgate-Basic und Sipgate-Team zwei identische Einträge ;) Und diese zwei Einträge machen jetzt aus 00496021 bzw 06021 ein +496021 richtig? :)
Ich find nämlich immer wichtig zu wissen warum man etwas macht um auch zu verstehen wie das funktioniert.
Danke und Gruß
Dennis Meyer
Peter Kozak
> Also wertet Freeswitch als angerufene Nummer das aus was in
> destination_number steht, sprich wenn ich als Nummern Source sip_to_user
> setze macht GS bzw. Freeswitch intern quasie ein destination_number =
> sip_to_user?
In einer "inbound" Route kannst du destination_number mit jedem
beliebigen Wert ueberschreiben.
> Aber stimmt, wenn ich es eh schon ersetze kann ich es auch gleich ins
> einheitliche Format bringen.
einheitlich zu haben.
> Okay, hier nochmal eine Verst�ndnissfrage. Die Inbound-Eintr�ge greifen
> f�r jedes Gateway, man braucht also das ganze nur einmal machen, bzw.
> erg�nzen wenn man Gateways hat die die Rufnummer in einem anderen Format
> liefern sollten?
Die Regeln greifen fuer das, was in den Route-Elements steht. D.h. wenn
dort kein Gateway spezifiziert ist, dann gilt das fuer alle.
Es muss allerdings min. ein "match" Element greifen, damit die "set"
Elemente in einer ROute wirken.
> Weil momentan habe ich f�r Sipgate-Basic und
> Sipgate-Team zwei identische Eintr�ge ;) Und diese zwei Eintr�ge machen
wenn pro Gateway eine Regel vorhanden ist?
> Ich find n�mlich immer wichtig zu wissen warum man etwas macht um auch
d.me...@gmail.com
Am Donnerstag, 7. März 2013 12:28:02 UTC+1 schrieb Peter Kozak:
Was passiert, wenn Du einfach
contact = +496021YYYYYYY
in Gateway-Settings eintraegst?
> Weil momentan habe ich f�r Sipgate-Basic und
> Sipgate-Team zwei identische Eintr�ge ;) Und diese zwei Eintr�ge machen
> jetzt aus 00496021 bzw 06021 ein +496021 richtig? :)
"inbound" Regeln? Wie sind diese mit jeweils einem Gateway verknuepft,
wenn pro Gateway eine Regel vorhanden ist?
<call_route endpoint_type='phonenumber' name='strip international' position='1' routing_table='inbound'>
<route_elements count='3'>
<route_element action='match' mandatory='true' pattern='^00([1-9]%d+)$' position='1' replacement='+%1' var_in='destination_number' var_out='destination_number'></route_element>
<route_element action='set' mandatory='false' pattern='^00([1-9]%d+)$' position='2' replacement='+%1' var_in='caller_id_number' var_out='caller_id_number'></route_element>
<route_element action='set' mandatory='false' pattern='^0([1-9]%d+)$' position='3' replacement='+49%1' var_in='caller_id_number' var_out='caller_id_number'></route_element>
</route_elements>
</call_route>
Peter Kozak
> Also ich hatte diese inbound Regel zweimal drin stehen, jeweils f�r
> spezifiziert, so das diese Regel ja auf alle Gateways greift, sprich ich
> brauche es ja nur einmal drin haben. Richtig?
Bei eingehenden Anrufen wird immer die erste Regel genommen, die
zutrifft. Wahrscheinlich wurde die zweite Regel dann einfach nie
ausgefuehrt.
> Die Fritzbox erwartet als Rufnummer vom Telefon sprich Gemeinschaft die
> 620. Also ist caller_id_number auf 620 zu setzen?
> caller_id_number ist also immer die Rufnummer des Telefon bzw. eben des SIP-Accounts
Alle Rufnummern des SIP-Accounts + die Werte aus "clip_no_screening"
stehen im Array "val:caller_id_numbers".
Folgendes wuerde also z.B. die 620 setzen, wenn dein SIP-Account eine
Rufnummer "620" besitzt.
<route_element action="set" mandatory="false" pattern="^(%d+)$"
replacement="620" var_in="val:caller_id_numbers"
var_out="caller_id_number"/>
Oder fest auf 620 verdrahten:
<route_element action="set" mandatory="false" pattern=""
> Und als destination_number ist die angerufene Nummer zu verstehen?
> Hier erwartet die Fritzbox diese aber nicht im e164 Format, ich denke
> das funktioniert nicht und ich muss diese wieder umwandeln?
<route_element action="match" mandatory="true" pattern="^%+49(%d+)$"
replacement="0%1" var_in="destination_number" var_out="destination_number"/>
Du brauchst aber wahrscheinlich zwei Routen, einmal international und
einmal national, also z.B.
<call_route endpoint="fritzbox" endpoint_type="gateway" name="fritzbox
national" routing_table="outbound">
<route_elements count="2">
<route_element action="match" mandatory="true" pattern="^%+49(%d+)$"
replacement="0%1" var_in="destination_number" var_out="destination_number"/>
</route_elements>
</call_route>
<call_route endpoint="fritzbox" endpoint_type="gateway" name="fritzbox
international" routing_table="outbound">
<route_elements count="2">
<route_element action="match" mandatory="true" pattern="^%+(%d+)$"
replacement="00%1" var_in="destination_number"
var_out="destination_number"/>
</route_elements>
</call_route>
Vielleicht waere es auch intelligenter statt zwei Routen nur eine zu
benutzen, allerdings fuer nationale anrufe die 0049 in einem weiteren
Element abzuschneiden:
<call_route endpoint="fritzbox" endpoint_type="gateway" name="fritzbox"
routing_table="outbound">
<route_elements count="3">
<route_element action="match" mandatory="true" pattern="^%+(%d+)$"
replacement="00%1" var_in="destination_number"
var_out="destination_number"/>
<route_element action="set" mandatory="false" pattern="^0049(%d+)$"
replacement="0%1" var_in="destination_number" var_out="destination_number"/>
</route_elements>
</call_route>
Das hat neben der besseren Uebersichtlichkeit den weiteren Vorteil, dass
nicht ein zweites mal versucht wird zu waehlen, wenn die erste Route mit
einem in "failover" definierten Wert fehlschlaegt.
Wie man auch sieht, greift das zweite Element auf die bereits im ersten
Element bearbeitete Nummer in "destination_number" zu.
Die Variablen sind auch nicht fest vorgegegeben, man kann auch eigene
benutzen. D.h. in einem Element weiter oben setzen und in einem weiter
unten abfragen. Aber alles nur innerhalb eines Routing-Eintrages.
Folgendes sollte also auch gehen:
<route_element action="match" mandatory="true" pattern="^%+(%d+)$"
replacement="00%1" var_in="destination_number"
var_out="fritzbox_destination"/>
<route_element action="set" mandatory="false" pattern="^%+49(%d+)$"
replacement="0%1" var_in="destination_number"
var_out="fritzbox_destination"/>
<route_element action="match" mandatory="true" pattern="^(0%d+)$"
replacement="%1" var_in="fritzbox_destination"
var_out="destination_number"/>
Die Beispiele oben beinhalten keine Garantie fuer Fehlerfreiheit, ich
habe sie gerade nur mit einem Texteditor zusammenkopiert :)
d.me...@gmail.com
Am Freitag, 8. März 2013 08:18:57 UTC+1 schrieb Peter Kozak:
> Hier erwartet die Fritzbox diese aber nicht im e164 Format, ich denke
> das funktioniert nicht und ich muss diese wieder umwandeln?
Ja. z.B.
<route_element action="match" mandatory="true" pattern="^%+49(%d+)$"
replacement="0%1" var_in="destination_number" var_out="destination_number"/>
Du brauchst aber wahrscheinlich zwei Routen, einmal international und
einmal national, also z.B.